🐞 Vulnerability Management
Introducción
Vulnerability Management es el submódulo de ScanOne que permite la gestión de vulnerabilidades y la automatización de procesos de desarrollo seguro - como por ejemplo el análisis de código. Es posible crear Activos empresariales que pueden representar cualquier tipo de objeto como un servidor, una base de datos, etc. Todos los dominios, escaneos y vulnerabilidades se agruparán por Activo.

Algunas funcionalidades de Vulnerability Management, como los tests y la Integración SonarQube requieren el uso de una Instancia de ScanOne. StrikeOne Admin intentará establecer una conexión SSH con la instancia para hacer uso de las herramientas que se pueden integrar en StrikeOne.
En nuestro perfil de usuario será posible configurar esta instancia - además de la dirección IP, es posible utilizar nombre y contraseña o una llave privada como credenciales. También será posible insertar el puerto y el token de usuario de SonarQube en caso de que el usuario desee usar la Integración SonarQube.
IMPORTANTE
- La Instancia de ScanOne deberá contener también el paquete de scripts correspondiente para la integración de herramientas StrikeOne Collector. De otro modo, la integración de las herramientas no funcionará de manera adecuada.
Instancia de ScanOne
La Instancia de ScanOne corresponde a un servidor que alojará las herramientas y scripts que se pueden integrar a StrikeOne Admin. La máquina debe permitir las conexiones por SSH desde el sitio de StrikeOne. Adicionalmente, se deben de cumplir una serie de requisitos:
- De momento, StrikeOne Admin solo soporta máquinas basadas en Linux.
- El paquete de scripts (StrikeOne Collector) debe ser alojado en la ruta
/opt/scanone/vuln-management - El archivo de configuración de StrikeOne Collector debe estar actualizado.
- Las herramientas a integrar deben estar configuradas correctamente.
La información específica de como debe estar levantada cada herramienta puede ser vista aquí.
Configuración de herramientas para StrikeOne Collector
OpenVAS
StrikeOne Collector utiliza el driver de Python de OpenVAS python-gvm para hacer uso de él. Las configuraciones como puertos, direcciones IP, etc deben ser modificadas en el archivo de configuración de StrikeOne Collector config.ini.
OWASP ZAP
Al ejecutar un Test de OWASP ZAP, StrikeOne Collector ejecutará el comando sudo docker run --rm -v $PWD:/zap/wrk owasp/zap2docker-stable:latest zap-baseline.py, por lo tanto, se requiere de Docker, la imagen owasp/zap2docker-stable:latest y de permisos para sudo para ejecutar el escaneo de OWASP correctamente. Además, el reporte se guardará y se leerá en /home/ubuntu, para después ser movido a la carpeta de reportes de Vulnerability Management (/opt/scanone/vuln-management/reports)
SonarQube
Vulnerability Management permite importar resultados desde SonarQube, o ejecutar SonarScanner, subir los resultados a su instancia local de SonarQube y después importarlos de vuelta a StrikeOne. Asegúrese que SonarQue está funcionando en su instancia - y que haya configurado SonarQube de manera apropiada desde la configuración de ScanOne en su perfil.
Si desea ejecutar un escaneo, usted necesitará la última versión de la imagen de Docker sonarsource/sonar-scanner-cli. Además, su instancia de SonarQube deberá de estar en funcionamiento si desea utilizar SonarScanner.
Cuando el análisis se haya realizado, StrikeOne importará los resultados directamente desde SonarQube, igual que si estuviese importando los resultados.
OWASP Dependency Check
StrikeOne Collector ejecutará un script en bash para realizar el análisis de dependencias con OWASP Dependency Check. Este script hace uso de la imagen de Docker owasp/dependency-check y la intentará ejecutar. La herramienta clonará el repositorio objetivo y, además, instalará sus dependencias usando yarn para el posterior análisis.
Nuclei
La ejecución de Nuclei requiere esté instalado como binario, ya que StrikeOne Collector intentará ejecutar el comando nuclei utilizando sudo. StrikeOne Admin permite, de forma opcional, que el usuario escriba los nombres de los templates a utilizar. Si no se escribe ningún template, se usará nuclei-templates para el análisis.
GitLeaks
GitLeaks debe estar instalado como binario, ya que StrikeOne Collector intentará ejecutar el comando gitleaks utilizando sudo.
Horusec
Horusec debe estar instalado como binario, ya que StrikeOne Collector intentará ejecutar el comando horusec utilizando sudo.
Dashboard

El Dashboard de Vulnerability Management contiene una serie de métricas de todos los Activos e integraciones de Vulnerability Management. Es posible exportar las métricas a un archivo Excel. También se muestra el Estado de DevSecOps, el cual ofrece indicadores de estado de las herramientas de la Instancia de ScanOne que correspondan a cada fase de DevSecOps.
TIP
- El Estado de DevSecOps solo mostrará una fase como activa si es que hay al menos una herramienta compatible que haya sido encontrada en la Instancia de ScanOne.
Activos
Introducción

Los Activos corresponden a cualquier tipo de dispositivo o activo empresarial. Los usuarios tienen la posibilidad de utilizar los activos para representar cualquier tipo de activo empresarial como servidores o bases de datos. Además, es posible asignar a cada activo una criticidad empresarial, ambiente o incluso una Llave de Proyecto de SonarQube para importar resultados desde allí.
Dentro de la lista de activos vienen incluidas las métricas generales de vulnerabilidades para ese activo en específico.
Importar activos

Usted puede también importar activos desde un archivo .csv o .json. Para hacerlo, haga click sobre el butón de importar y después proceda con la importación. A usted se le solicitará seleccionar un archivo a subir. El peso del archivo estará limitado a 20 megabytes. Si la operación fue exitosa, las nuevas vulnerabilidades aparecerán en la página de Activos. Usted también puede mapear campos si está utilizando un esquema diferente al de StrikeOne, e incluso asignar el mismo campo de origen a varios campos objetivo.
IMPORTANT
Hay una serie de campos y valores que son requeridos para que la operación funcione correctamente. La lista es la siguiente:
name: string
Los siguientes campos son opcionales:
desc: string | nullenvironment: "dev" | "pre_prod" | "prod" | "qa" | nulltype: string | nullicon: "default" | "database" | "desktop" | "phone" | "server" | "tablet" | nulltags: string | null (separados por coma)businessCriticality: "very_high" | "high" | "medium" | "low" | "very_low" | nullsonarQubeProjectKey: string | null
Detalle del Activo
Métricas

La pestaña de Métricas mostrará métricas detalladas sobre el Activo y sus vulnerabilidades.
Dominios

La pestaña de Dominios mostrará una lista de dominios y sus respectivos Subdominios. Los dominios corresponden a cualquier tipo de dirección IP o URL, al igual que los subdominios. Las herramientas de escaneo (como OpenVAS) no solo escanearán un dominio en específico, si no que también todos los subdominios que le pertenezcan.
TIP
- Los dominios que posean alguna vulnerabilidad activa serán automáticamente clasificados como
VULNERABLE - Las herramientas que no usen direcciones IP o URLs (como SonarQube) para la ejecución de tests/importar resultados requerirán de un dominio para las vulnerabilidades.
Tests

Como fue explicado más arriba, los Tests representan la ejecución de una herramienta específica. StrikeOne intentará ejecutar una herramienta de forma remota que esté ubicada en su Instancia de ScanOne. El tiempo de ejecución de cada herramienta puede variar desde solo unos minutos a varias horas - ésto dependerá de la instancia y de la herramienta en particular.
Una vez que su Instancia de ScanOne haya sido configurada en su perfil, usted podrá ejecurar un test. Cada test requiere un nombre, un dominio para asociar cada vulnerabilidad encontrada, y una herramienta en particular a ejecutar.
Algunas herramientas aceptan parámetros opcionales, y otras pueden incluso requerir más parámetros para funcionar de forma apropiada. Comúnmente hay herramientas que necesitan clonar un repositorio de Git para analizarlo, y este es el caso con herramientas como GitLeaks y OWASP Dependency Check. Los siguientes parámetros son requeridos:
- Una URL de repositorio debe ser introducida para ejecutar git clone. La URL de repositorio debe incluir sus credenciales (un nombre y un token), más abajo encontrará algunos ejemplos. Recuerde que usted siempre puede usar su proveedor de elección para generar o encontrar su URL de repositorio:
https://USER:[email protected]/USER_OR_ORGANIZATION/REPO.git
https://USER:[email protected]/GROUP/REPO.git
https://USER:[email protected]/ORGANIZATION/PROJECT/_git/REPO
https://USER:[email protected]/COLLECTION/PROJECT/_git/REPO
https://USER:[email protected]/USER_REPO/PROJECT_REPO.git
- El nombre del repositorio es requerido para leer los contenidos de la carpeta que será creada después de clonar. Este valor debe ser exactamente el mismo que el nombre del repositorio, o la ejecución del test fallará.
IMPORTANTE
No es necesario que el valor del nombre del repositorio sea igual al nombre del repositorio en sí al usar curl. Sin embargo, tenga en cuenta que SonarScanner usará ese valor como llave de proyecto. Esto significa que si el valor es similar pero no igual a una llave de proyecto ya existente (por ejemplo, usar 'RepoName' cuando ya hay un proyecto que usa 'reponame' como llave de proyecto) hará que el escaneo fracase. Usar un valor que es igual a una llave de proyecto ya existente, o uno que no es igual a ninguna llave asegurará que el escaneo se lleve a cabo correctamente.
La rama del repositorio a clonar es requerida. Este valor no es necesario si se está usando curl.
Los usuarios también podrán activar la opción para usar curl en vez de git clone. Esto sirve para casos de uso donde el usuario deba descargar el repositorio como .zip de algún lado - como por ejemplo, un repositorio de TFVC descargado usando la API de Azure. A continuación se incluirá un ejemplo de como debe cambiar la URL del repositorio si se utiliza esta opción para Azure. Si desea ver más información, consulte la documentación de la API de Azure DevOps.
https://ORGANIZATION:[email protected]/ORGANIZATION/_apis/tfvc/items?path=$/EXAMPLE-PROJECT&api-version=5.0&download=true&organization=ORGANIZATION
Todos los tests nuevos serán inmediatamente añadidos a la lista de tests de cada escaneo. Esta lista se actualizará en vivo dependiendo de si su test falló o se completó. No todas las herramientas ofrecen una barra de progreso, por lo que algunos tests simplemente saltarán al 100% una vez que hayan sido completados.
Adicionalmente, algunas herramientas permiten importar resultados directamente desde ellas, una herramienta así es SonarQube. Por favor recuerde que SonarQube requiere que el activo en cuestión tenga una Llave de Proyecto de SonarQube definida antes de usar la opción de importar.
Los tests también poseen una vista de detalle que muestran una lista de todas las vulnerabilidades asociadas a ese test en específico.
Es posible ejecutar tests de forma externa a StrikeOne a través de una llamada a nuestra API. Si desea integrar StrikeOne a alguna herramienta de CI/CD, lea nuestra sección de Integraciones.
Vulnerabilidades

En el apartado de Vulnerabilidades se podrá visualizar la lista completa de vulnerabilidades - tanto las que hayan sido creadas por tests, como las que hayan sido añadidas por el usuario.
Cada vulnerabilidad tiene un estado de priorización. Cuando una vulnerabilidad haya sido priorizada, se añadirá a la vista de Hallazgos.
Asignar una vulnerabilidad a uno o más usuarios le permitirá visualizarla en la vista de Remediación. Además, todas las vulnerabilidades resueltas no serán contadas al obtener la mayoría de métricas.
Esta pestaña también permite crear, importar y exportar vulnerabilidades, el método para exportar será en formato Excel para su posterior uso y visualización.
TIP
- Es recomendable usar la vista de Detalle de Test accesible desde un test en la pestaña de Tests si solo desea visualizar las vulnerabilidades de un test en particular.
TIP
- La columna para asignar una incidencia de Jira a una vulnerabilidad solo aparecerá si el usuario tiene configurado Jira.

Usted puede también importar vulnerabilidades desde un archivo .csv o .json. Para hacerlo, haga click sobre el butón de importar y después proceda con la importación. A usted se le solicitará seleccionar un archivo a subir. El peso del archivo estará limitado a 20 megabytes. Si la operación fue exitosa, las nuevas vulnerabilidades aparecerán en la pestaña Vulnerabilidades. Usted también puede mapear campos si está utilizando un esquema diferente al de StrikeOne, e incluso asignar un campo personalizado a varios campos de Vulnerabilidad (campos objetivo).
IMPORTANTE
Hay una serie de campos y valores que son requeridos para que la operación funcione correctamente. La lista es la siguiente:
name: stringstatus: "active" | "accepted" | "closed" | "duplicate" | "false_positive" | "out_of_scope" | "reviewing" | "verified" (o cualquier nombre de estado personalizado)severity: "critical" | "high" | "medium" | "low" | "info" (o cualquier nombre de severidad personalizada)
Los siguientes campos y valores son opcionales:
cveId: string | nullcwe: string | nullcvssv3: string | nulldesc: string | nullmitigation: string | nullimpact: string | nullrequest: string | nullresponse: string | nullstepsToReproduce: string | nullseverityJustification: string | nullscanType: "sast" | "dast" | "secret_scanning" | "sca"foundBy: "manual" | TOOL_NAME | nullsonarQubeIssueType: string | nulllineNumber: string | nullfilePath: string | nullcomponentName: string | nullcomponentVersion: string | nullprioritized: "true" | "false"resolved: "true" | "false"tags: string | null (separados por coma)
Eventos

La pestaña de eventos mostrará todas las acciones que se hayan realizado sobre un activo en específico. Cada elemento de la tabla mostrará información detallada sobre elementos creados, actualizados y borrados.
Configuración

La pestaña de configuración le permitirá modificar aspectos importantes del comportamiento de su activo. En esta pestaña será capaz de definir los SLAs para distintos estados y severidades, incluyendo los días de notificación. Además, podrá crear campos, estados y severidades personalizadas para sus vulnerabilidades.
También será capaz de establecer ciertas reglas para su activo, y ejecutar una acción en caso de que esa regla no se cumpla. Por ejemplo, usted puede limitar la cantidad de vulnerabilidades resultantes y/o por severidad y bloquear un test en caso de que una de las dos reglas no se haya cumplido.
IMPORTANTE
Los miembros de organización requieren permisos para gestión de Activos para poder acceder a esta pestaña.
Además, tenga en cuenta que los SLAs de Estado se actualizarán cada vez que el Estado de la Vulnerabilidad sea modificado, mientras que los SLAs de Severidad solo se actualizarán cuando el estado de resolución de la Vulnerabilidad cambie.
Código (Integración SonarQube)
Introducción

La vista de Código permite visualizar los proyectos y análisis de SonarQube desde StrikeOne Admin, además de importar nuevos proyectos a SonarQube desde GitHub, GitLab, Azure DevOps o Bitbucket Cloud. El estado del proyecto y el resto de indicadores relevantes podrán ser visualizados en la lista de proyectos.
Es posible, además, acceder a la lista de Puntos Críticos de Seguridad, visualizar las vulnerabilidades de un análisis, o exportar estadísticas a PDF, o Excel.
Para hacer uso de la integración se requiere de una instancia que posea SonarQube. Un puerto y token de usuario de SonarQube deben estar configurados, también.
TIP
- SonarQube debe estar funcionando en la dirección IP y el puerto configurados de la Instancia de ScanOne, de otro modo, la integración no funcionará.
Hallazgos
Introducción

La vista de Hallazgos contiene las vulnerabilidades que hayan sido priorizadas. Esta vista permite a los usuarios gestionar las vulnerabilidades priorizadas (para funciones de Red Team, por ejemplo) y evidenciarlas.
Evidencia

La sección de evidencia de cada vulnerabilidad solo permite un máximo de 5 archivos.
Remediación (BETA)
Introducción

La vista de Remediación le permite visualizar todas las Vulnerabilidades que actualmente se encuentren asignadas a mínimo un usuario para su resolución.
Herramientas (BETA)
Introducción

Esta vista le permitirá gestionar todas las herramientas actualmente disponibles en su Instancia de ScanOne.
Pipelines (BETA)
Introducción

Esta vista le permitirá crear, de forma automatizada, un pipeline para un CI/CD como GitHub Actions, GitLab CI/CD, etc. Al generar el pipeline, se le entregará el código que corresponde al pipeline del CI/CD que fue elegido.
Para crear un nuevo pipeline, presione en el botón de Nuevo pipeline y será redirigido a la vista de creación de pipelines.

El creador de pipelines le solicitará definir ciertos parámetros. Actualmente, los campos relacionados al repositorio (URL, nombre y contraseña) no tienen ningún uso, pero la URL deberá de ser introducida de todas maneras.
Los campos de Eventos y Lenguaje servirán para definir la estructura del pipeline y el código que podrá ser generado. Es importante que usted seleccione el lenguaje que corresponda a su proyecto, y que defina los eventos que requiere.
IMPORTANTE
La contraseña o token de repositorio no volverá a ser revelada. Recuerde que usted es responsable de guardar sus credenciales de forma segura.

Para generar el snippet de código necesario para su pipeline después de crearlo solo deberá volver a la vista principal y presionar en Generar código.
