Machine Translated by Google

Machine Translated by Google

Diseñado para lectores de libros electrónicos o impresión a doble cara.

Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Este manual proporciona casos de prueba que dan como

resultado hechos verificados. Estos hechos proporcionan
información procesable que puede mejorar de manera
mensurable su seguridad operativa. Al utilizar OSSTMM,
ya no tendrá que depender de las mejores prácticas
generales, la evidencia anecdótica o las supersticiones
porque tendrá información verificada específica para sus
necesidades en la que basar sus decisiones de seguridad.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 1
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Instrucciones
Se trata de una metodología para probar la seguridad operativa de ubicaciones físicas, interacciones humanas y todas las formas
de comunicación, como inalámbricas, cableadas, analógicas y digitales. Aquellos que quieran comenzar a realizar pruebas
directamente mientras la utilizan pueden encontrar útil la siguiente información de inicio rápido.

Inicio rápido
Para comenzar a realizar una prueba OSSTMM, deberá realizar un seguimiento de lo que prueba (los objetivos), cómo lo prueba
(las partes de los objetivos probadas y no las herramientas o técnicas utilizadas), los tipos de controles descubiertos y lo que no
probó (los objetivos y las partes de los objetivos). Luego, puede realizar la prueba como está acostumbrado con el objetivo de poder
responder las preguntas en el Informe de auditoría de pruebas de seguridad (STAR) disponible al final de este manual o como un
documento independiente. El STAR brinda información específica sobre la prueba sobre el estado del alcance para obtener los
beneficios de tener una declaración clara de las métricas de seguridad y detalles para comparaciones con pruebas de seguridad
anteriores o promedios de pruebas de la industria. En este manual se encuentran disponibles más detalles sobre la información
requerida para el STAR y se puede hacer referencia a ellos según sea necesario.
Como puede ver, adoptar este enfoque implica que se requiere muy poco tiempo además de una prueba estándar y la formalización
del informe. Se ha informado que esta metodología en realidad reduce el tiempo de prueba y presentación de informes debido a
las eficiencias introducidas en el proceso. No debería haber ninguna razón de tiempo o financiera para evitar el uso del OSSTMM y
no se imponen restricciones irrazonables al evaluador.

Actualización desde versiones anteriores

Si está familiarizado con la serie OSSTMM 2.x, entonces encontrará que la metodología ha cambiado por completo. El nuevo rav
proporciona una métrica de superficie de ataque factual que es mucho más precisa para medir la susceptibilidad a los ataques.
También hay muchos otros cambios y mejoras, pero el enfoque principal ha sido alejarse de las pruebas basadas en soluciones
que asumen que se encontrarán soluciones de seguridad específicas en un ámbito y que son necesarias para la seguridad (como
un firewall). Otro cambio que puede notar es que ahora hay una única metodología de pruebas de seguridad para todos los canales:
humano, físico, inalámbrico, telecomunicaciones y redes de datos.

La información de la versión 2.x a la 3.0 es incompatible. Aquellos que tengan una versión 3.0 del borrador de la versión 3.0
(anterior a la RC 12) necesitarán que se vuelvan a calcular los valores utilizando este cálculo final de la superficie de ataque, que
está disponible como calculadora de hoja de cálculo en [Link] Las métricas de seguridad anteriores de
OSSTMM medían el riesgo con la degradación, pero esta versión no lo hace. En cambio, ahora el foco está en una métrica para la
superficie de ataque (la exposición) de un objetivo o alcance. Esto permite una métrica factual que no tiene sesgo ni opinión como
el riesgo. Nuestra intención es eliminar eventualmente el uso del riesgo en áreas de seguridad que no tienen un valor de precio fijo
de un activo (como las personas, la privacidad personal e incluso los mercados fluctuantes) a favor de métricas de confianza que
se basan completamente en hechos.

Gran parte de la terminología ha cambiado en esta versión para ofrecer una definición profesional de lo que realmente se puede
crear o desarrollar. Esto es más notable en las definiciones de seguridad y protección, que adoptan significados más específicos y
concretos para las operaciones que se llevan a cabo en ellas.

Dado que se han producido muchos cambios con respecto a las versiones anteriores, y dado que se trata de una metodología
completamente reescrita, le recomendamos que la lea una vez antes de utilizarla. Puede obtener más ayuda en [Link]
ISECOM ofrece cursos que le ayudarán a realizar pruebas, sistemas y procesos de seguridad exhaustivos y adecuados que le
ayudarán a aprovechar al máximo el OSSTMM.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
2 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Información de la versión

La versión actual del Manual de metodología de pruebas de seguridad de código abierto (OSSTMM) es la 3.02. Esta versión
del OSSTMM pone fin a la serie 2.x. Todas las versiones del OSSTMM anteriores a la 3.0, incluidas las versiones candidatas
a la versión 3.0 (versiones RC), ahora están obsoletas.

La versión original fue publicada el lunes 18 de diciembre de 2000. Esta versión actual se publica el martes 14 de diciembre
de 2010.

Acerca de este proyecto

Este proyecto es mantenido por el Instituto de Seguridad y Metodologías Abiertas (ISECOM), desarrollado en una comunidad
abierta y sujeto a revisión interdisciplinaria y por pares. Este proyecto, como todos los proyectos de ISECOM, está libre de
influencias comerciales y políticas. La financiación para todos los proyectos de ISECOM se proporciona a través de
asociaciones, suscripciones, certificaciones, licencias e investigación basada en estudios de casos. ISECOM es una
organización sin fines de lucro registrada y establecida en Nueva York, EE. UU. y en Cataluña, España.

Soporte local
Es posible que haya oficinas regionales de ISECOM disponibles en su área para brindarle asistencia comercial y lingüística.
Encuentre al socio de ISECOM en su área en [Link]

Apoyo comunitario
Para un mayor desarrollo del documento, se requiere la evaluación del lector, sugerencias para mejoras y resultados de su aplicación
para estudios posteriores. Póngase en contacto con nosotros en [Link] Ofrecer apoyo en la investigación, revisión y
asistencia en la edición.

Edición impresa

La edición impresa de este manual está disponible para su compra en el sitio web de ISECOM.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 3
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Restricciones

La información contenida en este documento no puede modificarse ni venderse sin el consentimiento expreso de ISECOM. La venta comercial
de este documento o de la información contenida en él, incluida la metodología aplicada en una herramienta, software o lista de
verificación, NO puede realizarse sin el permiso explícito de ISECOM.

Este documento de investigación es de libre lectura, libre distribución no comercial, libre cita o aplicación en investigaciones académicas o comerciales,
y libre uso o aplicación en los siguientes compromisos comerciales: pruebas, educación, consultoría e investigación.

Este manual está licenciado por ISECOM bajo Creative Commons 3.0 Atribución­NoComercial­SinDerivadas y la Licencia de Metodología Abierta 3.0.

El logotipo de ISECOM es una marca registrada oficial y no se puede usar ni reproducir comercialmente sin el consentimiento de ISECOM. El gráfico
del colibrí de OSSTMM es propiedad intelectual de Marta Barceló Jordan, licenciado a ISECOM y no se puede usar ni reproducir comercialmente sin
permiso.

Como proyecto colaborativo y abierto, el OSSTMM no se debe distribuir por ningún medio que genere un beneficio comercial, ya sea por sí mismo o
como parte de una colección. Como norma, solo puede haber una versión oficial del OSSTMM en cualquier momento y esa versión no se debe alterar
ni bifurcar de ninguna manera que genere confusión en cuanto al propósito de la metodología original. Por lo tanto, no se permite ninguna derivación
del OSSTMM.

Como metodología, la OSSTMM está protegida por la Licencia de Metodología Abierta 3.0, que aplica la misma protección
que la otorgada a los Secretos Comerciales. Sin embargo, cuando un Secreto Comercial requiere un esfuerzo suficiente
para mantenerlo, la OML exige que el usuario haga el esfuerzo suficiente para ser lo más transparente posible sobre la
aplicación de la metodología. Por lo tanto, el uso y la aplicación de la OSSTMM se consideran como la aceptación de la
responsabilidad del usuario de cumplir con los requisitos de la OML. No existen restricciones comerciales sobre el uso o
la aplicación de la metodología dentro de la OSSTMM. La OML está disponible al final de este manual y en http://
[Link]/oml.

Cualquier pregunta o solicitud sobre licencias debe dirigirse a ISECOM.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
4 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Desarrolladores primarios
• ISECOM
◦ Marta Barceló, Directora, Miembro de la Junta Directiva de ISECOM
◦ Pete Herzog, Director, Líder del Proyecto OSSTMM, Miembro de la Junta Directiva de ISECOM

Contribuyentes principales
Las siguientes personas aparecen ordenadas alfabéticamente por empresa. Cada una de ellas ha ejercido una influencia sustancial en el desarrollo de
este OSSTMM.

@[Link], Italia Raoul ISECOM, Estados Unidos

Chiesa, miembro de la junta directiva de ISECOM Robert E. Lee, miembro de la junta directiva de ISECOM
Marco Ivaldi Fabio
Guasconi Fabrizio GCP Global, México
Sensibile Francisco Puente

adMERITia GmbH, Alemania KCT Data, Inc., EE. UU.

Heiko Rudolph, miembro de la junta directiva de ISECOM Kim Truett, miembro de la junta directiva de ISECOM
Aarón Brown
URL de La Salle, España
Bell Canada, Canadá Jaume Abella, miembro de la Junta Directiva de ISECOM
Rick Mitchell
Lab106 y Outpost24, Países Bajos
Blue Secure Limited, Nueva Zelanda Coro Rosielle
Richard Feist, miembro de la junta directiva de ISECOM
OneConsult GmbH, Suiza
Dreamlab Technologies Ltd., Suiza Christoph Baumgartner, miembro de la junta directiva de ISECOM
Nick Mayencourt, miembro de la junta directiva de ISECOM
Urs B. Weber Puesto de avanzada 24,
Adrian Gschwend Thomas Suecia Jack C. Louis
Bader

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 5
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Colaboradores, revisores y asistentes

Un enorme y sincero agradecimiento a todos aquellos que han dedicado su esfuerzo para hacer realidad esta versión de OSSTMM. Sin
ustedes, no habrían existido los debates sensatos que dieron origen a este manual.

Un agradecimiento especial a Jack C. Louis (5 de enero de 1977 ­ 15 de marzo de 2009), un brillante

investigador de seguridad, una persona increíble y uno de los primeros capacitadores de OPST y
OPSA certificados por ISECOM. En ISECOM apreciamos enormemente todos sus esfuerzos y los
dejamos como un punto de referencia que esperamos sirva de inspiración a otros profesionales de
la seguridad. Sus contribuciones al OSSTMM nunca serán olvidadas. ¡Gracias!

Contribuciones Revisión y asistencia

Alberto Perrone, @[Link], Italia Martin Gunnar Peterson, Arctec Group, EE. UU.
Dion, Above Security, Canadá Lars Heidelberg, Dieter Sarrazyn, Ascure nv., Bélgica Bob
adMERITia GmbH, Alemania Martin Pajonk, adMERITia Davies, Bell Canada, Canadá Josep Ruano,
GmbH, Alemania Dru Lavigne, Carleton University, Capside, España Adrien de Beaupre,
Canadá Todd A. Jacobs, Codegnome, EE. UU. Phil Canadá Clement Dupuis, CCCure,
Robinson, Digital Assurance, Reino Unido Canadá Armand Puccetti, CEA, Francia
Philipp Egli, Dreamlab Technologies Ltd., Jose Luis Martin Mas, davinci
Suiza Daniel Hulliger, Dreamlab Technologies Ltd., Suiza Simon Consulting, España Sylvie Reinhard, Dreamlab
Nussbaum, Dreamlab Technologies Ltd., Suiza Sven Vetsch, Dreamlab Technologies Ltd., Suiza Raphaël Haberer­Proust, Dreamlab
Technologies Ltd., Suiza Colby Clark, Guidance Software, EE. UU. Andy Technologies Ltd., Suiza Josh Zelonis, Dyad Security, EE. UU. Bora Turan, Ernst
Moore, Hereford InfoSec, Reino Unido Peter Klee, IBM, Alemania and Young, Turquía Luis Ramon Garcia
Daniel Fernandez Bleda, Internet Security Solano, GCP Global, México John Thomas
Auditors, España Jay Abbott, Outpost24 / Regney, Gedas, España Mike Aiello, Goldman Sachs, EE.
Lab106, Países Bajos Steve UU. Dirk Kuhlmann, HP, Reino Unido John
Armstrong, Logically Secure, Reino Unido Simon Wepfer, OneConsult Rittinghouse, Hypersecurity LLC, EE. UU.
GmbH, Suiza Manuel Krucker, OneConsult GmbH, Suiza Massimiliano Graziani,
Jan Alsenz, OneConsult GmbH, Suiza Tobias IISFA, Italia Jose Navarro, Indiseg, España Timothy
Ellenberger, OneConsult GmbH, Suiza Shaun Copplestone, Phillips, Information Assurance Solutions,
The Watchers Inc., Canadá Ian Latter, Pure Hacking, EE. UU. Joan Ruiz, La Salle URL,
Australia Ty Miller, Pure Hacking, Australia Jordi España Víktu Pons i Colomer, La Salle URL, España Roman
André i Vallverdú, La Caixa, España Jim Brown, Thrupoint, EE. Drahtmueller, Novell, Alemania
UU. Chris Griffin, ISECOM, EE. UU. Charles Le Grand, EE. Hernán Marcelo Racciatti, SICLABS, Argentina
UU. Dave Lauer, EE. UU. John Hoffoss, Tom Brown, RWE Shared Services IS, Reino
Minnesota State Colleges and Unido Marcel Gerardino, Sentinel, República Dominicana
Universities, EE. UU. Mike Mooney, EE. UU. Manuel Atug, SRC Security Research &
Pablo Endres, Venezuela / Consulting GmbH, Alemania Torsten Duwe, SUSE, Alemania
Alemania Jeremy Wilde, Alexander J. Herzog, EE. UU. Drexx Laggui, L&A Inc, Filipinas Ruud van der Meulen,
[Link], Países Bajos Chris Gatford, HackLabs,
Reino Unido / Francia Australia Wim Remes, Bélgica
Rob J. Meijer, Países Bajos Mike Simpson, EE. UU. / Alemania Gary Axten, Reino Unido / España Alan
Tang, Reino Unido Jason Woloz, [Link].
John R. Moser, [Link]. Tom O'Connor,
Irlanda Mike Vasquez,
Ciudad de Mesa, [Link].

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
6 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Prefacio
La verificación de seguridad solía requerir un especialista interdisciplinario que entendiera la seguridad tan profundamente como entendía las
reglas, leyes, premisas subyacentes, operaciones, procesos y tecnología involucradas.
Algún tiempo después, la verificación por terceros surgió de la noción popular de la ceguera del constructor, que dice que aquellos que están
más cerca del objetivo generalmente y por lo general pasan por alto involuntariamente la mayoría de los problemas. Este se convirtió en el
procedimiento estándar durante un tiempo y todavía se considera ampliamente cierto, aunque en realidad significa que un extraño con menos
conocimiento del objetivo supuestamente es más capaz de comprenderlo que el operador. En algún momento, el péndulo comenzó a oscilar
en sentido contrario. No está claro si esto sucedió por razones de eficiencia o económicas, pero ha provocado un cambio importante para
proporcionar a los operadores la capacidad de realizar pruebas de seguridad. Ha llevado a marcos simplificados, software, listas de verificación,
kits de herramientas y muchas otras formas de hacer que las pruebas de seguridad sean lo suficientemente fáciles para que cualquiera pueda
hacerlo. Eso es algo bueno.

Lamentablemente, no existe ningún tema complejo en el que el proceso de simplificación no sea en sí mismo complejo ni el resultado final
significativamente inferior al conjunto. Esto significa que para que una solución de pruebas de seguridad sea lo suficientemente sencilla como
para que la ejecuten personas no expertas, la solución requiere un back­end complejo para recopilar los datos de acuerdo con reglas
preconcebidas. Esto supone que las operaciones siempre se ejecutan de acuerdo con el diseño y la configuración. También supone que el
desarrollador de la solución ha tenido en cuenta todas las posibilidades de dónde, qué y cómo se pueden recopilar los datos. Además, supone
que los datos recopilados se pueden clasificar correctamente en un formato uniforme para su comparación y análisis basado en reglas. Ninguna
de esas tareas es sencilla.
Suponiendo que esto se pueda hacer, todavía se requeriría una base de datos exhaustiva de posibilidades para las numerosas representaciones
de seguridad y capas de controles para deducir los problemas de seguridad, al tiempo que se minimizan los falsos positivos mediante
correlaciones basadas en las reglas, leyes, premisas subyacentes, operaciones, procesos y tecnologías involucradas. Esta solución podría
entonces ser capaz de proporcionar un informe y una métrica claros y concisos. Esta solución necesitaría tener más que solo el marco, el
software, la lista de verificación o el kit de herramientas que produce; necesitaría una metodología.

Una metodología de seguridad no es algo sencillo. Es la parte final de un proceso o solución que define qué o quién se prueba, así como
cuándo y dónde. Debe tomar un proceso complejo y reducirlo a procesos elementales y explicar suficientemente los componentes de esos
procesos. Luego, la metodología debe explicar las pruebas para verificar lo que esos procesos elementales están haciendo mientras están en
acción, moviéndose y cambiando. Finalmente, la metodología debe contener métricas tanto para asegurar que la metodología se ha llevado a
cabo correctamente como para comprender o calificar el resultado de la aplicación de la metodología. Por lo tanto, crear una metodología de
pruebas de seguridad no es una tarea fácil.

Con cada nueva versión de OSSTMM nos acercamos a expresar la seguridad de forma más satisfactoria que las versiones anteriores. No es
que esta OSSTMM 3 promueva ideas revolucionarias, sino que aplica muchos conceptos pragmáticos nuevos que mejorarán la seguridad. Nos
estamos acercando cada vez más a comprender realmente qué nos hace sentir seguros.

Por la oportunidad de tener esta iluminación, quiero agradecer a todos los contribuyentes de OSSTMM, al equipo de ISECOM, a todos los
estudiantes certificados de ISECOM que se preocupan por la forma correcta de hacer pruebas de seguridad, a todos los que enseñan Hacker
Highschool a la próxima generación, a todos los partidarios de los proyectos de ISECOM, incluidos los socios de capacitación de ISECOM, los
auditores autorizados de ISECOM y, finalmente, a mi muy paciente y comprensiva esposa que entiende lo importante que es esto para mí y
para el mundo que necesitamos mejorar.

Gracias a todos por vuestra ayuda.

Pete Herzog

Director, ISECOM

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 7
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Tabla de contenido
Instrucciones..................................................................................................................................................................2 Inicio
rápido...............................................................................................................................................................2 Actualización desde versiones
anteriores..............................................................................................................................2 Información de la
versión..............................................................................................................................................3 Acerca de este
proyecto..............................................................................................................................................3
Restricciones..............................................................................................................................................................4 Desarrolladores
principales..............................................................................................................................................5 Colaboradores
principales..............................................................................................................................................5 Colaboradores, revisores y
asistentes....................................................................................................................6
Prólogo ....................................................................................................................................................................................7
Introducción.....................................................................................................................................................................11
Propósito.....................................................................................................................................................................13 Alcance del
documento..................................................................................................................................................13
Responsabilidad.....................................................................................................................................................13 Certificación y
acreditación..................................................................................................................................14 Relacionado
Proyectos..................................................................................................................................................................17 Capítulo 1 – Lo que
necesita saber.............................................................................................................................................20 1.1
Seguridad.........................................................................................................................................................23 1.2
Controles..................................................................................................................................................................24 1.3 Objetivos de
aseguramiento de la información..................................................................................27 1.4
Limitaciones.............................................................................................................................................................28 1.5 Seguridad
real.............................................................................................................................................31 1.6
Cumplimiento.................................................................................................................................................31 Capítulo 2 – Lo que necesita
hacer..................................................................................................................................33 2.1 Definición de una prueba de
seguridad..................................................................................................................33 2.2
Alcance.........................................................................................................................................................34 2.3 Tipos de pruebas
comunes..............................................................................................................................36 2.4 Reglas de
compromiso..................................................................................................................................38 2.5 El proceso de pruebas de seguridad
operacional.............................................................................................41 2.6 Proceso de cuatro
puntos............................................................................................................................................43 2.7 La
trifecta.........................................................................................................................................................44 2.8 Manejo de
errores..................................................................................................................................................46 2.9
Divulgación..............................................................................................................................................................51 Capítulo 3 – Análisis de
seguridad..................................................................................................................................53 3.1 Pensamiento crítico de
seguridad..................................................................................................................54 3.2 Reconocer el modelo
OpSec.........................................................................................................................56 3.3 Buscar coincidencias de patrones como señal de
errores..................................................................57 3.4 Caracterizar los
resultados..................................................................................................................................57 3.5 Buscar señales de
intuición..................................................................................................................................58 3.6 Informes
transparentes..................................................................................................................................59 Capítulo 4 – Métricas de seguridad
operacional.............................................................................................................62 4.1 Conozca el
Rav..............................................................................................................................................63 4.2 Cómo crear un
Rav.........................................................................................................................................67 4.3 Cómo convertir los resultados de las pruebas
en una medición de la superficie de ataque..................................70 4.4 La fórmula de seguridad
operacional..............................................................................................................79 4.5 La fórmula de
controles..................................................................................................................................80 4.6 La fórmula de
limitaciones..................................................................................................................................83 4.7 La fórmula de seguridad
real.....................................................................................................................85

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
8 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 5 – Análisis de confianza.............................................................................................................................................87 5.1 Entendiendo la

confianza............................................................................................................................................87 5.2 Falacias en la
confianza.........................................................................................................................................89 5.3 Las diez propiedades de la
confianza..................................................................................................................90 5.4 Las reglas de
confianza..............................................................................................................................................91 5.5 Aplicación de las reglas de confianza
a las pruebas de seguridad..................................................................94 Capítulo 6 – Flujo de
trabajo..................................................................................................................................................96 6.1 Flujo de la
metodología..................................................................................................................................................97 6.2 Los módulos de
prueba.............................................................................................................................................99 6.3 Una
metodología.........................................................................................................................................103 Capítulo 7 ­ Pruebas de seguridad
humana..................................................................................................................105 Capítulo 8 ­ Pruebas de seguridad
física.....................................................................................................................120 Capítulo 9 ­ Seguridad inalámbrica
Pruebas..................................................................................................................................138 Capítulo 10 ­ Pruebas de seguridad de
telecomunicaciones.............................................................................................151 Capítulo 11 ­ Pruebas de seguridad de redes de
datos..............................................................................................167 Capítulo 12 ­
Cumplimiento..............................................................................................................................................185
Regulaciones..............................................................................................................................................................186 Capítulo 13 ­ Informes
con STAR..............................................................................................................................192 Capítulo 14 ­ Lo que
obtienes..............................................................................................................................................204 La defensa de
Möbius.....................................................................................................................................................205 Obtenga lo que
necesitamos..............................................................................................................................................206 Capítulo 15 ­ Licencia de metodología
abierta..............................................................................................................208 La OML
3.............................................................................................................................................................................208

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 9
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

En el arte, el resultado final es una cuestión de belleza,

mientras que en la ciencia, los medios para alcanzarlo
son una cuestión de belleza. Cuando una prueba de
seguridad es un arte, el resultado no se puede verificar y
eso socava el valor de la prueba. Una forma de garantizar
que una prueba de seguridad tenga valor es saber que
se ha realizado correctamente. Para ello, es necesario
utilizar una metodología formal. La OSSTMM pretende
ser esa metodología.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
10 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Introducción
El Manual de metodología de pruebas de seguridad de código abierto (OSSTMM) proporciona una metodología para realizar
pruebas de seguridad exhaustivas, a las que en adelante se denominará auditoría OSSTMM. Una auditoría OSSTMM es una
medición precisa de la seguridad a nivel operativo que está libre de suposiciones y evidencia anecdótica. Como metodología,
está diseñada para ser consistente y repetible. Como proyecto de código abierto, permite que cualquier evaluador de seguridad
contribuya con ideas para realizar pruebas de seguridad más precisas, prácticas y eficientes. Además, permite la libre difusión
de información y propiedad intelectual.

Desde su inicio a finales de 2000, el OSSTMM creció rápidamente hasta abarcar todos los canales de seguridad con la
experiencia aplicada de miles de revisores. En 2005, el OSSTMM ya no se consideraba simplemente un marco de mejores
prácticas, sino una metodología para garantizar que la seguridad se estuviera llevando a cabo correctamente en el nivel
operativo. A medida que las auditorías de seguridad se generalizaron, la necesidad de una metodología sólida se volvió crítica.
En 2006, el OSSTMM pasó de definir pruebas basadas en soluciones como pruebas de firewall y pruebas de enrutador a un
estándar para aquellos que necesitaban una prueba de seguridad confiable en lugar de simplemente un informe de cumplimiento
para una regulación o legislación específica.

Dado que los entornos son significativamente más complejos que en años anteriores, debido a cuestiones como las operaciones
remotas, la virtualización, la computación en la nube y otros nuevos tipos de infraestructura, ya no podemos pensar en pruebas
simplistas destinadas únicamente a equipos de escritorio, servidores o equipos de enrutamiento. Por lo tanto, con la versión 3, OSSTMM
abarca pruebas de todos los canales: humanos, físicos, inalámbricos, telecomunicaciones y redes de datos. Esto también lo convierte
en un sistema perfectamente adecuado para probar la computación en la nube, las infraestructuras virtuales, el middleware de
mensajería, las infraestructuras de comunicación móvil, las ubicaciones de alta seguridad, los recursos humanos, la computación de
confianza y cualquier proceso lógico que cubra varios canales y requiera un tipo diferente de prueba de seguridad. Un conjunto de
métricas de superficie de ataque, llamadas ravs, proporciona una herramienta potente y muy flexible que puede proporcionar una
representación gráfica del estado y mostrar cambios en el estado a lo largo del tiempo. Esto se integra bien con un "panel de control"
para la gestión y es beneficioso tanto para las pruebas internas como externas, lo que permite una comparación/combinación de los
dos. La gestión cuantitativa de riesgos se puede realizar a partir de los hallazgos del informe de auditoría de OSSTMM, lo que
proporciona un resultado mucho mejor debido a que los resultados son más precisos y sin errores; sin embargo, encontrará que la
gestión de confianza propuesta aquí es superior a la gestión de riesgos. El OSSTMM incluye información para la planificación de
proyectos, la cuantificación de resultados y las reglas de participación para realizar auditorías de seguridad. La metodología se puede
integrar fácilmente con las leyes y políticas existentes para garantizar una auditoría de seguridad exhaustiva a través de todos los canales.

Las normativas legales y específicas de la industria también suelen exigir una auditoría de seguridad como componente para cumplir
con las normas. Una auditoría OSSTMM es adecuada para la mayoría de estos casos. Por lo tanto, las pruebas OSSTMM específicas
se pueden conectar con requisitos de estándares de seguridad particulares, lo que hace que el propio OSSTMM sea una forma de
lograr el cumplimiento de esos requisitos. Esto se aplica a las normativas y políticas de seguridad física, como la resolución de la
Comisión de la Reserva Federal de Energía de los EE. UU., hasta las iniciativas de seguridad de datos pura, como el último PCI­DSS,
e incluyendo los requisitos de canales cruzados que se encuentran en muchas recomendaciones del NIST y especificaciones de gestión
de seguridad de la información como ISO/IEC 27001:2005, ISO/IEC 27002:2005 e ISO/IEC 27005:2008.

Se recomienda leer el OSSTMM en su totalidad antes de ponerlo en práctica. Su objetivo es ser una herramienta sencilla para la implementación
y documentación de una prueba de seguridad. En el sitio web de ISECOM se puede encontrar más ayuda para quienes necesiten ayuda para
comprender e implementar esta metodología.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 11
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Una breve nota sobre el lenguaje en el OSSTMM

¿Qué es una auditoría? Algunas de las palabras utilizadas en este documento pueden
diferir de la definición con la que está familiarizado. Las nuevas investigaciones a menudo
requieren actualizar, mejorar o retirar información del mundo tal como creíamos que lo
conocíamos. Esto es algo normal y, para ayudarlo con los cambios, este documento intenta
definir estas palabras correctamente en su nuevo contexto. En este documento, una
auditoría OSSTMM o "auditoría" es el resultado del análisis realizado después de una
prueba OSSTMM. La persona que realiza esta función de prueba y análisis se denomina
analista de seguridad o simplemente "analista".

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
12 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Objetivo
El objetivo 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 las pruebas de una manera consistente y confiable.
Este manual se puede adaptar a casi cualquier tipo de auditoría, incluidas las pruebas de penetración, el hackeo ético, las
evaluaciones de seguridad, las evaluaciones de vulnerabilidad, el trabajo en equipo rojo, el trabajo en equipo azul, etc. Está escrito
como un documento de investigación de seguridad y está diseñado para la verificación de seguridad factual y la presentación de
métricas a nivel profesional.

Un objetivo secundario es proporcionar pautas que, si se siguen correctamente, permitirán al analista realizar una auditoría OSSTMM
certificada. Estas pautas existen para garantizar lo siguiente:

1. La prueba se realizó exhaustivamente.

2. La prueba incluyó todos los canales necesarios.
3. La postura para 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 únicamente hechos derivados de las propias pruebas.

Un beneficio indirecto de este manual es que puede actuar como referencia central en todas las pruebas de seguridad,
independientemente del tamaño de la organización, la tecnología o la protección.

Alcance del documento

El objetivo de este documento es proporcionar descripciones específicas para las pruebas de seguridad operativa en todos los
canales operativos, que incluyen redes humanas, físicas, inalámbricas, de telecomunicaciones y de datos, en cualquier vector, y la
descripción de las métricas derivadas. Este manual se centra únicamente en OpSec y el uso de las palabras seguridad y protección
se encuentra dentro de este contexto.

Responsabilidad

Este manual describe ciertas pruebas diseñadas para obtener una respuesta. Si estas pruebas causaran daño o perjuicio, el analista
podría ser responsable de acuerdo con las leyes que rigen la ubicación del analista, así como la ubicación de los sistemas probados.
ISECOM no ofrece garantía alguna en cuanto a un resultado inocuo de ninguna prueba.
Cualquier analista que aplique esta metodología no podrá responsabilizar a ISECOM por los problemas que surjan durante las
pruebas. Al utilizar esta metodología, el analista acepta asumir esta responsabilidad.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 13
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Certificación y Acreditación
Para producir una prueba certificada OSSTMM que pueda recibir acreditación por la seguridad operativa del objetivo, se requiere que el
analista o analistas que realizaron la prueba firmen un STAR. El STAR también debe cumplir con los requisitos de informe de este manual.
El STAR se puede enviar a ISECOM para su revisión y certificación oficial de ISECOM. Una prueba certificada y un informe acreditado no
necesitan demostrar que se siguió todo este manual o alguna subsección específica. Solo necesita mostrar lo que se probó y lo que no para
ser aplicable a la certificación. (Consulte el Capítulo 16, Elaboración del STAR para obtener detalles y un ejemplo de un STAR).

Una auditoría OSSTMM certificada proporciona los siguientes beneficios:

• Sirve como prueba de una prueba fáctica

• Responsabiliza al analista de la prueba.
• Proporciona un resultado claro al cliente
• Proporciona una descripción general más completa que un resumen ejecutivo
• Proporciona métricas comprensibles

La revisión, certificación y acreditación de pruebas por parte de ISECOM o de un tercero acreditado está sujeta a otras condiciones y tarifas
de operación. Póngase en contacto con ISECOM para obtener más información.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
14 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Certificaciones para profesionales

Se dice que todo aquel que utilice esta metodología para realizar pruebas y análisis de seguridad y complete un STAR válido ha realizado una
auditoría OSSTMM. Sin embargo, también está disponible la certificación individual a través de ISECOM para las habilidades aplicadas en
pruebas y análisis de seguridad profesionales, procesos metódicos y estándares profesionales, tal como se describe en las Reglas de participación
de OSSTMM. ISECOM es la autoridad para una variedad de exámenes de certificación de habilidades y conocimientos aplicados basados en la
investigación de OSSTMM. Las clases y los exámenes oficiales son impartidos por socios de capacitación certificados en varias regiones del
mundo. Los exámenes de certificación disponibles actualmente son:

OPST
El evaluador de seguridad profesional OSSTMM demuestra que un candidato tiene las habilidades y el
conocimiento para realizar pruebas de seguridad precisas y eficientes en redes de datos.

[Link]

OPSA
El analista de seguridad profesional de OSSTMM demuestra que un candidato puede aplicar los principios
del análisis de seguridad y las métricas de la superficie de ataque con precisión y eficiencia.

[Link]

OPSE
La certificación de experto en seguridad profesional de OSSTMM demuestra que un candidato ha
aprendido todos los conceptos de seguridad dentro del OSSTMM más actual y disponible públicamente,
así como los antecedentes de la investigación.

[Link]

OWSE
El experto en seguridad inalámbrica de OSSTMM demuestra que un candidato tiene las habilidades y el
conocimiento para analizar y probar la seguridad operativa de las tecnologías inalámbricas en todo el
espectro electromagnético de forma precisa y eficiente.

[Link]

Llamada a la acción

El analista de confianza certificado demuestra que un candidato tiene las habilidades y el conocimiento
para evaluar de manera eficiente las propiedades de confianza de cualquier persona, lugar, cosa, sistema
o proceso y tomar decisiones de confianza precisas y eficientes.

[Link]

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 15
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Certificaciones para Organizaciones

Las certificaciones para organizaciones, infraestructuras y productos también están disponibles a través de ISECOM. Están disponibles las siguientes
certificaciones:

Informe de auditoría de pruebas de seguridad

La certificación OSSTMM está disponible para organizaciones o partes de organizaciones que validan su
seguridad con la certificación STAR de ISECOM. La validación de las pruebas de seguridad y las métricas
trimestrales están sujetas a los requisitos de validación de ISECOM para garantizar un alto nivel de
confiabilidad en una organización.

Auditores autorizados por ISECOM

Los ILA han demostrado a ISECOM que tienen la competencia y la capacidad para realizar auditorías
OSSTMM para sí mismos y para otros. Esto proporciona una manera fácil y eficiente de mantener los
informes de auditoría de pruebas de seguridad y hacer que ISECOM los certifique.

Sello de aprobación OSSTMM

Los sellos de evaluación OSSTMM están disponibles para productos, servicios y procesos de negocio. Este
sello define un estado operativo de seguridad, protección, confianza y privacidad. Los productos, servicios y
procesos evaluados con éxito llevan su sello de certificación visible y su puntuación rav. Esto permite al
comprador ver con precisión la cantidad y el tipo de cambio en la seguridad que presentan las soluciones
evaluadas.
Elimina las conjeturas en las adquisiciones y permite encontrar y comparar soluciones alternativas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
16 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Proyectos relacionados
Para probar correctamente la seguridad de cualquier cosa, primero hay que saber cómo funciona, de qué está compuesta y en
qué entorno existe. Así es como se había abordado el propio OSSTMM como un medio para comprender la mejor, más eficiente
y más exhaustiva forma de probar la seguridad. Por lo tanto, necesitábamos comprender la seguridad. Esta investigación en
busca de la "partícula de seguridad" ha dado lugar a la aplicación y el diseño de más proyectos más allá del OSSTMM.

Si bien no todas las aplicaciones del OSSTMM en áreas fuera de las pruebas de seguridad son dignas de ser proyectos.
Sin embargo, algunos dan testimonio del hecho de que hoy en día solo estamos limitados por nuestra propia imaginación.
El OSSTMM se ha convertido en una herramienta con la que podemos adoptar nuevos enfoques para muchos nuevos medios
de protección.

Evaluación de riesgos del análisis del código fuente (SCARE)

El proyecto SCARE aplica los valores rav de OSSTMM al análisis del código fuente. El resultado
final es un valor SCARE que es la cantidad de código fuente con operaciones sin protección.
[Link]

Metodología de seguridad para el hogar y guía de vacaciones (HSM)

El proyecto HSM aplica los principios de OSSTMM, el proceso de cuatro puntos, las métricas de
confianza y el proceso de análisis para proteger y fortalecer una vivienda. El resultado final es crear
una vivienda más segura y protegida sin restringir las libertades de los ocupantes.
[Link]

Escuela secundaria de hackers (HHS)

HHS es un programa de concienciación sobre seguridad diferente para adolescentes. Utiliza la

investigación de análisis y pruebas OSSTMM para brindar conocimientos y habilidades a través de
lecciones prácticas y acceso a una red de prueba basada en Internet. Sin embargo, al mismo tiempo
refuerza la capacidad de ingenio y el
pensamiento crítico. [Link]

El Proyecto de Gente Mala (BPP)

El BPP es un programa de concienciación sobre seguridad y protección diferente para niños y

padres. Utiliza los criterios de OSSTMM y las métricas de confianza para crear mejores reglas para
los niños sobre seguridad y protección que se explican mediante juegos, historias y juegos de rol.
Las reglas son más fáciles de recordar y están libres de contradicciones y prejuicios culturales. Los
padres pueden visitar y contribuir a la galería de dibujos de los niños, que examina lo que los niños
piensan sobre el aspecto de una mala persona. Estos dibujos se utilizan a su vez para encontrar
nuevas formas de llegar a los niños y mejorar las reglas que se les enseñan.
[Link]

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 17
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Arquitectura de madurez de operaciones de seguridad (SOMA)

El proyecto SOMA tiene como objetivo proporcionar los procesos operativos de OSSTMM a nivel estratégico.
Este proyecto aplica RAV y Trust Metrics para determinar la madurez de la seguridad en función de lo bien
que funcionan la estrategia y las tácticas de protección y no solo de cómo deberían funcionar de acuerdo
con la política.
[Link]

Pruebas de integridad empresarial (BIT)

El proyecto BIT amplía las pruebas y análisis operativos de OSSTMM a los procesos y transacciones
comerciales, lo que aporta una nueva perspectiva estratégica a la seguridad de la conducta empresarial de
los empleados y al desarrollo de nuevos planes comerciales.
[Link]

Más inteligente, más seguro, mejor

Este proyecto proporciona las herramientas y habilidades de seguridad que las personas necesitan
todos los días para combatir el fraude, las mentiras y el engaño. Las herramientas se basan en la
investigación de OSSTMM, que se centra en evitar trucos persuasivos y técnicas de manipulación.
El proyecto es único en la forma en que utiliza grupos de apoyo para que las personas discutan
los problemas que han encontrado y trabajen juntos para
analizarlos. [Link]

Dominando la confianza

Este proyecto tiene como objetivo crear materiales para seminarios y libros de trabajo sobre cómo utilizar las
Métricas de Confianza OSSTMM en la vida cotidiana para tomar mejores decisiones. Este proyecto aborda
por qué nuestros instintos viscerales fallan y cómo podemos solucionarlos y mejorarlos. Ya sea en las
relaciones comerciales o privadas, saber en quién puedes confiar y en qué medida es más que protegerte
de ser lastimado: es una ventaja competitiva.
[Link]

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
18 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

La seguridad no tiene por qué durar para siempre;

sólo más que cualquier otra cosa que pueda notar
su desaparición.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 19
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 1 – Lo que necesitas saber

Este manual trata sobre la seguridad operativa (OpSec), es decir, sobre cómo medir el funcionamiento de la seguridad. Si bien esto puede parecer
obvio: “¿Acaso no todos hacemos seguridad operativa?”, es una distinción que debe hacerse porque la mayoría de los objetivos de cumplimiento
no requieren más que adaptar los procesos y las configuraciones a un conjunto de prácticas recomendadas. Este manual y el proceso de prueba
que describe requieren que no se hagan suposiciones de que una solución, un producto o un proceso de seguridad se comportará durante el uso
operativo como se ha diseñado para hacerlo en el papel. En términos más simples, esta metodología le dirá si lo que tiene hace lo que usted
quiere que haga y no solo lo que se le dijo que hiciera.

OpSec es una combinación de separación y controles. En el marco de OpSec, para que una amenaza sea efectiva, debe interactuar directa o
indirectamente con el activo. Separar la amenaza del activo es evitar una posible interacción. Por lo tanto, es posible tener una seguridad total
(100 %) si la amenaza y el activo están completamente separados entre sí. De lo contrario, lo que se tiene es la seguridad del activo, que se
proporciona mediante los controles que se aplican al activo o el grado en que se reduce el impacto de la amenaza.

Por ejemplo, para estar a salvo de los rayos, uno debe trasladarse a un lugar donde los rayos no puedan llegar, como en lo profundo de una
montaña. Las amenazas que no se pueden separar de los activos deben hacerse más seguras para que sus interacciones y los efectos de las
interacciones causen poco o ningún daño. En este mismo ejemplo, para estar a salvo de los rayos, uno debe permanecer en el interior durante
las tormentas, evitar las ventanas u otras aberturas y utilizar pararrayos en el techo. Por lo tanto, en el contexto de la seguridad operativa,
llamamos seguridad a la separación de un activo y una amenaza, y seguridad al control de una amenaza o sus efectos.

Para garantizar una verdadera seguridad de los activos, se requieren distintos tipos de controles. Sin embargo, los controles también pueden
aumentar el número de interacciones dentro del ámbito de aplicación, lo que significa que más controles no es necesariamente mejor. Por lo
tanto, se recomienda utilizar distintos tipos de controles operativos en lugar de sólo más controles. Más controles del mismo tipo de controles
operativos no proporcionan una defensa en profundidad, ya que el acceso a través de uno de ellos suele ser el acceso a través de todos los
controles de ese tipo. Por eso es tan importante poder clasificar los controles según lo que hacen en las operaciones para estar seguros del nivel
de protección que proporcionan.

Para entender mejor cómo puede funcionar OpSec en un entorno operativo, es necesario reducirlo 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 ese vector, la dirección de
la interacción. El enfoque reduccionista nos lleva a la necesidad de ver la seguridad y la protección de una nueva manera, una que les permita
existir independientemente del riesgo y que sean totalmente capaces de crear la seguridad perfecta, el equilibrio exacto de seguridad y controles
con operaciones y limitaciones. Sin embargo, ver la seguridad de una nueva manera también requiere una nueva terminología.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
20 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Término Definición

La falta de separaciones específicas y controles funcionales que existen para ese vector.
Superficie de ataque

Subámbito de un vector creado con el fin de abordar de forma organizada las pruebas de seguridad de
un ámbito complejo. Se basa en el paradigma de diseño de algoritmos de divide y vencerás que consiste
en descomponer recursivamente un problema en dos o más subproblemas del mismo tipo (o relacionados),
Vector de ataque
hasta que estos se vuelvan lo suficientemente simples como para ser resueltos directamente.

Controles de reducción de impacto y 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. Por ejemplo, asegurar la tienda en caso de incendio es un control que no evita que
el inventario se dañe o sea robado, pero que pagará un valor equivalente por la pérdida. Se han definido
diez controles. Los primeros cinco controles son de Clase A y de interacciones de control. Los cinco
Controles
controles de Clase B son relevantes para los procedimientos de control. Consulte la sección 1.2 a
continuación para obtener más información sobre los controles.

Este es el estado actual de los límites percibidos y conocidos para los canales, las operaciones y los
controles, tal como se verificó en la auditoría. Los tipos de limitaciones se clasifican según la forma en
que interactúan con la seguridad y la protección a nivel operativo. Por lo tanto, no se utilizan opiniones
sobre el impacto, la disponibilidad en la práctica, la dificultad de ejecución y la complejidad para
clasificarlas. Por ejemplo, una cerradura vieja y oxidada que se utiliza para asegurar las puertas de la
tienda a la hora de cierre tiene una limitación de seguridad impuesta que proporciona una fracción de la
fuerza de protección necesaria para retrasar o resistir un ataque. Determinar que la cerradura es vieja y
Limitaciones
débil mediante una verificación visual se conoce como una limitación identificada.

Determinar que es viejo y débil al romperlo utilizando 100 kg de fuerza cuando una disuasión exitosa
requiere 1000 kg de fuerza muestra una limitación verificada.
Una de sus limitaciones se clasifica entonces en función de la consecuencia de la acción operacional,
que en este caso es el Acceso.

Las operaciones son la falta de seguridad que se debe tener para ser interactivo, útil, público, abierto o
disponible. Por ejemplo, limitar la forma en que una persona compra bienes o servicios en una tienda a
Operaciones través de un canal en particular, como una puerta para entrar y salir, es un método de seguridad dentro
de las operaciones de la tienda.

El equilibrio exacto entre seguridad y controles con operaciones y limitaciones.

Seguridad perfecta

Todos los puntos interactivos, operaciones, que se clasifican como Visibilidad, Acceso o Confianza.
Porosidad

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 21
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Término Definición

Una forma de protección en la que se controlan la amenaza o sus efectos. Para que haya seguridad,
se deben implementar controles que aseguren que la amenaza en sí o sus efectos se minimicen a un
nivel aceptable por parte del propietario o administrador de los activos. Este manual trata la seguridad
Seguridad
como “controles”, que son los medios para mitigar los ataques en un entorno operativo o en vivo.

Una forma de protección en la que se crea una separación entre los activos y la amenaza. Esto
incluye, entre otras cosas, la eliminación del activo o de la amenaza. Para que sea seguro, el activo
se elimina de la amenaza o la amenaza se elimina del activo. Este manual cubre la seguridad desde
Seguridad una perspectiva operativa, verificando las medidas de seguridad en un entorno operativo o en vivo.

El rav es una medida de escala de la superficie de ataque, la cantidad de interacciones no controladas

con un objetivo, que se calcula mediante el equilibrio cuantitativo entre porosidad, limitaciones y
controles. En esta escala, 100 rav (que a veces también se muestra como 100 % rav) es un equilibrio
perfecto y cualquier valor menor significa que hay muy pocos controles y, por lo tanto, una mayor
Rav superficie de ataque.
Más de 100 RAV muestran más controles de los necesarios, lo que en sí mismo puede ser un
problema, ya que los controles a menudo agregan interacciones dentro de un alcance, así como
complejidad y problemas de mantenimiento.

Eso dentro del alcance que estás atacando, el cual está compuesto por el activo y cualquier protección
Objetivo que el activo pueda tener.

La dirección de una interacción.

Vector

Una clasificación de limitación en la que una persona o un proceso puede acceder, denegar el acceso
a otros u ocultarse a sí mismo o a activos dentro del alcance. Hay más detalles y ejemplos disponibles
Vulnerabilidad
en la tabla de limitaciones en 4.2.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
22 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

1.1 Seguridad
La seguridad es una función de separación. La separación entre un activo y cualquier amenaza existe o no. Hay tres formas lógicas y
proactivas de crear esta separación:

1. Mueva el activo para crear una barrera física o lógica entre él y las amenazas.
2. Cambiar la amenaza a un estado inofensivo.
3. Destruir la amenaza.

Al analizar el estado de la seguridad podemos ver dónde existe la posibilidad de interacción y dónde no. Sabemos que algunas, todas o
incluso ninguna de estas interacciones pueden ser necesarias para las operaciones. Como las puertas de entrada a 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 como las no deseadas, como los robos.
Dado que el evaluador de seguridad puede no saber en este momento la justificación comercial de todos estos puntos interactivos, nos
referimos a esto como porosidad. La porosidad reduce la separación entre una amenaza y un acceso. Se clasifica además como uno de los
tres elementos, visibilidad, acceso o confianza, que describe su función en las operaciones, lo que permite además que se agreguen los
controles adecuados durante la fase de remediación para mejorar la protección.

Por lo tanto, considere que si la separación existe de manera adecuada de las amenazas, como un hombre dentro de una montaña que evita
un rayo, entonces esa seguridad es verdadera; es del 100%. Por cada agujero en la montaña, por cada medio por el cual un rayo puede
causar daño a ese hombre, la porosidad aumenta como un Acceso. Cada punto de interacción reduce la seguridad por debajo del 100%,
donde el 100% representa una separación completa. Por lo tanto, el aumento de la porosidad es la disminución de la seguridad y cada poro
es una Visibilidad, un Acceso o una Confianza.

Término Definición

La ciencia policial considera la “oportunidad” como uno de los tres elementos que incentivan el robo,
junto con el “beneficio” y la “disminución del riesgo”. La visibilidad es un medio para calcular la
oportunidad. Es el activo de cada objetivo que se sabe que existe dentro del alcance. Los activos
Visibilidad
desconocidos solo corren peligro de ser descubiertos, en lugar de estar en peligro de ser atacados.

Dado que la seguridad es la separación entre una amenaza y un activo, la capacidad de interactuar
directamente con el activo implica acceder a él. El acceso se calcula en función de la cantidad de
lugares diferentes en los que puede producirse la interacción. Eliminar la interacción directa con un
Acceso
activo reducirá a la mitad la cantidad de formas en las que puede arrebatárselo.

Medimos la confianza como parte de OpSec como cada relación que existe donde el objetivo acepta
la interacción libremente de otro objetivo dentro del alcance.
Si bien la confianza puede ser un agujero de seguridad, es un sustituto común de la autenticación y
un medio para evaluar las relaciones de manera racional y repetible. Por lo tanto, se fomenta el uso
Confianza
de métricas de confianza que permitan medir la validez de una confianza calculando el grado de
fiabilidad de la misma.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 23
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

1.2 Controles
Cuando la amenaza está por todas partes, los controles son los que garantizan la seguridad en las operaciones. Los controles son un medio para
influir en el impacto de las amenazas y sus efectos cuando se requiere interacción.

El hecho de que no puedas controlarlo directamente no significa

que no se pueda controlar. Si controlas el entorno, controlas todo lo que
hay en él.

Si bien existen muchos nombres y tipos diferentes de controles operativos, solo hay 12 categorías principales que contienen todos los controles
posibles. Sin embargo, dos de las categorías, Identificación, la verificación de una identidad existente, y Autorización, la concesión de permisos
de la autoridad competente, no pueden funcionar solas en un entorno operativo y, en cambio, en las operaciones, se combinan y se agregan al
control de Autenticación. Esto deja a OpSec con diez posibles controles que un analista deberá identificar y comprender.

La razón por la que la identificación y la autorización no se pueden expresar de manera operativa es porque ninguna de las dos puede transferirse.
La identidad existe tal como es y, si bien los medios de identificación, como proceso, son un aspecto operativo, el proceso real consiste en
verificar una identidad proporcionada previamente a partir de otra fuente o de la última en una cadena de fuentes. Incluso en circunstancias en las
que una agencia gubernamental cambia oficialmente la identidad de una persona, sigue siendo la misma persona desde las marcas de
identificación hasta su ADN y solo cambia su documentación. Por lo tanto, un proceso de seguridad puede intentar identificar a alguien verificando
su identidad, pero en este caso no se concede ni se proporciona nada. No hay una verdadera "concesión" de identidad, así como no puede haber
un verdadero "robo" de identidad. Además, la identidad es una colección de pensamientos, emociones, experiencias, relaciones e intenciones, así
como forma física o marcas. Eres quien eres porque existes, no porque alguien te lo haya concedido. Un duplicado o clon perfecto de ti sigue sin
ser tú porque desde el origen tus experiencias serán diferentes. Si bien esto puede sonar más a filosofía que a seguridad, es muy importante que
los analistas lo entiendan. Los procesos de identificación solo verifican con un proceso de identificación anterior. Si ese proceso ha sido dañado
o puede eludirse, entonces toda la base de seguridad que requiere una identificación adecuada está defectuosa.

La autorización, al igual que la identificación, es otro control de operaciones que no se puede transferir. Es el control para otorgar permisos. Un
empleado autorizado para ingresar a una habitación puede mantener la puerta abierta para que otra persona ingrese. Esto no autoriza a la nueva
persona. La autorización no se transfirió. Esta nueva persona está invadiendo un área restringida y el empleado que mantuvo abierta la puerta en
realidad formaba parte de una limitación en el proceso de autenticación para otorgar acceso.

Otra propiedad de la Autorización es que requiere identificación para funcionar. Sin identificación, la autorización es un “permitir todo” general sin
siquiera saber qué es todo. Sin embargo, en las operaciones esto es en sí mismo una paradoja porque autorizar todo sin escrutinio significa que
no hay autorización. Por lo tanto, al no autorizar no se utiliza la autorización.

El control de autenticación combina la identificación y la autorización para mapear el acceso. El proceso consiste simplemente en saber quién (o
qué) es y qué, dónde, cuándo y cómo puede acceder antes de que se le conceda el acceso. Debido a que la autenticación es un control de
interactividad, es uno de los cinco controles de Clase A, también conocidos como "Controles interactivos".

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
24 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Controles interactivos

Los controles interactivos de clase A constituyen exactamente la mitad de todos los controles operativos. Estos controles influyen
directamente en las interacciones de visibilidad, acceso o confianza. Las categorías de clase A son autenticación, indemnización,
subyugación, continuidad y resiliencia.

1. La autenticación es un control a través del desafío de credenciales basadas en la identificación y

autorización.
2. La indemnización es un control mediante un contrato entre el propietario del activo y la parte que interactúa. Este contrato
puede adoptar la forma de una advertencia visible como preludio de una acción legal si no se siguen las normas publicadas,
una protección legislativa pública específica o con un proveedor de seguros externo en caso de daños, como una compañía
de seguros.
3. La resiliencia es un control sobre todas las interacciones para mantener la protección de los activos en caso de
corrupción o fracaso.
4. La subyugación es un control que garantiza que las interacciones se produzcan únicamente de acuerdo con procesos definidos. El
propietario del activo define cómo se produce la interacción, lo que elimina la libertad de elección, pero también la responsabilidad de
la parte que interactúa.
5. La continuidad es un control sobre todas las interacciones para mantener la interactividad con los activos en caso de
corrupción o fracaso.

Controles de procesos

La otra mitad de los controles de operación son los controles de Clase B, que se utilizan para crear procesos defensivos.
Estos controles no influyen directamente en las interacciones, sino que protegen los activos una vez que se presenta la amenaza.
También se conocen como controles de proceso e incluyen no repudio, confidencialidad, privacidad, integridad y alarma.

6. El no repudio es un control que impide que la parte interactuante niegue su papel en cualquier
interactividad.
7. La confidencialidad es un control para asegurar que un activo exhibido o intercambiado entre personas que interactúan
Las partes no pueden ser conocidas fuera de ellas.
8. La privacidad es un control para garantizar los medios mediante los cuales se accede, se muestra o se intercambia un activo.
entre partes no puede ser conocido fuera de esas partes.
9. La integridad es un control para garantizar que las partes que interactúan sepan cuándo se han utilizado los activos y procesos.
cambió.
10. La alarma es un control para notificar que una interacción está ocurriendo o ha ocurrido.

Si bien los controles tienen una influencia positiva en OpSec, ya que minimizan la superficie de ataque, pueden por sí mismos
aumentarla si tienen limitaciones. Muchas veces, este efecto no se nota y, si los mecanismos de protección no se prueban a fondo
para comprobar cómo funcionan en todas las condiciones, esto puede no resultar evidente. Por lo tanto, el uso de controles debe
garantizar que no insinúen nuevos vectores de ataque hacia el objetivo. Por lo tanto, a veces es mejor no tener controles que tener
malos controles.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 25
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

El ejemplo de la cerradura defectuosa

¿Es mejor tener una cerradura defectuosa en una puerta que no tener ninguna? Un analista debe utilizar el pensamiento crítico sobre
seguridad, una forma de habilidades lógicas para superar el sentido innato de seguridad que tenemos y entender por qué los controles
deficientes pueden aumentar la superficie de ataque a un nivel mayor que la ausencia total de control.

La idea común es que agregar controles con limitaciones es mejor que no tener ninguno. ¿No es mejor tener una cerradura deficiente
que no tener ninguna? Después de todo, como sugiere la sabiduría convencional, una sabiduría que nace de la emoción más que de
la verificación, un poco de “seguridad” es mejor que nada. Por eso la analogía de la cerradura es un buen ejemplo y, de hecho,
responde mejor a la pregunta que cualquier otra, porque muestra muy bien cómo malinterpretamos los controles que son tan comunes
a nuestro alrededor.

Pregúntele a cualquiera que haya tenido que forzar una puerta cerrada y que haya dado una patada o un golpe para abrirla. La
respuesta es diferente si se trata de una cerradura con llave que se abre desde el exterior o de una cerradura con pestillo que se abre
desde el interior. Hay una razón para esto.

Cuando se añade una cerradura (que se considera el control de autenticación) a una puerta, es necesario hacer un hueco en la puerta
sólida y pesada y colocar la cerradura. Esto crea una limitación, un punto débil en la puerta. Lo mismo ocurre con la adición de una
manija. Las puertas sin manijas ni cerraduras internas no tienen esta limitación. Sin embargo, requieren que la puerta se abra desde
adentro de otra manera. Por lo tanto, para abrir una puerta con ese tipo de cerradura, se patea o golpea la puerta en la manija o el
mecanismo de la cerradura.

Si hay una cerradura con pestillo, esa limitación no existe porque la puerta permanece sólida. Esas puertas a menudo requieren una
fuerza para abrirse que romperá antes la puerta que la cerradura. Las puertas hechas para soportar altas presiones tienen los pestillos
en el exterior y el mecanismo de apertura en el centro de la puerta como un pequeño orificio, como las puertas de un barco o
submarino, para evitar las debilidades de ahuecar parte de la puerta.

Ahora, para responder de forma más directa a la pregunta: ¿es mejor tener una cerradura débil que no tener cerradura? Esta pregunta
se refiere a una puerta con lo mínimo, una cerradura de llave barata o sencilla (autenticación) que pueda ser burlada por alguien que
quiera entrar. Por lo tanto, si sabemos que la autenticación es débil, entonces sabemos que alguien puede entrar y, lo que es peor,
puede hacerlo sin dañar la cerradura o la puerta, lo que significa que es posible que no tengamos conocimiento de la intrusión. Si
piensas, bueno, eso está bien porque nuestro problema no son los verdaderos delincuentes, sino los oportunistas que buscan la fruta
al alcance de la mano, entonces estás tomando una decisión de riesgo y eso no afecta a tu superficie de ataque, que está formada
por lo que tienes y no por lo que quieres. Además, el hecho de tener una cerradura implica, sobre todo para los oportunistas, que hay
algo de valor en el interior.

Si agregas un control, cualquier control, aumentas la superficie de ataque de cualquier cosa. Si ese nuevo elemento que agregas
genera un nuevo vector de ataque, entonces probablemente te convenga prescindir de él. En algunos casos, el nuevo vector de
ataque es menor que la cantidad real de seguridad que te brinda el nuevo control.
Sin embargo, un buen control no tendrá limitaciones y puede reducir la superficie de ataque.

Una cerradura en una puerta no debe ser fácil de forzar ni debe aumentar significativamente la superficie de ataque. Una cerradura
de este tipo requiere fuerza para abrirse y eso agrega otro control al que proporciona la cerradura: la alarma. Una cerradura rota
también es una buena notificación de un robo.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
26 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

1.3 Objetivos de la garantía de la información

Para facilitar la comprensión de los controles de operación, se pueden comparar con los tres objetivos de garantía de la información:
confidencialidad, disponibilidad e integridad. Estos objetivos se utilizan en toda la industria de la seguridad de la información, aunque
debido en parte a su simplificación excesiva, su finalidad es más la de gestionarla que la de crearla o probarla. La correlación no es
perfecta 1:1, pero es suficiente para demostrar los controles de operación de acuerdo con la tríada básica de la CIA. Debido a que las
definiciones utilizadas para la CIA son muy amplias, las correlaciones parecen ser las siguientes:

Objetivos de la garantía de la información Controles de operación

Confidencialidad
Privacidad
Confidencialidad
Autenticación
Resiliencia

Integridad
No repudio
Integridad
Subyugación

Continuidad
Indemnización
Disponibilidad
Alarma

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 27
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

1.4 Limitaciones
La incapacidad de los mecanismos de protección para funcionar son sus limitaciones. Por lo tanto, el estado de seguridad en relación con las
fallas y restricciones conocidas dentro del ámbito de operaciones se denomina Limitación. Son los agujeros, vulnerabilidades, debilidades y
problemas para mantener esa separación entre un activo y una amenaza o para asegurar que los controles sigan funcionando correctamente.

Las limitaciones se han clasificado en cinco categorías y estas categorías definen el tipo de vulnerabilidad, error, configuración incorrecta o
deficiencia por operación. Esto es diferente de cómo se clasifican las limitaciones en la mayoría de los marcos de gestión de seguridad y las
mejores prácticas, por lo que utilizamos el término Limitación en lugar de los términos más comunes para evitar confusiones. Esos otros términos
se refieren a vulnerabilidades o deficiencias porque se clasifican por el tipo de ataque o, a menudo, la amenaza en sí. Hay un enfoque en el riesgo
del ataque. Sin embargo, para eliminar el sesgo de las métricas de seguridad y proporcionar una evaluación más justa, eliminamos el uso del
riesgo. El riesgo en sí mismo está muy sesgado y, a menudo, es muy variable según el entorno, los activos, las amenazas y muchos otros
factores. Por lo tanto, en OpSec, utilizamos el término Limitaciones para expresar la diferencia de categorizar cómo falla OpSec en lugar de por el
tipo de amenaza.

Dado que no se puede conocer la cantidad y el tipo de amenazas, tiene más sentido comprender un mecanismo de seguridad o protección en
función de cuándo fallará. Esto permite al analista probar las condiciones en las que ya no mantendrá el nivel necesario de protección. Solo
cuando tengamos este conocimiento podremos comenzar a jugar el juego de hipótesis de amenazas y riesgos. Luego también podremos invertir
en el tipo adecuado de separación o controles necesarios y crear planes precisos para desastres y contingencias.

Aunque las Limitaciones se clasifican aquí del 1 al 5, esto no significa que estén en un formato jerárquico de gravedad. Más bien, están numeradas
solo para diferenciarlas tanto para la planificación operativa como para las métricas. Esto también significa que es posible que se pueda aplicar
más de un tipo de Limitación a un solo problema. Además, el peso (valor) de una Limitación en particular se basa en los demás controles y áreas
interactivas disponibles y correspondientes al alcance; no puede haber una jerarquía específica ya que el valor de cada una es específico para
las medidas de protección en el alcance que se está auditando.

Dentro del OSSTMM las cinco clasificaciones de Limitaciones son:

1. Una vulnerabilidad es el defecto o error que: (a) niega el acceso a los activos a personas o procesos autorizados, (b) permite el acceso
privilegiado a los activos a personas o procesos no autorizados, o (c) permite que personas o procesos no autorizados oculten activos
o a sí mismos dentro del alcance.
2. La debilidad es el defecto o error que altera, reduce, abusa o anula específicamente los efectos de los cinco controles de interactividad:
autenticación, indemnización, resiliencia, subyugación y continuidad.
3. La preocupación es la falla o error que interrumpe, reduce, abusa o anula los efectos del flujo o ejecución de los cinco controles del
proceso: no repudio, confidencialidad, privacidad, integridad y alarma.

4. La exposición es una acción, falla o error injustificable que proporciona visibilidad directa o indirecta de objetivos o
activos dentro del canal de alcance elegido.
5. Anomalía es cualquier elemento no identificable o desconocido que no ha sido controlado y no puede ser
contabilizados en las operaciones normales.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
28 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Mapeo de limitaciones
Para comprender mejor cómo las limitaciones encajan en el marco de OpSec, se puede ver su relación con la seguridad y la
protección:

Categoría Seguridad operacional

Limitaciones

Visibilidad Exposición
Operaciones Acceso Vulnerabilidad
Confianza

Autenticación Debilidad
Indemnización
Clase A ­
Resiliencia
Interactivo
Subyugación
Continuidad
Controles
No repudio Inquietud
Confidencialidad
Clase B ­
Privacidad
Proceso
Integridad
Alarma
Anomalías

Este mapeo muestra cómo las limitaciones afectan la seguridad y cómo se determinan sus valores.

Una vulnerabilidad es un defecto o error que: (a) niega el acceso a los activos a personas o procesos autorizados (b) permite el acceso
privilegiado a los activos a personas o procesos no autorizados, o (c) permite que personas o procesos no autorizados oculten activos o a sí
mismos dentro del alcance. Esto significa que la vulnerabilidad debe asignarse a todos los puntos de interacción u OpSec y, dado que la
vulnerabilidad puede eludir o anular los controles, estos también deben considerarse en la ponderación de la vulnerabilidad.

Una debilidad es una falla en los controles de clase A, pero puede afectar a OpSec; por lo tanto, se asigna a todos los parámetros de OpSec
y también a esta clase interactiva de controles.

Una preocupación solo se puede encontrar en los controles de clase B, pero puede afectar a OpSec; por lo tanto, se asigna a todos los
parámetros de OpSec y también a esta clase de proceso de controles.

Una exposición nos brinda información sobre la interacción con un objetivo y, por lo tanto, se asigna directamente a la visibilidad y el acceso.
Esta información también puede ayudar a un atacante a navegar por algunos o todos los controles, por lo que la exposición también se
asigna a ambas clases de control. Finalmente, la exposición no tiene valor en sí misma a menos que haya una forma de usar esta información
para explotar el activo o un control, por lo que las vulnerabilidades, las debilidades y las preocupaciones también desempeñan un papel en la
ponderación del valor de la exposición.

Una anomalía es cualquier elemento no identificable o desconocido que no ha sido controlado y no puede tenerse en cuenta en las operaciones
normales. El hecho de que no haya sido controlado y no pueda tenerse en cuenta significa un vínculo directo con la confianza. Esta limitación
también puede causar anomalías en la forma en que funcionan los controles y, por lo tanto, también se incluyen en la ponderación. Finalmente,
al igual que con una exposición, una anomalía por sí sola no afecta a OpSec sin la existencia de una vulnerabilidad, debilidad o preocupación
que pueda explotar este comportamiento inusual.

Además, más de una categoría puede aplicarse a una limitación cuando la falla viola OpSec en más de

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 29
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

un lugar. Por ejemplo, un control de autenticación que permite a una persona secuestrar las credenciales de otra persona
tiene una debilidad y, si las credenciales permiten el acceso, también tiene una vulnerabilidad.

En otro ejemplo, un control de autenticación utiliza una lista común de nombres correspondientes a direcciones de correo
electrónico. Cada dirección que se pueda encontrar o adivinar y utilizar como inicio de sesión es una exposición, mientras
que el control en sí tiene una debilidad por su incapacidad para identificar al usuario correcto del mecanismo de autenticación
del inicio de sesión. Si alguna de esas credenciales permite el acceso, también lo incluimos como una vulnerabilidad.

Justificación de las limitaciones

El concepto de que las limitaciones sólo son limitaciones si no tienen justificación comercial es falso. Una limitación es una
limitación si se comporta en uno de los factores limitantes que se describen aquí. Una justificación para una limitación es una
decisión de riesgo que se cumple con algún tipo de control o simplemente con la aceptación de la limitación. Las decisiones
de riesgo que aceptan las limitaciones tal como son a menudo se reducen a: el daño que una limitación puede causar no
justifica el costo de reparar o controlar la limitación, la limitación debe permanecer de acuerdo con la legislación, los contratos
o la política, o una conclusión de que la amenaza no existe o es poco probable para esta limitación en particular. Dado que
las justificaciones de riesgo no son parte del cálculo de una superficie de ataque, todas las limitaciones descubiertas deben
contarse dentro de la superficie de ataque independientemente de si las mejores prácticas, la práctica común o la práctica
legal las denotan como no un riesgo. Si no es así, la auditoría no mostrará una representación verdadera de la seguridad
operativa del alcance.

Gestión de limitaciones
Otro concepto que debe tomarse en consideración es el de la gestión de fallas y errores en una auditoría.
Las tres formas más sencillas de gestionar las limitaciones son eliminar por completo el área problemática que proporciona
el punto interactivo, solucionarlas o aceptarlas como parte del proceso de negocios (lo que se conoce como justificación
comercial).

Una auditoría a menudo descubrirá más de un problema por objetivo. El analista debe informar las limitaciones por objetivo
y no solo cuáles son los objetivos débiles. Estas limitaciones pueden estar en las medidas de protección y los controles
mismos, lo que disminuye la seguridad operacional. Cada limitación debe evaluarse en función de lo que ocurre cuando se
invoca el problema, incluso si esa invocación es teórica o la verificación es de ejecución limitada para restringir los daños
reales. La categorización teórica, donde no se puede hacer ninguna verificación, es una pendiente resbaladiza y debe
limitarse a los casos en que la verificación reduciría la calidad de las operaciones. Luego, al categorizar los problemas, cada
limitación debe examinarse y calcularse en términos específicos de operación en sus componentes más básicos. Sin
embargo, el analista debe asegurarse de nunca informar una "falla dentro de una falla" donde las fallas comparten el mismo
componente y el mismo efecto operativo. Un ejemplo de esto sería una puerta rota que se abre con una ventana rota. La
abertura de la puerta es un acceso incluso si la ventana rota también lo es, pero ambas son para el mismo componente, la
puerta, y el mismo efecto operativo, una abertura. Un ejemplo de redes de datos sería un sistema informático que envía una
respuesta de núcleo, como un paquete ICMP T03C03 de “puerto cerrado” para un puerto en particular. Esta interacción no
se contabiliza para todos esos puertos, ya que el acceso proviene del mismo componente, el núcleo, y tiene el mismo efecto
operativo, enviando un paquete T03C03 por cada puerto consultado.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
30 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

1.5 Seguridad real

La función de los controles es controlar la porosidad de la seguridad operacional. Es como tener diez formas de controlar las amenazas que entran
por un agujero en la pared. Para cada agujero, se pueden aplicar un máximo de diez controles diferentes que llevan la seguridad hacia el 100 %
y, a veces, a más. Las limitaciones reducen la eficacia de la seguridad operacional y los controles. El resultado de una auditoría que descubre y
muestra la seguridad, los controles y las limitaciones demuestra de manera efectiva la seguridad real.

La seguridad real es un término que se utiliza para describir una instantánea de la superficie de ataque en un entorno operativo. Es una
representación logarítmica de los controles, las limitaciones y la seguridad operacional en un momento determinado. Es logarítmica porque
representa la realidad del tamaño, donde un alcance mayor tendrá una superficie de ataque mayor, incluso si matemáticamente los controles
equilibrarán la seguridad operacional. Si utilizamos esto como elementos básicos para comprender mejor cómo funciona la seguridad, la
visualización que creamos a partir de esto es el equilibrio efectivo creado entre dónde puede ocurrir un ataque, dónde están los controles para
gestionar un ataque y las limitaciones de las medidas de protección.

Otro beneficio de la representación matemática de una superficie de ataque como Seguridad Actual es que además de mostrar dónde faltan
medidas de protección, también puede mostrar lo contrario. Dado que es posible tener más controles de los que se necesitan, esto se puede
representar matemáticamente como más del 100% de RAV. Si bien una evaluación de riesgos puede hacer que este punto parezca imposible, la
representación matemática es útil para mostrar el desperdicio. Se puede utilizar para demostrar cuándo se está gastando dinero de más en los
tipos de controles incorrectos o en controles redundantes.

1.6 Cumplimiento
El cumplimiento normativo es algo distinto de la seguridad y existe por separado de la seguridad. Es posible cumplir con las normas pero no ser
seguro, y es posible ser relativamente seguro pero no cumplir con las normas y, por lo tanto, tener poca confiabilidad.

Los proyectos de cumplimiento no son el momento de redefinir los requisitos de seguridad operacional como resultado de una prueba OSSTMM,
pero pueden ser el momento de especificar el uso de pruebas OSSTMM, de forma periódica, para cumplir con un requisito de control elaborado
como resultado de una evaluación de confianza que ha delimitado el número mínimo de controles necesarios para lograr un estado compatible
(pero no necesariamente seguro).

El gran problema del cumplimiento normativo es que requiere una gran cantidad de documentación que debe estar versionada y actualizada. Esta
documentación puede incluir procesos empresariales, descripciones, evaluaciones de confianza, evaluaciones de riesgo, pruebas de diseño
aprobadas, auditorías operativas, certificaciones, etc. Esta documentación es examinada por auditores internos y externos y debe cumplir
lógicamente con su existencia en el mundo de un estado que cumple con las normas.

Los esfuerzos más recientes en materia de cumplimiento se han basado en requisitos de corto plazo de regulaciones impuestas con requisitos de
implementación a corto plazo, lo que ha generado una gran cantidad de requisitos de recursos y costos.
Si nos damos tiempo para pensarlo, tratamos de incorporar el cumplimiento y la producción de evidencia en un proceso y gestionar este requisito
de recursos y su costo.

El cumplimiento normativo es un enfoque amplio para la aplicación de las mejores prácticas, en lo que respecta a las tecnologías de la información,
de COBIT e ITIL; una prueba OSSTMM debe proporcionar documentación que proporcione un nivel de calidad comprensible y verificable. Sin
embargo, el uso de OSSTMM está diseñado para permitir que el analista vea y comprenda la seguridad y la protección. Por lo tanto, con el uso
de esta metodología, cualquier cumplimiento normativo es, al menos, la producción de evidencia de gobernanza dentro del proceso empresarial
de seguridad.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 31
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Los hechos no surgen de los grandes saltos

del descubrimiento, sino de los pequeños y
cuidadosos pasos de la verificación.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
32 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 2 – Lo que debes hacer

¿Por dónde empezar? Las pruebas son un asunto complicado y, como ocurre con cualquier cosa complicada, hay que
abordarla en partes pequeñas y comprensibles para asegurarse de no cometer errores.

La sabiduría convencional dice que la complejidad es enemiga de la seguridad. Sin embargo, esto solo es contrario a la
naturaleza humana. Todo lo que se vuelve más complejo no es intrínsecamente inseguro. Consideremos un ordenador que
gestiona tareas complejas. El problema, tal como lo conocemos, no es que el ordenador cometa errores, confunda las tareas
u olvide completar algunas. A medida que se añaden más tareas al ordenador, este se vuelve cada vez más lento y tarda más
tiempo en completarlas todas. Sin embargo, las personas cometen errores, olvidan tareas y abandonan deliberadamente
tareas que no son importantes o necesarias en ese momento. Por lo tanto, al probar la seguridad, lo que hay que hacer es
gestionar adecuadamente cualquier complejidad. Esto se hace definiendo adecuadamente la prueba de seguridad.

2.1 Definición de una prueba de seguridad

Estos 7 pasos le llevarán al inicio de una prueba de seguridad correctamente definida.

1. Defina lo que desea proteger. Estos son los activos. Los mecanismos de protección para estos activos
son los controles que probarás para identificar limitaciones.
2. Identifique el área alrededor de los activos que incluye los mecanismos de protección y los procesos o servicios
construidos alrededor de los activos. Aquí es donde se producirá la interacción con los activos. Esta es su zona de
interacción.
3. Define todo lo que esté fuera de la zona de compromiso y que necesites para mantener tus activos operativos.
Esto puede incluir elementos que no puedas influenciar directamente, como la electricidad, los alimentos, el agua, el
aire, el suelo estable, la información, la legislación, las regulaciones y elementos con los que puedas trabajar, como la
sequedad, el calor, el frío, la claridad, los contratistas, los colegas, la marca, las asociaciones, etc. También debes
tener en cuenta lo que mantiene la infraestructura operativa, como los procesos, los protocolos y los recursos
continuos. Este es el alcance de tu prueba.
4. Defina cómo interactúa su ámbito dentro de sí mismo y con el exterior. Compartimente de forma lógica los activos dentro
del ámbito a través de la dirección de las interacciones, como de dentro a fuera, de fuera a dentro, de dentro a dentro,
del departamento A al departamento B, etc. Estos son sus vectores. Lo ideal sería que cada vector fuera una prueba
independiente para mantener la duración de cada prueba compartimentada corta antes de que se produzcan
demasiados cambios en el entorno.
5. Identificar qué equipo será necesario para cada prueba. Dentro de cada vector, pueden ocurrir interacciones en varios niveles. Estos niveles
pueden clasificarse de muchas maneras, sin embargo, aquí se han clasificado por función en cinco canales. Los canales son humanos,
físicos, inalámbricos, telecomunicaciones y redes de datos. Cada canal debe probarse por separado para cada vector.

6. Determine qué información desea obtener de la prueba. ¿Probará las interacciones con los activos o también la
respuesta de las medidas de seguridad activas? El tipo de prueba debe definirse individualmente para cada prueba,
sin embargo, existen seis tipos comunes identificados aquí como ciego, doble ciego, caja gris, doble caja gris, tándem
y reversión.
7. Asegúrese de que la prueba de seguridad que ha definido cumpla con las Reglas de participación, una guía para
garantizar el proceso para una prueba de seguridad adecuada sin crear malentendidos, conceptos erróneos o falsas
expectativas.

El resultado final será una medición de su superficie de ataque. La superficie de ataque es la parte desprotegida del alcance
de un vector definido.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 33
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

2.2 Ámbito de aplicación

El alcance es el entorno de seguridad operativo total posible para cualquier interacción con cualquier activo, que puede incluir
también los componentes físicos de las medidas de seguridad. El alcance se compone de tres clases, de las cuales hay cinco
canales: los canales de seguridad de redes de datos y telecomunicaciones de la clase COMSEC, los canales de seguridad
física y humana de la clase PHYSSEC y el canal de seguridad inalámbrica de espectro completo de la clase SPECSEC. Las
clases proceden de designaciones oficiales que se utilizan actualmente en la industria de la seguridad, el gobierno y el ejército.
Las clases se utilizan para definir un área de estudio, investigación u operación. Sin embargo, los canales son los medios
específicos de interacción con los activos. Un activo puede ser cualquier cosa que tenga valor para el propietario. Los activos
pueden ser propiedades físicas como oro, personas, planos, ordenadores portátiles, la típica señal telefónica de frecuencia de
900 MHz y dinero; o propiedad intelectual como datos personales, una relación, una marca, procesos empresariales, contraseñas
y algo que se dice a través de la señal telefónica de 900 MHz. A menudo, el alcance se extiende mucho más allá del alcance
del propietario del activo, ya que las dependencias están más allá de la capacidad del propietario del activo para proporcionarlas
de forma independiente. El alcance requiere que todas las amenazas se consideren posibles, incluso si no probables. Sin
embargo, debe quedar claro que un análisis de seguridad debe restringirse a lo que está dentro de un tipo de certeza (no debe
confundirse con el riesgo, que no es una certeza sino una probabilidad). Estas restricciones incluyen:

1. No eventos como una erupción volcánica donde no existe ningún volcán, 2. No

impacto como la luz de la luna a través de la ventana del centro de datos, o
3. De impacto global, como el impacto catastrófico de un meteorito.

Si bien una auditoría de seguridad exhaustiva requiere probar los cinco canales, en realidad las pruebas se realizan y
categorizan según la experiencia requerida del analista y el equipo requerido para la auditoría.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
34 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Canales

Clase Canal Descripción

Comprende el elemento humano de la comunicación donde la interacción

Humano es física o psicológica.

Pruebas de seguridad física en las que el canal es de naturaleza física

Seguridad física
y no electrónica. Comprende el elemento tangible de seguridad en el
(SEGURIDAD FÍSICA)
que la interacción requiere un esfuerzo físico o un transmisor de energía
Físico
para manipularlo.

Incluye todas las comunicaciones, señales y emanaciones electrónicas

que tienen lugar en el espectro electromagnético conocido. Esto incluye
Seguridad del espectro ELSEC como comunicaciones electrónicas, SIGSEC como señales y
Inalámbrico
(SEGURIDAD ESPECIFICATIVA) EMSEC, que son emanaciones no conectadas por cables.

Comprende todas las redes de telecomunicaciones, digitales o

analógicas, donde la interacción tiene lugar a través de líneas telefónicas
Telecomunicaciones
o redes similares establecidas.

Comunicaciones
Comprende todos los sistemas electrónicos y redes de datos donde la
Seguridad (COMSEC)
interacción se realiza a través de cables y líneas de red cableadas
Redes de datos establecidas.
Redes de datos

Si bien los canales y sus divisiones pueden representarse de cualquier manera, en este manual están organizados como medios reconocibles
de comunicación e interacción. Esta organización está diseñada para facilitar el proceso de prueba y, al mismo tiempo, minimizar la sobrecarga
ineficiente que suele asociarse con las metodologías estrictas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 35
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

2.3 Tipos de pruebas comunes

Estos seis tipos difieren en función de la cantidad de información que el evaluador conoce sobre los objetivos, lo que el objetivo
sabe sobre el evaluador o espera de la prueba, y la legitimidad de la prueba. Algunas pruebas pondrán a prueba la habilidad del
evaluador más que la seguridad de un objetivo.

Tenga en cuenta que, al informar sobre la auditoría, a menudo se exige identificar exactamente el tipo de auditoría realizada.
Con demasiada frecuencia, se comparan auditorías basadas en diferentes tipos de pruebas para realizar un seguimiento de las
diferencias (desviaciones) con respecto a una línea base establecida del alcance. Si un revisor o regulador externo no dispone
del tipo de prueba preciso, la auditoría en sí debe considerarse una prueba a ciegas, que es la que tiene menos méritos para una
prueba de seguridad exhaustiva.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
36 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Tipo Descripción

El analista se involucra con el objetivo sin conocimiento previo de sus defensas, activos o canales. El objetivo está
preparado para la auditoría, conociendo de antemano todos los detalles de la misma. Una auditoría a ciegas prueba
principalmente las habilidades del analista. La amplitud y profundidad de una auditoría a ciegas solo puede ser tan
1 Ciego amplia como lo permitan el conocimiento y la eficiencia aplicables del analista. En COMSEC y SPECSEC, esto a
menudo se conoce como piratería ética y en la clase PHYSSEC, generalmente se describe como juego de guerra o
juego de roles.

El analista se involucra con el objetivo sin conocimiento previo de sus defensas, activos o canales. El objetivo no es
notificado con anticipación del alcance de la auditoría, los canales probados o los vectores de prueba. Una auditoría
doble ciego prueba las habilidades del analista y la preparación del objetivo ante variables desconocidas de agitación.
La amplitud y profundidad de cualquier auditoría a ciegas solo puede ser tan amplia como lo permitan los conocimientos
2 Doble ciego
y la eficiencia aplicables del analista. Esto también se conoce como prueba de caja negra o prueba de penetración.

El analista se involucra con el objetivo con un conocimiento limitado de sus defensas y activos y un conocimiento
completo de los canales. El objetivo está preparado para la auditoría, conociendo de antemano todos los detalles de
la misma. Una auditoría de caja gris pone a prueba las habilidades del analista. La naturaleza de la prueba es la
eficiencia. La amplitud y profundidad dependen de la calidad de la información proporcionada al analista antes de la
3 Caja gris
prueba, así como del conocimiento aplicable del analista. Este tipo de prueba a menudo se conoce como prueba de
vulnerabilidad y, en la mayoría de los casos, la inicia el objetivo como una autoevaluación.

El analista se involucra con el objetivo con un conocimiento limitado de sus defensas y activos y un conocimiento
completo de los canales. Se le notifica al objetivo con anticipación el alcance y el marco temporal de la auditoría, pero
no los canales probados ni los vectores de prueba. Una auditoría de doble caja gris prueba las habilidades del analista
Doble gris y la preparación del objetivo ante variables desconocidas de agitación. La amplitud y profundidad dependen de la
4
Caja calidad de la información proporcionada al analista y al objetivo antes de la prueba, así como del conocimiento aplicable
del analista. Esto también se conoce como prueba de caja blanca .

El analista y el objetivo están preparados para la auditoría, ya que ambos conocen de antemano todos los detalles de
la misma. Una auditoría en tándem prueba la protección y los controles del objetivo. Sin embargo, no puede probar la
preparación del objetivo ante variables desconocidas de agitación. La verdadera naturaleza de la prueba es la
minuciosidad, ya que el analista tiene una visión completa de todas las pruebas y sus respuestas. La amplitud y
5 tándem profundidad dependen de la calidad de la información proporcionada al analista antes de la prueba (transparencia), así
como del conocimiento aplicable del analista. Esto a menudo se conoce como auditoría interna o prueba Crystal Box y
el analista suele ser parte del proceso de seguridad.

El analista se relaciona con el objetivo con pleno conocimiento de sus procesos y seguridad operativa, pero el objetivo
no sabe nada de qué, cómo o cuándo el analista estará probando. La verdadera naturaleza de esta prueba es auditar
la preparación del objetivo ante variables desconocidas y vectores de agitación. La amplitud y profundidad dependen
6 Inversión de la calidad de la información proporcionada al analista y del conocimiento y creatividad aplicables del analista. Esto
también se suele llamar ejercicio de equipo rojo.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 37
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

2.4 Reglas de enfrentamiento

Estas reglas definen las pautas operativas de las prácticas aceptables en la comercialización y venta de pruebas, la realización de trabajos
de pruebas y el manejo de los resultados de los trabajos de prueba.

A. Ventas y marketing
1. No se puede utilizar el miedo, la incertidumbre, la duda ni el engaño en presentaciones de ventas o marketing, sitios web, materiales
de apoyo, informes ni en debates sobre pruebas de seguridad con el fin de vender o proporcionar pruebas de seguridad. Esto
incluye, entre otras cosas, destacar delitos, hechos, perfiles criminales o de piratas informáticos glorificados y estadísticas para
motivar las ventas.
2. Queda prohibido ofrecer servicios gratuitos en caso de no lograr penetrar el objetivo.
3. Se prohíben los concursos públicos de piratería, hackeo y violación de derechos de autor para promover la garantía de seguridad para
las ventas o la comercialización de pruebas de seguridad o productos de seguridad.
4. Solo se permite nombrar a clientes pasados o presentes en las actividades de marketing o ventas para clientes potenciales si el trabajo
para el cliente fue específicamente el mismo que se comercializa o vende y el cliente nombrado ha proporcionado permiso por
escrito para hacerlo.
5. Se exige que los clientes reciban información veraz y objetiva sobre sus medidas de seguridad. La ignorancia no es excusa para una
asesoría deshonesta.

B. Evaluación / Estimación de entrega

6. Realizar pruebas de seguridad contra cualquier ámbito sin el permiso explícito por escrito del objetivo.
Está estrictamente prohibido al propietario o autoridad competente.
7. La prueba de seguridad de sistemas, ubicaciones y procesos obviamente altamente inseguros e inestables es
prohibido hasta que se haya establecido la infraestructura de seguridad adecuada.

C. Contratos y Negociaciones
8. Con o sin un contrato de Acuerdo de Confidencialidad, el Analista de Seguridad está obligado a garantizar la confidencialidad y no
divulgación de la información del cliente y los resultados de las pruebas.
9. Los contratos deben limitar la responsabilidad al costo del trabajo, a menos que se haya demostrado una actividad maliciosa.
10. Los contratos deben explicar claramente los límites y peligros de la prueba de seguridad como parte de la declaración de
trabajar.

11. En el caso de pruebas remotas, el contrato deberá incluir el origen de los Analistas por domicilio,
número de teléfono o dirección IP.
12. El cliente debe proporcionar una declaración firmada que otorgue permiso para realizar pruebas eximiendo a los analistas de invadir
el alcance y de la responsabilidad por daños y perjuicios hasta el costo del servicio de auditoría, con la excepción de que se haya
demostrado una actividad maliciosa.
13. Los contratos deben contener nombres y números de teléfono de contactos de emergencia.
14. El contrato debe incluir permisos claros y específicos para las pruebas que impliquen fallas de supervivencia, negación
de servicio, pruebas de procesos e ingeniería social.
15. Los contratos deben contener el proceso para futuros cambios en el contrato y la declaración de trabajo (SOW).
16. Los contratos deben contener conflictos de intereses verificados para una prueba de seguridad factual y un informe.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
38 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

D. Definición del alcance

17. El alcance debe definirse claramente contractualmente antes de verificar los servicios vulnerables.
18. La auditoría debe explicar claramente los límites de cualquier prueba de seguridad según el alcance.

E. Plan de prueba

19. El plan de pruebas no podrá contener planes, procesos, técnicas o procedimientos que estén fuera del
Área de especialización o nivel de competencia del Analista.

F. Proceso de prueba

20. El Analista debe respetar y mantener la seguridad, la salud, el bienestar y la privacidad del público tanto dentro como fuera del
ámbito.
21. El analista debe operar siempre dentro de la ley de la(s) ubicación(es) física(s) de los objetivos, además
a las reglas o leyes que rigen la ubicación de la prueba del analista.
22. Para evitar aumentos temporales de la seguridad durante la prueba, notifique únicamente a las personas clave sobre la prueba.
El criterio del cliente es el que determina quiénes son las personas clave; sin embargo, se supone que serán los guardianes de
la información y las políticas, los administradores de los procesos de seguridad, el personal de respuesta a incidentes y el
personal de operaciones de seguridad.
23. Si es necesario para realizar pruebas privilegiadas, el cliente debe proporcionar dos tokens de acceso separados, ya sean
contraseñas, certificados, números de identificación seguros, credenciales, etc., y deben ser típicos de los usuarios de los
privilegios que se están probando en lugar de accesos especialmente vacíos o seguros.
24. Cuando las pruebas incluyen privilegios conocidos, el analista primero debe realizar la prueba sin privilegios (como en un
entorno de caja negra) antes de volver a probar con privilegios.
25. Los analistas deben conocer sus herramientas, de dónde provienen, cómo funcionan y probarlas en un área de prueba restringida
antes de usarlas en la organización cliente.
26. La realización de pruebas que tengan como finalidad explícita comprobar la denegación de un servicio o proceso o la capacidad
de supervivencia solo se puede realizar con permiso explícito y solo en el ámbito en que no se produzcan daños fuera del ámbito
o de la comunidad en la que reside el ámbito.
27. Las pruebas que involucren personas solo podrán realizarse en aquellas identificadas en el alcance y no podrán incluir personas
privadas, clientes, socios, asociados u otras entidades externas sin el permiso por escrito de dichas entidades.

28. Las limitaciones verificadas, como infracciones descubiertas, vulnerabilidades con tasas de explotación conocidas o altas,
vulnerabilidades que se pueden explotar para un acceso completo, no supervisado o imposible de rastrear, o que pueden poner
en peligro vidas de forma inmediata, descubiertas durante las pruebas, deben notificarse al cliente con una solución práctica tan
pronto como se encuentren.
29. Se prohíbe cualquier forma de prueba de inundación en la que un alcance se vea abrumado por una fuente más grande y más
fuerte en canales que no sean de propiedad privada.
30. El Analista no podrá dejar el alcance en una posición de menor seguridad real que la que tenía cuando
proporcionó.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 39
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

G. Informes
31. El analista debe respetar la privacidad de todas las personas y mantener su privacidad para todos los resultados.
32. Los resultados que involucren a personas no capacitadas en seguridad o personal no especializado en seguridad solo podrán comunicarse a través de
medios no identificativos o estadísticos.
33. El Analista no podrá firmar resultados de pruebas ni informes de auditoría en los que no haya participado directamente.
34. Los informes deben ser objetivos y no contener falsedades ni mala intención personal.
35. Se requieren notificaciones a los clientes siempre que el analista cambie el plan de pruebas, cambie el lugar de origen de las
pruebas, tenga resultados de baja confianza o se produzcan problemas con las pruebas. Se deben proporcionar notificaciones
antes de ejecutar pruebas nuevas, peligrosas o de alto tráfico, y se requieren actualizaciones periódicas del progreso.

36. Cuando se incluyan soluciones y recomendaciones en el informe, deberán ser válidas y

práctico.
37. Los informes deben marcar claramente todas las incógnitas y anomalías.
38. Los informes deben indicar claramente tanto las medidas de seguridad exitosas como las fallidas descubiertas y las pérdidas.
controles.
39. Los informes deben utilizar únicamente parámetros cuantitativos para medir la seguridad. Estos parámetros deben basarse en
hechos y no deben contener interpretaciones subjetivas.
40. Se debe notificar al cliente cuando se envía el informe para que espere su llegada y confirme
Recibo de entrega.
41. Todos los canales de comunicación para la entrega del informe deben ser confidenciales de extremo a extremo.
42. Los resultados e informes nunca podrán utilizarse con fines comerciales más allá de la interacción con
El cliente.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
40 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

2.5 El proceso de prueba de seguridad operativa

¿Por qué probar las operaciones? Lamentablemente, no todo funciona como está configurado. No todo el mundo se comporta como se
ha entrenado. Por lo tanto, la verdad de la configuración y el entrenamiento está en las operaciones resultantes. Por eso es necesario
probar las operaciones.

El proceso de prueba de OpSec es una prueba de eventos discretos de un sistema dinámico y estocástico. Esto significa que se
realizará una secuencia cronológica de pruebas en un sistema que cambia y no siempre da el mismo resultado para la entrada
proporcionada. El objetivo es un sistema, una colección de procesos interactuantes y codependientes que también está influenciado
por el entorno estocástico en el que existe. Ser estocástico significa que el comportamiento de los eventos en un sistema no se puede
determinar porque el siguiente estado ambiental solo puede estar determinado parcialmente, pero no completamente, por el estado
anterior. El sistema contiene una cantidad finita, pero posiblemente extremadamente grande, de variables y cada cambio en las
variables puede presentar un evento y un cambio de estado.
Dado que el entorno es estocástico, existe un elemento de aleatoriedad y no hay forma de predeterminar con certeza cómo todas las
variables afectarán el estado del sistema.

La mayor parte de lo que la gente entiende sobre OpSec proviene del aspecto defensivo, lo cual es comprensible ya que la seguridad
generalmente se considera una estrategia defensiva. Las pruebas agresivas de OpSec se relegan entonces a la misma categoría que
la explotación y la elusión del diseño o la configuración actuales. Sin embargo, el problema fundamental con esta técnica es que un
diseño o una configuración no equivalen a una operación.

En la vida nos encontramos con muchos casos en los que el funcionamiento no se ajusta a la configuración. Un ejemplo sencillo es una
descripción de trabajo típica. Es más común que la política que dicta el trabajo de una persona, también conocida como descripción de
trabajo, no refleje realmente lo que hacemos en el trabajo. Otro ejemplo es el canal de televisión. Aunque un canal esté configurado en
una frecuencia particular, no significa que recibiremos el programa transmitido en ese canal o solo ese programa.

Esta metodología de pruebas de seguridad está diseñada sobre el principio de verificar la seguridad de las operaciones. Si bien no
siempre se pueden probar los procesos y las políticas directamente, una prueba exitosa de las operaciones permitirá el análisis de
datos directos e indirectos para estudiar la brecha entre las operaciones y los procesos. Esto mostrará el tamaño de la brecha entre lo
que la gerencia espera de las operaciones a partir de los procesos que desarrolló y lo que realmente está sucediendo. En términos
más simples, el objetivo del analista es responder: "¿cómo funcionan las operaciones actuales y en qué se diferencian de cómo la
gerencia cree que funcionan?"

Un punto a destacar es la amplia investigación disponible sobre el control de cambios para procesos con el fin de limitar la cantidad de
eventos indeterminables en un sistema aleatorio. El analista a menudo intentará superar las limitaciones del control de cambios y
presentará escenarios hipotéticos que los implementadores del control de cambios pueden no haber considerado. Una comprensión
profunda del control de cambios es esencial para cualquier analista.

Por lo tanto, una prueba de seguridad operacional requiere una comprensión profunda del proceso de prueba, elegir el tipo correcto de
prueba, reconocer los canales y vectores de prueba, definir el alcance según el índice correcto y aplicar la metodología correctamente.

Curiosamente, en ningún otro lugar, excepto en las pruebas de seguridad, se considera que el proceso de eco es la prueba de facto.
Como gritar en un área cavernosa y esperar la respuesta, el proceso de eco requiere interactuar y luego monitorear las emanaciones
del objetivo en busca de indicadores de un estado particular, como seguro o inseguro, vulnerable o protegido, encendido o apagado,
izquierda o derecha. El proceso de eco es un tipo de verificación de causa y efecto. El analista establece la causa y analiza el efecto en
el objetivo. Es extraño que este sea el medio principal para probar algo tan crítico como la seguridad porque, si bien permite una prueba
muy rápida, también es muy propensa a errores, algunos de los cuales pueden ser devastadores para el objetivo. Considere que en
una prueba de seguridad que utiliza el proceso de eco, un objetivo que no responde se considera seguro. Siguiendo esa lógica, un

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 41
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

El objetivo solo necesita no responder a un tipo particular de solicitud para dar la apariencia de seguridad, pero aún
así ser completamente interactivo con otros tipos de solicitudes, lo que demuestra que no ha habido separación.

Si los hospitales utilizaran el proceso de eco para determinar la salud de un individuo, rara vez ayudaría a la gente,
pero al menos el tiempo de espera sería muy corto. Sin embargo, los hospitales, como la mayoría de las demás
industrias científicas, aplican el Proceso de Cuatro Puntos que incluye una función del proceso de eco llamada la
“interacción” como una de las cuatro pruebas. Las otras tres pruebas son: la “investigación” de lectura de emanaciones
del paciente como el pulso, la presión arterial y las ondas cerebrales; la “intervención” de condiciones operativas
cambiantes y estresantes como la homeostasis, el comportamiento, la rutina o el nivel de comodidad del paciente; y la
“inducción” de examinar el entorno y cómo puede haber afectado al objetivo, como analizar con qué ha interactuado el
paciente, qué ha tocado, comido, bebido o respirado. Sin embargo, en las pruebas de seguridad, la mayoría de las
pruebas se basan únicamente en el proceso de eco. Se pierde tanta información en estas pruebas unidimensionales
que deberíamos estar agradecidos de que la industria de la atención médica haya evolucionado más allá del método
de diagnóstico basado únicamente en “¿Me duele si hago esto?”.

El proceso de prueba de seguridad de esta metodología no recomienda el proceso de eco por sí solo para obtener
resultados confiables. Si bien el proceso de eco se puede utilizar para ciertas pruebas particulares en las que el
margen de error es pequeño y la mayor eficiencia permite dedicar tiempo a otras técnicas que requieren más tiempo,
no se recomienda para pruebas fuera de un entorno determinista. El analista debe elegir cuidadosamente cuándo y
bajo qué condiciones aplicar el proceso de eco.

Si bien existen muchos procesos de prueba, el proceso de cuatro puntos para pruebas de seguridad está diseñado
para lograr una eficiencia, precisión y minuciosidad óptimas para garantizar la validez de las pruebas y minimizar los
errores en entornos no controlados y aleatorios. Está optimizado para escenarios de prueba del mundo real fuera del
laboratorio. Si bien también utiliza agitación, se diferencia del proceso de eco en que permite determinar más de una
causa por efecto y más de un efecto por causa.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
42 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

2.6 Proceso de cuatro puntos

El proceso de cuatro puntos (4PP) desglosa una prueba desde el principio hasta la conclusión. Estas son cosas que un
grupo de pruebas experimentado ya hace. No confunda la formalidad en la disección del proceso con la formalidad del
informe. No tiene que mostrar cada paso que se está realizando, pero debe comprender cómo llegó de A a C. Es como dar
instrucciones a las personas para conducir. Les dice los pasos hacia dónde girar y la proximidad relativa a los lugares que
verán para saber que van por el camino correcto, pero no les dice todas las calles por las que conducen ni todas las señales
de tráfico que deben obedecer para llegar al final. Bueno, el 4PP son las instrucciones específicas y los medios y los
informes son en realidad los relativistas.

Interacciones dentro del proceso de 4 puntos

1. Inducción: (Z) establecer principios de verdad sobre el objetivo a partir de leyes y hechos ambientales. El analista determina principios fácticos
sobre el objetivo a partir del entorno en el que reside. Como el objetivo estará influenciado por su entorno, su comportamiento será determinable
dentro de esta influencia. Cuando el objetivo no está influenciado por su entorno, existe una anomalía que debe comprenderse.

2. Investigación: (C) investigación de las emanaciones del objetivo. El analista investiga las emanaciones del objetivo y
cualquier rastro o indicador de dichas emanaciones. Un sistema o proceso generalmente dejará una firma de su
existencia a través de interacciones con su entorno.

3. Interacción: (A/B) como las pruebas de eco, interacciones estándar y no estándar con el objetivo para desencadenar
respuestas. El analista indagará o agitará al objetivo para desencadenar respuestas para el análisis.

4. Intervención: (X/Y/Z) cambios en las interacciones de los recursos con el objetivo o entre objetivos. El analista
intervendrá con los recursos que el objetivo requiere de su entorno o de sus interacciones con otros objetivos para
comprender los extremos en los que puede seguir operando adecuadamente.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]

Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 43

Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

2.7 La trifecta
Esta metodología de pruebas de seguridad tiene una base sólida que puede parecer bastante complicada, pero en realidad es
sencilla en la práctica. Está diseñada como un diagrama de flujo; sin embargo, a diferencia del diagrama de flujo estándar, el
flujo, representado por las flechas, puede ir hacia atrás así como hacia adelante. De esta manera, está más integrado y, si bien
el principio y el final son claros, la auditoría tiene mayor flexibilidad. El analista crea un camino único a través de la metodología
en función del objetivo, el tipo de prueba, el tiempo asignado para la auditoría y los recursos aplicados a la prueba. Para una
orquesta, el compositor escribe la partitura para designar el orden y la duración de las notas, pero solo el director puede controlar
la ejecución de la interpretación. Esta metodología es como la partitura, designa las pruebas necesarias, pero el analista controla
el orden, la duración, así como la ejecución. La razón principal para requerir este nivel de flexibilidad en el OSSTMM es porque
ninguna metodología puede presumir con precisión las justificaciones para las operaciones de los gateways de canal en un
objetivo y su nivel adecuado de seguridad. Más directamente, esta metodología no puede presuponer una mejor práctica para
realizar todas las auditorías, ya que la mejor práctica se basa en una configuración específica de operaciones.

Las mejores prácticas son las mejores para algunos, generalmente para el creador de la práctica. Las operaciones dictan cómo
se deben ofrecer los servicios y esos servicios dictan los requisitos de seguridad operativa. Por lo tanto, una metodología que se
invoca de manera diferente para cada auditoría y por cada analista puede tener el mismo resultado final si el analista completa la
metodología. Por esta razón, uno de los fundamentos del OSSTMM es registrar con precisión lo que no se probó. Al comparar lo
que se probó y la profundidad de las pruebas con otras pruebas, es posible medir la seguridad operativa (OpSec) en función de
los resultados de las pruebas.

Por lo tanto, la aplicación de esta metodología permitirá cumplir el objetivo del analista de responder las tres preguntas siguientes
que conforman la Trifecta, la respuesta a las necesidades de OpSec.

1. ¿Cómo funcionan las operaciones actuales?

Las métricas derivadas se pueden aplicar para determinar las áreas problemáticas dentro del alcance
y qué problemas deben abordarse. Las métricas de esta metodología están diseñadas para mapear
los problemas de diferentes maneras a fin de mostrar si el problema es general o más específico,
como un descuido o un error.

2. ¿En qué se diferencian de cómo cree la gerencia que funcionan?

El acceso a políticas o a una evaluación de la confianza (o incluso de los riesgos) se relacionará con
las diferentes categorías de métricas. Las categorías proporcionan los valores del estado actual, con
los que se puede hacer una comparación tanto con un estado óptimo según las políticas como con
uno según las amenazas evaluadas.

3. ¿Cómo deben trabajar?

Cuando las métricas no muestran ninguna brecha entre los valores óptimos de la evaluación de
políticas o de confianza (o riesgo), pero la prueba de seguridad muestra que efectivamente existe un
problema de protección independientemente de los controles implementados en las políticas, es
posible identificar claramente un problema. A menudo, sin siquiera hacer un mapeo con las políticas,
una discrepancia entre los controles implementados y la pérdida de protección es simplemente evidente.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
44 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Combinando la Trifecta y el Proceso de 4 Puntos

La Trifecta combinada con el Proceso de Cuatro Puntos proporciona una aplicación bastante completa de esta metodología. Los pasos de esta
aplicación se pueden resumir de la siguiente manera:

1. Recopilar pasivamente datos de operaciones normales para comprender el objetivo.

2. Probar activamente las operaciones agitándolas más allá de la línea base normal.
3. Analizar los datos recibidos directamente de las operaciones probadas.
4. Analizar datos indirectos de recursos y operadores (es decir, trabajadores, programas).
5. Correlacionar y conciliar la inteligencia de los resultados de pruebas de datos directos (paso 3) e indirectos (paso 4) para determinar los
procesos de seguridad operativa.
6. Determinar y conciliar errores.
7. Derivar métricas de operaciones normales y agitadas.
8. Correlacionar y conciliar la inteligencia entre las operaciones normales y agitadas (pasos 1 y 2) para determinar el nivel óptimo de
protección y control que sería mejor implementar.
9. Asignar el estado óptimo de las operaciones (paso 8) a los procesos (paso 5).
10. Crear un análisis de brechas para determinar qué mejoras son necesarias para los procesos que rigen la protección y los controles
necesarios (paso 5) para alcanzar el estado operativo óptimo (paso 8) desde el actual.

Combinando la Trifecta y el Proceso de 4 Puntos

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 45
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

2.8 Manejo de errores

La veracidad de una prueba de seguridad no está en la suma de sus errores, sino en la contabilización de los mismos. Dado que los errores
pueden no ser culpa del analista, es mucho más razonable comprender cómo y dónde pueden existir errores dentro de una prueba que
esperar que un analista realice la prueba sin errores. Además, es el analista que intenta lo que no debería ser posible el que tiene más
probabilidades de encontrar errores; por lo tanto, calificar los errores como algo negativo desestima la práctica de realizar pruebas exhaustivas.

Tipo de error Descripción

Algo determinado como verdadero en realidad se revela falso.

La respuesta objetivo indica que un estado en particular es verdadero, aunque en realidad no lo sea.
1 falso positivo Un falso positivo ocurre a menudo cuando las expectativas o suposiciones del analista sobre lo que
indica un estado en particular no se cumplen con las condiciones del mundo real, que rara vez son
claras o concisas.

Algo determinado como falso se revela en realidad como verdadero.

La respuesta objetivo indica que un estado en particular no es verdadero, aunque en realidad el

estado sea verdadero. Un falso negativo ocurre a menudo cuando las expectativas o suposiciones
2 falsos negativos del analista sobre el objetivo no se ajustan a las condiciones del mundo real, las herramientas no
son adecuadas para la prueba, las herramientas se utilizan incorrectamente o el analista carece de
experiencia. Un falso negativo puede ser peligroso, ya que es un diagnóstico erróneo de un estado
seguro cuando no existe.

Algo responde verdadero a todo, incluso si es falso.

La respuesta del objetivo indica un estado particular como verdadero, sin embargo, el objetivo está
3 Gris Positivo diseñado para responder a cualquier causa con este estado, sea verdadero o no.
Este tipo de seguridad a través de la oscuridad puede ser peligrosa, ya que no se puede garantizar
que la ilusión funcione del mismo modo para todos los estímulos.

A todo algo le responde falso, incluso si es verdadero.

La respuesta objetivo indica que un estado particular no es verdadero, sin embargo, el objetivo está
4 Negativo Gris diseñado para responder a cualquier causa con este estado, sea verdadero o no. Este tipo de
seguridad a través de la oscuridad puede ser peligroso, ya que no se puede garantizar que la ilusión
funcione de la misma manera para todos los estímulos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
46 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Tipo de error Descripción

Algo responde como verdadero o falso pero el estado real se revela como desconocido.

La respuesta del objetivo indica un estado particular como verdadero o falso, aunque en realidad no se
puede conocer el estado. Un espectro se produce a menudo cuando el analista recibe una respuesta
de un estímulo externo que se percibe como procedente del objetivo. Un espectro puede ser intencional,
una anomalía dentro del canal o el resultado de un descuido o inexperiencia del analista. Uno de los
5 Espectro
problemas más comunes en el proceso de eco es la suposición de que la respuesta es resultado de la
prueba.

Las pruebas de causa y efecto en el mundo real no pueden lograr resultados consistentemente
confiables ya que ni la causa ni el efecto pueden aislarse adecuadamente.

Algo responde verdadero o falso dependiendo de cuándo se pregunta.

La respuesta objetivo indica un estado particular como verdadero o falso, pero solo durante un tiempo
determinado, que puede o no seguir un patrón. Si la respuesta no se puede verificar en un momento en
que el estado cambia, puede impedir que el analista comprenda el otro estado. Un analista también
puede determinar que se trata de una anomalía o un problema con el equipo de prueba, especialmente
6 Indiscreción
si el analista no calibró el equipo antes de la prueba o no realizó la logística y los controles adecuados.
Una indiscreción puede ser peligrosa, ya que puede dar lugar a un informe falso sobre el estado de la
seguridad.

La respuesta se pierde o se confunde en el ruido de la señal.

La respuesta del objetivo no puede indicar con precisión un estado particular como verdadero o falso
debido a una alta relación entre el ruido y la señal. De manera similar a la idea de perder el haz de luz
de una linterna a la luz del sol, el analista no puede determinar correctamente el estado hasta que se
7 Error de entropía
reduce el ruido. Este tipo de error causado por el entorno rara vez existe en un laboratorio, sin embargo,
es una ocurrencia normal en un entorno no controlado. La entropía puede ser peligrosa si no se pueden
contrarrestar sus efectos.

La respuesta cambia dependiendo de cómo y dónde se formule la pregunta.

La respuesta del objetivo indica un estado particular como verdadero o falso, aunque en realidad el
estado depende de variables en gran medida desconocidas debido al sesgo del objetivo. Este tipo de
8 Falsificación seguridad a través de la oscuridad puede ser peligroso, ya que el sesgo cambiará cuando las pruebas
provengan de vectores diferentes o empleen técnicas diferentes. También es probable que el objetivo
no sea consciente del sesgo.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 47
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Tipo de error Descripción

La respuesta no puede representar el todo porque se ha alterado el alcance.

El objetivo es una muestra sesgada de un sistema más grande o de un mayor número de estados
posibles. Este error ocurre normalmente cuando una autoridad influye en el estado operativo del
9 Error de muestreo
objetivo durante la duración de la prueba. Esto puede deberse a restricciones de tiempo específicas
en la prueba o a un sesgo al probar solo componentes designados como "importantes" dentro de un
sistema. Este tipo de error provocará una representación errónea de la seguridad operativa general.

La respuesta cambia dependiendo de las limitaciones de las herramientas utilizadas.

Las limitaciones de los sentidos humanos o las capacidades del equipo indican que un estado
10 Restricción particular es verdadero o falso, aunque se desconoce el estado real.
Este error no se debe a un mal juicio o a una elección incorrecta de equipos, sino a una falta de
reconocimiento de restricciones o limitaciones impuestas.

Se presume que la respuesta es de un estado u otro aunque no se realizó ninguna prueba.

El analista no realiza una prueba en particular o tiene un sesgo a ignorar un resultado en particular
debido a un resultado presunto. Esto suele ser un cegamiento por la experiencia o un sesgo de
confirmación. La prueba puede repetirse muchas veces o las herramientas y el equipo pueden
modificarse para obtener el resultado deseado. Como lo indica el nombre, un proceso que no recibe
11 Propagación
retroalimentación y en el que los errores permanecen desconocidos o se ignoran propagará más
errores a medida que continúe la prueba. Los errores de propagación pueden ser peligrosos porque
los errores propagados desde el comienzo de la prueba pueden no ser visibles durante un análisis
de las conclusiones. Además, se requiere un estudio de todo el proceso de prueba para descubrir
errores de propagación.

La respuesta cambia dependiendo de la habilidad del analista.

Un error causado por falta de habilidad, experiencia o comprensión no es un error de sesgo y siempre
es un factor presente, independientemente de la metodología o técnica. Si bien un analista
experimentado puede cometer errores de propagación, uno sin experiencia es más propenso a no
12 Error humano reconocer el error humano, algo que la experiencia enseña a reconocer y compensar.

Estadísticamente, existe una relación indirecta entre la experiencia y el error humano. Cuanto menos
experiencia tenga un analista, mayor será la cantidad de error humano que puede contener una
auditoría.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
48 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Trabajar con errores de prueba

Durante la fase de análisis, un analista puede llevar un registro de la cantidad y la gravedad de los errores de funcionamiento
de la prueba. Una simple autoevaluación puede crear un margen de errores de funcionamiento causados durante la prueba
que el analista puede utilizar para enmarcar la minuciosidad de la auditoría actual u otras auditorías de sistemas similares.

Dado que se trata de una autoevaluación, tenderá a ser parcial. El analista debe tener mucho cuidado de que sea lo más
objetiva posible como una forma de garantía de calidad de la prueba y del proceso de prueba. Aunque algunos pueden intentar
descartar los errores de prueba que fueron culpa del analista, llevar un registro de todos los errores solo puede mejorar las
pruebas futuras y no es algo que se deba ocultar. Los errores ocurrirán y no son más que el intento del analista de interactuar
con un sistema en constante cambio. Independientemente de la cantidad y la gravedad de los errores, el seguimiento de los
errores de prueba servirá como un registro de la dificultad y la complejidad de la auditoría y de la competencia del analista
para deducir los errores.

Un registro de los errores de prueba del alcance también ayudará a resumir el entorno de una manera simplista. Es una
reducción directa del Resumen Ejecutivo que a menudo describe la opinión del Analista sobre el estado de la seguridad,
donde pocos o ningún error mostrará un objetivo y un entorno bastante estáticos. Muchos errores muestran un entorno caótico
y uno que puede carecer de controles para gestionar cambios o pérdidas.

En general, los registros de errores de prueba son útiles para comprender la complejidad de la auditoría y el control de
cambios entre auditorías de intervalos regulares.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 49
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Resultados de la prueba

Los resultados de las pruebas suelen ir acompañados de soluciones recomendadas u ofertas de consultoría, ninguna de las cuales es necesaria en una
auditoría OSSTMM. Las soluciones recomendadas pueden proporcionarse como valor añadido a una prueba de seguridad, pero no se consideran
obligatorias. A menudo, no existen soluciones adecuadas en función de la visión limitada que tiene un analista del entorno del cliente. Por lo tanto, no se
requieren soluciones como parte de una auditoría OSSTMM.

Con frecuencia, una prueba excederá los límites de un control de seguridad. En el marco de un trabajo, el analista siempre debe informar el estado actual
de la seguridad, las limitaciones dentro de ese estado actual y los procesos que causaron esas limitaciones de los controles y protecciones aplicados.

Para medir tanto la minuciosidad de la prueba como la seguridad del objetivo, el uso de esta metodología debe concluir con el Informe de Auditoría de
Pruebas de Seguridad (STAR), disponible en este manual o en el sitio web de ISECOM.
STAR requiere la siguiente información:

1. Fecha y hora de la prueba

2. Duración de la prueba
3. Nombres de los analistas responsables
4. Tipo de prueba
5. Alcance de la prueba
6. Índice (método de enumeración de objetivos)
7. Canal probado
8. Vector de prueba
9. Métrica de superficie de ataque
10. ¿Qué pruebas se han completado, no se han completado o se han completado parcialmente y en qué medida?
11. Cualquier problema relacionado con la prueba y la validez de los resultados.
12. Cualquier proceso que influya en las limitaciones de seguridad.
13. Cualquier incógnita o anomalía

El uso correcto del OSSTMM muestra una medición real de la seguridad y los controles. La tergiversación de los resultados en los informes puede dar lugar
a una verificación fraudulenta de los controles de seguridad y a un nivel de seguridad inexacto. Por este motivo, el analista debe aceptar la responsabilidad
limitada por la inexactitud de los informes.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
50 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

2.9 Divulgación
Durante una prueba de seguridad, pueden aparecer limitaciones de seguridad previamente desconocidas o no publicadas. Lo que haga un
analista con ellas es, en primer lugar, resultado de las regulaciones legales de la región del analista y de la región donde se realiza el trabajo.

Derechos de divulgación

Lo que sí debe hacer es asegurarse de que su acceso y uso del producto o la solución no requieran ningún tipo de cláusula, contrato de
confidencialidad o acuerdo de licencia de usuario final (EULA) que le niegue el derecho a reclamar, anunciar o distribuir cualquier vulnerabilidad
descubierta. Si así fuera y usted o el cliente aceptaron este contrato, no podrá revelar información a nadie, tal vez ni siquiera al fabricante, sin
posibles repercusiones legales. Además, si trabaja para la empresa que fabrica ese producto o es un cliente legal de la misma, es posible que
tampoco pueda revelar nada legalmente. Además, sus derechos en cualquier caso pueden ser impugnados de acuerdo con el proceso legal
de su región en lugar de los precedentes legales existentes.

Responsabilidades

Sin embargo, si esos casos no se aplican, entonces usted es efectivamente el propietario de esa vulnerabilidad y cuanto antes la haga pública,
más derechos tendrá como propietario. En muchos países, los procesos y la información pueden estar protegidos por la ley y, a menudo, el
proceso legal requiere la publicación o el registro legal de los mismos con atribución. Si su divulgación no puede causar daño FÍSICO (como
gritar fuego en un cine lleno de gente), es suya y ninguna postura legal debe hacerle dudar cuando tenga razón. Sin embargo, para estar más
seguro, también debe promover, junto con la vulnerabilidad divulgada, los controles que se pueden aplicar para solucionar el problema. Por
ejemplo, si se trata de un problema con la forma en que uno se autentica con una solución, sugiera un esquema de autenticación alternativo y
cómo se puede integrar con éxito. No necesita esperar a que el fabricante publique una solución o un retiro del mercado para que la gente
solucione el problema. Sin embargo, si decide trabajar en el contexto de notificar al fabricante, deberá darle tiempo suficiente para abordar el
problema antes de hacerlo público. Existe un argumento válido de que la vulnerabilidad puede ya ser conocida en los círculos criminales y
necesita atención inmediata. Por lo tanto, si decide publicar sin la ayuda del fabricante, tenga en cuenta que incluir una corrección también
demostrará legalmente que tenía buenas intenciones y gran parte del sistema legal se centra en la intención implícita.

Su elección depende de si las demandas frívolas se aceptan o prevalecen en su región. Recuerde que no es usted, el analista, quien debe
realizar las pruebas de control de calidad para el fabricante, por lo tanto, no le debe ninguna información sobre el trabajo que ha realizado,
incluso si incluye su producto.

La divulgación completa es útil siempre que no pueda causar daño físico o humano. Además, los consumidores no deberían tener que esperar
a que el fabricante solucione los problemas para que sus productos sean seguros. Si el producto no se vende como una solución específica de
seguridad, entonces es responsabilidad de los consumidores hacerlo seguro o no usarlo. Si se vende como seguro, es responsabilidad del
fabricante solucionarlo; sin embargo, es posible que el consumidor no quiera esperar hasta que el fabricante pueda hacerlo. La divulgación
completa permite esta elección.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 51
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

La debilidad no se encuentra analizando lo que es sino

analizando lo que hace.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
52 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 3 – Análisis de seguridad

El análisis de seguridad se refiere aquí a la habilidad de convertir la información en inteligencia de seguridad. Esto requiere comprender más
que solo la información, sino también de dónde proviene, cómo y cuándo se recopiló y las limitaciones del proceso de recopilación. La parte
final del proceso de análisis es crear inteligencia procesable, información derivada de hechos que se puede utilizar para tomar decisiones. Esta
es la clara distinción entre el análisis de seguridad y el análisis de riesgos. En el análisis de seguridad, se producen hechos incluso si esos
hechos indican que no se puede saber algo a partir de la información proporcionada. En el análisis de riesgos, se especula y se derivan
opiniones basadas en la información. El análisis de riesgos puede utilizar el análisis de seguridad para obtener respuestas mejores y más
precisas, pero el análisis de seguridad no puede utilizar el análisis de riesgos para mejorar la precisión. Por este motivo, recomendamos el
análisis de confianza.

Analizando la seguridad de todo

La diferencia fundamental entre un análisis de riesgos y un análisis de seguridad es que en el análisis de seguridad nunca se analiza la
amenaza, ya que suponer que se sabe qué amenazas existen, cuándo pueden atacar, cómo llegarán y adónde irán es algo reservado para el
análisis de riesgos. En el análisis de seguridad, se estudia y mide la superficie de ataque de un objetivo y sus alrededores. Esto le permitirá
comprender dónde pueden atacar las amenazas, si lo hacen. Por ejemplo, considere una pared larga y alta. El análisis de riesgos considerará
qué puede atravesar la pared, pero el análisis de seguridad se centrará en dónde están las grietas, si la base es sólida y si la pared es lo
suficientemente gruesa o alta como para impedir el acceso durante el tiempo suficiente para que llegue la ayuda y responda al ataque. Un
análisis de seguridad también le permitirá asegurarse de que existan los controles adecuados, que funcionen como deberían y cubran
adecuadamente los puntos interactivos de los diversos vectores y canales accesibles.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 53
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

3.1 Pensamiento crítico sobre seguridad

El pensamiento crítico en materia de seguridad, tal como se utiliza aquí, es un término que hace referencia a la práctica de utilizar la lógica y los
hechos para formar una idea sobre la seguridad. Esa idea puede ser una respuesta, una conclusión o una caracterización de algo o alguien, de
modo que las pruebas de verificación puedan definirse bien. Como respuesta o conclusión, el pensamiento crítico en materia de seguridad
proporcionará lo que tenga más sentido. Como caracterización, le mostrará lo que necesita verificar, según lo que necesite verificar, según qué
vector, cómo y cuáles serán los objetivos. También le ayudará a respetar diferentes opiniones o puntos de vista más allá de la seguridad en sí
misma, hasta la interconexión que la seguridad establece con las personas, los lugares, los procesos y el dinero. Le ayudará a abordar
conclusiones contradictorias y explorar consecuencias alternativas. Por lo tanto, incluso si el modelo de pensamiento crítico en materia de
seguridad no puede proporcionar una respuesta, debería decirle qué hechos aún faltan y de dónde debe obtenerlos.

El proceso de pensamiento crítico en materia de seguridad depende de que el analista sea capaz de discernir las afirmaciones verdaderas o, al
menos, reconocer el grado de posible falsedad o las propiedades dinámicas de una afirmación. Una forma de hacerlo es reconocer el grado de
confianza que se puede tener en un hecho mediante el uso de métricas de confianza. Otra forma es poder deconstruir una afirmación, separando
los argumentos falaces. En la práctica, un analista deberá hacer ambas cosas. El analista deberá tener una buena comprensión de lo que se está
analizando y una buena comprensión de las falacias lógicas que se utilizan para hacer calificadores, afirmaciones basadas en conceptos falaces,
generalmente en forma de axiomas o mejores prácticas.

La técnica de análisis de seis pasos

Lamentablemente, el mundo no es prescriptivo. No todas las preguntas tienen una respuesta correcta. La exactitud de una respuesta depende de
muchas cosas, incluida, la más importante, la forma en que se formula. Este es un problema que afecta a todas las industrias, pero ninguna tan
obviamente como la seguridad, por lo que el pensamiento crítico sobre seguridad es tan importante. Como técnica de análisis, se puede reducir a
6 pasos simples para determinar resultados factuales con un alto nivel de confianza en cuanto a su exactitud, 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 fuentes y medir la confianza es crucial
para generar inteligencia adecuada y procesable a partir de las pruebas. En estos pasos, "objetivo" se refiere a lo que se está analizando en la
preparación de una prueba, ya sean personas, computadoras, edificios o procesos.

1. Aumente su conocimiento del objetivo a partir de una variedad de recursos fácticos y contemporáneos, evitando información especulativa
y con sesgo comercial.
2. Determinar el nivel global de experiencia para el tipo de objetivo y la cantidad de información.
Posiblemente se sepa de ello.
3. Determinar cualquier sesgo o motivos ocultos en las fuentes de información.
4. Traduce la jerga de las fuentes de información a palabras similares o conocidas para compararlas, porque lo que puede sonar nuevo o
complicado puede ser sólo un truco para diferenciar algo común.
5. Asegúrese de que el equipo de prueba haya sido calibrado correctamente y que el entorno de prueba haya sido verificado.
garantizar que los resultados no estén contaminados por la propia prueba.
6. Asegúrese de que el estado de traducción de las herramientas o los procesos de prueba se haya eliminado tanto como sea posible para
que los resultados no provengan de fuentes indirectas en un proceso o del análisis previo de algunas herramientas.

Lo más importante que hay que entender aquí es que, al hacer una caracterización, no hay que preocuparse por tener razón. Es más importante
tener razón en cuanto a estar equivocado o en lo cierto, lo que significa que se realizaron las pruebas adecuadas para verificar la caracterización.
Entonces, si la caracterización es incorrecta, al menos sabemos con certeza que es incorrecta y podemos volver a caracterizar. Así es como
funciona el método científico. No se trata de creer o confiar en tu experiencia, sin importar cuán amplia sea, sino de conocer hechos sobre los que
podemos construir.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
54 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Las falacias como calificadores

Un problema adicional de la humanización de las pruebas como una forma de arte en lugar de manejarlas como una ciencia es que introduce
todo tipo de nuevos errores. Comprender nuestras propias limitaciones como seres humanos y nuestra forma de pensar influye en cómo se
puede percibir y definir la seguridad. Esto lleva a muchos profesionales de la seguridad a proporcionar calificadores para lo que no entienden o
no pueden ofrecer. Sin embargo, la mayoría de las veces se repiten como axiomas sin pensarlo más y finalmente se aceptan como verdades
de seguridad. Esto perjudica aún más nuestra capacidad de proporcionar una seguridad adecuada porque nuestro análisis se ve pervertido por
frases hechas y mejores prácticas que pueden no tener ninguna base en la realidad ahora o nunca.

Por ejemplo, algunos axiomas comunes que todavía se utilizan parecerán mucho menos reglas de oro y más excusas cuando se los ponga a
la luz de cuestiones críticas de seguridad. Estos axiomas son tan comunes porque existe una incapacidad general para pensar críticamente
sobre la seguridad o separarla del riesgo como concepto. La seguridad no tiene que ver con el riesgo. Tiene que ver con la protección y los
controles. El riesgo tiene que ver con el riesgo. El riesgo es especulativo, inventado, derivado y correlacionado. El riesgo también es subjetivo.
La seguridad no debería serlo. Para entender mejor cómo estos calificativos manchan nuestra capacidad de hacer un buen análisis de
seguridad, podemos examinar las falacias de los calificadores comunes:

1. No existe nada 100% seguro.

La declaración no proporciona condiciones como el tiempo y la métrica para la cual se pueden usar porcentajes como escala.
Como declaración de riesgo, podría ser cierta: “No existe tal cosa como estar siempre 100% libre de riesgos”, porque según la
definición de riesgo, incluso nuestros propios cuerpos están sujetos al tiempo y a las lesiones autoinfligidas. Sin embargo, como
declaración de seguridad puede tener demasiadas excepciones para ser cierta.

2. Incluso si estás seguro, si un atacante quiere entrar con suficiente fuerza, lo logrará.
La afirmación no proporciona la condición del tiempo, que para cualquier atacante humano sería finito, e incluye una forma de
falacia de equívoco que califica el deseo del atacante.
Por lo tanto, si ningún atacante ha entrado, es que aparentemente no querían entrar "con suficiente urgencia".
Además, la declaración utiliza la frase “entrar” de forma demasiado amplia, de modo que la idea de ganar terreno podría
aplicarse a cualquier cantidad de ataques potenciales y dañinos.

3. No existe la seguridad perfecta.

La afirmación no proporciona la condición de tiempo que implica que el axioma significa "siempre", lo que es en sí mismo un
absoluto y difícil de probar. Esta breve afirmación también entra en las categorías de dos falacias lógicas, la falacia del Nirvana
y la falacia de la Solución Perfecta. En la falacia del Nirvana, nos vemos engañados a rechazar algo porque no puede ser
perfecto. Sin embargo, puede ser lo suficientemente bueno para nuestras necesidades. En la falacia de la Solución Perfecta, el
argumento supone que incluso existe una solución perfecta. Esta suposición es fácil de argumentar en términos de productos
para aquellos que solo entienden los conceptos de seguridad en términos de productos. En realidad, "perfecto" es un concepto
subjetivo y lo que puede no ser perfecto para una persona puede serlo para otra. En el contexto de este manual, "perfecto"
significa una ecuación perfectamente equilibrada al calcular la superficie de ataque que consiste en OpSec y Limitaciones contra
los Controles.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 55
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

4. La seguridad es un proceso, no un producto.

Si bien esta afirmación tiene como objetivo informar a quienes piensan en la seguridad en términos de productos, esta frase
clave en realidad utiliza las falacias del falso dilema y la presunción para persuadir. Como falso dilema, afirma que solo hay dos
opciones, un producto y un proceso y, por lo tanto, la seguridad debe ser una u otra. Como presunción, la conclusión de la
afirmación ya se presume como un proceso que es el medio para la seguridad. En conjunto, estas falacias no permiten que los
productos y los procesos se combinen en la formación de la seguridad ni permiten algo completamente diferente. En realidad,
la definición pública de seguridad está mal definida y no es realmente alcanzable, que es la razón probable de todos estos
axiomas en primer lugar. Esto deja lugar a muchas interpretaciones de lo que puede ser la seguridad y la razón principal por la
que el analista debe comprometerse con una definición alcanzable y medible de seguridad. Afirmar entonces que la seguridad
es una cosa u otra es falso, especialmente cuando la seguridad en sí misma no está definida y se presta a interpretaciones
estándar de diccionario. Es también por eso que este manual define claramente la seguridad como algo medible.

Se requiere que un analista aplique habilidades de pensamiento crítico sobre seguridad a la información tal como se proporciona, así como a
las afirmaciones que se hacen sobre la información analizada para formar inteligencia factual. La inteligencia creada de esa manera
proporcionará métricas precisas e imparciales, así como una comprensión clara de cómo la seguridad es deficiente sin la necesidad de
calificadores.

3.2 Reconocer el modelo OpSec

El análisis de seguridad en la práctica tiene dos problemas. El primero es que la tecnología suele ir mucho más allá de la capacidad de cada
analista para comprender cómo funciona, si es que es posible obtener este conocimiento en el actual estado de caja cerrada de la mayoría de
los productos tecnológicos comerciales. El segundo problema es que, irónicamente, la deconstrucción de cómo funciona algo, incluidos los
procesos comerciales, puede ser ilegal para proteger el riesgo financiero y la privacidad del fabricante frente al comprador, aunque, como
usuario del producto, el comprador puede necesitar esa información para protegerse de amenazas reales que probablemente no sean sus
clientes. Sin embargo, incluso en los casos en que una tecnología o un proceso no se pueden analizar directamente, el producto se puede
analizar dentro del entorno con el que interactúa.

Para cada vector y canal que se analiza, el analista superpondrá el modelo OpSec sobre los objetivos. Aplicar el modelo OpSec es simplemente
contar los controles para cada punto interactivo de acceso o confianza, así como el descubrimiento de oportunidades en forma de visibilidad.
Cuando un objetivo es desconocido, como una caja negra que no se puede abrir, el analista debe abordar los controles sobre las interacciones
del sistema en su entorno. El proceso se verá así:

1. ¿Qué es visible en el osciloscopio? ¿Qué es posible que tenga valor y que se conozca? ¿Qué objetivos se pueden
¿determinado?
2. ¿Cuáles son los puntos de acceso interactivos a esos objetivos y desde qué vector o canal?
3. ¿Cuáles son los Trusts dentro del ámbito y sobre qué vector o canal?
4. ¿Cuáles son los controles para dichos Accesos y Confianzas?
5. ¿Los controles están completos o tienen limitaciones?

Incluso una aplicación rápida del modelo OpSec le dirá si un acceso o un fideicomiso está equilibrado con controles.
Esto le indicará el tamaño de la superficie de ataque y qué puntos interactivos están abiertos sin ningún control que los gobierne.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
56 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

3.3 Busque la coincidencia de patrones como señal de errores

Si empiezas buscando exactamente lo que buscas, es posible que solo encuentres lo que esperas encontrar. Esto es adecuado cuando
buscas calcetines que combinen, pero no tanto cuando miras el panorama general de una superficie de ataque. Es el principal problema
conocido como coincidencia de patrones, el rasgo humano de saltarse pasos, a veces sin saberlo, que se consideran innecesarios debido a
un resultado "obvio". También hace que las personas vean causa y efecto donde puede que no los haya. Es un punto ciego que los analistas
desarrollarán después de años de realizar tareas iniciales, básicas o redundantes. Estas tareas se vuelven más eficientes mediante atajos
que afectan la calidad de las pruebas de verificación y, en última instancia, el análisis.

Para que la inteligencia sea procesable, un resultado es tan bueno como los métodos utilizados para obtenerlo. No saber cómo se obtuvo un
resultado en particular limitará severamente la acción que se puede tomar para solucionarlo. Cuando un analista utiliza la comparación de
patrones para omitir pasos, no se puede conocer correctamente el método. Aun así, el deseo de "ir al grano" para llegar al meollo de un
problema mientras se presupone un estado que en realidad es desconocido es un problema en muchas áreas de la ciencia. La seguridad no
es una excepción. Por lo tanto, un analista debe reconocer cuándo se han omitido pruebas o se han manipulado los datos para proporcionar
resultados no verificados.

Para detectar la coincidencia de patrones, examine los métodos de prueba y los datos de resultados para lo siguiente:

1. Pruebas que utilizan amenazas específicas en lugar de una interacción exhaustiva con la superficie de ataque.
2. La falta de detalles sobre los procesos resultantes de las interacciones con el objetivo.
3. Poca o ninguna información sobre los controles para los distintos objetivos.
4. Sólo se informan algunos de los objetivos para ciertas pruebas y estos tienen resultados completamente negativos.
5. Objetivos no probados por razones anecdóticas (notas donde una persona ha dicho que no hay nada
allí para probar o ha sido asegurado).
6. Pruebas de objetivos que evidentemente no han sido asegurados.

3.4 Caracterizar los resultados

El método científico no es una lista de verificación. Es un proceso que permite la inteligencia y la imaginación. Se formula una hipótesis y
luego se recopilan datos mediante pruebas y observaciones para evaluar esa hipótesis. En una prueba de seguridad, se formula una hipótesis
esencialmente cada vez que se realiza una verificación contra un punto interactivo directo o indirecto en el ámbito. El analista tiene los datos
empíricos de esas pruebas y debe considerar si las pruebas realmente verificaron la hipótesis. ¿Se realizaron las pruebas correctas? ¿Se
realizaron suficientes pruebas? ¿Se probaron los canales o vectores correctos? ¿Se crearon nuevas interacciones que también se probaron?
Para hacer esto, caracterizamos los resultados.

Para caracterizar una prueba de seguridad mediante el método científico se deben descubrir las propiedades del ámbito de aplicación para
garantizar que se hayan realizado las pruebas correctas. El evaluador formula una hipótesis sobre la interactividad de un punto en la
superficie de ataque. La prueba arrojará como resultado que el punto es interactivo y contribuye a la superficie de ataque o no, y si aún
contribuye a la superficie de ataque, los controles implementados, las limitaciones en dichos controles, las limitaciones en la seguridad
definida y las anomalías. En este punto, el analista puede estar equivocado sobre la función del proceso en funcionamiento, pero puede que
no esté equivocado sobre qué pruebas se deben utilizar para verificar cuál es realmente la función. Por eso es necesario tanto el conocimiento
del proceso como la imaginación creativa de la interacción indirecta.

Por ejemplo, el analista puede caracterizar un proceso como si incluyera la interacción entre un visitante y la red a través de la tarjeta de
acceso. Por lo tanto, si bien este visitante no tiene las credenciales para acceder a la red, debido a que el lector de tarjetas está conectado al
sistema informático, ese visitante sí accede a la red al pasar la tarjeta. El analista debe considerar cómo probar lo que sucede cuando el
visitante interactúa con el lector de tarjetas para obtener acceso, así como los efectos secundarios de que se lea la tarjeta. Sin embargo,
incluso si las pruebas muestran que el lector de tarjetas está conectado a un sistema informático independiente y no está conectado a la red,

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 57
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

El analista ha verificado adecuadamente que se realizaron las pruebas correctas contra los objetivos correctos para obtenerlo.
respuesta.

Por lo tanto, el analista examinará el alcance de los lugares en los que podría producirse una interacción, así como los lugares en los que las
operaciones muestran que se producen interacciones. Esto permitirá una caracterización de los puntos de interacción, cualquier posible
interacción indirecta y todos los efectos secundarios de dichas interacciones. Esta caracterización debe luego compararse con las pruebas
realizadas para determinar si se realizaron todas las pruebas correctas.

3.5 Busque señales de intuición

Una cosa en la que las máquinas son claramente mejores que los humanos es la coherencia. Los humanos generalmente se aburren, se
confunden o se descuidan. Cuando una máquina cuenta monedas, no pierde la cuenta y necesita empezar de nuevo. No duda de sí misma y
empieza de nuevo. Tampoco usa la intuición. También llamada "instinto", el poder de la intuición es increíble. Permite a las personas imaginar,
aplicar la creatividad a un trabajo y saber cuándo algo parece ir mal. Es parte de la condición humana detectar problemas de manera
subconsciente y prepararse en consecuencia. Sin embargo, es exactamente esto lo que a veces nos lleva a cometer errores. Esto nunca es más
obvio que cuando contamos grandes cantidades de objetos de apariencia similar. Sin una concentración total, podemos comenzar a sentirnos
incómodos con el recuento y, con el tiempo, podemos sentirnos obligados a comenzar de nuevo o simplemente aceptar un número particular
que suena correcto donde creemos que lo dejamos y continuar desde allí.

Hay un momento en que una prueba requiere una concentración precisa; durante un gran número de secuencias repetitivas.
Generalmente, solemos crear herramientas para manejar este tipo de repeticiones, pero no siempre es posible debido a la naturaleza dinámica
de la prueba, como cuando se interactúa con personas en lugar de objetos inanimados o máquinas. Por lo tanto, a medida que avanza la prueba,
el evaluador puede usar la intuición para suponer que la prueba será innecesaria. El analista debe prestar especial atención a estas pruebas y
buscar signos de intuición en parte del evaluador.

Las señales de problemas de intuición en los tests son:

1. Inconsistencias en los tipos de pruebas realizadas en múltiples objetivos similares.

2. El número de pruebas disminuye entre los objetivos.
3. El tiempo de duración de las pruebas disminuye entre los objetivos.
4. El mismo objetivo probado más de una vez con las mismas pruebas.

La detección de intuición en las pruebas indicará que el proceso de evaluación es inadecuado y la calidad de los resultados debe considerarse
con sospecha. Puede ser necesario volver a realizar la prueba.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
58 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

3.6 Informes transparentes

Es raro que un análisis de seguridad termine con todas las respuestas. Dado que las pruebas dependerán de la seguridad operacional y de los
controles de un canal y un vector en particular, habrá incógnitas. Puede haber un objetivo visible que no proporcione interacción y no se pueda
determinar más información sobre ese objetivo a partir de este vector y este canal. Esto es correcto. El analista debe informar lo que ha
encontrado con certeza y no simplemente lo que podría encontrarse. No hay lugar para conjeturas cuando se mide una superficie de ataque.

Además de la información sobre la prueba en sí y cómo se realizó, el analista deberá informar los siguientes 7 resultados de la prueba:

1. Incógnitas
A medida que se analicen más vectores y canales, habrá más información disponible y lo que se informe cambiará y proporcionará información
procesable. Por el contrario, puede que haya más resultados no concluyentes o que la correlación de los resultados proporcione respuestas
contradictorias; la información procesable resultante sea desconocida. Desconocido es una respuesta válida para informar. Lo que no se puede
saber es tan válido e importante en materia de seguridad como lo que se descubre. Lo desconocido muestra lo que es difícil de probar o
analizar. Lo desconocido no tiene por qué verse como un fallo del evaluador, sino que puede deberse a una protección superior o a un ataque
que utiliza un gran coste de tiempo o recursos que no es posible en una prueba. Ningún analista debería tener miedo de informar que algo es
desconocido. Es un resultado poderoso en el que basar un análisis de riesgos posterior.

2. Objetivos no probados
Además, el analista debe informar sobre otro tipo de incógnitas: objetivos en el ámbito de aplicación que no se han probado en un vector o
canal en particular. Si una prueba no se puede completar debido a limitaciones de tiempo, limitaciones de la herramienta, objetivos inestables,
el entorno de prueba es demasiado dinámico o demasiado ruidoso para recopilar los resultados adecuados, o porque el propietario del objetivo
no quería las pruebas, entonces es necesario saberlo. Al informar lo que no se probó, es posible hacer comparaciones adecuadas de las
pruebas con las pruebas futuras. También ayudará a evitar hacer trampas al probar solo el segmento bien protegido de un ámbito de aplicación
e ignorar el resto para crear la ilusión de una superficie de ataque pequeña.

3. Limitaciones identificadas y verificadas

Además de las incógnitas, el analista también debe informar sobre las limitaciones identificadas y verificadas, como las vulnerabilidades en los
objetivos. Una limitación identificada es aquella que se ha determinado mediante el conocimiento y la correlación. Esto resulta útil cuando las
pruebas en sí mismas son peligrosas o muy costosas. A veces, una prueba puede ser perjudicial para un objetivo o causar daños colaterales
inaceptables o incluso criminales. Una limitación verificada es aquella en la que el problema se ha probado específicamente para determinar si
existe.

4. Falsos positivos y los medios para generarlos

Durante las pruebas, algunas limitaciones identificadas no serán vulnerables a esos ataques particulares durante la verificación. Sin embargo,
esto no implica que el objetivo no tenga esas limitaciones. Solo significa que esa prueba en particular en ese momento particular y realizada por
ese evaluador en particular no expuso la vulnerabilidad identificada. También podría significar que el objetivo es vulnerable pero está protegido
por un control particular. Esos falsos positivos determinados deberían informarse para que durante el desarrollo posterior de técnicas de
protección y defensa, el problema pueda examinarse más de cerca, particularmente desde un vector diferente.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 59
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

5. Procesos y procedimientos de seguridad fallidos

Durante el análisis, los resultados de la prueba mostrarán más que solo OpSec, los tipos de controles y la cantidad de limitaciones.
Se mostrará un panorama más amplio, de los procesos y procedimientos que se utilizan para formalizar las medidas de protección. Estos
pueden ser sobre cualquier cosa que esté diseñada para llevar las medidas de protección a su estado actual. Esto incluye, entre otros,
mantenimiento, adquisiciones, identificación, autorización, mantenimiento, recuperación de desastres, relaciones con socios, generación de
políticas, control del clima y recursos humanos. Cuando un objetivo tiene una limitación, muchas veces hay un proceso o procedimiento
fallido detrás de ella. El analista debe poder determinar exactamente de qué se trata a partir de los resultados agregados de la prueba.

6. Buenas prácticas
El término “Mejores prácticas” se utiliza para explicar la mejor manera para que una persona u organización haga algo.
Lamentablemente, esto se ha abusado hasta el punto de que ahora significa que es lo mejor para todos. Esto en sí mismo ha causado
problemas y ha desperdiciado recursos. Una forma de contrarrestar este problema es utilizar los resultados de las pruebas agregadas para
mostrar las prácticas que dan resultado. Esto mostrará qué se puede repetir para obtener un éxito equivalente en otras áreas de la
organización y definirá una "mejor práctica" personalizada para ellas. También reducirá su dependencia de las mejores prácticas de toda la
industria en favor de lo que funciona mejor para ellas.

7. Cumplimiento
Si es necesario alcanzar objetivos de cumplimiento específicos, el analista debe utilizar los resultados de las pruebas correlacionadas para
determinar si se han cumplido estos objetivos. Es posible que sea necesario proporcionar estos resultados en un formato especial, según
lo determine el auditor; sin embargo, el analista es el que mejor puede demostrar qué resultados de las pruebas proporcionan la información
necesaria.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
60 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

La evaluación de riesgos es un concepto que se

utiliza para seleccionar la seguridad y los controles
en función del riesgo presunto. Sirve para definir
la estrategia. Sin embargo, las pruebas de
seguridad sirven para verificar hasta qué punto
existen la seguridad o los controles. Sirven para
definir las operaciones. Para realizar pruebas, no
se debe realizar una evaluación de riesgos porque
eso limitaría el potencial y los hallazgos.
Después de todo, no deberías estar haciendo las
mismas conjeturas que ellos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 61
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 4 – Métricas de seguridad operativa

Las métricas de seguridad operativa son las métricas con las que estamos más familiarizados en nuestras vidas. Cuando medimos la altura, el
ancho o la longitud de un objeto, estamos utilizando una métrica operativa. Cuando escribimos la fecha, celebramos un cumpleaños o preguntamos
el resultado de un juego, estamos utilizando métricas operativas. Una métrica operativa es una medición constante que nos informa de un recuento
factual en relación con el mundo físico en el que vivimos. Son operativas porque son números con los que podemos trabajar de manera constante
día a día y de persona a persona. Es difícil trabajar con mediciones relativas o inconsistentes como elegir un tono específico de amarillo para pintar
una habitación, comenzar a trabajar al amanecer, tener el sabor correcto de fresa para un batido o prepararse para la próxima amenaza que afecte
las ganancias de su organización porque los factores tienen muchas variables que están sesgadas o cambian con frecuencia entre personas,
regiones, costumbres y ubicaciones. Por esta razón, muchas profesiones intentan estandarizar cosas como sabores, colores y horas de trabajo.
Esto se hace a través del reduccionismo, un proceso de encontrar los elementos de tales cosas y construirlas a partir de allí cuantificando esos
elementos. De esta manera, los colores se convierten en frecuencias, las horas de trabajo en horas y minutos, los sabores en compuestos químicos
y una superficie de ataque en porosidad, controles y limitaciones. El único problema real con las métricas operativas es el requisito de saber cómo
aplicarlas correctamente para que sean útiles.

Usando ravs para medir y rastrear la seguridad de cualquier cosa a lo largo del tiempo.

La realización de una prueba de seguridad exhaustiva tiene la ventaja de proporcionar métricas precisas sobre el estado de la seguridad. Como
ocurre con el uso de cualquier métrica, cuanto menos exhaustiva sea la prueba, menos precisa será la métrica general.
Los analistas menos capacitados o menos experimentados también afectarán negativamente la calidad de la métrica, al igual que las personas
que no pueden decir la hora no pueden construir relojes, los diseñadores sin las herramientas adecuadas no pueden combinar colores exactamente y

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]

62 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]

Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Los maestros cerveceros que no pueden medir los ingredientes de la cerveza no pueden producir lotes similares repetidamente para el
mercado. Por lo tanto, una métrica de seguridad exitosa requiere una prueba que se puede describir como la medición de los vectores
apropiados teniendo en cuenta las imprecisiones y las tergiversaciones en los datos de prueba recopilados, así como las habilidades o la
experiencia de los profesionales de seguridad que realizan la prueba. Las fallas en estos requisitos dan como resultado mediciones de menor
calidad y determinaciones de seguridad falsas, por lo tanto, la métrica también debe ser lo suficientemente simple para usar sin hacerla tan
simple que no diga nada. Además, una métrica de seguridad adecuada debe evitar los sesgos inherentes a las evaluaciones de riesgos al
garantizar que las mediciones tengan integridad.
Estas cualidades se han combinado para crear los ravs, una descripción imparcial y objetiva de una superficie de ataque.

4.1 Conociendo al Rav

El rav es una medida de escala de la superficie de ataque, la cantidad de interacciones no controladas con un objetivo, que se calcula mediante
el equilibrio cuantitativo entre operaciones, limitaciones y controles.
Tener los RAV es entender qué parte de la superficie de ataque está expuesta. En esta escala, 100 RAV (también se muestra como 100%
RAV para simplificar la comprensión, aunque no es exactamente un porcentaje) es el equilibrio perfecto y cualquier valor menor significa que
hay muy pocos controles y, por lo tanto, una mayor superficie de ataque. Más de 100 RAV muestran más controles de los necesarios, lo que
en sí mismo puede ser un problema, ya que los controles a menudo agregan interacciones dentro de un alcance, así como complejidad y
problemas de mantenimiento.

El RAV no mide el riesgo de una superficie de ataque, sino que permite medirlo. No puede decir si un objetivo en particular
será atacado, pero sí puede decir en qué parte del objetivo será atacado, contra qué tipos de ataques se puede defender
con éxito el objetivo, hasta dónde puede llegar un atacante y cuánto daño puede causar. Con esa información, es posible
evaluar las confianzas (y los riesgos) con mucha más precisión.

El rav es en realidad un conjunto de cálculos separados de porosidad, controles y limitaciones que, cuando se combinan,
muestran el tamaño de una superficie de ataque de dos maneras prácticas. La primera es mediante un cálculo directo. Es el
cálculo del delta, un número que describe la exposición específica de ese objetivo. Esto es útil para determinar cómo una
nueva persona, cosa o proceso cambiará la seguridad operativa de un nuevo ámbito o como una comparación entre múltiples
objetivos individuales. Esta es también la manera más fácil de ver la seguridad perfecta, el equilibrio perfecto entre porosidad,
controles y limitaciones. El rav se muestra como un número positivo o negativo que muestra qué tan lejos está el objetivo de
un equilibrio de seguridad perfecto. Un delta positivo muestra que se gasta demasiado en controles en general o incluso si
el gasto excesivo se debe a demasiado de un tipo de control. Un delta negativo muestra una falta de controles o controles
en sí mismos con limitaciones que no pueden proteger al objetivo adecuadamente. Esta es una herramienta poderosa para
saber exactamente dónde y cómo se están gastando los recursos para proteger un objetivo en particular. Sin embargo, esta
no es la forma en que el rav es más útil; eso se hace mejor de la segunda manera.

La segunda forma práctica de mostrar la superficie de ataque es para entender el panorama general. Esto se representa
como Seguridad real. Mientras que el cálculo del delta se basa en un equilibrio perfecto, el cálculo de Seguridad real utiliza
el delta pero también incluye controles adicionales y redundantes para proporcionar una métrica más amigable y familiar
para las personas. Aquí la representación rav es similar a cómo las personas utilizan los porcentajes. El rav se calcula con
un logaritmo de base 10, lo que hace que la representación sea más comprensible. Si bien el rav sigue siendo un equilibrio,
el equilibrio perfecto se establece en 100 y los cálculos se realizan con respecto a eso. Esto permitirá que la mayoría de las
personas tengan una descripción general rápida y fácil de todos los objetivos en un alcance o de solo un objetivo en relación
con otros objetivos. Es extremadamente flexible, por lo que la Seguridad real puede comparar múltiples superficies de ataque
incluso si el alcance o los objetivos son muy diferentes: el 95% rav de un alcance con 1000 sistemas informáticos es
comparable al 95% rav con solo 10 sistemas, que a su vez se puede comparar con un edificio con un 95% rav. Los tres
proporcionarán la misma información a una persona: la protección del objetivo es deficiente en un 5% y, por lo tanto, está
expuesto a ataques. Con este conocimiento, uno puede comenzar a evaluar el riesgo y determinar qué está expuesto, qué
queda sin control y si ese 5% es aceptable. Por lo tanto, sea cual sea la amenaza que exista, solo puede ocurrir donde haya
aberturas y eso agudizará la exactitud de un análisis de riesgos desde la espada ancha hasta el bisturí.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 63
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

¿Cómo es un Rav?

Un RAV es un poco diferente de otras mediciones de seguridad porque el recuento es único desde el osciloscopio. Eso es como determinar el tamaño
general de una persona contando todas sus células y categorizándolas según lo que hacen para determinar la salud general de la persona. Para un
RAV, se requieren tanto el recuento como la operación. Es por eso que el RAV solo se puede derivar de pruebas de seguridad operativas.

Imaginemos que existe una máquina que puede auditar todas las células
del cuerpo humano. Esta máquina funciona monitoreando las células en su
entorno e incluso estimulando a cada célula para que reaccione y clasifique
mejor su propósito.
Entonces podríamos ver qué hacen las distintas células y cómo contribuyen
a la composición general del cuerpo humano.
Algunas células forman las paredes de los tejidos, como las células de la
piel. Algunas, como los glóbulos blancos, proporcionan autenticación y
atacan a otras células que están en su lista de “malas”. Luego, algunas
células son extrañas, como las bacterias que han entrado en algún momento
y han prosperado. La máquina clasificaría todas las células que componen
a la persona, un ámbito definido, en lugar de decir cuáles son “malas” o
“buenas”.

Contando las células, la máquina puede determinar principalmente cómo

funciona la persona como organismo (salud) y cómo se adapta a su entorno
actual. También puede determinar qué células están rotas, cuáles son
superfluas y de qué tipo se podrían necesitar más para que la persona sea
más eficiente, esté preparada para lo inesperado o para cualquier número
de necesidades específicas. Como las células se dividen y mueren todo el
tiempo, la máquina también debe realizar pruebas periódicas y registrar la
capacidad de la persona para mejorar o al menos mantener la homeostasis.

Ahora, además de contar células y ver cómo funcionan, la máquina también

verá con qué otras células o bajo qué condiciones interactúan y qué tan
bien. En cada operación de las funciones de la célula, la máquina puede Los ravs son como contar células y clasificarlas según lo que hacen
determinar cuáles son las limitaciones de la célula. Por lo tanto, si fuera para determinar qué tan bien se adapta el organismo a un entorno.
posible que la máquina también reparara un problema en células
defectuosas directamente, fortificara el cuerpo cambiando el proceso de las
células o eliminara las células innecesarias, podríamos afectar directamente
la salud del cuerpo en su conjunto con cada cambio. O tal vez podríamos cambiar el entorno al que está expuesto el cuerpo en lugar de las células
para hacer cambios más globales. Al someter a la persona a una mejor nutrición, dieta o ejercicio, también cambiaremos el cuerpo a nivel celular.
Todo esto es posible al saber cómo funcionan las cosas dentro del cuerpo y qué hay en estas operaciones.

Lamentablemente, no existe una máquina que cuente todas las células del cuerpo humano, pero sí existe por razones de seguridad.
Los analistas pueden contar y verificar las operaciones de los objetivos en un ámbito como si se tratara de un superorganismo. Registran sus
interacciones y los controles que rodean esas interacciones. Las clasifican por operación, recursos, procesos y limitaciones. Esos números que
generan los analistas se combinan de modo que los controles suman a la seguridad operativa y las limitaciones la restan. Incluso el valor de las
limitaciones, lo mucho que afecta cada tipo de problema, tampoco es arbitrario porque se basa en la combinación de seguridad y controles dentro de
ese ámbito en particular. Por lo tanto, un problema grave en un entorno de protección proporcionará una exposición general menor que uno en un
entorno menos controlado.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
64 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Ocho respuestas fundamentales sobre seguridad

El RAV no representa el riesgo, ya que este se conoce como Riesgo = Amenaza x Vulnerabilidad x Activo. En esa ecuación, el riesgo es el resultado
de una ecuación informada, aunque muy sesgada. Si podemos eliminar la mayor parte del sesgo conociendo el nivel de protección y, por lo tanto,
el nivel de impacto de la vulnerabilidad, podemos reducir el sesgo en esa ecuación y brindar una evaluación de riesgo mucho mejor. Por lo tanto, el
RAV es en realidad la base fáctica para una evaluación de riesgo en la que un analista tiene hechos con los que trabajar. Sin embargo, el verdadero
poder del RAV es cómo puede brindar respuestas a las siguientes ocho preguntas fundamentales de seguridad con gran precisión.

1. ¿Cuánto dinero se debe gastar en seguridad?

El RAV mostrará la cantidad actual de protección para hacer proyecciones de seguridad y definir hitos incluso antes
de comprar una solución en particular o implementar algún nuevo proceso. A partir de estas proyecciones e hitos, se
pueden crear restricciones financieras para cumplir con los objetivos y obtener los resultados más específicos de la
inversión. Al saber exactamente qué se controla en función del gasto actual, también se puede ver qué no se está
controlando por ese dinero. “Más” se convierte entonces en lo que falta. Entonces es posible pronosticar el costo de
completar los controles faltantes para lograr un equilibrio perfecto o al menos un nivel de cobertura decididamente
aceptable.

2. ¿Qué se debe proteger primero?

El RAV se puede utilizar para ver la seguridad como parte de un panorama general y como una lente macro para
una parte particular de un objetivo, o cualquier combinación de ambos. Después del análisis, el RAV mostrará qué
parte particular del alcance tiene la mayor porosidad y los controles más débiles. Al comparar eso con las necesidades
y el valor de los activos de uno, se puede generar una relación entre la fortaleza de la protección y el valor para
decidir exactamente por dónde empezar.

3. ¿Qué soluciones de protección necesitamos y cómo debemos configurarlas para obtener el máximo rendimiento?
¿eficacia?

Un RAV completamente completado mostrará los 10 posibles controles operativos aplicados para cada objetivo y las
limitaciones de esos controles. Luego, puede elegir soluciones en función de los tipos de controles que desea
implementar. La diferencia ahora es que ya no necesita analizar una solución en términos de lo que es en lugar de
considerar la protección o los controles que puede proporcionar. Esto le permite ver los productos para los controles
que necesita proporcionar en las áreas donde los controles son deficientes actualmente.

4. ¿En qué medida se mejoran las adquisiciones y los procesos de seguridad específicos?

Una característica clave del RAV es que se puede hacer un “Delta” al trazar un mapa de los beneficios y limitaciones
de una solución particular para comparar antes de la adquisición.
Esto significa que puede ver qué cambios generará esa solución en el alcance para compararla con otras soluciones.
Al combinar ese mapa con un RAV del alcance donde se colocaría la solución, se puede medir la cantidad de mejora
incluso antes de la compra. Incluso puede predecir el valor de esa protección dividiendo el precio de la solución por
el delta del RAV.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 65
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

5. ¿Cómo medimos los esfuerzos y mejoras periódicas de seguridad?

Con auditorías regulares, el RAV se puede recalcular y comparar con el valor anterior.
De esta forma se pueden justificar periódicamente los costes de nuevas soluciones y procesos, así como
los costes de mantenimiento del nivel de seguridad actual.

6. ¿Cómo sabemos si estamos reduciendo nuestra exposición a nuestras amenazas?

Con un conocimiento específico de sus controles, puede determinar fácilmente qué parte o vector del
alcance es débil ante amenazas específicas y más desconocidas. En la terminología de RAV, una
amenaza desconocida es simplemente aquella que puede aparecer donde existen interacciones pero no
controles. Por lo tanto, se puede trazar un mapa entre las amenazas determinadas por los evaluadores
de riesgos y los controles establecidos. Las revisiones periódicas de métricas mostrarán cualquier cambio
en este mapa y se pueden realizar de manera regular. Luego es posible medir el costo que tiene cada
una de esas amenazas sobre la seguridad mediante el gasto en controles.

7. ¿Puede el Rav decirnos qué tan bien algo resiste los ataques?

Técnicamente, sí. Cuanto más se puedan equilibrar los controles con las interacciones, menor será la
superficie de ataque y más capaz será el objetivo de controlar tipos de interacciones conocidos y
desconocidos.

8. ¿Puede el RAV ayudarme con el cumplimiento normativo?

Todo lo que le ayude a clasificar todos los controles y puntos de acceso en un ámbito le ayudará con las
auditorías de cumplimiento. El RAV le ayuda a hacer un trabajo tan bueno para mantener su seguridad
bajo control que incluso puede encontrar las principales fallas en las regulaciones de cumplimiento. Si
bien en este momento no existe ningún cumplimiento en particular que le pida tener una puntuación RAV
en particular, mostrar OSSTMM STAR con su puntuación RAV le ayudará a cumplir con varios requisitos
de cumplimiento para una auditoría y documentación de terceros.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
66 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

4.2 Cómo hacer un Rav

El rav requiere una prueba de seguridad para tener las cosas correctas contadas y las operaciones correctas analizadas.
Se puede utilizar cualquier prueba de seguridad, pero cuanto más exhaustiva y precisa sea la prueba, más concluyentes
serán los resultados. El rav se diseñó originalmente para pruebas operativas, como OSSTMM, donde el auditor se centra
en el comportamiento del objetivo en lugar de en la configuración. Sin embargo, los experimentos muestran que es
posible aplicar el rav también a pruebas no operativas, como en el análisis de código estático para determinar el nivel de
seguridad y complejidad del software o en auditorías de listas de verificación de seguridad física para determinar el nivel
de protección que proporcionará un espacio físico. El proyecto SCARE (Source Code Analysis Risk Evaluation) hace
exactamente esto al aplicar los rav al código fuente C.

La sencillez de hacer un rav a partir de una prueba de seguridad.

El rav mínimo se realiza mediante el cálculo de la porosidad, que son los agujeros en el alcance. El problema con las
métricas de seguridad generalmente está en la determinación de los evaluadores de contar lo que no pueden saber
realmente. Este problema no existe en el rav. Se obtiene lo que se sabe de lo que está allí para un vector en particular
y no se hacen suposiciones sobre lo que no está allí. Se cuenta todo lo que es visible e interactivo fuera del alcance y
se permite la interacción no autenticada entre otros objetivos en el alcance. Eso se convierte en la porosidad. Este valor
de porosidad constituye la primera de las 3 partes del valor rav final. La siguiente parte es dar cuenta de los controles
establecidos por objetivo. Esto significa ir objetivo por objetivo y determinar dónde se encuentran establecidos cualquiera
de los 10 controles, como Autenticación, Subyugación, No repudio, etc. Cada control se valora como el 10% de un poro,
ya que cada uno proporciona 1/10 de los controles totales necesarios para prevenir todos los tipos de ataque. Esto se
debe a que tener los 10 controles para cada poro es funcionalmente lo mismo que cerrar el poro siempre que los
controles no tengan limitaciones. La tercera parte del rav es dar cuenta de las limitaciones encontradas en la protección
y los controles. Estas también se conocen como "vulnerabilidades". El valor de estas limitaciones proviene de la
porosidad y los controles establecidos en sí mismos. Una vez completados todos los recuentos, el rav básicamente resta
la porosidad y las limitaciones de los controles. Esto se hace más fácilmente con la calculadora de hoja de cálculo rav.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]

Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 67

Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Desafortunadamente, un analista no calificado puede proporcionar información errónea, lo que se traducirá en un mal resultado.
Esta es una posibilidad, al igual que es posible que un carpintero no mida bien una tabla o que un mecánico no lea bien los calibres. El mundo
está lleno de escenarios hipotéticos. Por lo tanto, el RAV está diseñado para verse mínimamente influenciado por una auditoría incorrecta o
por trampas al eliminar el tamaño del osciloscopio directo del cálculo métrico.
Sin embargo, ninguna métrica puede ser inmune a las falsificaciones y la única forma de garantizar el RAV más preciso es realizar múltiples
pruebas a lo largo del tiempo para hacer los recuentos y estar seguro de que el auditor asumirá la responsabilidad de la precisión de la prueba.

Es posible tomar un atajo en las pruebas y aun así obtener un RAV representativo. Si no le importa el margen de error porque solo desea hacer
una comparación rápida, puede calcular la porosidad, lo que significa contar los objetivos visibles y accesibles. Por ejemplo, quienes ejecutan
escáneres de vulnerabilidades pueden contar la porosidad y las limitaciones con relativa facilidad y asignar controles predeterminados para los
servicios descubiertos. Los analistas también pueden crear una lista de verificación que ofrezca controles predeterminados para diferentes
soluciones comunes encontradas. Todos estos son atajos para reducir el tiempo de cálculo, pero afectarán el RAV general con un margen de
error desconocido, pero quizás aceptable.

El resultado final es un cálculo de seguridad real. Aplica múltiples controles del mismo tipo para satisfacer requisitos de doble aplicación como
la autenticación de dos factores. También utiliza Log10 para reducir números grandes a un formato manejable por humanos. Por lo general, a
las personas les gusta trabajar con números más pequeños y, especialmente, como porcentajes que son más fáciles de visualizar. Para un
alcance pequeño, la precisión de usar Log10 como técnica de reducción es insignificante. Sin embargo, si tiene un alcance muy grande con
muchos objetivos, es posible que desee trabajar con números muy grandes para lograr una mayor precisión. Además, si desea ver el equilibrio
real donde no se miden múltiples controles del mismo tipo, ese cálculo se puede encontrar en el encabezado Protección real.

Combinando canales y vectores

Un requisito importante en la aplicación del rav es que la seguridad real solo se puede calcular por alcance.
Un cambio de canal, vector o índice es un nuevo alcance y un nuevo cálculo para la seguridad real.
Sin embargo, una vez calculados, se pueden combinar varios alcances en conjunto para crear una Seguridad real que represente una visión
más completa de la seguridad operativa de todos los alcances. Por ejemplo, se puede realizar una prueba de servidores que dan a Internet
tanto desde el lado de Internet como desde dentro de la red perimetral donde residen los servidores. Eso son 2 vectores. Supongamos que el
vector de Internet está indexado por dirección IP y contiene 50 objetivos. El vector de intranet está indexado por dirección MAC y está
compuesto por 100 objetivos porque existen menos controles internamente para permitir una interacción más colaborativa entre los sistemas.
Una vez que se completa cada prueba y se cuenta el RAV, se pueden combinar en un cálculo de 150 objetivos, así como las sumas de cada
limitación y control. Esto dará una métrica de Seguridad real final que es más completa para esa red perimetral que la que proporcionaría cada
prueba por separado. También sería posible agregar el análisis de las pruebas de seguridad física, inalámbrica, de telecomunicaciones y de
seguridad humana de la misma manera. Tales combinaciones son posibles para crear una mejor comprensión de la seguridad total de una
manera holística.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
68 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Calculadora Rav
Una forma sencilla y directa de realizar cálculos RAV es utilizar hojas de cálculo creadas específicamente para
calcular la superficie de ataque y varias métricas populares requeridas a partir de los datos de prueba. Esta hoja de
cálculo está disponible en el sitio web de ISECOM. El analista solo debe ingresar los valores en los cuadros blancos
vacíos y el resto de los cálculos se realizarán automáticamente.

Hoja de cálculo rav para determinar el equilibrio entre porosidad, controles y limitaciones.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 69
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

4.3 Convertir los resultados de las pruebas en una medición de la superficie de ataque

Seguridad operacional
La medición de la superficie de ataque requiere las mediciones de visibilidad, confianza y acceso en relación con el alcance. La cantidad de objetivos
en el alcance que se puede determinar que existen mediante interacción directa, interacción indirecta o emanaciones pasivas es su visibilidad. A
medida que se determina la visibilidad, su valor representa la cantidad de objetivos en el alcance. La confianza es cualquier interacción no autenticada
con cualquiera de los objetivos. El acceso es la cantidad de puntos de interacción con cada objetivo.

Categoría Descripción

La cantidad de objetivos en el ámbito. Cuente todos los objetivos por índice solo una vez y
mantenga el índice de manera uniforme para todos los objetivos. Por lo general, no es realista tener
más objetivos visibles que los que hay en el ámbito definido; sin embargo, puede ser posible debido
a las transiciones de vectores, donde un objetivo que normalmente no es visible desde un vector
es visible debido a una configuración incorrecta o una anomalía.
1 Visibilidad

Una auditoría de HUMSEC emplea a 50 personas; sin embargo, solo 38 de ellas interactúan con el
vector y canal de prueba. Esto daría una visibilidad de 38.

Esto difiere de la visibilidad, en la que se determina la cantidad de objetivos existentes. En este

caso, el auditor debe contar cada acceso por punto de interacción único por sonda única.

En una auditoría PHYSSEC, un edificio con 2 puertas y 5 ventanas que se abren todas tiene un
Acceso de 7. Si todas las puertas y ventanas están selladas, entonces es un Acceso de 0 ya que
estos no son puntos por donde se pueda ingresar.

Para una auditoría COMSEC de redes de datos, el auditor cuenta cada respuesta de puerto como
un acceso, independientemente de cuántas formas diferentes pueda utilizar el auditor para sondear
ese puerto. Sin embargo, si un servicio no está alojado en ese puerto (un demonio o una aplicación),
todas las respuestas provienen de la pila IP. Por lo tanto, un servidor que responde con un SYN/
ACK e interactividad de servicio solo a uno de los puertos TCP escaneados y con un RST al resto
2 Acceso no tiene un recuento de accesos de 65536 (incluido el puerto 0), ya que 66535 de los puertos
responden con la misma respuesta de RST del núcleo.

Para simplificar, cuente solo los puertos con respuestas de servicio y solo una respuesta de pila IP,
independientemente de la cantidad de puertos que puedan iniciar este tipo de interactividad.

Con las auditorías de HUMSEC, esto es mucho más sencillo. Una persona que responde a una
consulta cuenta como un acceso con todos los tipos de consultas (todas las diferentes preguntas
que pueda hacer o las afirmaciones que haga cuentan como el mismo tipo de respuesta en el
mismo canal). Por lo tanto, una persona solo puede ser un acceso de 1 por canal y vector. Solo no
se cuenta una persona que ignore por completo la solicitud al no reconocer el canal.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
70 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Categoría Descripción

Esto difiere de la visibilidad, en la que se determina la cantidad de objetivos existentes. En este

caso, el auditor debe contar cada confianza por punto de interacción único por sonda única.

En una auditoría PHYSSEC, un edificio con 2 puertas internas que separan habitaciones y que
se abren tiene una Confianza de 2. Si esas puertas están selladas, entonces es una Confianza
de 0, ya que estos no son puntos por donde se pueda pasar.

3 Confianza
Para una auditoría COMSEC de redes de datos, el auditor cuenta cada tipo de reenvío de
servicio o de puerto como una confianza.

En las auditorías de HUMSEC, una persona que actúa como puerta de enlace para interactuar
con otras personas o acceder a una propiedad es un fideicomiso por canal. Por lo tanto, una
persona solo puede ser un fideicomiso de 1 por canal y vector. Solo no se contabiliza una
persona que no cumple con la solicitud de fideicomiso.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 71
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Controles
El siguiente paso para calcular el RAV es definir los Controles; los mecanismos de seguridad implementados para
Proporcionar seguridad y protección durante las interacciones.

Categoría Descripción

Contabilizar cada instancia de autenticación necesaria para obtener acceso. Esto requiere que la
autorización y la identificación constituyan el proceso para el uso correcto del mecanismo de
autenticación.

1 Autenticación
En una auditoría de PHYSSEC, si se requiere tanto una tarjeta de identificación especial como el
escaneo de la huella dactilar para obtener acceso, se suman dos para la autenticación. Sin embargo,
si Access solo requiere uno o el otro, entonces se cuenta solo uno.

Cuente cada instancia de los métodos utilizados para exigir responsabilidad y asegurar la
compensación para todos los activos dentro del alcance.

Un ejemplo básico de PHYSSEC es una señal de advertencia que amenaza con procesar a los
intrusos. Otro ejemplo común es el seguro de la propiedad. En un ámbito de 200 computadoras,
2 Indemnización una póliza de seguro general contra robo se aplica a las 200 y, por lo tanto, se trata de un recuento
de 200. Sin embargo, no confunda el método con la falla en el método. Una amenaza de
procesamiento sin la capacidad o la voluntad de procesar sigue siendo un método de indemnización,
sin embargo, tiene una limitación.

Cuente cada instancia de Acceso o Confianza en el alcance que estrictamente no permite que los
controles sigan la discreción del usuario o se originen fuera de sí mismo.
Esto se diferencia de ser una limitación de seguridad en el objetivo, ya que se aplica al diseño o
implementación de controles.

En una auditoría de redes de datos COMSEC, si se puede iniciar sesión tanto en HTTP como en
HTTPS, pero se requiere que el usuario haga esa distinción, no se contabiliza para Subjugation. Sin
embargo, si la implementación requiere el modo seguro de forma predeterminada, como un sistema
de mensajería interna de PKI, sí cumple con el requisito del control de Subjugation para ese ámbito.
3 Subyugación

De manera más simple, en HUMSEC, un proceso de no repudio donde la persona debe firmar un
registro y proporcionar un número de identificación para recibir un documento está bajo controles
de subyugación cuando el proveedor del documento registra el número de identificación, en lugar
de que lo haga el receptor, para eliminar el registro de un número falso con un número falso.

nombre.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
72 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Categoría Descripción

Cuente cada instancia de acceso o confianza en el ámbito que garantiza que no se produzcan
interrupciones en la interacción a través del canal y el vector, incluso en situaciones de falla total.
Continuidad es el término general para características como capacidad de supervivencia, equilibrio
de carga y redundancia.

4 En una auditoría PHYSSEC, si se descubre que una vía de entrada a una tienda queda bloqueada
Continuidad
de tal manera que no es posible ninguna vía de entrada alternativa y los clientes no pueden ingresar,
ese acceso no tiene continuidad.

En una auditoría de redes de datos COMSEC, si un servicio de servidor web falla debido a una
carga alta y un servidor web alternativo proporciona redundancia para que no se pierdan
interacciones, este acceso tiene continuidad.

Cuente cada instancia de acceso o confianza en el ámbito que no falla al abrirse o proporcionar
nuevos accesos en caso de falla de seguridad. En lenguaje común, "fallar de forma segura".

En una auditoría PHYSSEC donde 2 guardias controlan el acceso a una puerta, si se retira uno y el
guardia restante no puede abrir la puerta, entonces tiene resiliencia.
5 Resiliencia

En una auditoría de redes de datos COMSEC, si un servicio web que requiere un inicio de sesión o
una contraseña pierde la comunicación con su base de datos de autenticación, entonces se debe
denegar todo acceso en lugar de permitirlo para tener resiliencia.

Cuente cada instancia del acceso o confianza que proporciona un mecanismo de no repudio para
cada interacción a fin de garantizar que la interacción en particular ocurrió en un momento
determinado entre las partes identificadas. El no repudio depende de que la identificación y la
autorización se establezcan correctamente para que se aplique correctamente sin limitaciones.

En una auditoría PHYSSEC, el control de no repudio existe si la entrada a un edificio requiere una
cámara con un escáner biométrico de rostro para ingresar y cada vez que se utiliza, la hora de
entrada se registra junto con la identificación. Sin embargo, si se utiliza una tarjeta de acceso, el
control de no repudio requiere una cámara sincronizada con código de tiempo para asegurar el
6 No repudio registro de la identidad del usuario de la tarjeta y evitar que se trate de una implementación
defectuosa. Si se intenta abrir la puerta sin la tarjeta de acceso, el hecho de que la cámara
sincronizada no controle la puerta significaría que no todas las interacciones con la entrada tienen
el control de no repudio y, por lo tanto, no cuentan para este control.

En una auditoría de redes de datos de COMSEC, puede haber varios archivos de registro para el
no repudio. Un escaneo de puerto que interactúa en la pila IP se registra en un registro, mientras
que la interacción con el servicio web se registra en otro archivo de registro.
Sin embargo, como es posible que el servicio web no registre las interacciones del método POST,
el control aún se cuenta; sin embargo, también lo hace la limitación de seguridad.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 73
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Categoría Descripción

Cuente cada instancia de acceso o confianza en el ámbito que proporciona los medios para
mantener el contenido de las interacciones no reveladas entre las partes que interactúan.

Una herramienta típica para la confidencialidad es el cifrado. Además, la ofuscación del contenido
7 Confidencialidad de una interacción también es un tipo de confidencialidad, aunque con defectos.

Sin embargo, en HUMSEC, un método de confidencialidad puede incluir susurrar o usar señales
con las manos.

Cuente cada instancia de acceso o confianza en el ámbito que proporciona los medios para
mantener el método de interacciones no divulgadas entre las partes que interactúan. Si bien “ser
privado” es una expresión común, la frase es un mal ejemplo de privacidad como control de pérdida
porque incluye elementos de confidencialidad. Como control de pérdida, cuando algo se hace “en
privado” significa que solo “el acto” es privado, pero el contenido de la interacción puede no serlo.

Una herramienta típica de la Privacidad es el ocultamiento de la interacción, es decir, que ésta se

8 Privacidad produzca fuera de la visibilidad de terceros. La confusión de los medios de interacción, denominada
ofuscación, es otro método de aplicación del control de la Privacidad.

En HUMSEC, un método de privacidad puede ser simplemente llevar la interacción a una habitación
cerrada, lejos de otras personas. En las películas, vemos técnicas para crear el control de privacidad
colocando dos maletas idénticas una al lado de la otra, se produce algún tipo de incidente que crea
confusión y las dos personas intercambian las maletas aparentemente a plena vista.

Cuente cada instancia de acceso o confianza en el ámbito que pueda garantizar que el proceso de
interacción y acceso a los activos tenga carácter definitivo y no pueda corromperse, detenerse,
continuarse, redirigirse ni revertirse sin que las partes involucradas lo sepan. La integridad es un
proceso de control de cambios.

En las redes de datos COMSEC, el cifrado o un hash de archivo pueden proporcionar control de
integridad sobre el cambio del archivo en tránsito.
9 Integridad
En HUMSEC, la segregación de funciones y otros mecanismos de reducción de la corrupción
permiten controlar la integridad. Para garantizar la integridad del personal es necesario que dos o
más personas participen en un único proceso para garantizar la supervisión de dicho proceso. Esto
incluye que no exista un acceso maestro a todo el proceso. No puede haber ninguna persona con
acceso total ni una llave maestra para todas las puertas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
74 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Categoría Descripción

Cuente cada instancia de Acceso o Confianza que tiene un registro o realiza una notificación
cuando aumenta la porosidad no autorizada y no intencionada para el vector o las restricciones y
controles se ven comprometidos o corrompidos.

En las redes de datos COMSEC, cuente cada servidor y servicio que un sistema de detección de
intrusiones basado en red monitorea. O cuente cada servicio que mantiene un registro monitoreado
10 Alarm
de interacción. Los registros de acceso cuentan, incluso si no se utilizan para enviar una alerta de
notificación de inmediato, a menos que nunca se monitoreen. Sin embargo, los registros que no
están diseñados para usarse para tales notificaciones, como un contador de paquetes enviados y
recibidos, no se clasifican como una alarma ya que hay muy pocos datos almacenados.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 75
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Limitaciones
Finalmente, se verifican las limitaciones cuando es posible. Los valores de cada limitación dependen de la porosidad.
y controles. Esto es diferente de la perspectiva de riesgo más común donde una vulnerabilidad puede ser
Se le asigna un nivel de riesgo en función del daño que puede causar, lo fácil que es hacerlo y la distancia en la que se encuentra.
el ataque. Por lo tanto, los valores de limitación se calculan en función de la porosidad y los controles de la
objetivo en el que se pueden encontrar.

Categoría Descripción

Cuente por separado cada falla o error que desafíe las protecciones mediante las cuales una
persona o un proceso puede acceder, negar el acceso a otros u ocultarse a sí mismo o a sus
activos dentro del alcance.

En PHYSSEC, una vulnerabilidad puede ser tan simple como una puerta de vidrio, una puerta
de metal corroída por el clima, una puerta que se puede sellar introduciendo monedas en el
espacio entre ella y su marco, un equipo electrónico no sellado contra plagas como hormigas
o ratones, una unidad de CD de arranque en una PC o un proceso que permite a un empleado
tomar un bote de basura lo suficientemente grande como para ocultar o transportar activos
fuera del alcance.

En HUMSEC, una vulnerabilidad puede ser un sesgo cultural que no permite a un empleado
cuestionar a otros que parecen fuera de lugar o una falta de capacitación que lleva a una
nueva secretaria a entregar información comercial clasificada solo para uso interno.

En la seguridad de datos de COMSEC, una vulnerabilidad puede ser una falla en el software
que permite a un atacante sobrescribir el espacio de memoria para obtener acceso, una falla
1 Vulnerabilidad
de cálculo que permite a un atacante bloquear la CPU al 100% de uso o un sistema operativo
que permite que se copien suficientes datos en el disco hasta que ya no pueda funcionar.

En las telecomunicaciones COMSEC, una vulnerabilidad puede ser una falla en el sistema de
teléfonos públicos que permite que sonidos a través del receptor imiten la caída de monedas,
una cabina telefónica que permite que cualquiera acceda a la línea telefónica de cualquier otra
persona, un sistema de correo de voz que proporciona mensajes desde cualquier teléfono en
cualquier lugar, o una máquina de FAX que puede ser sondeada remotamente para reenviar lo
último en la memoria al número de la persona que llama.

En SPECSEC, una vulnerabilidad puede ser un hardware que puede sobrecargarse y quemarse
por versiones de mayor potencia de la misma frecuencia o una frecuencia cercana, un receptor
estándar sin configuraciones especiales que puede acceder a los datos de la señal, un receptor
que puede ser forzado a aceptar una señal de terceros en lugar de la deseada, o un punto de
acceso inalámbrico que interrumpe las conexiones cerca de un horno microondas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
76 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Categoría Descripción

Cuente cada falla o error en los controles de interactividad: autenticación, indemnización, resiliencia,
subyugación y continuidad.

En PHYSSEC, una debilidad puede ser una cerradura de puerta que se abre cuando una tarjeta
queda encajada entre ella y el marco de la puerta, un generador de respaldo sin combustible o un
seguro que no cubre daños por inundaciones en una zona inundable.

En HUMSEC, una debilidad puede ser una falla en el proceso de un segundo guardia que toma el
puesto del guardia que persigue a un intruso o un clima cultural dentro de una empresa que permite
que amigos ingresen a espacios restringidos.

En la seguridad de datos de COMSEC, una debilidad puede ser un inicio de sesión que permite
2 Debilidad
intentos ilimitados o una granja web con DNS round­robin para equilibrar la carga, pero cada sistema
también tiene un nombre único para el enlace directo.

En las telecomunicaciones COMSEC, una debilidad puede ser un PBX que todavía tiene las
contraseñas de administración predeterminadas o un banco de módems para acceso remoto
telefónico que no registra los números de las personas que llaman, la hora y la duración.

En SPECSEC, una debilidad puede ser un punto de acceso inalámbrico que autentica usuarios
basándose en direcciones MAC (que pueden ser falsificadas) o una etiqueta de seguridad RFID que
ya no recibe señales y, por lo tanto, falla al “abrirse” después de recibir una señal de una fuente de
alta potencia.

Cuente cada falla o error en los controles de proceso: no repudio, confidencialidad, privacidad,
integridad y alarma.

En PHYSSEC, una preocupación puede ser un mecanismo de bloqueo de puerta cuyos controles
de operación y tipos de llaves son públicos, un generador de respaldo sin medidor de energía o
indicador de combustible, un proceso de equipo que no requiere que el empleado firme la salida de
los materiales cuando los recibe, o una alarma contra incendios que no es lo suficientemente fuerte
para ser escuchada por trabajadores de máquinas con tapones para los oídos.

En HUMSEC, una preocupación puede ser una falla del proceso de un guardia que mantiene el
mismo horario y rutina o un clima cultural dentro de una empresa que permite a los empleados usar
salas de reuniones públicas para negocios internos.

3 Preocupación
En la seguridad de datos de COMSEC, un problema puede ser el uso de certificados de servidor
web generados localmente para HTTPS o archivos de registro que registran solo los participantes
de la transacción y no la fecha y hora correctas de la transacción.

En las telecomunicaciones COMSEC, un problema puede ser el uso de una máquina de FAX para
enviar información privada o un sistema de correo de voz que utiliza tonos táctiles para ingresar un
PIN o una contraseña.

En SPECSEC, un problema puede ser un punto de acceso inalámbrico que utiliza un cifrado de
datos débil o un abridor de puertas infrarrojo que no puede leer el remitente bajo la lluvia.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 77
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Categoría Descripción

Cuente cada acción, falla o error injustificable que proporcione visibilidad directa o indirecta de los
objetivos o activos dentro del canal de alcance elegido.

En PHYSSEC, una exposición puede ser una ventana que permite ver activos y procesos o un
medidor de energía que muestra cuánta energía utiliza un edificio y su fluctuación a lo largo del
tiempo.

En HUMSEC, una exposición puede ser un guardia que permite a todos los visitantes ver la lista de
nombres en la hoja de registro o un operador de la empresa que informa a quienes llaman que una
persona en particular está enferma o de vacaciones.

En la seguridad de datos de COMSEC, una exposición puede ser un banner descriptivo y válido
4 Exposición
sobre un servicio (los banners de desinformación no son exposiciones) o una respuesta de eco
ICMP de un host.

En telecomunicaciones COMSEC, una exposición puede ser un directorio automatizado de

empresas ordenado alfabéticamente, que permite a cualquier persona recorrer todas las personas
y números, o una máquina de FAX que almacena los últimos números marcados.

En SPECSEC, una exposición puede ser una señal que interrumpe otra maquinaria o un dispositivo
infrarrojo cuyo funcionamiento es visible mediante cámaras de vídeo estándar con capacidad
nocturna.

Contar cada elemento no identificable o desconocido que no pueda tenerse en cuenta en

operaciones normales, generalmente cuando no se puede entender la fuente o el destino del
elemento. Una anomalía puede ser una señal temprana de un problema de seguridad. Dado que
los elementos desconocidos son elementos que no se pueden controlar, una auditoría adecuada
requiere anotar todas y cada una de las anomalías.

En PHYSSEC, una anomalía puede ser el descubrimiento de pájaros muertos en el techo de un

edificio alrededor de equipos de comunicaciones.

En HUMSEC, una anomalía pueden ser preguntas que hace un guardia que pueden parecer
5 Anomalía
irrelevantes para el trabajo o para una conversación informal estándar.

En la seguridad de datos de COMSEC, una anomalía puede ser una respuesta correcta a una
sonda desde una dirección IP diferente a la que se sondeó o se esperaba.

En las telecomunicaciones COMSEC, una anomalía puede ser una respuesta de módem de un
número que no tiene módem.

En SPECSEC, una anomalía puede ser una señal local que no se puede localizar correctamente y
que no causa ningún daño conocido.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
78 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

4.4 La fórmula de seguridad operacional

El RAV se deriva de tres categorías definidas dentro del alcance: Seguridad operativa, controles y limitaciones. Para
comenzar, primero debemos agregar y asociar toda nuestra información de entrada en las categorías adecuadas
para cada variable de entrada.

La ecuación rav requiere que a cada una de las categorías se le asigne un valor base logarítmico para escalar los
tres factores de Seguridad Actual de acuerdo con el alcance.

La información contenida en el RAV se compone de cómo se equilibran las operaciones con los controles y las limitaciones. No hay "pesos"
que sesguen los resultados, lo que deja una cuantificación flexible de la superficie de ataque que permite compararla con la seguridad de cualquier
otra cosa, sin importar el tamaño, el vector o el canal.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 79
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Porosidad
La Seguridad Operacional, también conocida como Porosidad del alcance, es el primero de los tres factores de Seguridad
Actual que se deben determinar. Se mide inicialmente como la suma de la visibilidad ( PV ), el acceso ( PA ) y la confianza
( PT ) del alcance.

OpSecsum  PPP
TAV

Sin embargo, al calcular el rav es necesario determinar el valor base de seguridad operacional, OpSecbase . El valor base de
seguridad operacional se obtiene mediante la ecuación

2 
Base de seguridad operativa 1001log  Suma de seguridad operativa
.

Como el logaritmo de 0 no está definido en el cálculo, necesitábamos incluir aquí el 1+100. El logaritmo de 1 es 0. Por lo tanto, si tenemos 0
porosidad y queremos expresar esta falta de interacción como una seguridad perfecta de 100 rav, entonces necesitábamos agregar +1 a la
ecuación. Sin el 1+100, tendríamos números indefinidos en el caso de que las sumas de cualquiera de esos factores sean 0. Esto es requerido
por la metodología porque la ausencia de interacciones representa una seguridad perfecta y, por lo tanto, el logaritmo debe ser igual a 0 para
proporcionar el 100 rav.

4.5 La fórmula de los controles

El siguiente paso para calcular el RAV es definir los controles de pérdidas, es decir, los mecanismos de seguridad
implementados para proteger las operaciones. Primero, se debe determinar la suma de los controles de pérdidas, LCsum ,
sumando las 10 categorías de control de pérdidas.

Controles Clase A
Autenticación
LCAu
Indemnización
LCId
Resiliencia
LCRe
Subyugación Universidad de California en Los Ángeles

Continuidad LCCt
Clase B
No repudio LCNR
Confidencialidad
LCCf
Privacidad LCPr
Integridad LCI
Alarma
LCA

Por lo tanto, la suma de control de pérdidas LCsum se da como

 LCLCLCLLCLCLCLCLCLCLCLCLC Cf Al.
suma Au Identificación Re Su Connecticut NR Pr Él

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
80 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Controles faltantes
Dado que la combinación de cada uno de los 10 controles de pérdida equilibra el valor de una pérdida de OpSec (visibilidad, acceso, confianza),
es necesario determinar la cantidad de controles faltantes, MCsum , para evaluar el valor de las limitaciones de seguridad. Esto debe hacerse
de forma individual para cada una de las 10 categorías de control de pérdida.
Por ejemplo, para determinar los controles faltantes para la autenticación ( MCAu ), debemos restar la suma de los controles de autenticación

( LCAu ) del ámbito de OpSecsum . Sin embargo, los controles faltantes nunca pueden ser menores que cero.

La ecuación para determinar los controles faltantes para la autenticación ( MCAu ) viene dada por

SI OpSecsum ­ LCAu 0
ENTONCES MCAu 0

DE LO CONTRARIO MCAu OpSecsum  LCAu .

Luego, los totales de control faltante resultantes para cada uno de los 10 controles de pérdida se deben sumar para llegar al valor total
de control faltante ( MCsum ), como se ve a continuación.

Suma MC
 MCMCMCMMCMCMCMCMCMC
Au Re Su NR Él Pr
Identificación Connecticut
Cf Alabama

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 81
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Controles verdaderos

Los controles verdaderos (TCsum ) son el inverso de los controles faltantes, lo que significa que los controles verdaderos para cada control individual también

deben calcularse antes de que los resultados se puedan contabilizar en TCsum .

La ecuación para determinar los controles verdaderos para la autenticación (TCAu ) está dada por

TCAu OpSecsum  MCAu

Luego, los totales de Control Verdadero resultantes para cada uno de los 10 Controles de Pérdida se deben sumar para llegar al valor de Control Verdadero total
(TCsum ), como se ve a continuación.

TCsum  TCTCTCTCTCTCTCTCTCTC
Au Re
Identificación Su Connecticut NR Él Pr Cf Alabama

Los controles verdaderos se utilizan para medir la ubicación ideal de los controles. El valor base también ayuda a eliminar la influencia de una ubicación

desproporcionada de los controles en la seguridad. El valor base de los controles verdaderos ( TCbase ) se expresa como:

TCbase  (1001
2
log )1.0
 OpSecsum 
MCsum .

Basándose en la misma idea que los controles verdaderos, la cobertura verdadera (TCvg) se puede utilizar para medir el porcentaje de controles implementados
en relación con la cantidad y la ubicación óptimas de los controles. La cobertura verdadera se obtiene a partir de los totales de controles faltantes y la siguiente
ecuación:

SI OpSecsum 0

ENTONCES TCvg 0
MC
DEMÁS Tcvg 
1 suma
.
10 Seguridad operacional
suma

Controles completos

Por otro lado, los controles completos tienen en cuenta todos los controles implementados independientemente de una distribución equilibrada. Este valor es
importante para medir el valor de la autenticación de dos factores, por ejemplo, y otras instancias de defensa en profundidad para la misma visibilidad, acceso o

confianza. El valor base de los controles completos ( FCbase ) se proporciona de la siguiente manera:

2 
FCbase 101log  LCsuma

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
82 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

4.6 La fórmula de las limitaciones

A continuación, se ponderan individualmente las limitaciones. La ponderación de las vulnerabilidades, debilidades y preocupaciones se basa
en una relación entre la porosidad u OpSecsum , los controles de pérdida y, en el caso de las exposiciones y las anomalías, la existencia de
otras limitaciones también juega un papel. Una exposición o anomalía no plantea problemas por sí sola a menos que también esté presente
una vulnerabilidad, debilidad o preocupación. Piense en una exposición como un puntero. Si hay un puntero que no lleva a ninguna parte, o
en este caso no conduce a nada explotable (vulnerabilidad, debilidad, preocupación) y se tienen en cuenta todos los controles, entonces, en
el momento de la prueba, la exposición no tiene ningún efecto sobre la seguridad y, por lo tanto, no tiene valor en el rav.

La siguiente tabla de valores se utiliza para calcular la variable SecLimsum , como paso intermedio entre las entradas de Limitación de seguridad y la variable

SecLimbase , que es la entrada básica de Limitaciones de seguridad para la ecuación rav.

SI OpSecsum 0

ENTONCES MCvg 0
MC 1.0
suma
DEMÁS MCvg
Seguridad operacional
suma

Aporte
Vulnerabilidad

Valor ponderado
Seguridad operacional  MC
suma suma
 Variables

MCsum : suma de los controles faltantes

Vuelta al cole

Debilidad  Seguridad operacional

Seguridad operacional  MC
suma A
suma
 MCA : suma de controles faltantes en la clase de control A

LW
Inquietud  Seguridad operacional

Seguridad operacional  MC
suma B
suma
 MCB : suma de controles faltantes en la clase de control B

LC

Exposición    PV
Seguridad operacional

 LLLMCvgPP
: suma
AV CWVde visibilidad
suma

EL Seguridad operacional
PA : suma de accesos


suma

MCvg : Porcentaje de cobertura faltante

Anomalía  LLLMCvgP
T­CWV PT : suma de Visibilidad
LA Seguridad operacional MCvg : Porcentaje de cobertura faltante
suma

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 83
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Base de limitaciones de seguridad

Luego, SecLimsum se calcula como el total agregado de cada entrada multiplicado por su valor ponderado correspondiente, según se define en la tabla anterior.

SecLimsum L
 
Operador de seguridad MC
suma suma  L
Operadorsuma
de seguridadA   L
Operadorsuma
de seguridadB 
 
V MC  Yo MC  do

Seguridad operacional Seguridad operacional Seguridad operacional
suma suma suma

L AV CWV
LLLMCvgPP
L
  LLLMCvgP
T­CWV 

mi
Seguridad operacional
  A
Seguridad operacional
suma suma

La ecuación base de limitaciones de seguridad se da como:

2 
SecLimbase 1001log  SecLimsum

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
84 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

4.7 La fórmula de seguridad real

Esta es la parte final para utilizar todos los cálculos anteriores de tres maneras diferentes.

Delta de seguridad actual

El Delta de Seguridad Actual es útil para comparar productos y soluciones estimando previamente el cambio (delta) que el producto o solución
generaría en el alcance. Podemos hallar el Delta de Seguridad Actual, ActSec con la fórmula:
,

ActSec FCbase  OpSecbase  SecLimbase .

Protección verdadera

Se puede utilizar como una expresión simplificada para la cobertura óptima de un alcance determinado, donde 100 significa una relación óptima
entre la porosidad, los controles reales y las limitaciones de seguridad. Se proporciona protección real.
como:

TruPro 100 TCbase  OpSecbase  SecLimbase

Seguridad actual

Para medir el estado actual de las operaciones con los controles aplicados y las limitaciones detectadas, se requiere un cálculo final para definir
la seguridad real. Como lo implica su nombre, este es el valor total de la seguridad que combina los tres valores de seguridad operativa,
controles y limitaciones para mostrar el estado actual de la seguridad.

, real de seguridad proporcionado como un hash de las tres secciones. Un valor rav de 100 significa
Seguridad real (total), ActSec es el estado
un equilibrio perfecto de seguridad; sin embargo, la seguridad real no es un valor porcentual real.
También es posible que se obtengan puntuaciones superiores a 100, lo que significa que el alcance probado tiene implementados más
controles de los necesarios, lo que también podría ser una prueba de gastos excesivos. La ecuación final de RAV para la seguridad real se da
como:

ActSec 100 
ActSec 
1
OpSecbase FCbase 
 OpSecbase SecLimbase FCbase  SecLimbase 100


Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 85
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Confiar en todos es inseguro, pero no confiar

en nadie es ineficiente.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
86 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 5 – Análisis de la confianza

“Si pudieras tomar una pastilla que te hiciera más confiado, ¿lo harías?” Así empezó un estudio informal de
ISECOM para ayudar a la gente a entender mejor cómo se hace un mal uso del concepto de confianza. El
público en general responde que no a esta pregunta. Un profesional de seguridad respondió: “Sí, pero solo
si todos los demás también tienen que tomarla”.

La confianza puede ser tanto un problema como una solución. Es un problema cuando pone a la seguridad en una posición comprometida. Al
igual que el concepto de energía potencial en física, la confianza crea una concentración de autorización que puede explotar y convertirse en
un gran problema si la confianza falla o si el objetivo de confianza es engañado y perjudica al que la dio. Sin embargo, también puede reducir
la necesidad de una re­autenticación continua, posiblemente redundante, lo que aumenta la eficiencia de las operaciones. Por esa razón, la
confianza a menudo se ve como un protocolo de "autenticación una vez y marcharse". Esto se ve con más frecuencia en Seguridad Humana,
donde los departamentos de Recursos Humanos investigan a un candidato antes de contratarlo y luego esa persona tiene acceso continuo a
los recursos hasta que ya no es un empleado. La re­autenticación se realiza entonces en raras ocasiones o esporádicamente y rara vez con la
misma profundidad que cuando fue contratado.

En la seguridad operacional, la confianza es simplemente un factor que contribuye a la porosidad, otra interacción que controlar. Se diferencia
del acceso (la otra forma de interacción) en cómo se relaciona con otros objetivos dentro del alcance. Así, mientras que el acceso es la
interacción entre dos lados de un vector que entran y salen del alcance, la confianza se mide como las interacciones entre los objetivos dentro
del alcance. Sin embargo, la mayoría de las personas no utilizan la confianza de manera tan concreta. La confianza suele aplicarse a una
persona o un elemento específico y a un acto específico, como "¿Puedo confiar en que este empleado entregará antes de la fecha límite?" o
"¿Puedo confiar en esta computadora?". Hay respuestas correctas para estas preguntas, pero las personas a menudo carecen de las
habilidades necesarias para cuantificar el nivel de confianza para esa persona u objeto, lo que nos permitiría tomar una decisión más racional
y lógica. Sin embargo, para cuantificar la confianza, primero debemos comprenderla.

5.1 Entendiendo la confianza

La confianza es una decisión. Aunque algunas personas afirman que es una emoción, como el amor, o un sentimiento, como el dolor, es
claramente una cualidad compleja con la que nacemos los humanos. A diferencia de una emoción o un sentimiento, podemos elegir confiar o
no confiar en alguien o en algo, incluso si nos parece mal hacerlo. Parece que somos capaces de racionalizar de una manera que sustituya lo
que sentimos acerca de confiar en un objetivo. Esto significa que podemos cuantificarla aplicando un proceso lógico. También significa que
podemos asignar valores de confianza a objetos y procesos, así como a personas, en función de estos valores. Esto aporta un nuevo poder a
quienes pueden analizar la confianza y tomar decisiones basadas en ese análisis. También significa que los analistas con esta habilidad
pueden controlar mejor los sesgos, identificar falacias (especialmente las que provienen de fuentes autorizadas o confiables) y manejar lo
desconocido para generar informes transparentes.
Sin embargo, es importante tener en cuenta que, una vez cuantificada la confianza, esta es solo un vehículo para racionalizarla. No hará que
algo parezca digno de confianza ahora o en el futuro. Algunas personas tienen fuertes sentimientos de aversión o atracción que pueden estar
en desacuerdo con los hechos.

Como parte de la seguridad operacional, la confianza es una parte de la porosidad de un objetivo. Mientras que la seguridad es como un muro
que separa las amenazas de los activos, la confianza es un agujero en ese muro. Es donde el objetivo acepta la interacción de otros objetivos
dentro del alcance. Sin embargo, las personas tienden a utilizar controles operativos inadecuados o incompletos con sus fideicomisos, como la
autenticación que se ha realizado con una identificación incorrecta, como una voz por teléfono, una tarjeta de presentación o incluso
simplemente la suposición de que, debido a que una persona está en la habitación, está autorizada a estar allí. Esto expone a las personas al
fraude y al engaño. Se requiere el uso de controles adicionales para proteger un fideicomiso, para asegurar su integridad y resiliencia.

Lamentablemente, si bien el uso de más controles funciona con objetos y procesos, puede que no funcione entre personas. Muchas veces, las
normas sociales consideran controles que van más allá de la simple autenticación, como la coincidencia de un rostro o

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 87
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Voz con una identidad que resulta ofensiva para la persona en la que se debe confiar. La sociedad a menudo exige que seamos más confiados
como individuos para beneficiar a la sociedad en su conjunto y, a veces, a expensas de la protección individual de todos.

Como se dijo antes, la confianza operativa se mide como algo negativo que surge de una interacción entre dos entidades en un ámbito. Cuando
una confianza no tiene controles, es lo que la gente llama "confianza ciega", que puede ser buena para las relaciones y puede acelerar las
interacciones, pero es mala para la seguridad operativa. Las personas generalmente aplican controles a las confianzas incluso si no lo
consideran así en ese momento. Algunos controles tienen inherentemente más peso que otros según la situación y la necesidad. Al seleccionar
a una persona de la que necesitan depender, pueden dar un mayor valor a la integridad y la resiliencia. Al realizar una transacción financiera,
pueden dar un mayor valor a la autenticación, la continuidad y la confidencialidad. Pueden dar un mayor valor a la alarma y la subyugación
para el asesoramiento sobre un producto a menos que sea una receta médica, en cuyo caso preferirían la privacidad y el no repudio. Sin
embargo, siendo realistas, en realidad no están dando más valor a controles particulares. En cambio, en realidad están evaluando las diez
propiedades de la confianza y buscando esos controles específicos para la comodidad de sus decisiones de confianza. El uso de las
propiedades de la confianza les permite tomar una decisión de confiar o no, incluso cuando la información que tienen sobre el objetivo es
incompleta. Dado que la toma de decisiones en materia de confianza sin información ni práctica es una apuesta peligrosa, lo mínimo que puede
proporcionar un proceso formal como la aplicación de las propiedades de la confianza es informar al responsable de la toma de decisiones
exactamente cuánto desconoce y permitirle buscar más información antes de continuar. Esto significa que la verdadera necesidad de poder
cuantificar la confianza operativa surge cuando debemos confiar en muchas incógnitas para determinar y racionalizar la confianza.

Las propiedades de confianza son los elementos cuantificables y objetivos que se utilizan para generar confianza. Podemos decir que estas
propiedades son las que nos dan “razones para confiar”. Estas propiedades deben convertirse en reglas de referencia basadas en el objetivo y
la situación que estamos verificando. Desafortunadamente, existen muchas propiedades de confianza ilógicas y se usan con demasiada
frecuencia, lo que hace que sea más difícil para nosotros tomar decisiones de confianza adecuadas sin sentirnos mal . Sin embargo, es
precisamente la parte del sentimiento la que nos hace más propensos a cometer errores.
Durante la investigación, se descubrieron muchas propiedades fiduciarias potenciales que se usan comúnmente e incluso las regulaciones
oficiales, gubernamentales y de la industria recomiendan, sin embargo, no aprobaron las pruebas lógicas y se descartaron de nuestro conjunto
de propiedades, dejando solo diez.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
88 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

5.2 Falacias en la confianza

Lamentablemente, la mayoría de las personas no entienden ni utilizan bien la confianza. Existen muchos métodos ilógicos para la confianza que
se utilizan de forma popular. Dos ejemplos de las propiedades de confianza más comunes y falaces son la componibilidad y la transitividad. Estas
propiedades son utilizadas de forma popular por las personas para tomar decisiones de confianza sobre lo desconocido. En la componibilidad, una
persona toma una decisión de confianza basándose en lo que una gran cantidad de personas tienen que decir sobre la cosa o la persona en
cuestión, incluso si no se confía en esas personas individualmente.
En esencia, una persona acepta las opiniones del grupo como propias. Esto es similar a la presión que ejercen los grupos sociales o políticos y los
medios de comunicación. La razón por la que esto es ilógico es que las experiencias individuales de los demás, especialmente de los desconocidos,
son todas relativas y no pueden verificar la fiabilidad de los acontecimientos futuros.

Ejemplos comunes de uso falaz de confianza, primero con Componibilidad y segundo con Transitividad.

El otro uso falaz común de la confianza es la transitividad. Se da cuando una persona acepta la decisión de confiar en otra persona de confianza.
También se conoce como la cadena de confianza: confías en Alice y Alice confía en Jack, por lo tanto, puedes confiar en Jack. Sin embargo, la
confianza transitiva también es ilógica porque puedes confiar en Alice para algunas cosas, pero tal vez no para las mismas cosas por las que ella
confía en Jack. También existe la posibilidad de que Alice haya recurrido a la confianza para obtener algún beneficio emocional que no está
disponible para ti.

Las personas que a menudo confían en su instinto para tomar decisiones de confianza son elogiadas cuando tienen razón, como si tuvieran un
sentido secreto y poderoso por encima de otros seres humanos. Sin embargo, además de la suerte, algunas personas son mejores prestando
atención a los detalles, viendo microexpresiones emocionales en los rostros y aplicando la lógica rápidamente a situaciones comunes que ellos
mismos podrían no ser capaces de expresar verbalmente, pero que sí sienten que están mal. Estas personas aprendieron a hacer esto de forma
natural y lo desarrollaron con una experiencia llena de ensayo y error que no es realmente obvia para ellos, como tampoco nadie se da cuenta de
los millones de pequeñas decisiones que toman cada día y sus consecuencias. Las propiedades de la confianza permiten a las personas comunes
que no tienen esta capacidad natural analizar cualquiera de sus decisiones de confianza con habilidad, distanciándose de su propio instinto visceral
subdesarrollado hasta que pueden reacondicionarse para hacerlo automáticamente, con fluidez, agudizando sus instintos hasta que funcionan
"desde el instinto".

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 89
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

5.3 Las diez propiedades del fideicomiso

Las diez propiedades de confianza para realizar un análisis de confianza adecuado son:

Propiedad fiduciaria Descripción

¿El número de personas en las que se puede confiar? ¿Se debe confiar en una sola persona o
en muchas? ¿Se debe confiar en un grupo que tome decisiones colectivas?
1 Tamaño

El vector (dirección) de la confianza. La confianza puede ser unidireccional (asimétrica) y estar

definida en función de en qué dirección debe circular la confianza o en ambas direcciones
2 Simetría (simétrica). Una persona que también debe confiar en usted tiene que considerar la reciprocidad
que se deriva de romper la confianza.

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

También llamado control, la cantidad de influencia sobre el alcance por parte del operador.
4 Subyugación

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

5 Consistencia

La cantidad y el aviso oportuno del cambio dentro del objetivo.

6 Integridad

Las compensaciones de una seguridad suficiente son la compensación para quien deposita la
confianza o el castigo para quien la rompe. Es un valor que se asigna a la confianza
7 Compensaciones
depositada en el destinatario.

La compensación financiera del riesgo, la cantidad de ganancia o beneficio por la cual el riesgo
de depositar la confianza en el objetivo es suficiente para compensar el riesgo de fracaso en la
8 Valor
confianza.

El número de otros elementos que actualmente proporcionan recursos para el objetivo, ya sea
a través de interacciones directas o indirectas, similar a la Intervención del Proceso de Cuatro
9 Componentes
Puntos.

La cantidad de separación entre el objetivo y el entorno externo.

10 Porosidad

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
90 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

5.4 Las reglas del fideicomiso

El uso de las propiedades de confianza nos permite crear únicamente reglas cuantificables, no reglas “suaves” que no pueden fundamentar el
nivel de confianza ni alterarlo con un peso emocional sesgado. Sin embargo, las propiedades por sí solas son inútiles si no pueden convertirse
en propiedades cuantificables, objetivas o comprensibles para la persona común que no necesariamente esté involucrada en el campo de la
seguridad. Por lo tanto, todavía necesitamos convertir las propiedades de confianza en reglas de confianza, cálculos de operaciones
directamente relevantes realizadas a partir de todas las propiedades de confianza. Lo hacemos en forma de preguntas donde las respuestas
son números imparciales que se utilizarán para crear un porcentaje para una comprensión más fácil y que coincida con nuestro uso común de
calificadores de confianza en el lenguaje normal como casi, a veces, siempre y nunca.

Al crear las reglas de confianza a partir de las propiedades de confianza, es importante tener en cuenta que las decisiones de confianza no son
lineales. No se puede construir hacia la confianza en un orden particular o incluso un sistema de valores de esfuerzo donde se pueda determinar
que un nivel requiere más esfuerzo que otro. En términos metodológicos, parece irracional cuando se calcula. Por lo tanto, una decisión de
confiar puede concluirse con una respuesta a solo una de las siguientes pruebas que componen las reglas de confianza. Sin embargo, hacerlo
es nuestra elección consciente de generar confianza cuando el cálculo dice específicamente que no. Esto puede tener más sentido en una
situación de vida o muerte donde el resultado de la confiabilidad es muy bajo pero el Valor de la Recompensa (la vida de uno) es tan
increíblemente grande que no se puede hacer otra elección.

Las reglas de confianza deben crearse específicamente para el objetivo. Si bien esto puede parecer complicado, es posible crear reglas de
confianza genéricas y específicas para cada tema que se adapten al propósito. El beneficio de esto es que las propiedades de confianza
pueden convertirse en reglas que se adapten a cualquier propósito y situación en la que uno deba tomar una decisión de confianza sobre otra
persona, cosa, proceso, sistema o acción. Con la práctica, estas reglas de confianza se pueden crear de manera automática y muy rápida
como parte del proceso de decisión, centrándose solo en las reglas que se pueden responder y descubriendo aquellas para las que no puede
haber una respuesta conocida con la información disponible.

La aplicación de las reglas de confianza en pruebas de verificación específicas que proporcionan una cantidad es buena, pero lo ideal es
determinar una cantidad finita. Una cantidad infinita puede ser demasiado relativa para el evaluador y no proporciona las restricciones
necesarias para expresar el resultado en un porcentaje. Por ejemplo, para aplicar la tercera propiedad, la transparencia, los componentes
deben contarse como indexados de modo que haya una cantidad finita. Por lo tanto, las partes de una computadora pueden tener un número
final antes de que la computadora esté completamente construida y un proceso puede tener un número preciso y finito de pasos antes de que
se complete. Sin embargo, para las personas, esto puede no ser tan fácil de hacer, pero es posible si se aplica correctamente a la situación.
En el caso de una autorización de seguridad, puede contar todas las relaciones dentro de un rango de tiempo determinado y, de ellas, el
número de las que son con personas que tienen antecedentes penales. Esto permite un número finito, aunque sea bastante grande. Luego,
puede que desee completar otras pruebas específicas de la tercera regla, ya que es posible que solo se obtenga un tipo de influencia. Otros
factores pueden ser las necesidades financieras, la experiencia laboral, las membresías, las convicciones y cualquier otra cosa que dé una
buena idea de cuán transparente es esa persona. Sin embargo, el cálculo final debe ser la suma total de todas las pruebas que proporcionarán
un porcentaje único de transparencia para esa regla.

El porcentaje resultante para cada regla de confianza se puede ver individualmente para mostrar dónde se deben aplicar controles para mejorar
o mantener los niveles necesarios de confiabilidad. Esto también puede mostrar dónde se deben realizar mejoras antes de que se pueda
considerar una confianza. Por ejemplo, un análisis de confianza para una campaña militar costosa y difícil puede mostrar que la regla cuatro,
subyugación, está en el 10% porque algunos de los participantes necesarios son civiles y no están bajo control militar. Esto brinda a los
operadores del teatro de operaciones de la campaña información específica y procesable para hacer los ajustes necesarios para llevar ese
porcentaje a un nivel que sea aceptable o, de lo contrario, aplicar más controles para garantizar mejor el cumplimiento de esos miembros civiles.

Otro resultado del análisis de los porcentajes de las reglas de confianza individuales es que las incógnitas se vuelven claramente...

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 91
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Es obvio porque cuanto menos se sepa, menor será el porcentaje. Esto significa que las incógnitas serán del 0 % o muy
cercanas a él.

Sin embargo, la métrica final es la media de todos los porcentajes. Esto proporciona una visión general que se puede tener
racionalmente del objetivo de la confianza. Esto es especialmente útil cuando es difícil tomar una decisión de confianza
debido a prejuicios personales. El uso de reglas de confianza en el análisis de seguridad formal, así como en la toma de
decisiones habitual, puede minimizar en gran medida los prejuicios y los errores. Por lo tanto, el analista debe practicar esta
habilidad para poder aplicarla rápidamente y poder usarla incluso en situaciones de alta presión o de emergencia donde es
necesaria una decisión rápida y una decisión incorrecta es una tragedia.

Ejemplo de reglas de confianza

Este es un ejemplo de reglas genéricas de confianza que cualquiera puede emplear para tomar mejores decisiones de
contratación más allá de la mera calificación técnica del solicitante. Sigue las 10 propiedades de la confianza. El objetivo es
hacer preguntas cuantificables que puedan responderse para cada una de las propiedades y que pueda aplicar cualquier
persona y cualquier posible nuevo empleado. Las reglas de confianza sólidas permiten la coherencia en la calidad en lugar
de depender del "instinto" de los guardianes que deben tomar las decisiones de confianza.

1. Tamaño:
1.1. Calcular el número de solicitantes dividido por el grupo total de solicitantes.

1.2. Calcule el número de personas que el solicitante parece conocer en el grupo dividido por el total
solicitantes del grupo total.

1.3. Calcule la cantidad de empleados actuales que el solicitante conoce (y con los que es “amigo”) en esta ubicación
y divídala por la cantidad total de empleados en esta ubicación.

1.4. Registre el promedio de estos resultados.

2. Simetría:
2.1. El número de personas en las que el solicitante debe confiar para realizar su trabajo en este puesto (incluido el
solicitante) dividido por el número de profesionales que deben confiar en el solicitante en este puesto.

3. Visibilidad:
3.1. El número de horas diarias que el solicitante trabajará solo, sin ayuda y sin supervisión dividido por el número
de horas de trabajo.

4. Subyugación:
4.1. El número de decisiones que el empleado tomará diariamente, de forma independiente, sin participación de
nadie, dividido por el número total de decisiones que el puesto requiere normalmente en un día.

4.2. El solicitante dividido por el número de miembros del equipo con el que trabajará el solicitante
a diario.

4.3. Registre el promedio de estos resultados.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
92 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

5. Consistencia:
5.1. El número total de meses que el solicitante no ha estado empleado dividido por el número total de meses que el
solicitante ha estado en la fuerza laboral y es elegible para el empleo.

5.2. El número total de delitos conocidos dividido por la edad actual menos dieciocho años (o
la edad legal de un adulto en su región) del solicitante.

5.3. El número de referencias neutrales o negativas de empleadores anteriores dividido por el número total de
empleadores anteriores.

5.4. Registre el promedio de estos resultados.

6. Integridad:
6.1. El número de entregables que el solicitante debe producir o mostrar semanalmente dividido
por la semana laboral.

7. Compensaciones:

7.1. Monto de los activos por valor al que tendrá acceso el solicitante dividido por un costo estandarizado de
procesamiento y costos de recuperación.

8. Valor:
8.1. El ingreso mensual generado o ahorrado por el candidato en el puesto dividido por el costo mensual del candidato.
(No medimos el monto pagado por el puesto en comparación con el promedio nacional porque no existe una
correlación clara entre el nivel salarial y la satisfacción laboral que impida que un empleado se vaya, robe o sabotee
el lugar de trabajo).

9. Componentes:
9.1. El número de procesos que requiere el solicitante dividido por el número total de procesos
para el puesto.

9.2. El número de recursos que utilizará el empleado mensualmente dividido por el número total de
recursos disponibles para todos los empleados en esa posición.

9.3. Registre el promedio de estos resultados.

10. Porosidad:
10.1. La cantidad de tiempo semanal que el solicitante dedicaría a interactuar directamente con los competidores,
socios o clientes dividido por el número total de horas de trabajo semanales.

10.2. El número de empleados que viven en la misma comunidad que el solicitante dividido por el total
Número de personas en la comunidad.

10.3. Registre el promedio de estos resultados.

Cada ejemplo de cálculo consiste en generar un porcentaje que se promediará con los demás porcentajes de todas las propiedades fiduciarias
para crear un valor fiduciario final. El valor final le indicará cuánto debe confiar en el nuevo empleado. Luego, se pueden realizar reevaluaciones
periódicas para ver cuánto ha cambiado y si esto debería influir en los permisos otorgados al empleado, la tasa de pago u otras bonificaciones.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 93
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

5.5 Aplicación de reglas de confianza a las pruebas de seguridad

Las pruebas de seguridad verificarán qué confianzas operativas existen, pero se requiere el uso de reglas de confianza para saber
si deberían existir. Esto se determina con el uso de las reglas de confianza durante las pruebas de seguridad.

La gestión de la seguridad y la creación de políticas se basan generalmente en el riesgo, que define las interacciones permitidas
dentro y a través de una organización. Este método define esencialmente reglas para los usuarios y configuraciones para los
sistemas que proporcionarán el nivel requerido de protección cuando se cumplan. La política también puede dictar cómo manejar
los problemas que pueden ocurrir si las reglas o configuraciones son insuficientes o no se siguen correctamente. Por lo tanto, la
política de seguridad describirá lo que la organización determina como confiable o no y qué confianzas operativas se permitirán. Sin
embargo, probar la confianza operativa según lo establecido por la política de seguridad no es una prueba de seguridad y no
ayudará a una organización a determinar mejor dónde su protección es limitada.

Las pruebas de seguridad realizadas con una política en particular para garantizar que se cumplan las reglas se denominan pruebas
de cumplimiento y no son lo mismo que las pruebas de seguridad. El uso de la auditoría OSSTMM determinará las confianzas
operativas existentes, independientemente de si se reconocen o no en la política de seguridad. Estos hallazgos, sujetos al análisis
de confianza en el que se han aplicado las Reglas de confianza a personas, sistemas y procesos, proporcionarán una medición
precisa de dónde deben estar los controles. Esto se puede comparar luego con la política de seguridad para encontrar las
deficiencias que afectan las medidas de protección actuales, así como los planes de seguridad futuros.
En última instancia, el analista utilizaría métricas de confianza en lugar del análisis de riesgos para obtener un medio más preciso
de proteger un ámbito.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
94 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Sólo hay dos maneras de robar algo: o lo

tomas tú mismo o haces que otra persona lo
tome y te lo dé.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 95
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 6 – 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 al objetivo. Termina con comparaciones de resultados con cualquier alarma, alerta, informe o registro
de acceso. Este es un concepto de círculo completo donde el primer paso es conocer los requisitos operativos para interactuar con el objetivo
y el último paso es la revisión de los registros del registro de auditoría.
Para el analista, esto es simplemente: sabes lo que tienes que hacer, lo haces y luego compruebas lo que has hecho.

Esta metodología separa lo que debe hacerse en este formato jerárquico:

1. CANAL 2. MÓDULO
3.
TAREA

El trabajo se describe en la descripción del módulo para cada auditoría de canal en particular. Algunas auditorías se aplican a tecnologías que
pueden estar en la frontera entre dos o más canales. Por ejemplo, las redes LAN inalámbricas que se encuentran comúnmente deben probarse
tanto en el canal de redes de datos como en el canal inalámbrico. Por eso es tan importante tener un plan de pruebas correctamente definido.
La hibridación de canales es una constante y no debe pasarse por alto. El OSSTMM es totalmente capaz de realizar una revisión de seguridad
"de la acera al núcleo" y, por lo tanto, es totalmente capaz de aplicar un análisis a un objetivo, ya sea que sus canales sean claramente distintos
y separados o estén compuestos por múltiples canales. Por lo tanto, para todos los objetivos, el analista debe anticipar la necesidad de definir
una auditoría que incluya múltiples canales. A veces, solo durante la investigación se hará evidente si el alcance contiene objetivos bajo un
canal en particular o si el analista pasará por alto objetivos que solo estén disponibles bajo otros canales.

Esta metodología se aplica a los cinco canales. Tiene 17 módulos y todas las mismas propiedades se aplican a los cinco canales. Si bien la
metodología en sí puede ser la misma, cada canal difiere en las tareas. Cada módulo tiene una entrada y una salida. La entrada es la
información utilizada para realizar cada tarea. La salida es el resultado de las tareas completadas. Esta salida puede o no ser inteligencia
(datos analizados) que sirva como entrada para otro módulo y esta salida puede servir a su vez como entrada para más de un módulo o
sección.
Por lo tanto, el hecho de no completar determinados módulos o tareas puede limitar la finalización satisfactoria de otros módulos o tareas, lo
que limitaría la exhaustividad de la auditoría mucho más de lo que revelaría una simple contabilización de las tareas faltantes.

Algunas tareas no producen resultados, lo que significa que existirán módulos para los que no hay ninguna entrada. Los módulos que no
tienen ninguna entrada se pueden ignorar durante la prueba, pero se deben documentar más adelante con una explicación de por qué no se
han realizado. Además, las tareas sin resultados no necesariamente indican una prueba inferior; más bien, pueden indicar una seguridad
superior. En detalle, las tareas que no tienen ningún resultado resultante pueden significar cualquiera de cinco cosas:

1. El canal fue obstruido de alguna manera durante la ejecución de las tareas.

2. Las tareas no se realizaron adecuadamente.
3. Las tareas no eran aplicables.
4. Los datos del resultado de la tarea se han analizado incorrectamente.
5. La tarea revela una seguridad superior.

Es importante que exista imparcialidad y apertura mental en la realización de las tareas de cada módulo. El principio básico de la auditoría
establece, en relación con un sesgo conformacional similar: “Cuando uno busca algo, espera encontrarlo, lo que puede llevarle a encontrar
sólo lo que está buscando”. En el OSSTMM, cada módulo comienza como una entrada y termina como una salida precisamente por el motivo
de mantener el sesgo al mínimo. Por lo tanto, cada tarea da una dirección de lo que debe revelarse para pasar a otro punto dentro de la
metodología.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
96 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Se puede incorporar un análisis de confianza previo para determinar el alcance según el vector y el canal. También se puede utilizar un análisis
de confianza para predeterminar qué módulos se deben realizar como pruebas independientes. Sin embargo, recuerde que los módulos son
partes de una prueba completa y la suposición de que cualquier módulo en particular se puede omitir es falsa y conducirá a una prueba incorrecta.
Sin embargo, si no hay entrada para un módulo en particular, se puede omitir sin degradar la calidad de la prueba. La diferencia es que, en el
primer caso, el módulo o la tarea se ignoran en función de una decisión de confianza, mientras que en el segundo, la prueba misma dictaminó
que el módulo o la tarea no se pueden realizar.

Al ofrecer pruebas como servicio, es importante comunicar al propietario del objetivo exactamente qué parte del alcance no se ha probado o no
se probará. Esto permite gestionar las expectativas y las garantías de riesgo potencialmente inapropiadas en la seguridad de un sistema.

El tiempo de prueba con los módulos es relativo al plan. Por ejemplo, si el analista prueba la seguridad física de una puerta, entonces la prueba
tendría al menos dos vectores: la seguridad funcional de la puerta desde el exterior de la habitación hacia el interior y luego desde el interior de
la habitación hacia el exterior. Determinar el alcance adecuado en función del vector es importante porque aún puede haber objetivos fuera del
vector y dentro del alcance que no conformarán el alcance de prueba actual. En general, los alcances más grandes con múltiples canales y
múltiples vectores requieren más tiempo dedicado a cada módulo y sus tareas. La cantidad de tiempo permitido antes de regresar con datos de
salida no está determinada por esta metodología y depende del analista, el objetivo, el entorno de prueba y el plan de prueba.

6.1 Flujo de la metodología

El OSSTMM no permite una separación entre lo que se considera recopilación activa de datos y verificación a través de la agitación, ya que en
ambos casos se requiere interacción. Tampoco diferencia entre pruebas activas y pasivas, donde las pruebas activas son la agitación para crear
una interacción con el objetivo y las pruebas pasivas son el registro, la agregación y el análisis de las emanaciones del objetivo. Esta metodología
requiere pruebas tanto activas como pasivas. Además, el analista puede no ser capaz de diferenciar entre los datos recopilados pasivamente a
partir de las emanaciones de las operaciones y los que son la respuesta retrasada o mal dirigida a la agitación. La introducción de cualquier
evento externo, incluido el tipo pasivo, tiene el potencial de cambiar la naturaleza de las operaciones del objetivo y reducir la calidad de una
prueba no influenciada sobre la seguridad operativa. Sin embargo, esto no representa un fracaso del analista o del proceso de auditoría, sino
simplemente un mal inevitable de probar un sistema en un entorno estocástico durante un marco de tiempo lineal. En pocas palabras, el analista
a menudo no puede “recuperar” la agitación una vez que se ha puesto en marcha y cualquier corrección causará resultados adicionales y
variados que no coinciden con el objetivo de la tarea original.

Esto es importante porque dificultará la comparación posterior de los resultados. También significará que las pruebas anteriores influirán en las
pruebas posteriores debido a la “memoria” del impacto de la prueba. Esto es muy evidente en las pruebas realizadas a través del canal PHYSSEC.

Es importante tener en cuenta que al armonizar el OSSTMM con otros estándares de prueba, es importante no restringir el flujo de esta
metodología introduciendo estándares tan formales e implacables que afecten la calidad de la prueba.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 97
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

La memoria de las operaciones

Este es un ejemplo de cómo las pruebas operativas de PHYSSEC en un entorno estocástico durante un período
de tiempo lineal se ven afectadas por su propia memoria.

Escenario 1
El analista prueba el ingreso a un área segura con una autenticación falsa. El guardia examina brevemente la credencial y permite
el ingreso del analista. El analista realiza la auditoría hasta el punto en que se lo identifica y se revela la naturaleza de la auditoría,
si es que se la realiza.

Escenario 2
El analista prueba la entrada a un área segura con una autenticación falsa. El guardia examina brevemente la credencial y, al
dudar de su autenticidad, no permite que el analista entre. El analista prueba tácticas adicionales hasta que logra entrar. El analista
realiza la auditoría hasta el punto en que se identifica al analista y se revela la naturaleza de la auditoría, si es que se realiza.

En ambos escenarios 1 y 2, puede haber o no un registro del intento de ingreso. Si hay un registro, ese registro puede ser
reutilizado por el analista la próxima vez si se niega la credencial como prueba de su autenticidad o por el guardia que puede estar
dudando de su autenticidad y desea ver lo que otros guardias han hecho.

Para la próxima auditoría, el analista puede intentar usar la misma credencial nuevamente, intentar otros medios para ingresar
mediante técnicas de ingeniería social o intentar usar una credencial diferente. Ese guardia, otros guardias con los que el guardia
pudo haber hablado y cualquier registro del intento exitoso o fallido son todos recuerdos del analista, de la técnica y, si el guardia
sabía de la auditoría, de la auditoría en sí.

Sin embargo, si se produce el escenario 2, es posible que la interacción que se intensifica a través de las técnicas adicionales
utilizadas por el analista signifique que el escenario 2 es una prueba más exhaustiva, ya que se realizan más pruebas dentro de la
misma interacción. También significa que es más probable que el guardia recuerde la auditoría y al analista.

Si el analista no logra ingresar, la integridad de la prueba se ve limitada en función del momento en que el analista se quedó sin
técnicas, y cada técnica fallida dificulta aún más la entrada. Si el analista realiza todas las técnicas descritas en las tareas de la
metodología, las pruebas se han completado. Si no es así, las pruebas que aún no se han realizado deben probarse en un guardia
diferente con resultados diferentes, ya que las personas se comportan de manera diferente.

Aunque parezca un problema humano, no lo es. Una puerta o ventana que se abre a la fuerza con demasiada frecuencia
permanecerá dañada hasta que se la reemplace. El uso físico siempre produce deterioro físico.
Incluso en las comunicaciones por cable, el acto de espiar el tráfico provocará demoras (a veces notables) o cambiará el consumo
de energía, ambos con resultados directos o indirectos y a menudo variados.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
98 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

6.2 Los módulos de prueba

Para elegir el tipo de prueba adecuado, es mejor comprender primero cómo están diseñados para funcionar los módulos.
Dependiendo de la minuciosidad, el negocio, la asignación de tiempo y los requisitos de la auditoría, el analista puede querer programar los
detalles de la auditoría por fase.

Hay cuatro fases en la ejecución de esta metodología:

A. Fase de inducción
B. Fase de interacción
C. Fase de investigación
D. Fase de intervención

Cada fase aporta una profundidad diferente a la auditoría, pero ninguna fase es menos importante que otra en términos de Seguridad Real.

A. Fase de inducción
Todo viaje comienza con una dirección. En la fase de inducción, el analista comienza la auditoría con una comprensión de los requisitos de
auditoría, el alcance y las limitaciones de la auditoría de este alcance.
A menudo, el tipo de prueba se determina mejor después de esta fase.

Módulo Descripción Explicación

La revisión de la cultura, reglas, normas, regulaciones, Conozca el alcance y las pruebas que se deben
legislación y políticas aplicables al objetivo. realizar. Es necesario para que la Fase C se lleve a
A.1 Revisión de la postura
cabo correctamente.

La medición de la interacción Conocer las limitaciones de la propia auditoría. restricciones como la distancia,
la velocidad, Esto minimizará el error y mejorará la falibilidad para determinar márgenes de eficiencia.
A.2 Logística
Precisión en los resultados.

La verificación de la práctica y el conocimiento de las restricciones impuestas a la amplitud de la detección

de interacciones, las pruebas interactivas. Esto es necesario para la respuesta y la predictibilidad de la
A.3 Verificación de detección activa
respuesta. Realizar adecuadamente las Fases B y D.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 99
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

B. Fase de interacción
El núcleo de la prueba de seguridad básica requiere conocer el alcance en relación con las interacciones con los objetivos transmitidos a las
interacciones con los activos. Esta fase definirá el alcance.

Módulo Descripción Explicación

La determinación de los objetivos a comprobar dentro del alcance. La visibilidad se considera como “presencia”
y no como un objetivo muerto o perdido, y no como un objetivo muerto o perdido.

B.4 Auditoría de visibilidad objetivo que no responde. Sin embargo, un

objetivo que no responde no es necesariamente
un objetivo perdido.

La medición de la amplitud y profundidad de los El punto de acceso es el punto principal de cualquier

puntos de acceso interactivos dentro del objetivo y la interacción con activos. Verificar la existencia de un
autenticación requerida. punto de acceso es una parte de la determinación de
B.5 Verificación de acceso [Link]
su existencia. La verificación completa
conocer todo lo que hay que saber sobre el punto de
acceso.

La determinación de las relaciones de confianza Las confianzas para los nuevos procesos suelen ser
muy limitadas, ya que existen relaciones entre los objetivos y entre ellos. Existe una confianza limitada
cuando los procesos más antiguos tienen una relación que aparentemente evoluciona de manera
B.6 Verificación de confianza caótica hacia la interacción entre los objetivos y los externos. Conocer el alcance de las relaciones de
confianza. entre objetivos se mostrará la edad o el valor de la
interacción.

La medición del uso y La mayoría de los procesos se definen en respuesta

eficacia de los controles de pérdidas basados en a una interacción necesaria y algunos persisten
procesos (Clase B): no repudio, confidencialidad, mucho tiempo después de que esa interacción se
B.7 Verificación de control privacidad e integridad. detiene o ha cambiado.
El control de alarma se verifica al final de la Saber qué controles de proceso están
metodología. implementados es un tipo de arqueología de seguridad.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
100 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

C. Fase de investigación

Gran parte de la auditoría de seguridad se centra en la información que descubre el analista. En esta fase, se revelan los distintos tipos de
valor o perjuicios que puede tener la información mal ubicada o mal gestionada como activo.

Módulo Descripción Explicación

La determinación de la existencia de los controladores y sus rutinas y la eficacia de los registros y de los
controles. La mayoría de los procesos tendrán un conjunto definido de reglas, sin embargo, los niveles de
seguridad o la diligencia definidos por las operaciones reales reflejan cualquier revisión de la postura y la
eficiencia, la pereza o la paranoia que los controles de indemnización.
C.8 Verificación del proceso
Puede redefinir las reglas. No se trata solo de que el
proceso esté ahí, sino también de cómo funciona.

La investigación del estado estable Este módulo explora el funcionamiento normal (por defecto) de los
objetivos como condiciones en las que los objetivos para los que han sido diseñados operan regularmente
para comprender las condiciones normales y determinar la intención, la justificación comercial y los problemas
subyacentes fuera del razonamiento de los objetivos. Además, la aplicación de pruebas de estrés de
Verificación de configuración /
seguridad. Muchas regulaciones requieren información sobre cómo se planifica que funcione algo y esto no
C.9 Verificación de la formación
siempre es evidente en la ejecución de ese trabajo.

La medición de la amplitud y profundidad del uso de Conozca el estado de los derechos de propiedad de la
propiedad intelectual o aplicaciones ilegales o sin propiedad.
C.10 Validación de la propiedad licencia dentro del objetivo.

Una determinación de los niveles de Conozca qué derechos de privacidad se aplican y en

información de identificación personal definida por la qué medida se divulgan.
revisión de la postura. La información de identificación personal puede
C.11 Revisión de la segregación clasificarse según estos requisitos.

La búsqueda de información disponible libremente La palabra en la calle tiene valor.

que describa la visibilidad indirecta de objetivos o Descubra información sobre objetivos y activos de
C.12 Verificación de la exposición activos dentro del canal elegido del alcance. fuentes públicas, incluida la de los propios objetivos.

La búsqueda de información disponible de forma gratuita puede tener más valor, directa o indirectamente,
que la información de los procesos y podría dañar o afectar negativamente a los objetivos que los activos que
el propietario del objetivo protege a través de medios externos. Descubra información que sea competitiva.
Inteligencia competitiva
C.13
Exploración por sí solo o en conjunto pueden influir en las
decisiones comerciales competitivas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 101
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

D. Fase de intervención
Estas pruebas se centran en los recursos que requieren los objetivos en el ámbito de aplicación. Esos recursos se pueden cambiar, modificar,
sobrecargar o privar de recursos para provocar una penetración o interrupción. Esta suele ser la fase final de una prueba de seguridad para
garantizar que las interrupciones no afecten las respuestas de las pruebas menos invasivas y porque la información para realizar estas pruebas
puede no conocerse hasta que se hayan llevado a cabo otras fases. El módulo final, D.17, de Revisión de alertas y registros, es necesario para
verificar las pruebas anteriores que no proporcionaron interactividad al analista. La mayoría de las pruebas de seguridad que no incluyen esta fase
pueden necesitar realizar una revisión final desde la perspectiva de los objetivos y los activos para aclarar cualquier anomalía.

Módulo Descripción Explicación

La determinación y medición del uso efectivo de la Determinar la efectividad de los controles de

cuarentena para todos los accesos al objetivo y autenticación y sometimiento en términos de
D.14 Verificación de cuarentena dentro de él. cuarentenas de listas blancas y negras.

El mapeo y medición del impacto del mal uso de la autorización de subyugación sobre la autenticación,
controles, credenciales y privilegios o indemnización, y la escalada no autorizada de controles en términos
de profundidad y roles.
D.15 Auditoría de privilegios

privilegio.

La determinación y medición Determinar la efectividad de la resiliencia del objetivo a cambios excesivos o

adversos donde a través de la verificación de la negación del servicio y de la negación de la interactividad.
Validación de la capacidad de supervivencia /
D.16
Continuidad del servicio
se verían afectados.

Una revisión de las actividades de auditoría Conozca qué partes de la auditoría dejaron un rastro
realizadas con la profundidad real de aquellas utilizable y confiable.
Revisión de alertas y registros /
D.17 actividades tal como las registra el objetivo o un
Fin de la encuesta
tercero, como en el control de alarma.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
102 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

6.3 Una metodología

La combinación de todos los módulos proporciona una metodología que se debe conocer y con la que se puede
trabajar. Se trata de una metodología que se puede aplicar a todo tipo de pruebas de seguridad. Ya sea que el objetivo
sea un sistema en particular, una ubicación, una persona, un proceso o miles de ellos, esta metodología garantizará
la prueba más exhaustiva y eficiente posible.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 103
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

En la ruleta, debes apostar a la persona que hace girar

la rueda y lanza la bola.
Como cualquier otro ser humano, se aburren y caen en
la rutina. Explota a la persona cuya predictibilidad tiene
inevitablemente mejores probabilidades que la máquina.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
104 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 7 ­ Pruebas de seguridad humana

Seguridad Humana (HUMSEC) es una subsección de PHYSSEC e incluye Operaciones Psicológicas (PSYOPS).
Para probar este canal es necesario interactuar con personas que ocupan puestos de control de los activos.

Este canal cubre la participación de personas, principalmente del personal operativo dentro del alcance o marco de trabajo objetivo. Si bien algunos
servicios consideran esto simplemente como “ingeniería social”, el verdadero objetivo de cumplimiento de las pruebas de seguridad en este canal es
la evaluación de la concienciación del personal sobre la seguridad y la medición de las brechas en relación con el estándar de seguridad requerido
delineado en la política de la empresa, las regulaciones de la industria o la legislación regional.

El analista deberá contar con múltiples herramientas y métodos para realizar algunas tareas a fin de garantizar que no se despierten sospechas entre
el personal y que las pruebas no se invaliden debido a un descubrimiento temprano o a una mayor paranoia. También puede ser pertinente limitar los
sujetos de prueba a uno por departamento u otro límite.

Los analistas competentes requerirán tanto habilidades interpersonales diligentes como habilidades de pensamiento crítico para garantizar que la
recopilación de datos factuales genere resultados factuales a través de la correlación y el análisis.

Consideraciones
Tenga en cuenta las siguientes consideraciones para garantizar una prueba segura y de alta calidad:

1. In personam: Las restricciones del alcance se dirigen a aquel personal que tiene un contrato legal directo con el propietario del alcance y, por
lo tanto, tiene la responsabilidad legal de su conocimiento y obligaciones en materia de seguridad.

2. Negación plausible: No se realizarán pruebas de seguridad directas al personal que no haya sido capacitado, informado o que no se pueda
decir que posee experiencia u obligaciones de concientización sobre seguridad debido a los requisitos de responsabilidad laboral.

3. Derechos humanos: Cuando el personal que se va a someter a la prueba se elige al azar o no se dice que tenga responsabilidades laborales
directamente relacionadas con el control de acceso, la seguridad o la protección, el analista se abstendrá de identificar personalmente a la
persona y elaborará el informe únicamente sobre una base estadística.

4. Incomunicación: El personal al que se le dé tiempo discutirá las acciones de la prueba con otros y alterará el curso de la prueba.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 105
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.1 Revisión de la postura

Los estudios iniciales de la postura incluyen las leyes, la ética, las políticas, las regulaciones de la industria y la cultura política
que influyen en los requisitos de seguridad y privacidad para el ámbito de aplicación. Esta revisión forma una matriz a la que
se deben asignar las pruebas, pero no limitarlas.

7.1.1 Política
Revisar y documentar la política organizacional apropiada con respecto a las responsabilidades de seguridad,
integridad y privacidad del personal dentro del alcance.

7.1.2 Legislación y reglamentación

Revisar y documentar la legislación regional y nacional apropiada y las regulaciones de la industria con respecto a
los requisitos de seguridad y privacidad de la organización dentro del alcance, así como aquellos que incluyen a los
clientes, socios, sucursales organizacionales o revendedores apropiados fuera del alcance.

7.1.3 Cultura

Revisar y documentar la cultura organizacional apropiada en el ámbito de la concientización sobre seguridad y

privacidad, la capacitación de personal requerida y disponible, la jerarquía organizacional y la interacción de confianza
reconocida entre los empleados.

7.1.4 Relaciones
Revisar y documentar las relaciones de influencia apropiadas entre el personal de la jerarquía organizacional dentro
del alcance.

7.1.5 Cultura regional

Revisar y documentar la influencia apropiada de las culturas regionales y extranjeras en la jerarquía social en el
entorno en el que reside el alcance.

7.1.6 Economía

Revisar y documentar la influencia apropiada de la economía y la escala salarial en el estatus social del personal,
tanto del vector de personal dentro del alcance como del de la comunidad externa en la que reside el alcance.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
106 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.2 Logística
Preparación del entorno de prueba del canal necesaria para evitar falsos positivos y falsos negativos que conducen a resultados de prueba
inexactos.

7.2.1 Equipos de comunicaciones

Pruebe las comunicaciones que brindan identificación al receptor, como identificador de llamadas, respuesta de fax, registro de
direcciones IP, credenciales de localización y encabezados de puerta de enlace de correo electrónico. Pruebe si la identificación se
puede bloquear, eliminar u ofuscar, y hasta qué grado de anonimato.

7.2.2 Comunicaciones

Pruebe qué idiomas se utilizan dentro del alcance y qué idiomas se comunican entre el alcance y los clientes, socios y revendedores
fuera del alcance.

7.2.3 Tiempo

Pruebe la zona horaria, los días festivos y los horarios de trabajo para varios roles y trabajos dentro del alcance, incluidos socios,
revendedores y clientes influyentes que interactúan con el alcance.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 107
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.3 Verificación de detección activa

La determinación de los controles activos y pasivos para detectar intrusiones para filtrar o denegar intentos de prueba debe
realizarse antes de la prueba para mitigar el riesgo de crear falsos positivos y negativos en los datos de los resultados de la
prueba, así como cambiar el estado de alarma del personal o los agentes de monitoreo.

7.3.1 Monitoreo de canales

Pruebe si el servicio de asistencia técnica o los canales de soporte por teléfono, mensajería instantánea, chat, foros
web o correo electrónico son supervisados por un tercero para control de calidad.

7.3.2 Moderación de canales

Pruebe si el servicio de asistencia técnica o los canales de soporte por teléfono, mensajería instantánea, chat, foros
web o correo electrónico están filtrados o puestos en cuarentena por el personal o un sistema automatizado para
verificar la autenticidad, eliminar datos extraños, ignorar solicitudes repetidas o moderar las interacciones.

7.3.3 Supervisión
Probar si el personal de soporte puede responder solicitudes sin confirmación de un supervisor o personal similar.

7.3.4 Asistencia al operador

Probar que el acceso a qué personal a través del canal de telecomunicaciones debe realizarse a través de un operador,
ya sea atendido por personal o automatizado.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
108 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.4 Auditoría de visibilidad

Pruebas de enumeración y verificación de la visibilidad del personal con el que es posible interactuar a través de todos los canales.

7.4.1 Identificación de acceso

Pruebe los canales que brindan interacciones con personal fuera del alcance y documente todos los métodos utilizados y los resultados
de esos métodos.

7.4.2 Enumeración del personal

Enumere la cantidad de personal dentro del alcance con acceso autorizado y no autorizado a los procesos dentro del alcance,
independientemente del tiempo o el canal de acceso, y el método para obtener esos datos.

7.5 Verificación de acceso

Pruebas para la enumeración de los puntos de acceso del personal dentro del ámbito de aplicación. Si bien el acceso al personal fuera del ámbito
de aplicación es un escenario real y se utiliza a menudo para el robo de información, este puede limitarse a la interacción exclusiva dentro del
ámbito de aplicación para proteger los derechos de privacidad independientes del personal en su vida privada.

7.5.1 Proceso de acceso

Mapee y explore el uso de canales en el ámbito para alcanzar los activos. Documente todos los métodos utilizados y los resultados de
esos métodos.

7.5.2 Autoridad

Utilice personal en puestos de autoridad con control de acceso o que ocupen puestos de control de acceso a los activos
dentro del alcance. Documente los métodos utilizados en el descubrimiento de personal clave.

7.5.3 Autenticación

Enumerar y probar las deficiencias del personal de acceso y los privilegios necesarios para interactuar con ellos a fin de
garantizar que solo las partes identificadas, autorizadas y previstas tengan acceso.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 109
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.6 Verificación de confianza

Pruebas de confianza entre el personal dentro del alcance, donde la confianza se refiere al acceso a información o activos físicos de otros
objetivos dentro del alcance.

7.6.1 Tergiversación

Probar y documentar la profundidad de los requisitos para el acceso a los activos dentro del alcance con el uso de una representación
falsa como miembro del personal de soporte o entrega “interno” dentro del alcance sin ninguna credencial.

7.6.2 Fraude

Probar y documentar la profundidad de los requisitos de acceso a los activos dentro del alcance con el uso de representación
fraudulenta como miembro de la gerencia u otro personal clave.

7.6.3 Desorientación

Probar y documentar la profundidad de los requisitos para el acceso a los activos dentro del alcance con el uso de una representación
errónea como miembro del personal de soporte o de entrega fuera del alcance.

7.6.4 Suplantación de identidad (phishing)

Probar y documentar la profundidad de los requisitos para el acceso a la información controlada por el personal o a los activos físicos
a través de todos los canales descubiertos para el personal dentro del alcance con el uso de una puerta de enlace fraudulenta donde
se le pide al personal que proporcione credenciales. Documentar los métodos y todas las credenciales recopiladas de esta manera.

7.6.5 Abuso de recursos

Probar y documentar la profundidad de los requisitos para llevar activos fuera del alcance a una fuente conocida y confiable o dentro
del alcance mismo a otro personal sin credenciales establecidas y requeridas.

7.6.6 En Terrorem

Probar y documentar la profundidad de los requisitos para incitar el miedo, la revuelta, la violencia y el caos, mediante la perturbación
del personal y el uso de rumores u otros abusos psicológicos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
110 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.7 Verificación de controles

Pruebas para enumerar los tipos de controles de pérdidas utilizados para proteger el valor de los activos.

7.7.1 No repudio
Enumere y pruebe el uso o las deficiencias del personal de acceso para identificar y registrar adecuadamente el
acceso o las interacciones con los activos a fin de obtener evidencia específica para impugnar el repudio.
Documente la profundidad de la interacción que se registra.

7.7.2 Confidencialidad
Enumerar y probar el uso o las deficiencias de todos los segmentos de comunicación con el personal dentro del alcance a través de un
canal o las propiedades transportadas a través de un canal utilizando líneas seguras, cifrado, interacciones personales "silenciadas" o
"cerradas" para proteger la confidencialidad de los activos de información conocidos solo por aquellos con la clasificación de autorización
de seguridad adecuada de ese activo.

7.7.3 Privacidad
Enumerar y probar el uso o las deficiencias de todos los segmentos de comunicación con el personal dentro del
alcance a través de un canal o propiedades transportadas utilizando firmas individuales específicas, identificación
personal, interacciones personales "silenciadas" o "en sala cerrada" para proteger la privacidad de la interacción
y el proceso de proporcionar activos solo a aquellos dentro de la autorización de seguridad adecuada para ese
proceso, información o activos físicos.

7.7.4 Integridad
Enumerar y probar las deficiencias en todos los segmentos de comunicación con el personal dentro del alcance
donde los activos se transportan a través de un canal utilizando un proceso documentado, firmas, cifrado, hash
o marcas para proteger y asegurar que la información o los activos físicos no se puedan cambiar, conmutar,
redirigir o revertir sin que las partes involucradas lo sepan.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 111
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.8 Verificación del proceso

Pruebas para examinar el mantenimiento de la conciencia de seguridad funcional del personal en los procesos establecidos y la
debida diligencia según se define en la Revisión de Postura.

7.8.1 Mantenimiento

Examinar y documentar la puntualidad, idoneidad, acceso y alcance de los procesos para la notificación y concientización
sobre seguridad de todo el personal con respecto a la seguridad operativa, la seguridad real y los controles de pérdidas.

7.8.2 Desinformación

Determinar hasta qué punto las notificaciones de seguridad del personal y las noticias de seguridad pueden ampliarse o
alterarse con información errónea.

7.8.3 Debida diligencia

Mapear y verificar cualquier brecha entre la práctica y los requisitos determinados en la Revisión de Postura a través de
todos los canales.

7.8.4 Indemnización

Documentar y enumerar el abuso o la elusión de las políticas de los empleados, seguros, confidencialidad, no
competencia, contratos de responsabilidad o exenciones de responsabilidad de uso/usuario con todo el personal de
acceso dentro del alcance en todos los canales.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
112 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.9 Verificación de la formación

Pruebas para examinar la capacidad de eludir o interrumpir la educación y capacitación sobre concientización sobre seguridad funcional en
el personal de acceso.

7.9.1 Mapeo de la educación

Mapee los tipos y la frecuencia de la asistencia en materia de concientización sobre seguridad, los cursos de educación y la
capacitación brindados al personal, los socios, los clientes y, específicamente, a los guardianes.

7.9.2 Interrupción de la política

Descubra y examine el proceso y la profundidad del autocontrol del personal ante la interrupción o no conformidad de la política de
seguridad.

7.9.3 Mapeo de conciencia

Mapear las limitaciones descubiertas en la capacitación de concientización sobre seguridad para el personal a través del análisis
de brechas con procedimientos reales, incluyendo pero no limitado a: la provisión de activos a través de cualquier canal, la
capacidad de reconocer identificaciones inapropiadas y falsificadas o métodos requeridos, el método de identificación adecuado
entre el personal, el uso de medidas de seguridad personal para uno mismo y sus activos, el manejo de activos confidenciales y
sensibles, y la conformidad con la política de seguridad organizacional.

7.9.4 Secuestro de la conciencia

Descubrir y examinar en qué medida una persona no oficial proporciona información errónea sobre la política de seguridad de
manera autorizada para eludir o infringir deliberadamente la política de seguridad.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 113
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.10 Validación de la propiedad

Pruebas para examinar la información y la propiedad física disponibles dentro del alcance o proporcionadas por el personal que puedan ser
ilegales o poco éticas.

7.10.1 Compartir

Verificar hasta qué punto la propiedad con licencia individual, privada, falsificada, reproducida, no libre o no abierta se comparte entre
el personal, ya sea intencionalmente a través de procesos y programas compartidos, bibliotecas y cachés personales, o
involuntariamente a través de una mala administración de licencias y recursos, o negligencia.

7.10.2 Mercado negro

Verificar en qué medida se promueve, comercializa o vende propiedad con licencia individual, privada, falsificada, reproducida, no libre
o no abierta, entre el personal o por parte de la organización.

7.10.3 Canales de venta

Verificar negocios públicos, fuera del alcance, subastas o ventas de propiedades que brinden información de contacto a través de
canales que se originan dentro del alcance.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
114 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.11 Revisión de la segregación

Pruebas para la separación adecuada de los activos de información privada o personal de la información comercial. Al igual que una revisión
de privacidad, es el punto focal del almacenamiento, transmisión y control legal y ético de la información privada del personal, los socios y
los clientes.

7.11.1 Mapeo de contención de privacidad

Mapear los guardianes de los activos de información privada dentro del alcance, qué información se almacena, cómo y dónde se
almacena la información y a través de qué canales se comunica la información.

7.11.2 Información Evidente

Enumerar y mapear información sobre personas individuales que ingresan al país, como nombres, raza, sexo, religión, días de
vacaciones, páginas web personales, currículums publicados, afiliaciones personales, consultas de directorio, sucursal(es) bancarias,
registro electoral y cualquier información personal particular declarada implícitamente como privada en regulaciones y políticas.

7.11.3 Divulgación

Examinar y documentar los tipos de divulgaciones de activos de información privada sobre el personal por parte de los guardianes
responsables de esta segregación de acuerdo con la política y las regulaciones determinadas en la Revisión de la Postura y el
derecho humano básico a la privacidad.

7.11.4 Limitaciones

Examinar y documentar los tipos de puertas de enlace y alternativas de canales con puertas de enlace accesibles para personas
con limitaciones físicas dentro de ese canal.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 115
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.12 Verificación de la exposición

Pruebas para descubrir información que permita o conduzca a un acceso autenticado o permita un acceso no deseado
a múltiples ubicaciones con la misma autenticación.

7.12.1 Mapeo de exposición

Enumerar y mapear información del personal sobre la organización, tal como organigramas, títulos de personal clave, descripciones
de trabajo, números de teléfono personales y laborales, números de teléfono móvil, tarjetas de presentación, documentos
compartidos, currículums, afiliaciones organizacionales, direcciones de correo electrónico privadas y públicas, inicios de sesión,
esquemas de inicio de sesión, contraseñas, métodos de respaldo, aseguradoras o cualquier información organizacional particular
declarada implícitamente como confidencial en regulaciones y políticas.

7.12.2 Elaboración de perfiles

Perfilar y verificar la organización, los tipos de requisitos de habilidades de los empleados, las escalas salariales, la información
de canales y puertas de enlace, las tecnologías y la dirección.

7.13 Inteligencia Competitiva

Pruebas para recopilar información que pueda analizarse como inteligencia empresarial. Si bien la inteligencia competitiva como campo
está relacionada con el marketing, el proceso aquí incluye cualquier forma de recopilación de inteligencia competitiva, incluido, entre otros,
el espionaje económico e industrial.

7.13.1 Molienda de negocios

Mapee los guardianes de los activos comerciales dentro del alcance, qué información se almacena, cómo y dónde se almacena la
información y a través de qué canales se comunica la información entre el personal.

7.13.2 Entorno empresarial

Explorar y documentar a partir de los datos personales del personal de acceso individual, detalles comerciales tales como alianzas,
socios, clientes principales, proveedores, distribuidores, inversores, relaciones comerciales, producción, desarrollo, información
de productos, planificación estratégica, existencias y comercio, y cualquier información o propiedad comercial en particular
declarada implícitamente como confidencial en las regulaciones y políticas.

7.13.3 Entorno organizacional

Examinar y documentar los tipos de divulgaciones de activos comerciales de los guardianes sobre operaciones, procesos,
jerarquía, informes financieros, oportunidades de inversión, fusiones, adquisiciones, inversiones de canales, mantenimiento de
canales, políticas sociales internas, insatisfacción del personal y tasa de rotación, tiempos de vacaciones principales, contrataciones,
despidos y cualquier activo organizacional particular declarado implícitamente como confidencial en regulaciones y políticas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
116 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.14 Verificación de cuarentena

Pruebas para verificar la correcta recepción y contención de contactos agresivos u hostiles en los puntos de entrada.

7.14.1 Identificación del proceso de contención

Identificar y examinar los métodos y procesos de cuarentena en las entradas de todos los canales para detectar contactos agresivos
y hostiles, como vendedores, cazatalentos, estafadores, periodistas, competidores, buscadores de empleo, candidatos a un puesto
de trabajo y personas disruptivas.

7.14.2 Niveles de contención

Verificar el estado de contención, la duración y todos los canales en los que la interacción con los guardianes tiene métodos de
cuarentena. Asegurarse de que los métodos se encuentren dentro del contexto y los límites legales.

7.15 Auditoría de privilegios

Pruebas en las que se proporcionan credenciales al usuario y se le concede permiso para realizar pruebas con esas credenciales.

7.15.1 Identificación

Examinar y documentar el proceso de obtención de identificación a través de medios legítimos y fraudulentos en todos los canales.

7.15.2 Autorización

Verificar el uso de autorización fraudulenta en todos los canales para obtener privilegios similares a los del resto del personal.

7.15.3 Escalada

Verificar y mapear el acceso a los activos mediante el uso de privilegios para obtener privilegios mayores o más amplios más allá de
los que están designados autorizadamente para el rol.

7.15.4 Discriminación

Verificar la información solicitada y los privilegios otorgados a los guardianes en los casos en que la edad (específicamente aquellos
que son menores de edad legalmente para la región), el sexo, la raza, las costumbres/cultura y la religión sean factores que puedan
ser discriminados de acuerdo con la Revisión de Postura.

7.15.5 Subyugación

Enumerar y comprobar si existen deficiencias en los activos comunicados a través de canales en los que dichos controles no son
necesarios o pueden eludirse o ignorarse, como el correo electrónico inseguro o una línea telefónica pública.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 117
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

7.16 Continuidad del servicio

Determinar y medir la resiliencia de los guardianes dentro del alcance ante cambios excesivos u hostiles diseñados para provocar fallas
en el servicio.

7.16.1 Resiliencia

Enumerar y probar las deficiencias en todos los canales del personal dentro del alcance, mediante el cual la eliminación o el
silenciamiento del personal de entrada permitirá el acceso directo a los activos.

7.16.2 Continuidad

Enumerar y probar las deficiencias de todo el personal con respecto a los retrasos en el acceso y el tiempo de respuesta del servicio
a través de personal de respaldo o medios automatizados para el acceso a personal de puerta de enlace alternativo.

7.16.3 Seguridad

Mapear y documentar el proceso por el cual los guardianes desconectan canales debido a problemas de evacuación o seguridad
como un análisis de brechas con la regulación y la política de seguridad.

7.17 Finalizar la encuesta

Un análisis de la brecha entre las actividades realizadas con la prueba y la profundidad real de esas actividades tal como se registraron
o según las percepciones de terceros, tanto humanos como mecánicos.

7.17.1 Alarm

Verificar y enumerar el uso de un sistema, registro o mensaje de advertencia localizado o de alcance amplio para cada puerta de
acceso en cada canal donde el personal detecte una situación sospechosa por sospecha de intentos de evasión, ingeniería social o
actividad fraudulenta.

7.17.2 Almacenamiento y recuperación

Documentar y verificar el acceso privilegiado y eficiente a las ubicaciones y propiedades de almacenamiento de alarmas, registros y
notificaciones.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
118 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Los tipos de controles de seguridad física más inútiles son

los que no protegen contra lo que necesitas y los que
protegen contra cualquier cosa sin ningún motivo.

razón.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 119
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 8 ­ Pruebas de seguridad física

PHYSSEC (Seguridad física) es una clasificación de la seguridad material dentro del ámbito físico que se encuentra dentro de los
límites del espacio tridimensional interactivo con humanos. Para probar este canal se requiere una interacción no comunicativa
con barreras y humanos en posiciones de control de los activos.

Este canal cubre la interacción del analista en la proximidad de los objetivos. Si bien algunos servicios consideran esto simplemente
como un “allanamiento de morada”, el verdadero objetivo de cumplimiento de las pruebas de seguridad en este canal es la prueba
de barreras físicas y lógicas y la medición de brechas según el estándar de seguridad requerido, tal como se describe en la
política de la empresa, las regulaciones de la industria o la legislación regional.

El analista deberá contar con múltiples herramientas y métodos para la realización de algunas tareas a fin de garantizar que no
se despierten sospechas entre el personal y que las pruebas no se invaliden debido a un descubrimiento temprano o a una mayor
paranoia. También puede ser pertinente limitar los sujetos de prueba a uno por departamento u otro límite. Los analistas también
deberán estar preparados para la posibilidad de daño corporal accidental por barreras y armas convencionales, interacciones con
animales, exposición a bacterias, virus y hongos dañinos, exposición a radiación electromagnética y de microondas, especialmente
aquella que puede dañar permanentemente la audición o la vista, y agentes químicos venenosos o corrosivos en cualquier forma.

Los analistas competentes requerirán fuerza física, resistencia, agilidad y habilidades de pensamiento crítico para garantizar que
la recopilación de datos factuales cree resultados factuales a través de la correlación y el análisis.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
120 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Consideraciones
Tenga en cuenta las siguientes consideraciones para garantizar una prueba segura y de alta calidad:

1. Conato: Todo intento de atravesar barreras físicas requiere un juicio imparcial sobre la dificultad necesaria para alcanzar e interactuar
con el objetivo y el peligro que implica. Estas consideraciones deben hacerse en relación con la “voluntad de vivir” de los seres
humanos, así como con cualquier efecto sobre los objetivos si el ataque se realiza sin tener en cuenta la vida (suicida).

2. Ecce hora: Todas las pruebas físicas requieren que se preste mucha atención al tiempo. Se deben llevar registros de la hora en que se
realiza la prueba, el tiempo en el objetivo y la hora en que termina la prueba, ya sea exitosa o no, porque eso también ayudará a
determinar qué se puede lograr dentro del rango de tiempo para fallar. Conocer esa información puede ayudar a comprender lo que
puede ser un ataque engañoso para asegurarse de que no se desperdicien recursos en un área mientras se deja otra abierta.

3. Abuso de discreción: El analista debe tener cuidado de no ignorar ni malinterpretar los resultados de las pruebas de una barrera u
obstáculo físico porque no se encuentre dentro del rango de sus posibilidades físicas. El analista debe permanecer imparcial y no
sobreestimar ni sobrevalorar las habilidades y capacidades personales, sino aplicar las pruebas como lo haría una persona altamente
capacitada y capaz.

4. Magister pecuarius: El analista no debe descartar la posibilidad razonable de que un atacante utilice animales entrenados para sortear
barreras y obstáculos que un ser humano no puede.

5. Negación plausible: No se realizarán pruebas de seguridad personal directas o físicas a personal que no haya sido capacitado, informado
o que no se pueda decir que posee experiencia u obligaciones de concientización sobre seguridad debido a los requisitos de
responsabilidad laboral.

6. Sui generis: toda interacción con barreras físicas dejará un registro de esta interactividad y, en casos más extremos, puede debilitar o
destruir la barrera. El analista debe tener cuidado al probar objetivos únicos que pueden no ser reemplazables. El analista también
debe tener cuidado de no dejar marcas permanentes siempre que sea posible y de mantener un registro de todas las barreras probadas
para verificar que no tengan daños después de la auditoría.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 121
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.1 Revisión de la postura

Los estudios iniciales de la postura incluyen las leyes, la ética, las políticas, las regulaciones de la industria y la cultura política
que influyen en los requisitos de seguridad y privacidad para el ámbito de aplicación. Esta revisión forma una matriz a la que se
deben asignar las pruebas, pero no limitarlas.

8.1.1 Política

Revisar y documentar la política organizacional apropiada con respecto a la seguridad, protección, integridad (es decir,
cadena de suministro) y requisitos de privacidad para las barreras en el alcance.

8.1.2 Legislación y reglamentación

Revisar y documentar la legislación regional y nacional apropiada y las regulaciones de la industria con respecto a los
requisitos de seguridad y privacidad de la organización dentro del alcance, así como aquellos que incluyen a los clientes,
socios, sucursales organizacionales o revendedores apropiados fuera del alcance.

8.1.3 Cultura

Revisar y documentar la cultura organizacional apropiada en el ámbito de la concientización sobre seguridad y privacidad,
la capacitación de personal requerida y disponible, la jerarquía organizacional y la interacción de confianza reconocida
entre los empleados.

8.1.4 Relaciones

Revisar y documentar las relaciones de influencia apropiadas entre el personal de la jerarquía organizacional dentro del
alcance.

8.1.5 Cultura regional

Revisar y documentar la influencia apropiada de las culturas regionales y extranjeras sobre la seguridad, la jerarquía
social, la cadena de suministro y los servicios en el entorno en el que reside el alcance.

8.1.6 Economía

Revisar y documentar la influencia apropiada de la economía y la escala salarial en el estatus social y la intención
delictiva del personal, tanto del vector del personal dentro del alcance como del de la comunidad externa en la que reside
el alcance.

8.1.7 Medio ambiente

Revise para la región objetivo los patrones climáticos, extremos climáticos peligrosos (es decir, inundaciones, tornados,
huracanes), extremos de temperatura, máximos de humedad, calidad del aire, estabilidad tectónica, fauna típica, formas
de desastre natural o provocado por el hombre y la infestación general de insectos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
122 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.2 Logística
Preparación del entorno de prueba del canal necesaria para evitar falsos positivos y falsos negativos que conducen a resultados de prueba
inexactos.

8.2.1 Medio ambiente

(a) Examine el telescopio para determinar si se requiere algún equipo especial para el entorno de los objetivos. El equipo puede
variar desde cuerdas para escalar paredes hasta equipo de buceo para viajar bajo el agua. Los tipos de equipo no se limitan
solo al entorno, sino también a las barreras que se deben sortear.

(b) Verificar el equipo de seguridad dañado que pueda provocar lesiones al analista.
(c) Examinar los objetivos en busca de terrenos, aire, agua, edificios o estructuras peligrosos, contaminados o mal mantenidos.

(d) Examine los niveles de ruido, radiación electromagnética y campo magnético en el osciloscopio.

8.2.2 Comunicaciones

(a) Probar qué idiomas se utilizan dentro del alcance y qué idiomas se comunican entre el alcance y los clientes, socios y
revendedores fuera del alcance. (b) Examinar los medios de comunicación entre el personal y si se mejoran
mediante el uso de herramientas como banderas, bengalas, radios, binoculares, visión nocturna, etc.

8.2.3 Tiempo

(a) Pruebe la zona horaria, los días festivos y los horarios de trabajo para varios roles y trabajos dentro del alcance, incluidos socios,
revendedores y clientes influyentes que interactúan con el alcance.
(b) Determinar si la movilidad o la visibilidad disminuyen durante el día, la semana, el mes o la temporada (día o
La noche, la niebla, la lluvia o la nieve tendrán un impacto en las operaciones en el objetivo.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 123
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.3 Verificación de detección activa

La determinación de los controles activos y pasivos para detectar intrusiones para filtrar o denegar intentos de prueba debe realizarse antes de la
prueba para mitigar el riesgo de crear falsos positivos y negativos en los datos de los resultados de la prueba, así como cambiar el estado de alarma
del personal o los agentes de monitoreo.

8.3.1 Monitoreo

(a) Verificar que el telescopio esté controlado por un tercero para detectar intrusiones a través de vigías, guardias, cámaras o sensores.
Se deben registrar la fecha y hora de entrada y salida del objetivo.
(b) Determinar el alcance del monitoreo y si el recorrido de una amenaza hacia el objetivo puede ser
interceptado de manera oportuna.
(c) Verificar si el viaje al objetivo requiere un mayor tiempo en el objetivo y una mayor exposición. Esto incluye, entre otros: salas de
cuarentena, pasillos largos y vacíos, estacionamientos, grandes espacios vacíos, terrenos difíciles o poco naturales y áreas para
invitados o de espera.
(d) Verificar que la iluminación y el contraste visible al acercarse al objetivo permitan la interceptación de
amenazas.

8.3.2 Reacción

(a) Verificar si los controles interactivos para el objetivo reaccionarán oportunamente ante condiciones ambientales extremas
de acuerdo con la tarea de revisión ambiental de la Revisión de Postura.
(b) Verificar si el objetivo reaccionará oportunamente ante una perturbación en la calidad del aire, el agua y el suelo.
(c) Verificar si el objetivo reaccionará oportunamente ante perturbaciones críticas de ruido.
(d) Verificar si el objetivo reaccionará oportunamente a las perturbaciones del campo magnético.
(e) Verificar si el objetivo reaccionará oportunamente ante los incendios.
(f) Verificar si el objetivo reaccionará oportunamente ante la denegación de acceso al objetivo mediante bloqueo o cuarentena.
(g) Verificar si el objetivo reaccionará oportunamente ante amenazas de miedo, revuelta o violencia dentro del alcance.
(h) Determinar la finalidad de la interceptación de la amenaza.

8.4 Auditoría de visibilidad

Pruebas de enumeración y verificación de la visibilidad de los objetivos y los activos. En PHYSSEC, los activos también deben incluir suministros
como alimentos, agua, combustible, etc. y procesos operativos que puedan afectar a dichos suministros como la eliminación adecuada de desechos
y otros contaminantes, la carga y descarga de los envíos de suministros, los ciclos de sueño y descanso, la aclimatación adecuada, etc.

8.4.1 Reconocimiento

(a) Mapear y detallar el perímetro de alcance determinado mediante técnicas de visualización visible y asistida, áreas de acceso público,
planos públicos y fuentes públicas.
(b) Enumerar y detallar los objetivos y activos visibles desde fuera del alcance.
(c) Enumerar y detallar los patrones de tráfico objetivo, el tráfico peatonal, las áreas ocupadas y los sensores visibles.
fuera del alcance.
(d) Enumerar directorios y guías telefónicas internas que identifiquen la ubicación de información sensible.
instalaciones de procesamiento de información que no son fácilmente accesibles al público.
(e) Mapear y enumerar la ubicación física y el diseño de los objetivos, el tamaño y la navegabilidad de los obstáculos, barreras y peligros
que aumentarán el tiempo en el objetivo.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
124 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.5 Verificación de acceso

Pruebas para la enumeración de puntos de acceso para interactuar con los objetivos y activos dentro del alcance. Si bien el acceso a muros
y vallas que bordean propiedades fuera del alcance es un escenario real y que se utiliza a menudo en un ataque, esta auditoría se limita a
la interacción solo dentro del alcance para proteger los derechos de propiedad de terceros.

8.5.1 Enumeración

(a) Mapear y explorar el terreno navegable, las barreras y los obstáculos en el ámbito de aplicación para alcanzar los objetivos y
los activos. Documentar todos los métodos utilizados y los resultados de dichos métodos.
(b) Mapear y verificar todos los puntos de acceso que permitan una interacción sigilosa o no monitoreada, directa (tiempo de 3
segundos o menos en el objetivo) con el objetivo.
(c) Verificar el tamaño y la navegabilidad de los puntos de acceso públicos y privados y todas las rutas de acceso al objetivo.

8.5.2 Autenticación

(a) Enumerar y probar para detectar deficiencias, qué privilegios se requieren para acceder, el proceso de obtención de esos
privilegios y asegurar que solo se proporcione acceso a las partes identificadas, autorizadas y previstas.

(b) Verificar el proceso de autenticación de qué elementos pueden ser llevados al alcance tanto por personal autorizado como no
autorizado.
(c) Verificar el proceso de autenticación de qué elementos pueden ser retirados del alcance tanto por personal autorizado como
no autorizado.
(d) Verificar el proceso de registro de acceso y qué elementos se ingresaron y se retiraron.

8.5.3 Ubicación
(a) Mapee la distancia desde el perímetro del alcance hasta los objetivos y activos visibles desde fuera del
alcance.
(b) Mapear e identificar todas las rutas a los puntos de acceso a los que se puede llegar mediante una interacción ruidosa, no
sigilosa y directa (3 segundos o menos de tiempo en el objetivo) con ese punto de acceso. Esto puede incluir ataques que
sean sans conatus (sin tener en cuenta la vida del atacante).

8.5.4 Penetración
(a) Determinar qué barreras y obstáculos en el alcance proporcionan acceso remoto al cambio,
perturbar, destruir u obtener activos (visual, auditivo y magnético).
(b) Determinar la eficacia de las barreras y obstáculos para soportar las condiciones definidas en el
Revisión de postura.
(c) Determinar y evaluar la eficacia de las barreras y obstáculos para resistir incendios, explosiones,
y fuerzas conmocionantes generales, como disparos y embestidas de vehículos.
(d) Determinar y evaluar la eficacia de las barreras y obstáculos para reducir los niveles críticos de ruido entrante, calor, frío,
humo, humedad, olores molestos o cáusticos, campos magnéticos intensos, luz dañina y contaminantes.

(e) Determinar y evaluar la efectividad de las barreras y obstáculos para reducir las emisiones de: sonidos, olores, vibraciones,
condiciones de aclimatación, humo, campos magnéticos, desechos y contaminantes.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 125
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.6 Verificación de confianza

Pruebas de confianza entre procesos dentro del ámbito donde la confianza se refiere al acceso a los activos sin necesidad de identificación o
autenticación.

8.6.1 Tergiversación

(a) Probar y documentar la profundidad de los requisitos para el acceso a los activos con el uso de declaraciones falsas como
miembro del personal de soporte o entrega “interno” sin las credenciales adecuadas.

(b) Probar y documentar la profundidad de los requisitos para el acceso a los activos con el uso de la representación falsa como
persona discapacitada.

8.6.2 Fraude

Probar y documentar la profundidad de los requisitos de acceso a los activos con el uso de representación fraudulenta de autoridad
como miembro de la gerencia u otro personal clave.

8.6.3 Desorientación

Probar y documentar la profundidad de los requisitos para el acceso a los activos con el uso de tergiversación como miembro del
personal de soporte o de entrega fuera del alcance.

8.6.4 Estiba

Probar y documentar la profundidad de los requisitos para el acceso a los activos a través de estiba sigilosa con un transporte de
apoyo o entrega para llevar la estiba fuera del alcance.

8.6.5 Malversación de fondos

Probar y documentar la profundidad de los requisitos para ocultar activos dentro del alcance (en su totalidad o destruidos), llevar
activos fuera del alcance a una fuente conocida y confiable, y a lo largo del alcance mismo a otro personal sin ninguna credencial
establecida y requerida.

8.6.6 En Terrorem

Probar y documentar la profundidad de los requisitos para incitar el miedo, la revuelta, la violencia y el caos, a través de la interrupción
de los procesos y la contaminación de los suministros.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
126 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.7 Verificación de controles

Pruebas para enumerar los tipos de controles de pérdidas utilizados para proteger el valor de los activos.

8.7.1 No repudio

Enumere y pruebe el uso o las deficiencias de los monitores y sensores para identificar y registrar adecuadamente el
acceso o las interacciones con los activos a fin de obtener evidencia específica para cuestionar el repudio. Documente la
profundidad de la interacción que se registra.

8.7.2 Confidencialidad

Enumerar y probar el uso o las deficiencias de todas las señales, comunicaciones físicas y elementos transportados entre procesos
y personal de alcance interno y externo utilizando códigos, lenguaje indescifrable, interacciones personales “silenciadas” o “cerradas”
para promover la confidencialidad de la comunicación solo con aquellos con la clasificación de autorización de seguridad adecuada
para esa comunicación.

8.7.3 Privacidad

Enumerar y probar el uso o las deficiencias de todas las interacciones dentro del alcance utilizando envases o etiquetas
sin marcar o no obvios, interacciones "silenciadas" o "en salas cerradas" y dentro de espacios elegidos al azar para ocultar
o proteger la privacidad de la interacción y solo para aquellos con la autorización de seguridad adecuada para ese proceso
o activo.

8.7.4 Integridad

(a) Enumerar y probar las deficiencias en todas las señales y comunicaciones entre los procesos y el personal utilizando
un proceso documentado, sellos, firmas, hash o marcas cifradas para proteger y asegurar que los activos no se
puedan cambiar, redirigir o revertir sin que las partes involucradas lo sepan.

(b) Enumerar y probar las deficiencias en todos los procesos e interacciones con los activos en transporte que utilizan un
proceso documentado, firmas, sellos, cintas desprendibles, marcas, etiquetas, sensores o marcas cifradas para
proteger y asegurar que los activos no se puedan cambiar, redirigir o revertir sin que las partes involucradas lo sepan.

(c) Verificar que todos los medios de almacenamiento de información no estén en peligro de deterioro no natural, como
daño por calor o humedad, decoloración por la luz solar directa o degradación magnética (podredumbre de bits).

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 127
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.8 Verificación del proceso

Pruebas para examinar el mantenimiento de las operaciones de seguridad funcional en los procesos establecidos y la debida diligencia según se
define en la Revisión de Postura.

8.8.1 Mantenimiento

(a) Examinar y documentar la puntualidad, idoneidad, acceso y alcance de los procesos de reparación de equipos y barreras en relación
con la seguridad operativa, la seguridad real y los controles de pérdidas.

(b) Verificar la reparación y determinar en qué medida el aviso y la calidad de las reparaciones pueden ser tergiversados y falsificados.

8.8.2 Indemnización

(a) Documentar y enumerar la capacidad de abusar o eludir las políticas de los empleados, los seguros, los contratos de confidencialidad,
de no competencia, de responsabilidad o las exenciones de responsabilidad de uso/usuario para el personal dentro del alcance.

(b) Enumerar el uso de señales de advertencia de peligro, vigilancia o alarmas vigentes, problemas de salud y carteles de prohibición de
paso.
(c) Verificar el alcance y la finalidad de las acciones legales utilizadas para hacer efectiva la indemnización.

8.9 Verificación de la configuración

Pruebas para examinar el funcionamiento de los procesos en distintos niveles de condiciones de seguridad. Comprender cómo funcionan los
procesos en condiciones de rutina y eficiencia diarias proporciona información sobre cómo deberían comportarse en condiciones más extremas.

8.9.1 Mapeo de la educación

Mapee los tipos y la frecuencia de la asistencia en materia de seguridad y protección física, los cursos de educación y la capacitación
brindados al personal, los socios, los clientes y, específicamente, a los guardianes.

8.9.2 Interrupción de la política

Descubra y examine el proceso y la profundidad del autocontrol del personal ante la interrupción o no conformidad con la política de
seguridad y protección física.

8.9.3 Condiciones de amenaza

(a) Mapear las respuestas preparadas de los procesos de seguridad en reacción a mayores niveles de condiciones de amenaza (es
decir, alertas verdes, amarillas, naranjas y rojas) según los requisitos determinados en la Revisión de Postura.

(b) Determinar qué factores desencadenantes son necesarios para aumentar los niveles de amenaza y verificar que se cumplan.
(c) Mapear las respuestas inmediatas de los procesos de seguridad en reacción a la disminución de los niveles de amenaza
según los requisitos determinados en la Revisión de Postura.
(d) Descubrir y examinar en qué medida una persona no oficial proporciona información errónea sobre los niveles de amenaza de manera
autorizada para aumentar o reducir deliberadamente el estado de preparación.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
128 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.10 Validación de la propiedad

Pruebas para examinar la propiedad física disponible dentro del alcance o proporcionada por el personal que pueda ser ilegal o poco ética.

8.10.1 Compartir

Verificar en qué medida los activos personales o de la organización han sido falsificados, reproducidos o compartidos de manera
ilegal e intencional de acuerdo con los requisitos de la Revisión de Postura a través de servicios de intercambio, préstamo, alquiler o
arrendamiento, bibliotecas personales y cachés personales o de manera no intencional por ignorancia o negligencia.

8.10.2 Mercado negro

Verificar en qué medida los activos personales o de la organización han sido falsificados o reproducidos y están siendo promocionados,
comercializados o vendidos entre el personal o por la organización.

8.10.3 Canales de venta

Verificar activos en subastas, mercados de pulgas, anuncios clasificados, ventas de garaje, reuniones de intercambio o ventas de
propiedades que brinden información de contacto a través de canales que se originan dentro del alcance.

8.10.4 Almacenamiento

(a) Verificar que las ubicaciones de almacenamiento y los pequeños cachés de activos organizacionales estén en el lugar apropiado.
Ubicación dentro del alcance.
(b) Verificar que las ubicaciones de almacenamiento y los pequeños depósitos de activos de la organización para uso o venta pública
o a otros miembros de la organización no se estén ocultando, acaparando, controlando o guardando deliberadamente.

8.10.5 Abuso de recursos

(a) Enumerar los artículos personales que consumen energía, combustible, alimentos, agua u otros activos dentro de los requisitos
definidos en la Revisión de Postura.
(b) Enumerar los artículos personales utilizando canales que son propiedad de la organización (es decir,
(c) Enumere los elementos personales que se puedan ver
abiertamente y que simbolicen creencias que no estén dentro de los requisitos.
definido en la Revisión de Postura.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 129
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.11 Revisión de la segregación

Pruebas para separar adecuadamente la información privada o personal de la información empresarial. Al igual que una revisión de privacidad,
es el punto central del almacenamiento, transporte y control legal y ético de la información privada del personal, socios y clientes.

8.11.1 Mapeo de contención de privacidad

Mapear las ubicaciones de almacenamiento de información privada dentro del alcance, qué información se almacena, cómo y dónde se
almacena la información, y cómo y dónde se descarta la propiedad.

8.11.2 Información Evidente

Enumerar y mapear a partir de los documentos de destino y la propiedad física con información personal no segura según se define
implícitamente como privada en las regulaciones y políticas de la Revisión de Postura (es decir, nombres completos, raza, sexo, religión,
días de vacaciones, páginas web personales, currículums publicados, afiliaciones personales, consultas de directorio, sucursal bancaria,
registro electoral, etc.).

8.11.3 Divulgación

Verificar el acceso a los almacenes de información privada propiedad del personal según lo determinado en la Revisión de Postura.

8.11.4 Limitaciones

Examinar y documentar alternativas de movilidad accesibles para personas con limitaciones físicas dentro de ese canal.

8.11.4 Materiales ofensivos

Verifique que la propiedad personal visible al público no haga alarde ni ofenda como se determina como ofensiva o privada en la
Revisión de Postura.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
130 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.12 Verificación de la exposición

Pruebas para descubrir información que permita o conduzca al acceso autenticado o permita el acceso a múltiples
ubicaciones con la misma autenticación.

8.12.1 Mapeo de exposición

Descubra y enumere documentos y elementos no seguros con información de construcción sobre la organización, como
planos, logística, horarios, llaves, tokens de acceso, insignias, uniformes o cualquier activo organizacional particular que
proporcione un acceso más profundo o más amplio.

8.12.2 Elaboración de perfiles

(a) Perfilar y verificar la definición estructural de los objetivos, incluyendo tipo de material, altura, espesor y propiedades
de seguridad. (b) Descubrir y enumerar sensores
de control de acceso, cámaras, monitores, trampas para personas, jaulas, portones, cercas, etc. para tipo, tecnología,
fabricante, materiales y propiedades de seguridad.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 131
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.13 Inteligencia Competitiva

Pruebas para recopilar información que pueda analizarse como inteligencia empresarial. Si bien la inteligencia competitiva como campo está
relacionada con el marketing, el proceso aquí incluye cualquier forma de recopilación de inteligencia competitiva, incluido, entre otros, el
espionaje económico e industrial.

8.13.1 Rectificado comercial

Descubra y mapee las ubicaciones de almacenamiento de la propiedad comercial dentro del alcance, qué información se almacena,
cómo y dónde se almacena la información y cómo y dónde se descarta la propiedad.

8.13.2 Entorno empresarial

Descubra y enumere documentos y artículos con detalles comerciales como personal, tasas de pago, alianzas, socios, clientes
principales, proveedores, distribuidores, inversores, relaciones comerciales, producción, desarrollo, información de productos,
planificación, existencias y comercio, y cualquier información o propiedad comercial particular determinada implícitamente como
confidencial o de no competencia a partir de la Revisión de Postura.

8.13.3 Entorno organizacional

Descubra y enumere documentos y elementos con detalles organizacionales tales como procesos, jerarquía, informes financieros,
oportunidades de inversión, fusiones, adquisiciones, inversiones de canales, mantenimiento de canales, políticas sociales internas,
insatisfacción del personal y tasa de rotación, tiempos de vacaciones principales, contrataciones, despidos y cualquier propiedad
organizacional particular indicada implícitamente como confidencial o de no competencia de la Revisión de Postura.

8.13.4 Entorno operativo

Descubrir y enumerar procesos que exponen detalles operativos tales como embalaje, envío, distribución, tiempos de llegada y salida
de empleados, administración, clientes, métodos de interacción, planes de publicidad y marketing, desarrollo de productos, capacidad
de productos y cualquier propiedad operativa particular indicada implícitamente como confidencial o de no competencia de la Revisión
de Postura.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
132 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.14 Verificación de cuarentena

Pruebas para verificar la correcta colocación y contención de personas y procesos con intención agresiva u hostil dentro del
ámbito de aplicación.

8.14.1 Identificación del proceso de contención

(a) Identificar y examinar los métodos y procesos de cuarentena física dentro del alcance de contactos agresivos y hostiles, como
personas caóticas o violentas, vendedores no programados, cazatalentos, estafadores, periodistas, competidores, solicitantes
de empleo, candidatos a un puesto de trabajo y personas disruptivas.

(b) Identificar y examinar los métodos y procesos de cuarentena física dentro del alcance para la gestión de artículos o sustancias
peligrosas y dañinas, sustancias ilegales y propiedad de la empresa retirada ilegalmente.

(c) Identificar y examinar los métodos y procesos de cuarentena física dentro del alcance de comportamientos meramente
sospechosos o artículos y sustancias de utilidad sospechosa.

8.14.2 Niveles de contención

(a) Verificar el estado del lugar de contención, la duración y el proceso del método de cuarentena. Asegurarse de que los métodos
se encuentren dentro del contexto y los límites legales según la Revisión de la postura.

(b) Verificar que se sigan los procedimientos adecuados para un bloqueo total según los requisitos de la Revisión de Postura para
amenazas ambientales, amenazas de contaminación biológica, química o de otro tipo y en casos de violencia en el lugar de
trabajo.
(c) Verificar los procedimientos adecuados para la recuperación de la cuarentena y el regreso al estado seguro adecuado.
después de un estado de bloqueo según los requisitos de la Revisión de Postura.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 133
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.15 Auditoría de privilegios

Pruebas para obtener credenciales de acceso y privilegios proporcionados a otro personal con los permisos adecuados.

8.15.1 Identificación

Examinar y documentar el proceso de obtención de identificación a través de medios legítimos, ilegales (es decir,
sobornos, robo, amenazas, etc.) y fraudulentos (falsificación, tergiversación, etc.).

8.15.2 Autorización

Verificar el uso de autorización fraudulenta para obtener privilegios similares a los del resto del personal.

8.15.3 Escalada

Verificar y enumerar los accesos a los activos mediante el uso de privilegios para obtener privilegios superiores a
los de los guardianes.

8.15.4 Circunstancias especiales

Verificar la obtención de los privilegios de acceso solicitados en los casos en que la edad (específicamente
aquellos considerados legalmente como menores para la región), la relación (es decir, hijo, hija, padre, madre,
etc.), el sexo, la raza, las costumbres/cultura y la religión sean factores a los que se les puedan otorgar
circunstancias especiales o discriminar de acuerdo con la Revisión de Postura.

8.15.5 Subyugación
Enumerar y probar las deficiencias en el acceso a activos no controlados por la fuente que proporciona el acceso
(es decir, PIN, fotografías de identificación, etc. seleccionados por el actor, inicios de sesión con números de
identificación escritos por el actor, etc.).

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
134 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.16 Validación de la capacidad de supervivencia

Determinar y medir la resiliencia de las barreras y resguardos dentro del alcance ante cambios excesivos u hostiles
diseñados para provocar fallas en las operaciones.

8.16.1 Resiliencia

(a) Enumerar y verificar que la distracción, remoción o silenciamiento del personal de entrada no permitirá el acceso
directo a los activos u operaciones.
(b) Enumerar y verificar que la desactivación o destrucción de las medidas o controles de seguridad operacional no
permitirá el acceso directo a los activos u operaciones.
(c) Verificar que el alcance esté aislado de recursos tales como combustible, energía, alimentos, agua,
comunicaciones, etc. no permite el acceso directo a los activos u operaciones.
(d) Verificar que las condiciones de amenaza de alta alerta no detengan o minimicen las medidas de seguridad operativa
o los controles que permitan el acceso directo a los activos u operaciones.

8.16.2 Continuidad

(a) Enumerar y verificar las condiciones en las que los retrasos en el acceso se abordan adecuadamente a través de
personal de respaldo o un medio automatizado para el acceso oportuno a los servicios, procesos y operaciones.
(b) Enumerar y verificar que la distracción, remoción o silenciamiento del personal de entrada no
detener o denegar el acceso oportuno a servicios, procesos y operaciones.
(c) Enumerar y verificar que la desactivación o destrucción de las medidas de seguridad operacional o
Los controles no negarán el acceso oportuno a los servicios, procesos y operaciones.
(d) Verificar que el aislamiento del alcance de recursos tales como combustible, energía eléctrica, alimentos, agua,
comunicaciones, etc. no detendrá ni negará el acceso a servicios, procesos y operaciones.
(e) Verificar que la imposibilidad de eliminar desechos, contaminantes u otros contaminantes del alcance no detendrá
ni negará el acceso a los servicios, procesos y operaciones.
(f) Verificar que las condiciones de amenaza de alta alerta no detengan ni nieguen el acceso a los servicios, procesos y
operaciones.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 135
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

8.17 Revisión de alertas y registros

Un análisis de la brecha entre las actividades realizadas con la prueba y la profundidad real de esas actividades tal como se registraron
o según las percepciones de terceros, tanto humanos como mecánicos.

8.17.1 Alarm

Verificar y enumerar el uso de un sistema, registro o mensaje de advertencia local o de alcance amplio para cada puerta de acceso
donde el personal detecte una situación sospechosa por sospecha de intentos de elusión, actividad fraudulenta, intrusión o infracción.
Asegurarse de que los sensores/sistemas estén instalados de acuerdo con estándares nacionales, regionales o internacionales y se
prueben periódicamente para cubrir todos los puntos accesibles.

8.17.2 Almacenamiento y recuperación

Documentar y verificar los permisos y el acceso eficiente a las ubicaciones y propiedades de almacenamiento de alarmas, registros y
notificaciones. El acceso a las áreas donde se procesa o almacena información confidencial debe estar controlado y restringido
únicamente al personal autorizado; se debe mantener un registro de auditoría de todos los accesos de forma segura.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
136 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

La información que se encuentra dentro del espectro

inalámbrico no se limita a las especificaciones del
producto.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 137
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 9 ­ Pruebas de seguridad inalámbrica

La seguridad del espectro (SPECSEC) es la clasificación de seguridad que incluye la seguridad electrónica (ELSEC), la seguridad de las señales
(SIGSEC) y la seguridad de las emanaciones (EMSEC). ELSEC son las medidas para denegar el acceso no autorizado a la información derivada
de la interceptación y el análisis de radiaciones electromagnéticas no relacionadas con las comunicaciones. SIGSEC son las medidas para
proteger las comunicaciones inalámbricas del acceso no autorizado y la interferencia. EMSEC son las medidas para evitar las emanaciones de
las máquinas que, si se interceptan y analizan, revelarían la información transmitida, recibida, manejada o procesada de otro modo por los
equipos de los sistemas de información. La prueba de este canal requiere la interacción con barreras a los activos en frecuencias
electromagnéticas (EM) y de microondas (MW).

Este canal cubre la interacción del analista dentro del rango de proximidad de los objetivos. Si bien algunos servicios consideran esto simplemente
como un "escaneo", los verdaderos objetivos de cumplimiento de las pruebas de seguridad en este canal son las pruebas de barreras físicas y
lógicas y la medición de brechas según el estándar de seguridad requerido delineado en la política de la empresa, las regulaciones de la industria
o la legislación regional.

El analista deberá contar con la protección adecuada contra fuentes de energía electromagnética y otras formas de radiación. Los analistas
también deberán estar preparados para la posibilidad de sufrir daños corporales accidentales por exposición a la radiación electromagnética y
de microondas, especialmente la que puede dañar permanentemente la audición o la vista. El equipo adecuado debe advertir cuando se
encuentre dentro del rango de radiación electromagnética y de microondas de ­12 dB o más. Algunas frecuencias específicas pueden afectar
negativamente a los dispositivos médicos implantados, causar vértigo, dolores de cabeza, calambres estomacales, diarrea y otras molestias
tanto a nivel emocional como físico.

Los analistas competentes requerirán conocimientos suficientes de radiación EM y MW y habilidades de pensamiento crítico para garantizar que
la recopilación de datos factuales cree resultados factuales a través de la correlación y el análisis.

Consideraciones
Tenga en cuenta las siguientes consideraciones para garantizar una prueba segura y de alta calidad:

1. Ignorantia legis neminem excusat: los analistas que no realizan una revisión adecuada de la postura en relación con el alcance y las
regiones a las que se dirigen los negocios o las interacciones no pueden escapar del castigo por violar las leyes simplemente porque
desconocían la ley; es decir, los analistas tienen un conocimiento presunto de la ley. Los analistas son considerados profesionales en
esta materia y, por lo tanto, se presupone que incluso lo que puede no ser de conocimiento común para la persona promedio sobre las
leyes de una región extranjera en relación con los sistemas de comunicación EM y MW, será conocido por el analista.

2. En persona: las pruebas deben estar dirigidas específicamente solo a SPECSEC del personal que tiene un contrato legal directo con el
propietario del osciloscopio, sistemas informáticos en la propiedad del propietario del osciloscopio y señales electromagnéticas o de
microondas o emanaciones de nivel de potencia lo suficientemente grande como para interrumpir o dañar las comunicaciones
inalámbricas dentro del osciloscopio. Los analistas deben esforzarse por no invadir la vida privada de una persona, como escuchar o
grabar comunicaciones personales que se originen dentro del osciloscopio, cuando esa vida privada haya hecho esfuerzos por
separarse del osciloscopio.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
138 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.1 Revisión de la postura

Los estudios iniciales de la postura incluyen las leyes, la ética, las políticas, las regulaciones de la industria y la cultura política
que influyen en los requisitos de seguridad y privacidad para el ámbito de aplicación. Esta revisión forma una matriz a la que se
deben asignar las pruebas, pero no limitarlas.

9.1.1 Política

Revisar y documentar la política organizacional correspondiente en relación con las responsabilidades de seguridad,
integridad y privacidad del ámbito de aplicación. Revisar y documentar los contratos y los acuerdos de nivel de servicio
(SLA) con los proveedores de servicios y otros terceros involucrados.

9.1.2 Legislación

Revisar y documentar la legislación regional y nacional apropiada y las regulaciones de la industria con respecto a los
requisitos de seguridad y privacidad de la organización dentro del alcance, así como aquellos que incluyen a los clientes,
socios, sucursales organizacionales o revendedores apropiados fuera del alcance.

9.1.3 Cultura

Revisar y documentar la cultura organizacional apropiada en el ámbito de la concientización sobre seguridad y

privacidad, la capacitación de personal requerida y disponible, la jerarquía organizacional, el uso de la mesa de ayuda y
los requisitos para informar problemas de seguridad.

9.1.4 Edad
Revisar y documentar la antigüedad de los sistemas, software y aplicaciones de servicio necesarios para las operaciones.

9.1.5 Artefactos frágiles

Revisar y documentar cualquier sistema, software y aplicación de servicio que requiera cuidado especial debido al alto
uso, inestabilidad o una alta tasa de cambio.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 139
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.2 Logística
Preparación del entorno de prueba del canal necesaria para evitar falsos positivos y falsos negativos que conducen a resultados de prueba
inexactos.

9.2.1 Equipos de comunicaciones

Prueba de equipos que puedan transmitir radiación electromagnética, como CRT, LCD, impresoras, módems y teléfonos celulares,
y que puedan usarse para recrear los datos que se muestran en la pantalla, se imprimen o se transmiten, etc. La explotación de
esta vulnerabilidad se conoce como Van Eck phreaking.

9.2.2 Comunicaciones

Probar qué protocolos se utilizan dentro del alcance y los métodos de transmisión.

9.2.3 Tiempo

Pruebe el horario de funcionamiento del equipo. Por ejemplo, ¿un punto de acceso inalámbrico (PA) está disponible las 24 horas del
día, los 7 días de la semana o solo durante el horario comercial normal?

9.3 Verificación de detección activa

La determinación de los controles activos y pasivos para detectar intrusiones para filtrar o denegar intentos de prueba debe realizarse antes
de la prueba para mitigar el riesgo de crear falsos positivos y negativos en los datos de los resultados de la prueba, así como cambiar el
estado de alarma del personal o los agentes de monitoreo.

9.3.1 Monitoreo de canales

Pruebe si existen controles para monitorear intrusiones o manipulación de señales.

9.3.2 Moderación de canales

Pruebe si existen controles para bloquear señales (bloqueo) o alertar sobre actividades no autorizadas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
140 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.4 Auditoría de visibilidad

Pruebas de enumeración y verificación de la visibilidad del personal con el que es posible interactuar a través de todos los canales.

9.4.1 Intercepción
Localice el control de acceso, la seguridad perimetral y la capacidad de interceptar o interferir con canales inalámbricos.

9.4.2 Detección de señal pasiva

(a) Determinar qué frecuencias y señales pueden filtrarse dentro o fuera del área objetivo utilizando una antena
direccional de alta ganancia y medios de detección pasivos como el análisis de frecuencia.
(b) Cree un mapa de calor del alcance que muestre todas las fuentes de radiación y sus radios y
fortaleza.
(c) Prueba de fuentes que interactúan sin autorización.
(d) Recopilar información difundida por estas fuentes.
(e) Asignar todos los datos encontrados a los valores límite de emisión requeridos actualmente en la región para todos los contaminantes detectados.
radiación.

9.4.2 Detección de señal activa

Examine qué frecuencias o transmisiones de señales electromagnéticas desencadenan respuestas como las de
RFID u otras fuentes inalámbricas interactivas. (Las etiquetas de identificación por radiofrecuencia se componen de
un circuito integrado, que a veces tiene la mitad del tamaño de un grano de arena, y una antena, generalmente una
bobina de cables. La información se almacena en el circuito integrado y se transmite a través de la antena cuando
es detectada por la señal correcta. Por lo tanto, las frecuencias exactas utilizadas en los sistemas RFID pueden
variar según el país o la región).

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 141
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.5 Verificación de acceso

Pruebas para la enumeración de los puntos de acceso al personal dentro del ámbito de aplicación. Si bien el acceso al personal fuera del ámbito de
aplicación es un escenario real y se utiliza a menudo para el robo de información, el analista puede limitarse a la interacción solo dentro del ámbito
de aplicación para proteger los derechos de privacidad independientes del personal en su vida privada.

9.5.1 Evaluar el acceso administrativo a los dispositivos inalámbricos

Determinar si los puntos de acceso se apagarán durante los momentos del día en que no estarán en uso.

9.5.2 Evaluar la configuración del dispositivo

Pruebe y documente utilizando antenas direccionales y de alta ganancia que los dispositivos inalámbricos estén configurados con la
configuración de potencia más baja posible para mantener un funcionamiento suficiente que mantenga las transmisiones dentro de los
límites seguros de la organización.

9.5.3 Evaluación de la configuración, autenticación y cifrado de redes inalámbricas

Verifique que se haya cambiado el Identificador de conjunto de servicios (SSID) predeterminado del punto de acceso.

9.54 Autenticación

Enumerar y probar las deficiencias en los métodos de autenticación y autorización.

9.5.5 Control de acceso

Evaluar los controles de acceso, la seguridad perimetral y la capacidad de interceptar o interferir en la comunicación, determinando el
nivel de controles de acceso físico a los puntos de acceso y dispositivos que los controlan (cerraduras con llave, lectores de tarjetas,
cámaras, etc.).

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
142 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.6 Verificación de confianza

Pruebas de confianza entre el personal dentro del ámbito donde la confianza se refiere al acceso a información o propiedad física sin necesidad
de identificación o autenticación.

9.6.1 Tergiversación

Probar y documentar el método de autenticación de los clientes.

9.6.2 Fraude

Probar y documentar la profundidad de los requisitos para el acceso a dispositivos inalámbricos dentro del alcance con el uso de
credenciales fraudulentas.

9.6.3 Abuso de recursos

Probar y documentar la profundidad de los requisitos para enviar la propiedad fuera del alcance a una fuente conocida y confiable o
dentro del alcance mismo a otro personal sin ninguna credencial establecida y requerida.

9.6.4 Confianza ciega

Pruebe y documente las conexiones que se realizan a un receptor falso o comprometido.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 143
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.7 Verificación de controles

Pruebas para enumerar los tipos de controles de pérdida utilizados para proteger la información.

9.7.1 No repudio

Enumerar y probar el uso o las deficiencias de los daemons y sistemas para identificar y registrar adecuadamente
el acceso o las interacciones con la propiedad para obtener evidencia específica para desafiar el repudio y
documentar la profundidad de la interacción registrada y el proceso de identificación.

9.7.2 Confidencialidad

Enumerar y probar el uso de equipos para amortiguar señales de transmisión electromagnética fuera de la empresa y los
controles establecidos para asegurar o cifrar las transmisiones inalámbricas.

9.7.3 Privacidad

Determinar el nivel de controles de acceso físico a los puntos de acceso y dispositivos que los controlan (cerraduras con llave,
lectores de tarjetas, cámaras, etc.).

9.7.4 Integridad

Determinar que los datos sólo puedan ser accedidos y modificados por aquellos que estén autorizados y asegurar que se utilice un
cifrado adecuado para garantizar la firma y la confidencialidad de las comunicaciones.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
144 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.8 Verificación del proceso

Pruebas para examinar el mantenimiento de la conciencia de seguridad funcional del personal en los procesos establecidos y la debida
diligencia según se define en la Revisión de Postura.

9.8.1 Línea base

Examine y documente la configuración de referencia para garantizar que la postura de seguridad esté en línea con la política de
seguridad.

9.8.2 Blindaje adecuado

Examine y determine que se haya instalado el blindaje adecuado. Por ejemplo, determine que las impresoras estén en gabinetes
especialmente blindados para bloquear los EMT, que se utilicen paneles o pintura metálica para bloquear las señales inalámbricas,
etc.

9.8.3 Debida diligencia

Mapear y verificar cualquier brecha entre la práctica y los requisitos determinados en la Revisión de Postura a través de todos los
canales.

9.8.4 Indemnización

Documentar y enumerar los objetivos y servicios que están protegidos contra el abuso o la elusión de la política de los empleados,
están asegurados contra robo o daños, o utilizan exenciones de responsabilidad y permisos. Verificar la legalidad y la idoneidad
del lenguaje de las exenciones de responsabilidad.

9.9 Verificación de la configuración

Pruebas para examinar la capacidad de eludir o interrumpir la seguridad funcional de los activos.

9.9.1 Errores de configuración comunes

Realice ataques de fuerza bruta contra puntos de acceso para determinar la solidez de las contraseñas. Verifique que las
contraseñas contengan letras mayúsculas y minúsculas, números y caracteres especiales. Los puntos de acceso que utilizan
contraseñas que no distinguen entre mayúsculas y minúsculas facilitan a los atacantes realizar un ataque de adivinación por
fuerza bruta debido al menor espacio entre las posibles contraseñas.

9.9.2 Controles de configuración

Examinar los controles, incluida la configuración de referencia, para validar que las configuraciones cumplan con la política de
seguridad.

9.9.3 Evaluar y probar el cableado y las emisiones

Verifique que todos los cables que entran y salen de las salas blindadas estén hechos de fibra, siempre que sea posible.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 145
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.10 Validación de la propiedad

Pruebas para examinar la información y la propiedad física disponibles dentro del alcance, o proporcionadas por el personal, que puedan ser
ilegales o poco éticas.

9.10.1 Compartir

Verificar hasta qué punto la propiedad con licencia individual, privada, falsificada, reproducida, no libre o no abierta se comparte
entre el personal, ya sea intencionalmente a través del intercambio de procesos y programas, bibliotecas y cachés personales, o
involuntariamente a través de la mala administración de licencias y recursos, o negligencia.

9.10.2 Transceptores inalámbricos no autorizados

Realizar un inventario completo de todos los dispositivos inalámbricos. Verificar que la organización cuente con una política de
seguridad adecuada que aborde el uso de tecnología inalámbrica.

9.11 Revisión de la segregación

Pruebas para separar adecuadamente la información privada o personal de la información empresarial. Al igual que una revisión de privacidad,
es el punto focal del almacenamiento, transmisión y control legal y ético de la información privada del personal, socios y clientes.

9.11.1 Mapeo de contención de privacidad

Mapee a los guardianes de la información privada dentro del alcance, qué información se almacena, cómo y dónde se almacena la
información y a través de qué canales se comunica la información.

9.11.3 Divulgación

Examinar y documentar los tipos de divulgaciones de información privada en el espectro inalámbrico.

9.11.4 Limitaciones

Examinar y documentar los tipos de puertas de enlace y alternativas de canales accesibles para personas con limitaciones físicas
dentro de ese canal.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
146 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.12 Verificación de la exposición

Pruebas para descubrir información que permita o conduzca al acceso autenticado o permita el acceso a múltiples
ubicaciones con la misma autenticación.

9.12.1 Mapeo de exposición

Enumerar y mapear información del personal sobre la organización, tal como organigramas, títulos de personal clave, descripciones
de trabajo, números de teléfono personales y laborales, números de teléfono móvil, tarjetas de presentación, documentos
compartidos, currículums, afiliaciones organizacionales, direcciones de correo electrónico privadas y públicas, inicios de sesión,
esquemas de inicio de sesión, contraseñas, métodos de respaldo, aseguradoras o cualquier información organizacional particular
declarada implícitamente como confidencial en regulaciones y políticas.

9.12.2 Elaboración de perfiles

Examine y verifique con el uso de una antena direccional y de alta ganancia si las señales inalámbricas con información sobre el
dispositivo se extienden más allá de las paredes o la propiedad del objetivo.

9.13 Inteligencia Competitiva

Pruebas para recopilar información que pueda analizarse como inteligencia empresarial. Si bien la inteligencia competitiva como campo
está relacionada con el marketing, el proceso aquí incluye cualquier forma de recopilación de inteligencia competitiva, incluido, entre otros,
el espionaje económico e industrial.

9.13.1 Rectificado comercial

Mapear objetivos dentro del alcance del análisis activo y pasivo de emanaciones: qué información se almacena, cómo y dónde se
almacena la información y cómo se comunica la información.

9.13.2 Entorno empresarial

Explorar y documentar detalles comerciales tales como alianzas, socios, clientes principales, proveedores, distribuidores,
inversores, relaciones comerciales, producción, desarrollo, información de productos, planificación, existencias y comercio, y
cualquier información o propiedad comercial particular declarada implícitamente como confidencial en regulaciones y políticas.

9.13.3 Entorno organizacional

Examinar y documentar los tipos de divulgaciones de propiedad comercial de los guardianes sobre operaciones, procesos,
jerarquía, informes financieros, oportunidades de inversión, fusiones, adquisiciones, inversiones de canal, mantenimiento de canal,
política social interna, insatisfacción del personal y tasa de rotación, tiempos de vacaciones principales, contrataciones, despidos
y cualquier propiedad organizacional particular indicada implícitamente como confidencial en regulaciones y políticas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 147
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.14 Verificación de cuarentena

La determinación y medición del uso efectivo de la cuarentena para todos los accesos al objetivo y dentro de él.

9.14.1 Identificación del proceso de contención

Identificar y examinar los métodos y procesos de cuarentena en el objetivo en todos los canales para detectar contactos agresivos
y hostiles.

9.14.2 Niveles de contención

Verificar el estado de contención, el tiempo de duración y todos los canales en los que se realizan interacciones con métodos de
cuarentena. Asegurarse de que los métodos se encuentren dentro del contexto y los límites legales.

9.15 Auditoría de privilegios

Pruebas en las que se proporcionan credenciales al usuario y se le concede permiso para realizar pruebas con esas credenciales.

9.15.1 Identificación

Examinar y documentar el proceso de obtención de identificación a través de medios legítimos y fraudulentos en todos los canales.

9.15.2 Autorización

Verificar el uso de autorización fraudulenta en todos los canales para obtener privilegios similares a los del resto del personal.

9.15.3 Escalada

Verificar y mapear el acceso a la información mediante el uso de privilegios para obtener mayores privilegios.

9.15.4 Subyugación

Enumerar y probar las deficiencias de todos los canales para utilizar o habilitar controles de pérdida que no están habilitados de forma
predeterminada.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
148 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

9.16 Validación de la capacidad de supervivencia

Determinar y medir la resiliencia del objetivo dentro del alcance ante cambios excesivos u hostiles diseñados para provocar fallas en el
servicio.

9.16.1 Continuidad

Enumerar y probar las deficiencias del objetivo con respecto a los retrasos en el acceso y el tiempo de respuesta del servicio a través
de personal de respaldo o medios automatizados para acceso alternativo.

9.16.2 Resiliencia

Mapear y documentar el proceso por el cual los guardianes desconectan canales debido a violaciones o problemas de seguridad
como un análisis de brechas con la regulación y la política de seguridad.

9.17 Revisión de alertas y registros

Un análisis de la brecha entre las actividades realizadas con la prueba y la profundidad real de esas actividades tal como se registraron
o según las percepciones de terceros, tanto humanos como mecánicos.

9.17.1 Alarm

Verificar y enumerar el uso de un sistema, registro o mensaje de advertencia localizado o de alcance amplio para cada puerta de
acceso en cada canal donde el personal detecte una situación sospechosa por sospecha de intentos de evasión, ingeniería social o
actividad fraudulenta.

9.17.2 Almacenamiento y recuperación

Documentar y verificar el acceso sin privilegios a las ubicaciones y propiedades de almacenamiento de alarmas, registros y
notificaciones.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 149
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

En las telecomunicaciones, las personas son parte del

proceso tanto como las máquinas y rara vez son
mutuamente excluyentes.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
150 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 10 ­ Pruebas de seguridad de las telecomunicaciones

COMSEC es una clasificación para la seguridad material dentro del ámbito ELSEC que está dentro de los límites de las telecomunicaciones por
cables.

Este canal cubre la interacción del analista con los objetivos. Si bien algunos servicios consideran esto simplemente como “phreaking”, el
verdadero objetivo de cumplimiento de las pruebas de seguridad en este canal es la prueba de barreras lógicas y la medición de brechas en
relación con el estándar de seguridad requerido, tal como se describe en la política de la empresa, las regulaciones de la industria o la legislación
regional.

El analista deberá contar con múltiples herramientas y métodos para realizar algunas tareas a fin de garantizar que no se despierten sospechas
entre el personal por el sonido continuo y secuencial de los teléfonos y que las pruebas no se invaliden debido a un descubrimiento temprano o
a una mayor paranoia. Los analistas también deberán estar preparados para trabajar con equipos de telecomunicaciones digitales y analógicos,
analizadores de frecuencia de sonido y dentro de redes de información que proporcionen contenido regional a través de proveedores de telefonía
locales.

Los analistas competentes requerirán experiencia en electrónica tanto en telefonía analógica como digital y habilidades de pensamiento crítico
para garantizar que la recopilación de datos factuales genere resultados factuales a través de la correlación y el análisis.

Consideraciones
Tenga en cuenta las siguientes consideraciones para garantizar una prueba segura y de alta calidad:

1. Ignorantia legis neminem excusat: Los analistas que no realizan una revisión adecuada de la postura en relación con el alcance y las
regiones a las que se dirigen los negocios o las interacciones no pueden escapar del castigo por violar las leyes simplemente porque
desconocían la ley; es decir, se presume que las personas conocen la ley. Los analistas son considerados profesionales en esta
materia y, por lo tanto, se presupone que incluso lo que puede no ser de conocimiento común para una persona normal sobre las leyes
de una región extranjera en materia de sistemas informáticos, será conocido por los profesionales, ya que conocen las leyes necesarias
para llevar a cabo sus tareas.

2. Derechos de propiedad: Las pruebas deben estar dirigidas específicamente solo a sistemas que estén bajo la propiedad legal directa del
propietario del alcance o sistemas informáticos que se encuentren en la propiedad del propietario del alcance. Dicha propiedad o
efectos personales deben seguir siendo personales y privados a menos que involucren específicamente al propietario del alcance a
través de menosprecio, falsa luz, competitividad o razones establecidas en los acuerdos contractuales del personal. Los analistas
deben hacer esfuerzos para no invadir la vida privada de una persona cuando esa vida privada haya hecho esfuerzos por separarse
del alcance. Los analistas con un acuerdo especial para probar sistemas que están bajo contrato directo pero que no son de su
propiedad, o que son de su propiedad pero no se encuentran en la propiedad legal del propietario, deben tener mucho cuidado para
asegurar que las pruebas tengan un impacto mínimo en otros sistemas fuera del alcance o contrato.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 151
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.1 Revisión de la postura

Los estudios iniciales de la postura incluyen las leyes, la ética, las políticas, las regulaciones de la industria y la cultura política
que influyen en los requisitos de seguridad y privacidad para el ámbito. En la mayoría de los casos, un objetivo también
puede tener contratos con proveedores y otros terceros que pueden necesitar ser revisados y documentados.
Esta revisión forma una matriz con la que se deben mapear las pruebas, pero no limitarlas, debido a la ubicuidad de los
puntos finales del canal. Por lo tanto, es importante considerar, como lo exigen algunas legislaciones, el mercado objetivo o
los usuarios finales de este canal, que también deben agregarse al alcance de este módulo.

10.1.1 Política
(a) Revisar y documentar la política organizacional correspondiente en relación con los requisitos de seguridad,
integridad y privacidad del ámbito de aplicación. Verificar las limitaciones a las telecomunicaciones impuestas
por la política de seguridad.
(b) Revisar y documentar los contratos y Acuerdos de Nivel de Servicio (SLA) con los proveedores de servicios.
y otros terceros involucrados.

10.1.2 Legislación
Revise y documente la legislación regional y nacional correspondiente en relación con los requisitos de seguridad y privacidad de la
organización en el ámbito de aplicación, así como la que incluye a los clientes, socios, sucursales de la organización o revendedores
correspondientes fuera del ámbito de aplicación. Cuando corresponda, preste especial atención a la privacidad y la retención de
datos de los registros de detalles de llamadas, las leyes y las normas que rigen la interceptación o el monitoreo de las
telecomunicaciones y la prestación de servicios críticos como el E­911.

10.1.3 Cultura

Revisar y documentar la cultura organizacional apropiada en el ámbito de la concientización sobre seguridad y

privacidad, la capacitación de personal requerida y disponible, la jerarquía organizacional, el uso de la mesa de
ayuda y los requisitos para informar problemas de seguridad.

10.1.4 Edad
Revisar y documentar la antigüedad de los sistemas, software y aplicaciones de servicio necesarios para las
operaciones.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
152 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.1.5 Artefactos frágiles

Revisar y documentar cualquier sistema, software y aplicación de servicio que requiera cuidado especial debido al alto uso,
inestabilidad o una alta tasa de cambio.

10.1.6 Vectores de ataque

(a) Pruebas de PBX

(b) Prueba del buzón de voz
(c) Encuesta, sondeo y prueba de FAX y módem
(d) Pruebas de servicios de acceso remoto (RAS)
(e) Pruebas de líneas RDSI de respaldo
(f) Pruebas de voz sobre IP
(g) Pruebas de redes conmutadas por paquetes X.25

10.2 Logística
Preparación del entorno de prueba del canal necesaria para evitar falsos positivos y falsos negativos que conducen a resultados de prueba
inexactos.

10.2.1 Marco

(a) Verificar el alcance y los propietarios de los objetivos delineados para la auditoría, junto con los operadores y otros terceros que
administran las líneas y la infraestructura de telecomunicaciones para los objetivos.

(b) Determinar la ubicación de la propiedad y el propietario de la propiedad que alberga los objetivos.
(c) Buscar otros objetivos del mismo propietario.
(d) Encontrar y verificar las rutas de los servicios de telecomunicaciones que interactúan fuera del objetivo.
los caminos que siguen dentro y fuera del ámbito.
(e) Determinar la ubicación física de los objetivos.
(f) Pruebe qué protocolos se utilizan dentro del alcance (ejemplo: PSTN, ISDN, GSM, UMTS, SIP, H.323, RTP, XOT, DECNET, IPX,
etc.).
(g) Verificar y documentar las limitaciones especiales que impone el contrato con el cliente.

10.2.2 Calidad de la red

(a) Mida las velocidades de conexión máximas y mínimas admitidas por los objetivos.
(b) Determinar y verificar la velocidad de conexión, la paridad, el tiempo de anillo y otros parámetros de configuración específicos
adecuados que se utilizarán para el escaneo y las pruebas.
(c) Verificar y documentar las limitaciones particulares impuestas por el alcance (ejemplo: red X.25
congestión, rutas estrictas XOT, filtros de acceso basados en CLID).

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 153
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.2.3 Tiempo y costos adicionales

(a) Pruebe el marco de tiempo de funcionamiento del equipo (ejemplo: redirección de llamada al contestador automático fuera de servicio)
del horario laboral normal).
(b) Determinar y documentar la configuración horaria (zona horaria, horario de verano, etc.) para los objetivos.
(c) Asegúrese de que el reloj del analista esté sincronizado con la hora de los objetivos. Ciertos equipos, como los artefactos
frágiles, pueden tener configuraciones de hora que no representan una hora válida; si el reloj del analista se sincroniza con
estas, puede tener un impacto en el resultado de la prueba.
(d) Determinar los costos financieros adicionales que implica realizar pruebas exhaustivas desde una ubicación remota (por
ejemplo: escanear en busca de módems/FAX, probar servicios de acceso remoto que no sean en números gratuitos, realizar
llamadas X.25 sin cobro revertido).

10.3 Verificación de detección activa

La determinación de los controles activos para detectar intrusiones y filtrar o rechazar los intentos de prueba debe realizarse antes de la
prueba para mitigar el riesgo de corromper los datos de los resultados de la prueba, así como de cambiar el estado de alarma del personal o
los agentes de monitoreo. Puede ser necesario coordinar estas pruebas con el personal apropiado dentro del alcance.

10.3.1 Monitoreo

(a) Probar si las telecomunicaciones son monitoreadas por una parte autorizada para detectar la transmisión de datos de red
indebidos, inyecciones de código, contenido malicioso y conducta indebida, y registrar las respuestas y el tiempo de respuesta.

(b) Probar si existen controles para monitorear actividades fraudulentas o manipulación de servicios, y registrar las respuestas y
el tiempo de respuesta, como en la conciliación de facturación periódica, utilizando registros de detalles de llamadas (CDR).

10.3.2 Filtrado

(a) Probar si existen controles a nivel de red para bloquear actividades no autorizadas y registrar las respuestas y el tiempo de
respuesta, como los filtros de acceso basados en la identificación de línea de llamada (CLID), la dirección de usuario de red
(NUA) o el grupo cerrado de usuarios (CUG).
(b) Probar si existen controles a nivel de aplicación para bloquear actividades no autorizadas y
Registrar respuestas y tiempo de respuesta.

10.3.3 Detección activa

(a) Verificar las respuestas activas a las sondas de los sistemas y servicios.
(b) Verifique si existe protección contra ataques de fuerza bruta, como el bloqueo de cuentas.
(c) Asignar cualquier aplicación, sistema o segmento de red dentro del alcance que produzca registros,
alarmas o notificaciones.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
154 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.4 Auditoría de visibilidad

Enumeración e indexación de los objetivos en el alcance a través de la interacción directa e indirecta con o entre sistemas en vivo.

10.4.1 Topografía de redes

(a) Compilar un mapa de los protocolos de comunicación en uso dentro del ámbito. (b)
Describir la topología de las redes de telecomunicaciones dentro del ámbito.

10.4.2 Enumeración

(a) Pruebas de PBX: enumerar los sistemas de telefonía dentro del alcance. (b)
Pruebas de buzón de voz: encontrar buzones de voz dentro del alcance. (c) Pruebas
de FAX: enumerar los sistemas de FAX dentro del alcance. (d) Encuesta
de módem: encontrar todos los sistemas con módems de escucha e interactivos dentro del alcance. (e) Pruebas de
servicios de acceso remoto: enumerar los sistemas RAS dentro del alcance. (f) Pruebas de líneas
ISDN de respaldo: enumerar los dispositivos de red con líneas ISDN de respaldo dentro del alcance. (g) Pruebas de voz sobre
IP: enumerar los sistemas VoIP dentro del alcance. (h) Pruebas de red conmutada por
paquetes X.25: encontrar sistemas activos y accesibles dentro del alcance.
grabando sus códigos de respuesta.

10.4.3 Identificación

(a) Identifique los tipos y versiones de sistemas operativos en uso en los sistemas dentro
del alcance. (b) Identifique los tipos y versiones de servicios en uso en los sistemas dentro del
alcance. (c) Identifique los tipos de módem y FAX y los programas operativos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 155
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.5 Verificación de acceso

Pruebas para la medición de la amplitud y profundidad de los puntos de acceso interactivos dentro del alcance y la autenticación requerida.

10.5.1 Proceso de acceso

(a) Pruebas PBX: encontrar sistemas PBX que permitan la administración remota o el acceso mundial a la red.
terminal de mantenimiento, ya sea vía marcación telefónica o red IP.
(b) Prueba del buzón de voz: encontrar buzones de voz que sean accesibles desde todo el mundo.
(c) Pruebas de FAX: encontrar sistemas de FAX que permitan la administración remota o el acceso mundial al
terminal de mantenimiento.
(d) Estudio del módem: probar y documentar los protocolos de autenticación en uso (ejemplo: terminal,
PAP, CHAP, otros).
(e) Pruebas de servicios de acceso remoto: probar y documentar los protocolos de autenticación en uso (ejemplo: terminal, PAP,
CHAP, otros).
(f) Pruebas de líneas ISDN de respaldo: probar y documentar los protocolos de autenticación en uso (ejemplo: terminal, PAP, CHAP,
otros).
(g) Pruebas de voz sobre IP: verificar la posibilidad de realizar fraude telefónico, escuchas o rastreo de llamadas, secuestro de
llamadas, suplantación de CLID y denegación de servicio, mediante ataques dirigidos a redes convergentes, elementos de red
VoIP, protocolos de señalización y transporte de medios.
(h) Pruebas de redes conmutadas por paquetes X.25: encontrar sistemas que permitan la administración remota, el acceso a otros
servicios a través de CUD específicos o cobro revertido, verificar cuántos canales virtuales (VC) y canales virtuales permanentes
(PVC) están en uso y cómo se gestionan (CUG, mapeo de subdirecciones, filtrado de llamadas entrantes X.25, filtrado basado
en NUA, etc.).

10.5.2 Servicios

(a) Solicitar servicios remotos conocidos y comunes.

(b) Identificar los componentes de los servicios y sus versiones.
(c) Verificar el tiempo de actividad del servicio según las últimas vulnerabilidades y versiones de parches.
(d) Para cada servicio identificado, probar de forma remota y documentar los errores de configuración.
(e) Para cada aplicación identificada, probar de forma remota y documentar los errores de programación.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
156 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.5.3 Autenticación

(a) Enumerar los recursos de telecomunicaciones que requieren autenticación y verificar todos los recursos aceptables.
formas de privilegios para interactuar o recibir acceso.
(b) Documentar los esquemas de autenticación en uso, verificar el proceso para recibir la autenticación,
y comprobar si hay errores lógicos.
(c) Verificar los métodos de autorización y la identificación requerida.
(d) Asegúrese de que las cuentas administrativas no tengan credenciales predeterminadas o fáciles de adivinar.
(e) Asegúrese de que las cuentas de usuario no tengan credenciales predeterminadas o fáciles de adivinar.
(f) Verificar y probar las protecciones contra ataques de fuerza bruta y de tipo diccionario.
(g) Verificar y probar las comprobaciones de complejidad de contraseñas y el tamaño del PIN del buzón de voz, la antigüedad de las contraseñas y
Frecuencia de los controles de cambio.
(h) Pruebe las credenciales “conocidas” en todos los puntos de acceso enumerados para verificar los controles de reutilización de contraseñas.
(i) Verificar el formato utilizado para el almacenamiento de las credenciales de autenticación y el documento en texto claro o
contraseñas ofuscadas y algoritmos de cifrado débiles.
(j) Verificar el formato utilizado para la transmisión de credenciales de autenticación a través de la red y documentar contraseñas en texto
claro u ofuscadas y algoritmos de cifrado débiles.
(k) Verificar que la información de autenticación, ya sea intentada, exitosa o fallida, se registre adecuadamente.

10.6 Verificación de confianza

Pruebas de confianza entre sistemas dentro del alcance, donde la confianza se refiere al acceso a la información o propiedad física sin necesidad de
credenciales de autenticación.

10.6.1 Suplantación de identidad

(a) Probar y documentar los métodos de acceso en uso que no requieren la presentación de credenciales de autenticación.

(b) Probar y documentar la profundidad de los requisitos para la interacción con y el acceso a la propiedad dentro del alcance mediante la
suplantación de una fuente confiable (ejemplo: suplantación de CLID y X.25 NUA).

10.6.2 Abuso de recursos

(a) Probar y documentar la profundidad de los requisitos para llevar la propiedad fuera del alcance a una fuente conocida y confiable o a lo
largo del alcance mismo sin ninguna credencial establecida y requerida.

(b) Probar y documentar la propiedad disponible fuera del alcance debido a fugas de información.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 157
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.7 Verificación de controles

Pruebas para enumerar y verificar la funcionalidad operativa de las medidas de seguridad de los activos y servicios,
definidas mediante controles de pérdidas basados en procesos (Clase B). El control de alarmas se verifica al final de la
metodología.

10.7.1 No repudio

(a) Enumerar y probar el uso o las deficiencias de las aplicaciones y los sistemas para identificar y registrar adecuadamente
el acceso o las interacciones con la propiedad para obtener evidencia específica para impugnar el repudio.
(b) Documentar la profundidad de la interacción registrada y el proceso de identificación.
(c) Verificar que todos los métodos de interacción estén correctamente registrados con la identificación apropiada.
(d) Identificar métodos de identificación que derroten el repudio.

10.7.2 Confidencialidad

(a) Enumerar todas las interacciones con los servicios dentro del alcance de las comunicaciones o activos transportados a
través del canal utilizando líneas seguras, encriptación, interacciones “silenciadas” o “cerradas” para proteger la
confidencialidad de la propiedad de la información entre las partes involucradas.

(b) Verificar los métodos aceptables utilizados para la confidencialidad.

(c) Probar la solidez y el diseño de los métodos de cifrado u ofuscación.
(d) Verificar los límites externos de la comunicación que se pueden proteger mediante el método aplicado de
confidencialidad.

10.7.3 Privacidad

Enumere todas las interacciones con servicios dentro del alcance de las comunicaciones o activos transportados a través del
canal utilizando líneas seguras, cifrado, interacciones “silenciadas” o “cerradas” para proteger la privacidad de la interacción y
el proceso de proporcionar activos solo a aquellos dentro de la autorización de seguridad adecuada para ese proceso,
comunicación o activo.

10.7.4 Integridad

Enumerar y probar las deficiencias de integridad utilizando un proceso documentado, firmas, cifrado, hash o marcas para
garantizar que el activo no se pueda cambiar, intercambiar, redirigir o revertir sin que las partes involucradas lo sepan.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
158 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.8 Verificación del proceso

Pruebas para examinar el mantenimiento de la seguridad funcional y la eficacia en los procesos establecidos y la debida diligencia
según se define en la Revisión de Postura.

10.8.1 Línea base

Examinar y documentar los servicios de referencia para garantizar que los procesos estén en línea con la política de seguridad.

10.8.2 Mantenimiento

Examinar y documentar la puntualidad, idoneidad, acceso y alcance de los procesos para la notificación y concientización sobre
seguridad del personal con respecto a la seguridad operativa, la seguridad real y los controles de pérdidas.

10.8.3 Desinformación

Determinar hasta qué punto las notificaciones de seguridad del personal y las noticias de seguridad pueden ampliarse o
alterarse con información errónea.

10.8.4 Debida diligencia

Mapear y verificar cualquier brecha entre la práctica y los requisitos determinados en la Revisión de Postura a través de todos
los canales.

10.8.5 Indemnización

(a) Documentar y enumerar los objetivos y servicios que están protegidos contra el abuso o la elusión de la política de los
empleados, que están asegurados contra robo o daños, o que utilizan renuncias de responsabilidad y permisos.

(b) Verificar la legalidad y la idoneidad del lenguaje utilizado en las exenciones de responsabilidad.
(c) Verificar el efecto de las exenciones de responsabilidad sobre las medidas de seguridad o protección.
(d) Examine el lenguaje de la póliza de seguro para detectar limitaciones sobre los tipos de daños o activos.
(e) Compare la política de acceso cultural con la política de indemnización para encontrar evidencia de debilidades.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 159
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.9 Verificación de la configuración

Pruebas para recopilar toda la información, técnica y no técnica, sobre cómo se supone que deben funcionar los activos y para examinar la
capacidad de eludir o interrumpir la seguridad funcional de los activos, explotando una configuración incorrecta de los controles de acceso,
controles de pérdida y aplicaciones.

10.9.1 Controles de configuración

(a) Examinar los controles, incluida la configuración de referencia, para validar las configuraciones adecuadas de
equipos, sistemas y aplicaciones dentro del alcance.
(b) Examinar los controles para garantizar que las configuraciones de equipos, sistemas y aplicaciones coincidan con la intención de
la organización y reflejen una justificación comercial.
(c) Examinar las listas de control de acceso (ACL) configuradas en redes, sistemas, servicios y aplicaciones dentro del alcance, para
garantizar que coincidan con la intención de la organización y reflejen una justificación comercial.

10.9.2 Errores de configuración comunes

(a) Pruebas de PBX: verificar si hay servicios/funciones innecesarios, inseguros o no utilizados y credenciales predeterminadas,
verificar el nivel de parches de los sistemas PBX para identificar vulnerabilidades conocidas.
(b) Prueba del buzón de voz: verificar si hay servicios o funciones innecesarios, inseguros o no utilizados y credenciales
predeterminadas, verificar el nivel de parche de los sistemas de buzón de voz para identificar vulnerabilidades conocidas.

(c) Pruebas de FAX: verificar si hay servicios o funciones innecesarios, inseguros o no utilizados y credenciales predeterminadas,
verificar el nivel de parches de los sistemas de FAX para identificar vulnerabilidades conocidas.
(d) Inspección del módem: verificar si hay módems de respuesta innecesarios o no utilizados dentro del alcance.
(e) Pruebas de servicios de acceso remoto: verificar si hay servicios o funciones innecesarios, inseguros o no utilizados y credenciales
predeterminadas, verificar el nivel de parche de los servidores RAS para identificar vulnerabilidades conocidas.
(f) Pruebas de líneas ISDN de respaldo: verificar servicios innecesarios, inseguros o no utilizados y credenciales predeterminadas,
verificar el nivel de parches de los equipos de red para identificar vulnerabilidades conocidas.
(g) Pruebas de voz sobre IP: verificar si hay servicios/protocolos innecesarios, inseguros o no utilizados y credenciales predeterminadas
en todos los sistemas dentro de la infraestructura de VoIP, y verificar su nivel de parche para identificar vulnerabilidades conocidas.

(h) En las pruebas de red conmutada por paquetes X.25, comprobar si hay servicios innecesarios, inseguros o no utilizados y
credenciales predeterminadas en todos los sistemas X.25, y verificar su nivel de parche para identificar vulnerabilidades conocidas.

10.9.3 Auditoría de código fuente

Examinar el código fuente disponible de las aplicaciones cuando estén disponibles para validar las operaciones de equilibrio de
controles.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
160 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.10 Validación de la propiedad

Pruebas para examinar la información y la propiedad física disponibles dentro del alcance o proporcionadas por el personal que puedan ser ilegales
o poco éticas.

10.10.1Compartir

Verificar hasta qué punto la propiedad con licencia individual, privada, falsificada, reproducida, no libre o no abierta se comparte entre el
personal, ya sea intencionalmente a través del intercambio de procesos y programas, bibliotecas y cachés personales, o involuntariamente
a través de la mala administración de licencias y recursos, o negligencia.

10.10.2Mercado negro

Verificar en qué medida se promueve, comercializa o vende propiedad con licencia individual, privada, falsificada, reproducida, no libre o
no abierta, entre el personal o por parte de la organización.

10.10.3 Canales de venta

Verificar negocios públicos, fuera del alcance, subastas o ventas de propiedades que brinden información de contacto a través de canales
que se originan dentro del alcance.

10.10.4 Módems no autorizados

Realizar un inventario completo de todos los módems dentro del alcance. Verificar que la organización haya adoptado una política de
seguridad adecuada que aborde el uso y la provisión de módems.

10.11 Revisión de la segregación

Pruebas para la separación adecuada de la información privada o personal de la información comercial. Al igual que una revisión de privacidad, es el
punto focal del almacenamiento, transmisión y control legal y ético de la información privada del personal, socios y clientes.

10.11.1 Mapeo de contención de privacidad

Mapee a los guardianes de la información privada dentro del alcance, qué información se almacena, cómo y dónde se almacena la
información y a través de qué canales se comunica la información.

10.11.2Divulgación

Examinar y documentar los tipos de divulgaciones de información privada en los servicios de comunicación de los guardianes responsables
de esta segregación de acuerdo con la política y las regulaciones determinadas en la Revisión de la Postura y el derecho humano básico
a.

10.11.3 Limitaciones

Examinar y documentar los tipos de puertas de enlace y alternativas de canales con puertas de enlace accesibles para personas con
limitaciones físicas dentro de ese canal, como en el servicio TTY.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 161
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.12 Verificación de la exposición

Pruebas para descubrir información pública que describa la visibilidad indirecta de los objetivos dentro del alcance o que permita o conduzca al acceso
autenticado.

10.12.1 Mapeo de exposición

(a) Identificar información personal y comercial, como números de teléfono personales y de trabajo, números de teléfono móvil,
números de teléfono gratuitos, números de FAX, propietarios de líneas de telecomunicaciones, operadores y afiliaciones
organizacionales, utilizando todos los medios disponibles, como sitios web de empresas, guías telefónicas, información de
directorio en línea y bases de datos de suscriptores de telecomunicaciones.

(b) Identifique otras líneas de telecomunicaciones como X.25, utilizando los sitios web de ambas empresas y la búsqueda
motores.
(c) Identificar información personal y comercial, como organigramas, títulos de personal clave, descripciones de trabajo,
direcciones de correo electrónico privadas y públicas, inicios de sesión (ejemplo: fuga de información de correo X.25
PSI), esquemas de inicio de sesión, contraseñas, métodos de respaldo, aseguradoras o cualquier información
organizacional particular declarada implícitamente como confidencial en regulaciones y políticas.

10.12.2 Elaboración de perfiles

Perfilar y verificar la organización, sus redes públicas de telecomunicaciones, empleados, tecnologías y dirección del
negocio.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
162 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.13 Inteligencia Competitiva

Pruebas para recopilar información que pueda analizarse como inteligencia empresarial. Si bien la inteligencia competitiva como campo está
relacionada con el marketing, el proceso aquí incluye cualquier forma de recopilación de inteligencia competitiva, incluido, entre otros, el
espionaje económico e industrial.

10.13.1 Rectificado comercial

(a) Describir los guardianes de la propiedad comercial dentro del alcance, qué información se almacena, cómo y dónde se
almacena y a través de qué canales se comunica la información.
(b) Medir el costo de la infraestructura de telecomunicaciones en función del equipo (ejemplo:
teléfonos, PBX, módems, FAX, etc.).
(c) Medir el costo de la infraestructura de soporte, con base en los costos de transporte y mantenimiento, incluyendo el personal
técnico.
(d) Verificar qué tipo de negocio se gestiona a través de la infraestructura de telecomunicaciones
(ejemplo: call center, atención al cliente, help desk, etc.).
(e) Verificar la cantidad de tráfico en un rango de tiempo definido.

10.13.2 Entorno empresarial

(a) Explorar y documentar detalles comerciales tales como alianzas, socios, clientes principales, proveedores, distribuidores,
inversionistas, relaciones comerciales, producción, desarrollo, información de productos, planificación, existencias y comercio,
y cualquier información o propiedad comercial particular declarada implícitamente como confidencial en regulaciones y
políticas.
(b) Identificar las líneas de telecomunicaciones que forman parte del negocio de los socios.

10.13.3 Entorno organizacional

Examinar y documentar los tipos de divulgaciones de propiedad comercial de los guardianes sobre operaciones, procesos,
jerarquía, informes financieros, oportunidades de inversión, fusiones, adquisiciones, inversiones de canal, mantenimiento de canal,
política social interna, insatisfacción del personal y tasa de rotación, tiempos de vacaciones principales, contrataciones, despidos y
cualquier propiedad organizacional particular indicada implícitamente como confidencial en regulaciones y políticas.

10.14 Verificación de cuarentena

Pruebas para verificar la correcta recepción y contención de contactos agresivos u hostiles en los puntos de entrada.

10.14.1 Identificación del proceso de contención

Identificar y examinar los métodos y procesos de cuarentena en el objetivo en todos los canales para detectar contactos molestos,
agresivos u hostiles, como teleoperadores, cazatalentos y acosadores.

10.14.2 Niveles de contención

Verificar el estado de contención, el tiempo de duración y todos los canales en los que se realizan interacciones con métodos de
cuarentena. Asegurarse de que los métodos se encuentren dentro del contexto y los límites legales.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 163
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.15 Auditoría de privilegios

Pruebas en las que se proporcionan credenciales al usuario y se le concede permiso para realizar pruebas con esas credenciales.

10.15.1 Identificación

Examinar y documentar el proceso de obtención de identificación a través de medios legítimos y fraudulentos en todos los canales.

10.15.2Autorización

(a) Verificar el uso de autorización fraudulenta en todos los canales para obtener privilegios similares a los de
Otro personal.
(b) Probar y documentar posibles rutas para eludir las listas de control de acceso (ACL) configuradas para redes, sistemas, servicios
y aplicaciones dentro del alcance.

10.15.3 Escalada

Verificar y mapear el acceso a la información mediante el uso de privilegios para obtener mayores privilegios.

10.15.4 Subyugación

Enumerar y probar las deficiencias de todos los canales para utilizar o habilitar controles de pérdida que no están habilitados de forma
predeterminada.

10.16 Validación de la capacidad de supervivencia

Determinar y medir la resiliencia del objetivo dentro del alcance ante cambios excesivos u hostiles diseñados para
provocar fallas en el servicio.

10.16.1 Continuidad

(a) Enumerar y probar las deficiencias del objetivo con respecto a los retrasos en el acceso y el tiempo de respuesta del servicio a
través de personal de respaldo o medios automatizados para acceso alternativo.
(b) Enumerar y comprobar las deficiencias del objetivo en lo que respecta a cuestiones de calidad del servicio y
Requisitos de rendimiento de las tecnologías de telecomunicaciones.

10.16.2 Resiliencia

Mapear y documentar el proceso por el cual los guardianes desconectan canales debido a violaciones o problemas de seguridad
como un análisis de brechas con la regulación y la política de seguridad.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
164 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

10.17 Revisión de alertas y registros

Un análisis de la brecha entre las actividades realizadas con la prueba y la profundidad real de esas actividades tal como se registraron
o según las percepciones de terceros, tanto humanos como mecánicos.

10.17.1 Alarma

(a) Verificar y enumerar el uso de un sistema de advertencia, registro o mensaje localizado o de alcance amplio para cada puerta de acceso
sobre cada canal donde se eleva una situación sospechosa ante la sospecha de intentos de intrusión o actividad fraudulenta y determinar
los niveles de recorte.
(b) Revisar los registros detallados de llamadas entrantes y salientes para detectar señales de abuso o fraude.
(c) Sistemas de gestión de registros de pruebas y documentos.

10.17.2 Almacenamiento y recuperación

(a) Documentar y verificar el acceso sin privilegios a las ubicaciones de almacenamiento de alarmas, registros y notificaciones.
y propiedad.
(b) Probar y documentar la política de respaldo de registros y el registro en múltiples ubicaciones, para garantizar que
Los registros de auditoría no pueden ser alterados.
(c) Sistemas de gestión de registros de pruebas y documentos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 165
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Las 3 reglas de las herramientas de seguridad de datos

son: 1. las herramientas no saben cuándo mienten, 2. las
herramientas son tan inteligentes como sus diseñadores
y 3. las herramientas solo pueden funcionar correctamente
dentro de los límites del entorno para el que fueron
creadas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
166 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 11 ­ Pruebas de seguridad de redes de datos

Las pruebas para el canal de Seguridad de Redes de Datos (COMSEC) requieren interacciones con las medidas de seguridad operativas de la
red de comunicación de datos existente que se utilizan para controlar el acceso a la propiedad.

Este canal cubre la participación de los sistemas informáticos, principalmente las redes operativas dentro del ámbito o marco de trabajo objetivo.
Si bien algunas organizaciones consideran esto simplemente como "pruebas de penetración", el verdadero objetivo de cumplimiento de las
pruebas de seguridad en este canal es la interacción del sistema y las pruebas de calidad operativa con mediciones de brechas con el estándar
de seguridad requerido delineado en la política de la empresa, las regulaciones de la industria o la legislación regional.

Durante las pruebas, los operadores finales y la inteligencia artificial pueden reconocer los ataques en curso tanto por el proceso como por la
firma. Por este motivo, el analista deberá contar con una variedad suficiente de métodos para evitar la divulgación de las pruebas o trabajar con
los operadores para garantizar que se revele dónde falla la seguridad y dónde tiene éxito. Las pruebas que se centran únicamente en el
descubrimiento de nuevos problemas solo dejan espacio para correcciones y no para diseños de mejoras futuras.

Los analistas competentes requerirán conocimientos adecuados de redes, habilidades diligentes de pruebas de seguridad y habilidades de
pensamiento crítico para garantizar que la recopilación de datos factuales cree resultados factuales a través de la correlación y el análisis.

Consideraciones
Tenga en cuenta las siguientes consideraciones para garantizar una prueba segura y de alta calidad:

1. Ignorantia legis neminem excusat: Los analistas que no realizan una revisión adecuada de la postura en relación con el alcance y las
regiones a las que se dirigen los negocios o las interacciones no pueden escapar del castigo por violar las leyes simplemente porque
desconocían la ley; es decir, las personas tienen un presunto conocimiento de la ley. Los analistas son considerados profesionales en
esta materia y, por lo tanto, se presupone que lo que puede no ser de conocimiento común para una persona normal sobre las leyes
de una región extranjera en materia de sistemas informáticos, los profesionales se informan por sí mismos de las leyes necesarias para
emprender esa tarea.

2. Derechos de propiedad: Las pruebas deben estar dirigidas específicamente solo a sistemas que sean propiedad legal directa del
propietario del ámbito de aplicación y a sistemas informáticos que sean propiedad del propietario del ámbito de aplicación. Cualquier
efecto personal debe seguir siendo personal y privado a menos que involucre específicamente al propietario del ámbito de aplicación
mediante menosprecio, imagen engañosa, competitividad o razones establecidas en los acuerdos contractuales del personal.
Los analistas deben esforzarse por no invadir la vida privada de una persona cuando esa vida privada haya intentado separarse del
ámbito de aplicación. Los analistas con acuerdos especiales para probar sistemas que están bajo contrato directo pero que no son de
su propiedad o que son de su propiedad pero no están alojados en la propiedad legal del propietario deben tener mucho cuidado para
garantizar que las pruebas tengan el mínimo impacto en otros sistemas y terceros fuera del ámbito de aplicación o del contrato.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 167
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.1 Revisión de la postura

Los estudios iniciales de la postura incluyen las leyes, la ética, las políticas, las regulaciones de la industria y la cultura
política que influyen en los requisitos de seguridad y privacidad para el ámbito. Esta revisión forma una matriz con la que
se deben trazar las pruebas, pero no se deben limitar debido a la ubicuidad de los puntos finales del canal.
Por tanto, es importante considerar, tal y como exigen algunas legislaciones, el mercado objetivo o usuarios finales de ese
canal que también deben añadirse al alcance de este módulo.

11.1.1 Política
Revisar y documentar la política organizacional adecuada en relación con los requisitos de seguridad, integridad y
privacidad del ámbito de aplicación. Revisar y documentar los contratos y los acuerdos de nivel de servicio (SLA)
con los proveedores de servicios y otros terceros involucrados.

11.1.2 Legislación y reglamentación

Revisar y documentar la legislación regional y nacional apropiada, y las regulaciones de la industria con respecto
a los requisitos de seguridad y privacidad de la organización dentro del alcance, así como aquellos que incluyen a
los clientes, socios, sucursales organizacionales o revendedores apropiados fuera del alcance.

11.1.3 Cultura

Revisar y documentar la cultura organizacional apropiada en el ámbito de la concientización sobre seguridad y

privacidad, la capacitación de personal requerida y disponible, la jerarquía organizacional, el uso de la mesa de
ayuda y los requisitos para informar problemas de seguridad.

11.1.4 Edad
Revisar y documentar la antigüedad de los sistemas, software y aplicaciones de servicio necesarios para las
operaciones.

11.1.5 Artefactos frágiles

Revisar y documentar cualquier sistema, software y aplicación de servicio que requiera cuidado especial debido al
alto uso, inestabilidad o una alta tasa de cambio.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
168 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.2 Logística
Esta es la preparación del entorno de prueba del canal necesaria para evitar falsos positivos y falsos negativos que conducen a resultados de
prueba inexactos.

11.2.1 Marco

(a) Verificar el alcance y el propietario de los objetivos planteados para la auditoría.

(b) Determinar la ubicación de la propiedad y el propietario de la propiedad que alberga los objetivos.
(c) Verificar el propietario de los objetivos a partir de la información de registro de la red.
(d) Verificar el propietario de los dominios de destino a partir de la información de registro del dominio. (e)
Verificar los ISP que proporcionan acceso a la red o redundancia.
(f) Buscar otros bloques de IP y objetivos relacionados con el mismo propietario(s).
(g) Busque nombres de dominio similares o nombres de dominio mal escritos que puedan confundirse con el
objetivo.
(h) Verificar qué nombres de dominio de destino se resuelven en sistemas fuera del control del propietario, como
dispositivos de almacenamiento en caché.

(i) Verifique qué direcciones IP de destino se rastrean a ubicaciones diferentes de la ubicación del propietario.
(j) Verificar que las búsquedas inversas de nombres de direcciones del sistema de destino correspondan con el alcance y
El propietario del alcance.
(k) Encontrar y verificar las rutas de los servicios de red que interactúan fuera del objetivo para las rutas que siguen.
seguir dentro y fuera del ámbito.
(l) Preparar la resolución de nombres locales para asignar nombres de dominio solo a los sistemas específicos que se van a probar
y no a ningún dispositivo fuera del objetivo o de la propiedad del objetivo.
(m)Utilice búsquedas de nombres inversas como fuente de información adicional para determinar la existencia de todas las máquinas
en una red.

11.2.2 Calidad de la red

(a) Mida la velocidad y la pérdida de paquetes en el ámbito de un servicio solicitado en TCP, UDP e ICMP, tanto como una solicitud
de servicio completo como como un par solicitud/respuesta. Repita cada solicitud en sucesión al menos 100 veces y registre el
promedio tanto de las solicitudes de servicio completo como de las respuestas de paquetes para cada uno de los tres protocolos.

(b) Determine las tasas de envío y recepción de paquetes para un total de 6 promedios (por protocolo) como
solicitudes por segundo por segmento de red en el alcance. (c) Registre
los porcentajes de pérdida de paquetes para las tasas de envío y recepción de paquetes determinadas.

11.2.3 Tiempo

(a) Verificar la zona horaria, los días festivos y los horarios de trabajo de los distintos sistemas dentro del alcance, incluidos socios,
revendedores y clientes influyentes que interactúan con el alcance.
(b) Identifique la distancia de tiempo de vida (TTL) hasta la puerta de enlace y los objetivos.
(c) Asegurarse de que el reloj del analista esté sincronizado con la hora de los objetivos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 169
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.3 Verificación de detección activa

La determinación de los controles activos y pasivos para detectar intrusiones, filtrar o rechazar intentos de prueba debe realizarse
antes de la prueba para mitigar el riesgo de corromper los datos de los resultados de la prueba, así como de cambiar el estado de
alarma del personal o los agentes de monitoreo. Puede ser necesario coordinar estas pruebas con las personas adecuadas dentro
del alcance.

11.3.1 Filtrado

(a) Probar si los datos de red ENTRANTES o las comunicaciones a través de la web, mensajería instantánea, chat, foros
basados en la web o correo electrónico son monitoreados o filtrados por una parte autorizada para la retransmisión
de materiales indebidos, inyecciones de código, contenido malicioso y conducta indebida y registrar las respuestas y
el tiempo de respuesta.
(b) Probar si los datos de red SALIENTES o las comunicaciones a través de la web, mensajería instantánea, chat, foros
basados en la web o correo electrónico son monitoreados o filtrados por una parte autorizada para la retransmisión
de materiales indebidos, inyecciones de código, contenido malicioso y conducta indebida y registrar las respuestas y
el tiempo de respuesta.

11.3.2 Detección activa

(a) Verificar las respuestas activas a las sondas de los sistemas y servicios. Pueden ser notificaciones legibles por
humanos o máquinas, respuestas de paquetes, disparos de alarmas silenciosas o similares.
(b) Asignar cualquier aplicación, sistema o segmento de red dentro del alcance que produzca registros, alarmas o notificaciones.
Esto podría incluir sistemas de prevención o detección de intrusiones basados en red o host, syslog, herramientas de gestión
de información de seguridad (SIM), registros de aplicaciones y similares.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
170 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.4 Auditoría de visibilidad

Enumeración e indexación de los objetivos en el alcance a través de la interacción directa e indirecta con o entre sistemas en vivo.

11.4.1 Topografía de red

(a) Identifique el perímetro del segmento o segmentos de la red objetivo y el vector desde el cual se ubicarán.
Probado.
(b) Utilizar el rastreo de red para identificar los protocolos que emanan de las respuestas o solicitudes de servicios de red, cuando
corresponda. Por ejemplo, Netbios, ARP, SAP, NFS, BGP, OSPF, MPLS, RIPv2, etc.
(c) Consultar todos los servidores de nombres y los servidores de nombres del ISP o proveedor de alojamiento, si están disponibles, para
obtener los registros A, AAAA y PTR correspondientes, así como la capacidad de realizar transferencias de zona para determinar la
existencia de todos los objetivos en la red y cualquier redundancia relacionada, equilibrio de carga, almacenamiento en caché, proxy
y alojamiento virtual.
(d) Verificar las solicitudes de transmisión y las respuestas de todos los objetivos.
(e) Verificar y examinar el uso de protocolos de tráfico y enrutamiento para todos los objetivos.
(f) Verifique las respuestas ICMP para los tipos ICMP 0 a 255 y los códigos ICMP 0 a 2 de todos los destinos.
(g) Verificar que los nombres de comunidad SNMP predeterminados y probables en uso sean acordes a la práctica.
Implementaciones de todas las versiones de SNMP.
(h) Verificar las respuestas de los destinos para seleccionar puertos con vencimiento de TTL establecido en menos de 1 y 2 saltos desde
los destinos. Por ejemplo:
TCP 8, 22, 23, 25, 80, 443, 445, 1433
UDP 0, 53, 139, 161
ICMP T00:C00, T13:C00, T15:C00, T17:C00
(i) Rastrear la ruta de los paquetes ICMP a todos los destinos.
(j) Rastrear la ruta de los paquetes TCP a todos los destinos para los puertos SSH, SMTP, HTTP y HTTPS.
(k) Rastrear la ruta de los paquetes UDP a todos los destinos para los puertos DNS y SNMP.
(l) Identificar la predictibilidad del número de secuencia ISN de TCP para todos los objetivos.
(m)Verificar los incrementos de IPID a partir de las respuestas para todos los objetivos.
(n) Verificar el uso del enrutamiento de origen suelto hacia la puerta de enlace de destino y los sistemas del perímetro externo para enrutar
paquetes a todos los destinos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 171
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.4.2 Enumeración
(a) Busque en grupos de noticias, foros, IRC, mensajería instantánea, P2P, VoIP y comunicaciones basadas en la web información de
conexión del objetivo para determinar los sistemas de puerta de enlace salientes y el direccionamiento interno.

(b) Examinar encabezados de correo electrónico, correos rebotados, confirmaciones de lectura, errores de correo y rechazos de malware.
para determinar los sistemas de puerta de enlace saliente y el direccionamiento interno.
(c) Examinar el código fuente y los scripts de la aplicación web de destino para determinar la existencia de
objetivos adicionales en la red.
(d) Examinar las emanaciones de servicios y aplicaciones. Manipular y reproducir el tráfico capturado para invocar nuevas solicitudes o
respuestas, obtener más información o exponer información adicional. Por ejemplo, SQL, Citrix, HTTP, SAP, DNS, ARP, etc.

(e) Busque en los registros web y en los registros de intrusiones rastros del sistema de la red de destino. (f)
Verifique todas las respuestas de las solicitudes de paquetes UDP a los puertos 0­65535.
(g) Verificar las respuestas a las solicitudes de paquetes UDP DESDE los puertos FUENTE 0, 53, 139 y 161 a 0, 53, 69,
131 y 161.
(h) Verifique las respuestas a las solicitudes de paquetes UDP con SUMAS DE VERIFICACIÓN INCORRECTAS para todos los puertos
descubiertos y para 0, 53, 69, 131 y 161.
(i) Verificar las respuestas a las solicitudes de servicio ante malware de acceso remoto UDP común y contemporáneo
puertos.
(j) Verificar las respuestas de las solicitudes de paquetes TCP SYN a los puertos 0­65535.
(k) Verificar las respuestas de las solicitudes de servicio TCP a los puertos 0, 21, 22, 23, 25, 53, 80 y 443.
(l) Verificar las respuestas de un TCP ACK con un puerto SOURCE de 80 a los puertos 3100­3150, 10001­10050,
33500­33550 y 50 puertos aleatorios por encima de 35000.
(m)Verificar las respuestas de los fragmentos TCP SYN a los puertos 0, 21, 22, 23, 25, 53, 80 y 443.
(n) Verificar las respuestas de todas las combinaciones de indicadores TCP a los puertos 0, 21, 22, 23, 25, 53, 80 y 443.
(o) Verificar el uso de todos los objetivos con VPN, servidores proxy y redireccionadores de URL basados en HTTP o HTTPS para redirigir
solicitudes a objetivos dentro del alcance.
(p) Verificar el uso de todos los objetivos con IPID secuenciales para enumerar sistemas dentro de la red.
(q) Mapear y verificar la consistencia de los sistemas visibles y los puertos que responden por TTL.

11.4.3 Identificación
Identifique la respuesta TTL de los objetivos, el tiempo de actividad del sistema, los servicios, las aplicaciones y las fallas de las
aplicaciones, y correlacione esto con las respuestas de las herramientas de identificación de sistemas y servicios.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
172 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.5 Verificación de acceso

Pruebas para la enumeración de puntos de acceso que conducen dentro del alcance.

11.5.1 Red

(a) Solicitar servicios comunes conocidos que utilicen UDP para conexiones desde todas las direcciones.
(b) Solicitar servicios VPN conocidos y comunes, incluidos aquellos que utilizan IPSEC e IKE para
Conexiones desde todas las direcciones.
(c) Manipular el servicio de red y el enrutamiento para acceder a restricciones pasadas dentro del alcance.
(d) Solicitar servicios troyanos conocidos y comunes que utilicen UDP para conexiones desde todas las direcciones.
(e) Solicitar servicios troyanos conocidos y comunes que utilicen ICMP para conexiones desde todas las direcciones.
(f) Solicitar servicios troyanos conocidos y comunes que utilizan TCP para conexiones desde todas las direcciones
y puertos sin filtrar que no han enviado respuesta a un TCP SYN.

11.5.2 Servicios

(a) Solicitar todos los banners de servicio (banderas) para los puertos TCP descubiertos.
(b) Verificar los banners (banderas) de servicio a través de interacciones con el servicio que comprenden tanto los válidos como los
solicitudes no válidas
(c) Haga coincidir cada puerto abierto con un demonio (servicio), una aplicación (código o producto específico que utiliza el servicio) y un
protocolo (el medio para interactuar con ese servicio o aplicación).
(d) Verificar el tiempo de actividad del sistema en comparación con las últimas vulnerabilidades y versiones de parches.
(e) Verificar la aplicación al sistema y la versión.
(f) Identifique los componentes del servicio de escucha.
(g) Verificar el tiempo de actividad del servicio en comparación con las últimas vulnerabilidades y versiones de parches.
(h) Verificar el servicio y la aplicación frente a los resultados de huellas dactilares TTL y del sistema operativo para todas las direcciones.
(i) Verificar HTTP y HTTPS para el alojamiento virtual.
(j) Verificar los servicios de VoIP.
(k) Manipular solicitudes de aplicaciones y servicios fuera de los límites estándar para incluir caracteres especiales o terminología especial
de ese servicio o aplicación para obtener acceso.

11.5.3 Autenticación

(a) Enumere los accesos que requieren autenticación y documente todos los privilegios descubiertos.
se puede utilizar para proporcionar acceso.
(b) Verificar el método de obtención de la Autorización adecuada para la autenticación.
(c) Verificar el método de estar debidamente Identificado para que se le proporcione la autenticación.
(d) Verificar el método lógico de autenticación.
(e) Verificar la solidez de la autenticación mediante el descifrado de contraseñas y su nueva aplicación.
descubrió contraseñas para todos los puntos de acceso que requieren autenticación.
(f) Verificar el proceso para recibir la autenticación.
(g) Probar errores lógicos en la aplicación de la autenticación.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 173
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.6 Verificación de confianza

Pruebas de confianza entre sistemas dentro del ámbito donde la confianza se refiere al acceso a información o propiedad física sin necesidad
de identificación o autenticación.

11.6.1 Suplantación de identidad

(a) Pruebe las medidas para acceder a la propiedad dentro del alcance falsificando su dirección de red como una de
Los anfitriones de confianza.

(b) Verifique si los mecanismos de almacenamiento en caché disponibles pueden ser envenenados.

11.6.2 Suplantación de identidad (phishing)

(a) Verificar que las URL para envíos y consultas sobre el objetivo sean concisas y dentro del mismo dominio.
Utilice únicamente el método POST y utilice una marca coherente.
(b) Verificar que las imágenes/registros/datos del contenido de destino no existan en sitios fuera del destino.
crear un duplicado del objetivo.
(c) Examinar los registros de dominio de nivel superior en busca de dominios similares a los identificados dentro del alcance.
(d) Verificar que el objetivo utilice personalización en sitios web y correo cuando interactúa con usuarios autenticados.

(e) Verificar el control y la respuesta del destino a los rebotes de correo donde el FROM está falsificado.
El campo de encabezado debe ser el del dominio de destino.

11.6.3 Abuso de recursos

(a) Probar la profundidad del acceso a la información comercial o confidencial disponible en servidores web sin ninguna credencial
requerida establecida.
(b) Pruebe si la información se envía al exterior del ámbito como relleno para los paquetes de red, como
lo que ocurrió anteriormente como “Etherleak”.
(c) Verificar que las medidas de continuidad, específicamente el equilibrio de carga, sean perfectas fuera del alcance para evitar que
los usuarios utilicen, hagan referencia, vinculen, marquen como favoritos o abusen de solo uno de los recursos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
174 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.7 Verificación de controles

Pruebas para enumerar y verificar la funcionalidad operativa de las medidas de seguridad de activos y servicios.

11.7.1 No repudio (a)

Enumerar y probar el uso o las deficiencias de los daemons y sistemas para identificar y registrar adecuadamente
el acceso o las interacciones con la propiedad para obtener evidencia específica para desafiar el repudio.
(b) Documentar la profundidad de la interacción registrada y el proceso de identificación.
(c) Verificar que todos los métodos de interacción se registren correctamente con la identificación apropiada.
(d) Identificar métodos de identificación que derroten el repudio.

11.7.2 Confidencialidad

(a) Enumerar todas las interacciones con los servicios dentro del alcance de las comunicaciones o activos transportados a
través del canal utilizando líneas seguras, encriptación, interacciones “silenciadas” o “cerradas” para proteger la
confidencialidad de la propiedad de la información entre las partes involucradas.

(b) Verificar los métodos aceptables utilizados para la confidencialidad.

(c) Probar la solidez y el diseño del método de cifrado u ofuscación.
(d) Verificar los límites externos de la comunicación que pueden protegerse mediante los métodos aplicados de
confidencialidad.

11.7.3 Privacidad

(a) Enumerar los servicios dentro del alcance de las comunicaciones o activos transportados utilizando firmas individuales
específicas, identificación personal, interacciones personales “silenciosas” o “en sala cerrada” para proteger la privacidad
de la interacción y el proceso de proporcionar activos solo a aquellos dentro de la autorización de seguridad adecuada
para ese proceso, comunicación o activo.
(b) Correlacionar la información con los puertos TCP y UDP que no responden para determinar si hay disponibilidad.
depende de un tipo de contacto o protocolo privado.

11.7.4 Integridad

Enumerar y probar las deficiencias de integridad utilizando un proceso documentado, firmas, cifrado, hash o marcas para
garantizar que el activo no se pueda cambiar, redirigir o revertir sin que las partes involucradas lo sepan.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 175
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.8 Verificación del proceso

Pruebas para examinar el mantenimiento de la seguridad funcional en los procesos establecidos y la debida diligencia según se define en la
Revisión de Postura.

11.8.1 Mantenimiento

(a) Examinar y documentar la puntualidad, idoneidad, acceso y alcance de los procesos de notificación y respuesta de seguridad en
relación con el monitoreo de la red y la seguridad.
(b) Verificar la idoneidad y funcionalidad de las capacidades forenses y de respuesta a incidentes para
Todo tipo de sistemas.
(c) Verificar el nivel de incidente o compromiso que los canales de soporte pueden detectar y la
duración del tiempo de respuesta.

11.8.2 Desinformación

Determinar hasta qué punto las notificaciones y alarmas de seguridad pueden ampliarse o alterarse con información errónea.

11.8.3 Debida diligencia

Mapear y verificar cualquier brecha entre la práctica y los requisitos determinados en la Revisión de Postura a través de todos los
canales.

11.8.4 Indemnización
(a) Documentar y enumerar los objetivos y servicios que están protegidos contra el abuso o la elusión de la política de los empleados,
que están asegurados contra robo o daños, o que utilizan renuncias de responsabilidad y permisos.

(b) Verificar la legalidad y la idoneidad del lenguaje utilizado en las exenciones de responsabilidad.
(c) Verificar el efecto de las exenciones de responsabilidad sobre las medidas de seguridad o protección.
(d) Examine el lenguaje de la póliza de seguro para detectar limitaciones sobre los tipos de daños o activos.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
176 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.9 Verificación de la configuración

Pruebas para recopilar toda la información, técnica y no técnica, sobre cómo se supone que deben funcionar los activos y para examinar la capacidad
de eludir o interrumpir la seguridad funcional de los activos, explotando una configuración incorrecta de los controles de acceso, controles de pérdida
y aplicaciones.

11.9.1 Controles de configuración

(a) Examinar los controles para verificar que las configuraciones y líneas de base de los sistemas, equipos y aplicaciones cumplan con la
intención de la organización y reflejen una justificación comercial.
(b) Examinar las listas de control de acceso (ACL) y los roles comerciales configurados en redes, sistemas, servicios y aplicaciones dentro
del alcance para garantizar que cumplan con la intención de la organización y reflejen una justificación comercial.

11.9.2 Errores de configuración comunes

(a) Verificar que los servicios disponibles no sean innecesariamente redundantes y que coincidan con los sistemas
Función empresarial prevista.
(b) Verifique que se hayan cambiado las configuraciones predeterminadas. Algunos dispositivos o aplicaciones se entregan con una cuenta
administrativa predeterminada u oculta. Estas cuentas se deben cambiar o, si es posible, deshabilitar o eliminar y reemplazar por una
nueva cuenta administrativa.
(c) Verificar que la Administración se realice localmente o con controles para limitar quién o qué puede acceder a la
Interfaces de administración remota del equipo.

11.9.3 Mapeo de limitaciones

(a) Verifique si hay servicios o funciones innecesarios o no utilizados disponibles.

(b) Verifique las credenciales predeterminadas.
(c) Identificar si existen vulnerabilidades conocidas en los sistemas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 177
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.10 Validación de la propiedad

Pruebas para examinar información y datos disponibles dentro del alcance o proporcionados por el personal que puedan ser ilegales o poco
éticos.

11.10.1Compartir

Verificar hasta qué punto se comparte propiedad con licencia individual, privada, falsificada, reproducida, no libre o no abierta, ya sea
intencionalmente a través de procesos y programas compartidos, bibliotecas y cachés personales, o involuntariamente a través de
una mala administración de licencias y recursos, o negligencia.

11.10.2Mercado negro

Verificar en qué medida se promueve, comercializa o vende propiedad con licencia individual, privada, falsificada, reproducida, no
libre o no abierta, entre el personal o por parte de la organización.

11.10.3 Canales de venta

Verificar si algún negocio público, subasta o venta de propiedades fuera del alcance proporciona información de contacto de los
objetivos dentro del alcance.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
178 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.11 Revisión de la segregación

Pruebas para separar adecuadamente la información privada o personal de la información empresarial. Al igual que una revisión de privacidad,
es el punto focal del almacenamiento, transmisión y control legal y ético de la información privada del personal, socios y clientes.

11.11.1 Mapeo de contención de privacidad

Mapear las ubicaciones clave de la propiedad de información privada dentro del alcance, qué información se almacena, cómo y dónde
se almacena la información y a través de qué canales se comunica la información.

11.11.2Divulgación

(a) Examinar y documentar los tipos de divulgación de información privada sobre la propiedad para su segregación.
de acuerdo con la política y regulaciones determinadas en la Revisión de Postura.
(b) Verificar que la información privada y la propiedad intelectual confidencial, como documentos, contratos de servicios, claves de
SO/software, etc., no estén disponibles para ninguna persona sin los privilegios adecuados.

11.11.3 Limitaciones

(a) Verificar que existan consideraciones de diseño o alternativas de canales para personas con discapacidades físicas.
limitaciones para interactuar con el objetivo.
(b) Identificar cualquier parte de la infraestructura diseñada para interactuar con niños legalmente identificados como menores y
verificar qué información de identificación se proporciona de ese niño y cómo.

11.11.4 Discriminación

Verificar la información solicitada y los privilegios otorgados a los porteros en los casos en que la edad (específicamente menores de
edad), el sexo, la raza, las costumbres/cultura y la religión sean factores que puedan ser discriminados de acuerdo con la Revisión
de Postura.

11.12 Verificación de la exposición

Pruebas para descubrir información que permite o permite el acceso a múltiples ubicaciones con la misma autenticación.

11.12.1 Enumeración de la exposición

(a) Enumerar información sobre la organización, como organigramas, títulos de personal clave, descripciones de trabajo, números
de teléfono personales y laborales, números de teléfono móvil, tarjetas de presentación, documentos compartidos, currículums,
afiliaciones organizacionales, direcciones de correo electrónico privadas y públicas, inicios de sesión, esquemas de inicio de
sesión, contraseñas, métodos de respaldo, aseguradoras o cualquier información organizacional particular indicada implícitamente
como confidencial en regulaciones y políticas. (b) Enumerar las exposiciones del sistema, servicio y aplicación
detallando el diseño, tipo, versión o estado en los objetivos o de recursos fuera del alcance, como publicaciones o filtraciones.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 179
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.13 Inteligencia Competitiva

Pruebas para recopilar información que pueda analizarse como inteligencia empresarial. Si bien la inteligencia competitiva como campo
está relacionada con el marketing, el proceso aquí incluye cualquier forma de recopilación de inteligencia competitiva, incluido, entre otros,
el espionaje económico e industrial. La información empresarial incluye, entre otros, relaciones comerciales como empleados, socios o
revendedores, contactos, finanzas, estrategia y planes.

11.13.1 Rectificado comercial

Enumerar y evaluar los puntos de acceso (puertas de enlace) a la propiedad comercial dentro del alcance: qué información
comercial se almacena, cómo se almacena y dónde se almacena la información.

11.13.2 Elaboración de perfiles

(a) Perfilar los requisitos de habilidades de los empleados, las escalas salariales, la información de canales y puertas de enlace,
tecnologías y dirección organizacional de fuentes fuera del alcance.
(b) Perfiles de configuraciones y configuraciones de redes de datos provenientes de bases de datos de empleos y anuncios de
contratación en periódicos para puestos de redes de datos dentro de la organización relacionados con ingeniería o
administración de hardware y software dentro de los idiomas comerciales predeterminados del objetivo.

11.13.3 Entorno empresarial

(a) Explorar y documentar a partir del personal de acceso individual detalles comerciales tales como alianzas, socios, clientes
principales, proveedores, distribuidores, inversionistas, relaciones comerciales, producción, desarrollo, información de
productos, planificación, existencias y comercio, y cualquier información o propiedad comercial particular declarada
implícitamente como confidencial en las regulaciones y políticas.
(b) Revisar notas web de terceros, anotaciones y contenido de sitios de marcadores sociales creados para la presencia web del
ámbito.

11.13.4 Entorno organizacional

Examinar y documentar los tipos de divulgaciones de propiedad comercial de los guardianes sobre operaciones, procesos,
jerarquía, informes financieros, oportunidades de inversión, fusiones, adquisiciones, inversiones de canal, mantenimiento de
canal, política social interna, insatisfacción del personal y tasa de rotación, tiempos de vacaciones principales, contrataciones,
despidos y cualquier propiedad organizacional particular indicada implícitamente como confidencial en regulaciones y políticas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
180 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.14 Verificación de cuarentena

Las medidas de contención dictan el manejo de los ataques, programas maliciosos y egresos. La identificación de los mecanismos de
seguridad y la política de respuesta deben ser específicas. Puede ser necesario solicitar primero una nueva cuenta de correo de prueba
o un sistema de escritorio que el administrador pueda monitorear. Pruebas para verificar la correcta recepción y contención de contactos
agresivos u hostiles en los puntos de entrada.

11.14.1 Identificación del proceso de contención

Identifique y examine los métodos de cuarentena para detectar contactos agresivos y hostiles, como malware, puntos de acceso
no autorizados, dispositivos de almacenamiento no autorizados, etc.

11.14.2 Niveles de contención

(a) Medir los recursos mínimos que deben estar disponibles para este subsistema para que pueda
realizar su tarea.
(b) Verificar cualquier recurso disponible para este subsistema que no necesite para realizar sus tareas y
¿Qué recursos están protegidos del uso por parte de este subsistema?
(c) Verificar las medidas de detección presentes para la detección de intentos de acceso al sistema blindado.
recursos.
(d) Verificar las características del sistema de contención.
(e) Verificar que existan medidas de detección para detectar accesos "inusuales" a los recursos necesarios.
recursos
(f) Medir la respuesta y el proceso frente a entradas codificadas, empaquetadas, condensadas, renombradas o enmascaradas.

g) Verificar el estado de contención y la duración de los métodos de cuarentena tanto dentro como fuera del ámbito de aplicación.
Asegurarse de que los métodos sean completos y exhaustivos y de que se ajusten al contexto y los límites legales.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 181
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.15 Auditoría de privilegios

Pruebas en las que se proporcionan credenciales al usuario y se le concede permiso para realizar pruebas con esas credenciales.

11.15.1 Identificación

Examinar y documentar el proceso de autorización para la obtención de identificación de los usuarios a través de medios legítimos y
fraudulentos en todos los canales.

11.15.2Autorización

(a) Examinar y verificar cualquier medio para obtener autorización fraudulenta para obtener privilegios similares a
la de otro personal. (b) Enumere
el uso de cuentas predeterminadas en los objetivos.
(c) Probar el acceso a los puntos de acceso autenticados mediante las técnicas de descifrado más adecuadas y disponibles. El
descifrado de contraseñas mediante diccionario o fuerza bruta puede estar limitado por el marco temporal de la auditoría y, por lo
tanto, no es una prueba válida de la protección que ofrece ese esquema de autenticación; sin embargo, cualquier descubrimiento
exitoso da fe de su debilidad.

11.15.3 Escalada
(a) Recopilar información sobre personas con altos privilegios. Buscar roles o puestos de confianza, puertas de acceso para personas
de confianza y cualquier medio de acceso físico requerido, como tokens o tarjetas inteligentes.

(b) Verificar los límites de los privilegios en el objetivo o en múltiples objetivos y si los medios
Existe para aumentar esos privilegios.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
182 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

11.16 Validación de la capacidad de supervivencia

Determinar y medir la resiliencia de los objetivos dentro del alcance ante cambios excesivos u hostiles diseñados para provocar fallas o degradación del servicio.

La denegación de servicio (DoS) es una situación en la que una circunstancia, ya sea intencional o accidental, impide que el sistema funcione como se
esperaba. En ciertos casos, el sistema puede funcionar exactamente como se diseñó, pero nunca estuvo pensado para soportar la carga, el alcance o los
parámetros que se le imponen. Las pruebas de supervivencia deben supervisarse de cerca, ya que la intención es provocar una falla y esto puede ser inaceptable
para el objetivo.
dueño.

11.16.1 Resiliencia

(a) Verificar puntos únicos de falla (puntos de estrangulamiento) en la infraestructura donde se pueden producir cambios o fallas.
provocar una interrupción del servicio.
(b) Verificar el impacto que una falla del sistema o servicio causará en el acceso al objetivo. (c) Verificar los
privilegios disponibles a partir del acceso inducido por la falla.
(d) Verificar la funcionalidad operativa de los controles para evitar el acceso o los permisos superiores a los mínimos.
Posibles privilegios en caso de fallo.

11.16.2 Continuidad

(a) Enumerar y comprobar las deficiencias de todos los objetivos en lo que respecta a los retrasos en el acceso y el servicio.
tiempos de respuesta a través de sistemas de respaldo o el cambio a canales alternativos.
(b) Verificar que los esquemas de bloqueo de intrusos no se puedan utilizar contra usuarios válidos.

11.16.3Seguridad

Mapear y documentar el proceso mediante el cual los guardianes apagan los sistemas objetivo debido a problemas de evacuación o
seguridad, como un análisis de brechas con la regulación y la política de seguridad.

11.17 Revisión de alertas y registros

Un análisis de la brecha entre las actividades realizadas con la prueba y la profundidad real de esas actividades tal como se registraron o según las percepciones
de terceros, tanto humanos como mecánicos.

11.17.1 Alarm

Verificar y enumerar el uso de un sistema, registro o mensaje de advertencia localizado o de alcance amplio para cada puerta de acceso
en cada canal donde el personal detecte una situación sospechosa por sospecha de intentos de evasión, ingeniería social o actividad
fraudulenta.

11.17.2 Almacenamiento y recuperación

(a) Documentar y verificar el acceso sin privilegios a las ubicaciones de almacenamiento de alarmas, registros y notificaciones y
propiedad.
(b) Verificar la calidad y el tiempo de almacenamiento de los documentos para asegurar que los datos
mantener la integridad de ese medio de almacenamiento durante el tiempo requerido.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 183
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Los requisitos de cumplimiento que imponen

medidas de protección como sustituto de la
responsabilidad también son un sustituto de la
rendición de cuentas.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
184 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 12 ­ Cumplimiento
El cumplimiento es la alineación con un conjunto de políticas generales, donde el tipo de cumplimiento requerido depende de la región y del
gobierno vigente, los tipos de industria y negocios y la legislación de respaldo.
El cumplimiento normativo es obligatorio; sin embargo, como ocurre con cualquier otra amenaza, es necesario evaluar los riesgos para determinar
si conviene o no invertir en algún tipo de cumplimiento normativo. A menudo, el cumplimiento normativo no es tan claro como parece.
La OSSTMM reconoce tres tipos de cumplimiento:

1. Legislativo. El cumplimiento de la legislación depende de la región en la que se pueda aplicar. La solidez y el compromiso con la legislación
provienen de argumentos jurídicos exitosos anteriores y de medidas de aplicación adecuadas y justas. El incumplimiento de la legislación puede
dar lugar a cargos penales. Algunos ejemplos son la ley Sarbanes­Oxley, la ley HIPAA y las diversas leyes de protección de datos y privacidad.

2. Contractual. El cumplimiento de los requisitos contractuales se realiza de acuerdo con la industria o dentro del grupo que exige el contrato y se
pueden tomar medidas para exigir su cumplimiento. El incumplimiento de los requisitos contractuales a menudo conduce al despido del grupo, la
pérdida de privilegios, la pérdida de reputación, cargos civiles y, en algunos casos en que existe legislación que respalda al organismo regulador,
cargos penales.
Un ejemplo es el estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS) promovido y requerido por VISA y MasterCard.

3. Basado en estándares. El cumplimiento de los estándares se realiza de acuerdo con la empresa u organización donde el cumplimiento de los
estándares se hace cumplir como política. El incumplimiento de los estándares a menudo conduce al despido de la organización, la pérdida de
privilegios, la pérdida de reputación o confianza en la marca, cargos civiles y, en algunos casos donde existe legislación para apoyar a los
responsables de las políticas, cargos penales. Algunos ejemplos son OSSTMM, ISO 27001/5 e ITIL.

El OSSTMM se desarrolló teniendo en cuenta la legislación principal, los requisitos contractuales y la conformidad con las normas. Como no
todos los objetivos de cumplimiento son iguales, el enfoque principal del OSSTMM es la seguridad. Las medidas de cumplimiento que requieren
productos o servicios específicos, comerciales o de otro tipo, a menudo mediante esfuerzos de lobby especialmente organizados, pueden tener
buenas intenciones; sin embargo, en realidad pueden ser un desperdicio de recursos o una versión inferior de la seguridad deseada. El hecho
de que un objetivo de cumplimiento pueda requerir un producto específico debería ser ilegal en sí mismo.

Dado que la legislación y la reglamentación pueden auditarse en virtud de la letra o del espíritu de la ley, según el organismo de auditoría, la
prueba de la protección y los controles operativos adecuados y válidos, tal como se puede demostrar mediante una prueba OSSTMM, puede ser
satisfactoria o no. Por lo tanto, además, también se debe presentar a los organismos de auditoría correspondientes una prueba OSSTMM
certificada completa con la STAR.

La siguiente lista es solo para el cumplimiento que se ha verificado con la OSSTMM y no limita el alcance real de los organismos reguladores y
legislativos para los que se puede aplicar esta norma. Si puede verificar medidas de cumplimiento que no se enumeran aquí según la OSSTMM
o necesita verificar una medida de cumplimiento específica, envíela a ISECOM para su inclusión en esta lista. La medida de cumplimiento debe
estar en inglés o enviarse a un socio de ISECOM que exista dentro de una región con ese idioma local.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 185
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Reglamento

Australia
• Enmiendas a la Ley de Privacidad de Australia: Ley Nº 119 de 1988 enmendada, preparada el 2 de agosto de 2001 que incorpora
enmiendas hasta la Ley Nº 55 de 2001. La Ley de Privacidad de 1988 (la Ley de Privacidad) busca equilibrar la privacidad individual
con el interés público en la aplicación de la ley y los objetivos regulatorios del gobierno.

• El Principio Nacional de Privacidad (NPP) 6 otorga a una persona el derecho de acceso a la información que se encuentra en su poder.
sobre ellos por una organización.
• El Principio Nacional de Privacidad (NPP) 4.1 establece que una organización debe tomar medidas razonables para proteger la
información personal que posee contra mal uso y pérdida y contra acceso, modificación o divulgación no autorizados.

• Ley de Privacidad de la Commonwealth.

• Autoridad Australiana de Comunicaciones: [Link]
• Agencia Australiana de Protección Radiológica y Seguridad Nuclear
[Link]

Austria
• Ley austriaca de protección de datos de 2000 (Bundesgesetz über den Schutz personenbezogener Daten
(Ley de Protección de Datos de 2000 ­ DSG 2000)), en concreto los requisitos del §14.

Bélgica
• Belgisch Staatsblad N. 189, junio de 2005

Canadá
• Ley de Privacidad de 1983.
• Ley de Libertad de Información y Protección de la Privacidad Municipal (MFIPPA), 1991.
• Ley de Quebec sobre la protección de la información personal en el sector privado, 1993.
• Ley de Protección de Información Personal y Documentos Electrónicos (PIPEDA), 2000.
• Proyecto de ley 198 de 2002 de Ontario.
• Ley de Protección de Información Personal (PIPA), provincias de Alberta y Columbia Británica, 2004.
• Ley de Protección de Información de Salud Personal (PHIPA), 2004.
• Sociedad Real de Canadá ­ [Link]

Estonia
• Ministro de Asuntos Económicos y Política de Seguridad de la Información de las Comunicaciones

Francia
• Sociedad Francesa de Radioprotección ­ [Link]

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
186 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Alemania
• Deutsche Bundesdatenschutzgesetz (BDSG)­­ Artículo 1 des Gesetzes zur Fortentwicklung der Datenverarbeitung und des
Datenschutzes del 20 de diciembre de 1990, BGBl. I S. 2954, 2955, zuletzt geändert durch das Gesetz zur Neuordnung des
Postwesens und der Telekommunikation vom 14.
Septiembre de 1994, BGBl. I S. 2325.
• Manual de protección básica de TI (catálogos IT­Grundschutz) publicado por Bundesamt für Sicherheit in
der Informationstechnik (Oficina Federal de Seguridad de la Información (BSI)) disponible en http://
[Link]/gshb/english/[Link].
• Sistemas de TI alemanes. S6.68 (Prueba de la eficacia del sistema de gestión para el manejo de incidentes de seguridad) y
pruebas S6.67 (Uso de medidas de detección para incidentes de seguridad).
• Bundesamt für Strahlenschutz ­ [Link]

India
• La Ley de Tecnología de la Información de 2000.

Italia
• [Link]. n. 196/2003 ­ Código en materia de protección de datos personales. En caso de que en un contrato/acuerdo el Cliente, titular del
tratamiento de los datos, deba asumir cualquier responsabilidad legal en cuanto a la protección de datos sensibles, como médicos,
personales o judiciales, de Empleados o Clientes, pero también de Distribuidores y Socios. El tester debe estar dispuesto a aceptar
toda la responsabilidad consecuente al aceptar el Acuerdo de Confidencialidad, en particular en lo que respecta al riesgo derivado
del posible conocimiento de datos sensibles y a la cláusula de reserva del plazo de esta especial custodia, que podría ser indefinida.

Malasia
• Ley de Fraude y Abuso Informático.
• La Ley de Delitos Informáticos.

México
• Ley Federal de Transparencia y Acceso a la Información Pública Gubernamental.
• Ley de Propiedad Industrial (LPI).
• Ley Federal de Derechos de Autor (LFDA) y su reglamento (RLFDA). • Código Penal
Federal y Código Federal de Procedimientos Penales.

Países Bajos

• Ley de Delitos Informáticos de los Países Bajos II del 1 de septiembre de 2006 que modifica la Ley de Delitos Informáticos de los Países Bajos
1993
• Convenio sobre la ciberdelincuencia del Consejo de Europa, de 23 de noviembre de 2001
• La ratificación del Tratado "Convención sobre la Ciberdelincuencia, Budapest, [Link].2001" entró en vigor el 1 de junio de 2006

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 187
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Singapur
• Ley de Uso Indebido de Computadoras.
• Código de Comercio Electrónico para la Protección de la Información y las Comunicaciones Personales de los Consumidores de
Comercio por Internet.

España
• LOPD Ley Orgánica de Protección de Datos de Carácter Personal. • LSSICE 31/2002 (Ley de Servicios de la
Sociedad de la Información y el Correo Electrónico), de 11 de julio de
2002.
• RD 14/1999 (Real Decreto de Regulación de la Firma Electrónica), 17 de septiembre de 1999.
• Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de
diciembre, de protección de datos de carácter personal.

Suiza
• Bundesverfassung (BV) de 18 de diciembre de 1998, artículos 7 y 13.
• Obligationenrecht (OR) 2002 (Stand am 1. Oktober 2002), Artikel 707, 716, 716b, 717, 727ff und
321a.
• Datenschutzgesetz (DSG) del 19 de junio de 1992 (Stand am 3 de octubre de 2000). • Bundesamt für
Kommunikation (BAKOM)
• Ministerio Federal de Medio Ambiente

Tailandia
• Derecho de Delitos Informáticos.
• Ley de Protección de Datos de Carácter Personal.

Reino Unido
• Ley de Protección de Datos del Reino Unido de 1998.
• Ley de Libertad de Información de 2000
• Ley de Derechos Humanos de 2000
• Ley de regulación de los poderes de investigación de 2000
• Ley de acceso a los registros sanitarios de 1990
• Ley de 2002 sobre el producto del delito
• Reglamento sobre el blanqueo de dinero de 2003
• Ley de Comunicaciones Electrónicas de 2000
• Reglamento sobre firma electrónica de 2002
• Reglamento sobre privacidad y comunicaciones electrónicas (Directiva CE) de 2003
• Reglamento sobre Comercio Electrónico (Directiva CE) de 2003
• Proyecto de ley de Sociedades (Auditoría, Investigaciones y Empresas Comunitarias)
• Biblioteca de información de TI disponible en [Link] emitida por la Oficina Británica de Comercio
Gubernamental (OGC).
• BSI ISO 17799­2000 (BS 7799): este manual cumple totalmente con todos los requisitos de auditoría y pruebas remotas de BS7799 (y su
equivalente internacional ISO 17799) para auditoría de seguridad de la información.

• CESG CHECK DEL REINO UNIDO: específicamente el servicio CESG IT Health CHECK.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
188 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Estados Unidos de América

• AICPA SAS 70: la verificación de las actividades de control de procesos se aplica al Informe del Auditor de Servicio en la Declaración sobre
Normas de Auditoría (SAS) N.° 70 de la guía para auditores internos del Instituto Americano de Contadores Públicos Certificados.

• Ley Clinger­Cohen.
• Ley de Desempeño y Resultados Gubernamentales.
• Ley FTC, 15 USC 45(a), Sección 5(a).
• Ley de Protección de la Privacidad Infantil en Internet (COPPA).
• Ley de Protección Contra la Ciberocupación (ACPA).
• Ley Federal de Gestión de la Seguridad de la Información.
• Ley Sarbanes­Oxley de Estados Unidos (SOX).
• Proyecto de ley del Senado sobre privacidad individual en California – SB1386.
• Ley de Reforma de Seguridad de la Información del Gobierno de los EE. UU. de 2000, sección 3534(a)(1)(A).
• Vulnerabilidades y exposiciones comunes de MITRE: las limitaciones de seguridad descritas en este manual cumplen
con las descripciones de CVE para categorizaciones más eficientes ([Link]

• DoD FM 31­21, Guerra de guerrillas y operaciones de fuerzas especiales.

• Ley de Portabilidad y Responsabilidad del Seguro Médico de 1996 (HIPAA). • Ley de Privacidad
HIPAA de la OCR TA 164.502E.001, Socios comerciales [45 CFR §§ 160.103, 164.502(e), 164.514(e)].
• OCR HIPAA Privacy TA 164.514E.001, Comunicaciones y marketing relacionados con la salud [45 CFR §§
164.501, 164.514(e)].
• OCR HIPAA Privacidad TA 164.502B.001, Mínimo Necesario [45 CFR §§ 164.502(b), 164.514(d)].
• OCR HIPAA Privacidad TA 164.501.002, Pago [45 CFR 164.501].
• Normas HIPAA para la privacidad de la información de salud individualmente identificable (45 CFR partes 160 y
164).
• FDA: Sistemas informáticos utilizados en ensayos clínicos. Registros electrónicos; Firmas electrónicas; [21 CFR
Parte 11].
• Ley Gramm­Leach­Bliley de los Estados Unidos (GLBA).
• Ley de Seguridad Informática de 1987 (PL 100­235)
• Oficina de Gestión de Personal (OPM) ­ Reglamento de Implementación de los Requisitos de Capacitación de
Ley de Seguridad Informática de 1987 ­ 5 CFR Parte 930, Subparte C
• Sección 7 de COSO Información y comunicación
• Sección 3 de COBit Educar y capacitar a los usuarios
• Consejo de Confiabilidad Eléctrica de América del Norte (NERC) ­ Norma 1300 sección 1303.a.1, 1303.a.2,
1303.a.3
• Manual del Servicio Geológico de Estados Unidos, 600.5 ­ Seguridad de los sistemas de información automatizados ­ General
Requisitos, sección 6 A
• Departamento de Asuntos de Veteranos ­ DIRECTIVA VA 6210 sección 2(d)(3) Concientización y capacitación sobre seguridad
• Ley Federal de Gestión de Seguridad de la Información (FISMA) § 3544(a)(4), (b)(4)
• Directiva Ejecutiva Apéndice III de la Circular N.° A­130 de la OMB
• Norma ITRM 95­1 del estado de Virginia, sección VI •
Administración de Alimentos y Medicamentos: [Link]
• Comisión Federal de Comunicaciones: [Link]

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 189
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Publicaciones del NIST

• Introducción a la seguridad informática: Manual del NIST, 800­12.
• Directrices sobre firewalls y política de firewalls, 800­41. • Requisitos de
capacitación en seguridad de la tecnología de la información: un modelo basado en roles y desempeño,
800­16.
• Directriz sobre pruebas de seguridad de red, 800­42.
• Guía de autoevaluación de seguridad para sistemas de tecnología de la información.
• Análisis de vulnerabilidad de PBX: Cómo encontrar agujeros en su PBX antes de que alguien más lo haga, 800­24.
• Guía de Gestión de Riesgos para Sistemas de Tecnologías de Información, 800­30.
• Sistemas de detección de intrusiones, 800­31.
• Creación de un programa de concientización y capacitación sobre seguridad de tecnologías de la información, 800­50.
• Publicación especial 800­53 del NIST, Controles de seguridad recomendados para sistemas de información federales.
• Guía de métricas de seguridad para sistemas de tecnología de la información, 800­55. • Guía
para la certificación y acreditación de seguridad de sistemas de información federales, 800­37.
• BORRADOR: Guía de recursos introductoria para la implementación de la Regla de seguridad de la Ley de Portabilidad y Responsabilidad del
Seguro Médico (HIPAA), 800­66.
• Consejo de Examen de Instituciones Financieras Federales (FFIEC): Operaciones electrónicas, 12 CFR Parte 555.
• Directrices interinstitucionales que establecen estándares para salvaguardar la información del cliente, 12 CFR 570
Apéndice B.
• Directrices interinstitucionales que establecen normas de seguridad y solidez, 12 CFR 570, Apéndice A.
• Privacidad de la información financiera del consumidor, 12 CFR 573.
• Procedimientos para supervisar el cumplimiento de la Ley de Secreto Bancario, 12 CFR 563.177.
• Procedimientos de seguridad según la Ley de Protección Bancaria, 12 CFR 568.
• Informes de actividades sospechosas y otros informes y declaraciones, 12 CFR 563.180.

General
• SAC: este manual cumple en diseño con los Sistemas del Instituto de Auditores Internos (IIA).
Modelo de Aseguramiento y Control (SAC).
• ITIL ­ este manual es aplicable a la revisión de controles de seguridad operacional y a las interrelaciones de procesos según la Biblioteca
de Infraestructura de TI (ITIL).
• PCI­DSS 1.2 (Estándar de seguridad de datos para la industria de tarjetas de pago)
• ISO/IEC 27001:2005 (Sistemas de gestión de seguridad de la información ­ Requisitos)
• ISO/IEC 27002:2005 (Código de prácticas para la gestión de la seguridad de la información)
• Código de prácticas de la OIT y la OMI: Protección en los puertos, sección 10
• Basilea II (Internacional)

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
190 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

La conciencia de seguridad debe ser la práctica continua

de una habilidad y no el recordatorio continuo de una
amenaza.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 191
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 13 – Informes con el STAR

El STAR es el Informe de Auditoría de Pruebas de Seguridad. Su propósito es servir como resumen ejecutivo de un cálculo preciso que indique
la superficie de ataque de los objetivos probados dentro de un alcance particular. Esta precisión se logra mediante el requisito de anotar
específicamente lo que NO se probó además de lo que se probó de acuerdo con el OSSTMM.

La plantilla proporcionada debe completarse por completo (se puede encontrar una copia de esta plantilla en el sitio web de ISECOM) y el
analista debe firmarla. Luego se proporciona a ISECOM con el permiso explícito del propietario del alcance o directamente al propietario del
alcance junto con el informe completo de la prueba de seguridad. No reemplaza a un informe completo.

Al proporcionar la STAR a ISECOM para su verificación, se imprime, el auditor de verificación la firma y ISECOM la sella. Se proporciona un
certificado para todas las pruebas que indica que el alcance ha sido probado y verificado. No hay aprobación ni reprobación, ya que no existe
un valor rav de superficie de ataque particular para todos los alcances como límite entre uno que aprueba y uno que reprueba. Sin embargo,
los valores rav para un alcance superiores al 90 % se marcarán con un sello de excelencia.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
192 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

Informe de auditoría de pruebas de seguridad

Certificación de verificación de seguridad OSSTMM 3.0
[Link] ­ [Link]

Identificación del informe Fecha

Auditor principal Fecha de la prueba Duración

Alcance e índice Vectores

Canales Tipo de prueba

Soy responsable de la información contenida en este informe y he verificado personalmente que toda la información aquí contenida es real y verdadera.

FIRMA SELLO DE LA EMPRESA

Certificación ISECOM # Certificación ISECOM #

VALORES DE SEGURIDAD OPERACIONAL VALORES DE CONTROL

Visibilidad Autenticación
Acceso Indemnización
Confianza Resiliencia
Subyugación
VALORES DE LIMITACIONES Continuidad
Vulnerabilidad No repudio
Debilidad Confidencialidad
Inquietud Privacidad
Exposición Integridad
Anomalía Alarma

Seguridad operacional
Controles verdaderos

Limitaciones Seguridad Δ

Protección verdadera Seguridad actual

Machine Translated by Google

Página 1 de 9

DESCRIPCIÓN GENERAL

Este manual de metodología de pruebas de seguridad de código abierto proporciona una metodología para realizar pruebas de
seguridad exhaustivas. Una prueba de seguridad es una medición precisa de la seguridad a nivel operativo, libre de suposiciones y
evidencia anecdótica. Una metodología adecuada permite obtener una medición de seguridad válida, consistente y repetible.

ACERCA DE ISECOM
ISECOM, el creador y mantenedor de OSSTMM, es una organización de investigación de seguridad independiente y sin fines de lucro
y una autoridad de certificación definida por los principios de colaboración abierta y transparencia.

TÉRMINOS Y DEFINICIONES RELACIONADOS

Este informe puede hacer referencia a palabras y términos que pueden interpretarse con otras intenciones o significados. Esto es
especialmente cierto en el caso de las traducciones internacionales. Este informe intenta utilizar términos y definiciones estándar que
se encuentran en el vocabulario OSSTMM 3, que se ha basado en NCSC­TG­004 (Teal Green Book) del Departamento de Defensa
de los EE. UU. cuando corresponde.

OBJETIVO
El objetivo principal de este Informe de Auditoría es proporcionar un esquema de informes estándar basado en una metodología
científica para la caracterización precisa de la seguridad mediante el examen y la correlación de una manera consistente y confiable.
El objetivo secundario es proporcionar pautas que, al seguirse, permitan al auditor proporcionar una auditoría OSSTMM certificada.

PROCESO
Este Informe de Auditoría debe acompañar el documento de informe de prueba de seguridad completo que proporciona evidencia de
la prueba y los resultados según se define en la declaración de trabajo entre la organización de pruebas y el cliente.

VALIDEZ
Para que este Informe de Auditoría OSSTMM sea válido, debe completarse de forma clara, correcta y completa. El Informe de Auditoría OSSTMM debe estar firmado por el

probador o analista responsable o líder y debe incluir el sello de la empresa que tiene el contrato o subcontrato de la prueba. Este informe de auditoría debe mostrar en ESTADO

DE FINALIZACIÓN qué Canal y los Módulos y Tareas asociados se han probado hasta su finalización, cuáles no y cuáles no fueron aplicables y por qué. Un informe que

documente que solo se han completado partes específicas de la prueba del Canal debido a limitaciones de tiempo, problemas del proyecto o rechazo del cliente puede ser

reconocido como una auditoría oficial OSSTMM si va acompañado de este informe que muestra claramente las deficiencias y las razones de esas deficiencias.

PROCESO DE DAR UN TÍTULO

La certificación OSSTMM es la garantía de la seguridad de una organización según las pruebas exhaustivas dentro del estándar
OSSTMM y está disponible por vector y canal para organizaciones o partes de organizaciones que mantienen vigilancia sobre sus
niveles de RAV y los validan anualmente por un auditor externo independiente. La validación de las pruebas de seguridad o métricas
trimestrales está sujeta a los requisitos de validación de ISECOM para garantizar la coherencia y la integridad.
Machine Translated by Google

Página 2 de 9

1. REVISIÓN DE LA POSTURA
TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

1.1 Objetivos comerciales y mercados identificados.

1.2 Legislación y reglamentación identificadas aplicables a
los objetivos en el ámbito de aplicación.
1.3 Políticas de negocio identificadas.
1.4 Se identificaron políticas éticas empresariales e
industriales.
1.5 Culturas y normas de operación identificadas.
1.6 Se identificaron los tiempos y flujos de operación
aplicables a los objetivos del alcance.
1.7 Se identificaron todos los canales necesarios para este
alcance.
1.8 Se identificaron todos los vectores para este alcance.

2. LOGÍSTICA
TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

2.1 Se aplicaron medidas de seguridad en las pruebas.

2.2 Se determinaron y tuvieron en cuenta las inestabilidades
de las pruebas.

2.3 Se determinó y contabilizó el tiempo de inactividad dentro del

alcance.
2.4 Determinó y tuvo en cuenta el ritmo de la prueba de acuerdo
con el entorno de prueba y la presencia de seguridad.

3. VERIFICACIÓN DE DETECCIÓN ACTIVA

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

3.1 Interferencias determinadas y contabilizadas.

3.2 Probado con ambas interferencias activas y

inactivo.

3.3 Restricciones determinadas impuestas a las pruebas.

3.4 Reglas de detección verificadas y previsibilidad.

4. AUDITORÍA DE VISIBILIDAD

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

4.1 Objetivos determinados a través de todos

tareas de enumeración.

4.2 Se determinaron nuevos objetivos investigando objetivos conocidos.

Machine Translated by Google

Página 3 de 9

5. VERIFICACIÓN DE ACCESO

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

5.1 Interacciones verificadas con puntos de acceso a todos los

objetivos dentro del alcance.

5.2 Se determinó el tipo de interacción para todos los puntos de

acceso.
5.3 Fuente determinada de interacción definida como un servicio o proceso.

5.4 Profundidad de acceso verificada.

5.5 Limitaciones de seguridad conocidas verificadas de los puntos

de acceso descubiertos.
5.6 Se buscó una nueva forma de eludir la normativa

Técnicas y limitaciones de seguridad de los puntos de

acceso descubiertos.

6. VERIFICACIÓN DE CONFIANZA

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

6.1 Interacciones determinadas que dependen de otras

interacciones para completar la interacción de
prueba de acuerdo a las tareas.

6.2 Objetivos determinados con relaciones de confianza con otros objetivos

en el alcance para completar interacciones.

6.3 Objetivos determinados con relaciones de confianza con otros objetivos

fuera del alcance para completar interacciones.

6.4 Se verificaron las limitaciones de seguridad conocidas de las

confianzas descubiertas entre las confianzas.

6.5 Limitaciones de seguridad conocidas y verificadas

Se descubrieron confianzas entre los objetivos en el alcance y
las interacciones confiables.
6.6 Se buscó una nueva forma de eludir la normativa

Técnicas y limitaciones de seguridad de los fideicomisos

descubiertos.
Machine Translated by Google

Página 4 de 9

7. VERIFICACIÓN DE CONTROLES

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

7.1 Controles verificados para el funcionamiento de No

Repudio de acuerdo a todas las tareas.

7.2 Controles verificados para el funcionamiento de

Confidencialidad de acuerdo a todas las tareas.

7.3 Controles verificados para el funcionamiento de la Privacidad según

todas las tareas.

7.4 Controles verificados para el funcionamiento de Integridad de

acuerdo a todas las tareas.

7.5 Controles verificados para el funcionamiento de la alarma de

acuerdo a todas las tareas.

7.6 Limitaciones de seguridad conocidas y verificadas de todos los

controles de las categorías de clase B.
7.7 Se buscó una nueva forma de eludir la normativa

Técnicas y limitaciones de seguridad de todos los controles

categorías de clase B.

8. VERIFICACIÓN DEL PROCESO

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

8.1 Se determinaron todos los procesos que controlan la acción de

interactividad con cada acceso.

8.2 Se verifica que la interacción opera dentro de los confines del proceso
determinado.

8.3 Se verificó que la interacción funciona dentro de los límites de la política

de seguridad para dichas interacciones.

8.4 Se determinó la brecha entre las operaciones de interacciones

y los requerimientos de la postura a partir de la
Revisión de Postura.

8.5 Se verificaron las limitaciones de seguridad conocidas de los

procesos descubiertos.
8.6 Se buscó una nueva forma de eludir la normativa

Técnicas y limitaciones de seguridad de los procesos

descubiertos.
Machine Translated by Google

Página 5 de 9

9. VERIFICACIÓN DE CONFIGURACIÓN Y ENTRENAMIENTO

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

9.1 Requisitos de configuración/entrenamiento verificados según

la postura en la Revisión de Postura.

9.2 Se verificó la aplicación de los mecanismos de seguridad

adecuados según lo definido en la Revisión de Postura.

9.3 Se verificó la funcionalidad y seguridad

limitaciones dentro de las configuraciones/entrenamiento para
los objetivos en el alcance.
9.4 Se buscó una nueva forma de eludir la normativa
Técnicas y limitaciones de seguridad dentro de las
configuraciones/entrenamiento.

10. VALIDACIÓN DE LA PROPIEDAD

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

10.1 Se determinó la cantidad y el tipo de

propiedad intelectual sin licencia distribuida dentro del ámbito.

10.2 Verificó la cantidad y tipo de sin licencia

propiedad intelectual disponible para la venta/
comercio con el vendedor originariamente dentro del ámbito.
Machine Translated by Google

Página 6 de 9

11. REVISIÓN DE LA SEGREGACIÓN

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

11.1 Se determinó la cantidad y ubicación de

información privada tal como se define en la Revisión
de Postura disponible a través de los objetivos.

11.2 Se determinó el tipo de información privada según se define en la

Revisión de Postura disponible dentro del alcance.

11.3 Se verificó la relación entre la información de acceso público

fuera del objetivo que detalla información privada o
confidencial definida en la Revisión de Postura y la

alcance.

11.4 Se verificó la accesibilidad de los accesos públicos dentro del área

de influencia a personas con discapacidad.

12. VERIFICACIÓN DE LA EXPOSICIÓN

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

12.1 Se buscaron objetivos disponibles a través de fuentes

disponibles públicamente fuera del alcance.

12.2 Se buscó información organizativa disponible

activos tal como se definen en la Revisión de Postura a
través de fuentes disponibles públicamente fuera del alcance.

12.3 Se determinó el acceso, la visibilidad, la confianza y los

controles de la información disponible públicamente
dentro de los objetivos.

12.4 Se determinó un perfil de la organización.

Infraestructura de canal para todos los canales
probados a través de información disponible
públicamente dentro de los objetivos.

12.5 Se determinó un perfil de la organización.

Infraestructura de canal para todos los canales
probados a través de información disponible
públicamente fuera del alcance.
Machine Translated by Google

Página 7 de 9

13. INTELIGENCIA COMPETITIVA

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

13.1 Se determinó el entorno empresarial de

socios, proveedores, trabajadores y mercado a través
de información disponible públicamente sobre los objetivos
dentro del alcance.
13.2 Se determinó el entorno empresarial de
socios, vendedores, distribuidores, proveedores,
trabajadores y mercado a través de información
disponible públicamente fuera del alcance.

13.3 Determinó el entorno organizacional a través de

información disponible públicamente sobre los objetivos
dentro del alcance.

13.4 Determinó el entorno organizacional a través de

información públicamente disponible fuera del alcance.

14. VERIFICACIÓN DE CUARENTENA

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

14.1 Métodos de cuarentena verificados para

interacciones con los objetivos en el alcance.

14.2 Métodos de cuarentena verificados para

interacciones de los objetivos con otros objetivos
fuera del alcance.

14.3 Duración verificada del período de cuarentena.

14.4 Proceso de cuarentena verificado desde la recepción hasta la

liberación.

14.5 Limitaciones de seguridad conocidas verificadas de las

cuarentenas descubiertas.
14.6 Se buscó una nueva forma de eludir la normativa
Técnicas y limitaciones de seguridad de las
cuarentenas descubiertas.
Machine Translated by Google

Página 8 de 9

15. AUDITORÍA DE PRIVILEGIOS

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

15.1 Se verificaron los medios para obtener

legítimamente privilegios para todas las interacciones
autenticadas.

15.2 Verificado el uso de identificación

fraudulenta para obtener privilegios.
15.3 Se verificaron los medios para eludir los requisitos de
autenticación.
15.4 Se verificaron los medios para tomar privilegios de
autenticación no públicos.
15.5 Se verificó que los medios secuestran otros
privilegios de autenticación.
15.6 Se verificaron las limitaciones de seguridad conocidas
de los mecanismos de autenticación descubiertos para
escalar privilegios.
15.7 Se buscó una nueva forma de eludir la normativa
Técnicas y limitaciones de seguridad de los
mecanismos de autenticación descubiertos para escalar
privilegios.

15.8 Se determinó la profundidad de todos los privilegios de

autenticación descubiertos.

15.9 Se determinó la reutilización de todos los privilegios de

autenticación descubiertos en los mecanismos
de autenticación en todos los objetivos.

15.10 Requisitos verificados para la obtención de privilegios de

autenticación para prácticas
discriminatorias según la Revisión de Postura.

15.11 Medios verificados para obtener privilegios de

autenticación para prácticas
discriminatorias para personas con discapacidad.
Machine Translated by Google

Página 9 de 9

16. VALIDACIÓN DE LA CAPACIDAD DE SUPERVIVENCIA Y CONTINUIDAD DEL SERVICIO

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

16.1 Medidas determinadas aplicables a

interrumpir o detener la continuidad del servicio hacia y
desde los objetivos.

16.2 Procesos de continuidad verificados y mecanismos de

seguridad activos para los objetivos.

16.3 Limitaciones de seguridad conocidas verificadas

Descubrió procesos y mecanismos de seguridad y
continuidad del servicio.
16.4 Se buscó una nueva forma de eludir la normativa
Técnicas y limitaciones de seguridad de los procesos
y mecanismos de seguridad y continuidad del servicio
descubiertos.

17. FINALIZACIÓN DE LA ENCUESTA, ALERTA Y REVISIÓN DE REGISTROS

TAREA COMENTARIOS ESTADO DE FINALIZACIÓN

17.1 Métodos verificados para el registro y

alertar sobre las interacciones con los objetivos en el ámbito de
aplicación.

17.2 Métodos verificados para el registro y

alertar sobre interacciones de los objetivos con otros
objetivos fuera del alcance.

17.3 Velocidad verificada de grabación y alerta.

17.4 Persistencia verificada de la grabación y alertas.

17.5 Integridad verificada de la grabación y alertas.

17.6 Proceso de distribución verificado de grabaciones y alertas.

17.7 Se verificaron las limitaciones de seguridad conocidas de

los métodos de grabación y alerta descubiertos.

17.8 Se buscó una nueva forma de eludir la normativa

Técnicas y limitaciones de seguridad de los métodos
de grabación y alerta descubiertos.
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Cuanto más te alejas del concepto de

seguridad carcelaria, más exiges la cooperación
y las buenas intenciones de las personas a
las que estás protegiendo.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 203
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 14 – Lo que obtienes

Lo que obtendremos al utilizar OSSTMM es simplemente una comprensión profunda de la interconexión de las cosas. Las personas, los
procesos, los sistemas y el software tienen algún tipo de relación. Esta interconexión requiere interacciones. Algunas interacciones son
pasivas y otras no. Algunas interacciones son simbióticas mientras que otras son parásitas. Algunas interacciones están controladas por
un lado de la relación mientras que otras están controladas por ambos. Luego, algunos controles son defectuosos o superfluos, lo que es
perjudicial para al menos un lado de la relación, si no ambos. Otros controles se equilibran perfectamente con las interacciones. Cualquiera
sea el resultado de la interconexión, independientemente de cómo ocurran las interacciones, independientemente de cómo se controlen,
son las operaciones que hacen posible la supervivencia. Cuando probamos las operaciones obtenemos el panorama general de nuestras
relaciones. Podemos ver la interconexión de las operaciones en gran detalle.

Podemos planificar cómo nosotros, nuestros negocios y nuestras operaciones sobreviviremos e incluso prosperaremos.

Lamentablemente, la forma en que interactuamos se basa únicamente en una colección de prejuicios que acumulamos a lo largo de la
vida, que están sujetos al estado emocional o bioquímico en el que nos encontramos cuando los tenemos. Éstos son nuestros atajos.
Debido a la increíble cantidad de decisiones que debemos tomar a lo largo de todas nuestras interacciones, utilizamos una hoja de trucos
mental para comparar interacciones similares en lugar de calcular cada situación de forma independiente. Después de todo, somos
humanos. Sin embargo, la mayoría de las veces nuestras opiniones son limitadas y restringidas a un pequeño ámbito que conocemos
como "nuestro pequeño mundo". Las aplicamos en todas partes porque hacen la vida más fácil.
Pero si las llevamos con nosotros y tratamos de aplicarlas a series y tipos de interacciones más amplios, diferentes y más complicados, es
probable que cometamos errores. Lo que para nosotros puede tener todo el sentido de acuerdo con nuestras experiencias puede no tener
ningún sentido fuera de “nuestro pequeño mundo”. Por lo tanto, lo que necesitamos es una forma mejor y menos sesgada de mirar el
mundo más grande, más dinámico y menos personal que está más allá de nosotros mismos.

Además, nuestro pequeño mundo es algo que llevamos con nosotros. Cuando estamos fuera, nuestro pequeño mundo está fuera con
nosotros. Interactuamos en el espacio con los supuestos y prejuicios que conocemos y llevamos dentro. Cuando entramos, llevamos
nuestro pequeño mundo dentro con nosotros. Esto significa que llevamos nuestras formas de hacer las cosas y nuevas interacciones a un
nuevo entorno. Y siempre ha sido así. No hay perímetro. No hay nosotros y ellos. Es cada individuo interactuando e interconectando con
todos y con todo; cada individuo con su propio pequeño mundo de problemas y preconcepciones que impactan en el resto, mientras que
al mismo tiempo es impactado por otros. Esto significa que necesitamos una manera de ver más que solo el mundo más grande; también
necesitamos una manera de ver también los pequeños mundos de cada individuo.

A menudo, la dificultad de crear seguridad se atribuye a la sofisticación y la persistencia de los ataques.

Sin embargo, esto sólo sirve para desviar la culpa, pero no resuelve el problema. El verdadero desafío consiste en proteger interacciones
particulares en un mundo interconectado lleno de elementos incontrolables. A primera vista, la gran cantidad de interacciones puede
resultar abrumadora. Las soluciones de protección suelen abordar este desafío abordando de manera amplia tipos particulares de
interacciones o monitoreando todas las interacciones a medida que ocurren para detectar intenciones maliciosas. Desafortunadamente, los
programas y procesos de seguridad amplios no pueden abordar una cantidad suficiente de elementos como para brindar una protección
significativa. Esto hace que la seguridad en la práctica sea más un arte que depende de que el profesional aplique su propio pequeño
mundo al desafío de la seguridad. Esto sólo puede agregar más complejidad y nuevos problemas. El medio para encontrar una protección
global y persistente en perfecto equilibrio con las operaciones es a través de la Defensa Möbius.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
204 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

La defensa de Möbius
Debido a la multitud de medios en los que ocurren las interacciones hacia y desde cualquier organización, como los diversos Canales y
vectores, los perímetros a defender parecen tomar la forma de una banda de Möbius.
Una cinta de Möbius es una forma sin interior ni exterior, lo que significa que no hay ningún “lado” desde el cual defenderse.
Por lo tanto, lo que se necesita es una defensa diseñada para proteger un entorno en el que cada individuo pueda interactuar e interconectarse
con todos y con todo. La Defensa de Möbius lo hace en tres pasos:

1. Mejorar la verificación y el análisis: verificar y analizar las operaciones en busca de interacciones y controles.
y no sólo defectos.
2. Establecer una defensa en amplitud: aplicar tácticas defensivas para equilibrar los controles de todas las interacciones
con operaciones.
3. Implementar una estrategia de confianza: compartimentar cómo se autorizan o controlan las interacciones.

1. Mejora de la verificación y el análisis

La práctica de verificar la seguridad operativa debe incluir más que simplemente encontrar fallas. Es necesario tener en cuenta y comprender
mejor los errores que harán que las pruebas sean inexactas. Es necesario mejorar la precisión de las pruebas mediante una mejor comprensión
de qué probar y cuándo hacerlo.
Aumentar la precisión de los resultados de las pruebas servirá para proporcionar resultados que se puedan repetir y resultados que se puedan
utilizar para realizar mediciones consistentes. La prueba de seguridad debe catalogar y clasificar todos los puntos de interacción, determinar
qué controles existen para esas interacciones y verificar la funcionalidad de esos controles. Las fallas dentro del alcance o de los controles se
deben clasificar según la forma en que afectan las operaciones y no según el riesgo posible o potencial que representan para las operaciones.
La prueba de seguridad también debe rastrear lo que no se probó y las pruebas que no se realizaron para asegurar la repetibilidad y
comparaciones justas con pruebas pasadas y futuras. Finalmente, el analista de pruebas debe ser capaz de comprender adecuadamente los
resultados de la prueba y lo que significan para las operaciones. Los medios para hacer todo esto se proporcionan en este manual.

2. Establecer defensa en amplitud

El concepto principal detrás de una Defensa Möbius es proporcionar Defensa en Ancho y una variedad equilibrada de controles para cada
punto interactivo. Se logra un equilibrio perfecto con la aplicación impecable de los diez tipos de controles operativos para cada punto
interactivo. Esto difiere de la Defensa en Profundidad al asegurar que se apliquen diferentes tipos de controles a todos los puntos interactivos
en lugar de solo cualquier control en varios puntos dentro de un proceso. Con nueva información de la prueba de seguridad, se puede crear
una postura defensiva verificando que exista un equilibrio de controles en todos los puntos de interacción. Esto cambia el entorno en el que se
produce la interconectividad y limita los posibles cambios operativos causados por elementos caóticos, ya sea internos o externos.

El equilibrio de los controles es importante porque cada uno de ellos puede contribuir a la superficie de ataque de una operación. Garantizar un
equilibrio también garantiza que se utilicen distintos tipos de controles que proporcionen protección de distintas maneras. Esto aumenta la
variedad de tipos de ataques y problemas contra los que se puede defender el punto interactivo. Los RAV se deben utilizar para medir la
cantidad de equilibrio alcanzado y para garantizar que se mantenga a medida que se introducen nuevas operaciones en el ámbito. Este manual
cubre toda la información necesaria para crear una defensa en amplitud.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 205
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

3. Implementación de una estrategia de confianza

Para saber qué interacciones requieren menos equilibrio que otras desde Defense in Width es necesario saber en qué interacciones debemos
confiar. En el caso de las operaciones en las que tenemos menos motivos para confiar, debemos aplicar más de los diez controles para lograr
un equilibrio perfecto. A los individuos en los que tenemos menos motivos para confiar los colocamos en entornos en los que todas las
interacciones están protegidas por más de los diez controles. Por el contrario, se puede autorizar a los individuos dignos de confianza a tener
un mayor control individual sobre las interacciones en su entorno.
Por último, debemos separar los elementos del entorno cuando no se encuentren motivos importantes para confiar en ellos ni beneficios para
la operación. De esta manera, también se mantendrá la Defensa en Ancho dentro de una escala de operaciones razonable, de modo que la
eficiencia y los gastos no superen los beneficios de la protección.

Las métricas de confianza que se proporcionan en este manual garantizan que las razones para confiar se basan en hechos. A medida que las
razones para confiar se acercan al 100%, no solo estamos seguros de que el individuo o la operación son incapaces de causar daños
maliciosos o accidentales, sino que también se ha demostrado que lo son. No se trata de una evaluación de riesgos ni de una suposición
basada en lo que sabemos de nuestro “pequeño mundo”. Sin embargo, la dificultad de este proceso puede estar en asignar métricas de
confianza a las personas. A diferencia de la forma informal y casi caprichosa en que se suele asignar la confianza, esta nueva forma puede
parecer fría y despiadada. Pero no lo es, porque mientras investigas qué razones tienes para confiar en alguien, también puedes informarle
plenamente de lo que puede hacer para darte más razones para confiar en él. El medio típico para confiar o no confiar no es tan específico ni
tan amable. Es más bien un juego social de agradar o no a la persona que proporciona la autorización. Las métricas de confianza son más
transparentes y más neutrales, más allá de cómo se siente alguien en función de su “pequeño mundo”. Las métricas de confianza incluso
pueden ser verificadas por otros, como una junta o un departamento, que pueden mantener los cálculos de confianza de manera neutral y
reevaluarlos periódicamente o cuando sea necesario.

Conseguir lo que necesitamos

La aplicación de la Defensa Möbius tiene muchas ramificaciones. En primer lugar, garantiza que los resultados de las pruebas de seguridad
sean los hechos. Garantiza que las pruebas hayan sido exhaustivas y se hayan basado en los procesos de las operaciones y no en las
habilidades del analista. Esto proporciona a una organización una increíble cantidad de información sobre sus propias operaciones para realizar
comparaciones con otras organizaciones o incluso para realizar autoevaluaciones de tendencias.
Es el tipo de información que requieren las decisiones y la que fomenta mejoras operativas significativas.

En segundo lugar, cambia la frecuencia de las pruebas de seguridad necesarias porque, en lugar de basarse en la reacción a los ataques y las
vulnerabilidades, las defensas forman parte del control de cambios. Por lo tanto, cuando se inician nuevas operaciones, se vuelve a evaluar el
entorno para detectar puntos de interacción nuevos o diferentes. Ya no es necesario realizar pruebas para detectar nuevos fallos ni comprobar
la compatibilidad de las actualizaciones de seguridad después de corregirlos. Las actualizaciones de seguridad, si se desea, pasarán a formar
parte del proceso de control de cambios y se podrán probar según lo programado. Esto reducirá drásticamente el tiempo dedicado a apagar
incendios, de modo que se pueda centrar la atención en mejorar las operaciones y construir una mejor infraestructura.

En tercer lugar, cambia la forma, a menudo secreta y socialmente exigente, en que utilizamos la confianza dentro de las organizaciones.
Permite que el desempeño y la historia de cada individuo hablen por sí mismos. Esto añade responsabilidad a cada función y elimina los
prejuicios que pueden estrangular a una organización, ya sea operativa o legalmente. Sin mencionar que es el medio más justo de garantizar
que cada persona sea responsable de sus propios éxitos y fracasos.

Los cambios que requiere una organización típica para lograr estos beneficios son en realidad pequeños. Los cambios que requiere la industria
de la seguridad para satisfacer las nuevas necesidades de los implementadores de Möbius Defense serán enormes. Y el cambio traerá nuevas
oportunidades.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
206 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Esta metodología es libre precisamente porque

nosotros también preferimos ser libres.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 207
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

Capítulo 15 – Licencia de Metodología Abierta

El OML 3
Esta licencia se proporciona bajo la licencia Creative Commons 3.0 Attribution, 2010 de ISECOM.

PREÁMBULO

Esta licencia tiene por objeto proteger una metodología como un conjunto complejo de métodos, procesos o procedimientos que se aplican en una
disciplina. Los requisitos clave de esta licencia son que: 1) la metodología tenga valor como propiedad intelectual y que, a través de su aplicación,
pueda producir valor cuantificable, y 2) que la metodología esté disponible públicamente y se haga un esfuerzo adecuado para que sea transparente
para todos.

Con respecto a la Licencia Pública General de GNU (GPL), esta licencia es similar con la excepción de que otorga el derecho a los desarrolladores
de incluir esta Licencia de Metodología Abierta (OML) a cualquier cosa que no sea modificable ni distribuida comercialmente.

La principal preocupación que cubre esta licencia es que los desarrolladores de metodologías abiertas reciban el crédito adecuado por su
contribución y desarrollo.

Consideraciones especiales para la Free Software Foundation y la Licencia Pública General GNU por conceptos y redacción legal.

TÉRMINOS Y CONDICIONES

1. La licencia se aplica a cualquier metodología u otra herramienta intelectual (es decir, matriz, lista de verificación, etc.) que contenga un aviso
colocado por el creador indicando que está protegida bajo los términos de esta Licencia de Metodología Abierta 3.0 u OML 3.0.

2. La Metodología se refiere a cualquier metodología, herramienta intelectual o cualquier trabajo basado en la Metodología. Una “obra basada en
la Metodología” significa la Metodología o cualquier obra derivada según la ley de secretos comerciales que se aplique a una obra que contenga la
Metodología o una parte de ella, ya sea textualmente o con modificaciones o traducida a otro idioma.

3. Todas las personas pueden usar, distribuir, enseñar y promover la Metodología exactamente como la han recibido, en cualquier medio, siempre
que publiquen de manera visible y apropiada en cada copia el aviso correspondiente de la Licencia de Metodología Abierta y la atribución al creador
o creadores de la Metodología; mantengan intactos todos los avisos que hagan referencia a esta Licencia y a la ausencia de cualquier garantía;
entreguen a cualquier otro destinatario de la Metodología una copia de esta Licencia junto con la Metodología, y la ubicación donde pueden recibir
una copia original de la Metodología del creador de la Metodología.

4. Cualquier persona que venda capacitación o servicios de la Metodología deberá mostrar claramente el nombre de los creadores de esta
Metodología además de los términos de esta licencia.

5. Todas las personas pueden incluir esta Metodología en parte o en su totalidad en ofertas de servicios comerciales, uso privado, interno o no
comercial incluyendo software, listas de verificación o herramientas, o dentro de una clase o capacitación con fines educativos sin el consentimiento
explícito del creador siempre que se cumplan los puntos 3 y 4.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
208 Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link]
Machine Translated by Google

OSSTMM 3 – Manual de metodología de pruebas de seguridad de código abierto

6. Ninguna persona puede distribuir una adaptación, modificación o cambio de esta Metodología ni vender comercialmente un producto,
herramienta, lista de verificación o software que aplique esta Metodología sin el consentimiento explícito del creador.

7. Todas las personas pueden utilizar la Metodología o cualquier parte de ella para crear o mejorar software libre y copiar y distribuir dicho
software bajo cualquier condición, siempre que cumplan también con todas estas condiciones:

a) Se cumplen estrictamente los puntos 3, 4, 5 y 6 de esta Licencia.

b) Cualquier reducción o uso incompleto de la Metodología en el software deberá indicar estricta y explícitamente qué partes de la
Metodología fueron utilizadas en el software y cuáles no.

c) Cuando se ejecuta el software, todo software que utilice la Metodología debe hacer que, al iniciarse su ejecución, el software imprima o
muestre un anuncio de uso de la Metodología, incluido un aviso de garantía sobre cómo ver una copia de esta Licencia o hacer
disposiciones claras en otra forma, como en la documentación o en el código fuente abierto entregado.

8. Si, como consecuencia de una sentencia judicial o una alegación de infracción de patentes, infracción de la ley de secretos comerciales o por
cualquier otra razón legal, se imponen condiciones a cualquier persona (ya sea por orden judicial, acuerdo o de otro modo) que contradigan las
condiciones de esta Licencia, dichas condiciones no eximen a dicha persona de cumplir las condiciones de esta Licencia. Si dicha persona no
puede satisfacer simultáneamente las obligaciones bajo esta Licencia y cualquier otra obligación pertinente, entonces, como consecuencia, dicha
persona no podrá usar, copiar, aplicar, distribuir o promover la Metodología en absoluto. Si alguna parte de esta sección se considera inválida o
inaplicable bajo alguna circunstancia particular, se pretende que se aplique el resto de la sección y la sección en su totalidad se pretende que se
aplique en otras circunstancias.

9. Si la distribución o el uso de la Metodología está restringido en ciertos países, ya sea por patentes o por interfaces de secretos comerciales, el
creador original que coloca la Metodología bajo esta Licencia puede agregar una limitación explícita de distribución geográfica que excluya esos
países, de modo que la aplicación, el uso o la distribución se permitan solo en o entre los países no excluidos. En tal caso, esta Licencia incorpora
la limitación como si estuviera escrita en el cuerpo de esta Licencia.

10. ISECOM podrá publicar versiones revisadas o nuevas de la Licencia de Metodología Abierta. Dichas nuevas versiones serán similares en
espíritu a la versión actual, pero podrán diferir en detalles para abordar nuevos problemas o inquietudes.

SIN GARANTÍA

11. Debido a que la metodología se otorga bajo licencia sin cargo, no existe garantía para la metodología, en la medida permitida por la ley
aplicable, excepto cuando se indique por escrito que el creador u otras partes proporcionan la metodología “tal cual”, sin garantía de ningún tipo,
ya sea expresa o implícita, incluidas, entre otras, las garantías implícitas de comerciabilidad y de idoneidad para un propósito particular. El riesgo
total en cuanto a la calidad y el rendimiento en el uso de la metodología recae sobre las personas que aceptan esta licencia. Si la metodología
resulta incompleta o incompatible, dicha persona asume el costo de todo el servicio, reparación o corrección necesarios.

12. En ningún caso, a menos que lo exija la ley aplicable o se acuerde por escrito, el creador o cualquier otra parte que pueda usar, aplicar o
enseñar la metodología sin modificaciones según lo permitido en este documento, será responsable ante ninguna persona por daños, incluidos
los daños generales, especiales, incidentales o consecuentes que surjan del uso o la imposibilidad de usar la metodología (incluidos, entre otros,
la pérdida, las inexactitudes o la falla de la metodología para operar con otras metodologías), incluso si dicho titular u otra parte ha sido informado
de la posibilidad de tales daños.

Creative Commons 3.0 Atribución­No comercial­Sin obras derivadas 2010, ISECOM, [Link], [Link]
Certificaciones oficiales OSSTMM: [Link], [Link], [Link], [Link], [Link] 209
Machine Translated by Google
Machine Translated by Google

¿Por qué probar las operaciones? Lamentablemente, no todo funciona como está configurado. No todos se comportan como se les enseñó.
Por lo tanto, la verdad de la configuración y el entrenamiento está en las operaciones resultantes. Por eso es necesario probar las
operaciones.

El Manual de metodología de pruebas de seguridad de código abierto se propone ser la guía de seguridad definitiva.
Más conocido por expertos en seguridad y hackers como OSSTMM, pronunciado como “genial” pero con “b”, es
una metodología formal para romper cualquier seguridad y atacar cualquier cosa de la forma más exhaustiva
posible.

El manual, que se publicó de forma gratuita por primera vez en 2001 como la versión menos recomendada de los
consejos de seguridad centrados en productos de la industria de la seguridad, tuvo una aceptación inmediata. Al
estar abierto a cualquier persona para su revisión por pares y para realizar más investigaciones, pasó de tener 12
páginas al tamaño actual de más de 200. No tiene rival para probar operaciones de seguridad y diseñar tácticas.

El OSSTMM se encuentra en su tercera versión y es una reescritura completa de la metodología original. Ahora
incluye las siempre esquivas métricas de seguridad y confianza como base. Se necesitaron siete años de
investigación y desarrollo para producir la métrica de seguridad operativa perfecta, un algoritmo que calcula la
superficie de ataque de cualquier cosa. En esencia, es una escala numérica para mostrar cuán desprotegido y
expuesto está algo en la actualidad. Los profesionales de seguridad, los estrategas militares y los investigadores
de seguridad saben que sin saber cuán expuesto está un objetivo, simplemente no es posible decir qué probabilidad
hay de que una amenaza cause daño y en qué medida. Pero para saberlo se requiere una prueba de seguridad
exhaustiva, que es exactamente lo que proporciona el OSSTMM.

Decir que OSSTMM 3 es una metodología muy completa es quedarse corto. Abarca los procedimientos de ataque
adecuados, el manejo de errores, las reglas de interacción, el análisis adecuado, el pensamiento crítico sobre
seguridad y las métricas de confianza. Proporciona 17 módulos como Auditoría de visibilidad, Verificación de
confianza, Validación de propiedades y Exploración de inteligencia competitiva, cada uno de los cuales describe
múltiples ataques (llamados Tareas), para 5 tipos de interacción diferentes con un objetivo (llamados Canales)
organizados por conocimientos técnicos y requisitos de equipo como Humanos, Físicos, Telecomunicaciones,
Redes de datos e Inalámbricos. OSSTMM se ha convertido en un organismo complejo, pero con un nuevo enfoque
en la legibilidad y la facilidad de uso, está lejos de ser complicado de usar.

La seguridad no tiene por qué durar para siempre; sólo más que
cualquier otra cosa que pueda notar su desaparición.

Certificaciones oficiales OSSTMM: [Link], [Link],

[Link], [Link], [Link]

Derechos de autor 2010, ISECOM, [Link], [Link]