Las políticas del programa son fundamentales para todos los VDP y deben redactarse con cuidado. La política del programa es lo primero que ven los investigadores de seguridad cuando participan en un VDP. Define la pauta del programa, define las expectativas y define tu compromiso con los investigadores que deciden participar.
Cómo crear y alojar la política del programa
Usa los siguientes lineamientos para redactar la política del programa del VDP. Las políticas del programa suelen tener solo de 1 a 3 páginas y suelen incluir los siguientes temas:
- Una promesa a un investigador
- Lineamientos para las pruebas
- El alcance del programa
La política del programa debe estar disponible para todos los posibles investigadores. Si planeas lanzar el VDP de forma privada solo a unos pocos investigadores invitados, la política del programa necesita algún tipo de control de acceso para que esté disponible para los investigadores que invitaste, pero restringido a todos los demás. Los investigadores también necesitan una forma de enviar informes, como un formulario web o un alias de correo electrónico conectado a un sistema de tickets para realizar un seguimiento de los informes. Ten esto en cuenta cuando configures los recursos en línea del VDP.
Por lo general, las plataformas de divulgación de vulnerabilidades de terceros y de recompensas por errores ofrecen las siguientes funciones:
- Una forma de crear, editar y publicar una política
- Controles de acceso para crear un programa privado
- Invita automáticamente a los hackers a un ritmo cómodo.
- Función de bandeja de entrada que facilita el procesamiento de informes entrantes.
Las plataformas de terceros también ofrecen una variedad de servicios de consultoría para facilitar el proceso de creación y lanzamiento de un VDP. Por lo general, las plataformas y los servicios de consultoría de terceros tienen un costo. Ten en cuenta los costos y beneficios de usar un tercero en lugar de crear y administrar el programa de forma interna a fin de determinar el mejor camino para tu organización.
Para obtener más inspiración sobre lo que debes incluir en la política del programa, lee el documento "A Framework for a Vulnerability Communication Program for Online Systems" del Departamento de Justicia de Estados Unidos.
Interesados de la política del programa
Cuando redactes la política del programa, considera cómo trabajar con los interesados. Varios equipos pueden proporcionar información sobre las consideraciones que se deben incluir en la política.
| Interesados | Consideraciones |
|---|---|
| Legal |
|
| IT |
|
| Ingeniería |
|
| PR |
|
| Seguridad |
|
Promesa a un investigador
La promesa a los investigadores explica los compromisos de la organización con los investigadores participantes que actúan de buena fe y siguen los lineamientos de pruebas que se describen en la política. Por ejemplo, un compromiso de responder a todos los informes de seguridad entrantes dentro de un período específico, así como comunicar decisiones sobre qué informes de vulnerabilidad se aceptan y se corrigen.
Ejemplo:
<Name of your organization> se compromete a trabajar con los investigadores de seguridad para ayudar a identificar y solucionar las vulnerabilidades en nuestros sistemas y servicios. Siempre y cuando actúes de buena fe y cumplas con los lineamientos descritos en esta política, haremos todo lo posible para comprometerte con lo siguiente:- Proporciona una respuesta inicial a tu informe de vulnerabilidad en un plazo de tres días hábiles
- Determinar si aceptaremos (intentamos corregir) o rechazaremos (identificaremos tu informe como un falso positivo o un riesgo aceptable) tu informe de vulnerabilidad en un plazo de diez días hábiles.
- Mantenerte al tanto del progreso hacia la solución de los informes que aceptamos
Si adoptas el lenguaje de espacio seguro en tu política del programa, ayudas a garantizar a los investigadores que no se tomarán acciones legales contra ellos para realizar pruebas en tus sistemas, siempre que actúen de buena fe y sigan todos los lineamientos explicados en la política.
Lineamientos para las pruebas
En los lineamientos para pruebas, se describen las pruebas de seguridad que están dentro del alcance del VDP, así como las pruebas que no están dentro del alcance y que los investigadores deben evitar. Si hay tipos específicos de vulnerabilidades en los que quieres que se enfoquen los investigadores, esta sección es un buen lugar para destacarlos.
Ejemplo:
Cuando realices pruebas de seguridad, sigue estos lineamientos:
- Solo realiza pruebas con tus propias cuentas y datos (p.ej., crea cuentas de prueba). Si identificas una vulnerabilidad que podría generar acceso a los datos de otros usuarios, consúltanos antes de continuar con la prueba.
- Si en tus pruebas accedes sin querer a los datos de otros usuarios, avísanos y no almacenes esos datos.
- No realices pruebas que den como resultado condiciones de denegación del servicio o la degradación de nuestros servicios de producción.
- La ingeniería social está fuera del alcance de este programa; no intentes realizar ingeniería social de nuestra organización ni a nuestros usuarios.
Nos interesan, en particular, los siguientes tipos de impactos y vulnerabilidades:
- Ejecución remota de código
- XSS que genera acceso a datos sensibles (p.ej., información de la sesión)
- Inyección de SQL que da como resultado el acceso a funciones o datos sensibles
- Fallas de lógica empresarial que generan acceso a funciones o datos sensibles
Nos interesan menos los siguientes tipos de vulnerabilidades, ya que es más probable que
se rechacen como falsos positivos o riesgos aceptados:
- Falta del encabezado X-Frame-Options en páginas sin funcionalidad de cambio de estado
- Resultados sin verificar del escáner automatizado
- Problemas que tienen pocas probabilidades de aprovecharse o que no tienen un impacto realista en la seguridad
Permiso
El alcance define los recursos con los que los investigadores pueden realizar pruebas, así como los que no se consideran parte del VDP. El alcance debe considerarse con cuidado y ser lo más amplio posible sin sobrecargar al equipo. Cuanto más amplio sea el alcance, más probabilidades tendrás de obtener la participación de los investigadores de seguridad. Sin embargo, no hagas que el alcance sea tan amplio como para que tu equipo no pueda mantenerse al día con los informes entrantes. Comienza con algunos recursos dentro del alcance. Expande el alcance a medida que tengas una mejor idea del volumen de informes que recibirás. Con el tiempo, antes de abrir el VDP al público, procura tener todo dentro del alcance.
En términos de cómo definir el alcance dentro de la política del programa, agregar detalles sobre cada recurso o área ayudará a los investigadores de seguridad a saber qué es importante para ti y dónde enfocar sus esfuerzos. También puedes incluir sugerencias sobre cómo realizar pruebas de forma segura con tus elementos. Por ejemplo:
| Asset | mail.example.com |
|---|---|
| Descripción | Dominio principal donde los usuarios pueden acceder a su correo electrónico. |
| Impactos y vulnerabilidades interesantes |
|
| Problemas que probablemente se rechacen |
|
| Lineamientos para las pruebas | Realiza pruebas solo con cuentas de tu propiedad o con las que tengas consentimiento expreso para realizarlas. Cuando crees cuentas de prueba, incluye "pruebavdp" en algún lugar del nombre de usuario. Puedes crear cuentas de prueba en mail.example.com/new. |
Este es un desglose bastante detallado. Como alternativa, puedes incluir una lista simple de los recursos que están dentro y fuera del alcance:
Dentro del alcance
- mail.example.com
- example.com
Fuera de alcance
- blog.example.com
Asignación de recursos para el VDP
Deberás contar con ciertos recursos antes de lanzar un VDP. Necesitarás recursos para lo siguiente:
- Revisión de los informes de vulnerabilidad entrantes
- Cómo comunicarse con hackers
- Cómo buscar propietarios de activos y registrar errores
- Corrección de errores
- Administración de vulnerabilidades y seguimiento de la solución
Revisar a los principales interesados
Si aún no lo has hecho, revisa las conversaciones con las partes interesadas clave con las que hablaste antes para asegurarte de que estén alineadas con el cronograma de lanzamiento del VDP y de la puesta en cola de los recursos necesarios. Por ejemplo, es posible que desees trabajar con los líderes de ingeniería para asegurarte de que sus equipos estén listos para trabajar con un posible flujo de errores de seguridad en las primeras semanas después del lanzamiento. En tu equipo de seguridad, asegúrate de que las alertas de clasificación de tus sistemas de detección y respuesta estén al tanto de la fecha de lanzamiento de VDP y considera asignar más tiempo y recursos para cuando comiencen las pruebas. También deberás crear un equipo que te ayude a respaldar las operaciones diarias del VDP.
Construye tu equipo
Ejecutar un VDP requiere una cantidad aceptable de trabajo operativo impulsado por interrupciones. Si intentas revisar, validar técnicamente y responder a cada informe de vulnerabilidad que llega, además de informar cada error, realizar un seguimiento de los estados y comunicar las actualizaciones a los investigadores por tu cuenta, es posible que te agotes. Incluso si no tienes un equipo de seguridad grande, busca voluntarios orientados a la seguridad que ayuden a formar un equipo para que te ayude a poner en funcionamiento y ejecutar el VDP. Necesitarás un "propietario" o "líder" definido del VDP que sea, en última instancia, responsable del éxito del VDP, pero también necesitarás un equipo que lo apoye.
Crear un cronograma de turnos
Una vez que tengas los recursos a bordo y estés dispuesto a ayudarte con el VDP, establece un cronograma de turnos. Puedes crearlo como quieras, pero una rotación semanal es una práctica bastante común. Cuando estés de servicio durante la semana, es tu responsabilidad hacer lo siguiente:
- Evaluación: Revisar los informes de vulnerabilidad con contenido nuevo
- Validar el informe de forma técnica y tomar una decisión de "aceptar" o "rechazar"
- Comunica tu decisión al hacker que informó el problema.
- Si es necesario, pídele más información al hacker si no puedes reproducir el problema
- Si la vulnerabilidad es válida, envía un error corregido al propietario correcto.
- Administración de vulnerabilidades: promueve las vulnerabilidades existentes
- Revisa los errores presentados durante las últimas semanas de servicio para asegurarte de que la solución esté progresando según tus estándares de gravedad y cronogramas de soluciones.
- Usa las sugerencias de cómo buscar propietarios para persuadirlos de que trabajen en estos errores.
- Comunicarse: Proporciona actualizaciones a los investigadores de seguridad sobre los informes existentes.
- Los investigadores pueden solicitar de forma proactiva actualizaciones sobre los informes existentes. Verifica esto y responde según sea necesario.
- Si se corrige una vulnerabilidad, comunícaselo al investigador para que sepa que su arduo trabajo generó un cambio positivo en tu organización. Incluso puedes incluir lenguaje de plantilla que le pida al investigador que te haga saber si omitiste algo en tu corrección o si se podría omitir de alguna manera.
Según la cantidad de informes que recibas, la complejidad de estos, y las habilidades y el conocimiento de la persona de trabajo, estar de servicio puede llevar desde unas horas hasta toda tu semana. Las sugerencias para lograr una rotación de turnos exitosa son las siguientes:
- Asegúrate de que tu equipo esté listo para intervenir y ayudar a brindar asistencia en las semanas particularmente pesadas.
- Debes contar con un buen proceso de transferencia. Si hay problemas que podrían requerir la atención inmediata de la siguiente persona de turno, escribe algunas notas de traspaso o ten una conversación en vivo al final de la semana.
- Crea un cronograma automatizado para garantizar que todos sepan cuándo están de turno. Esto puede ser tan simple como crear entradas de calendario recurrentes para cada persona.
- En particular, al comienzo del VDP, vuelve a consultar con la persona de trabajo para asegurarte de que recuerde que es su semana y para saber si necesita ayuda. Si tienes recursos más jóvenes en la rotación, solicita que más recursos de alto nivel trabajen con ellos para asegurarte de que se sientan cómodos y puedan hacer preguntas a medida que avancen.
- Implementa un proceso flexible para cambiar de semana. Inevitablemente, alguien tendrá una emergencia y necesitará tomarse tiempo libre durante la semana, o alguien se tomará vacaciones, etc. Cuando esto suceda, anima al equipo a intercambiar semanas según sea necesario para adaptarse a los horarios de todos.
- Crea una "hoja de referencia" que describa las tareas que se deben cubrir, incluida la documentación sobre cómo hacerlo.
Decidir la configuración interna y de terceros
La mayor parte de la orientación hasta ahora se basó en que creaste y ejecutas el VDP de forma interna. Hay una variedad de plataformas y servicios de consultoría disponibles que pueden ayudarte a crear y ejecutar un VDP. Estos servicios de terceros suelen tener un costo, pero pueden ser útiles para guiarte en la creación, el lanzamiento y la ejecución del VDP. Algunos incluso ofrecen servicios de clasificación para ayudarte a revisar los informes de vulnerabilidad entrantes, controlar la comunicación con los hackers y solo escalar informes válidos a tu equipo. Decidir si creas este proceso de forma interna o si usas una plataforma de terceros dependerá de tus requisitos y de los recursos disponibles. Si tienes un gran presupuesto, pero no mucho personal, puede tener sentido recurrir a un tercero para que te ayude a ejecutar el programa. Si es al revés, puede valer la pena invertir tiempo para crear tu programa tú mismo.
Cómo recibir informes
Si decides usar una plataforma de terceros, estos deben tener un método para que los hackers te envíen los informes directamente. Si creas el programa internamente, tendrás que hacerlo tú mismo. Puede ser una dirección de correo electrónico que cree automáticamente un ticket o un error en tu Herramienta de seguimiento de errores (p.ej., seguridad@example.com) o puede ser un formulario web con campos obligatorios que esté vinculado desde la política del programa o en la misma página. Independientemente de la forma que tome, esta es la mejor oportunidad para informarles a los hackers sobre el formato en el que deseas recibir tus informes. Ten en cuenta que pedirles a los hackers que envíen informes en un formato determinado no siempre garantiza que lo harán, pero no viene mal pedirlo. Este es un ejemplo de lo que podrías pedir en un formulario de envío de informe:
Título: [Agrega una descripción de una línea sobre el problema, p.ej., "XSS in
mail.example.com
results in session theft"]
1.
2.
3.
Situación del ataque e impacto: [¿Cómo se podría explotar esto? ¿Qué impacto
de seguridad tiene este
problema?]
Consejos para solucionar este problema: [De manera opcional, si tienes algún consejo sobre cómo solucionar o solucionar este problema, agrégalo aquí].