(6) Estándares y modelos

Vista previa del material en texto

Estándares y modelos
Índice
3
3
5
8
10
1 | Introducción
2 | OWASP
3 | OSSTMM
4 | NIST
5 | CVSS
Estándares y modelos | TELEFÓNICA // 3
Los estándares sirven de patrón, modelo o punto de referencia para 
poder medir o hacer una valoración de las cosas o procesos. Se 
utilizan en un proceso de hacking ético y es muy importante para:
• Homogeneizar procesos.
• Poder comparar resultados en función de una métrica. Por 
ejemplo, dos empresas que entregan informes con resultados 
pueden ser valorados y comparados a través de un estándar 
con el fin de poder entender los cambios o si las mejoras han 
proporcionado resultados.
• Definir pruebas y formas de actuar.
El primer modelo que se estudiará es OWASP. OWASP es una guía de 
buenas prácticas de desarrollo y autoevaluación. OWASP proporciona 
un TOP 10 sobre las vulnerabilidades más encontradas en las 
aplicaciones web. También existe un TOP 10 sobre vulnerabilidades 
más encontradas en aplicaciones móviles.
A continuación, se muestra el TOP 10 de OWASP con la descripción 
de las categorías de las vulnerabilidades.
1. Introducción
2. OWASP
Imagen 99 Logo OWASP
En la parte superior del top 101 se encuentran aquellas 
vulnerabilidades que son del tipo inyección. Estas vulnerabilidades 
suelen explotarse por errores en la programación de las consultas. En 
segundo lugar, y subiendo desde la tercera posición, se encuentran 
aquellas vulnerabilidades que respectan al manejo de sesiones. 
En este caso se apunta a errores en el diseño donde los atacantes 
pueden comprometer tokens y contraseñas o incluso explotar 
vulnerabilidades dentro de la aplicación.
El caso de XSS sigue permaneciendo dentro de las 3 vulnerabilidades 
más comunes. Suelen verse ataques web XSS que aprovechan la 
falta de controles en la validación de los datos ingresados por el 
usuario.
1 https://www.owasp.org/index.php/Main_Page
http://www.owasp.org/index.php/Main_Page
Estándares y modelos | TELEFÓNICA // 4
Imagen 100 Top 10 OWASP
El resto de las vulnerabilidades que componen el ranking incluyen 
tanto fallas en el diseño de aplicaciones como también errores 
netamente de las personas que administran las mismas. Uno 
de los puntos que vale pena destacar es el referido a las malas 
configuraciones ubicada en la posición 5. En muchos casos, existen 
configuraciones inadecuadas por parte de los administradores, o 
incluso, configuraciones por defecto que no se adecuan al contexto 
de los sistemas y pueden derivar en el compromiso del sistema si un 
atacante toma provecho.
OWASP TOP 10 DE RIESGOS DE SEGURIDAD EN APLIACIONES
A1- Inyección
A6- Exposición de 
datos sensibles
A2- Pérdida de 
Autenticación y Gestión 
de Sesiones
A7- Ausencia de 
Control de Acceso a 
Funciones
A3- Secuencia de 
Comandos en Sitios 
Cruzados (XSS)
A8- Falsificación de 
Peticiones en Sitios 
Cruzados (CSRF)
A4- Referencia Directa 
Insegura a Objetos
A9- Utilización de 
componentes con 
vulnerabilidades 
conocidas
A5- Configuración de 
Seguridad Incorrecta
A10- Redirecciones y 
reenvíos no validados
Las fallas de inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no 
confiables son enviados a un intérprete como parte de un comando o consulta. 
Los datos hostiles del atacante pueden engañar al intérprete en ejecutar 
comandos no intencionados o acceder datos no autorizados
Muchas apliaciones web no protegen adecuadamente datos sensibles tales 
como números de tarjetas de crédito o credenciales de autenticación. Los 
atacantes pueden robar o modificar tales datos para llevar a cabo fraudes, 
robos de identidad u otros delitos. Los datos sensibles requieren de métodos 
de protección adicionales tales como el cifrado de datos, así como también de 
precauciones especiales en un intercambio de datos con el navegador
Las funciones de la apliación relacionadas a autenticación y gestión de sesiones 
son frecuentemente implementadas incorrectamente, permitiendo a los 
atacantes comprometer contraseñas, claves, token de sesiones, o explotar otras 
fallas de implementación para asumir la identidad de otros usuarios.
La mayoría de las aplicaciones web verifican los derechos de acceso a nivel 
función antes de hacer visible en la misma interfaz de usuario. A pesar de esto, 
las apliaciones necesitan verificar el control de acceso en el servidor cuando se 
accede a cada función. Si las solicitudes de acceso no se verifican, los atacantes 
podrían realizar peticiones son la autorización apropiada.
Las fallas XSS ocurren cada vez que una apliación toma datos no confiables y los 
envía al navegador web sin una validación y codificación apropiada. XSS permite 
a los atacantes ejecutar secuencia de comandos en el navegador de la víctima 
los cuales pueden secuestrar las sesiones de usuario, destruir sitios web o 
dirigir al usuario hacia un sitio malicioso.
Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una 
petición HTTP falsificado, incluyendo la sesión de usuario y cualquier otra 
información de autenticación incluida automáticamente, a una apliación web 
vulnerable. Esto permite al atacante forzar el navegador de la víctima para 
generar pedidos que la apliación vulnerable piensa son peticiones legítimas 
provenientes de la víctima.
Una referencia directa a objetos ocurre cuando un desarrollador expone una 
referencia a un objeto de implementación interno, tal como un fichero, directorio 
o base de datos. Sin un chequeo de control de acceso u otra protección, 
los atacantes pueden manipular estas referencias para acceder datos no 
autorizados.
Algunos componentes tales como las librerías, los frameworks y otros módulos 
de software casi siempre funcionan con todos los privilegios. si se ataca 
un componente vulnerable, esto podría facilitar la intrusión en el servidor o 
una pérdida seria de datos. Las apliaciones que utilicen componentes con 
vulnerabilidades conocidas, debilitan las defensas de la apliación y permiten 
ampliar el rango de posibles ataques e impactos.
Una buena seguridad requiere tener definida e implementada una configuración 
segura para la apliación, marcos de trabajo, servidor de apliación, servidor web, 
base de datos, y plataforma. Todas esas configuraciones deben ser definidas, 
implementadas y mantenidas ya que por lo general no son seguras por defecto. 
Esto incluye mantener todo el software actualizado, incluidas las librerías de 
código utilizadas por la apliación
Las apliaciones web frecuentemente redirigen y reenvían a los usuarios hacia 
otras páginas o sitios web, y utilizan datos no confiables para determinar la 
página de destino. Sin una validación apropiada, los atacantes pueden redirigir a 
las víctimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder 
a páginas no autorizadas.
Estándares y modelos | TELEFÓNICA // 5
La metodología OSSTMM2, Open Source Security Testing Methodology 
Manual, está compuesta de quince capítulos y describen las pruebas a 
realizar durante un proceso de auditoría y hacking ético. Las pruebas 
a realizar van en función del ámbito, por ejemplo, si la auditoría es 
wireless, web, de red, ... Cabe destacar la parte de informes dónde 
se puede encontrar un estándar. Este estándar es ideal para que las 
empresas lo sigan y puedan ser comparadas.
Imagen 101 Logo OSSTMM
Para estructurar su contenido, la metodología se subdivide en los 
aspectos más importantes de los sistemas de información:
• Seguridad de la Información
• Seguridad de los Procesos
• Seguridad en las Tecnologías de Internet
• Seguridad en las Comunicaciones
• Seguridad Inalámbrica
• Seguridad Física
De manera sencilla se identifican una serie de actividades de 
testeo específicas por área, sobre las que se comprueban las 
especificaciones de seguridad, integradas con las verificaciones 
realizadas en las revisiones rutinarias.
Con esta metodología, se realiza un esfuerzo para convertir en 
predecible QUE se debe de probar, COMO se puede hacer y CUANDO 
es necesario ejecutarlo. De estamanera se aumenta la calidad del 
desarrollo, ya que la seguir esta metodología, se tiene la certeza de 
que se cumplen unos objetivos prefijados.
2 http://www.isecom.org/research/osstmm.html
3. OSSTMM
http://www.isecom.org/research/osstmm.html
Estándares y modelos | TELEFÓNICA // 6
Un aspecto importante de esta metodología, es que no solo se centra 
en los aspectos eminentemente técnicos de seguridad tradicionales, 
sino que abarca aspectos sobre los responsables del testeo. Trata 
de estandarizar las credenciales del desarrollador a cargo del test, 
el formato de los resultados, crear un código ético, un plan temporal 
de ejecución, etc… Un aspecto muy importante de la metodología, 
es la incorporación del concepto de Valores de Evaluación de Riesgo, 
que permiten diferenciar y clasificar las diferentes problemáticas.
Existen algunas organizaciones como:
Imagen 103 Logo MITRE
• MITRE se encarga de regir las vulnerabilidades. Cada vulnerabilidad 
tiene un CVE (Common Vulnerabilities and Exposures) asociado, 
mientras que hay categorías de vulnerabilidades mediante la 
nomenclatura CWE (Common Weakness Enumeration).
 − CWE: lista de tipos de debilidades de software. Ej: CWE-
120: Buffer Copy without Checking Size of Input (Classic 
Buffer Overflow).
 − CVE: lista de información registrada sobre conocidas 
vulnerabilidades de seguridad. Ej: CVE-2014-0160
Imagen 104 Logo FIRST
• FIRST Forum for Incident Response and Security Teams. 
Esta organización se encarga de asignar un score a las 
vulnerabilidades. Cuando se publica una vulnerabilidad se calcula 
un base score de 0 a 10 según la severidad de la vulnerabilidad. 
Para calcular el base score hay que utilizar una fórmula, la cual se 
puede encontrar en la siguiente dirección URL https://nvd.nist.
gov/CVSS/v3-calculator.
Imagen 102 Esquema OSSTMM
OSSTMM
Discovery:
Obtaining and analysis of the existing system documentation.
Enumeration and verification:
Testing of the operating systems, the configuration and services in 
comparisson with the system documentation.
Vulnerability Research & Verification:
Vulnerability research and analysis by penetration tests. 
Integrity Testing:
Integrity testing of alla results.
Risk Assesment Value:
Calculation of the RAV and risk classification of the weaknesses found.
Reporting:
Mapping of the results and giving of recommendations.
Security Mapping:
Mapping of the measured security. Mapping of the results on systems 
and services.
Estándares y modelos | TELEFÓNICA // 7
Los parámetros que se deben especificar para calcular el CVSS v3 son:
Imagen 105 Parámetros CVSS
BASE METRIC GROUP ENVIRONMENTAL METRIC GROUPTEMPORAL METRIC GROUP
Exploitability
metrics
Impact
metrics
Attack Vector Confidentiality 
Impact
Confidentiality 
Impact
Exploit Code 
Maturity
Remediation
Level
Report
ConfidenceIntegrity
Impact
Integrity
Impact
Availability
Impact
Availability
Impact
Attack Complexity
User Interaction
Scope
Priviledges 
Required
Modified Base 
Metrics
Estándares y modelos | TELEFÓNICA // 8
Según la Wikipedia, el Instituto Nacional 
de Normas y Tecnología (NIST por sus 
siglas en inglés, National Institute of 
Standards and Technology) es una agencia 
de la Administración de Tecnología del 
Departamento de Comercio de los Estados 
Unidos. La misión de este instituto es 
promover la innovación y la competencia 
industrial mediante avances en metrología, 
normas y tecnología de forma que mejoren 
la estabilidad económica y la calidad de vida. 
El NIST (National Institute of Standards 
and Technology) ha dedicado una serie 
de publicaciones especiales, la SP 800 a 
la seguridad de la información. Esta serie 
incluye una metodología para el análisis 
y gestión de riesgos de seguridad de la 
información, alineada y complementaria con 
el resto de documentos de la serie.
El proceso de análisis de riesgos definido 
en la metodología NIST SP 800-30 puede 
resumirse en el siguiente gráfico [NIST800-
30.02]:
4. NIST
Imagen 93 Nessus - Configuración política
ENTRADAS ACTIVIDADES SALIDAS
- Hardware
- Software
- Interfaces entre sistemas
- Datos e información
- Personal
- Misión de los sistemas
- Fronteras del sistema
- Funciones del sistema
- Criticidad de datos y 
sistemas
- Sensibilidad de datos y 
sistemas
- Lista de vulnerabilidades 
potenciales
- Lista de controles 
actuales y planificados
- Rating de probabilidades
- Rating de impactos
- Riesgos y niveles de 
riesgo
- Controles recomendados
- Informe de valoración de 
riesgos
-Definición de amenazas
- Histórico de ataques
- Datos de agencias de 
inteligencia: NIPC, OIG, 
FedCIRC
- Datos de medios de 
comunicación
- Informes de evaluaciones 
de riesgos anteriores
- Resultados de auditorías
- Requerimientos de 
seguridad
- Resultados de pruebas 
de seguridad
- Análisis de impacto sobre 
la misión
- Valoración de la criticidad 
de los activos
- Criticidad de datos
- Sensibilidad de datos
- Pérdida de integridad
- Pérdida de disponibilidad
- Pérdida de confidencialidad
- Probabilidad de explotación 
de las amenazas.
- Magnitud de los impactos 
- Adecuación de los controles 
actuales y planificados
- Motivaciones para los 
ataques
- Capacidad de las amenazas
- Naturaleza de las 
vulnerabilidades
- Controles actuales
- Controles actuales
- Controles planificados
Paso 1: Caracterización de sistemas
Paso 2: Identificación de amenazas
Paso 3: Identificación de vulnerabilidades
Paso 4: Análisis de controles
Paso 5: Determinación de probabilidades
Paso 7: Determinación del riesgo
Paso 8: Recomendación de controles
Paso 9: Documentación de resultados
Paso 6: Análisis de impacto
Estándares y modelos | TELEFÓNICA // 9
Imagen 93 Nessus - Configuración política
El proceso de gestión de riesgos definido en la metodología NIST SP 
800-30 puede resumirse en el siguiente gráfico:
ENTRADAS ACTIVIDADES SALIDAS
- Niveles de riesgo del 
informe de evaluación de 
riesgos
- Lista de posibles 
controles
- Análisis de coste 
beneficio
- Controles seleccionados
- Listado de responsables
- Plan de implantación de 
salvaguardas
- Riesgos residuales
-Ranking de acciones
- Informe de evaluación de 
riesgos
- Viabilidad
- Eficacia
- Impactode la implantación
- Impacto de la no implantación
- Costes asociados
- Riesgos y niveles de riesgos
- Acciones priorizadas
- Controles recomendados
- Controles seleccionados
- Responsables
- Fecha de inicio
- Fecha objetivo de financiación
- Requerimientos de mantenimiento
Paso 1: Priorización de acciones
Paso 4: Selección de controles
Paso 5: Asignación de responsabilidades
Paso 6: Desarrollo de plan de implantación de 
salvaguardas
Paso 2: Evaluación de opciones de controles 
recomendados
Paso 3: Análisis coste-beneficio
Paso 7: implantación de controles seleccionados
La Metodología NIST SP 800-30 está 
compuesta por 9 pasos básicos para el 
análisis de riesgo:
• Caracterización del sistema.
• Identificación de amenazas.
• Identificación de vulnerabilidades.
• Control de análisis.
• Determinación del riesgo.
• Análisis de impacto.
• Determinación del riesgo.
• Recomendaciones de control.
• Resultado de la implementación o 
documentación.
Estándares y modelos | TELEFÓNICA // 10
Se trata de un sistema de puntaje diseñado para proveer un método 
abierto y estándar que permite estimar el impacto derivado de 
vulnerabilidades identificadas en Tecnologías de Información, es 
decir, contribuye a cuantificar la severidad que pueden representar 
dichas vulnerabilidades. 
Imagen 108 CVSS v3.0
Características generales de CVSS versión 3.0
Del mismo modo que la versión anterior, CVSS v3.0 se conforma 
de tres grupos de métricas utilizadas para el cálculo de un puntaje, 
que estima la severidad de una vulnerabilidad. El primer grupo, 
denominado base, busca representar las cualidades intrínsecas de 
ésta, es decir, aquéllas que son inherentes a la vulnerabilidad.
El segundo grupo, conocido como temporal, refleja las características 
que cambian con el tiempo, mientrasque el grupo de métricas de 
entorno considera características de una vulnerabilidad que son 
únicas para el contexto del usuario que lleva a cabo la evaluación.
Después de asignar valores a las métricas base, la fórmula puede 
tener como resultado una puntuación que oscila entre 0.0 y 10.0, 
mismo que representa la severidad de la vulnerabilidad en cuestión. 
Este puntaje puede ser modificado en función de los valores que se 
les asignan a los dos grupos de métricas restantes (temporal y de 
entorno).
Además, una puntuación obtenida con CVSS, también se representa 
como una cadena de caracteres (vector), que muestra un resumen 
de los valores utilizados para cada una de las métricas. Y del mismo 
modo que en las versiones anteriores, la puntuación es el resultado 
de asignar valores cualitativos a las métricas (bajo, medio, alto o 
crítico), de manera que las organizaciones puedan evaluar y priorizar 
las vulnerabilidades.
5. CVSS
Estándares y modelos | TELEFÓNICA // 11
• Inclusión de la métrica ‘privilegios requeridos’
Esta es una nueva métrica que reemplaza la de ‘autenticación’ 
de la segunda versión, que recordemos, estaba enfocada al 
número de veces que debía autenticarse un atacante para lograr 
la explotación de la vulnerabilidad. Con esta nueva métrica, más 
que el número de veces, se evalúan los privilegios necesarios 
para lograr un propósito ofensivo.
A menor cantidad de privilegios necesarios para la explotación, 
mayor será el resultado de puntaje base. El atacante podría 
necesitar privilegios de administrador, de usuario común, o bien, 
no requerir de una autenticación previa, para aprovecharse de 
una debilidad en la infraestructura tecnológica.
• Cambios en el impacto a la confidencialidad, integridad y 
disponibilidad
En la versión 2 de CVSS el impacto a las propiedades de 
confidencialidad, integridad y disponibilidad en la información se 
aplicaban en función de un porcentaje de afectación (nulo, parcial 
o completo). Para la nueva versión, los valores de impacto son 
renombrados a las categorías: nulo, bajo y alto.
La criticidad de la información también es considerada, por 
ejemplo, el impacto a la integridad es alto si el atacante puede 
modificar cualquier información en cualquier momento o la 
información crítica puede ser alterada. Es bajo cuando solo 
cierta información puede ser modificada y/o el atacante no tiene 
control sobre información crítica. El impacto es nulo cuando no 
existe pérdida de integridad, es decir, la información se encuentra 
completa y es exacta.
• Inclusión de la métrica ‘factores de mitigación’
Además, se incluye una nueva métrica llamada ‘factores de 
mitigación’ que sustituye a las métricas de entorno ‘distribución 
de objetivos’ y ‘daño colateral’, la cual busca adaptar controles 
de mitigación o debilidades en los controles que operan en el 
ambiente de los usuarios, y que podrían reducir el impacto de 
una explotación de vulnerabilidades exitosa.
Estándares y modelos | TELEFÓNICA // 12
• Inclusión de una escala cualitativa de clasificación
Mientras que en la segunda versión de CVSS no se proporcionaba 
una guía formal para la clasificación de los resultados, en 
la nueva edición se proveen lineamientos oficiales para 
mapear un puntaje con una escala de clasificación cualitativa, 
que funciona de la siguiente manera: un resultado de 0.0 
corresponde a una categoría nula, si resultado oscila entre 0.1 
y 3.9 se considera baja.
La categoría es media si el valor está entre 4.0 y 6.9, mientras 
que es considerado alta si se encuentra dentro del rango 7.0 y 
8.9; finalmente, la vulnerabilidad es clasificada como crítica si el 
puntaje resulta entre 9.0 y 10.0. Aunque se trata de una guía 
oficial, las organizaciones pueden modificarla y aplicar su propia 
escala, pero siempre manteniendo la misma escala para todas 
las evaluaciones.
Es importante mencionar que la correspondencia entre las 
categorías cualitativas y cuantitativas solo se aplica si son evaluadas 
solo las métricas base, o en caso contrario si se consideran todas 
las métricas de los tres grupos: base, temporal y de entorno.
Consideraciones generales sobre las vulnerabilidades y CVSS
De manera similar al uso de versiones anteriores, existen beneficios 
que se observan a simple vista, con relación al uso de un método 
como CVSS3. Por ejemplo, con el sistema de puntaje se obtienen 
valores de vulnerabilidad estandarizados, lo que permite mantener 
criterios consistentes para la gestión de las debilidades en hardware 
y software que han sido evaluadas.
Además, al utilizar un marco abierto es posible conocer las 
características propias de cada vulnerabilidad, y cuando se calcula 
su resultado, se vuelve representativa de los riesgos dentro de 
las organizaciones, por lo que los usuarios conocen la importancia 
de una vulnerabilidad con relación a otras. Esto se traduce en una 
priorización consciente de las medidas de seguridad que se desean 
aplicar, con el propósito de atender primero las vulnerabilidades 
críticas.
Finalmente, un método de esta naturaleza contribuye a tener un 
panorama amplio sobre la exposición de una organización a riesgos, 
que pueden derivarse de las vulnerabilidades que ya han sido 
identificadas y evaluadas.
3 https://www.first.org/cvss/user-guide
http://www.first.org/cvss/user-guide