TRABAJO HACKING ÉTICO
MANUAL METODOLÓGICO PARA PRUEBAS DE SEGURIDAD OSSTMM 3 Y GUÍA DE PRUEBAS OWASP 4.0
SI. EMILIANI SILGADO RAFAEL EDUARDO SI. SIERRA CABALLERO YIMMY REINALDO
POLICÍA NACIONAL DE ESCUELAS DIRECCIÓN NACIONAL DE ESCUELAS ESCUELA DE TELEMÁTICA Y ELECTRÓNICA ESPECIALIZACIÓN EN INFORMÁTICA FORENSE BOGOTÁ D.C. 2015
MANUAL METODOLÓGICO PARA PRUEBAS DE SEGURIDAD OSSTMM 3 El Manual de Pruebas de Metodología Abierta de Seguridad Fuente (OSSTMM) proporciona una metodología para una prueba de seguridad completa, aquí referido como una auditoría OSSTMM. Una auditoría OSSTMM es una medida exacta de la seguridad a nivel operativo que está libre de hipótesis y la evidencia anecdótica. Como una metodología está diseñada para ser consistente y repetible. Como proyecto de código abierto, permite que cualquier analista de seguridad aportar ideas para la realización de pruebas de seguridad más precisos, viables y eficientes. Además permite la libre difusión de información y la propiedad intelectual. El propósito principal de este manual es proporcionar una metodología científica para la caracterización precisa de la seguridad operacional (OpSec) a través del examen y la correlación de los resultados de pruebas de una manera consistente y confiable. Este manual es adaptable a casi cualquier tipo de auditoría, incluyendo pruebas de penetración, hacking ético, evaluaciones de seguridad, evaluaciones de vulnerabilidad, de color rojo-azul-teaming, trabajo en equipo, y así sucesivamente. Está escrito como un documento de investigación de seguridad y está diseñado para la verificación de seguridad de hechos y la presentación de la métrica a un nivel profesional. Un segundo propósito es proporcionar directrices que, cuando se siguen correctamente, permitirán que el analista efectúe una auditoría OSSTMM certificada. Existen estas directrices para asegurar lo siguiente: 1. La prueba se llevó a cabo a fondo. 2. La prueba incluyó a todos los canales necesarios. 3. La postura de la prueba cumplió con la ley. 4. Los resultados son medibles de forma cuantificable. 5. Los resultados son consistentes y repetibles. 6. Los resultados contienen sólo los hechos derivados de las mismas pruebas. Un beneficio indirecto de este manual es que puede actuar como una referencia central en todas las pruebas de seguridad, independientemente del tamaño de la organización, la tecnología, o protección. Para producir una prueba certificada OSSTMM que puede recibir la acreditación para la seguridad operacional de los objetivos, se requiere una estrella para ser firmado por el analista (s) que realiza el examen. La estrella también debe cumplir con los requisitos de información en este manual. El STAR puede ser sometido a ISECOM para su revisión y certificación oficial. Una prueba de certificado y un informe acreditado no tiene que demostrar que todo el manual o cualquier subsecciones específicas fueron seguidos. Sólo se necesita mostrar lo que era y no fue probado para ser aplicable para la certificación.
Una auditoría OSSTMM certificado proporciona las siguientes ventajas: 1. Sirve como prueba de una prueba objetiva 2. Permanencia del analista responsable del ensayo 3. Proporciona unos resultados claros al cliente 4. Proporciona una visión más amplia que un resumen ejecutivo 5. Proporciona métricas comprensibles OpSec es una combinación de separación y controles. Bajo OpSec, para que una amenaza sea eficaz, debe interactuar directa o indirectamente con el activo. Para separar la amenaza del activo y evitar posibles interacciones. Por lo tanto, es posible tener un total del (100%) de seguridad si la amenaza y el activo están completamente separados uno del otro. De lo contrario lo que se tiene es la seguridad del activo que es proporcionada por los controles que pones en el activo o el grado en que a disminuir el impacto de la amenaza. Para entender mejor cómo OpSec puede trabajar dentro de un entorno operativo, debe reducirse a sus elementos. Estos elementos permiten cuantificar la superficie de ataque, que es la falta de separaciones específicas y controles funcionales que existen para cada Vector y la dirección de la interacción. El enfoque reduccionista nos resuelve la necesidad de ver la seguridad y la protección de una forma nueva, una que permita que existan independiente del riesgo y totalmente capaz de crear Seguridad perfecta, el equilibrio exacto de la seguridad y los controles con operaciones y limitaciones. Sin embargo, para ver la seguridad de una manera nueva requiere nueva terminología también. Superficie de ataque: La falta de separaciones específicas y controles funcionales que existen para ese vector. Vector de ataque: Un sub-ámbito de un vector creado con el fin de acercarse a la pruebas de seguridad en un ámbito complejo de una manera organizada. Se basa en el divide y vencerás paradigma de diseño de algoritmo que consiste en descomponer recursivamente un problema en dos o más sub-problemas del mismo tipo, hasta que éstos se vuelven lo suficientemente simple como para ser resueltos directamente. Controles: Controles de impacto y reducción de pérdidas. La garantía de que los activos físicos y de información, así como los propios canales están protegidos de diversos tipos de interacciones no válidas según lo definido por el canal. Se han definido diez controles. Los primeros cinco controles son de clase A y son los control de interacción, los otro cinco controles son de Clase B y son importantes para el control de los procedimientos.
Limitaciones: Identifica el estado actual de los límites percibidos y conocidos para los canales, las operaciones y los controles que se han verificado en la auditoría. Los tipos de limitación se clasifican por la forma en que interactúan con la seguridad y la protección a nivel operativo. Por lo tanto, las opiniones en cuanto a impacto, la disponibilidad en la naturaleza, la dificultad para llevar a cabo, y la complejidad no se utilizan para clasificarlos. Operaciones: Las operaciones son las necesidades de seguridad que hay que tener para ser interactivo, útil, público, abierto, o disponible. Seguridad Perfecta: El equilibrio exacto de la seguridad y los controles con operaciones y limitaciones. Porosidad: Todos los puntos interactivos, operaciones, que se clasifican como visibilidad, acceso, o Confianza. Seguridad: Es una forma de protección donde la amenaza o sus efectos se controlan. Con el fin de estar a salvo, los controles deben estar en su lugar para asegurar la amenaza en sí o los efectos de la amenaza se minimizan a un nivel aceptable por el propietario de los activos o gerente. Este manual cubre la seguridad como "controles", que son los medios para mitigar los ataques en un entorno operativo o en vivo. Protección: Una forma de protección donde se crea una separación entre los activos y la amenaza. Esto incluye pero no se limita a la eliminación de cualquiera de los activos o la amenaza. Para ser seguro, el activo se elimina de la amenaza o la amenaza se retira del activo. Este manual cubre la seguridad desde una perspectiva operacional, verificar las medidas de seguridad en un entorno de operación o en vivo. Rav: El rav es una medida de escala de una superficie de ataque, la cantidad de interacciones no controlados con un objetivo, que se calcula por el equilibrio cuantitativo entre porosidad, limitaciones y controles. En esta escala, 100 rav (también a veces se muestra como 100% rav) es el equilibrio perfecto y nada menos es demasiado pocos controles y, por tanto, una superficie de ataque mayor. Objetivo: se determina en el ámbito de lo que usted está atacando, y se compone del activo y cualquier protección que el activo pueda tener. Vector: La dirección de una interacción. Vulnerabilidad: Una clasificación de Limitación en que una persona o proceso puede acceder, negar el acceso a los demás, o se ocultan activos dentro del alcance.
Seguridad Seguridad es una función de separación. O bien la separación entre un activo y cualquier amenaza existe o no. Hay 3 formas lógicas y dinámicas para crear esta separación: 1. 2. 3.
Mover el activo para crear una barrera física o lógica entre ella y las amenazas. Cambiar la amenaza a una inofensiva. Destruir la amenaza
Al analizar el estado de la seguridad podemos ver donde existe la posibilidad de interacción y donde no lo hay. Sabemos que algunos, todos, o incluso ninguna de estas interacciones pueden ser necesarios para las operaciones. Al igual que las puertas en un edificio, algunas de las puertas son necesarias para los clientes y otras para los trabajadores. Sin embargo, cada puerta es un punto interactivo que puede aumentar tanto las operaciones necesarias y los no deseados, como el robo. Controles Cuando las interacciones deben estar presentes entonces existen los controles para proveer protección a las operaciones. El objetivo principal es reducir el impacto de las amenazas sobre los activos. Existen diez tipos de controles divididos en dos clases:
Controles de interacción (Clase A): estos controles afectan directamente a la visibilidad, accesos o confianza.
Controles de proceso (Clase B): se utilizan para crear procesos defensivos. No afectan a las interacciones sino que proporcionan seguridad cuando la amenaza está presente. Controles de interacción
Autenticación Se basa en el intercambio y validación de credenciales, donde se hacen presentes mecanismos de identificación y autorización. Indemnización Es un compromiso entre el propietario del activo y la parte que interactúa. Puede ser un aviso legal para el caso en que una de las partes no cumpla con las reglas prefijadas; o puede ser un seguro contratado a terceros para el caso que se produzcan fallas o pérdidas de algún tipo. Resistencia Es el mecanismo que brinda protección a los activos en caso que las interacciones sufran alguna falla. Subyugación Define las condiciones en las cuales ocurrirán las interacciones. Esto quita libertad en la forma de interacción pero disminuye los riesgos.
Continuidad Permite mantener la interacción con los activos aún en caso de fallas. Controles de proceso No repudio Impide que las partes que interactúan nieguen su participación en la interacción. Confidencialidad Impide que la información que circula entre dos partes sea conocida por terceros no autorizados. Privacidad Evita que un tercero conozca la forma en la cual es accedido, mostrado o intercambiado un activo. Integridad Permite identificar cuando un activo ha sido modificado por alguien ajeno a la interacción en curso. Alarma Es un aviso de que ha ocurrido un interacción o que la misma está en curso. Objetivos para el Aseguramiento de la Información Objetivos para el aseguramiento de la información Confidencialidad Integridad Disponibilidad
Controles Confidencialidad, Privacidad, Autenticación Resistencia. Integridad, No Repudio, Subyugación Continuidad, Indemnización, Alarma
Limitaciones La incapacidad de un mecanismo de protección de funcionar como se espera de él, se conoce como limitación. Dicho de otra manera, las limitaciones son los inconvenientes que presentan los controles para mantener la separación entre los activos y las amenazas. Es posible clasificar las limitaciones dentro de cinco categorías: Limitaciones Es una falla que puede permitir el acceso no autorizado a un activo o Vulnerabilidad puede denegar dicho acceso a alguien que sí esté autorizado. Debilidad Es una falla que reduce o anula los efectos de los controles de interacción. Preocupación Es una falla que reduce los efectos de los controles de proceso. Es una acción injustificada que permite dejar visible, ya sea de forma Exposición directa o indirecta, a un activo. Es un elemento desconocido y no se encuentra dentro de las Anomalía operaciones normales. Por lo general es síntoma de algún fallo pero que todavía no se comprende.
Relación de los elementos
Justificación de las limitaciones El concepto de que las limitaciones son sólo limitaciones si no tienen justificación de negocio es falso. Una limitación es una limitación si se comporta en uno de los factores limitantes como se describe aquí. La justificación de un riesgo es una limitación que se reunió con un control de algún tipo o simplemente aceptación de la limitación. El riesgo es aceptar las limitaciones ya que a menudo estas se reducen a: el daño que una limitación puede causar un costo no justificado para corregir o controlar la limitación, la limitación debe permanecer de acuerdo con la legislación, los contratos, o política, o una conclusión de que la amenaza no existe o es poco probable para esta limitación en particular. Dado el riesgo las justificaciones no son una parte del cálculo de una superficie de ataque, todas las limitaciones descubiertas deben ser contadas dentro de la superficie de ataque sin importar si las mejores prácticas, la práctica común, o práctica jurídica indican que no se trata de un riesgo. Si no es así entonces la auditoría no mostrará una verdadera representación de la seguridad operacional en el ámbito de aplicación. Gestionar las limitaciones Otro concepto que debe tomarse en consideración es una de la gestión de fallas y errores en una auditoría. Las tres formas más sencillas de manejar limitaciones es eliminar el área del problema proporcionando el punto interactivo completo, arreglarlos, o aceptarlos como parte de conocer el negocio como la justificación de negocio.
Una auditoría a menudo busca descubrir más de un problema por objetivo. El analista esta para informar de las limitaciones por objetivo y no sólo que son los objetivos débiles. Estas limitaciones pueden estar en las medidas de protección y controla a sí mismos, lo que disminuye OpSec. Cada limitación debe ser clasificada como de lo que ocurre cuando se invoca el problema, incluso si esa invocación es teórica o la verificación de la ejecución es limitada para restringir los daños reales. Categorización teórica, donde se podría hacer ninguna verificación, es una pendiente resbaladiza y debe limitarse a los casos en que la verificación sería reducir la calidad de las operaciones. Luego, al categorizar los problemas, cada limitación debe ser examinado y se calcula en términos específicos de la operación en sus componentes más básicos. Sin embargo, el analista debe estar seguro antes de reportar un "defecto dentro de una falla", donde las fallas comparten el mismo componente y el mismo efecto operativo. Seguridad Real El rol de los controles es reducir y manejar la porosidad. Por cada poro existen diez tipos de controles que pueden ser aplicados y buscan llevar a la seguridad al 100%. Inclusive hay veces en que se puede superar este porcentaje, indicando que se han aplicado controles excesivos, aumentando los costos de manera innecesaria. Luego, las limitaciones reducen la efectividad de los controles. El término seguridad real hace referencia a una instantánea de la superficie de ataque en un ambiente operacional. El Cumplimiento El cumplimiento es otra cosa que la seguridad y existe independiente de seguridad. Es posible que no sea compatible y sin embargo seguro y es posible ser relativamente seguro pero de incumplimiento y por lo tanto de baja confiabilidad. El gran problema con el cumplimiento se requiere una gran cantidad de documentación que ha de ser versionados y actualizado. Esta documentación puede ser de los procesos de negocio, las descripciones, la confianza las evaluaciones, las evaluaciones de riesgos, firmaron pruebas de diseño, auditorías operacionales, certificados, etcétera. Esta documentación será examinada por los auditores internos y externos y lógicamente tiene que cumplir con su existencia en el mundo de un estado de cumplimiento. Definición del alcance • Definir los activos que quieren protegerse. • Identificar el área alrededor de los activos, la cual incluye los mecanismos de protección y los procesos o servicios en torno a los activos. Esta es la zona de compromiso. • Definir todo aquello que se encuentre fuera de la zona de compromiso y sea necesario para mantener operacionales a los activos. Esto incluye a la electricidad, agua, información, leyes, contratos, socios, procesos, protocolos, recursos, etc. Esto es el alcance.
• Definir cómo el alcance interactúa consigo mismo y con el exterior. Caracterizar la dirección de las interacciones, es decir, de adentro hacia adentro, de adentro hacia afuera, de afuera hacia adentro. Estos son los vectores. • Dentro de cada vector las interacciones pueden ocurrir en varios niveles o canales. Se clasifican en: humanos, físicos, medios inalámbricos, telecomunicaciones y redes de datos. Se deben definir las herramientas que se necesitarán para los análisis que se lleven a cabo en los diferentes canales. • Se debe definir el tipo de test que se realizará. El tipo de test depende del conocimiento que se tenga del entorno. De esta forma se pueden encontrar tres grandes categorías: black box (sin conocimiento), gray box (conocimiento incompleto) y white box (conocimiento total). • Verificar que el análisis se encuentra definido dentro de las reglas de compromiso asegurando que los procesos ejecutados no generan malentendidos ni falsas expectativas. Ámbito El alcance es la total seguridad de medio ambiente para cualquier interacción con cualquier tipo de activos que se pueden incluir los componentes físicos de las medidas de seguridad. El alcance se compone de tres clases de las que hay cinco canales: las telecomunicaciones y redes de datos seguridad Canales de la COMSEC clase, seguridad física y humana PHYSSEC Canales de la clase, y toda la gama Seguridad Inalámbrica SPECSEC Canal de la clase. Las clases son de denominaciones oficiales actualmente en uso en la industria de la seguridad, el gobierno y los militares. Las clases se utilizan para definir el área de estudio, investigación, o una operación. Sin embargo, los canales son los medios específicos de interacción con los activos. Un activo puede ser cualquier cosa que tiene valor para el propietario. Definición de un Test de Seguridad • Definir los activos que quieren protegerse. • Identificar el área alrededor de los activos, la cual incluye los mecanismos de protección y los procesos o servicios en torno a los activos. Esta es la zona de compromiso. • Definir todo aquello que se encuentre fuera de la zona de compromiso y sea necesario para mantener operacionales a los activos. Esto incluye a la electricidad, agua, información, leyes, contratos, socios, procesos, protocolos, recursos, etc. Esto es el alcance. • Definir cómo el alcance interactúa consigo mismo y con el exterior. Caracterizar la dirección de las interacciones, es decir, de adentro hacia adentro, de adentro hacia afuera, de afuera hacia adentro. Estos son los vectores. • Dentro de cada vector las interacciones pueden ocurrir en varios niveles o canales. Se clasifican en: humanos, físicos, medios inalámbricos, telecomunicaciones y redes de datos. Se deben definir las herramientas que se necesitarán para los análisis que se lleven a cabo en los diferentes canales.
• Se debe definir el tipo de test que se realizará. El tipo de test depende del conocimiento que se tenga del entorno. De esta forma se pueden encontrar tres grandes categorías: black box (sin conocimiento), gray box (conocimiento incompleto) y white box (conocimiento total). • Verificar que el análisis se encuentra definido dentro de las reglas de compromiso asegurando que los procesos ejecutados no generan malentendidos ni falsas expectativas. Canales Clase Seguridad Física
Canal Humano
Física
Seguridad en el espectro
Wireless
Comunicaciones seguras
Telecomunicaciones
Redes de datos
Descripción Comprende el elemento humano de la comunicación donde la interacción es física o psicológica. Pruebas de seguridad física donde el canal es tanto físico como no electrónico en la naturaleza. Comprende el elemento tangible de seguridad donde la interacción requiere esfuerzo físico o un transmisor de energía para manipular. Comprende todas las comunicaciones electrónicas, señales y emanaciones que tienen lugar en el espectro EM conocido. Esto incluye Elsec como las comunicaciones electrónicas, SIGSEC como señales, y EMSEC que son emanaciones desligadas por cables. Comprende todas las redes de telecomunicaciones, digitales o análogas, la interacción toma lugar sobre los teléfonos establecidos o redes telefónicas similares Comprende todos los sistemas y redes de datos electrónicos donde la interacción se lleva a cabo a través de cable establecido y líneas de la red de cable. Redes de datos
Tipo de test más comunes Hay seis tipos diferentes basados en la cantidad de información que el analista conoce de los objetivos, lo que el objetivo sabe acerca del analista o expectativas de la prueba, y la legitimidad de la prueba. Algunas pruebas pondrán a prueba la habilidad del analista, más que valorar la seguridad de un objetivo. Tipo 1
2
3
4
5
Descripción El analista se acopla al objetivo sin conocimiento previo de sus defensas, los activos, o canales. El objetivo se prepara para la auditoría, sabiendo de antemano todos los detalles de la auditoría. Una auditoría ciega prueba principalmente las habilidades del analista. La amplitud y profundidad de una auditoría ciega sólo puede ser tan vasto como el conocimiento y la eficiencia de aplicación del Analista. Doble caja El analista se acopla al objetivo sin conocimiento previo de su defensa, Negra los activos, o canales. El objetivo no es notificado con antelación sobre el alcance de la auditoría, los canales de prueba, o los vectores de prueba. Una auditoría de doble ciego pone a prueba las habilidades del analista y la preparación de la meta a las variables desconocidas de agitación. La amplitud y profundidad de cualquier auditoría ciego sólo puede ser tan vasto como el conocimiento y la eficiencia de aplicación del Analista. Esto también se conoce como una prueba de Box Negro o la prueba de penetración. Caja Gris El analista se acopla al objetivo con un conocimiento limitado de sus defensas y de los activos y el conocimiento cabal de los cauces. El objetivo se prepara para la auditoría, sabiendo de antemano todos los detalles de la auditoría. Una auditoría de caja gris a prueba la habilidad del analista. La naturaleza de la prueba es la eficiencia. La amplitud y profundidad depende de la calidad de la información proporcionada a la analista antes de la prueba, así como el conocimiento del Analista aplicable. Este tipo de prueba se refiere a menudo como una prueba de la vulnerabilidad y la mayoría de las veces es iniciada por el destino como una autoevaluación. Doble caja gris El analista se acopla al objetivo con un conocimiento limitado de sus defensas y de los activos y el conocimiento cabal de los cauces. El objetivo se informe previamente de la trama de alcance y momento de la auditoría, pero no los canales probados o los vectores de prueba. Una doble auditoría caja gris a prueba la habilidad del analista y preparación del objetivo a las variables desconocidas de agitación. La amplitud y profundidad depende de la calidad de la información proporcionada a la analista y el objetivo antes de la prueba, así como el conocimiento del Analista aplicable. Esto también se conoce como una prueba de caja blanca Tándem El analista y el objetivo se preparan para la auditoría, tanto sabiendo de antemano todos los detalles de la auditoría. Una auditoría tándem pone a prueba la protección y los controles de la meta. Sin embargo, no se puede comprobar el estado de preparación de la meta a las Caja negra
6
Reverso
variables desconocidas de agitación. La verdadera naturaleza de la prueba es la minuciosidad que el analista tiene la vista de todas las pruebas y sus respuestas. La amplitud y profundidad depende de la calidad de la información proporcionada a la analista antes de la prueba (transparencia), así como el conocimiento del Analista aplicable. Esto a menudo se conoce como una auditoría interna o una prueba de la caja cristalina y el analista es a menudo parte del proceso de seguridad. El analista se acopla al objetivo con pleno conocimiento de sus procesos y la seguridad operacional, pero el objetivo no sabe nada de qué, cómo, o cuando el analista será la prueba. La verdadera naturaleza de esta prueba consiste en auditar el estado de preparación de la meta a variables desconocidas y vectores de agitación. La amplitud y profundidad depende de la calidad de la información proporcionada a la analista y el conocimiento y la creatividad aplicable del Analista. Esto también se llama a menudo un ejercicio Equipo Rojo.
Reglas de compromiso Estas reglas definen las directrices operacionales de 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 los trabajos de prueba.
A. Ventas y Marketing 1. El uso del miedo, la incertidumbre, la duda y el engaño no puede ser utilizado en las ventas o presentaciones de marketing, sitios web, material de apoyo, informes o análisis de las pruebas de seguridad con el fin de vender o proporcionar pruebas de seguridad. Esto incluye pero no se limita a poner de relieve los crímenes, los hechos, los perfiles de criminales o de hackers glorificados, y las estadísticas de motivar las ventas. 2. Se prohíbe el ofrecimiento de servicios gratuitos en caso de no penetrar en el objetivo. 3. craqueo, la piratería, y concursos de traspaso público para promover la garantía de seguridad para las ventas o comercialización de pruebas de seguridad o de seguridad de productos, están prohibidos. 4. Nombre clientes pasados o presentes en la comercialización o ventas para los clientes potenciales sólo se permite si el trabajo para el cliente era específicamente lo mismo que ser comercializado o vendido y el cliente llamado ha dado su permiso por escrito para hacerlo.
5. Es necesario que los clientes se les aconseja veraz y objetivamente en lo que respecta a sus medidas de seguridad y de seguridad. La ignorancia no es una excusa para consultoría deshonesto. B. Evaluación / Estimación Entrega 6. Realización de pruebas de seguridad contra cualquier ámbito sin la autorización por escrito del propietario de destino o autoridad correspondiente está estrictamente prohibido. 7. Las pruebas de seguridad de los sistemas, obviamente, muy inseguros e inestables, ubicaciones y procesos está prohibida hasta la infraestructura de seguridad adecuada se ha puesto en marcha. C. Contratos y Negociaciones 8. Con o sin un contrato de acuerdo de no divulgación, se requiere el analista de seguridad para garantizar la confidencialidad y no divulgación de información de los clientes y resultados de las pruebas. 9. Los contratos deben limitar la responsabilidad al coste del trabajo, a menos que la actividad maliciosa se ha probado. 10. Los contratos deben explicar claramente los límites y peligros de la prueba de seguridad como parte de la declaración de trabajo. 11. En el caso de las pruebas de control remoto, el contrato debe incluir el origen de los analistas por dirección, número de teléfono o la dirección IP. 12. El cliente debe proporcionar una declaración firmada que proporciona permiso pruebas eximir los analistas de prevaricación en el ámbito de aplicación, y los daños de responsabilidad civil con el costo del servicio de auditoría con la excepción donde la actividad maliciosa se ha probado. 13. Los contratos deben contener nombres de los contactos de emergencia y números de teléfono. 14. El contrato debe incluir claras y permisos específicos para las pruebas que implican fallas de supervivencia, denegación de servicio, pruebas de proceso, y la ingeniería social. 15. Los contratos deben contener el proceso de contrato y la declaración de trabajo (SOW) los cambios futuros. 16. Los contratos deben contener los conflictos de intereses verificada por una prueba de seguridad de hecho y de informe.
D. Definición del Alcance 17. El ámbito de aplicación debe estar claramente definido contractualmente antes de verificar los servicios vulnerables. 18. La auditoría debe explicar claramente los límites de las pruebas de seguridad de acuerdo con el ámbito de aplicación. E. Plan de pruebas 19. El plan de pruebas no puede contener los planes, procesos, técnicas o procedimientos que están fuera del área de experiencia o competencia de nivel del analista. F. Proceso de Prueba 20. El analista debe respetar y mantener la seguridad, la salud, el bienestar y la intimidad de los ciudadanos, tanto dentro como fuera del ámbito de aplicación. 21. El analista siempre debe operar dentro de la ley de la ubicación física (s) de los objetivos además de las normas o leyes que rigen el lugar del examen del Analista. 22. Para evitar aumentos temporales en la seguridad durante la duración de la prueba, sólo notificar a las personas clave acerca de la prueba. Es el juicio de que el cliente que discierne que son las personas claves; Sin embargo, se supone que van a ser de la información y de política porteros, administradores de procesos de seguridad, personal de respuesta a incidentes, y el personal de operaciones de seguridad. 23. Si es necesario para la prueba privilegiada, el cliente debe proporcionar dos, fichas separadas, acceso, ya sean contraseñas, certificados, números de identificación segura, insignias, etc., y que debe ser la típica para los usuarios de los privilegios de ser probado en lugar de todo vacío o accesos seguros. 24. Cuando la prueba incluye privilegios conocidos, el analista debe primero prueba sin privilegios (como en un entorno cuadro negro) antes de probar de nuevo con privilegios. Se requieren 25. Los analistas de conocer sus herramientas, donde las herramientas vienen, cómo funcionan las herramientas, y los han probado en un área de prueba restringida antes de usar las herramientas de la organización del cliente. 26. La realización de pruebas de que están destinados expresamente para probar la negación de un servicio o proceso, o de supervivencia sólo se puede hacer con el permiso explícito y sólo en el ámbito donde se hace ningún daño fuera del alcance o de la comunidad en la que reside el alcance.
27. Las pruebas que involucran a 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 escrito de esas entidades. 28. limitaciones verificadas, como infracciones descubiertas, las vulnerabilidades con las tasas de explotación conocida o alta, las vulnerabilidades que son explotables para tener acceso completo, sin control o imposible de encontrar, o que puedan poner en peligro inmediato la vida, descubiertos durante las pruebas han de ser comunicados al cliente una solución práctica tan pronto como se encuentran. 29. Cualquier forma de prueba de inundación en un ámbito se siente abrumado de una fuente más grande y más fuerte está prohibido a través de canales no privada de propiedad. 30. El analista puede no dejar al alcance en una posición de menor seguridad real de lo que era cuando se les proporciona. G. Presentación de informes 31. El analista debe respetar la privacidad de todas las personas y mantener su privacidad para todos los resultados. 32. 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 identifican o estadísticos. 33. El analista no puede firmar los resultados de pruebas e informes de auditoría en el que no participaron directamente. 34. Los informes deben ser objetivo y sin falsedades o cualquier malicia dirigida personalmente. 35. Se necesitarán notificaciones de cliente cada vez que el analista cambia el plan de pruebas, cambia el lugar de la prueba de origen, tiene hallazgos de baja confianza, o que se haya producido algún problema de prueba. Las notificaciones deben proporcionarse previa a la ejecución de los nuevos, peligrosos, o pruebas de alto tráfico, y se requieren actualizaciones regulares de avance. 36. Cuando las soluciones y recomendaciones se incluyen en el informe, que debe ser válido y práctico. 37. Los informes deben marcar claramente todas las incógnitas y anomalías. 38. Los informes deben indicar claramente tanto descubierto con éxito y han fracasado las medidas de seguridad y controles de pérdida.
39. 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. 40. El cliente debe ser notificado cuando se envía el informe como para esperar su llegada y para confirmar la recepción de la entrega. 41. Todos los canales de comunicación para la entrega del informe deben ser de extremo a extremo confidencial. 42. Resultados e informes nunca se pueden usar para obtener ganancias comerciales más allá de la interacción con el cliente. Proceso de cuatro puntos Muchas veces se considera a la seguridad como una estrategia defensiva donde se aplican ciertas recomendaciones y prácticas para proteger al sistema y se supone que todo se comporta como ha sido configurado. Por lo general, esto no es así y, si bien es necesario corroborar las configuraciones para un mejor análisis, también debe probarse el sistema en funcionamiento. Muchas son las variables que intervienen en las operaciones cotidianas, y deben ser tenidas en cuenta al momento de decidir si todo se comporta como se espera. Es por ello que, para un análisis completo, se necesita evaluar la información que provenga de todas las fuentes posibles. El proceso de cuatro puntos considera el análisis del entorno, la interacción directa, las emanaciones del objetivo y la modificación del ambiente, asegurando una revisión integral.
Figura 1. Proceso de cuatro puntos
1. Inducción: Estudiar el entorno donde reside el objetivo, debido a que de una manera u otra condiciona su comportamiento y muchas veces dicho comportamiento deriva directamente de la influencia que recibe del ambiente. 2. Interacción: Interactuar directamente con el objetivo y observar las respuestas obtenidas. 3. Investigación: Analizar las emanaciones que provengan del objetivo, así también como cualquier pista o indicador de las emanaciones mencionadas. 4. Intervención: Modificar los recursos del entorno que necesita el objetivo y observar cómo responde. Cada una de estas fases se divide en diferentes etapas que llevan el análisis a distintos niveles de profundidad, sin embargo ninguna de ellas es ni más ni menos importante que la otra. Inducción • Revisión del entorno: Conocer las normas, leyes, políticas y cultura organizacional que influyen en los requerimientos de seguridad dentro de la empresa o institución. • Logística: Obtener detalles del canal de análisis para evitar falsos positivos o falsos negativos; por ejemplo, en el canal humano, es necesario conocer los horarios de atención del personal, ya que una auditoría brindaría resultados incompletos cuando la organización está en inactividad. Es decir, en los horarios donde no hay atención al público, la interacción sería nula, y un análisis en ese horario no reflejaría la realidad de manera completa. Por lo tanto, es necesario definir los horarios, lugares y tipos de análisis para lograr resultados más precisos. • Verificación de detección activa: Averiguar si existen controles que detecten intrusiones que puedan filtrar o bloquear intentos de análisis, obteniendo falsos negativos como resultado. Interacción • Auditoría de visibilidad: Enumerar los objetivos visibles dentro del alcance. Conocer los puntos donde la interacción sería posible. • Verificación de accesos: Determinar los puntos de acceso, la forma de interacción y el propósito de su existencia. En el caso del canal "redes de datos", el ejemplo más claro es la verificación de puertos. • Verificación de confianza: Verificar las relaciones de confianza entre los objetivos, donde exista acceso a la información sin necesidad de autenticación. • Verificación de controles: Verificar la efectividad de controles de proceso (clase B): no repudio, confidencialidad, privacidad e integridad; el control de alarma se verifica al final de esta metodología.
Investigación • Verificación de procesos: Comprobar el mantenimiento y efectividad de los niveles de seguridad en los procesos establecidos. Además se debe verificar el cumplimiento de las normas, leyes, regulaciones y políticas que se investigaron en el primer punto. • Verificación de la configuración: Revisar el funcionamiento de los procesos en condiciones normales, para identificar cuál es su objetivo y así comprender la justificación de negocio de esa pieza de información. • Validación de propiedad: Revisar la procedencia de los datos, información, sistemas, etc., con el fin de identificar falsificaciones, fraudes, faltas de licencias o violaciones a los derechos de autor. • Revisión de segregación: Revisar los controles que aseguran separación entre la información personal y organizacional. Éste es un punto focal dentro de la ética y la legalidad en el almacenamiento y transmisión de los datos. • Verificación de exposición: Buscar información, disponible de manera abierta, que permita conocer detalles del objetivo. Normalmente se puede obtener una gran cantidad de información en las redes sociales, buscadores, folletos impresos, entre otros, que permite armar un perfil de la organización y que puede ser de vital importancia en las futuras etapas del análisis. • Exploración de inteligencia de negocios: Verificar la existencia de fuentes de información que contengan datos de negocio que debieran ser confidenciales y que, en caso de ser revelados, puedan brindar ventajas competitivas a otras organizaciones. Intervención • Verificación de cuarentena: Verificar la efectiva separación de elementos hostiles. Un ejemplo sencillo de esta etapa es cuando una pieza de software no se comporta dentro de los patrones permitidos, y es aislada para evitar afectar a otros sistemas. • Auditoría de privilegios: Analizar el correcto uso de los sistemas de autenticación y autorización. Analizar la posibilidad de ingresos no autorizados y escaladas de privilegios. • Continuidad de negocio: Analizar la efectividad de los controles de resistencia y continuidad. Esto puede ser realizado mediante intentos de denegación de servicio o denegación de interacciones. • Alerta y revisión de logs: Verificar la correctitud en la relación entre las actividades realizadas y los registros almacenados. Además se deben verificar los mecanismos que proporcionan una forma de alarma ante eventos no deseados. La tripleta Esta prueba de seguridad metodología tiene una base sólida que puede parecer un poco complicado, pero en realidad es fácil en la práctica. Está diseñado como un diagrama de flujo; sin embargo, a diferencia del estándar diagrama de flujo, el flujo representado por las flechas, puede ir hacia atrás y hacia delante. De esta manera, es más integrado y si bien el comienzo y el final son claros, la auditoría tiene una mayor flexibilidad. El analista crea una ruta de acceso única a través de una metodología basada en el destino, el tipo de prueba, el tiempo asignado a la auditoría, y los recursos destinados 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 música, para designar las pruebas necesarias, pero el analista controla el orden, la duración, así como la ejecución. La principal razón para exigir que este nivel de flexibilidad en el abierto OSSTMM (OPEN SOURCE SECURITY Testing Methodology metodología es porque no puede presumir con precisión las justificaciones de las operaciones del canal los gateways de la meta y su adecuado nivel de seguridad. Aplicando esta metodología, por lo tanto, cumplen la meta del analista para responder a las siguientes tres preguntas que conforman la tripleta, OpSec la respuesta a las necesidades. 1. ¿Cómo son las operaciones actuales? Las mediciones pueden ser aplicadas para determinar las áreas de los problemas en el ámbito y que deben abordarse los problemas. El sistema de medición de esta metodología se ha diseñado para asignar los problemas de diferentes maneras, de modo que se pongan de manifiesto si el problema es un problema general o más específico, como un mirador o un error. 2. ¿Cómo funcionan de manera diferente de cómo piensa que deben trabajar? Acceso a las políticas o de un fideicomiso (o incluso un riesgo) evaluación se asignan a las diferentes categorías de los sistemas de medición. Las categorías proporcionan el estado actual los valores en los que se pueden efectuar comparaciones tanto con un estado óptimo de acuerdo con las políticas y una en función de las amenazas. 3. ¿Cómo tienen que trabajar? Que las medidas no muestran diferencias entre política o confianza (o riesgo) evaluación del valor óptimo sin embargo, la prueba de seguridad muestra que, de hecho, hay un problema de protección independientemente de los controles como en política, es posible que claramente denoten un problema. A menudo, incluso sin asignación a la política, la discrepancia entre los controles implementados y la pérdida de la protección es sencillamente evidente. Combinando la tripleta y el Proceso 4 puntos La Tripleta combinada con los cuatro puntos proporciona una aplicación cabal de esta metodología. Los pasos de esta aplicación se pueden resumir de la siguiente manera: 1. Recopilar los datos de forma pasiva las operaciones normales para comprender el destino. 2. Activamente las operaciones de prueba agitando las operaciones más allá de las normales de referencia. 3. Analizar los datos recibidos directamente de las operaciones. 4. Analizar los datos indirectos de los recursos y los operadores (es decir, los trabajadores, programas). 5. Correlación entre inteligencia y conciliar de directa (paso 3) e indirectas (paso 4) datos resultados de la prueba para determinar los procesos operacionales de seguridad. 6. Determinar y reconciliar los errores.
7. Ambos derivan de las mediciones las operaciones normales y agitadas. 8. Correlación entre inteligencia y conciliar entre normal y agitado (pasos 1 y 2) operaciones para determinar el nivel óptimo de protección y control que se aplicaría mejor. 9. Mapa del estado óptimo de las operaciones (paso 8) en los procesos (paso 5). 10 Crear un análisis de diferencias para determinar qué mejoras son necesarias para los procesos de protección necesaria y en el de control (paso 5) para alcanzar el óptimo estado de funcionamiento (paso 8) de la actual.
Gestión de errores La veracidad de una prueba de seguridad no se encuentra en la suma de sus errores, sino en la contabilidad de sus errores. Ya que los errores no pueden ser el fallo de la analista, la comprensión de cómo y donde los errores pueden existir dentro de un test es mucho más razonable que se espera un analista para probar sin errores. Por otra parte, es el analista que intenta lo que no debería ser posible que es más probable que encuentre errores; por lo tanto, lo cual denota que los errores como una cosa negativa descuentos la práctica de pruebas exhaustivas. Tipo de Error 1 Falso positivo
2
Falso negativo
Descripción Algo determinado como verdadero es en realidad revela falso. La respuesta objetivo indica un estado en particular como verdadero aunque en realidad el estado no es cierto. Un falso positivo se produce a menudo cuando las expectativas de los analistas o suposiciones de lo que indica un estado en particular no espera a las condiciones del mundo real que rara vez son blanco y negro. Algo determinado, es en realidad falsa reveló como verdadero. La respuesta objetivo indica un estado en particular, no es cierto aunque en realidad el estado es cierto. Un falso negativo se produce a menudo cuando las expectativas de los analistas o presunciones acerca de la meta no se mantienen en las
3
Positivo gris
4
Negativo Color Gris
5
Specter
6
Indiscreción
7
Entropía Error
condiciones del mundo real, las herramientas no son suficientes para la prueba, las herramientas se emplean mal, o el analista carece de experiencia. Un falso negativo puede ser peligroso ya que es un diagnóstico incorrecto de un estado seguro cuando no existe. Algo respuestas verdaderas a todo, incluso si es falso. El objetivo de respuesta indica un estado en particular, cierto, sin embargo, la meta está diseñado para responder a cualquier causa de este estado si es verdad o no. Este tipo de seguridad a través de la oscuridad puede ser peligrosa, ya que la ilusión no se garantiza que funcione el mismo para todos. Respuesta algo falsa para todo, incluso si es verdadero. El objetivo de respuesta indica un estado en particular, no es cierto, sin embargo el objetivo está diseñado para responder a cualquier causa de este estado si es verdad o no. Este tipo de seguridad a través de la oscuridad puede ser peligrosa, ya que la ilusión no se garantiza que funcione el mismo para todos. Algo las respuestas verdaderas o falsas, pero la situación real es revelado como desconocido. La respuesta objetivo indica un estado como verdadero o falso a pesar de que 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 de la meta. UN fantasma puede ser intencional, una anomalía desde dentro del canal, o el resultado de negligencia o impericia de la analista. Uno de los problemas más comunes en el proceso eco es el supuesto de que la respuesta es el resultado de la prueba. Causa y efecto las pruebas en el mundo real no puede obtener siempre resultados fiables ya que ni la causa ni el efecto puede ser debidamente aislados. Algo respuestas verdaderas o falsas en función a la pregunta. El objetivo de respuesta indica un estado en particular como verdaderas o falsas, pero sólo durante un tiempo determinado, que puede o no seguir un patrón. Si la respuesta no puede ser verificada en un momento en que el estado los cambios, es posible que se impida que el analista de comprender al otro estado. El analista también puede determinar que se trata de una anomalía o un problema con el equipo de prueba, especialmente si el analista no se pudo calibrar el equipo antes de la prueba logística apropiada y controles. Una indiscreción puede ser peligrosa ya que puede dar lugar a una falsa presentación de informes sobre el estado de la seguridad. La respuesta es pérdida o confusión en ruido de la señal. La respuesta no puede indicar con precisión el estado como verdadero o falso debido a una alta relación señal a ruido. Similar a la idea de la pérdida de un haz de luz del sol, el analista puede determinar correctamente hasta que el ruido se reduce. Este tipo de medio ambiente causado error rara vez
Falsificación
Error de muestreo
Restricción
Propagación
Error humano
existe en un laboratorio, sin embargo, es un hecho 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 ha hecho la pregunta. La respuesta objetivo indica un estado como verdadero o falso a pesar de que en realidad el estado depende de variables desconocidas en gran medida debido a prejuicios. Este tipo de seguridad a través de la oscuridad puede ser peligrosa, ya que la tendencia cambiará cuando las pruebas vienen de diferentes vectores o emplear técnicas diferentes. También es probable que el destino no sea consciente de la parcialidad. La respuesta no puede representar al conjunto debido a que el alcance se ha modificado. El objetivo es una muestra sesgada de un sistema más grande o un mayor número de estados posibles. Este error normalmente se produce cuando una autoridad influye en el estado de funcionamiento de la meta para la duración de la prueba. Esto puede ser a través de determinadas limitaciones de tiempo en la prueba o un sesgo de prueba sólo los componentes designados como "importante" dentro de un sistema. Este tipo de error se producirá una tergiversación de la seguridad operacional. La respuesta varía en función de las limitaciones de las herramientas que se utilizan. Las limitaciones de los sentidos o capacidades de los equipos indican un estado determinado como verdadero o falso a pesar de que el estado actual es desconocido. Este error no se debe a un mal juicio u opciones equipo equivocado sino que es la incapacidad para reconocer las limitaciones que se han impuesto o limitaciones. La respuesta se supone que es de un estado o de la otra, aunque no hay ninguna prueba. El analista no hacer una prueba en particular o tiene una tendencia a ignorar un resultado determinado debido a un supuesto resultado. Esto es a menudo un deslumbrante de la experiencia o sesgo de confirmación. La prueba se puede repetir muchas veces o las herramientas y el equipo podrán ser modificados para tener los resultados deseados. Como su nombre indica, un proceso que no reciben información sobre los errores siguen siendo desconocidos o ignorados se propagan más errores como los ensayos. Errores de propagación puede ser peligroso porque los errores propagados desde temprano en las pruebas pueden no ser visibles durante un análisis de conclusiones. Por otra parte, un estudio de todo el proceso de prueba es necesario para descubrir errores de propagación. La respuesta varía en función de la habilidad del analista.
Un error provocado por la falta de capacidad, experiencia, o la comprensión no es uno de los prejuicios y es siempre un factor que está presente, independientemente de la metodología o técnica. Mientras que un experimentado Analista puede hacer errores de propagación, uno sin experiencia es más probable de no reconocer errores humanos, algo que la experiencia nos enseña a reconocer y compensar. Estadísticamente, hay una relación indirecta entre la experiencia y los errores humanos. La menor experiencia un analista tiene, cuanto mayor sea la cantidad de errores humanos una auditoría puede contener. Trabajar con errores de la prueba Durante la fase de análisis, el analista puede hacer un seguimiento de la cantidad y la gravedad de la operación los errores de la prueba. Una auto-evaluación sencilla puede crear un margen de errores de operación durante el examen en el que el analista puede utilizar para cualquier trama la minuciosidad del actual de la auditoría o de otros controles de sistemas similares. Ya que es un auto evaluación, tendrá una tendencia a estar sesgados. El analista debe tener mucho cuidado para que sea lo más objetivos posible, como una forma de garantía de la calidad de la prueba y el proceso de prueba. A pesar de que algunos pueden tratar de descartar errores de la prueba que se encontraban en el fallo del analista, el seguimiento de todos los errores sólo puede mejorar en el futuro las pruebas y no es algo que ocultar. Errores va a suceder y no son más que el intento del analista a interactuar con un sistema de cambio. Independientemente del número y la gravedad de los errores, el seguimiento de errores de la prueba servirá como un registro de las dificultades y la complejidad de la auditoría y la competencia del analista para deducir los errores. Un registro de errores de la prueba desde el ámbito también le ayudará a resumir el medio ambiente de una manera simplista. Se trata de un directo con reducción del Resumen Ejecutivo que a menudo se describe la opinión del analista sobre el estado de la seguridad en donde unos pocos errores no mostrarán un destino bastante estático y el medio ambiente. Muchos errores muestran un entorno caótico y uno que puede faltar controles para gestionar el cambio o la pérdida. En general, prueba de registros son útiles para entender la complejidad de la auditoría y control de cambios entre las auditorías de regularidad. Resultados de la prueba A menudo acompañada de soluciones recomendadas o se ofrece consultorías, ninguna de los cuales es necesaria en una auditoría. Las soluciones recomendadas se pueden proporcionar como un valor añadido a una prueba de seguridad pero no se considera obligatorio. A menudo no hay
soluciones adecuadas en función de la limitada visión un analista tiene del entorno del cliente. Por lo tanto, las soluciones no son necesarias como parte de una auditoría. Con frecuencia, la prueba supera los límites de un control de seguridad. En el combate, el analista debe informar de los hechos siempre estado actual de la seguridad, las limitaciones dentro de ese estado actual y cualquier de los procesos que causaron los límites de la aplica controles y protecciones. Para medir tanto el rigor de la prueba y la protección de la población, el uso de esta metodología debe concluir con la prueba de seguridad Informe de Auditoría, disponible en este manual o en el sitio web ISECOM. STAR requiere la información siguiente: 1. Fecha y hora de la prueba 2. Duración de la prueba 3. Los nombres de los analistas responsables 4. Tipo de prueba 5. Alcance de la prueba 6. Índice (método de enumeración) 7. Canal probado 8. Vectores de Prueba 9. Superficie de Ataque sistema métrico 10. Que las pruebas se han completado, no se ha completado, o parcialmente completado, y en qué medida 11. Las cuestiones relativas a la prueba y la validez de los resultados 12. Todos los procesos que influyen en las limitaciones de seguridad 13. Las incógnitas o anomalías El éxito en el uso del OSSTMM muestra una medición real de la seguridad y los controles. Algunas tergiversaciones de los resultados de los informes pueden dar lugar a fraudes verificación de los controles de seguridad, y un nivel de seguridad inexacta. Para ello, el analista debe aceptar la responsabilidad y la responsabilidad limitada de información inexacta. Divulgación Durante una prueba de seguridad la llegada de desconocidas anteriormente o no publicidad limitaciones de seguridad puede salir a la luz. ¿Qué es un analista con estos es, ante todo, un resultado de las regulaciones legales del analista de la región y de la región en que se realiza el trabajo.
Divulgación derechos Lo que tienes que hacer es asegurarse de que el acceso y el uso del producto o la solución no requieren de ningún tipo de disposiciones, confidencialidad contrato, o Acuerdo de Licencia de Usuario Final (EULA) que le niega el derecho a reclamar, anunciar o distribuir cualquier
vulnerabilidad descubierta. Si lo hizo, y que usted o el cliente acepta este contrato, no se puede revelar a nadie, tal vez incluso del fabricante, sin posibles repercusiones legales. Además, si usted trabaja para la empresa de ese producto o son un cliente de ellos, a continuación, puede que no sea capaz de revelar nada legalmente. Por otra parte, de sus derechos en cualquier caso pueden ser impugnadas, de conformidad con el proceso de la ley en la región, en lugar de los precedentes legales.
Responsabilidades Sin embargo, si esos casos no aplicar y, a continuación te propio que la vulnerabilidad, y la tarde se hará público el más derechos que tienen como su propietario. En muchos países, los procesos y la información puede ser protegido por la ley y a menudo un proceso legal exige la publicación o legalmente presentar tal atribución. Si su divulgación puede hacer ningún daño físico (como gritar fuego en una concurrida sala de cine), es tuyo para hacer poses y no jurídicas deben agitar cuando usted está en lo correcto. Sin embargo, para que sea más seguro, también debe promover, con la vulnerabilidad de la que se ha informado, los controles que se pueden aplicar para solucionar el problema. Por ejemplo, si se trata de un problema de cómo se autentica con una solución, a continuación, sugerir una alternativa esquema de autenticación y cómo puede integrarse con éxito. No es necesario que espere a que el fabricante para liberar una solución o una retirada del mercado para dejar que la gente corrija el problema. No obstante, en el caso de que elija para trabajar en el contexto de la notificación del fabricante, usted tendrá que darles tiempo suficiente para abordar el problema antes de publicarlo. No es un argumento válido que la vulnerabilidad ya puede ser conocida en círculos criminales y requieren atención inmediata. Por lo tanto, deben elegir a publicar, sin la asistencia del fabricante, tenga en cuenta que incluso una solución también muestran que legalmente le tenía buenas intenciones y mucho del sistema jurídico se centra en las intenciones. Su elección depende de si se aceptan las demandas frívolas o frecuentes en su región. Recuerde que no es usted el analista que se requiere para realizar las pruebas de control de calidad para el fabricante por lo tanto, no les debemos toda la información del trabajo que ha hecho incluso si se incluye su producto. Toda la información es útil en la medida en que puede hacer ningún ser humano, daño físico. Por otra parte, los consumidores no deberían tener que esperar el fabricante fija para sus productos para estar seguro. Si el producto no se vende como una solución específica, a continuación, seguridad de los consumidores para que sea seguro, o no. Si se vende como seguro y sin riesgos, a continuación, corresponde al fabricante para que lo arregle sin embargo, el consumidor no podrá esperar hasta que el fabricante puede hacerlo. Toda la información de esta elección.
Pensamiento Crítico de seguridad Pensamiento Crítico de seguridad tal como se utiliza aquí es un término que se utiliza para la práctica del uso de la lógica y los hechos para formar una idea acerca de la seguridad. Esa idea puede ser una respuesta, una conclusión o una caracterización de algo o de alguien para que las pruebas de verificación se puedan definir bien. Como una respuesta o una conclusión crítica de seguridad, pensando que lo que tiene más sentido. Como caracterización, se mostrará lo que usted necesita para comprobar, de acuerdo con lo que usted necesita para comprobar, según lo que vector, cómo y cuáles son los objetivos. También le ayudará a respetar las diferentes opiniones y puntos más allá de la seguridad propia seguridad a la interconexión con las personas, los lugares, los procesos y el dinero. Esto le ayudará a abordar conclusiones contradictorias y explorar alternativas consecuencias. Por lo que, incluso si el pensamiento crítico de seguridad modelo no se puede dar una respuesta que le indicará qué hechos han desaparecido y de donde se necesita llegar a ellos. El proceso de pensamiento crítico de seguridad depende de la analista ha podido discernir afirmaciones verdaderas o por lo menos reconocer el grado de posible falsedad o propiedades dinámicas en un comunicado. Una forma de hacerlo es reconocer la cantidad de confianza que puede tener en un hecho mediante el uso de métricas. Otra forma es la de ser capaces de construir una declaración, separando argumentos falaces. En la práctica, un analista tendrá que hacer las dos cosas. El analista tendrá que tener un buen entendimiento de lo que se está analizando y una buena comprensión de falacias lógicas utilizadas para los calificadores, falaces afirmaciones basadas en conceptos por lo general en forma de axiomas o mejores prácticas. La técnica de análisis seis Paso Por desgracia, el mundo no es preceptivo. No cada pregunta tiene una respuesta correcta. La exactitud de la respuesta depende de muchas cosas entre ellas, lo que es más importante, la forma en que se le pide. Este es un problema que afecta a todas las industrias, pero ninguno tan obviamente como la seguridad que es la razón por pensamiento crítico de seguridad es tan importante. Como una técnica de análisis, puede ser reducido a 6 pasos simples para determinar resultados con un alto nivel de confianza de correcta incluso cuando las soluciones no son lineales como cuando no hay conexión del punto A al punto B. Por lo tanto, la capacidad de validar las fuentes y medir confianza es crucial para la adecuada, inteligencia de las pruebas. En estos pasos, "objetivo" se refiere a cualquier cosa que esté analizando en la preparación de un examen, ya sea personas, equipos, edificios, o de los procesos. 1. Construir su conocimiento del objetivo a partir de una variedad de los más contemporáneos, los recursos y evitar hechos comercialmente información sesgada y especulativa. 2. Determinar el nivel global de la experiencia en el tipo de destino y la cantidad de información posible sobre ella. 3. Determinar el sesgo o segundas intenciones en las fuentes de información.
4. Traduzca la terminología de fuentes de información similar o palabras conocidas de comparación porque lo que puede parecer nuevo o complicado puede ser simplemente un truco para distinguir algo en común. 5. Asegúrese de que el equipo de prueba se ha calibrado correctamente y el entorno de pruebas verificadas para asegurar los resultados no están contaminados por la prueba en sí misma. 6. Asegurarse de que la traducción de estado de herramientas o procesos de prueba ha sido eliminado, en la medida de lo posible, de manera que los resultados no vienen de las fuentes indirectas en el proceso o el análisis previo de algunas herramientas. Buscar coincidencias de patrón como un signo de errores Si usted comienza a buscar exactamente lo que usted busca, solamente puede encontrar lo que usted espera encontrar. Esto es adecuado para la búsqueda de calcetines pero no tan bueno cuando se mira en la imagen grande de la superficie de ataque. Es el problema más grave conocido como coincidencia de patrones, el rasgo humano para saltar por encima de los escalones, a veces sin saberlo, lo que se considera innecesario debido a la "evidente" resultados. También hace que la gente ver, causa y efecto en el que puede haber ninguno. Es un punto ciego que los analistas se producirán después de años haciendo inicial, básico o las tareas redundantes. Estas tareas se han hecho más eficientes a través de los accesos directos que afectan a la calidad de las pruebas de verificación y en última instancia el análisis. De información procesable, el resultado es tan bueno como los métodos utilizados para llegar a ellos. No saber cómo se obtuvo un resultado concreto se limitan en gran medida la acción que puede tomar para solucionar el problema. Cuando un analista utiliza coincidencia de patrón para saltarse los pasos, el método no puede ser bien conocido. Aun así, el deseo de "cut to the chase" para llegar a la carne de un problema al suponer un estado que se conoce es un problema en muchas áreas de la ciencia. Seguridad no es una excepción. Por tanto, el analista debe reconocer cuando las pruebas se han omitido datos o la dejamos para proporcionar resultados no verificados. Para detectar patrones, examinar los métodos de prueba y resultado, los datos de los siguientes: 1. Las pruebas de amenazas específicas en lugar de una profunda interacción con la superficie de ataque. 2. La falta de detalles en los procesos resultantes de las interacciones con el objetivo. 3. Poca o ninguna información acerca de los controles para diversos objetivos. 4. Sólo algunos de los objetivos se informa de ciertas pruebas y completamente los resultados negativos. 5. Los objetivos no se ha probado por razones que son anecdóticos (notas cuando una persona ha dicho no hay nada que probar o ha sido asegurado). 6. Pruebas de objetivos que obviamente no han sido asegurados.
Caracterizar los resultados El método científico no es una lista de comprobación. Se trata de un proceso que permite para la inteligencia y la imaginación. Una hipótesis es hecha y, a continuación, los datos se recopilan mediante la realización de ensayos y la observación para evaluar esa hipótesis. En una prueba de seguridad, una hipótesis es esencialmente siempre que la verificación se realiza contra una interactiva directa o indirecta en el ámbito de aplicación. El analista tiene los datos empíricos de las pruebas y debe considerar si los exámenes que se verifica la hipótesis. Las pruebas fueron el derecho? Fueron suficientes pruebas? Fueron los canales adecuados o vectores probados? Se han creado nuevas interacciones que también se sometió a prueba? Para ello, se caracterizan los resultados. Buscar signos de la intuición Una cosa es que las máquinas son mucho mejores que en los seres humanos es la coherencia. Los seres humanos generalmente se aburren, confusos o descuidado. Cuando una máquina de monedas, no perder la cuenta y la necesidad de empezar de nuevo. No cabe duda, y empezar de nuevo. También no utilizar la intuición. También llamado "instinto" el poder de la intuición es increíble. Que permite a las personas a imaginar, aplicar creatividad a un trabajo, y saber cuándo algo está mal. Es parte de la condición humana que subconscientemente detectar problemas y actuar en consecuencia. No obstante que es exactamente esto lo que a veces nos lleva a cometer errores. Esto nunca es más evidente que cuando contamos grandes cantidades de objetos parecidos. Sin la total concentración, podemos comenzar a sentir incómodos por el cómputo y finalmente nos pueden sentirse obligados a empezar de nuevo o simplemente aceptar un determinado número de sonido correcto donde pensamos que dejó y continuar desde allí. Signos de que hay problemas de intuición en las pruebas son: 1. Las incoherencias de los tipos de pruebas que se realizan a través de múltiples y objetivos similares. 2. El número de pruebas disminución entre los objetivos. 3. La duración del tiempo de pruebas disminución entre los objetivos. 4. El mismo destino probado más de una vez con las mismas pruebas. Información Transparente En raras ocasiones un análisis de seguridad final con todas las respuestas. Desde las pruebas dependerá del OpSec y de los controles de un determinado canal y vector se incógnitas. No puede ser un objetivo visible que no proporciona interacción y no hay más información sobre este destino puede ser determinado a partir de este vector y este canal. Esto es correcto. El analista debe informar de lo que se ha encontrado con certeza y no simplemente lo que podría ser. No hay lugar para adivinar cuándo medir la superficie de ataque.
Además de la información de la prueba en sí misma de cómo se hizo, el analista tendrá que informe los siguientes 7 resultados de la prueba: Desconocidos Como más vectores y los canales son analizados, se dispondrá de más información y que, según se informó que va a cambiar y proporcionar información procesable. Por otra parte, y quizá más resultados no son concluyentes o la correlación de resultados proporciona respuestas contradictorias, la inteligencia es desconocida. Desconocido es una respuesta válida para informe. Lo que no se puede conocer es tan válida y tan importante en la seguridad como lo que se descubre. Muestra lo que se desconoce lo que es difícil de probar o analizar. El desconocido no debe verse como un fracaso de la prueba sino que puede ser causada por una mayor protección o un ataque que utiliza un gran coste de tiempo o de recursos no es posible en una prueba. Analista no debe temer los informes algo es desconocido. Se trata de una potente base de análisis de riesgo. Objetivos no probados Además, el analista debe informar sobre otro tipo de desconocidos: los objetivos en el ámbito de aplicación, que no han sido probadas en un vector particular o canal. Si una prueba no se puede completar debido a las limitaciones de tiempo, las limitaciones, las metas es inestable, el entorno de prueba es demasiado dinámica o demasiado ruidosa para recoger resultados adecuados, o porque las pruebas no fueron buscados por el propietario, este objetivo debe conocer. Por lo que no se ha probado, es posible realizar comparaciones con adecuados de prueba pruebas futuras. También ayudará a evitar engaños por sólo probar el bien protegido de un alcance y desconociendo el resto para crear la ilusión de una pequeña superficie de ataque. Identificado y verificado Las Limitaciones Además, el analista debe también informar de cualquier identificado y verificado las limitaciones como las vulnerabilidades de los objetivos. Una limitación es uno que se ha determinado a través del conocimiento y la correlación. Esto es útil cuando las pruebas son peligrosas o muy costoso. Algunas veces, un examen puede ser perjudicial para un destino o causa penal inaceptable o incluso daños colaterales. Una limitación es donde el problema se ha sometido a pruebas específicas para determinar si existe. Falsos positivos y los medios para generar Durante las pruebas, algunas limitaciones que se han identificado no serán vulnerables a los ataques durante la verificación. Esto, sin embargo no concluye que el objetivo no tiene esas limitaciones. Sólo quiere decir que prueba en particular en ese momento en particular y a partir de ese particular probador no exponer la vulnerabilidad identificada. También podría significar el objetivo es vulnerable pero está protegido por un determinado control. Esos determinados falsos positivos deben ser reportados por lo que, en un mayor desarrollo de las técnicas de protección y defensa, el problema puede ser visto más estrechamente, en particular de otro vector.
No los procesos de seguridad y procedimientos Durante el análisis, los resultados de la prueba se muestran más que la OPSEC, tipos de controles, y el número de limitaciones. Se mostrará una imagen mayor, uno de los procesos y procedimientos que se utilizan para formalizar las medidas de protección. Estos pueden ser sobre cualquier cosa que se han diseñado para obtener las medidas de protección a su estado actual. Esto incluye, pero no se limita a mantenimiento, adquisiciones, identificación, autorización, orden y limpieza, recuperación de desastres, las relaciones con los asociados, la política de generación, control de clima y recursos humanos. Cuando un objeto tiene una limitación a veces es un proceso que ha fallado o procedimiento. El analista debe ser capaz de determinar exactamente lo que es la suma de los resultados de la prueba. Buenas prácticas El término "Mejores Prácticas" se utiliza para explicar la mejor forma para que una persona o una organización para hacer algo. Por desgracia, esto ha sido objeto de abuso por lo que en la actualidad significa que es mejor para todos. Este mismo ha causado problemas y la pérdida de recursos. Una forma de contrarrestar este problema es utilizar el total de los resultados de las pruebas muestran que las prácticas se realizan con éxito. Esto mostrará lo que se puede repetir el éxito de equivalente en otras áreas de la organización y la definición de "Mejores Prácticas" para ellos. También disminuir su dependencia en mejores prácticas en favor de lo que funciona mejor para ellos. Cumplimiento Objetivos de cumplimiento específica hay que llegar, el analista debe utilizar la correlación entre los resultados de la prueba para determinar si se han cumplido dichos objetivos. Este puede que sea necesario proporcionar en un formato especial que determine el auditor sin embargo el Analista está mejor equipado para mostrar que los resultados de las pruebas proporcionan la información necesaria. Estadísticas de Seguridad Operacional La realización de una exhaustiva prueba de seguridad tiene la ventaja de proporcionar indicadores precisos sobre el estado de la seguridad. Al igual que con el uso de cualquier sistema métrico; Por lo tanto, una seguridad de éxito métrica requiere una prueba que puede ser descrito como medición de la correspondiente contabilidad mientras que los vectores de las inexactitudes y tergiversaciones de la recogida de datos, así como de las competencias o la experiencia de los profesionales de la seguridad de la prueba. Los fallos de estas exigencias son resultado de las mediciones de la calidad inferior y por lo tanto falsa seguridad las determinaciones la métrica debe también ser lo suficientemente simple para utilizar sin que esto sea tan simple que dice nada. Conocer el RAV El rav es una escala de medición de la superficie de ataque, la cantidad de interacciones no controlados con un objetivo, que es calculado por el equilibrio cuantitativo entre las operaciones, limitaciones y controles.
El RAV no medir el riesgo de un ataque, sino que permite la medición de la misma. No puede decir si un objetivo concreto será atacado sin embargo se puede decir que en una meta que será atacado, ¿qué tipo de ataques el objetivo puede defender exitosamente contra, cómo un atacante puede obtener y cuánto daño se puede hacer. Con esa información a continuación, es posible evaluar la confianza (y los riesgos) mucho más precisa. Ocho respuestas fundamentales en materia de seguridad El rav no representa riesgo cuando el riesgo es conocido como Riesgo = Amenaza x vulnerabilidad x activo. En esta ecuación, el riesgo es el resultado de un conocimiento muy parcial, sin embargo, la ecuación. Si podemos eliminar la mayor parte de la parcialidad de conocer el nivel de protección y por lo tanto el nivel de consecuencias de la vulnerabilidad, podemos reducir el sesgo en la ecuación y darle una mejor evaluación del riesgo. Por lo tanto, el rav es, en realidad, el fundamento fáctico para una evaluación del riesgo de un analista ha hechos con los que se va a trabajar. El verdadero poder del rav sin embargo es la manera en que puede proporcionar respuestas a las siguientes preguntas fundamentales de seguridad ocho con gran precisión. ¿Cuánto dinero se debe invertir en seguridad? El rav se mostrará la cantidad actual de la protección de seguridad y definir los hitos las proyecciones incluso antes de comprar una solución particular o aplicar algunas nuevo proceso. Según las proyecciones e hitos, las restricciones financieras se pueden crear para alcanzar las metas y obtener resultados más concretos de la inversión. Sabiendo exactamente lo que se controla en base a los gastos corrientes, también se puede ver lo que no se controla para obtener ese dinero. "Más" y, a continuación, se transforma en la que se echa en falta. A continuación, es posible predecir el coste de llenado en los controles que faltan para alcanzar un equilibrio perfecto o por lo menos un nivel aceptable de cobertura. Lo que se debe proteger en primer lugar? El rav puede ser usado para ver como parte de la gran imagen y como una lente macro en una parte en concreto de un objetivo, o cualquier combinación de los mismos. Tras el análisis, el rav le mostrará que determinada parte del ámbito de aplicación tiene la mayor porosidad y los más débiles. Comparación de éstos con las necesidades de uno y de los activos por valor, con una proporción de intensidad de protección se puede generar valor para decidir exactamente dónde comenzar. Las soluciones de protección lo que necesitamos y cómo debemos configurar para obtener la máxima eficacia? UN completo rav mostrará los 10 posibles controles operacionales aplicables a cada destino y las limitaciones de dichos controles. A continuación, puede seleccionar las soluciones basadas en qué
tipos de controles a los que desee poner en marcha. La diferencia ahora es que ya no se tiene que buscar una solución en términos de lo que es, más que a la protección o controles que puede ofrecer. Esto le permite ver los productos a los controles que debe realizar en las áreas donde los controles son actualmente deficientes. La mejora es adquirida por compras específicas de seguridad y procesos? Una característica clave del rav es que puede hacer un "Delta" mediante la asignación de los beneficios y las limitaciones de una solución particular para comparación antes de la compra. Esto significa que usted puede ver los cambios que la solución al alcance de comparar con otras soluciones. Combinando el mapa a un rav del alcance de la solución, la cantidad de mejoras se puede medir incluso antes de la compra. Incluso puede predecir el valor de esa protección, dividiendo el precio de la solución de la rav delta. ¿Cómo podemos medir la seguridad periódicas esfuerzos y mejoras? Con auditorías periódicas, el rav se puede volver a calcular y se compara con el valor anterior. Por lo tanto el costo de las nuevas soluciones y procesos se puede justificar con regularidad, así como el costo de mantener el nivel de seguridad actual. ¿Cómo sabemos si estamos reduciendo nuestra exposición a nuestras amenazas? Con conocimientos específicos de los controles, puede saber fácilmente qué parte o vector de su alcance es débil a la mayoría de las amenazas desconocidas. Rav en terminología, un desconocido amenaza es sólo uno que puede aparecer cuando existen interacciones pero los controles no. Por lo tanto, un mapa se puede distinguir entre las amenazas determinadas por los evaluadores de riesgos y los controles que se llevan a cabo. Métricas regulares exámenes mostrará cualquier cambio en este mapa y se puede hacer tan regularmente. A continuación, es posible medir el costo cada una de esas amenazas en seguridad con los gastos en los controles. ¿El rav puede decirnos cómo algo se resiste a los ataques? Técnicamente, sí. Cuanto más se pueden lograr un equilibrio entre los controles con las interacciones, los más pequeños la superficie de ataque y mayor será la capacidad del objetivo de conocidos y desconocidos de tipos de interacciones. ¿Puede el rav ayudarme con el cumplimiento de normativas? Nada de lo que le ayuda a clasificar todos los controles y puntos de acceso en un ámbito le ayudará a las auditorías de cumplimiento. El rav le ayuda a hacer un buen trabajo a la hora de conseguir su seguridad bajo control que incluso puede encontrar las principales deficiencias normativas. Si bien no existe un derecho particular, el cumplimiento ahora que le pide que le
tengan un especial rav puntuación abierto OSSTMM (OPEN SOURCE SECURITY Testing Methodology, mostrando la estrella con su rav puntuación le ayudará a cumplir con diversos requisitos de cumplimiento para una auditoría de terceros y la documentación. Seguridad operacional La medición de la superficie de ataque requiere la cuantificación de los accesos, visibilidad y confianza. Para llevar a cabo esta tarea deben seguirse los puntos que se indican a continuación. Visibilidad Contar el número de objetivos dentro del alcance. Por ejemplo si en una organización hay 100 empleados pero sólo 40 interactúan dentro de un canal específico, entonces se tiene una visibilidad de 40. Por cada canal se hacen diferentes auditorías para determinar la visibilidad. Accesos Contar todos los puntos de acceso por cada lugar de interacción. En el caso del canal físico, si dentro de un edificio hay 3 puertas y 5 ventanas, se obtiene un acceso de 8. En el caso que se encuentren selladas, el acceso es 0. En el caso de las redes de datos, si hay una ip activa dentro de la red y para esa ip hay 2 puertos abiertos, se cuenta un acceso equivalente a 3 (1 ip activa + 2 puertos abiertos). Es más sencillo de analizar cuando se trata del canal humano: si la persona responde a cualquier pregunta cuenta como un acceso, si no responde no cuenta como acceso. Confianza Contar cada punto de confianza por cada lugar de interacción. Por ejemplo, en el canal de las redes de datos, cada redirección de puertos cuenta como 1 punto de confianza. En el canal humano, cada persona que actúa como intermediario se cuenta como 1. Controles En el próximo paso se deben contar los controles, los mecanismos de protección. Autenticación Contar cada instancia de autenticación requerida para obtener acceso. Por ejemplo, en una auditoría de seguridad física en donde se solicita una tarjeta de Identificación y la huella dactilar, se suma 2 a los controles de autenticación. Indemnización Contar todas las instancias de métodos utilizados para la compensación por pérdidas referidas a los activos. Por ejemplo, un seguro que cubre el robo de 30 equipos de computación cuenta como 30.
Resistencia Contar cada instancia de acceso o confianza donde una falla en el sistema de seguridad no provea un nuevo acceso. Suponiendo que existe un webservice que solicita credenciales y la valido contra una base de datos, en el caso que este servicio pierda la conexión con la base, entonces no debería validar ninguna credencial hasta la restauración de la conexión. En caso de rechazar las credenciales, cuenta como 1 el valor de resistencia (este sería el caso ideal). Existe la posibilidad de que el servicio no esté correctamente diseñado y cuando pierde la conexión comience a validar todas las credenciales, inclusive las que no son correctas; en ese caso la resistencia es 0. Subyugación Contar todos los puntos de acceso o confianza donde la interacción deba cumplir condiciones preestablecidas. Por ejemplo el uso de PKI para las comunicaciones entre un cliente y un servidor cuenta como 1 ya que la comunicación sólo puede establecerse si cumplen esa condición. Continuidad Contar todos los puntos de acceso o confianza donde una falla no cause una interrupción en la interacción. Dentro de los ejemplos para este punto se encuentran la redundancia y el balanceo de carga. En seguridad física, si una puerta se bloquea y no existe una entrada alternativa para los clientes entonces tiene continuidad 0 para ese vector. No repudio Contar cada acceso o confianza que provea algún mecanismo de no repudio, tal que exista alguna forma de determinar que la interacción se produjo en un tiempo determinado entre las partes identificadas. Dentro del canal de las redes de datos, los archivos de logs brindan mecanismos para el no repudio. Confidencialidad Contar cada instancia de acceso o confianza que provea mecanismos para evitar revelar información a terceros no autorizados. Un ejemplo claro de confidencialidad es el cifrado de la información. Privacidad Contar cada acceso o confianza donde el método de interacción sea ocultado. Esto no quiere decir que la información viaje codificada sino que no se sepa que hay comunicación o que ésta sea ofuscada de alguna manera. En seguridad física, un cuarto cerrado donde se efectúe la comunicación entre personas provee privacidad.
Integridad Contar cada acceso o confianza donde la interacción brinde algún mecanismo que permita conocer si la información fue modificada por terceros no autorizados. En el canal de las redes de datos, una función de hash puede usarse para proveer integridad. Alarma Contar cada acceso o confianza que genere un registro o notificación cuando exista algún evento no autorizado o erróneo. En las redes de datos, los archivos de logs cuentan como alarma aunque estos no generen una notificación inmediata. También se debe sumar un punto por cada equipo monitoreado por un sistema de detección de intrusiones o antivirus. Limitaciones Finalmente las limitaciones, que son las fallas que presentan los controles para mantener la separación entre los activos y las amenazas. Vulnerabilidad Contar cada falla o error que pueda llevar a un acceso no autorizado o denegar un acceso legítimo. Un ejemplo referido al canal de las redes de datos puede ser un proceso que permite la sobreescritura de áreas de memoria que lleven a la ejecución de código malicioso. Debilidad Contar todas las fallas o errores en los controles de interacción: autenticación, indemnización, resistencia, subyugación y continuidad. Un ejemplo de debilidad en el canal de las redes de datos puede ser una pantalla que solicita credenciales de acceso que no posea límites en cuanto a la cantidad de intentos. Preocupación Contar todas las fallas en los controles de proceso: no repudio, confidencialidad, privacidad, integridad y alarma. Un ejemplo de preocupación es un proceso que genere archivos de log con los datos de los participantes involucrados pero no almacene correctamente la fecha y hora de la transacción. Exposición Contar cada acción no justificada, falla o error que provean visibilidad de los objetivos o activos, ya sea de forma directa o indirecta. Un claro ejemplo de exposición son los banners que brindan información de la aplicación que está corriendo detrás de un puerto específico. Anomalía Contar cada elemento desconocido que no puede clasificarse dentro de las operaciones normales, ya que esto puede ser un síntoma para problemas de seguridad futuros.
Fórmulas para la seguridad real Dentro de OSSTMM, los RAVs (Risk Assessment Values) representan la percepción de la seguridad de forma similar a un valor porcentual. Donde un rav de 100 representa el balance perfecto entre las operaciones, controles y limitaciones. Los ravs derivan de tres categorías definidas dentro del objetivo: seguridad operacional, controles y limitaciones. En primera instancia se debe asociar la información obtenida en los pasos anteriores a la categoría apropiada. Luego de haber obtenido los valores que corresponden a cada categoría, OSSTMM define una serie de fórmulas que determinan un hash que lleva el nombre de "Seguridad real". ISECOM ha optado por representar este valor de tal forma que se logre un número consistente con la percepción respecto al estado de seguridad de un sistema, donde un valor de 100 ravs representa el balance perfecto entre los distintos elementos, más de 100 significa que hay controles excesivos y un valor menor a 100 indica que faltan controles. Esto no es un valor porcentual, pero debido a que resulta cómodo trabajar con porcentajes, se seleccionó el valor de 100 como el balance perfecto y el resto de las combinaciones se distribuyen según una curva logarítmica que representa de forma aproximada y consistente la percepción de seguridad definida en todos los estándares de seguridad.
Categoría Operaciones
Clase A Controles
Clase B
Seguridad Operacional Visibilidad Acceso Confianza Autenticación Indemnización Resistencia Subyugación Continuidad No repudio Confidencialidad Privacidad Integridad Alarma
Limitaciones Exposición Vulnerabilidad
Debilidad
Preocupación
Anomalía
Este valor puede utilizarse para comparar los resultados que derivan de diversas entradas y de esa forma permite analizar la evolución lograda luego de la aplicación de diferentes mecanismos de control. A continuación se detallan los valores auxiliares que se utilizarán para llegar al resultado final. Porosidad La seguridad operacional, también conocida como porosidad, es el primero de los tres factores de la seguridad real que debe ser determinado. Inicialmente se determina como la suma de la visibilidad (Pv), accesos (Pa) y confianza (Pt). OpSeCsum = Pv + Pa + Pt Para calcular el rav es necesario determinar el valor base de la seguridad operacional, OpSeCbase, que está dado por la ecuación: OpSeCbase = log2(1 + 100 * OpSeesum) En el caso que la sumatoria de Opsecsim sea 0, es decir, que no existen interacciones, la fórmula es equivalente a log2(1) cuyo resultado es 0. Cuando se da esta condición el resultado final del rav será 100, que se traduce a: Seguridad Perfecta. Controles El próximo paso para el cálculo es determinar la suma de los controles (LCsum). • Autenticación (LCAU) • Indemnización (LCW) • Resistencia (LC^) • Subyugación (LCsu) • Continuidad (LCCt) • No repudio (LCNR) • Confidencialidad (LCCf) • Privacidad (LCPr) • Integridad (LC) • Alarma (LCAI) LCsum = LCAU + LCid + LCue + LCsu + LCct + LCNR + LCcf + LCpr + LC¡t + LCAI Controles faltantes Por cada categoría se debe calcular el valor de los controles faltantes. Se debe tener en cuenta que este valor nunca puede ser menor a 0. Entonces el algoritmo para cada categoría es el siguiente:
SI OpSeCsum - LCX < 0 ENTONCES MCX = 0 SINO MCx = OpSeCsum - LCX Luego se suman los controles faltantes de todas las categorías para obtener el valor de MCsum. MCMM = MCAU + MCu + MCR + MCSU + MCQ + MCNR + MCQ + MCPR + MCIT + MCAI Controles reales Los controles reales (TCmm) son la inversa de los controles faltantes. Donde cada uno de los elementos se calcula como: TCX = OpSecSum - MCX Por lo tanto la suma de los controles reales para los diez tipos de controles queda de la siguiente manera: TCSum = TCAU + TCid + TCRB + TCSU + TCct + TCNR + TCcf + TCpr + TCI, + TCA; El valor obtenido sirve para medir la ubicación ideal de los controles. El valor base ayuda a eliminar la influencia de ubicaciones desproporcionadas dentro de los controles. El valor base (TCbase) se calcula como se muestra a continuación: TCbase = log2(1 + 100 * (OpSecsum - MCsum * 0.1)) Porcentaje real de cobertura Como se ha visto en los capítulos anteriores, por cada punto de interacción existen diez controles posibles; por lo tanto, si la cantidad de controles es cero, el porcentaje real de cobertura será 0%, y si la cantidad de controles es igual a OpSecsum * 10 (contando sólo una vez los controles del mismo tipo), entonces el valor real de cobertura es 100%. Este valor se puede obtener mediante la siguiente fórmula: (100 * (1 - MCsum/ (10 * OpSecsum))) Este dato es muy importante ya que determina que es lo que se debe corregir, es decir, los puntos que no cuentan con los controles necesarios. Controles completos Este valor tiene en cuenta los controles qué se aplican a la misma instancia de visibilidad, acceso o confianza. Sirve, por ejemplo, para medir el valor de la defensa en profundidad. FCbase = lOg2(1 + 10 * LCsum) Por ejemplo si se aplican cinco controles de autenticación a una instancia de acceso, esto podría derivar en un rav mayor a 100.
Limitaciones Las limitaciones se miden individualmente y están directamente relacionadas con la porosidad y los controles. En el caso de una exposición o anomalía también se deben tener en cuenta otras limitaciones relacionadas. Las exposiciones o anomalías no generan inconvenientes por sí mismas, a menos que estén relacionadas con alguna otra limitación. Por ejemplo, cuando una exposición no conduce a nada que sea explotable, no afecta a la seguridad; y por lo tanto no se tiene en cuenta en el cálculo del rav. Los valores de la tabla que se muestra a continuación se utilizan para el cálculo de las limitaciones, donde la primer columna contiene las entradas, la segunda el peso que corresponde a cada una de ellas y la tercera, las variables utilizadas.
Entrada Vulnerabilidad LV Debilidad LW Preocupación LC Exposición LE
(OpSeCsum + MCsum) / OpSeCsum
Variables MCsum: Suma de controles faltantes
(OpSeCsum + MCA) / OpSeCsum
MCA: Suma de controles faltantes de clase A
(OpSeCsum + MCB) / OpSeCsum
MCB: Suma de controles faltantes de clase B
((PA + PV) * MCvg + LV + LW + LC) /
PV: Suma de visibilidad PA: Suma de accesos MCvg: Porcentaje de cobertura faltante = (M C sum * 0.1 / OpSec um) PT: Suma de confianza
OpSeC
sum
S
Anomalía LA
(PT * MC g + LV + LW + LC) / V
OpSeC
sum
Teniendo las variables de entrada y la ponderación correspondiente se puede obtener la fórmula que determina las limitaciones mediante la suma de sus productos. SecLinisum = (LV * (OpSecsum + MCsum) / OpSecsum) + (LW * (OpSecsum + MCA) / OpSecsum) + (LC * (OpSecsum + MCB) / OpSecsum) + (LE * ((PA + PB) * MCvg + LV + LW + LC) / OpSecsum) + (LA * (PT * MCvg + LV + LW + LC) / OpSecsum) Por último, el valor base está dado por el siguiente cálculo: SecLimbase = log2(1 + 100 * Sec Lim sum)
Seguridad real Esta es la parte final en la cual se utilizarán los cálculos definidos previamente para obtener el valor de la seguridad real. Antes de pasar al cálculo final, se utilizará un valor auxiliar (valor delta) que representa el cambio que una solución de seguridad genera en el alcance. El valor delta se calcula mediante la siguiente fórmula: ActSecA = FCbase - OpSecbase – Sec Lim base El cálculo final determinará el estado actual de las operaciones con los controles aplicados y las limitaciones descubiertas. Como se mencionó anteriormente, el valor que se obtiene no es un porcentaje aunque un rav de 100 determina el balance óptimo en la seguridad. El resultado del rav se calcula según la fórmula que se muestra a continuación: ActSec = 100 + ActSecA - 0.01 * (OpSecbase * FCbase - OpSecbase * SecLimbase + FCbase * SecLimbase) Si se analizan diferentes entradas de datos utilizando la planilla de cálculo de ravs, se puede observar que, a medida que aumenta el valor de la porosidad, disminuye el valor del rav, es decir, la percepción de seguridad disminuye. Cuando se agregan controles, el valor de la seguridad real sube nuevamente, indicando que la percepción de seguridad ha aumentado. Por otra parte, cuando se consideran las limitaciones de los controles, el resultado del rav vuelve a disminuir porque también disminuye la percepción de seguridad. Análisis de confianza En seguridad operacional, Confianza es simplemente un colaborador con la porosidad, sólo otra interacción de controlar. A diferencia del Acceso (la otra forma de interacción), en la forma en que se relaciona con otros objetivos en el ámbito de aplicación. Por lo que el acceso es la interacción entre los dos lados de un vector dentro y fuera del alcance, la confianza se mide como la interacción entre los objetivos en el ámbito. Sin embargo, la mayoría de las personas no se utilice tan concreta. Confianza por lo general se aplica a una persona específica o un elemento y un acto concreto, tales como: " ¿Puedo confiar en este empleado para entregar antes de la fecha límite?" o " ¿Puedo confiar en este equipo? ". No hay respuestas correctas a estas preguntas pero la gente a menudo carecen de las habilidades necesarias para cuantificar el nivel de confianza para que la persona o el objeto que nos permitiera hacer una más racional y lógica decisión. Sin embargo, cuantificar confianza, tenemos que saber lo que es.
Comprendiendo la confianza Como parte de OPSEC, la confianza es una parte de la porosidad. Donde la seguridad es como una pared que separa las amenazas de los activos, la confianza es un agujero en la pared. Es allí donde el destino acepta interacción de otros objetivos en el ámbito. Sin embargo, las personas tienden a utilizar inadecuado o incompleto con sus controles operativos como autenticación confía en que se ha llevado a cabo con identificación inadecuada como una voz a través de un teléfono, una tarjeta de visita, o, incluso, el supuesto de que porque una persona es en la sala que se está autorizado a estar allí. Esto abre las personas de fraude y el engaño. El uso de controles adicionales son requeridos para asegurar una confianza, para asegurar su integridad y resiliencia. La confianza propiedades cuantificables, son los elementos objetivos que se utilizan para crear confianza. Podemos decir estas propiedades son lo que podríamos decir que nos "motivos para confiar". Estas propiedades se van a convertir en referencia las reglas basadas en el objetivo y la situación que estamos verificando. Por desgracia, muchos ilógico las propiedades de confianza existen y están demasiado a menudo en el uso que hace que sea más difícil para nosotros para hacer las decisiones de confianza adecuado sin que siente mal. Sin embargo, es exactamente la sensación que nos hace más propensos a errores. Durante la investigación, muchos de los potenciales las propiedades de confianza fueron descubiertos que son de uso común e incluso oficiales, las regulaciones gubernamentales y del sector recomiendan, sin embargo no pruebas lógicas y fueron descartados de nuestro conjunto de propiedades dejando sólo diez. Falacias en la confianza Propiedades de la confianza 1 Tamaño
2
Simetría
3
Transparencia
4
Subyugación
5 6
Consistencia Integridad
7
Compensación
Descripción El número de fiar. ¿Debe la confianza extenderse a sólo uno o para muchos? ¿Es que el grupo sea una confianza que está destinado a tomar la decisión colectiva? El vector (dirección) de la confianza. La confianza puede ser una forma (asimétrica) y se define como de qué manera la confianza debe viajar o en ambos sentidos (simétrica). Una persona que también debe confiar en usted tiene que considerar el movimiento alternativo de romper la confianza. El nivel de transparencia de todas las partes y procesos de la diana y su entorno operacional. También se llama control, la cantidad de influencia sobre el alcance por el operador. La evidencia histórica de compromiso o la corrupción del objetivo. La cantidad y la notificación oportuna de cualquier cambio dentro del objetivo Las compensaciones de garantías suficientes son una compensación por el dador de fideicomiso o castigo por el interruptor confianza. Es un valor que se da en la confianza con el objetivo.
8
Valor
9
Componentes
10
Porosidad
El desplazamiento de riesgo financiero, la cantidad de ganar o ganar para que el riesgo de poner la confianza en el destino sea suficiente para compensar el riesgo de fracaso en el fideicomiso. El número de otros elementos que actualmente proporcionan recursos para el objetivo, ya sea a través de interacciones directas o indirectas, de forma similar a la Intervención del Proceso de cuatro puntos La cantidad de separación entre el objetivo y el medio ambiente externo.
Flujo de Trabajo El flujo OSSTMM comienza con una revisión de la postura del objetivo. La postura es la cultura, las reglas, las normas, los contratos, la legislación y las políticas que definen el destino. Termina con las comparaciones de resultados a cualquier alarma, alertas, informes o registros de acceso. Este es un concepto de círculo completo en el que el primer paso es ser consciente de los requisitos operacionales para interactuar con el objetivo, y el último paso es la revisión de los registros de la pista de auditoría. Para el analista, esto es simplemente: usted sabe lo que tiene que hacer, lo haces, y después de comprobar lo que has hecho. Esta metodología separa lo que hay que hacer en este formato jerárquico: 1. CANAL 2. MÓDULO 3. TAREA Algunas tareas no producen ninguna salida, lo que significa que existirán módulos para los que no hay entrada. Los módulos que no tienen entrada pueden ser ignorados durante la prueba, pero deben ser más tarde documentados con una explicación por no haber sido realizado. Además, las tareas que no tienen salida no indican necesariamente 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: 1. El canal fue obstruido de alguna manera durante el desempeño de las tareas. 2. Las tareas no se realizaron correctamente. 3. Las tareas no eran aplicables. 4. Los datos resultantes tarea se ha analizado de manera incorrecta. 5. La tarea revela una seguridad superior. Una Metodología Poner todos los módulos entre sí proporciona una metodología para conocer y trabajar con ellos. Esta es una metodología que es aplicable a cualquier y todos los tipos de pruebas de seguridad. Ya
sea que el objetivo sea un sistema en particular, un lugar, una persona, un proceso, o miles de ellos, ésta metodología asegurará la prueba más completa y eficiente posible.
Figura 3. Diagrama de Flujo OSSTMM
GUÍA DE PRUEBAS OWASP 4.0 En el desarrollo del presente trabajo, se hace un análisis general del proyecto de pruebas de OWASP, el cual viene siendo desarrollado desde hace muchos años y cuyo objetivo es el ayudar a las personas a entender el qué, por qué, cuándo, dónde, y cómo probar aplicaciones web. Este proyecto proporciona un marco de pruebas completo, no simplemente una lista de verificación o la prescripción de las preguntas que se deben abordar. Se puede utilizar este documento como una plantilla para crear sus propios programas de pruebas o para calificar los procesos de otras personas. La guía de pruebas se describe en detalle tanto el marco de pruebas generales y las técnicas necesarias para aplicar en la práctica.
¿Qué es la Prueba? Durante el ciclo de vida de desarrollo de una aplicación web muchas cosas necesitan ser probados, pero ¿qué significa realmente la prueba? El diccionario Merriam-Webster describe pruebas como:
Para poner a prueba o prueba. Para someterse a una prueba. Para asignar un estado o evaluación basada en pruebas.
Para el caso de esta guía, es un proceso de comparación del estado de un sistema o aplicación contra un conjunto de criterios.
¿Cuándo se valida? En la mayoría de ocasiones hoy en día no se 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 se ha creado y crea una instancia en una aplicación web de trabajo). Esto es generalmente es una práctica muy ineficaz y un costo prohibitivo. Uno de los mejores métodos para prevenir los errores de seguridad que aparezcan en aplicaciones de producción, es la de mejorar el desarrollo del Ciclo de Vida del Software (SDLC) mediante la inclusión de la seguridad en cada una de sus fases. Un SDLC es una estructura impuesta sobre el desarrollo de artefactos software.
Figura 4 Modelo Genérico SDLC ¿Lo que hay que probar? 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" el software, entonces es lógico que estos sean los factores que deben ser probadas. Un programa de pruebas efectivo debería tener componentes que ponen a prueba: Gente: para asegurar que hay educación y sensibilización adecuada; Proceso: para asegurar que existen políticas y normas adecuadas y que la gente sepa cómo seguir estas políticas; Tecnología: para asegurar que el proceso ha sido eficaz en su aplicación.
Comprender el alcance de la seguridad Es importante saber cuánta seguridad requerirá un proyecto determinado. La información y los activos que van a ser protegidos deben recibir una clasificación que establece la forma en que se deben manejar (por ejemplo, confidencial, secreto, alto secreto). Las discusiones deben ocurrir con consejo legal para asegurar que se cumplan todos los requisitos de seguridad específicos.
Guía de pruebas de OWASP 4.0 Open Web Application Security Project, está liderando desde 2001 un proyecto libre sin ánimo de lucro orientado a promover la seguridad del software en general y de aplicaciones web en particular, para ello trabaja en varios proyectos e iniciativas. Bajo licencia Creative Commons, genera y distribuye material relacionado con el desarrollo y seguridad del software, entre ellos guías, plataformas educativas y herramientas de auditoría, etc.
Dentro de los proyectos relacionados con el sector de la seguridad se destacan las guías publicadas por la fundación OWASP, las cuales se han convertido en un referente de la seguridad del desarrollo y evaluación de aplicaciones a nivel mundial. La versión 4 de OWASP Testing Guide se ha consolidado como un material indispensable para profesionales del desarrollo y pruebas de software, así como para especialistas en seguridad de la información. En la guía se presenta una metodología que recorre de forma organizada y sistemática todas las posibles áreas que supongan vectores de ataque a una aplicación web. De esta forma, siguiendo una lista de pruebas perfectamente organizada, se puede auditar de forma eficaz la seguridad de un desarrollo web.
El Framework de pruebas OWASP En esta sección se describe un marco de pruebas que se puede desarrollar dentro de una organización. Puede verse como un marco de referencia que comprende las técnicas y tareas que sean apropiados en diversas fases del ciclo de vida de desarrollo de software (SDLC); este no debe ser visto como una disposición, sino como un enfoque flexible que se puede ampliar y moldear para adaptarse proceso de desarrollo de una organización. Actualmente existen muchas metodologías de desarrollo como el Rational Unified Process, eXtreme and Agile development, y las metodologías tradicionales de cascada. Este marco de pruebas consta de las siguientes actividades que deben llevarse a cabo:
Antes de que comience el desarrollo Durante definición y diseño Durante el desarrollo Durante el despliegue Mantenimiento y operaciones
Fase 1: Antes de que comience el Desarrollo
Definir una SDLC: antes del desarrollo de aplicaciones se inicia un SDLC adecuado, y se debe definir cuando la seguridad es inherente en cada etapa.
Revisar las políticas y normas: Asegúrese de que las condiciones, estándares y documentación sean las adecuadas y que estén en su lugar.
Desarrollar Criterios de Medición y Métricas y asegurar la trazabilidad: Es esencial definir las métricas antes de que comience el desarrollo, ya que puede haber una necesidad de modificar el proceso con el fin de capturar los datos.
Fase 2: Durante el diseño y definición
Revisión de Requisitos de Seguridad: Definen cómo funciona una aplicación desde una perspectiva de seguridad. Es esencial que los requisitos de seguridad se prueben.
Revisión de Diseño y Arquitectura: Las aplicaciones deben tener un diseño y arquitectura documentado. Esta documentación puede incluir modelos, documentos textuales y otros artefactos similares. Es esencial para probar estos artefactos para asegurar que el diseño y la arquitectura cumplir el nivel apropiado de seguridad como se define en los requisitos.
Crear y verificar los modelos UML
Crear y revisar los modelos de amenazas
Fase 3: Durante el Desarrollo Teóricamente, el desarrollo es la implementación de un diseño. Sin embargo, en el mundo real, muchas decisiones de diseño se realizan durante el desarrollo del código. Si el diseño y la arquitectura no eran adecuadas, el desarrollador se enfrentará a muchas fallas. Si hubiera políticas y normas insuficientes, el desarrollador se enfrentará con más fallas aun.
Código Walk Through: El equipo de seguridad debe realizar una verificación de código con los desarrolladores, y en algunos casos, con los arquitectos de sistemas. El objetivo no es realizar una revisión de código, pero es necesario para entender en un nivel el diseño y la estructura del código.
Codificación de las revisiones
Armado con una buena comprensión de cómo el código está estructurado y por qué ciertas cosas fueron codificadas como estaban, el probador puede examinar el código real para identificar defectos de seguridad.
Fase 4: durante la implementación
Aplicación de Pruebas de Penetración: Después de haber probado los requisitos, analizado el diseño, y se llevada a cabo la revisión de código, se podría suponer que todas las dudas han sido resueltas.
Pruebas de gestión de configuración: La prueba de penetración debe incluir la comprobación de cómo se ha desarrollado y asegurado la infraestructura. Si bien la aplicación puede ser segura, un pequeño aspecto de configuración podría estar en una instalación por defecto, un escenario vulnerable a la explotación.
Fase 5: Mantenimiento y Operaciones
Llevar a cabo la gestión operativa Comentarios
Chequear periódicamente el comportamiento: Se deben realizar controles mensuales o trimestrales en la aplicación y la infraestructura para asegurar que no hayan entrado nuevos riesgos de seguridad, y que el nivel de seguridad sigue intacto.
Asegurar y Verificar Cambios: Después de que cada cambio haya sido aprobado y probado en el entorno de control de calidad y desplegado en el entorno de producción, es vital que se compruebe y asegure que el nivel de seguridad no se haya afectado por el cambio.
Test de Seguridad en Aplicaciones WEB En este capítulo se hace una descripción de la metodología de las pruebas de seguridad de aplicaciones web OWASP; de igual forma se explica cómo probar la evidencia de vulnerabilidades dentro de la aplicación causada por deficiencias en los controles de seguridad identificados.
¿Qué es la Web Application Security Testing? Se puede entender como un método de evaluación de la seguridad de un sistema informático o red, el cual valida y verifica metódicamente la eficacia de los controles de seguridad de la aplicación. Una prueba de la seguridad de aplicaciones web se centra sólo en la evaluación de la seguridad de una aplicación web. Este proceso implica un análisis activo de la solicitud de las debilidades, fallas técnicas, o vulnerabilidades. Todas las cuestiones de seguridad que se encuentran se presentarán al propietario del sistema, junto con una evaluación del impacto, una propuesta de mitigación o una solución técnica.
¿Cuál es la metodología de pruebas de OWASP? Las pruebas de seguridad nunca serán exactas, donde una lista de los posibles problemas que deban ser probados se defina en su totalidad. De hecho, las pruebas de seguridad es 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 posibles técnicas de prueba, explicar estas técnicas, y mantener la guía actualizada. El Método de ensayo de seguridad en aplicaciones de OWASP Web se basa en el enfoque de la caja negro. El probador no sabe nada o tiene muy poca información acerca de la aplicación que desea probar. El modelo de prueba consiste en: Tester: Quién lleva a cabo las actividades de prueba Herramientas y metodología: El núcleo de este proyecto “Guía de Pruebas” Aplicación: La caja negra a probar La prueba se divide en 2 fases: Fase 1 Modo pasivo: el probador intenta comprender la lógica de la aplicación y juega con la aplicación. Pueden utilizarse herramientas para obtener información gathering. Por ejemplo, un proxy HTTP se puede utilizar para observar todas las peticiones y respuestas HTTP. Al final de esta fase, el auditor debe entender todos los puntos de acceso ('' puertas '') de la aplicación (por ejemplo, los encabezados HTTP, parámetros y cookies).
Fase 2 Modo activo: el probador comienza a probar utilizando la metodología descrita en las secciones de seguimiento. El conjunto de pruebas activas se han dividido en 11 sub-categorías para un total de 91 controles: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Recopilación de información Configuración y pruebas de gestión de despliegue Pruebas de gestión de Identidad Prueba de autenticación Pruebas de autorización Prueba gestión de la sesión Pruebas de validación de entrada Control de errores Criptografía Empresas prueba lógica Prueba del lado del cliente
Checklist de Pruebas: Las listas descritas a continuación, son los controles a probar durante la evaluación en cada categoría. 4.2. Prueba de recopilación de información: Incluye los siguientes artículos: Ref. No.
Categoría
Nombre de la prueba
4.2.1
OTG-INFO-001
Realizar “Search Engine” descubrimiento y reconocimiento de fuga de información
4.2.2
OTG-INFO-002
Huella digital del servidor Web
4.2.3
OTG-INFO-003
Revisión Webserver, Metarchivos para fuga de información
4.2.4
OTG-INFO-004
Enumerar aplicaciones en Webserver
4.2.5
OTG-INFO-005
Revisión de comentarios en páginas web y metadatos para la fuga de información.
4.2.6
OTG-INFO-006
Identificar los puntos de entrada de la aplicación
4.2.7
OTG-INFO-007
Rutas de ejecución Mapa través de la aplicación
4.2.8
OTG-INFO-008
Marco de Aplicaciones Web de huellas dactilares
4.2.9
OTG-INFO-009
Aplicación Web de huellas dactilares
4.2.10
OTG-INFO-010
Mapa Solicitud Arquitectura
4.3 Configuración y Despliegue de Pruebas de gestión: La comprensión de la configuración desplegada del servidor que aloja la aplicación web es casi tan importante como la prueba de seguridad de la aplicación en sí. Después de todo, una cadena de solicitud es sólo tan fuerte como su eslabón más débil. Las plataformas de aplicaciones son amplias y variadas, pero algunos errores de configuración de plataforma pueden poner en peligro la aplicación, de la misma manera una aplicación segura puede comprometer el servidor.
Con el fin de evaluar el grado de preparación de la plataforma de aplicaciones, las pruebas para la gestión de configuración incluyen las siguientes secciones:
Ref. No.
Categoría
Nombre de la prueba
4.3.1
OTG-config-001
Prueba de red / Configuración de Infraestructura
4.3.2
OTG-config-002
Prueba de configuración de la plataforma de aplicaciones
4.3.3
OTG-config-003
Prueba de Extensiones de archivo de información sensible
4.3.4
OTG-config-004
Revisión antigua, copias de seguridad y archivos sin referencias de Información Sensible
4.3.5
OTG-config-005
Enumerar infraestructura y aplicaciones Interfaces admin
4.3.6
OTG-config-006
Métodos de prueba HTTP
4.3.7
OTG-config-007
Prueba HTTP Strict Transport Security
4.3.8
OTG-config-008
Prueba RIA política entre dominios
4.4 Pruebas de Gestión de Identidad: Es común que en las empresas modernas se definan las funciones del sistema para administrar usuarios, así como la autorización de los recursos del sistema. En la mayoría de las implementaciones de sistemas se espera que existan al menos dos funciones, los administradores y usuarios regulares. La primera permite el acceso a la funcionalidad y la información privilegiada y confidencial, la segunda representa una función que permite el acceso a la funcionalidad habitual de negocios y la información. Las pruebas para la Gestión de Identidad incluyen las siguientes secciones: Ref. No.
Categoría
Nombre de la prueba
4.4.1
OTG-IDENT-001
Definiciones de funciones de prueba
4.4.2
OTG-IDENT-002
Prueba Proceso de Registro de Usuario
4.4.3
OTG-IDENT-003
Proceso de “Test Account Provisioning”
4.4.4
OTG-IDENT-004
Pruebas de enumeración y cuentas de usuario.
4.4.5
OTG-IDENT-005
Pruebas para la política de nombre de usuario débil o no ejecutadas
4.4.6
OTG-IDENT-006
Permisos de prueba a cuentas de invitado
4.4.7
OTG-IDENT-007
Prueba de Suspensión / Reanudación Proceso
4.5 Prueba de autenticación: Autenticación es el acto de establecer o confirmar algo (o alguien) como auténtico, es decir, que las afirmaciones hechas por o sobre la cosa son ciertas. Autenticar un objeto puede significar confirmar su procedencia, mientras que la autenticación de una persona a menudo consiste en verificar su identidad. Las pruebas de autenticación incluyen los siguientes artículos: Ref. No.
Categoría
Nombre de la prueba
4.5.1
OTG-AUTHN-001
Pruebas para Credenciales transportadas sobre un canal cifrado
4.5.2
OTG-AUTHN-002
Pruebas para las credenciales predeterminadas
4.5.3
OTG-AUTHN-003
Pruebas para mecanismo de bloqueo débil
4.5.4
OTG-AUTHN-004
pruebas para pasar por el sistema de autenticación
4.5.5
OTG-AUTHN-005
Prueba de funcionalidad de recordar contraseña
4.5.6
OTG-AUTHN-006
Pruebas de debilidad de Caché del navegador
4.5.7
OTG-AUTHN-007
Pruebas para la política de contraseñas débiles
4.5.8
OTG-AUTHN-008
Pruebas para la seguridad débil - pregunta / respuesta
4.5.9
OTG-AUTHN-009
Pruebas para cambio de contraseña débil o funcionalidades de reinicio
4.5.10
OTG-AUTHN-010
Las pruebas para la autenticación más débil en el canal alternativo
4.6 Pruebas de Autorización: La autorización es el concepto de permitir el acceso a los recursos que sólo se tiene permitido usar. Pruebas de Autorización significa entender cómo funciona el proceso de autorización, y utilizar esa información para evitar el mecanismo de autorización. La autorización es un proceso que se produce después de una autenticación exitosa, por lo que el probador verificará este punto después de que él tiene credenciales válidas, asociados a un bien define un conjunto de roles y privilegios. Las pruebas de autorización incluyen los siguientes artículos: Ref. No. 4.6.1
Categoría OTG-authz-001
Nombre de la prueba Directorio Prueba de recorrido / archivo incluye
4.6.2
OTG-authz-002
Las pruebas para pasar del esquema de autorización
4.6.3
OTG-authz-003
Las pruebas de elevación de privilegios
4.6.4
OTG-authz-004
Las pruebas para inseguras de referencias a objetos directos
4.7 Prueba Gestión de la sesión: Uno de los componentes básicos de cualquier aplicación basada en la web, es el mecanismo por el cual se controla y mantiene el estado de un usuario con él. Esto se refiere a esto como Gestión de la sesión y se define como el conjunto de todos los controles que rigen la interacción de pleno estado entre un usuario y la aplicación basada en web. Esto cubre ampliamente nada de cómo se realiza la autenticación de usuarios, a lo que sucede en ellos salir de la sesión. Las pruebas de Gestión de la sesión incluyen los siguientes artículos: Ref. No.
Categoría
Nombre de la prueba
4.7.1
OTG-SESS-001
Pruebas para Omisión del esquema de gestión de la sesión
4.7.2
OTG-SESS-002
Pruebas para atributos de cookies
4.7.3
OTG-SESS-003
Pruebas de fijación de Sesión
4.7.4
OTG-SESS-004
Pruebas para variables de sesión expuestas
4.7.5
OTG-SESS-005
Pruebas de “Cross Site” Falsificación de Petición
4.7.6
OTG-SESS-006
Pruebas de funcionalidad de cierre de sesión
4.7.7
OTG-SESS-007
Prueba Sesión inactiva
4.7.8
OTG-SESS-008
Pruebas para la sesión desconectada
4.8 Datos de Pruebas de Validación: La debilidad más común de seguridad de aplicaciones web es la falta de una validación adecuada de las entradas procedentes del cliente o desde el medio ambiente antes de usarlo. Esta debilidad conduce a casi todas las principales vulnerabilidades en aplicaciones web, tales como cross site scripting, inyección SQL, inyección intérprete, ataques locale / Unicode, los ataques del sistema de archivos, y desbordamientos de búfer.
Las pruebas de Datos de pruebas de validación incluyen los siguientes artículos: Ref. No.
Categoría
Nombre de la prueba
4.8.1
OTG-INPVAL-001
Pruebas para Reflected Cross Site Scripting
4.8.2
OTG-INPVAL-002
Pruebas “Reflected Cross Site Scripting”
4.8.3
OTG-INPVAL-003
Las pruebas para Manipulación de HTTP
4.8.4
OTG-INPVAL-004
Las pruebas para Parámetros contaminados en HTTP
4.8.5
OTG-INPVAL-005
Pruebas de Inyección SQL
4.8.5.1
Pruebas de Oracle
4.8.5.2
Pruebas de MySQL
4.8.5.3
Pruebas de SQL Server
4.8.5.4
PostgreSQL Testing
4.8.5.5
MS Pruebas de Acceso
4.8.5.6
Pruebas para la inyección NoSQL
4.8.6
OTG-INPVAL-006
Pruebas de inyección LDAP
4.8.7
OTG-INPVAL-007
Pruebas de inyección ORM
4.8.8
OTG-INPVAL-008
Pruebas de inyección XML
4.8.9
OTG-INPVAL-009
Ruebas de inyección SSI
4.8.10
OTG-INPVAL-010
Pruebas para XPath Injection
4.8.11
OTG-INPVAL-011
Inyección IMAP / SMTP
4.8.12
OTG-INPVAL-012
Pruebas para la inyección de código
4.8.12.1
Pruebas para la Inclusión de archivos locales
4.8.12.2
Pruebas para la inclusión de archivos remotos
4.8.13
OTG-INPVAL-013
Pruebas de inyección de comandos
4.8.14
OTG-INPVAL-014
Pruebas para desbordamiento de búfer
4.8.14.1
Pruebas de desbordamiento del montón
4.8.14.2
Pruebas de desbordamiento de pila
4.8.14.3
Las pruebas para el formato de cadenas
4.8.15
OTG-INPVAL-015
Pruebas de vulnerabilidades incubadas
4.8.16
OTG-INPVAL-016
Pruebas de HTTP Splitting / Contrabando
4.9 Control de errores: A menudo, durante una prueba de penetración en aplicaciones web, nos encontramos con muchos códigos de error generados por las aplicaciones o servidores web. Es posible hacer que estos errores que se mostrarán mediante un pedido en particular, ya sea especialmente diseñados con herramientas o creados manualmente. Estos códigos son muy útiles a la penetración probadores durante sus actividades, porque revelan una gran cantidad de información acerca de las bases de datos, los insectos, y otros componentes tecnológicos vinculados directamente con las aplicaciones web.
Las pruebas de Control de errores incluyen los siguientes artículos: Ref. No.
Categoría
Nombre de la prueba
4.9.1
OTG-ERR-001
Análisis de códigos de error
4.9.2
OTG-ERR-002
Análisis de trazas de pila
4.10 Criptografía: Los datos sensibles deben ser protegidos cuando se transmite a través de la red. Estos datos pueden incluir credenciales de usuario y tarjetas de crédito. Como regla general, si los datos deben ser protegidos cuando se almacena, debe ser protegido también durante la transmisión. Las pruebas de Criptografía incluyen los siguientes artículos: Ref. No.
Categoría
Nombre de la prueba
4.10.1
OTG-CRYPST-001
Pruebas de SSL Débil / TSL Cifrados, Transporte insuficiente capa de protección
4.10.2
OTG-CRYPST-002
Las pruebas para Relleno Oracle
4.10.3
OTG-CRYPST-003
Las pruebas para la información sensible enviada a través de canales no cifrados
4.11 Pruebas Lógicas de Empresas: Pruebas para fallas de lógica de negocio en una aplicación web dinámica multi-funcional requiere pensar en métodos poco convencionales. Si el mecanismo de autenticación de una aplicación se desarrolla con la intención de realizar los pasos 1, 2, 3 en ese orden específico para autenticar un usuario. Las Pruebas Lógicas de Empresas incluyen los siguientes artículos: Ref. No.
Categoría
Nombre de la prueba
4.11.1
OTG-Buslogic-001
Pruebas de validación de Data Logic
4.11.2
OTG-Buslogic-002
Prueba capacidad de forjar las solicitudes
4.11.3
OTG-Buslogic-003
Pruebas de chequeo de integridad
4.11.4
OTG-Buslogic-004
Prueba para la sincronización de procesos
4.11.5
OTG-Buslogic-005
Prueba de número de veces que una función se puede utilizar
4.11.6
OTG-Buslogic-006
Las pruebas para la elusión de los flujos de trabajo
4.11.7
OTG-Buslogic-007
Defensas de prueba contra la aplicación Mis-use
4.11.8
OTG-Buslogic-008
Prueba de carga de archivos inesperados
4.11.9
OTG-Buslogic-009
Prueba carga de archivos maliciosos
4.12 Prueba del lado del cliente: Las pruebas del lado del cliente se refieren a la ejecución de código en el cliente, por lo general de forma nativa dentro de un navegador web o un plugin para el navegador. La ejecución de código en el lado del cliente es distinta de la ejecución en el servidor y devolver el contenido posterior. Los siguientes artículos describen cómo llevar a cabo una prueba del lado del cliente de una aplicación web: Ref. No.
Categoría
Nombre de la prueba
4.12.1
OTG-CLIENT-001
Pruebas para base DOM Cross Site Scripting
4.12.2
OTG-CLIENT-002
Pruebas para la ejecución de Javascript
4.12.3
OTG-CLIENT-003
Pruebas de inyección HTML
4.12.4
OTG-CLIENT-004
Pruebas para redireccionamiento del cliente a un sitio o URL
4.12.5
OTG-CLIENT-005
Pruebas para inyección CSS
4.12.6
OTG-CLIENT-006
Pruebas para la manipulación de recursos
4.12.7
OTG-CLIENT-007
Prueba intercambio de recursos de Origen
4.12.8
OTG-CLIENT-008
Pruebas “Cross Site Flashing”
4.12.9
OTG-CLIENT-009
Pruebas para “Clickjacking”
4.12.10
OTG-CLIENT-010
Prueba “WebSockets”
4.12.11
OTG-CLIENT-011
Prueba Mensajería Web
12.04.12
OTG-CLIENT-012
Prueba de almacenamiento local
Informes El desarrollo de la parte técnica de la evaluación es sólo la mitad del proceso de evaluación general. El producto final es la producción de un informe bien escrito e informativo. El informe debe ser fácil de entender y debe poner de relieve todos los riesgos encontrados durante la fase de evaluación; debe atraer tanto a la dirección ejecutiva y personal técnico. El informe debe tener tres secciones principales. Debe ser creado de una manera que permite que cada sección separada que se debe imprimir y dado a los equipos apropiados, tales como los promotores o gestores del sistema. Las secciones recomendadas se describen a continuación. 1. Resumen Ejecutivo: El resumen ejecutivo resume los resultados generales de la evaluación y ofrece a los administradores de negocios y propietarios de sistemas una vista de alto nivel de las vulnerabilidades descubiertas. El resumen ejecutivo también debe indicar claramente que las vulnerabilidades y su gravedad es una entrada al proceso de gestión de riesgo de la organización, no un resultado o remediación. 2. Parámetros de prueba: La Introducción debe perfilar los parámetros de las pruebas de seguridad, los resultados y la remediación. 3. Conclusiones: En la última sección del informe se incluye información técnica detallada acerca de las vulnerabilidades detectadas y las acciones necesarias para resolverlos. Esta sección está dirigida a un nivel técnico y debe incluir toda la información necesaria para que los equipos técnicos para entender el problema y resolverlo. Cada hallazgo debe ser
claro y conciso, y dar al lector del informe una comprensión completa del tema en cuestión.
