¿Qué debe incluir un informe de auditoría de seguridad?

Hay un par de maneras en que he visto esto hecho, cada una tiene sus pros y sus contras.

Como lo señala @RoryAlsop a continuación, un punto común para ambos enfoques es que el resumen ejecutivo debe, en la medida de lo posible, redactarse para una audiencia de negocios (suponiendo que se trata de una prueba para un tercero o el informe). será pasado a la gerencia).

• Informe por hallazgo. Aquí enumera los hallazgos, generalmente clasificados por gravedad (por ejemplo, puntuación CVSS o alguna otra escala como gravedad / probabilidad). A continuación, enumera los detalles técnicos del hallazgo y las posibles mitigaciones si tiene esa información. Este tipo de informe llega al punto con bastante rapidez y funciona bien con el resultado de la herramienta.
• Informes por metodología. Suponiendo que está siguiendo una metodología de prueba definida, el informe está estructurado de acuerdo con la metodología e incluye una sección para cada área de la revisión. Las secciones detallan qué pruebas se realizaron y el resultado (por ejemplo, un hallazgo o el hecho de que no hubo hallazgos en esta sección). La ventaja aquí es que está mostrando sus trabajos y que alguien que esté leyendo el informe puede tener una buena idea de que realmente ha probado algo y estuvo bien, en lugar de que solo lo haya perdido. La desventaja es que tiende a ser un informe más largo y más difícil de automatizar. Otro problema es que debes asegurarte de que los evaluadores no solo sigan la metodología y en realidad se involucren en el cerebro para buscar otras cosas.

En términos de formato para los hallazgos, generalmente incluyo lo siguiente

• Título (se describe descriptivamente en la tabla y se vincula al detalle)
• Descripción: descripción técnica de cuál es el problema y, lo que es más importante, en qué circunstancias es probable que cause un problema de seguridad (por ejemplo, para las secuencias de comandos entre sitios, uno de los posibles problemas es el uso para capturar tokens de sesión que podrían permitir a un atacante obtener acceso no autorizado a la aplicación)
• Recomendaciones: cómo se debe resolver el problema, cuando sea posible, incluya detalles específicos sobre la guía del proveedor para solucionarlo (por ejemplo, cosas como eliminar versiones de servidor web de los encabezados tienen instrucciones específicas para Apache / IIS, etc.)
• Referencias: cualquier enlace a información adicional que sea relevante para el hallazgo (por ejemplo, enlaces a la página OWASP relevante para problemas de aplicaciones web)
• Severidad. Como mencioné anteriormente, esto podría ser CVSS o algo más general como Alto / Medio / Bajo basado en el impacto y la probabilidad.
• Otra clasificación según sea necesario por el cliente. Por ejemplo, es posible que algún cliente necesite alinearse con un estándar o una política o algo así como OWASP Top 10.

Otro punto a destacar es que si realiza muchas pruebas, vale la pena tener una base de datos de hallazgos anteriores para evitar tener que buscar referencias repetidamente y asegurarse de que las severidades sean consistentes.

Pregunta emocionante! Con demasiada frecuencia, siento que nuestra industria se esfuerza por lograr la última y mejor moda en seguridad. Vamos tras las últimas hazañas, gastamos dinero en efectivo en las últimas herramientas y culpamos a la capa 8 por las brechas. Sé que es una generalización general, pero quería subrayar la importancia de este tema: ¡informar!

Tengo mis opiniones sobre lo que debería incluirse en un informe de vulnerabilidad. Desde la perspectiva de la estructura, un informe completo tendrá lo siguiente:

• Una página de título : esto indicará el nombre del informe, la agencia o departamento al que corresponde, la fecha en que se publicó el informe.

• Una tabla de contenido : parece obvio, pero estos documentos pueden alargarse, incluir esto como cortesía.

• Un resumen ejecutivo : Este será un resumen de alto nivel de los resultados, lo que se encontró y cuál es la línea de fondo.

• Una introducción : una declaración simple de sus calificaciones, el propósito de la auditoría y su alcance.

• Hallazgos : esta sección contendrá sus hallazgos y enumerará las vulnerabilidades o problemas que se deben volver a mediar. Esta lista debe estar ordenada por niveles críticos, de los cuales se espera que estén definidos por políticas internas (es decir, si su analizador de vulnerabilidades encuentra una alta vulnerabilidad crítica, según la forma en que se implementa esa vulnerabilidad en su entorno, es posible que no sea una verdadera crítica alta). las políticas internas deberían ayudar a definir los niveles críticos)

• Metodologías : aquí analizará las herramientas utilizadas, cómo se descartaron los falsos positivos, qué procesos completaron esta auditoría. Esto es para brindar consistencia y permitir que sus auditorías sean repetibles en el caso de que un hallazgo sea discutido o se considere que no sea digno de ser arreglado por la gerencia.

• Conclusión : conclusión básica, resume la información que ya has reunido.

• Apéndices : serán los archivos adjuntos adicionales necesarios para referencia.

Algunas de las personas que trabajan en el PTES están sentando algunas buenas bases. Si bien el enfoque está en las pruebas de penetración, creo que muchas de las metodologías, especialmente los informes, podrían transponerse para una auditoría. Puede consultarlos en enlace .

Después de una prueba de penetración o un análisis de aplicación híbrido, el informe resultante se centra en los hallazgos. Debe haber una descripción general de alto nivel que analice las fallas y su impacto colectivo en el sistema.

Un hallazgo es cualquier violación de seguridad. Esto incluye cualquier infracción de CWE , pero los hallazgos de aplicaciones web más comunes se encuentran en el top 10 de OWASP. Debería haber pasos para reproducir el problema, una gravedad, el impacto de esta falla, recomendaciones para solucionar el problema y enlaces con más información. Por ejemplo, si encuentra una vulnerabilidad de XSS, muestre un límite de pantalla de un cuadro de alerta y la URL que usó para desencadenar el problema y enlace a la página OWASP en XSS. Si puede acceder a la cookie con XSS, entonces el problema se puede usar para secuestrar una sesión, de lo contrario se podría usar para socavar la protección CSRF.

¿Qué pasa si no puedes encontrar nada? ¡Seguir mirando! El sistema CWE es masivo, e incluso los desarrollos más experimentados cometerán errores. Existen vulnerabilidades que afectan de manera legítima a todas las aplicaciones que he tocado. El secuestro de clics, la falta de protección de la fuerza bruta y la divulgación de información es probablemente el más común. Por ejemplo, el nombre de usuario / la dirección de correo electrónico a través de la contraseña olvidada o la función de registro. Visualización de números de versión (encabezados http o en cualquier otro lugar). Mensajes de error detallados, rutas locales, direcciones IP internas ... cualquier cosa que pueda ser útil para un atacante.

Creo que Rook lo dice muy cierto, aunque se trata más del núcleo del informe, en lugar de su estructura, que se colocará después de que se haya diseñado el formato del informe.

Pruebe el modelo STAR (Situación, Tarea, Acción y Resultado): He visto excelentes informes escritos con este modelo debajo del capó. Lo mejor de esto es que se puede usar en casi todos los contextos: solo tendría que adaptarse a lo que sea relevante para usted. En este caso, podría estructurar su informe alrededor de este modelo y usar lo que Rook describió para completar la estructura.

Además, incluso si no tiene resultados reales, aún podría escribir un informe completo basado en el modelo STAR y seguir ofreciendo algo que sea profesional y coherente.

Nunca he escrito un informe de auditoría de seguridad, aunque en mi función tiendo a recibirlos. El mejor que habíamos visto sobre todo nuestro producto en áreas específicas de interés. El informe se desglosó en esas áreas. En general, el formato fue:

1. título
2. Resumen ejecutivo: una breve descripción del propósito y alcance de la auditoría. Y comentarios de alto nivel, sobre las principales áreas de preocupación y, lo que es más importante, cubren aquellas áreas que están bien hechas
3. metodología de evaluación
4. Descripción del sistema: abarca la implementación que se está investigando
5. Luego secciones en cada área / objetivo
6. Resumen y recomendaciones

La Sección 5 se desglosó para cada objetivo como:

1. Introducción
2. objetivo
3. Significado
4. Evaluación (que abarca metodologías y vulnerabilidades reales)
5. Conclusión

En primer lugar: es como escribir un libro, la primera línea mantendrá al lector o no. (La introducción es escribir al menos.)

Algo como introducción, comienzo, contenido, fin.

• Introducción
• objetivos
  • Actualizar los términos del contrato.
  • Descripción de los objetivos
  • Descripción de los métodos
• Ejecución
  • Paso a paso: objetivo, acción, reacción
  • Observaciones - > preguntas
  • operaciones adicionales, paso a paso
  • Nuevas observaciones ...
  • furter otra vez ... y otra vez si es el caso
• Conclusión
  • éxito o no
  • lo que claramente está mal, tener que cambiar
  • qué falla, tener que ser corregido
  • propósitos

Algún truco que hay que tener en cuenta:

1. Su trabajo no está destinado a ser leído por personal técnico, así que trate de ser sencillo, pero
2. Su trabajo debe ser leído por personal técnico, para validar o aplicar sus recomendaciones, ¡así que no olvide nada! Su trabajo debe ser exacto, completo e indiscutible .
3. Como su trabajo se relaciona con fallas de seguridad, hacer alguna ofuscación, como usar John Doe: XXXXX para el nombre de usuario de pareja, la contraseña puede ser una buena práctica, deben mencionarse en la introducción, pero esto podría ser útil para seguir discutiendo.

Por lo tanto, para mantenerse ligeros para las personas administrativas, la Introducción y la Conclusión deben explicarse de manera sencilla, tal vez utilizando un lenguaje pictórico, y

para mantenerte ligero para las personas técnicas que tienen que trabajar alrededor de tu texto, sean exactos y detallados. Tal vez un simple volcado de consola con algunos comentarios podría ser suficiente.

Esto puede sonar como una anulación, pero no lo es, y es simplemente preguntar qué formato les gusta. He realizado todo tipo de revisiones y la mayoría de las empresas tienen un formato de qué información les gusta y cómo la disfrutan. Pida ver los informes anteriores como una plantilla, le ahorrará un montón de tiempo.

¿Cómo puedo reconstruir esta situación & ¿A qué me dirijo exactamente?

  

construyo & Operaciones de seguridad del arquitecto para vivir. Llevaba una década dirigiéndome a Informes de seguridad de aplicaciones & bastante seguro de lo que debe incluirse & Donde tenerlos incluidos. La presentación será importante.

He pensado en esto bastante. Mirando todas las respuestas, siento que las partes faltantes junto con la respuesta más definitiva & El conocimiento debe estar enfocado.

Para comenzar, me gustaría ir diciendo: No confunda entre Evaluación y amp; una auditoría . La auditoría tiene pistas de auditoría, y una evaluación tiene detalles técnicos esenciales. La publicación original dice que se realizó una auditoría de las aplicaciones que no pudo ser. Más técnicamente fueron las evaluaciones.

He recogido varios, incluida la Metodología seguida en CERN , ref: enlace . Para mi sorpresa, la mayoría de las veces, es probable que los detalles técnicos que son como una Evaluación de seguridad sean más útiles para el Desarrollador y amp; Es Operaciones en lugar de las partes interesadas del negocio. Cuando intenta auditar una aplicación o un conjunto de aplicaciones en una interfaz pública, lo lleva a la parte interesada de la aplicación.

En cuanto a los puntos de mi Ejemplo de Informe de Aplicación, aquí está cómo se ve (pido disculpas por los garabatos porque era absolutamente necesario, pero tuve que quitarlos según las normas de NDA):

Vamos a explicar cuáles son estos componentes en los punteros clave:

1. El primero es Clasificación de vulnerabilidad : por ejemplo. para XSS, podría escribirse como Code Injection. Para Inyección de Shell, la inyección de intérprete es un término más preciso. Del mismo modo, para las inyecciones de SQL, en lugar de MS-SQLi o MySQli, la clasificación debería ser Inyección de base de datos .
2. El siguiente es Título de vulnerabilidad : para la inyección de base de datos, siempre podría ser más preciso en una línea como UNION BASED MySQL Injection Leads to Command Level Compromise .
3. Lo siguiente es Calificación de riesgo : en mi opinión, me gustaría ir por WASC o algo así, pero prefiero nuestro propio circuito de calificación personalizado. Uno puede buscar OWASP , WASC u otros si le han dicho que se adhiera a una metodología particular. NIST sería uno si se trata principalmente de seguridad de la red.
4. Descripción : Esto debería ser lo más detallado posible. A veces puede suceder que no se encuentre un conjunto de clasificación debido a que la amenaza es la lógica empresarial en su naturaleza. Para aquellos, es necesario tener un gran sentido de comprensión de contexto & por qué el escenario de ataque se pone como tal.
5. Impacto : una vez más, diría, mencionar que esto es un punto difícil en las balas. Eso es saludable & higiénico para las partes interesadas del negocio también.
6. Prueba de concepto : creo que esto se explica por sí mismo. Pero incluye detalles que incluyen capturas de pantalla. Otra entrada sería que incluyas los parámetros afectados y amp; también anote el punto final en caso de que sea una API que se vea afectada junto con sus parámetros POST, si los hubiera.
7. Recomendación & Remediación : creo que esto también es explicativo. Mantenga una plantilla genérica para el OWASP Top 10 , SANS 15 & WASC Top 26 ones. Por lo demás, utilice las recomendaciones basadas en el contexto de un manual escrito, ya que ayuda a sus operaciones de TI.
8. Corregir responsabilidad : quién está arreglando. En tu caso, eres tú!

Espero que esto ayude.

Si el objetivo de un informe de auditoría de seguridad es persuadir a la administración para remediar las debilidades de seguridad encontradas, entonces usted debe describir el impacto de no solucionar los problemas. Como auditor de TI, con frecuencia me encuentro con la resistencia de miembros no técnicos de la gerencia sobre las recomendaciones que hago, tales como:

1. Es demasiado costoso de implementar
2. No hay suficiente retorno al negocio para justificar el esfuerzo
3. No hay beneficio económico tangible

Desea describir en su informe cuál sería el impacto de no remediar las vulnerabilidades de seguridad en términos comerciales como:

1. El costo de la pérdida de negocios será de aproximadamente $ X dólares si un adversario explota una vulnerabilidad de seguridad.
2. Se producirán X horas de tiempo de inactividad (RTO) durante las cuales no podremos atender a nuestros clientes como resultado de una amenaza que explota una vulnerabilidad a la disponibilidad de nuestros sistemas.

En resumen, su objetivo es obtener la aceptación del negocio para que la seguridad se transforme únicamente de una función de TI a una función que tenga ramificaciones económicas y no económicas negativas (por ejemplo, reputación dañada) si no se atienden a las vulnerabilidades.