Metodología de

evaluación para
Auditoria ASVS – ASVS

Marzo 2023
Índice de contenidos

METODOLOGÍA DE EVALUACIÓN...........................................................................................3

1.- Objetivo...................................................................................................................................3

3.- Resumen de Controles OWASP y otros procesos incluidos en la metodología....4

3.2.- Controles MASVS..............................................................................................................4

3.2.- Controles ASVS 4.0...........................................................................................................4

3.3.- Metodología de Desarrollo Seguro................................................................................6

3.4.- Cálculo del riesgo...............................................................................................................6

4.- Metodología de Trabajo.......................................................................................................9

5.- Consideraciones Finales....................................................................................................11

-2-
METODOLOGÍA DE EVALUACIÓN

1.- Objetivo
Los objetivos del presente documento es explicar la metodología utilizada por Base4
Security para la evaluación de controles OWASP ASVS para aplicaciones WEB y
MASVS para aplicaciones Móviles.
El resultado del proceso de evaluación permitirá:
 Auditar aplicaciones Web y móviles para documentar los que no se cumplen
aparentemente por alguna falla de seguridad, y así evitar alguna explotación de
vulnerabilidad.
● Detectar los controles no cumplidos y documentarlos para entregar a los
equipos de desarrollo, producción y/o otros que puedan verse involucrados
dependiendo de cuales sean.

● Detección en análisis SAST (Análisis Estático), y DAST (Análisis Dinámico), y

análisis caja blanca a los componentes de la aplicación.

2.- Alcance
El alcance de cada evaluación dependerá del nivel de controles que requiera el cliente
que abarca Level 1,2 o 3 para aplicaciones Web o Level 1, 2 y/o Ingeniería inversa
para aplicaciones móviles.

-3-
 3.- Resumen de Controles OWASP y otros procesos incluidos
en la metodología
Antes de pasar a describir el proceso utilizado para realizar las auditorías de
controles, se realiza una breve descripción de los controels ASVS y MASVS

3.2.- Controles MASVS

El proyecto estándar MASVS tiene cuenta con 2 niveles de los cuales un tercero
muy importante de ingeniería inversa, donde podemos describir de la siguiente
manera:
● MASVS-L2+R: Corresponde a la cantidad de 47 controles.
● MASVS-L2+R+MASVS-R: Corresponde a la cantidad de 47 Controles + 13,
quedando en total de 60.
● MASVS-L2: Corresponde a la cantidad de 71 controles.
● MASVS-L2+MASVS-R: Corresponde a la cantidad de 71 Controles + 13,
quedando en 84.

3.2.- Controles ASVS 4.0

-4-
El Proyecto del Estándar de Verificación de Seguridad de Aplicaciones (ASVS) de
OWASP proporciona una base para probar los controles técnicos de seguridad de las
aplicaciones web y también proporciona a los desarrolladores una lista de requisitos
para un desarrollo seguro
Niveles de ASVS
El estándar de verificación de seguridad de aplicaciones define tres niveles de
verificación de seguridad, con cada nivel aumentando en profundidad.
 ASVS Nivel 1 es para bajos niveles de garantía, y es completamente
comprobable con pentesting.
 ASVS Nivel 2 es para aplicaciones que contienen datos confidenciales, que
requiere protección y es el nivel recomendado para la mayoría de las
aplicaciones.
 ASVS Nivel 3 es para las aplicaciones más críticas - aplicaciones que realizan
transacciones de alto valor, contienen datos médicos sensibles, o cualquier
aplicación que requiere el más alto nivel de confianza.
Cada nivel ASVS contiene una lista de requisitos de seguridad. Cada uno de estos
requisitos también se puede asignar a características y capacidades específicas de
seguridad que los desarrolladores deben integrar en el software.

Figura 1

-5-
3.3.- Metodología de Desarrollo Seguro

El proceso de Base4 incluye dentro de su metodología de análisis una revisión de la

metodología de análisis de desarrollo seguro para fortalecer los controles sobre las
aplicaciones en análisis
El SDLC seguro (SSDLC) se basa en este proceso al incorporar seguridad en todas las
etapas del ciclo de vida. Los equipos a menudo implementan un SSDLC cuando hacen
la transición a DevSecOps . El proceso implica aplicar las mejores prácticas de
seguridad junto con los aspectos funcionales del desarrollo y asegurar el entorno de
desarrollo. En este servicio el objetivo es implementar buenas prácticas en la etapa de
Desarrollo y Pruebas.

3.4.- Cálculo del riesgo

Durante la ejecución de un proyecto, los consultores de seguridad de Base4 Security

trabajan con las siguientes metodologías a los fines de poder reflejar con mayor
precisión técnica el riesgo final de las vulnerabilidades que se pudieran hallar en los
recursos analizados:

CVSS v3.1 (Sistema Común de Puntuación de Vulnerabilidades)

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

-6-
Tecnologías de la Información (IT), es decir, contribuye a cuantificar la severidad que
pueden representar dichas vulnerabilidades. Una vez que los valores de las métricas
Base son asignadas por un analista, la ecuación definida para calcular la puntuación
genera un valor entre 0.0 y 10.0 derivada de dos subcálculos procedentes de las
métricas de Explotación e Impacto.

Riesgo Puntuación Definición

Crítico 9.0 – 10.0 Explotación simple, no se requieren

privilegios del sistema ni interacción
con usuario, perdida de
Confidencialidad, Integridad y
Disponibilidad del sistema. Se
recomienda formar un plan de acción y
remediar de inmediato.

Alto 7.0 – 8.9 Complejidad del ataque es baja, se

requieren privilegios del sistema, pero
no interacción con usuario, impacto
alto en Confidencialidad, Integridad y
Disponibilidad del sistema. Se
recomienda formar un plan de acción y
remediar lo antes posible.

Medio 4.0 – 6.9 Complejidad del ataque es alta, se

requieren privilegios del sistema o
interacción con usuario, impacto en por
lo menos una de Confidencialidad /
Integridad / Disponibilidad del sistema
afectado. Se recomienda formar un
plan de acción y remediar después de
los problemas de alta prioridad.

Bajo 0.1 – 3.9 Vulnerabilidad muy difícil de explotar,

impacto es mínimo. Se recomienda
-7-
Riesgo Puntuación Definición

formar un plan de acción y remediar en

la próxima ventana de mantenimiento.

-8-
OWASP (Open Web Application Security Project)
Acorde a la metodología OWASP, para determinar la severidad del riesgo se debe
trabajar con los siguientes valores:

 Probabilidad de la ocurrencia de la amenaza (PROBABILIDAD).

En este punto se intenta lograr identificar cuál es la amenaza y las vulnerabilidades
que puedan ser aprovechadas para comprometer los activos de la empresa y la
seguridad de la información que éstos contengan o manejen. Se analiza que tan
probable una determinada vulnerabilidad puede ser descubierta y aprovechada con
éxito.

 Impacto generado sobre el negocio (IMPACTO).

Se debe determinar el impacto que la vulnerabilidad tendrá tanto en el aspecto
técnico como así también en el negocio de la empresa. En cuanto al Impacto Técnico,
se contemplan la pérdida de la confidencialidad, integridad, disponibilidad y
auditabilidad de la información. El Impacto en el Negocio se mide según el daño
económico, de la imagen de la compañía, la violación de la privacidad de las personas
afectadas, como así también la falla en el cumplimiento de regulaciones.

RIESGO = PROBABILIDAD * IMPACTO

Tabla de riesgo ponderado

-9-
4.- Metodología de Trabajo
A continuación se describen los pasos metodológicos que se realizan durante una
auditoría de controles OWASP.

1. Recopilación de información: Se solicita al cliente la provisión de información

detallada de los accesos a los activos, URLs o aplicaciones móviles a evaluar,
credenciales de acceso, códigos fuentes, diagramas de arquitectura y
documentación técnica y funcional asociada a la aplicación, procesos,
procedimientos y políticas para la revisión de controles relevantes a los
diferentes grupos de análisis.

2. Identificación del alcance: Define el alcance de la auditoría, es decir, qué nivel

de auditoría se aplicará (Level 1, 2 o 3 para aplicaciones WEB o Level 1, 2, R,
para aplicaciones móviles) funcionalidades y componentes de la aplicación a
evaluar. Esto se puede basar en los objetivos de seguridad, los riesgos
conocidos, la importancia de las diferentes partes de la aplicación o
requerimientos regulatorios internos o externos

3. Acceso del entorno de auditoría: Confirmar contar con un entorno adecuado

para llevar a cabo la auditoría de seguridad de la aplicación. Esto puede incluir
la configuración de dispositivos móviles emulados o reales, así como la
configuración de herramientas de auditoría y análisis específicas para las
aplicaciones, funcionalidad de las credenciales, etc.

4. Revisión de la arquitectura y el código fuente: Realiza una revisión exhaustiva

de la arquitectura de la aplicación y el código fuente para identificar posibles
vulnerabilidades y debilidades de seguridad. Esto puede incluir la revisión de

- 10 -
 los componentes de la aplicación, los permisos requeridos, las llamadas a API,
el almacenamiento de datos, etc.

5. Ejecución de pruebas de seguridad: Sigue las pautas de las guías oficiales

provistas por OWASP para aplicaciones WEB o Móviles según corresponda
para llevar a cabo las pruebas de seguridad. Esto puede incluir pruebas de
análisis estático y dinámico, pruebas de manipulación de datos, análisis de
almacenamiento seguro, análisis de comunicaciones seguras, entre otros.
Utiliza herramientas y técnicas adecuadas para cada una de las categorías y
requisitos propuestos por las guías.

6. Documentación de hallazgos: Registrar todos los hallazgos encontrados

durante la auditoría, indicando la descripción del problema, su impacto
potencial, los pasos para reproducirlo y cualquier otra información relevante.
Esto ayudará a tener un registro claro de los problemas de seguridad
identificados.

7. Priorización y análisis de riesgos: Evaluar la gravedad y el impacto de cada

hallazgo de seguridad identificado. Priorizar los problemas según su riesgo y
potencial impacto en la aplicación y los datos sensibles. Esto ayudará a
determinar qué problemas deben abordarse primero y cómo mitigarlos
adecuadamente.

8. Creación de un informe de auditoría: Genera un informe detallado que resuma

los resultados de la auditoría. Incluye una descripción general de la aplicación
auditada, el alcance de la auditoría, los hallazgos de seguridad, las
recomendaciones de mitigación y cualquier otra información relevante. El
informe debe ser claro y comprensible para las partes interesadas, como los
desarrolladores y los responsables de la seguridad.

9. Creación Plan de Remediación: Proponer un plan de remediación de las

vulnerabilidades detectadas en función del riesgo y potencial impacto en la
- 11 -
 organización. Cada cliente luego adaptará este plan tentativo en función de la
disponibilidad de sus equipos de desarrollo. En principio se sugiere trabajar con
dichos equipos para abordar y corregir los problemas de seguridad
identificados durante la auditoría.

5.- Consideraciones Finales

El presente es un procedimiento general y que se pueden aplicar variaciones según
las necesidades específicas de la aplicación y del cliente.
Es importante destacar que Base4 Security cuenta con profesionales capacitados en
seguridad de aplicaciones y utiliza herramientas y técnicas adecuadas para llevar a
cabo la auditoría correctamente.

- 12 -
- 13 -