TRABAJO HACKING TICO

MANUAL METODOLGICO PARA PRUEBAS DE SEGURIDAD OSSTMM 3

Y
GUA DE PRUEBAS OWASP 4.0

SI. EMILIANI SILGADO RAFAEL EDUARDO

SI. SIERRA CABALLERO YIMMY REINALDO

POLICA NACIONAL DE ESCUELAS

DIRECCIN NACIONAL DE ESCUELAS
ESCUELA DE TELEMTICA Y ELECTRNICA
ESPECIALIZACIN EN INFORMTICA FORENSE
BOGOT D.C.
2015

MANUAL METODOLGICO PARA PRUEBAS DE SEGURIDAD OSSTMM 3

El Manual de Pruebas de Metodologa Abierta de Seguridad Fuente (OSSTMM) proporciona una
metodologa para una prueba de seguridad completa, aqu referido como una auditora OSSTMM.
Una auditora OSSTMM es una medida exacta de la seguridad a nivel operativo que est libre de
hiptesis y la evidencia anecdtica. Como una metodologa est diseada para ser consistente y
repetible. Como proyecto de cdigo abierto, permite que cualquier analista de seguridad aportar
ideas para la realizacin de pruebas de seguridad ms precisos, viables y eficientes. Adems
permite la libre difusin de informacin y la propiedad intelectual.
El propsito principal de este manual es proporcionar una metodologa cientfica para la
caracterizacin precisa de la seguridad operacional (OpSec) a travs del examen y la correlacin de
los resultados de pruebas de una manera consistente y confiable. Este manual es adaptable a casi
cualquier tipo de auditora, incluyendo pruebas de penetracin, hacking tico, evaluaciones de
seguridad, evaluaciones de vulnerabilidad, de color rojo-azul-teaming, trabajo en equipo, y as
sucesivamente. Est escrito como un documento de investigacin de seguridad y est diseado
para la verificacin de seguridad de hechos y la presentacin de la mtrica a un nivel profesional.
Un segundo propsito es proporcionar directrices que, cuando se siguen correctamente,
permitirn que el analista efecte una auditora OSSTMM certificada. Existen estas directrices para
asegurar lo siguiente:
1. La prueba se llev a cabo a fondo.
2. La prueba incluy a todos los canales necesarios.
3. La postura de la prueba cumpli con la ley.
4. Los resultados son medibles de forma cuantificable.
5. Los resultados son consistentes y repetibles.
6. Los resultados contienen slo los hechos derivados de las mismas pruebas.
Un beneficio indirecto de este manual es que puede actuar como una referencia central en todas
las pruebas de seguridad, independientemente del tamao de la organizacin, la tecnologa, o
proteccin.
Para producir una prueba certificada OSSTMM que puede recibir la acreditacin para la seguridad
operacional de los objetivos, se requiere una estrella para ser firmado por el analista (s) que
realiza el examen. La estrella tambin debe cumplir con los requisitos de informacin en este
manual. El STAR puede ser sometido a ISECOM para su revisin y certificacin oficial.
Una prueba de certificado y un informe acreditado no tiene que demostrar que todo el manual o
cualquier subsecciones especficas fueron seguidos. Slo se necesita mostrar lo que era y no fue
probado para ser aplicable para la certificacin.

Una auditora OSSTMM certificado proporciona las siguientes ventajas:

1. Sirve como prueba de una prueba objetiva
2. Permanencia del analista responsable del ensayo
3. Proporciona unos resultados claros al cliente
4. Proporciona una visin ms amplia que un resumen ejecutivo
5. Proporciona mtricas comprensibles
OpSec es una combinacin de separacin y controles. Bajo OpSec, para que una amenaza sea
eficaz, debe interactuar directa o indirectamente con el activo. Para separar la amenaza del activo
y evitar posibles interacciones. Por lo tanto, es posible tener un total del (100%) de seguridad si la
amenaza y el activo estn completamente separados uno del otro. De lo contrario lo que se tiene
es la seguridad del activo que es proporcionada por los controles que pones en el activo o el grado
en que a disminuir el impacto de la amenaza.
Para entender mejor cmo OpSec puede trabajar dentro de un entorno operativo, debe reducirse
a sus elementos. Estos elementos permiten cuantificar la superficie de ataque, que es la falta de
separaciones especficas y controles funcionales que existen para cada Vector y la direccin de la
interaccin. El enfoque reduccionista nos resuelve la necesidad de ver la seguridad y la proteccin
de una forma nueva, una que permita que existan independiente del riesgo y totalmente capaz de
crear Seguridad perfecta, el equilibrio exacto de la seguridad y los controles con operaciones y
limitaciones. Sin embargo, para ver la seguridad de una manera nueva requiere nueva
terminologa tambin.
Superficie de ataque: La falta de separaciones especficas y controles funcionales que existen para
ese vector.
Vector de ataque: Un sub-mbito de un vector creado con el fin de acercarse a la pruebas de
seguridad en un mbito complejo de una manera organizada. Se basa en el divide y vencers
paradigma de diseo de algoritmo que consiste en descomponer recursivamente un problema en
dos o ms sub-problemas del mismo tipo, hasta que stos se vuelven lo suficientemente simple
como para ser resueltos directamente.
Controles: Controles de impacto y reduccin de prdidas. La garanta de que los activos fsicos y de
informacin, as como los propios canales estn protegidos de diversos tipos de interacciones no
vlidas segn lo definido por el canal. Se han definido diez controles. Los primeros cinco controles
son de clase A y son los control de interaccin, los otro cinco controles son de Clase B y son
importantes para el control de los procedimientos.

Limitaciones: Identifica el estado actual de los lmites percibidos y conocidos para los canales, las
operaciones y los controles que se han verificado en la auditora. Los tipos de limitacin se
clasifican por la forma en que interactan con la seguridad y la proteccin a nivel operativo. Por lo
tanto, las opiniones en cuanto a impacto, la disponibilidad en la naturaleza, la dificultad para llevar
a cabo, y la complejidad no se utilizan para clasificarlos.
Operaciones: Las operaciones son las necesidades de seguridad que hay que tener para ser
interactivo, til, pblico, abierto, o disponible.
Seguridad Perfecta: El equilibrio exacto de la seguridad y los controles con operaciones y
limitaciones.
Porosidad: Todos los puntos interactivos, operaciones, que se clasifican como visibilidad, acceso, o
Confianza.
Seguridad: Es una forma de proteccin donde la amenaza o sus efectos se controlan. Con el fin de
estar a salvo, los controles deben estar en su lugar para asegurar la amenaza en s o los efectos de
la amenaza se minimizan a un nivel aceptable por el propietario de los activos o gerente. Este
manual cubre la seguridad como "controles", que son los medios para mitigar los ataques en un
entorno operativo o en vivo.
Proteccin: Una forma de proteccin donde se crea una separacin entre los activos y la amenaza.
Esto incluye pero no se limita a la eliminacin de cualquiera de los activos o la amenaza. Para ser
seguro, el activo se elimina de la amenaza o la amenaza se retira del activo. Este manual cubre la
seguridad desde una perspectiva operacional, verificar las medidas de seguridad en un entorno de
operacin o en vivo.
Rav: El rav es una medida de escala de una superficie de ataque, la cantidad de interacciones no
controlados con un objetivo, que se calcula por el equilibrio cuantitativo entre porosidad,
limitaciones y controles. En esta escala, 100 rav (tambin a veces se muestra como 100% rav) es el
equilibrio perfecto y nada menos es demasiado pocos controles y, por tanto, una superficie de
ataque mayor.
Objetivo: se determina en el mbito de lo que usted est atacando, y se compone del activo y
cualquier proteccin que el activo pueda tener.
Vector: La direccin de una interaccin.
Vulnerabilidad: Una clasificacin de Limitacin en que una persona o proceso puede acceder,
negar el acceso a los dems, o se ocultan activos dentro del alcance.

Seguridad
Seguridad es una funcin de separacin. O bien la separacin entre un activo y cualquier amenaza
existe o no. Hay 3 formas lgicas y dinmicas para crear esta separacin:
1.
2.
3.

Mover el activo para crear una barrera fsica o lgica entre ella y las amenazas.
Cambiar la amenaza a una inofensiva.
Destruir la amenaza

Al analizar el estado de la seguridad podemos ver donde existe la posibilidad de interaccin y

donde no lo hay. Sabemos que algunos, todos, o incluso ninguna de estas interacciones pueden
ser necesarios para las operaciones. Al igual que las puertas en un edificio, algunas de las puertas
son necesarias para los clientes y otras para los trabajadores. Sin embargo, cada puerta es un
punto interactivo que puede aumentar tanto las operaciones necesarias y los no deseados, como
el robo.
Controles
Cuando las interacciones deben estar presentes entonces existen los controles para proveer
proteccin a las operaciones. El objetivo principal es reducir el impacto de las amenazas sobre los
activos.
Existen diez tipos de controles divididos en dos clases:

Controles de interaccin (Clase A): estos controles afectan directamente a la visibilidad,

accesos o confianza.

Controles de proceso (Clase B): se utilizan para crear procesos defensivos. No afectan a las
interacciones sino que proporcionan seguridad cuando la amenaza est presente.
Controles de interaccin

Autenticacin Se basa en el intercambio y validacin de credenciales, donde se hacen

presentes mecanismos de identificacin y autorizacin.
Indemnizacin Es un compromiso entre el propietario del activo y la parte que interacta.
Puede ser un aviso legal para el caso en que una de las partes no cumpla con las reglas
prefijadas; o puede ser un seguro contratado a terceros para el caso que se produzcan fallas o
prdidas de algn tipo.
Resistencia Es el mecanismo que brinda proteccin a los activos en caso que las interacciones
sufran alguna falla.
Subyugacin Define las condiciones en las cuales ocurrirn las interacciones. Esto quita
libertad en la forma de interaccin pero disminuye los riesgos.

Continuidad Permite mantener la interaccin con los activos an en caso de fallas.

Controles de proceso
No repudio Impide que las partes que interactan nieguen su participacin en la interaccin.
Confidencialidad Impide que la informacin que circula entre dos partes sea conocida por
terceros no autorizados.
Privacidad Evita que un tercero conozca la forma en la cual es accedido, mostrado o
intercambiado un activo.
Integridad Permite identificar cuando un activo ha sido modificado por alguien ajeno a la
interaccin en curso.
Alarma Es un aviso de que ha ocurrido un interaccin o que la misma est en curso.
Objetivos para el Aseguramiento de la Informacin
Objetivos para el aseguramiento de la informacin
Confidencialidad
Integridad
Disponibilidad

Controles
Confidencialidad, Privacidad, Autenticacin
Resistencia.
Integridad, No Repudio, Subyugacin
Continuidad, Indemnizacin, Alarma

Limitaciones
La incapacidad de un mecanismo de proteccin de funcionar como se espera de l, se conoce
como limitacin. Dicho de otra manera, las limitaciones son los inconvenientes que presentan
los controles para mantener la separacin entre los activos y las amenazas.
Es posible clasificar las limitaciones dentro de cinco categoras:
Limitaciones
Es una falla que puede permitir el acceso no autorizado a un activo o
Vulnerabilidad
puede denegar dicho acceso a alguien que s est autorizado.
Debilidad
Es una falla que reduce o anula los efectos de los controles de interaccin.
Preocupacin Es una falla que reduce los efectos de los controles de proceso.
Es una accin injustificada que permite dejar visible, ya sea de forma
Exposicin
directa o indirecta, a un activo.
Es un elemento desconocido y no se encuentra dentro de las
Anomala
operaciones normales. Por lo general es sntoma de algn fallo pero que
todava no se comprende.

Relacin de los elementos

Justificacin de las limitaciones

El concepto de que las limitaciones son slo limitaciones si no tienen justificacin de negocio es
falso. Una limitacin es una limitacin si se comporta en uno de los factores limitantes como se
describe aqu. La justificacin de un riesgo es una limitacin que se reuni con un control de algn
tipo o simplemente aceptacin de la limitacin. El riesgo es aceptar las limitaciones ya que a
menudo estas se reducen a: el dao que una limitacin puede causar un costo no justificado para
corregir o controlar la limitacin, la limitacin debe permanecer de acuerdo con la legislacin, los
contratos, o poltica, o una conclusin de que la amenaza no existe o es poco probable para esta
limitacin en particular. Dado el riesgo las justificaciones no son una parte del clculo de una
superficie de ataque, todas las limitaciones descubiertas deben ser contadas dentro de la
superficie de ataque sin importar si las mejores prcticas, la prctica comn, o prctica jurdica
indican que no se trata de un riesgo. Si no es as entonces la auditora no mostrar una verdadera
representacin de la seguridad operacional en el mbito de aplicacin.
Gestionar las limitaciones
Otro concepto que debe tomarse en consideracin es una de la gestin de fallas y errores en una
auditora. Las tres formas ms sencillas de manejar limitaciones es eliminar el rea del problema
proporcionando el punto interactivo completo, arreglarlos, o aceptarlos como parte de conocer el
negocio como la justificacin de negocio.

Una auditora a menudo busca descubrir ms de un problema por objetivo. El analista esta para
informar de las limitaciones por objetivo y no slo que son los objetivos dbiles. Estas limitaciones
pueden estar en las medidas de proteccin y controla a s mismos, lo que disminuye OpSec. Cada
limitacin debe ser clasificada como de lo que ocurre cuando se invoca el problema, incluso si esa
invocacin es terica o la verificacin de la ejecucin es limitada para restringir los daos reales.
Categorizacin terica, donde se podra hacer ninguna verificacin, es una pendiente resbaladiza y
debe limitarse a los casos en que la verificacin sera reducir la calidad de las operaciones. Luego,
al categorizar los problemas, cada limitacin debe ser examinado y se calcula en trminos
especficos de la operacin en sus componentes ms bsicos. Sin embargo, el analista debe estar
seguro antes de reportar un "defecto dentro de una falla", donde las fallas comparten el mismo
componente y el mismo efecto operativo.
Seguridad Real
El rol de los controles es reducir y manejar la porosidad. Por cada poro existen diez tipos de
controles que pueden ser aplicados y buscan llevar a la seguridad al 100%. Inclusive hay veces en
que se puede superar este porcentaje, indicando que se han aplicado controles excesivos,
aumentando los costos de manera innecesaria. Luego, las limitaciones reducen la efectividad de
los controles. El trmino seguridad real hace referencia a una instantnea de la superficie de
ataque en un ambiente operacional.
El Cumplimiento
El cumplimiento es otra cosa que la seguridad y existe independiente de seguridad. Es posible que
no sea compatible y sin embargo seguro y es posible ser relativamente seguro pero de
incumplimiento y por lo tanto de baja confiabilidad.
El gran problema con el cumplimiento se requiere una gran cantidad de documentacin que ha de
ser versionados y actualizado. Esta documentacin puede ser de los procesos de negocio, las
descripciones, la confianza las evaluaciones, las evaluaciones de riesgos, firmaron pruebas de
diseo, auditoras operacionales, certificados, etctera. Esta documentacin ser examinada por
los auditores internos y externos y lgicamente tiene que cumplir con su existencia en el mundo
de un estado de cumplimiento.
Definicin del alcance
Definir los activos que quieren protegerse.
Identificar el rea alrededor de los activos, la cual incluye los mecanismos de proteccin y los
procesos o servicios en torno a los activos. Esta es la zona de compromiso.
Definir todo aquello que se encuentre fuera de la zona de compromiso y sea necesario para
mantener operacionales a los activos. Esto incluye a la electricidad, agua, informacin, leyes,
contratos, socios, procesos, protocolos, recursos, etc. Esto es el alcance.

 Definir cmo el alcance interacta consigo mismo y con el exterior. Caracterizar la direccin de
las interacciones, es decir, de adentro hacia adentro, de adentro hacia afuera, de afuera hacia
adentro. Estos son los vectores.
Dentro de cada vector las interacciones pueden ocurrir en varios niveles o canales. Se clasifican
en: humanos, fsicos, medios inalmbricos, telecomunicaciones y redes de datos. Se deben
definir las herramientas que se necesitarn para los anlisis que se lleven a cabo en los
diferentes canales.
Se debe definir el tipo de test que se realizar. El tipo de test depende del conocimiento que se
tenga del entorno. De esta forma se pueden encontrar tres grandes categoras: black box (sin
conocimiento), gray box (conocimiento incompleto) y white box (conocimiento total).
Verificar que el anlisis se encuentra definido dentro de las reglas de compromiso asegurando
que los procesos ejecutados no generan malentendidos ni falsas expectativas.
mbito
El alcance es la total seguridad de medio ambiente para cualquier interaccin con cualquier tipo
de activos que se pueden incluir los componentes fsicos de las medidas de seguridad. El alcance
se compone de tres clases de las que hay cinco canales: las telecomunicaciones y redes de datos
seguridad Canales de la COMSEC clase, seguridad fsica y humana PHYSSEC Canales de la clase, y
toda la gama Seguridad Inalmbrica SPECSEC Canal de la clase. Las clases son de denominaciones
oficiales actualmente en uso en la industria de la seguridad, el gobierno y los militares. Las clases
se utilizan para definir el rea de estudio, investigacin, o una operacin. Sin embargo, los canales
son los medios especficos de interaccin con los activos. Un activo puede ser cualquier cosa que
tiene valor para el propietario.
Definicin de un Test de Seguridad
Definir los activos que quieren protegerse.
Identificar el rea alrededor de los activos, la cual incluye los mecanismos de proteccin y los
procesos o servicios en torno a los activos. Esta es la zona de compromiso.
Definir todo aquello que se encuentre fuera de la zona de compromiso y sea necesario para
mantener operacionales a los activos. Esto incluye a la electricidad, agua, informacin, leyes,
contratos, socios, procesos, protocolos, recursos, etc. Esto es el alcance.
Definir cmo el alcance interacta consigo mismo y con el exterior. Caracterizar la direccin de
las interacciones, es decir, de adentro hacia adentro, de adentro hacia afuera, de afuera hacia
adentro. Estos son los vectores.
Dentro de cada vector las interacciones pueden ocurrir en varios niveles o canales. Se clasifican
en: humanos, fsicos, medios inalmbricos, telecomunicaciones y redes de datos. Se deben
definir las herramientas que se necesitarn para los anlisis que se lleven a cabo en los
diferentes canales.

 Se debe definir el tipo de test que se realizar. El tipo de test depende del conocimiento que se
tenga del entorno. De esta forma se pueden encontrar tres grandes categoras: black box (sin
conocimiento), gray box (conocimiento incompleto) y white box (conocimiento total).
Verificar que el anlisis se encuentra definido dentro de las reglas de compromiso asegurando
que los procesos ejecutados no generan malentendidos ni falsas expectativas.
Canales
Clase
Seguridad Fsica

Canal
Humano

Fsica

Seguridad en el espectro

Wireless

Comunicaciones seguras

Telecomunicaciones

Redes de datos

Descripcin
Comprende
el
elemento
humano de la comunicacin
donde la interaccin es fsica o
psicolgica.
Pruebas de seguridad fsica
donde el canal es tanto fsico
como no electrnico en la
naturaleza. Comprende el
elemento
tangible
de
seguridad donde la interaccin
requiere esfuerzo fsico o un
transmisor de energa para
manipular.
Comprende
todas
las
comunicaciones electrnicas,
seales y emanaciones que
tienen lugar en el espectro EM
conocido. Esto incluye Elsec
como las comunicaciones
electrnicas, SIGSEC como
seales, y EMSEC que son
emanaciones desligadas por
cables.
Comprende todas las redes de
telecomunicaciones, digitales
o anlogas, la interaccin
toma lugar sobre los telfonos
establecidos
o
redes
telefnicas similares
Comprende todos los sistemas
y redes de datos electrnicos
donde la interaccin se lleva a
cabo a travs de cable
establecido y lneas de la red
de cable.
Redes de datos

Tipo de test ms comunes

Hay seis tipos diferentes basados en la cantidad de informacin que el analista conoce de los
objetivos, lo que el objetivo sabe acerca del analista o expectativas de la prueba, y la legitimidad
de la prueba. Algunas pruebas pondrn a prueba la habilidad del analista, ms que valorar la
seguridad de un objetivo.
Tipo
1

Descripcin
El analista se acopla al objetivo sin conocimiento previo de sus
defensas, los activos, o canales. El objetivo se prepara para la auditora,
sabiendo de antemano todos los detalles de la auditora. Una auditora
ciega prueba principalmente las habilidades del analista. La amplitud y
profundidad de una auditora ciega slo puede ser tan vasto como el
conocimiento y la eficiencia de aplicacin del Analista.
Doble
caja El analista se acopla al objetivo sin conocimiento previo de su defensa,
Negra
los activos, o canales. El objetivo no es notificado con antelacin sobre
el alcance de la auditora, los canales de prueba, o los vectores de
prueba. Una auditora de doble ciego pone a prueba las habilidades del
analista y la preparacin de la meta a las variables desconocidas de
agitacin. La amplitud y profundidad de cualquier auditora ciego slo
puede ser tan vasto como el conocimiento y la eficiencia de aplicacin
del Analista. Esto tambin se conoce como una prueba de Box Negro o
la prueba de penetracin.
Caja Gris
El analista se acopla al objetivo con un conocimiento limitado de sus
defensas y de los activos y el conocimiento cabal de los cauces. El
objetivo se prepara para la auditora, sabiendo de antemano todos los
detalles de la auditora. Una auditora de caja gris a prueba la habilidad
del analista. La naturaleza de la prueba es la eficiencia. La amplitud y
profundidad depende de la calidad de la informacin proporcionada a
la analista antes de la prueba, as como el conocimiento del Analista
aplicable. Este tipo de prueba se refiere a menudo como una prueba
de la vulnerabilidad y la mayora de las veces es iniciada por el destino
como una autoevaluacin.
Doble caja gris El analista se acopla al objetivo con un conocimiento limitado de sus
defensas y de los activos y el conocimiento cabal de los cauces. El
objetivo se informe previamente de la trama de alcance y momento de
la auditora, pero no los canales probados o los vectores de prueba.
Una doble auditora caja gris a prueba la habilidad del analista y
preparacin del objetivo a las variables desconocidas de agitacin. La
amplitud y profundidad depende de la calidad de la informacin
proporcionada a la analista y el objetivo antes de la prueba, as como el
conocimiento del Analista aplicable. Esto tambin se conoce como una
prueba de caja blanca
Tndem
El analista y el objetivo se preparan para la auditora, tanto sabiendo
de antemano todos los detalles de la auditora. Una auditora tndem
pone a prueba la proteccin y los controles de la meta. Sin embargo,
no se puede comprobar el estado de preparacin de la meta a las
Caja negra

Reverso

variables desconocidas de agitacin. La verdadera naturaleza de la

prueba es la minuciosidad que el analista tiene la vista de todas las
pruebas y sus respuestas. La amplitud y profundidad depende de la
calidad de la informacin proporcionada a la analista antes de la
prueba (transparencia), as como el conocimiento del Analista
aplicable. Esto a menudo se conoce como una auditora interna o una
prueba de la caja cristalina y el analista es a menudo parte del proceso
de seguridad.
El analista se acopla al objetivo con pleno conocimiento de sus
procesos y la seguridad operacional, pero el objetivo no sabe nada de
qu, cmo, o cuando el analista ser la prueba. La verdadera
naturaleza de esta prueba consiste en auditar el estado de preparacin
de la meta a variables desconocidas y vectores de agitacin. La
amplitud y profundidad depende de la calidad de la informacin
proporcionada a la analista y el conocimiento y la creatividad aplicable
del Analista. Esto tambin se llama a menudo un ejercicio Equipo Rojo.

Reglas de compromiso
Estas reglas definen las directrices operacionales de prcticas aceptables en la comercializacin y
venta de las pruebas, la realizacin de trabajos de ensayo, y la manipulacin de los resultados de
los trabajos de prueba.

A. Ventas y Marketing
1. El uso del miedo, la incertidumbre, la duda y el engao no puede ser utilizado en las ventas o
presentaciones de marketing, sitios web, material de apoyo, informes o anlisis de las pruebas de
seguridad con el fin de vender o proporcionar pruebas de seguridad. Esto incluye pero no se limita
a poner de relieve los crmenes, los hechos, los perfiles de criminales o de hackers glorificados, y
las estadsticas de motivar las ventas.
2. Se prohbe el ofrecimiento de servicios gratuitos en caso de no penetrar en el objetivo.
3. craqueo, la piratera, y concursos de traspaso pblico para promover la garanta de seguridad
para las ventas o comercializacin de pruebas de seguridad o de seguridad de productos, estn
prohibidos.
4. Nombre clientes pasados o presentes en la comercializacin o ventas para los clientes
potenciales slo se permite si el trabajo para el cliente era especficamente lo mismo que ser
comercializado o vendido y el cliente llamado ha dado su permiso por escrito para hacerlo.

5. Es necesario que los clientes se les aconseja veraz y objetivamente en lo que respecta a sus
medidas de seguridad y de seguridad. La ignorancia no es una excusa para consultora deshonesto.
B. Evaluacin / Estimacin Entrega
6. Realizacin de pruebas de seguridad contra cualquier mbito sin la autorizacin por escrito del
propietario de destino o autoridad correspondiente est estrictamente prohibido.
7. Las pruebas de seguridad de los sistemas, obviamente, muy inseguros e inestables, ubicaciones
y procesos est prohibida hasta la infraestructura de seguridad adecuada se ha puesto en marcha.
C. Contratos y Negociaciones
8. Con o sin un contrato de acuerdo de no divulgacin, se requiere el analista de seguridad para
garantizar la confidencialidad y no divulgacin de informacin de los clientes y resultados de las
pruebas.
9. Los contratos deben limitar la responsabilidad al coste del trabajo, a menos que la actividad
maliciosa se ha probado.
10. Los contratos deben explicar claramente los lmites y peligros de la prueba de seguridad como
parte de la declaracin de trabajo.
11. En el caso de las pruebas de control remoto, el contrato debe incluir el origen de los analistas
por direccin, nmero de telfono o la direccin IP.
12. El cliente debe proporcionar una declaracin firmada que proporciona permiso pruebas eximir
los analistas de prevaricacin en el mbito de aplicacin, y los daos de responsabilidad civil con el
costo del servicio de auditora con la excepcin donde la actividad maliciosa se ha probado.
13. Los contratos deben contener nombres de los contactos de emergencia y nmeros de
telfono.
14. El contrato debe incluir claras y permisos especficos para las pruebas que implican fallas de
supervivencia, denegacin de servicio, pruebas de proceso, y la ingeniera social.
15. Los contratos deben contener el proceso de contrato y la declaracin de trabajo (SOW) los
cambios futuros.
16. Los contratos deben contener los conflictos de intereses verificada por una prueba de
seguridad de hecho y de informe.

D. Definicin del Alcance

17. El mbito de aplicacin debe estar claramente definido contractualmente antes de verificar los
servicios vulnerables.
18. La auditora debe explicar claramente los lmites de las pruebas de seguridad de acuerdo con el
mbito de aplicacin.
E. Plan de pruebas
19. El plan de pruebas no puede contener los planes, procesos, tcnicas o procedimientos que
estn fuera del rea de experiencia o competencia de nivel del analista.
F. Proceso de Prueba
20. El analista debe respetar y mantener la seguridad, la salud, el bienestar y la intimidad de los
ciudadanos, tanto dentro como fuera del mbito de aplicacin.
21. El analista siempre debe operar dentro de la ley de la ubicacin fsica (s) de los objetivos
adems de las normas o leyes que rigen el lugar del examen del Analista.
22. Para evitar aumentos temporales en la seguridad durante la duracin de la prueba, slo
notificar a las personas clave acerca de la prueba. Es el juicio de que el cliente que discierne que
son las personas claves; Sin embargo, se supone que van a ser de la informacin y de poltica
porteros, administradores de procesos de seguridad, personal de respuesta a incidentes, y el
personal de operaciones de seguridad.
23. Si es necesario para la prueba privilegiada, el cliente debe proporcionar dos, fichas separadas,
acceso, ya sean contraseas, certificados, nmeros de identificacin segura, insignias, etc., y que
debe ser la tpica para los usuarios de los privilegios de ser probado en lugar de todo vaco o
accesos seguros.
24. Cuando la prueba incluye privilegios conocidos, el analista debe primero prueba sin privilegios
(como en un entorno cuadro negro) antes de probar de nuevo con privilegios.
Se requieren 25. Los analistas de conocer sus herramientas, donde las herramientas vienen, cmo
funcionan las herramientas, y los han probado en un rea de prueba restringida antes de usar las
herramientas de la organizacin del cliente.
26. La realizacin de pruebas de que estn destinados expresamente para probar la negacin de
un servicio o proceso, o de supervivencia slo se puede hacer con el permiso explcito y slo en el
mbito donde se hace ningn dao fuera del alcance o de la comunidad en la que reside el
alcance.

27. Las pruebas que involucran a personas slo pueden realizarse en los identificados en el alcance
y pueden no incluir los particulares, clientes, socios, asociados, u otras entidades externas sin el
permiso escrito de esas entidades.
28. limitaciones verificadas, como infracciones descubiertas, las vulnerabilidades con las tasas de
explotacin conocida o alta, las vulnerabilidades que son explotables para tener acceso completo,
sin control o imposible de encontrar, o que puedan poner en peligro inmediato la vida,
descubiertos durante las pruebas han de ser comunicados al cliente una solucin prctica tan
pronto como se encuentran.
29. Cualquier forma de prueba de inundacin en un mbito se siente abrumado de una fuente ms
grande y ms fuerte est prohibido a travs de canales no privada de propiedad.
30. El analista puede no dejar al alcance en una posicin de menor seguridad real de lo que era
cuando se les proporciona.
G. Presentacin de informes
31. El analista debe respetar la privacidad de todas las personas y mantener su privacidad para
todos los resultados.
32. Los resultados que involucran a personas sin formacin en el personal de seguridad o no de
seguridad slo pueden ser reportados a travs de medios no identifican o estadsticos.
33. El analista no puede firmar los resultados de pruebas e informes de auditora en el que no
participaron directamente.
34. Los informes deben ser objetivo y sin falsedades o cualquier malicia dirigida personalmente.
35. Se necesitarn notificaciones de cliente cada vez que el analista cambia el plan de pruebas,
cambia el lugar de la prueba de origen, tiene hallazgos de baja confianza, o que se haya producido
algn problema de prueba. Las notificaciones deben proporcionarse previa a la ejecucin de los
nuevos, peligrosos, o pruebas de alto trfico, y se requieren actualizaciones regulares de avance.
36. Cuando las soluciones y recomendaciones se incluyen en el informe, que debe ser vlido y
prctico.
37. Los informes deben marcar claramente todas las incgnitas y anomalas.
38. Los informes deben indicar claramente tanto descubierto con xito y han fracasado las
medidas de seguridad y controles de prdida.

39. Los informes deben utilizar slo las mtricas cuantitativas para medir la seguridad. Estas
mtricas deben basarse en hechos y vaco de interpretaciones subjetivas.
40. El cliente debe ser notificado cuando se enva el informe como para esperar su llegada y para
confirmar la recepcin de la entrega.
41. Todos los canales de comunicacin para la entrega del informe deben ser de extremo a
extremo confidencial.
42. Resultados e informes nunca se pueden usar para obtener ganancias comerciales ms all de
la interaccin con el cliente.
Proceso de cuatro puntos
Muchas veces se considera a la seguridad como una estrategia defensiva donde se aplican ciertas
recomendaciones y prcticas para proteger al sistema y se supone que todo se comporta como ha
sido configurado. Por lo general, esto no es as y, si bien es necesario corroborar las
configuraciones para un mejor anlisis, tambin debe probarse el sistema en funcionamiento.
Muchas son las variables que intervienen en las operaciones cotidianas, y deben ser tenidas en
cuenta al momento de decidir si todo se comporta como se espera. Es por ello que, para un
anlisis completo, se necesita evaluar la informacin que provenga de todas las fuentes posibles.
El proceso de cuatro puntos considera el anlisis del entorno, la interaccin directa, las
emanaciones del objetivo y la modificacin del ambiente, asegurando una revisin integral.

Figura 1. Proceso de cuatro puntos

1. Induccin: Estudiar el entorno donde reside el objetivo, debido a que de una manera u otra
condiciona su comportamiento y muchas veces dicho comportamiento deriva directamente de
la influencia que recibe del ambiente.
2. Interaccin: Interactuar directamente con el objetivo y observar las respuestas obtenidas.
3. Investigacin: Analizar las emanaciones que provengan del objetivo, as tambin como
cualquier pista o indicador de las emanaciones mencionadas.
4. Intervencin: Modificar los recursos del entorno que necesita el objetivo y observar cmo
responde.
Cada una de estas fases se divide en diferentes etapas que llevan el anlisis a distintos niveles de
profundidad, sin embargo ninguna de ellas es ni ms ni menos importante que la otra.
Induccin
Revisin del entorno: Conocer las normas, leyes, polticas y cultura organizacional que influyen
en los requerimientos de seguridad dentro de la empresa o institucin.
Logstica: Obtener detalles del canal de anlisis para evitar falsos positivos o falsos negativos; por
ejemplo, en el canal humano, es necesario conocer los horarios de atencin del personal, ya que
una auditora brindara resultados incompletos cuando la organizacin est en inactividad. Es
decir, en los horarios donde no hay atencin al pblico, la interaccin sera nula, y un anlisis en
ese horario no reflejara la realidad de manera completa. Por lo tanto, es necesario definir los
horarios, lugares y tipos de anlisis para lograr resultados ms precisos.
Verificacin de deteccin activa: Averiguar si existen controles que detecten intrusiones que
puedan filtrar o bloquear intentos de anlisis, obteniendo falsos negativos como resultado.
Interaccin
Auditora de visibilidad: Enumerar los objetivos visibles dentro del alcance. Conocer los puntos
donde la interaccin sera posible.
Verificacin de accesos: Determinar los puntos de acceso, la forma de interaccin y el propsito
de su existencia. En el caso del canal "redes de datos", el ejemplo ms claro es la verificacin de
puertos.
Verificacin de confianza: Verificar las relaciones de confianza entre los objetivos, donde exista
acceso a la informacin sin necesidad de autenticacin.
Verificacin de controles: Verificar la efectividad de controles de proceso (clase B): no repudio,
confidencialidad, privacidad e integridad; el control de alarma se verifica al final de esta
metodologa.

Investigacin
Verificacin de procesos: Comprobar el mantenimiento y efectividad de los niveles de seguridad
en los procesos establecidos. Adems se debe verificar el cumplimiento de las normas, leyes,
regulaciones y polticas que se investigaron en el primer punto.
Verificacin de la configuracin: Revisar el funcionamiento de los procesos en condiciones
normales, para identificar cul es su objetivo y as comprender la justificacin de negocio de esa
pieza de informacin.
Validacin de propiedad: Revisar la procedencia de los datos, informacin, sistemas, etc., con el
fin de identificar falsificaciones, fraudes, faltas de licencias o violaciones a los derechos de autor.
Revisin de segregacin: Revisar los controles que aseguran separacin entre la informacin
personal y organizacional. ste es un punto focal dentro de la tica y la legalidad en el
almacenamiento y transmisin de los datos.
Verificacin de exposicin: Buscar informacin, disponible de manera abierta, que permita
conocer detalles del objetivo. Normalmente se puede obtener una gran cantidad de informacin
en las redes sociales, buscadores, folletos impresos, entre otros, que permite armar un perfil de la
organizacin y que puede ser de vital importancia en las futuras etapas del anlisis.
Exploracin de inteligencia de negocios: Verificar la existencia de fuentes de informacin que
contengan datos de negocio que debieran ser confidenciales y que, en caso de ser revelados,
puedan brindar ventajas competitivas a otras organizaciones.
Intervencin
Verificacin de cuarentena: Verificar la efectiva separacin de elementos hostiles. Un ejemplo
sencillo de esta etapa es cuando una pieza de software no se comporta dentro de los patrones
permitidos, y es aislada para evitar afectar a otros sistemas.
Auditora de privilegios: Analizar el correcto uso de los sistemas de autenticacin y autorizacin.
Analizar la posibilidad de ingresos no autorizados y escaladas de privilegios.
Continuidad de negocio: Analizar la efectividad de los controles de resistencia y continuidad.
Esto puede ser realizado mediante intentos de denegacin de servicio o denegacin de
interacciones.
Alerta y revisin de logs: Verificar la correctitud en la relacin entre las actividades realizadas y
los registros almacenados. Adems se deben verificar los mecanismos que proporcionan una
forma de alarma ante eventos no deseados.
La tripleta
Esta prueba de seguridad metodologa tiene una base slida que puede parecer un poco
complicado, pero en realidad es fcil en la prctica. Est diseado como un diagrama de flujo; sin
embargo, a diferencia del estndar diagrama de flujo, el flujo representado por las flechas, puede
ir hacia atrs y hacia delante. De esta manera, es ms integrado y si bien el comienzo y el final son
claros, la auditora tiene una mayor flexibilidad. El analista crea una ruta de acceso nica a travs
de una metodologa basada en el destino, el tipo de prueba, el tiempo asignado a la auditora, y
los recursos destinados a la prueba. Para una orquesta, el compositor escribe la partitura para

designar el orden y la duracin de las notas, pero slo el conductor puede controlar la ejecucin
de la actuacin. Esta metodologa es como la msica, para designar las pruebas necesarias, pero el
analista controla el orden, la duracin, as como la ejecucin. La principal razn para exigir que
este nivel de flexibilidad en el abierto OSSTMM (OPEN SOURCE SECURITY Testing Methodology
metodologa es porque no puede presumir con precisin las justificaciones de las operaciones del
canal los gateways de la meta y su adecuado nivel de seguridad.
Aplicando esta metodologa, por lo tanto, cumplen la meta del analista para responder a las
siguientes tres preguntas que conforman la tripleta, OpSec la respuesta a las necesidades.
1. Cmo son las operaciones actuales?
Las mediciones pueden ser aplicadas para determinar las reas de los problemas en el mbito y
que deben abordarse los problemas. El sistema de medicin de esta metodologa se ha diseado
para asignar los problemas de diferentes maneras, de modo que se pongan de manifiesto si el
problema es un problema general o ms especfico, como un mirador o un error.
2. Cmo funcionan de manera diferente de cmo piensa que deben trabajar?
Acceso a las polticas o de un fideicomiso (o incluso un riesgo) evaluacin se asignan a las
diferentes categoras de los sistemas de medicin. Las categoras proporcionan el estado actual los
valores en los que se pueden efectuar comparaciones tanto con un estado ptimo de acuerdo con
las polticas y una en funcin de las amenazas.
3. Cmo tienen que trabajar?
Que las medidas no muestran diferencias entre poltica o confianza (o riesgo) evaluacin del valor
ptimo sin embargo, la prueba de seguridad muestra que, de hecho, hay un problema de
proteccin independientemente de los controles como en poltica, es posible que claramente
denoten un problema. A menudo, incluso sin asignacin a la poltica, la discrepancia entre los
controles implementados y la prdida de la proteccin es sencillamente evidente.
Combinando la tripleta y el Proceso 4 puntos
La Tripleta combinada con los cuatro puntos proporciona una aplicacin cabal de esta
metodologa. Los pasos de esta aplicacin se pueden resumir de la siguiente manera:
1. Recopilar los datos de forma pasiva las operaciones normales para comprender el destino.
2. Activamente las operaciones de prueba agitando las operaciones ms all de las normales de
referencia.
3. Analizar los datos recibidos directamente de las operaciones.
4. Analizar los datos indirectos de los recursos y los operadores (es decir, los trabajadores,
programas).
5. Correlacin entre inteligencia y conciliar de directa (paso 3) e indirectas (paso 4) datos
resultados de la prueba para determinar los procesos operacionales de seguridad.
6. Determinar y reconciliar los errores.

7. Ambos derivan de las mediciones las operaciones normales y agitadas.

8. Correlacin entre inteligencia y conciliar entre normal y agitado (pasos 1 y 2) operaciones para
determinar el nivel ptimo de proteccin y control que se aplicara mejor.
9. Mapa del estado ptimo de las operaciones (paso 8) en los procesos (paso 5).
10 Crear un anlisis de diferencias para determinar qu mejoras son necesarias para los procesos
de proteccin necesaria y en el de control (paso 5) para alcanzar el ptimo estado de
funcionamiento (paso 8) de la actual.

Gestin de errores
La veracidad de una prueba de seguridad no se encuentra en la suma de sus errores, sino en la
contabilidad de sus errores. Ya que los errores no pueden ser el fallo de la analista, la comprensin
de cmo y donde los errores pueden existir dentro de un test es mucho ms razonable que se
espera un analista para probar sin errores. Por otra parte, es el analista que intenta lo que no
debera ser posible que es ms probable que encuentre errores; por lo tanto, lo cual denota que
los errores como una cosa negativa descuentos la prctica de pruebas exhaustivas.
Tipo de Error
1
Falso positivo

Falso negativo

Descripcin
Algo determinado como verdadero es en realidad revela falso.
La respuesta objetivo indica un estado en particular como
verdadero aunque en realidad el estado no es cierto. Un falso
positivo se produce a menudo cuando las expectativas de los
analistas o suposiciones de lo que indica un estado en
particular no espera a las condiciones del mundo real que rara
vez son blanco y negro.
Algo determinado, es en realidad falsa revel como verdadero.
La respuesta objetivo indica un estado en particular, no es
cierto aunque en realidad el estado es cierto. Un falso negativo
se produce a menudo cuando las expectativas de los analistas
o presunciones acerca de la meta no se mantienen en las

Positivo gris

Negativo Color Gris

Specter

Indiscrecin

Entropa Error

condiciones del mundo real, las herramientas no son

suficientes para la prueba, las herramientas se emplean mal, o
el analista carece de experiencia. Un falso negativo puede ser
peligroso ya que es un diagnstico incorrecto de un estado
seguro cuando no existe.
Algo respuestas verdaderas a todo, incluso si es falso.
El objetivo de respuesta indica un estado en particular, cierto,
sin embargo, la meta est diseado para responder a cualquier
causa de este estado si es verdad o no. Este tipo de seguridad a
travs de la oscuridad puede ser peligrosa, ya que la ilusin no
se garantiza que funcione el mismo para todos.
Respuesta algo falsa para todo, incluso si es verdadero.
El objetivo de respuesta indica un estado en particular, no es
cierto, sin embargo el objetivo est diseado para responder a
cualquier causa de este estado si es verdad o no. Este tipo de
seguridad a travs de la oscuridad puede ser peligrosa, ya que
la ilusin no se garantiza que funcione el mismo para todos.
Algo las respuestas verdaderas o falsas, pero la situacin real
es revelado como desconocido. La respuesta objetivo indica un
estado como verdadero o falso a pesar de que en realidad el
estado no puede ser conocido. Un espectro a menudo se
produce cuando el analista recibe una respuesta de un
estmulo externo que se percibe como de la meta. UN
fantasma puede ser intencional, una anomala desde dentro
del canal, o el resultado de negligencia o impericia de la
analista. Uno de los problemas ms comunes en el proceso eco
es el supuesto de que la respuesta es el resultado de la prueba.
Causa y efecto las pruebas en el mundo real no puede obtener
siempre resultados fiables ya que ni la causa ni el efecto puede
ser debidamente aislados.
Algo respuestas verdaderas o falsas en funcin a la pregunta.
El objetivo de respuesta indica un estado en particular como
verdaderas o falsas, pero slo durante un tiempo determinado,
que puede o no seguir un patrn. Si la respuesta no puede ser
verificada en un momento en que el estado los cambios, es
posible que se impida que el analista de comprender al otro
estado. El analista tambin puede determinar que se trata de
una anomala o un problema con el equipo de prueba,
especialmente si el analista no se pudo calibrar el equipo antes
de la prueba logstica apropiada y controles. Una indiscrecin
puede ser peligrosa ya que puede dar lugar a una falsa
presentacin de informes sobre el estado de la seguridad.
La respuesta es prdida o confusin en ruido de la seal.
La respuesta no puede indicar con precisin el estado como
verdadero o falso debido a una alta relacin seal a ruido.
Similar a la idea de la prdida de un haz de luz del sol, el
analista puede determinar correctamente hasta que el ruido se
reduce. Este tipo de medio ambiente causado error rara vez

Falsificacin

Error de muestreo

Restriccin

Propagacin

Error humano

existe en un laboratorio, sin embargo, es un hecho normal en

un entorno no controlado. La entropa puede ser peligrosa, si
sus efectos no pueden ser contrarrestados.
La respuesta cambia dependiendo de cmo y dnde se ha
hecho la pregunta.
La respuesta objetivo indica un estado como verdadero o falso
a pesar de que en realidad el estado depende de variables
desconocidas en gran medida debido a prejuicios. Este tipo de
seguridad a travs de la oscuridad puede ser peligrosa, ya que
la tendencia cambiar cuando las pruebas vienen de diferentes
vectores o emplear tcnicas diferentes. Tambin es probable
que el destino no sea consciente de la parcialidad.
La respuesta no puede representar al conjunto debido a que el
alcance se ha modificado.
El objetivo es una muestra sesgada de un sistema ms grande o
un mayor nmero de estados posibles. Este error normalmente
se produce cuando una autoridad influye en el estado de
funcionamiento de la meta para la duracin de la prueba. Esto
puede ser a travs de determinadas limitaciones de tiempo en
la prueba o un sesgo de prueba slo los componentes
designados como "importante" dentro de un sistema. Este tipo
de error se producir una tergiversacin de la seguridad
operacional.
La respuesta vara en funcin de las limitaciones de las
herramientas que se utilizan.
Las limitaciones de los sentidos o capacidades de los equipos
indican un estado determinado como verdadero o falso a pesar
de que el estado actual es desconocido. Este error no se debe a
un mal juicio u opciones equipo equivocado sino que es la
incapacidad para reconocer las limitaciones que se han
impuesto o limitaciones.
La respuesta se supone que es de un estado o de la otra,
aunque no hay ninguna prueba.
El analista no hacer una prueba en particular o tiene una
tendencia a ignorar un resultado determinado debido a un
supuesto resultado. Esto es a menudo un deslumbrante de la
experiencia o sesgo de confirmacin. La prueba se puede
repetir muchas veces o las herramientas y el equipo podrn ser
modificados para tener los resultados deseados. Como su
nombre indica, un proceso que no reciben informacin sobre
los errores siguen siendo desconocidos o ignorados se
propagan ms errores como los ensayos. Errores de
propagacin puede ser peligroso porque los errores
propagados desde temprano en las pruebas pueden no ser
visibles durante un anlisis de conclusiones. Por otra parte, un
estudio de todo el proceso de prueba es necesario para
descubrir errores de propagacin.
La respuesta vara en funcin de la habilidad del analista.

Un error provocado por la falta de capacidad, experiencia, o la

comprensin no es uno de los prejuicios y es siempre un factor
que est presente, independientemente de la metodologa o
tcnica. Mientras que un experimentado Analista puede hacer
errores de propagacin, uno sin experiencia es ms probable
de no reconocer errores humanos, algo que la experiencia nos
ensea a reconocer y compensar. Estadsticamente, hay una
relacin indirecta entre la experiencia y los errores humanos.
La menor experiencia un analista tiene, cuanto mayor sea la
cantidad de errores humanos una auditora puede contener.
Trabajar con errores de la prueba
Durante la fase de anlisis, el analista puede hacer un seguimiento de la cantidad y la gravedad de
la operacin los errores de la prueba. Una auto-evaluacin sencilla puede crear un margen de
errores de operacin durante el examen en el que el analista puede utilizar para cualquier trama la
minuciosidad del actual de la auditora o de otros controles de sistemas similares.
Ya que es un auto evaluacin, tendr una tendencia a estar sesgados. El analista debe tener
mucho cuidado para que sea lo ms objetivos posible, como una forma de garanta de la calidad
de la prueba y el proceso de prueba. A pesar de que algunos pueden tratar de descartar errores de
la prueba que se encontraban en el fallo del analista, el seguimiento de todos los errores slo
puede mejorar en el futuro las pruebas y no es algo que ocultar. Errores va a suceder y no son ms
que el intento del analista a interactuar con un sistema de cambio. Independientemente del
nmero y la gravedad de los errores, el seguimiento de errores de la prueba servir como un
registro de las dificultades y la complejidad de la auditora y la competencia del analista para
deducir los errores.
Un registro de errores de la prueba desde el mbito tambin le ayudar a resumir el medio
ambiente de una manera simplista. Se trata de un directo con reduccin del Resumen Ejecutivo
que a menudo se describe la opinin del analista sobre el estado de la seguridad en donde unos
pocos errores no mostrarn un destino bastante esttico y el medio ambiente. Muchos errores
muestran un entorno catico y uno que puede faltar controles para gestionar el cambio o la
prdida.
En general, prueba de registros son tiles para entender la complejidad de la auditora y control de
cambios entre las auditoras de regularidad.
Resultados de la prueba
A menudo acompaada de soluciones recomendadas o se ofrece consultoras, ninguna de los
cuales es necesaria en una auditora. Las soluciones recomendadas se pueden proporcionar como
un valor aadido a una prueba de seguridad pero no se considera obligatorio. A menudo no hay

soluciones adecuadas en funcin de la limitada visin un analista tiene del entorno del cliente. Por
lo tanto, las soluciones no son necesarias como parte de una auditora.
Con frecuencia, la prueba supera los lmites de un control de seguridad. En el combate, el analista
debe informar de los hechos siempre estado actual de la seguridad, las limitaciones dentro de ese
estado actual y cualquier de los procesos que causaron los lmites de la aplica controles y
protecciones.
Para medir tanto el rigor de la prueba y la proteccin de la poblacin, el uso de esta metodologa
debe concluir con la prueba de seguridad Informe de Auditora, disponible en este manual o en el
sitio web ISECOM. STAR requiere la informacin siguiente:
1. Fecha y hora de la prueba
2. Duracin de la prueba
3. Los nombres de los analistas responsables
4. Tipo de prueba
5. Alcance de la prueba
6. ndice (mtodo de enumeracin)
7. Canal probado
8. Vectores de Prueba
9. Superficie de Ataque sistema mtrico
10. Que las pruebas se han completado, no se ha completado, o parcialmente completado, y en
qu medida
11. Las cuestiones relativas a la prueba y la validez de los resultados
12. Todos los procesos que influyen en las limitaciones de seguridad
13. Las incgnitas o anomalas
El xito en el uso del OSSTMM muestra una medicin real de la seguridad y los controles. Algunas
tergiversaciones de los resultados de los informes pueden dar lugar a fraudes verificacin de los
controles de seguridad, y un nivel de seguridad inexacta. Para ello, el analista debe aceptar la
responsabilidad y la responsabilidad limitada de informacin inexacta.
Divulgacin
Durante una prueba de seguridad la llegada de desconocidas anteriormente o no publicidad
limitaciones de seguridad puede salir a la luz. Qu es un analista con estos es, ante todo, un
resultado de las regulaciones legales del analista de la regin y de la regin en que se realiza el
trabajo.

Divulgacin derechos
Lo que tienes que hacer es asegurarse de que el acceso y el uso del producto o la solucin no
requieren de ningn tipo de disposiciones, confidencialidad contrato, o Acuerdo de Licencia de
Usuario Final (EULA) que le niega el derecho a reclamar, anunciar o distribuir cualquier

vulnerabilidad descubierta. Si lo hizo, y que usted o el cliente acepta este contrato, no se puede
revelar a nadie, tal vez incluso del fabricante, sin posibles repercusiones legales. Adems, si usted
trabaja para la empresa de ese producto o son un cliente de ellos, a continuacin, puede que no
sea capaz de revelar nada legalmente. Por otra parte, de sus derechos en cualquier caso pueden
ser impugnadas, de conformidad con el proceso de la ley en la regin, en lugar de los precedentes
legales.

Responsabilidades
Sin embargo, si esos casos no aplicar y, a continuacin te propio que la vulnerabilidad, y la tarde se
har pblico el ms derechos que tienen como su propietario. En muchos pases, los procesos y la
informacin puede ser protegido por la ley y a menudo un proceso legal exige la publicacin o
legalmente presentar tal atribucin. Si su divulgacin puede hacer ningn dao fsico (como gritar
fuego en una concurrida sala de cine), es tuyo para hacer poses y no jurdicas deben agitar cuando
usted est en lo correcto. Sin embargo, para que sea ms seguro, tambin debe promover, con la
vulnerabilidad de la que se ha informado, los controles que se pueden aplicar para solucionar el
problema. Por ejemplo, si se trata de un problema de cmo se autentica con una solucin, a
continuacin, sugerir una alternativa esquema de autenticacin y cmo puede integrarse con
xito. No es necesario que espere a que el fabricante para liberar una solucin o una retirada del
mercado para dejar que la gente corrija el problema. No obstante, en el caso de que elija para
trabajar en el contexto de la notificacin del fabricante, usted tendr que darles tiempo suficiente
para abordar el problema antes de publicarlo. No es un argumento vlido que la vulnerabilidad ya
puede ser conocida en crculos criminales y requieren atencin inmediata. Por lo tanto, deben
elegir a publicar, sin la asistencia del fabricante, tenga en cuenta que incluso una solucin tambin
muestran que legalmente le tena buenas intenciones y mucho del sistema jurdico se centra en las
intenciones.
Su eleccin depende de si se aceptan las demandas frvolas o frecuentes en su regin. Recuerde
que no es usted el analista que se requiere para realizar las pruebas de control de calidad para el
fabricante por lo tanto, no les debemos toda la informacin del trabajo que ha hecho incluso si se
incluye su producto.
Toda la informacin es til en la medida en que puede hacer ningn ser humano, dao fsico. Por
otra parte, los consumidores no deberan tener que esperar el fabricante fija para sus productos
para estar seguro. Si el producto no se vende como una solucin especfica, a continuacin,
seguridad de los consumidores para que sea seguro, o no. Si se vende como seguro y sin riesgos, a
continuacin, corresponde al fabricante para que lo arregle sin embargo, el consumidor no podr
esperar hasta que el fabricante puede hacerlo. Toda la informacin de esta eleccin.

Pensamiento Crtico de seguridad

Pensamiento Crtico de seguridad tal como se utiliza aqu es un trmino que se utiliza para la
prctica del uso de la lgica y los hechos para formar una idea acerca de la seguridad. Esa idea
puede ser una respuesta, una conclusin o una caracterizacin de algo o de alguien para que las
pruebas de verificacin se puedan definir bien. Como una respuesta o una conclusin crtica de
seguridad, pensando que lo que tiene ms sentido. Como caracterizacin, se mostrar lo que
usted necesita para comprobar, de acuerdo con lo que usted necesita para comprobar, segn lo
que vector, cmo y cules son los objetivos. Tambin le ayudar a respetar las diferentes
opiniones y puntos ms all de la seguridad propia seguridad a la interconexin con las personas,
los lugares, los procesos y el dinero. Esto le ayudar a abordar conclusiones contradictorias y
explorar alternativas consecuencias. Por lo que, incluso si el pensamiento crtico de seguridad
modelo no se puede dar una respuesta que le indicar qu hechos han desaparecido y de donde
se necesita llegar a ellos.
El proceso de pensamiento crtico de seguridad depende de la analista ha podido discernir
afirmaciones verdaderas o por lo menos reconocer el grado de posible falsedad o propiedades
dinmicas en un comunicado. Una forma de hacerlo es reconocer la cantidad de confianza que
puede tener en un hecho mediante el uso de mtricas. Otra forma es la de ser capaces de
construir una declaracin, separando argumentos falaces. En la prctica, un analista tendr que
hacer las dos cosas. El analista tendr que tener un buen entendimiento de lo que se est
analizando y una buena comprensin de falacias lgicas utilizadas para los calificadores, falaces
afirmaciones basadas en conceptos por lo general en forma de axiomas o mejores prcticas.
La tcnica de anlisis seis Paso
Por desgracia, el mundo no es preceptivo. No cada pregunta tiene una respuesta correcta. La
exactitud de la respuesta depende de muchas cosas entre ellas, lo que es ms importante, la
forma en que se le pide. Este es un problema que afecta a todas las industrias, pero ninguno tan
obviamente como la seguridad que es la razn por pensamiento crtico de seguridad es tan
importante. Como una tcnica de anlisis, puede ser reducido a 6 pasos simples para determinar
resultados con un alto nivel de confianza de correcta incluso cuando las soluciones no son lineales
como cuando no hay conexin del punto A al punto B. Por lo tanto, la capacidad de validar las
fuentes y medir confianza es crucial para la adecuada, inteligencia de las pruebas. En estos pasos,
"objetivo" se refiere a cualquier cosa que est analizando en la preparacin de un examen, ya sea
personas, equipos, edificios, o de los procesos.
1. Construir su conocimiento del objetivo a partir de una variedad de los ms contemporneos, los
recursos y evitar hechos comercialmente informacin sesgada y especulativa.
2. Determinar el nivel global de la experiencia en el tipo de destino y la cantidad de informacin
posible sobre ella.
3. Determinar el sesgo o segundas intenciones en las fuentes de informacin.

4. Traduzca la terminologa de fuentes de informacin similar o palabras conocidas de

comparacin porque lo que puede parecer nuevo o complicado puede ser simplemente un truco
para distinguir algo en comn.
5. Asegrese de que el equipo de prueba se ha calibrado correctamente y el entorno de pruebas
verificadas para asegurar los resultados no estn contaminados por la prueba en s misma.
6. Asegurarse de que la traduccin de estado de herramientas o procesos de prueba ha sido
eliminado, en la medida de lo posible, de manera que los resultados no vienen de las fuentes
indirectas en el proceso o el anlisis previo de algunas herramientas.
Buscar coincidencias de patrn como un signo de errores
Si usted comienza a buscar exactamente lo que usted busca, solamente puede encontrar lo que
usted espera encontrar. Esto es adecuado para la bsqueda de calcetines pero no tan bueno
cuando se mira en la imagen grande de la superficie de ataque. Es el problema ms grave conocido
como coincidencia de patrones, el rasgo humano para saltar por encima de los escalones, a veces
sin saberlo, lo que se considera innecesario debido a la "evidente" resultados. Tambin hace que
la gente ver, causa y efecto en el que puede haber ninguno. Es un punto ciego que los analistas se
producirn despus de aos haciendo inicial, bsico o las tareas redundantes. Estas tareas se han
hecho ms eficientes a travs de los accesos directos que afectan a la calidad de las pruebas de
verificacin y en ltima instancia el anlisis.
De informacin procesable, el resultado es tan bueno como los mtodos utilizados para llegar a
ellos. No saber cmo se obtuvo un resultado concreto se limitan en gran medida la accin que
puede tomar para solucionar el problema. Cuando un analista utiliza coincidencia de patrn para
saltarse los pasos, el mtodo no puede ser bien conocido. Aun as, el deseo de "cut to the chase"
para llegar a la carne de un problema al suponer un estado que se conoce es un problema en
muchas reas de la ciencia. Seguridad no es una excepcin. Por tanto, el analista debe reconocer
cuando las pruebas se han omitido datos o la dejamos para proporcionar resultados no
verificados.
Para detectar patrones, examinar los mtodos de prueba y resultado, los datos de los siguientes:
1. Las pruebas de amenazas especficas en lugar de una profunda interaccin con la superficie de
ataque.
2. La falta de detalles en los procesos resultantes de las interacciones con el objetivo.
3. Poca o ninguna informacin acerca de los controles para diversos objetivos.
4. Slo algunos de los objetivos se informa de ciertas pruebas y completamente los resultados
negativos.
5. Los objetivos no se ha probado por razones que son anecdticos (notas cuando una persona ha
dicho no hay nada que probar o ha sido asegurado).
6. Pruebas de objetivos que obviamente no han sido asegurados.

Caracterizar los resultados

El mtodo cientfico no es una lista de comprobacin. Se trata de un proceso que permite para la
inteligencia y la imaginacin. Una hiptesis es hecha y, a continuacin, los datos se recopilan
mediante la realizacin de ensayos y la observacin para evaluar esa hiptesis. En una prueba de
seguridad, una hiptesis es esencialmente siempre que la verificacin se realiza contra una
interactiva directa o indirecta en el mbito de aplicacin. El analista tiene los datos empricos de
las pruebas y debe considerar si los exmenes que se verifica la hiptesis. Las pruebas fueron el
derecho? Fueron suficientes pruebas? Fueron los canales adecuados o vectores probados? Se han
creado nuevas interacciones que tambin se someti a prueba? Para ello, se caracterizan los
resultados.
Buscar signos de la intuicin
Una cosa es que las mquinas son mucho mejores que en los seres humanos es la coherencia. Los
seres humanos generalmente se aburren, confusos o descuidado. Cuando una mquina de
monedas, no perder la cuenta y la necesidad de empezar de nuevo. No cabe duda, y empezar de
nuevo. Tambin no utilizar la intuicin. Tambin llamado "instinto" el poder de la intuicin es
increble. Que permite a las personas a imaginar, aplicar creatividad a un trabajo, y saber cundo
algo est mal. Es parte de la condicin humana que subconscientemente detectar problemas y
actuar en consecuencia. No obstante que es exactamente esto lo que a veces nos lleva a cometer
errores. Esto nunca es ms evidente que cuando contamos grandes cantidades de objetos
parecidos. Sin la total concentracin, podemos comenzar a sentir incmodos por el cmputo y
finalmente nos pueden sentirse obligados a empezar de nuevo o simplemente aceptar un
determinado nmero de sonido correcto donde pensamos que dej y continuar desde all.
Signos de que hay problemas de intuicin en las pruebas son:
1. Las incoherencias de los tipos de pruebas que se realizan a travs de mltiples y objetivos
similares.
2. El nmero de pruebas disminucin entre los objetivos.
3. La duracin del tiempo de pruebas disminucin entre los objetivos.
4. El mismo destino probado ms de una vez con las mismas pruebas.
Informacin Transparente
En raras ocasiones un anlisis de seguridad final con todas las respuestas. Desde las pruebas
depender del OpSec y de los controles de un determinado canal y vector se incgnitas. No puede
ser un objetivo visible que no proporciona interaccin y no hay ms informacin sobre este
destino puede ser determinado a partir de este vector y este canal. Esto es correcto. El analista
debe informar de lo que se ha encontrado con certeza y no simplemente lo que podra ser. No hay
lugar para adivinar cundo medir la superficie de ataque.

Adems de la informacin de la prueba en s misma de cmo se hizo, el analista tendr que

informe los siguientes 7 resultados de la prueba:
Desconocidos
Como ms vectores y los canales son analizados, se dispondr de ms informacin y que, segn se
inform que va a cambiar y proporcionar informacin procesable. Por otra parte, y quiz ms
resultados no son concluyentes o la correlacin de resultados proporciona respuestas
contradictorias, la inteligencia es desconocida. Desconocido es una respuesta vlida para informe.
Lo que no se puede conocer es tan vlida y tan importante en la seguridad como lo que se
descubre. Muestra lo que se desconoce lo que es difcil de probar o analizar. El desconocido no
debe verse como un fracaso de la prueba sino que puede ser causada por una mayor proteccin o
un ataque que utiliza un gran coste de tiempo o de recursos no es posible en una prueba. Analista
no debe temer los informes algo es desconocido. Se trata de una potente base de anlisis de
riesgo.
Objetivos no probados
Adems, el analista debe informar sobre otro tipo de desconocidos: los objetivos en el mbito de
aplicacin, que no han sido probadas en un vector particular o canal. Si una prueba no se puede
completar debido a las limitaciones de tiempo, las limitaciones, las metas es inestable, el entorno
de prueba es demasiado dinmica o demasiado ruidosa para recoger resultados adecuados, o
porque las pruebas no fueron buscados por el propietario, este objetivo debe conocer. Por lo que
no se ha probado, es posible realizar comparaciones con adecuados de prueba pruebas futuras.
Tambin ayudar a evitar engaos por slo probar el bien protegido de un alcance y
desconociendo el resto para crear la ilusin de una pequea superficie de ataque.
Identificado y verificado Las Limitaciones
Adems, el analista debe tambin informar de cualquier identificado y verificado las limitaciones
como las vulnerabilidades de los objetivos. Una limitacin es uno que se ha determinado a travs
del conocimiento y la correlacin. Esto es til cuando las pruebas son peligrosas o muy costoso.
Algunas veces, un examen puede ser perjudicial para un destino o causa penal inaceptable o
incluso daos colaterales. Una limitacin es donde el problema se ha sometido a pruebas
especficas para determinar si existe.
Falsos positivos y los medios para generar
Durante las pruebas, algunas limitaciones que se han identificado no sern vulnerables a los
ataques durante la verificacin. Esto, sin embargo no concluye que el objetivo no tiene esas
limitaciones. Slo quiere decir que prueba en particular en ese momento en particular y a partir de
ese particular probador no exponer la vulnerabilidad identificada. Tambin podra significar el
objetivo es vulnerable pero est protegido por un determinado control. Esos determinados falsos
positivos deben ser reportados por lo que, en un mayor desarrollo de las tcnicas de proteccin y
defensa, el problema puede ser visto ms estrechamente, en particular de otro vector.

No los procesos de seguridad y procedimientos

Durante el anlisis, los resultados de la prueba se muestran ms que la OPSEC, tipos de controles,
y el nmero de limitaciones. Se mostrar una imagen mayor, uno de los procesos y
procedimientos que se utilizan para formalizar las medidas de proteccin. Estos pueden ser sobre
cualquier cosa que se han diseado para obtener las medidas de proteccin a su estado actual.
Esto incluye, pero no se limita a mantenimiento, adquisiciones, identificacin, autorizacin, orden
y limpieza, recuperacin de desastres, las relaciones con los asociados, la poltica de generacin,
control de clima y recursos humanos. Cuando un objeto tiene una limitacin a veces es un proceso
que ha fallado o procedimiento. El analista debe ser capaz de determinar exactamente lo que es la
suma de los resultados de la prueba.
Buenas prcticas
El trmino "Mejores Prcticas" se utiliza para explicar la mejor forma para que una persona o una
organizacin para hacer algo. Por desgracia, esto ha sido objeto de abuso por lo que en la
actualidad significa que es mejor para todos. Este mismo ha causado problemas y la prdida de
recursos. Una forma de contrarrestar este problema es utilizar el total de los resultados de las
pruebas muestran que las prcticas se realizan con xito. Esto mostrar lo que se puede repetir el
xito de equivalente en otras reas de la organizacin y la definicin de "Mejores Prcticas" para
ellos. Tambin disminuir su dependencia en mejores prcticas en favor de lo que funciona mejor
para ellos.
Cumplimiento
Objetivos de cumplimiento especfica hay que llegar, el analista debe utilizar la correlacin entre
los resultados de la prueba para determinar si se han cumplido dichos objetivos. Este puede que
sea necesario proporcionar en un formato especial que determine el auditor sin embargo el
Analista est mejor equipado para mostrar que los resultados de las pruebas proporcionan la
informacin necesaria.
Estadsticas de Seguridad Operacional
La realizacin de una exhaustiva prueba de seguridad tiene la ventaja de proporcionar indicadores
precisos sobre el estado de la seguridad. Al igual que con el uso de cualquier sistema mtrico; Por
lo tanto, una seguridad de xito mtrica requiere una prueba que puede ser descrito como
medicin de la correspondiente contabilidad mientras que los vectores de las inexactitudes y
tergiversaciones de la recogida de datos, as como de las competencias o la experiencia de los
profesionales de la seguridad de la prueba. Los fallos de estas exigencias son resultado de las
mediciones de la calidad inferior y por lo tanto falsa seguridad las determinaciones la mtrica debe
tambin ser lo suficientemente simple para utilizar sin que esto sea tan simple que dice nada.
Conocer el RAV
El rav es una escala de medicin de la superficie de ataque, la cantidad de interacciones no
controlados con un objetivo, que es calculado por el equilibrio cuantitativo entre las operaciones,
limitaciones y controles.

El RAV no medir el riesgo de un ataque, sino que permite la medicin de la misma. No puede decir
si un objetivo concreto ser atacado sin embargo se puede decir que en una meta que ser
atacado, qu tipo de ataques el objetivo puede defender exitosamente contra, cmo un atacante
puede obtener y cunto dao se puede hacer. Con esa informacin a continuacin, es posible
evaluar la confianza (y los riesgos) mucho ms precisa.
Ocho respuestas fundamentales en materia de seguridad
El rav no representa riesgo cuando el riesgo es conocido como Riesgo = Amenaza x vulnerabilidad
x activo. En esta ecuacin, el riesgo es el resultado de un conocimiento muy parcial, sin embargo,
la ecuacin. Si podemos eliminar la mayor parte de la parcialidad de conocer el nivel de proteccin
y por lo tanto el nivel de consecuencias de la vulnerabilidad, podemos reducir el sesgo en la
ecuacin y darle una mejor evaluacin del riesgo. Por lo tanto, el rav es, en realidad, el
fundamento fctico para una evaluacin del riesgo de un analista ha hechos con los que se va a
trabajar. El verdadero poder del rav sin embargo es la manera en que puede proporcionar
respuestas a las siguientes preguntas fundamentales de seguridad ocho con gran precisin.
Cunto dinero se debe invertir en seguridad?
El rav se mostrar la cantidad actual de la proteccin de seguridad y definir los hitos las
proyecciones incluso antes de comprar una solucin particular o aplicar algunas nuevo proceso.
Segn las proyecciones e hitos, las restricciones financieras se pueden crear para alcanzar las
metas y obtener resultados ms concretos de la inversin. Sabiendo exactamente lo que se
controla en base a los gastos corrientes, tambin se puede ver lo que no se controla para obtener
ese dinero. "Ms" y, a continuacin, se transforma en la que se echa en falta. A continuacin, es
posible predecir el coste de llenado en los controles que faltan para alcanzar un equilibrio perfecto
o por lo menos un nivel aceptable de cobertura.
Lo que se debe proteger en primer lugar?
El rav puede ser usado para ver como parte de la gran imagen y como una lente macro en una
parte en concreto de un objetivo, o cualquier combinacin de los mismos. Tras el anlisis, el rav le
mostrar que determinada parte del mbito de aplicacin tiene la mayor porosidad y los ms
dbiles. Comparacin de stos con las necesidades de uno y de los activos por valor, con una
proporcin de intensidad de proteccin se puede generar valor para decidir exactamente dnde
comenzar.
Las soluciones de proteccin lo que necesitamos y cmo debemos configurar para obtener la
mxima eficacia?
UN completo rav mostrar los 10 posibles controles operacionales aplicables a cada destino y las
limitaciones de dichos controles. A continuacin, puede seleccionar las soluciones basadas en qu

tipos de controles a los que desee poner en marcha. La diferencia ahora es que ya no se tiene que
buscar una solucin en trminos de lo que es, ms que a la proteccin o controles que puede
ofrecer. Esto le permite ver los productos a los controles que debe realizar en las reas donde los
controles son actualmente deficientes.
La mejora es adquirida por compras especficas de seguridad y procesos?
Una caracterstica clave del rav es que puede hacer un "Delta" mediante la asignacin de los
beneficios y las limitaciones de una solucin particular para comparacin antes de la compra. Esto
significa que usted puede ver los cambios que la solucin al alcance de comparar con otras
soluciones. Combinando el mapa a un rav del alcance de la solucin, la cantidad de mejoras se
puede medir incluso antes de la compra. Incluso puede predecir el valor de esa proteccin,
dividiendo el precio de la solucin de la rav delta.
Cmo podemos medir la seguridad peridicas esfuerzos y mejoras?
Con auditoras peridicas, el rav se puede volver a calcular y se compara con el valor anterior. Por
lo tanto el costo de las nuevas soluciones y procesos se puede justificar con regularidad, as como
el costo de mantener el nivel de seguridad actual.
Cmo sabemos si estamos reduciendo nuestra exposicin a nuestras amenazas?
Con conocimientos especficos de los controles, puede saber fcilmente qu parte o vector de su
alcance es dbil a la mayora de las amenazas desconocidas. Rav en terminologa, un desconocido
amenaza es slo uno que puede aparecer cuando existen interacciones pero los controles no. Por
lo tanto, un mapa se puede distinguir entre las amenazas determinadas por los evaluadores de
riesgos y los controles que se llevan a cabo. Mtricas regulares exmenes mostrar cualquier
cambio en este mapa y se puede hacer tan regularmente. A continuacin, es posible medir el
costo cada una de esas amenazas en seguridad con los gastos en los controles.
El rav puede decirnos cmo algo se resiste a los ataques?
Tcnicamente, s. Cuanto ms se pueden lograr un equilibrio entre los controles con las
interacciones, los ms pequeos la superficie de ataque y mayor ser la capacidad del objetivo de
conocidos y desconocidos de tipos de interacciones.
Puede el rav ayudarme con el cumplimiento de normativas?
Nada de lo que le ayuda a clasificar todos los controles y puntos de acceso en un mbito le
ayudar a las auditoras de cumplimiento. El rav le ayuda a hacer un buen trabajo a la hora de
conseguir su seguridad bajo control que incluso puede encontrar las principales deficiencias
normativas. Si bien no existe un derecho particular, el cumplimiento ahora que le pide que le

tengan un especial rav puntuacin abierto OSSTMM (OPEN SOURCE SECURITY Testing
Methodology, mostrando la estrella con su rav puntuacin le ayudar a cumplir con diversos
requisitos de cumplimiento para una auditora de terceros y la documentacin.
Seguridad operacional
La medicin de la superficie de ataque requiere la cuantificacin de los accesos, visibilidad y
confianza. Para llevar a cabo esta tarea deben seguirse los puntos que se indican a continuacin.
Visibilidad
Contar el nmero de objetivos dentro del alcance. Por ejemplo si en una organizacin hay 100
empleados pero slo 40 interactan dentro de un canal especfico, entonces se tiene una
visibilidad de 40. Por cada canal se hacen diferentes auditoras para determinar la visibilidad.
Accesos
Contar todos los puntos de acceso por cada lugar de interaccin.
En el caso del canal fsico, si dentro de un edificio hay 3 puertas y 5 ventanas, se obtiene un acceso
de 8. En el caso que se encuentren selladas, el acceso es 0.
En el caso de las redes de datos, si hay una ip activa dentro de la red y para esa ip hay 2 puertos
abiertos, se cuenta un acceso equivalente a 3 (1 ip activa + 2 puertos abiertos). Es ms sencillo de
analizar cuando se trata del canal humano: si la persona responde a cualquier pregunta cuenta
como un acceso, si no responde no cuenta como acceso.
Confianza
Contar cada punto de confianza por cada lugar de interaccin.
Por ejemplo, en el canal de las redes de datos, cada redireccin de puertos cuenta como 1 punto
de confianza.
En el canal humano, cada persona que acta como intermediario se cuenta como 1.
Controles
En el prximo paso se deben contar los controles, los mecanismos de proteccin.
Autenticacin
Contar cada instancia de autenticacin requerida para obtener acceso.
Por ejemplo, en una auditora de seguridad fsica en donde se solicita una tarjeta de
Identificacin y la huella dactilar, se suma 2 a los controles de autenticacin.
Indemnizacin
Contar todas las instancias de mtodos utilizados para la compensacin por prdidas referidas a
los activos.
Por ejemplo, un seguro que cubre el robo de 30 equipos de computacin cuenta como 30.

Resistencia
Contar cada instancia de acceso o confianza donde una falla en el sistema de seguridad no provea
un nuevo acceso.
Suponiendo que existe un webservice que solicita credenciales y la valido contra una base de
datos, en el caso que este servicio pierda la conexin con la base, entonces no debera validar
ninguna credencial hasta la restauracin de la conexin. En caso de rechazar las credenciales,
cuenta como 1 el valor de resistencia (este sera el caso ideal). Existe la posibilidad de que el
servicio no est correctamente diseado y cuando pierde la conexin comience a validar todas las
credenciales, inclusive las que no son correctas; en ese caso la resistencia es 0.
Subyugacin
Contar todos los puntos de acceso o confianza donde la interaccin deba cumplir condiciones
preestablecidas.
Por ejemplo el uso de PKI para las comunicaciones entre un cliente y un servidor cuenta como 1 ya
que la comunicacin slo puede establecerse si cumplen esa condicin.
Continuidad
Contar todos los puntos de acceso o confianza donde una falla no cause una interrupcin en la
interaccin. Dentro de los ejemplos para este punto se encuentran la redundancia y el balanceo de
carga.
En seguridad fsica, si una puerta se bloquea y no existe una entrada alternativa para los clientes
entonces tiene continuidad 0 para ese vector.
No repudio
Contar cada acceso o confianza que provea algn mecanismo de no repudio, tal que exista alguna
forma de determinar que la interaccin se produjo en un tiempo determinado entre las partes
identificadas.
Dentro del canal de las redes de datos, los archivos de logs brindan mecanismos para el no
repudio.
Confidencialidad
Contar cada instancia de acceso o confianza que provea mecanismos para evitar revelar
informacin a terceros no autorizados.
Un ejemplo claro de confidencialidad es el cifrado de la informacin. Privacidad
Contar cada acceso o confianza donde el mtodo de interaccin sea ocultado. Esto no quiere decir
que la informacin viaje codificada sino que no se sepa que hay comunicacin o que sta sea
ofuscada de alguna manera.
En seguridad fsica, un cuarto cerrado donde se efecte la comunicacin entre personas provee
privacidad.

Integridad
Contar cada acceso o confianza donde la interaccin brinde algn mecanismo que permita
conocer si la informacin fue modificada por terceros no autorizados.
En el canal de las redes de datos, una funcin de hash puede usarse para proveer integridad.
Alarma
Contar cada acceso o confianza que genere un registro o notificacin cuando exista algn evento
no autorizado o errneo.
En las redes de datos, los archivos de logs cuentan como alarma aunque estos no generen una
notificacin inmediata. Tambin se debe sumar un punto por cada equipo monitoreado por un
sistema de deteccin de intrusiones o antivirus.
Limitaciones
Finalmente las limitaciones, que son las fallas que presentan los controles para mantener la
separacin entre los activos y las amenazas.
Vulnerabilidad
Contar cada falla o error que pueda llevar a un acceso no autorizado o denegar un acceso legtimo.
Un ejemplo referido al canal de las redes de datos puede ser un proceso que permite la
sobreescritura de reas de memoria que lleven a la ejecucin de cdigo malicioso.
Debilidad
Contar todas las fallas o errores en los controles de interaccin: autenticacin, indemnizacin,
resistencia, subyugacin y continuidad.
Un ejemplo de debilidad en el canal de las redes de datos puede ser una pantalla que solicita
credenciales de acceso que no posea lmites en cuanto a la cantidad de intentos.
Preocupacin
Contar todas las fallas en los controles de proceso: no repudio, confidencialidad, privacidad,
integridad y alarma.
Un ejemplo de preocupacin es un proceso que genere archivos de log con los datos de los
participantes involucrados pero no almacene correctamente la fecha y hora de la transaccin.
Exposicin
Contar cada accin no justificada, falla o error que provean visibilidad de los objetivos o activos, ya
sea de forma directa o indirecta.
Un claro ejemplo de exposicin son los banners que brindan informacin de la aplicacin que est
corriendo detrs de un puerto especfico.
Anomala
Contar cada elemento desconocido que no puede clasificarse dentro de las operaciones normales,
ya que esto puede ser un sntoma para problemas de seguridad futuros.

Frmulas para la seguridad real

Dentro de OSSTMM, los RAVs (Risk Assessment Values) representan la percepcin de la seguridad
de forma similar a un valor porcentual. Donde un rav de 100 representa el balance perfecto entre
las operaciones, controles y limitaciones.
Los ravs derivan de tres categoras definidas dentro del objetivo: seguridad operacional, controles
y limitaciones. En primera instancia se debe asociar la informacin obtenida en los pasos
anteriores a la categora apropiada.
Luego de haber obtenido los valores que corresponden a cada categora, OSSTMM define una
serie de frmulas que determinan un hash que lleva el nombre de "Seguridad real". ISECOM ha
optado por representar este valor de tal forma que se logre un nmero consistente con la
percepcin respecto al estado de seguridad de un sistema, donde un valor de 100 ravs representa
el balance perfecto entre los distintos elementos, ms de 100 significa que hay controles excesivos
y un valor menor a 100 indica que faltan controles. Esto no es un valor porcentual, pero debido a
que resulta cmodo trabajar con porcentajes, se seleccion el valor de 100 como el balance
perfecto y el resto de las combinaciones se distribuyen segn una curva logartmica que
representa de forma aproximada y consistente la percepcin de seguridad definida en todos los
estndares de seguridad.

Categora
Operaciones

Clase A
Controles

Clase B

Seguridad
Operacional
Visibilidad
Acceso
Confianza
Autenticacin
Indemnizacin
Resistencia
Subyugacin
Continuidad
No repudio
Confidencialidad
Privacidad
Integridad
Alarma

Limitaciones
Exposicin
Vulnerabilidad

Debilidad

Preocupacin

Anomala

Este valor puede utilizarse para comparar los resultados que derivan de diversas entradas y de esa
forma permite analizar la evolucin lograda luego de la aplicacin de diferentes mecanismos de
control.
A continuacin se detallan los valores auxiliares que se utilizarn para llegar al resultado final.
Porosidad
La seguridad operacional, tambin conocida como porosidad, es el primero de los tres factores de
la seguridad real que debe ser determinado. Inicialmente se determina como la suma de la
visibilidad (Pv), accesos (Pa) y confianza (Pt).
OpSeCsum = Pv + Pa + Pt
Para calcular el rav es necesario determinar el valor base de la seguridad operacional, OpSeCbase,
que est dado por la ecuacin:
OpSeCbase = log2(1 + 100 * OpSeesum)
En el caso que la sumatoria de Opsecsim sea 0, es decir, que no existen interacciones, la frmula
es equivalente a log2(1) cuyo resultado es 0. Cuando se da esta condicin el resultado final del rav
ser 100, que se traduce a: Seguridad Perfecta.
Controles
El prximo paso para el clculo es determinar la suma de los controles (LCsum).

Autenticacin (LCAU)

Indemnizacin (LCW)

Resistencia (LC^)

Subyugacin (LCsu)

Continuidad (LCCt)

No repudio (LCNR)

Confidencialidad (LCCf)

Privacidad (LCPr)

Integridad (LC)

Alarma (LCAI)
LCsum = LCAU + LCid + LCue + LCsu + LCct + LCNR + LCcf + LCpr + LCt + LCAI
Controles faltantes
Por cada categora se debe calcular el valor de los controles faltantes. Se debe tener en cuenta que
este valor nunca puede ser menor a 0. Entonces el algoritmo para cada categora es el siguiente:

SI OpSeCsum - LCX < 0 ENTONCES MCX = 0 SINO MCx = OpSeCsum - LCX

Luego se suman los controles faltantes de todas las categoras para obtener el valor de MCsum.
MCMM = MCAU + MCu + MCR + MCSU + MCQ + MCNR + MCQ + MCPR + MCIT + MCAI
Controles reales
Los controles reales (TCmm) son la inversa de los controles faltantes. Donde cada uno de los
elementos se calcula como:
TCX = OpSecSum - MCX
Por lo tanto la suma de los controles reales para los diez tipos de controles queda de la siguiente
manera:
TCSum = TCAU + TCid + TCRB + TCSU + TCct + TCNR + TCcf + TCpr + TCI, + TCA;
El valor obtenido sirve para medir la ubicacin ideal de los controles. El valor base ayuda a eliminar
la influencia de ubicaciones desproporcionadas dentro de los controles. El valor base (TCbase) se
calcula como se muestra a continuacin:
TCbase = log2(1 + 100 * (OpSecsum - MCsum * 0.1))
Porcentaje real de cobertura
Como se ha visto en los captulos anteriores, por cada punto de interaccin existen diez controles
posibles; por lo tanto, si la cantidad de controles es cero, el porcentaje real de cobertura ser 0%,
y si la cantidad de controles es igual a OpSecsum * 10 (contando slo una vez los controles del
mismo tipo), entonces el valor real de cobertura es 100%. Este valor se puede obtener mediante la
siguiente frmula:
(100 * (1 - MCsum/ (10 * OpSecsum)))
Este dato es muy importante ya que determina que es lo que se debe corregir, es decir, los puntos
que no cuentan con los controles necesarios.
Controles completos
Este valor tiene en cuenta los controles qu se aplican a la misma instancia de visibilidad, acceso o
confianza. Sirve, por ejemplo, para medir el valor de la defensa en profundidad.
FCbase = lOg2(1 + 10 * LCsum)
Por ejemplo si se aplican cinco controles de autenticacin a una instancia de acceso, esto podra
derivar en un rav mayor a 100.

Limitaciones
Las limitaciones se miden individualmente y estn directamente relacionadas con la porosidad y
los controles. En el caso de una exposicin o anomala tambin se deben tener en cuenta otras
limitaciones relacionadas. Las exposiciones o anomalas no generan inconvenientes por s mismas,
a menos que estn relacionadas con alguna otra limitacin. Por ejemplo, cuando una exposicin
no conduce a nada que sea explotable, no afecta a la seguridad; y por lo tanto no se tiene en
cuenta en el clculo del rav.
Los valores de la tabla que se muestra a continuacin se utilizan para el clculo de las limitaciones,
donde la primer columna contiene las entradas, la segunda el peso que corresponde a cada una de
ellas y la tercera, las variables utilizadas.

Entrada
Vulnerabilidad
LV
Debilidad
LW
Preocupacin
LC
Exposicin
LE

(OpSeCsum + MCsum) / OpSeCsum

Variables
MCsum: Suma de controles faltantes

(OpSeCsum + MCA) / OpSeCsum

MCA: Suma de controles faltantes de

clase A

(OpSeCsum + MCB) / OpSeCsum

MCB: Suma de controles faltantes de

clase B

((PA + PV) * MCvg + LV + LW + LC) /

PV: Suma de visibilidad

PA: Suma de accesos
MCvg: Porcentaje de cobertura
faltante = (M C sum * 0.1 / OpSec um)
PT: Suma de confianza

OpSeC

sum

Anomala
LA

(PT * MC g + LV + LW + LC) /
V

OpSeC

sum

Teniendo las variables de entrada y la ponderacin correspondiente se puede obtener la frmula

que determina las limitaciones mediante la suma de sus productos.
SecLinisum = (LV * (OpSecsum + MCsum) / OpSecsum) + (LW * (OpSecsum + MCA) / OpSecsum) +
(LC * (OpSecsum + MCB) / OpSecsum) + (LE * ((PA + PB) * MCvg + LV + LW + LC) / OpSecsum) +
(LA * (PT * MCvg + LV + LW + LC) / OpSecsum)
Por ltimo, el valor base est dado por el siguiente clculo:
SecLimbase = log2(1 + 100 * Sec Lim sum)

Seguridad real
Esta es la parte final en la cual se utilizarn los clculos definidos previamente para obtener el
valor de la seguridad real. Antes de pasar al clculo final, se utilizar un valor auxiliar (valor delta)
que representa el cambio que una solucin de seguridad genera en el alcance. El valor delta se
calcula mediante la siguiente frmula:
ActSecA = FCbase - OpSecbase Sec Lim base
El clculo final determinar el estado actual de las operaciones con los controles aplicados y las
limitaciones descubiertas.
Como se mencion anteriormente, el valor que se obtiene no es un porcentaje aunque un rav de
100 determina el balance ptimo en la seguridad. El resultado del rav se calcula segn la frmula
que se muestra a continuacin:
ActSec =
100 + ActSecA - 0.01 * (OpSecbase * FCbase - OpSecbase * SecLimbase + FCbase *
SecLimbase)
Si se analizan diferentes entradas de datos utilizando la planilla de clculo de ravs, se puede
observar que, a medida que aumenta el valor de la porosidad, disminuye el valor del rav, es decir,
la percepcin de seguridad disminuye. Cuando se agregan controles, el valor de la seguridad real
sube nuevamente, indicando que la percepcin de seguridad ha aumentado. Por otra parte,
cuando se consideran las limitaciones de los controles, el resultado del rav vuelve a disminuir
porque tambin disminuye la percepcin de seguridad.
Anlisis de confianza
En seguridad operacional, Confianza es simplemente un colaborador con la porosidad, slo otra
interaccin de controlar. A diferencia del Acceso (la otra forma de interaccin), en la forma en que
se relaciona con otros objetivos en el mbito de aplicacin. Por lo que el acceso es la interaccin
entre los dos lados de un vector dentro y fuera del alcance, la confianza se mide como la
interaccin entre los objetivos en el mbito. Sin embargo, la mayora de las personas no se utilice
tan concreta. Confianza por lo general se aplica a una persona especfica o un elemento y un acto
concreto, tales como: " Puedo confiar en este empleado para entregar antes de la fecha lmite?"
o " Puedo confiar en este equipo? ". No hay respuestas correctas a estas preguntas pero la gente
a menudo carecen de las habilidades necesarias para cuantificar el nivel de confianza para que la
persona o el objeto que nos permitiera hacer una ms racional y lgica decisin. Sin embargo,
cuantificar confianza, tenemos que saber lo que es.

Comprendiendo la confianza
Como parte de OPSEC, la confianza es una parte de la porosidad. Donde la seguridad es como una
pared que separa las amenazas de los activos, la confianza es un agujero en la pared. Es all donde
el destino acepta interaccin de otros objetivos en el mbito. Sin embargo, las personas tienden a
utilizar inadecuado o incompleto con sus controles operativos como autenticacin confa en que
se ha llevado a cabo con identificacin inadecuada como una voz a travs de un telfono, una
tarjeta de visita, o, incluso, el supuesto de que porque una persona es en la sala que se est
autorizado a estar all. Esto abre las personas de fraude y el engao. El uso de controles
adicionales son requeridos para asegurar una confianza, para asegurar su integridad y resiliencia.
La confianza propiedades cuantificables, son los elementos objetivos que se utilizan para crear
confianza. Podemos decir estas propiedades son lo que podramos decir que nos "motivos para
confiar". Estas propiedades se van a convertir en referencia las reglas basadas en el objetivo y la
situacin que estamos verificando. Por desgracia, muchos ilgico las propiedades de confianza
existen y estn demasiado a menudo en el uso que hace que sea ms difcil para nosotros para
hacer las decisiones de confianza adecuado sin que siente mal. Sin embargo, es exactamente la
sensacin que nos hace ms propensos a errores. Durante la investigacin, muchos de los
potenciales las propiedades de confianza fueron descubiertos que son de uso comn e incluso
oficiales, las regulaciones gubernamentales y del sector recomiendan, sin embargo no pruebas
lgicas y fueron descartados de nuestro conjunto de propiedades dejando slo diez.
Falacias en la confianza
Propiedades de la confianza
1
Tamao

Simetra

Transparencia

Subyugacin

5
6

Consistencia
Integridad

Compensacin

Descripcin
El nmero de fiar. Debe la confianza extenderse a slo uno o
para muchos? Es que el grupo sea una confianza que est
destinado a tomar la decisin colectiva?
El vector (direccin) de la confianza. La confianza puede ser una
forma (asimtrica) y se define como de qu manera la confianza
debe viajar o en ambos sentidos (simtrica). Una persona que
tambin debe confiar en usted tiene que considerar el
movimiento alternativo de romper la confianza.
El nivel de transparencia de todas las partes y procesos de la diana
y su entorno operacional.
Tambin se llama control, la cantidad de influencia sobre el
alcance por el operador.
La evidencia histrica de compromiso o la corrupcin del objetivo.
La cantidad y la notificacin oportuna de cualquier cambio dentro
del objetivo
Las compensaciones de garantas suficientes son una
compensacin por el dador de fideicomiso o castigo por el
interruptor confianza. Es un valor que se da en la confianza con el
objetivo.

Valor

Componentes

10

Porosidad

El desplazamiento de riesgo financiero, la cantidad de ganar o

ganar para que el riesgo de poner la confianza en el destino sea
suficiente para compensar el riesgo de fracaso en el fideicomiso.
El nmero de otros elementos que actualmente proporcionan
recursos para el objetivo, ya sea a travs de interacciones directas
o indirectas, de forma similar a la Intervencin del Proceso de
cuatro puntos
La cantidad de separacin entre el objetivo y el medio ambiente
externo.

Flujo de Trabajo
El flujo OSSTMM comienza con una revisin de la postura del objetivo. La postura es la cultura, las
reglas, las normas, los contratos, la legislacin y las polticas que definen el destino. Termina con
las comparaciones de resultados a cualquier alarma, alertas, informes o registros de acceso. Este
es un concepto de crculo completo en el que el primer paso es ser consciente de los requisitos
operacionales para interactuar con el objetivo, y el ltimo paso es la revisin de los registros de la
pista de auditora.
Para el analista, esto es simplemente: usted sabe lo que tiene que hacer, lo haces, y despus de
comprobar lo que has hecho.
Esta metodologa separa lo que hay que hacer en este formato jerrquico:
1. CANAL
2. MDULO
3. TAREA
Algunas tareas no producen ninguna salida, lo que significa que existirn mdulos para los que no
hay entrada. Los mdulos que no tienen entrada pueden ser ignorados durante la prueba, pero
deben ser ms tarde documentados con una explicacin por no haber sido realizado. Adems, las
tareas que no tienen salida no indican necesariamente una prueba inferior; ms bien, pueden
indicar una seguridad superior. En detalle, las tareas que no tienen salida resultante pueden
significar cualquiera de las cinco cosas:
1. El canal fue obstruido de alguna manera durante el desempeo de las tareas.
2. Las tareas no se realizaron correctamente.
3. Las tareas no eran aplicables.
4. Los datos resultantes tarea se ha analizado de manera incorrecta.
5. La tarea revela una seguridad superior.
Una Metodologa
Poner todos los mdulos entre s proporciona una metodologa para conocer y trabajar con ellos.
Esta es una metodologa que es aplicable a cualquier y todos los tipos de pruebas de seguridad. Ya

sea que el objetivo sea un sistema en particular, un lugar, una persona, un proceso, o miles de
ellos, sta metodologa asegurar la prueba ms completa y eficiente posible.

Figura 3. Diagrama de Flujo OSSTMM

GUA DE PRUEBAS OWASP 4.0

En el desarrollo del presente trabajo, se hace un anlisis general del proyecto de pruebas de
OWASP, el cual viene siendo desarrollado desde hace muchos aos y cuyo objetivo es el ayudar a
las personas a entender el qu, por qu, cundo, dnde, y cmo probar aplicaciones web.
Este proyecto proporciona un marco de pruebas completo, no simplemente una lista de
verificacin o la prescripcin de las preguntas que se deben abordar. Se puede utilizar este
documento como una plantilla para crear sus propios programas de pruebas o para calificar los
procesos de otras personas.
La gua de pruebas se describe en detalle tanto el marco de pruebas generales y las tcnicas
necesarias para aplicar en la prctica.

Qu es la Prueba?
Durante el ciclo de vida de desarrollo de una aplicacin web muchas cosas necesitan ser probados,
pero qu significa realmente la prueba? El diccionario Merriam-Webster describe pruebas como:

Para poner a prueba o prueba.

Para someterse a una prueba.
Para asignar un estado o evaluacin basada en pruebas.

Para el caso de esta gua, es un proceso de comparacin del estado de un sistema o aplicacin
contra un conjunto de criterios.

Cundo se valida?
En la mayora de ocasiones hoy en da no se prueba el software hasta que ya ha sido creado y est
en la fase de despliegue de su ciclo de vida (es decir, el cdigo se ha creado y crea una instancia en
una aplicacin web de trabajo). Esto es generalmente es una prctica muy ineficaz y un costo
prohibitivo. Uno de los mejores mtodos para prevenir los errores de seguridad que aparezcan en
aplicaciones de produccin, es la de mejorar el desarrollo del Ciclo de Vida del Software (SDLC)
mediante la inclusin de la seguridad en cada una de sus fases. Un SDLC es una estructura
impuesta sobre el desarrollo de artefactos software.

Figura 4 Modelo Genrico SDLC

Lo que hay que probar?
Puede ser til pensar en el desarrollo de software como una combinacin de personas, procesos y
tecnologa. Si estos son los factores que "crean" el software, entonces es lgico que estos sean los
factores que deben ser probadas.
Un programa de pruebas efectivo debera tener componentes que ponen a prueba:
Gente: para asegurar que hay educacin y sensibilizacin adecuada;
Proceso: para asegurar que existen polticas y normas adecuadas y que la gente sepa cmo seguir
estas polticas;
Tecnologa: para asegurar que el proceso ha sido eficaz en su aplicacin.

Comprender el alcance de la seguridad

Es importante saber cunta seguridad requerir un proyecto determinado. La informacin y los
activos que van a ser protegidos deben recibir una clasificacin que establece la forma en que se
deben manejar (por ejemplo, confidencial, secreto, alto secreto). Las discusiones deben ocurrir
con consejo legal para asegurar que se cumplan todos los requisitos de seguridad especficos.

Gua de pruebas de OWASP 4.0

Open Web Application Security Project, est liderando desde 2001 un proyecto libre sin nimo de
lucro orientado a promover la seguridad del software en general y de aplicaciones web en
particular, para ello trabaja en varios proyectos e iniciativas. Bajo licencia Creative Commons,
genera y distribuye material relacionado con el desarrollo y seguridad del software, entre ellos
guas, plataformas educativas y herramientas de auditora, etc.

Dentro de los proyectos relacionados con el sector de la seguridad se destacan las guas publicadas
por la fundacin OWASP, las cuales se han convertido en un referente de la seguridad del
desarrollo y evaluacin de aplicaciones a nivel mundial.
La versin 4 de OWASP Testing Guide se ha consolidado como un material indispensable para
profesionales del desarrollo y pruebas de software, as como para especialistas en seguridad de la
informacin.
En la gua se presenta una metodologa que recorre de forma organizada y sistemtica todas las
posibles reas que supongan vectores de ataque a una aplicacin web. De esta forma, siguiendo
una lista de pruebas perfectamente organizada, se puede auditar de forma eficaz la seguridad de
un desarrollo web.

El Framework de pruebas OWASP

En esta seccin se describe un marco de pruebas que se puede desarrollar dentro de una
organizacin. Puede verse como un marco de referencia que comprende las tcnicas y tareas que
sean apropiados en diversas fases del ciclo de vida de desarrollo de software (SDLC); este no debe
ser visto como una disposicin, sino como un enfoque flexible que se puede ampliar y moldear
para adaptarse proceso de desarrollo de una organizacin.
Actualmente existen muchas metodologas de desarrollo como el Rational Unified Process,
eXtreme and Agile development, y las metodologas tradicionales de cascada.
Este marco de pruebas consta de las siguientes actividades que deben llevarse a cabo:

Antes de que comience el desarrollo

Durante definicin y diseo
Durante el desarrollo
Durante el despliegue
Mantenimiento y operaciones

Fase 1: Antes de que comience el Desarrollo

Definir una SDLC: antes del desarrollo de aplicaciones se inicia un SDLC adecuado, y se
debe definir cuando la seguridad es inherente en cada etapa.

Revisar las polticas y normas: Asegrese de que las condiciones, estndares y

documentacin sean las adecuadas y que estn en su lugar.

Desarrollar Criterios de Medicin y Mtricas y asegurar la trazabilidad: Es esencial definir

las mtricas antes de que comience el desarrollo, ya que puede haber una necesidad de
modificar el proceso con el fin de capturar los datos.

Fase 2: Durante el diseo y definicin

Revisin de Requisitos de Seguridad: Definen cmo funciona una aplicacin desde una
perspectiva de seguridad. Es esencial que los requisitos de seguridad se prueben.

Revisin de Diseo y Arquitectura: Las aplicaciones deben tener un diseo y arquitectura

documentado. Esta documentacin puede incluir modelos, documentos textuales y otros
artefactos similares. Es esencial para probar estos artefactos para asegurar que el diseo y
la arquitectura cumplir el nivel apropiado de seguridad como se define en los requisitos.

Crear y verificar los modelos UML

Crear y revisar los modelos de amenazas

Fase 3: Durante el Desarrollo

Tericamente, el desarrollo es la implementacin de un diseo. Sin embargo, en el mundo real,
muchas decisiones de diseo se realizan durante el desarrollo del cdigo. Si el diseo y la
arquitectura no eran adecuadas, el desarrollador se enfrentar a muchas fallas. Si hubiera polticas
y normas insuficientes, el desarrollador se enfrentar con ms fallas aun.

Cdigo Walk Through: El equipo de seguridad debe realizar una verificacin de cdigo con
los desarrolladores, y en algunos casos, con los arquitectos de sistemas. El objetivo no es
realizar una revisin de cdigo, pero es necesario para entender en un nivel el diseo y la
estructura del cdigo.

Codificacin de las revisiones

Armado con una buena comprensin de cmo el cdigo est estructurado y por qu
ciertas cosas fueron codificadas como estaban, el probador puede examinar el cdigo real
para identificar defectos de seguridad.

Fase 4: durante la implementacin

Aplicacin de Pruebas de Penetracin: Despus de haber probado los requisitos, analizado

el diseo, y se llevada a cabo la revisin de cdigo, se podra suponer que todas las dudas
han sido resueltas.

Pruebas de gestin de configuracin: La prueba de penetracin debe incluir la

comprobacin de cmo se ha desarrollado y asegurado la infraestructura. Si bien la
aplicacin puede ser segura, un pequeo aspecto de configuracin podra estar en una
instalacin por defecto, un escenario vulnerable a la explotacin.

Fase 5: Mantenimiento y Operaciones

Llevar a cabo la gestin operativa Comentarios

Chequear peridicamente el comportamiento: Se deben realizar controles mensuales o

trimestrales en la aplicacin y la infraestructura para asegurar que no hayan entrado
nuevos riesgos de seguridad, y que el nivel de seguridad sigue intacto.

Asegurar y Verificar Cambios: Despus de que cada cambio haya sido aprobado y probado
en el entorno de control de calidad y desplegado en el entorno de produccin, es vital que
se compruebe y asegure que el nivel de seguridad no se haya afectado por el cambio.

Test de Seguridad en Aplicaciones WEB

En este captulo se hace una descripcin de la metodologa de las pruebas de seguridad de
aplicaciones web OWASP; de igual forma se explica cmo probar la evidencia de vulnerabilidades
dentro de la aplicacin causada por deficiencias en los controles de seguridad identificados.

Qu es la Web Application Security Testing?

Se puede entender como un mtodo de evaluacin de la seguridad de un sistema informtico o
red, el cual valida y verifica metdicamente la eficacia de los controles de seguridad de la
aplicacin. Una prueba de la seguridad de aplicaciones web se centra slo en la evaluacin de la
seguridad de una aplicacin web. Este proceso implica un anlisis activo de la solicitud de las
debilidades, fallas tcnicas, o vulnerabilidades. Todas las cuestiones de seguridad que se
encuentran se presentarn al propietario del sistema, junto con una evaluacin del impacto, una
propuesta de mitigacin o una solucin tcnica.

Cul es la metodologa de pruebas de OWASP?

Las pruebas de seguridad nunca sern exactas, donde una lista de los posibles problemas que
deban ser probados se defina en su totalidad. De hecho, las pruebas de seguridad es slo una

tcnica apropiada para probar la seguridad de aplicaciones web bajo ciertas circunstancias. El
objetivo de este proyecto es recoger todas las posibles tcnicas de prueba, explicar estas tcnicas,
y mantener la gua actualizada.
El Mtodo de ensayo de seguridad en aplicaciones de OWASP Web se basa en el enfoque de la
caja negro. El probador no sabe nada o tiene muy poca informacin acerca de la aplicacin que
desea probar.
El modelo de prueba consiste en:
Tester: Quin lleva a cabo las actividades de prueba
Herramientas y metodologa: El ncleo de este proyecto Gua de Pruebas
Aplicacin: La caja negra a probar
La prueba se divide en 2 fases:
Fase 1 Modo pasivo: el probador intenta comprender la lgica de la aplicacin y juega con la
aplicacin. Pueden utilizarse herramientas para obtener informacin gathering. Por ejemplo, un
proxy HTTP se puede utilizar para observar todas las peticiones y respuestas HTTP. Al final de esta
fase, el auditor debe entender todos los puntos de acceso ('' puertas '') de la aplicacin (por
ejemplo, los encabezados HTTP, parmetros y cookies).

Fase 2 Modo activo: el probador comienza a probar utilizando la metodologa descrita en las
secciones de seguimiento.
El conjunto de pruebas activas se han dividido en 11 sub-categoras para un total de 91 controles:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

Recopilacin de informacin
Configuracin y pruebas de gestin de despliegue
Pruebas de gestin de Identidad
Prueba de autenticacin
Pruebas de autorizacin
Prueba gestin de la sesin
Pruebas de validacin de entrada
Control de errores
Criptografa
Empresas prueba lgica
Prueba del lado del cliente

Checklist de Pruebas: Las listas descritas a continuacin, son los controles a probar durante la
evaluacin en cada categora.
4.2. Prueba de recopilacin de informacin:
Incluye los siguientes artculos:
Ref. No.

Categora

Nombre de la prueba

4.2.1

OTG-INFO-001

Realizar Search Engine descubrimiento y reconocimiento de

fuga de informacin

4.2.2

OTG-INFO-002

Huella digital del servidor Web

4.2.3

OTG-INFO-003

Revisin Webserver, Metarchivos para fuga de informacin

4.2.4

OTG-INFO-004

Enumerar aplicaciones en Webserver

4.2.5

OTG-INFO-005

Revisin de comentarios en pginas web y metadatos para la

fuga de informacin.

4.2.6

OTG-INFO-006

Identificar los puntos de entrada de la aplicacin

4.2.7

OTG-INFO-007

Rutas de ejecucin Mapa travs de la aplicacin

4.2.8

OTG-INFO-008

Marco de Aplicaciones Web de huellas dactilares

4.2.9

OTG-INFO-009

Aplicacin Web de huellas dactilares

4.2.10

OTG-INFO-010

Mapa Solicitud Arquitectura

4.3 Configuracin y Despliegue de Pruebas de gestin: La comprensin de la configuracin

desplegada del servidor que aloja la aplicacin web es casi tan importante como la prueba de
seguridad de la aplicacin en s. Despus de todo, una cadena de solicitud es slo tan fuerte como
su eslabn ms dbil. Las plataformas de aplicaciones son amplias y variadas, pero algunos errores
de configuracin de plataforma pueden poner en peligro la aplicacin, de la misma manera una
aplicacin segura puede comprometer el servidor.

Con el fin de evaluar el grado de preparacin de la plataforma de aplicaciones, las pruebas para la
gestin de configuracin incluyen las siguientes secciones:

Ref. No.

Categora

Nombre de la prueba

4.3.1

OTG-config-001

Prueba de red / Configuracin de Infraestructura

4.3.2

OTG-config-002

Prueba de configuracin de la plataforma de aplicaciones

4.3.3

OTG-config-003

Prueba de Extensiones de archivo de informacin sensible

4.3.4

OTG-config-004

Revisin antigua, copias de seguridad y archivos sin referencias

de Informacin Sensible

4.3.5

OTG-config-005

Enumerar infraestructura y aplicaciones Interfaces admin

4.3.6

OTG-config-006

Mtodos de prueba HTTP

4.3.7

OTG-config-007

Prueba HTTP Strict Transport Security

4.3.8

OTG-config-008

Prueba RIA poltica entre dominios

4.4 Pruebas de Gestin de Identidad: Es comn que en las empresas modernas se definan las
funciones del sistema para administrar usuarios, as como la autorizacin de los recursos del
sistema. En la mayora de las implementaciones de sistemas se espera que existan al menos dos
funciones, los administradores y usuarios regulares. La primera permite el acceso a la
funcionalidad y la informacin privilegiada y confidencial, la segunda representa una funcin que
permite el acceso a la funcionalidad habitual de negocios y la informacin.
Las pruebas para la Gestin de Identidad incluyen las siguientes secciones:
Ref. No.

Categora

Nombre de la prueba

4.4.1

OTG-IDENT-001

Definiciones de funciones de prueba

4.4.2

OTG-IDENT-002

Prueba Proceso de Registro de Usuario

4.4.3

OTG-IDENT-003

Proceso de Test Account Provisioning

4.4.4

OTG-IDENT-004

Pruebas de enumeracin y cuentas de usuario.

4.4.5

OTG-IDENT-005

Pruebas para la poltica de nombre de usuario dbil o no

ejecutadas

4.4.6

OTG-IDENT-006

Permisos de prueba a cuentas de invitado

4.4.7

OTG-IDENT-007

Prueba de Suspensin / Reanudacin Proceso

4.5 Prueba de autenticacin: Autenticacin es el acto de establecer o confirmar algo (o alguien)

como autntico, es decir, que las afirmaciones hechas por o sobre la cosa son ciertas. Autenticar
un objeto puede significar confirmar su procedencia, mientras que la autenticacin de una
persona a menudo consiste en verificar su identidad.
Las pruebas de autenticacin incluyen los siguientes artculos:
Ref. No.

Categora

Nombre de la prueba

4.5.1

OTG-AUTHN-001

Pruebas para Credenciales transportadas sobre un canal cifrado

4.5.2

OTG-AUTHN-002

Pruebas para las credenciales predeterminadas

4.5.3

OTG-AUTHN-003

Pruebas para mecanismo de bloqueo dbil

4.5.4

OTG-AUTHN-004

pruebas para pasar por el sistema de autenticacin

4.5.5

OTG-AUTHN-005

Prueba de funcionalidad de recordar contrasea

4.5.6

OTG-AUTHN-006

Pruebas de debilidad de Cach del navegador

4.5.7

OTG-AUTHN-007

Pruebas para la poltica de contraseas dbiles

4.5.8

OTG-AUTHN-008

Pruebas para la seguridad dbil - pregunta / respuesta

4.5.9

OTG-AUTHN-009

Pruebas para cambio de contrasea dbil o funcionalidades de

reinicio

4.5.10

OTG-AUTHN-010

Las pruebas para la autenticacin ms dbil en el canal

alternativo

4.6 Pruebas de Autorizacin: La autorizacin es el concepto de permitir el acceso a los recursos

que slo se tiene permitido usar. Pruebas de Autorizacin significa entender cmo funciona el
proceso de autorizacin, y utilizar esa informacin para evitar el mecanismo de autorizacin. La
autorizacin es un proceso que se produce despus de una autenticacin exitosa, por lo que el
probador verificar este punto despus de que l tiene credenciales vlidas, asociados a un bien
define un conjunto de roles y privilegios.
Las pruebas de autorizacin incluyen los siguientes artculos:
Ref. No.
4.6.1

Categora
OTG-authz-001

Nombre de la prueba
Directorio Prueba de recorrido / archivo incluye

4.6.2

OTG-authz-002

Las pruebas para pasar del esquema de autorizacin

4.6.3

OTG-authz-003

Las pruebas de elevacin de privilegios

4.6.4

OTG-authz-004

Las pruebas para inseguras de referencias a objetos directos

4.7 Prueba Gestin de la sesin: Uno de los componentes bsicos de cualquier aplicacin basada
en la web, es el mecanismo por el cual se controla y mantiene el estado de un usuario con l. Esto
se refiere a esto como Gestin de la sesin y se define como el conjunto de todos los controles
que rigen la interaccin de pleno estado entre un usuario y la aplicacin basada en web. Esto
cubre ampliamente nada de cmo se realiza la autenticacin de usuarios, a lo que sucede en ellos
salir de la sesin.
Las pruebas de Gestin de la sesin incluyen los siguientes artculos:
Ref. No.

Categora

Nombre de la prueba

4.7.1

OTG-SESS-001

Pruebas para Omisin del esquema de gestin de la sesin

4.7.2

OTG-SESS-002

Pruebas para atributos de cookies

4.7.3

OTG-SESS-003

Pruebas de fijacin de Sesin

4.7.4

OTG-SESS-004

Pruebas para variables de sesin expuestas

4.7.5

OTG-SESS-005

Pruebas de Cross Site Falsificacin de Peticin

4.7.6

OTG-SESS-006

Pruebas de funcionalidad de cierre de sesin

4.7.7

OTG-SESS-007

Prueba Sesin inactiva

4.7.8

OTG-SESS-008

Pruebas para la sesin desconectada

4.8 Datos de Pruebas de Validacin: La debilidad ms comn de seguridad de aplicaciones web es

la falta de una validacin adecuada de las entradas procedentes del cliente o desde el medio
ambiente antes de usarlo. Esta debilidad conduce a casi todas las principales vulnerabilidades en
aplicaciones web, tales como cross site scripting, inyeccin SQL, inyeccin intrprete, ataques
locale / Unicode, los ataques del sistema de archivos, y desbordamientos de bfer.

Las pruebas de Datos de pruebas de validacin incluyen los siguientes artculos:

Ref. No.

Categora

Nombre de la prueba

4.8.1

OTG-INPVAL-001

Pruebas para Reflected Cross Site Scripting

4.8.2

OTG-INPVAL-002

Pruebas Reflected Cross Site Scripting

4.8.3

OTG-INPVAL-003

Las pruebas para Manipulacin de HTTP

4.8.4

OTG-INPVAL-004

Las pruebas para Parmetros contaminados en HTTP

4.8.5

OTG-INPVAL-005

Pruebas de Inyeccin SQL

4.8.5.1

Pruebas de Oracle

4.8.5.2

Pruebas de MySQL

4.8.5.3

Pruebas de SQL Server

4.8.5.4

PostgreSQL Testing

4.8.5.5

MS Pruebas de Acceso

4.8.5.6

Pruebas para la inyeccin NoSQL

4.8.6

OTG-INPVAL-006

Pruebas de inyeccin LDAP

4.8.7

OTG-INPVAL-007

Pruebas de inyeccin ORM

4.8.8

OTG-INPVAL-008

Pruebas de inyeccin XML

4.8.9

OTG-INPVAL-009

Ruebas de inyeccin SSI

4.8.10

OTG-INPVAL-010

Pruebas para XPath Injection

4.8.11

OTG-INPVAL-011

Inyeccin IMAP / SMTP

4.8.12

OTG-INPVAL-012

Pruebas para la inyeccin de cdigo

4.8.12.1

Pruebas para la Inclusin de archivos locales

4.8.12.2

Pruebas para la inclusin de archivos remotos

4.8.13

OTG-INPVAL-013

Pruebas de inyeccin de comandos

4.8.14

OTG-INPVAL-014

Pruebas para desbordamiento de bfer

4.8.14.1

Pruebas de desbordamiento del montn

4.8.14.2

Pruebas de desbordamiento de pila

4.8.14.3

Las pruebas para el formato de cadenas

4.8.15

OTG-INPVAL-015

Pruebas de vulnerabilidades incubadas

4.8.16

OTG-INPVAL-016

Pruebas de HTTP Splitting / Contrabando

4.9 Control de errores: A menudo, durante una prueba de penetracin en aplicaciones web, nos
encontramos con muchos cdigos de error generados por las aplicaciones o servidores web. Es
posible hacer que estos errores que se mostrarn mediante un pedido en particular, ya sea
especialmente diseados con herramientas o creados manualmente. Estos cdigos son muy tiles
a la penetracin probadores durante sus actividades, porque revelan una gran cantidad de
informacin acerca de las bases de datos, los insectos, y otros componentes tecnolgicos
vinculados directamente con las aplicaciones web.

Las pruebas de Control de errores incluyen los siguientes artculos:

Ref. No.

Categora

Nombre de la prueba

4.9.1

OTG-ERR-001

Anlisis de cdigos de error

4.9.2

OTG-ERR-002

Anlisis de trazas de pila

4.10 Criptografa: Los datos sensibles deben ser protegidos cuando se transmite a travs de la red.
Estos datos pueden incluir credenciales de usuario y tarjetas de crdito. Como regla general, si los
datos deben ser protegidos cuando se almacena, debe ser protegido tambin durante la
transmisin.
Las pruebas de Criptografa incluyen los siguientes artculos:
Ref. No.

Categora

Nombre de la prueba

4.10.1

OTG-CRYPST-001

Pruebas de SSL Dbil / TSL Cifrados, Transporte insuficiente

capa de proteccin

4.10.2

OTG-CRYPST-002

Las pruebas para Relleno Oracle

4.10.3

OTG-CRYPST-003

Las pruebas para la informacin sensible enviada a travs de

canales no cifrados

4.11 Pruebas Lgicas de Empresas: Pruebas para fallas de lgica de negocio en una aplicacin web
dinmica multi-funcional requiere pensar en mtodos poco convencionales. Si el mecanismo de
autenticacin de una aplicacin se desarrolla con la intencin de realizar los pasos 1, 2, 3 en ese
orden especfico para autenticar un usuario.
Las Pruebas Lgicas de Empresas incluyen los siguientes artculos:
Ref. No.

Categora

Nombre de la prueba

4.11.1

OTG-Buslogic-001

Pruebas de validacin de Data Logic

4.11.2

OTG-Buslogic-002

Prueba capacidad de forjar las solicitudes

4.11.3

OTG-Buslogic-003

Pruebas de chequeo de integridad

4.11.4

OTG-Buslogic-004

Prueba para la sincronizacin de procesos

4.11.5

OTG-Buslogic-005

Prueba de nmero de veces que una funcin se puede utilizar

4.11.6

OTG-Buslogic-006

Las pruebas para la elusin de los flujos de trabajo

4.11.7

OTG-Buslogic-007

Defensas de prueba contra la aplicacin Mis-use

4.11.8

OTG-Buslogic-008

Prueba de carga de archivos inesperados

4.11.9

OTG-Buslogic-009

Prueba carga de archivos maliciosos

4.12 Prueba del lado del cliente: Las pruebas del lado del cliente se refieren a la ejecucin de
cdigo en el cliente, por lo general de forma nativa dentro de un navegador web o un plugin para
el navegador. La ejecucin de cdigo en el lado del cliente es distinta de la ejecucin en el servidor
y devolver el contenido posterior.
Los siguientes artculos describen cmo llevar a cabo una prueba del lado del cliente de una
aplicacin web:
Ref. No.

Categora

Nombre de la prueba

4.12.1

OTG-CLIENT-001

Pruebas para base DOM Cross Site Scripting

4.12.2

OTG-CLIENT-002

Pruebas para la ejecucin de Javascript

4.12.3

OTG-CLIENT-003

Pruebas de inyeccin HTML

4.12.4

OTG-CLIENT-004

Pruebas para redireccionamiento del cliente a un sitio o URL

4.12.5

OTG-CLIENT-005

Pruebas para inyeccin CSS

4.12.6

OTG-CLIENT-006

Pruebas para la manipulacin de recursos

4.12.7

OTG-CLIENT-007

Prueba intercambio de recursos de Origen

4.12.8

OTG-CLIENT-008

Pruebas Cross Site Flashing

4.12.9

OTG-CLIENT-009

Pruebas para Clickjacking

4.12.10

OTG-CLIENT-010

Prueba WebSockets

4.12.11

OTG-CLIENT-011

Prueba Mensajera Web

12.04.12

OTG-CLIENT-012

Prueba de almacenamiento local

Informes
El desarrollo de la parte tcnica de la evaluacin es slo la mitad del proceso de evaluacin
general. El producto final es la produccin de un informe bien escrito e informativo.
El informe debe ser fcil de entender y debe poner de relieve todos los riesgos encontrados
durante la fase de evaluacin; debe atraer tanto a la direccin ejecutiva y personal tcnico.
El informe debe tener tres secciones principales. Debe ser creado de una manera que permite que
cada seccin separada que se debe imprimir y dado a los equipos apropiados, tales como los
promotores o gestores del sistema. Las secciones recomendadas se describen a continuacin.
1. Resumen Ejecutivo: El resumen ejecutivo resume los resultados generales de la
evaluacin y ofrece a los administradores de negocios y propietarios de sistemas una vista
de alto nivel de las vulnerabilidades descubiertas. El resumen ejecutivo tambin debe
indicar claramente que las vulnerabilidades y su gravedad es una entrada al proceso de
gestin de riesgo de la organizacin, no un resultado o remediacin.
2. Parmetros de prueba: La Introduccin debe perfilar los parmetros de las pruebas de
seguridad, los resultados y la remediacin.
3. Conclusiones: En la ltima seccin del informe se incluye informacin tcnica detallada
acerca de las vulnerabilidades detectadas y las acciones necesarias para resolverlos. Esta
seccin est dirigida a un nivel tcnico y debe incluir toda la informacin necesaria para
que los equipos tcnicos para entender el problema y resolverlo. Cada hallazgo debe ser

claro y conciso, y dar al lector del informe una comprensin completa del tema en
cuestin.