¿Cómo hacer un informe de seguridad?
¿Necesitas crear un informe de seguridad básico para evaluar las vulnerabilidades de un proyecto y no sabes por dónde empezar? ¿Cuál es el mejor momento para elaborar este tipo de informes? ¿Quién puede realizar un informe de este tipo? En este nuevo ebook te damos las respuestas que estás buscando.
Evaluaremos algunas de las herramientas de análisis de seguridad más comunes a la hora de realizar un análisis básico de un proyecto y ofreceremos una estructura básica para realizar un informe completo. Además, encontrarás información sobre cómo organizar el informe, qué herramientas puedes empezar a usar y cómo interpretar sus resultados.
https://www.paradigmadigital.com/dev/ebook-informe-seguridad-guia-definitiva/?twclid=2-1p3f7iehl0fwbf52glb6v56cw
¿Quién puede realizar un informe de este tipo?
Aún sabiendo que el informe que planteamos no es ni de lejos un informe que presentaría un auditor, sí que es necesario cierto nivel técnico para configurar, ejecutar e interpretar los datos que generan las
herramientas que proponemos en este ebook.
No obstante, ¡no te asustes! Estas herramientas son de manejo sencillo y, lo más importante, son gratuitas. Debajo de la descripción de cada una de ellas te damos ciertas nociones básicas para ejecutarlas einterpretar los resultados de los informes que genera cada herramienta.
¿Cuál es el mejor momento para elaborar este tipo de informes?
Esta pregunta es importante para plantearnos si es el momento de realizar este tipo de informe, o si nos interesa esperar un poco. Desde nuestro punto de vista, recomendamos realizar el informe sobre un
proyecto cuyo montaje o despliegue haya finalizado (aunque no esté en producción). Si es un proyecto que está por desplegar, obviamente vamos a tener información incompleta y tendremos que presentar
varias versiones del informe.
El momento más interesante para realizar este tipo de informes es justo al terminar el despliegue del proyecto y antes de ponerlo en producción. Con esto conseguimos haber solventado las vulnerabilidades más críticas de nuestro proyecto antes de exponerlo a los usuarios finales.
¿Qué fases tiene el proceso?
Podríamos decir que la evaluación de seguridad debería tener estas fases:
1. Disponer de un inventario de los componentes del proyecto a analizar. Para ello necesitarás, al menos, la siguiente información y accesos:
• Acceso a los endpoints a evaluar
• Acceso a los componentes de infraestructura a evaluar
• Servicios que conforman la plataforma a evaluar
2. Ejecución de las herramientas de análisis de vulnerabilidades
3. Revisión de los informes generados por las herramientas de análisis
4. Redacción del informe de seguridad con las conclusiones obtenidas
El momento más interesante para realizar este tipo de informes es justo al terminar el
despliegue del proyecto y antes de ponerlo en producción.
La fase de revisión y análisis de los informes generados por las herramientas es una de las más importantes en este proceso, ya que las herramientas de análisis generan muchísima información y es necesario un análisis y estudio posterior de esta información para filtrar, estudiar y revisar las vulnerabilidades que dichas herramientas reportan. Por este motivo, y como adelantamos al principio, es recomendable que un perfil técnico realice esta labor de análisis y revisión de las vulnerabilidades que se detecten.
A continuación, pasamos a presentarte las herramientas que te proponemos para realizar este análisis.
Herramientas
En este apartado vamos a hablar de algunas herramientas gratuitas que puedes usar para elaborar tu propio informe. Vamos a desglosar las herramientas por categorías, según lo que se vaya a evaluar. Hablaremos de herramientas para evaluar vulnerabilidades en los siguientes ámbitos:
• Código de la infraestructura
• Código de la aplicación
• Infraestructura
• Web de la aplicación
Hay que tener en cuenta que estas herramientas reportarán vulnerabilidades cuya corrección no aplique en situaciones concretas. Este tipo de decisiones o matices sobre la corrección o no de las vulnerabilidades detectadas en los informes habrá que comentarlo en la interpretación de los resultados del informe final, con la explicación de por qué se desestima la corrección del hallazgo.
Sin más dilación, pasamos a recomendarte algunas herramientas para realizar tu primer informe de seguridad, con pasos básicos para su ejecución e interpretación de resultados.
Este tipo de decisiones o matices sobre la corrección o no de las vulnerabilidades detectadas en los informes habrá que comentarlo en la interpretación de los resultados del informe final.
Herramientas para revisar el código dela infraestructura
—02.01
En esta entrada hemos seleccionado la herramienta Kics que permite el análisis de código de la infraestructura desplegada usando: Terraform, ficheros de configuración de K8s, Dockerfiles o Docker-compose, ficheros de CloudFormation (AWS) y playbooks o roles de Ansible.
Kics se centra en la búsqueda de vulnerabilidades de seguridad, problemas de conformidad y errores de configuración de la infraestructura del código. Se puede ejecutar de distintas maneras y adaptado a la revisión de distintos parámetros.
Aquí te dejamos algunos ejemplos de ejecución:
• Ejecución de Kics mediante una imagen Docker
• Ejecución de Kics a través del código fuente
• Ejecución de Kics usando queries específicas
• Ejecución de Kics para revisión de Passwords y secretos
Herramientas para revisar el código de la aplicación
—02.02
Para la evaluación del código de la aplicación, vamos a mostrar una herramienta de análisis de código de aplicaciones móviles. La herramienta que hemos elegido es MobSF. Esta herramienta permite la evaluación
de seguridad, análisis de malware y pruebas de pen-testing de aplicaciones
móviles (Android/iOS/Windows) de manera automatizada.
MobSF admite binarios de aplicaciones móviles (APK, XAPK, IPA y APPX)
junto con código fuente comprimido y proporciona un API REST para
una integración perfecta con los canales que tengas habilitados para
CI/CD o DevSecOps.
Herramientas para revisar la infraestructura
—02.03
En este punto vamos a centrarnos en herramientas para evaluar la infraestructura desplegada en nuestro proyecto. En este caso, hemos elegido la herramienta OpenVAS. Esta herramienta ofrece un escaneo
de vulnerabilidades de la infraestructura de las soluciones evaluadas.
Entre sus capacidades se incluyen: pruebas autenticadas y no autenticadas, uso de protocolos industriales y de Internet de alto y bajo nivel y
ajuste de rendimiento para exploraciones a gran escala, entre otros.
Herramientas para revisar la web
—02.04
Para la revisión de la web hemos elegido la herramienta ZAP. Esta herramienta ofrece pruebas de pentesting de manera gratuita. Está diseñada
para probar aplicaciones web y es flexible y extensible. Actúa como un
“proxy man-in-the-middle”, situándose entre el navegador de la persona
que realiza la prueba y la aplicación web, de modo que puede interceptar
e inspeccionar los mensajes enviados entre el navegador y la
aplicación web, modificar el contenido si es necesario y reenviar esos
paquetes al destino.
Informe
El objetivo de este apartado es tener un resumen de todo el contenido del documento con los puntos más importantes. Entre los apartados
que debería incluir este resumen, priorizaremos:
Alcance del informe:
Describir brevemente el proyecto o aplicación y explicar qué tipo de
análisis se han realizado. En nuestro caso, añadiremos que se han realizado
los siguientes análisis:
• Análisis del código de la infraestructura
• Análisis del código de la aplicación
• Análisis de la infraestructura
• Análisis de la web
Las herramientas usadas para los distintos análisis:
Es importante explicar brevemente qué herramientas se han usado y por qué se han escogido. También es recomendable hacer un breve resumen de cómo se han categorizado o interpretado las vulnerabilidades
detectadas. En caso de que este resumen se quede muy largo, se pueden poner referencias a los apartados posteriores del documento
donde se explique de manera más extensa el proceso de análisis y revisión
de cada vulnerabilidad.
Conclusiones después del análisis:
En el apartado de conclusiones se debería añadir:
Resumen ejecutivo
¿Cómo hacer un informe de seguridad sin ser auditor/a? La guía definitiva. 03 - Contenido del informe
El total de vulnerabilidades reportadas:
Deberías tener un apartado donde se indique, al menos, el número de vulnerabilidades reportadas después del análisis. Es conveniente separar las vulnerabilidades según el ámbito al que apliquen. En nuestro caso, según los análisis realizados, tendríamos los siguientes sub-apartados:
• Número de vulnerabilidades del código de la infraestructura
• Número de vulnerabilidades del código de la aplicación
• Número de vulnerabilidades de la infraestructura
• Número de vulnerabilidades de la web
El formato tabla es bastante adecuado para presentar esta información
Autores/as: Alberto Perrote y Alba García
Ilustraciones: Marta Ruiz
Maquetación: Candela Nieto
