Preparación

En esta sección, analizaremos en detalle cómo preparar tu organización para lanzar y ejecutar un programa exitoso de divulgación de vulnerabilidades, incluidos consejos prácticos sobre cómo llenar los vacíos que identificaste.

Cómo encontrar errores

Mejorar tu programa de seguridad existente con investigadores de seguridad externos es una excelente manera de encontrar problemas complejos y ocultar vulnerabilidades. Sin embargo, usar un VDP para encontrar problemas de seguridad básicos que podrían descubrirse internamente es un desperdicio de recursos.

Administración de recursos

Cuando se trata de encontrar errores, la única forma de saber por dónde empezar es si tienes una buena idea de lo que hay disponible. Puedes comprar cien herramientas de seguridad, pero no cambiará nada si los equipos ponen en marcha aplicaciones, sistemas y servicios ad hoc sin tu conocimiento, en especial si no tienes una forma de descubrir y realizar evaluaciones de seguridad con estos recursos. Consulta con las personas y los equipos responsables de ayudar a crear aplicaciones, sistemas y servicios nuevos a fin de ver si tienen un proceso para crear y mantener un inventario de lo que se implementa y quién es el propietario. Si no hay un proceso en curso, esta es una gran oportunidad para colaborar con estos equipos para crear uno. Comprender los recursos de tu organización es el mejor punto de partida para identificar la superficie de ataque. Como parte de este proceso, el equipo de seguridad debe participar en el desarrollo de la implementación de la infraestructura nueva para proporcionar revisiones de seguridad. Es una buena práctica tener un inventario amplio de activos y propietarios. Este tipo de inventario es útil cuando se aplican parches nuevos que requieren que ciertos sistemas se cierren temporalmente. Proporciona una hoja de ruta de las personas o los equipos que deben estar informados y qué sistemas se ven afectados. Tener un proceso sólido de administración de activos garantiza que los propietarios se identifiquen en las primeras etapas del proceso, se actualicen con regularidad y que todos los sistemas de la organización funcionen según lo previsto.

Además de la administración proactiva de recursos, considera qué medidas reactivas puedes implementar para identificar recursos que pertenecen a tu organización, pero que se pasaron por alto en tus procesos estandarizados de administración de recursos. Esto puede incluir el uso de los mismos procesos de "reconocimiento" que usan los investigadores de seguridad que participan en VDP y programas de recompensas por errores. Por ejemplo, puedes aprovechar herramientas gratuitas y de código abierto que analizan y enumeran rangos de IP orientados a Internet o dominios que pueden pertenecer a tu organización. Si buscas en Google reconocimiento de recompensas por errores, se producirá una variedad de sugerencias y trucos que te ayudarán a identificar recursos de tu organización que no conocías.

Análisis básico de vulnerabilidades

Ahora que tienes una base sólida en cuanto a dónde debes encontrar los problemas de seguridad, profundicemos en cómo hacerlo. Existen varios niveles de profundidad que puedes analizar según los recursos de tu organización, pero debes encontrar un equilibrio entre tus esfuerzos de seguridad interna y la comunidad externa de hackeo a través del programa de divulgación de vulnerabilidades. Este equilibrio es diferente para cada organización, según los recursos disponibles.

Elige tus herramientas

Existen muchas herramientas diferentes para ayudar a identificar las vulnerabilidades. Algunas herramientas de análisis de vulnerabilidades están disponibles de forma gratuita, mientras que otras tienen un costo. Determinar qué herramientas elegir depende de tus necesidades individuales.

• Los requisitos de tu organización
• Qué tan bien cada herramienta cumple con estos requisitos
• Si los beneficios de la herramienta superan los costos (financieros y de implementación)

Puedes usar esta plantilla de requisitos (OpenDocument .ods, Microsoft Excel .xlsx) para evaluar varias herramientas en función de tus requisitos. En la plantilla, se incluyen algunos requisitos de ejemplo, pero debes analizarlos con tus equipos de seguridad, ingeniería y TI para determinar cuáles son las capacidades requeridas. Antes de lanzar un programa de divulgación de vulnerabilidades, como mínimo, deberías poder realizar análisis de vulnerabilidades en relación con cualquier recurso externo (como sitios web, APIs y apps para dispositivos móviles). Esto te ayudará a encontrar y corregir vulnerabilidades fácilmente detectables antes de que invites a investigadores de seguridad externos para que realicen pruebas con estos recursos y servicios.

Configuración del análisis

Los análisis automáticos de vulnerabilidades pueden encontrar muchos problemas, pero también pueden producir falsos positivos. Por eso es necesario tener recursos para validar los resultados antes de compartirlos con los equipos afectados. Deberás implementar procesos para garantizar que los análisis se ejecuten de forma periódica y que sus resultados se aborden. Esto será diferente en cada organización, pero, como mínimo, deberás determinar lo siguiente:

• Frecuencia de búsqueda
  • Continua
  • semanalmente
  • Mensual
• Qué recursos se analizan
• Credenciales
  • Análisis autenticados y sin autenticar
  • Sugerencia: Si no analizas con credenciales y, luego, un investigador de seguridad realiza pruebas con credenciales cuando inicias el VDP, es posible que experimentes un gran aumento de vulnerabilidades identificadas.
• Funciones y responsabilidades
  • Identificar a los miembros del equipo responsables de ejecutar los análisis
  • Configura una rotación si es necesario
• Resultados del análisis
  • Verifica los resultados del análisis
  • Informar errores de vulnerabilidades verificadas
  • Identificar propietarios para corregir errores
  • Seguimiento con los propietarios sobre la solución

En la sección Cómo corregir errores que se encuentra más adelante en esta guía, veremos en detalle cómo garantizar que se corrijan los problemas de seguridad identificados.

Proceso de revisión de seguridad

Si bien el análisis de vulnerabilidades es una excelente manera de identificar de forma reactiva los problemas de seguridad en tu organización, implementar procesos de revisión de seguridad puede ayudar a evitar que se introduzcan vulnerabilidades en primer lugar. Para los fines de esta guía, el término revisión de seguridad hace referencia a cualquier situación que active una revisión manual por parte de un miembro de tu equipo de seguridad. Por lo general, esto incluye tener la autoridad para bloquear un cambio si se considera demasiado riesgoso. Si tu equipo de seguridad no puede bloquear cambios riesgosos, te recomendamos que implementes procesos para documentar el riesgo. Esto puede ayudar a garantizar que quien impulsa el cambio conozca el riesgo involucrado y lo acepte de forma proactiva.

Criterios de la revisión de seguridad

¿Cuándo deberían realizarse las revisiones de seguridad? Crear un conjunto de criterios que active una revisión de seguridad ayuda a garantizar que todos estén en sintonía. A continuación, se presentan algunos ejemplos de situaciones que pueden activar una revisión de seguridad.

• Se propone una nueva funcionalidad relacionada con los datos sensibles de los usuarios.
  • Una nueva función que permite a los usuarios compartir su ubicación en el mapa
  • Solicitar información potencialmente sensible de los usuarios, como su dirección particular, fecha de nacimiento o número de teléfono
• Se realizan actualizaciones importantes a las funciones existentes.
  • Tomar datos del usuario existentes y usarlos de una manera nueva que los usuarios podrían no esperar sin darles la oportunidad de rechazar
  • Cambios en cualquier función relacionada con la autenticación, autorización y administración de sesiones
• Cambios en el entorno de producción de la empresa
  • Cambios en la configuración de la red, en especial, los cambios que pueden provocar que los servicios se expongan de forma externa
  • Instalación de software nuevo que controle datos sensibles de los usuarios que, si se comprometieran, podrían usarse indirectamente para acceder a datos sensibles de los usuarios
  • Destacar nuevos sistemas o servicios
• Si interactúas con un proveedor nuevo o cambias tu forma de trabajar con uno existente
  • Incorporación de un nuevo proveedor que manejará datos sensibles de los usuarios
  • Cambios en la forma en que trabajas con un proveedor existente que genera que el proveedor controle datos sensibles del usuario

Esta lista no es exhaustiva, pero debería ayudarte a pensar qué tipos de cambios deberían requerir una revisión de seguridad. A medida que defines los criterios de lo que requiere y no una revisión de seguridad, habla con las partes interesadas clave de la organización para garantizar lo siguiente:

• Los interesados tienen la oportunidad de revisar y proporcionar comentarios sobre los criterios
• Los interesados aceptan los criterios
• Las partes interesadas acuerdan solicitar de forma proactiva revisiones de seguridad

Documenta estos criterios y cómo solicitar una revisión de seguridad (por ejemplo, informar un error en una cola que supervisa el equipo de seguridad) para que tu organización siga este proceso lo más fácil posible.

Recursos para la revisión de seguridad

A diferencia de los análisis automáticos, las revisiones de seguridad pueden requerir más recursos. Cada equipo de seguridad tiene poco tiempo en el día para realizar una gran cantidad de tareas, por lo que deberás estimar cuántas revisiones de seguridad se pueden generar según tus criterios. Si te das cuenta de que tu equipo se ve abrumado y se está quedando atrás, aquellos que esperan el lanzamiento de sus funciones se disgustarán con el equipo de seguridad. Esto puede provocar un cambio cultural en la organización, lo que provoca que se considere al equipo de seguridad como un obstáculo en lugar de un socio. Si el proceso de revisión de seguridad no es eficiente, muchas personas y equipos intentarán evitarlo por completo. Si los recursos son acotados, considera flexibilizar los criterios para requerir una revisión de seguridad y acepta un riesgo residual más. Si ocurren incidentes como resultado de la falta de recursos para realizar revisiones de seguridad, esto ayudará a justificar la necesidad de más recursos de seguridad.

Realización de revisiones de seguridad

A la hora de decidir qué revisiones de seguridad realizar y cómo llevarlas a cabo, necesitarás una cola priorizada de la cual extraer. Crea una manera estandarizada para que otras personas de tu organización soliciten una revisión de seguridad con la información que necesites a fin de priorizarla de forma adecuada. Por ejemplo, considera un cuestionario que incluya aspectos como la naturaleza del cambio, un breve resumen del cambio y los tipos de datos del usuario que se pueden ver afectados. Puedes categorizar automáticamente las posibles revisiones de seguridad en cambios de riesgo alto, medio o bajo según las respuestas a estas preguntas. Si un cambio es de alto riesgo, es posible que necesites un proceso de revisión de seguridad más detallado. Si un cambio es de menor riesgo, es posible que puedas implementar un proceso de revisión de seguridad más ligero para ayudar a reducir los recursos necesarios y acelerar el proceso, lo que permitirá mejorar la empresa. Considera configurar una rotación dentro de tu equipo para que sea responsable de administrar la cola de revisiones de seguridad, asegurarte de que los miembros de tu equipo recojan las nuevas revisiones de seguridad y hacer un seguimiento del progreso de las revisiones de seguridad existentes. El proceso real de la revisión de seguridad variará según lo que se examine. Por ejemplo, es posible que una función nueva en tu app para dispositivos móviles requiera que un ingeniero de seguridad revise el código y busque posibles vulnerabilidades. Es posible que se deba revisar el software nuevo que se instala para garantizar que el control de acceso esté configurado de forma correcta. Trabajar con proveedores externos puede presentar un proceso completamente diferente. A fin de obtener referencias, lee el Cuestionario de evaluación de seguridad de los proveedores de Google.

Corrección de errores

Es importante encontrar errores, pero la seguridad solo mejora una vez que se corrigen. Es bueno conocer los riesgos que existen en una organización, pero es mejor poder abordar ese riesgo de manera eficiente.

Administración de vulnerabilidades

Las vulnerabilidades provienen de una variedad de recursos, incluidos esfuerzos internos (por ejemplo, análisis de vulnerabilidades y revisiones de seguridad), pruebas de penetración y auditorías de terceros, o incluso investigadores de seguridad externos que te notifican a través de canales de asistencia antes del lanzamiento oficial del VDP. Tu organización necesita una forma de categorizar las vulnerabilidades nuevas y existentes para garantizar que se comuniquen a las partes interesadas correctas, se prioricen de forma correcta y se corrijan de manera oportuna. Cuando lances el VDP, tendrás un flujo nuevo de vulnerabilidades que ingresarán a los procesos de administración de vulnerabilidades. Tener procesos sólidos para controlar estas vulnerabilidades te ayuda a realizar un seguimiento del progreso hacia la solución y responder a las solicitudes de actualizaciones de investigadores de seguridad externos. Poder priorizar rápidamente una vulnerabilidad y comunicarte con los participantes del VDP acerca del cronograma de solución aumentará la participación con la comunidad de investigadores de seguridad y mejorará la reputación de la seguridad de tu organización. En las siguientes secciones, se describen varios aspectos del programa de administración de vulnerabilidades que debes implementar antes de lanzar el VDP.

Establece estándares de gravedad y cronogramas de soluciones

Crear un lenguaje común sobre la gravedad de las vulnerabilidades y los cronogramas de soluciones ideales asociados con cada gravedad facilita establecer las expectativas estándar en tu organización. Si todas las vulnerabilidades se tratan como una emergencia, la organización agotará sus recursos y se sentirá resentida con el equipo de seguridad. Si se considera que cada vulnerabilidad es de baja prioridad, las vulnerabilidades nunca se solucionarán y el riesgo de una violación de la seguridad aumenta. Todas las organizaciones tienen recursos limitados, por lo que deberás establecer una clasificación de gravedad. Esta clasificación proporciona criterios que ayudan a tu organización a comprender en qué gravedad se encuentra una vulnerabilidad y cronogramas de solución esperados asociados con cada gravedad. Redacta un conjunto de lineamientos de gravedad y compártelo con las partes interesadas clave de tu organización para recibir comentarios. Por ejemplo, si el equipo de ingeniería participa en la elaboración de tus estándares de gravedad, es más probable que acepten estos estándares y los cumplan cuando llegue el momento de corregir una vulnerabilidad en un período específico. Estos lineamientos de gravedad pueden variar según los riesgos específicos de tu empresa. Se recomienda realizar un ejercicio de modelado de amenazas para determinar cuáles son las amenazas más probables y que tienen más impacto en la organización y, luego, incluir ejemplos de problemas que se clasificarán en cada categoría de gravedad. A continuación, se muestra un ejemplo de estándares de gravedad y cronogramas de solución para una organización financiera.

Gravedad	Descripción	Cronograma de solución	Ejemplos
Crítico	Problemas que representan una amenaza inminente para los usuarios o la empresa.	Propietario: Un propietario principal que garantice que se solucione la vulnerabilidad debe identificarse en un plazo de 8 horas. Llama y localiza los recursos según sea necesario, incluso fuera del horario de atención normal. Solución: El problema en sí mismo debe corregirse, o bien se debe mitigar el riesgo lo antes posible o, como máximo, en un plazo de tres días hábiles.	Compromiso de una base de datos de producción que incluya los registros financieros de todos los usuarios Un atacante que obtiene acceso a secretos comerciales, como nuestros algoritmos de inversión de propiedad Un incidente activo en el que un atacante obtiene acceso a nuestra red interna o a nuestros sistemas de producción sensibles.
Alto	Problemas que, si se aprovechan, podrían causar un daño significativo.	Propietario: Se debe identificar a un propietario principal en el plazo de un día hábil. Solución: En un plazo de 10 días hábiles (aprox. 2 semanas).	Vulnerabilidades que podrían generar el acceso a funciones o datos sensibles del usuario (p. ej., la capacidad de cualquier usuario de robar fondos a otro)
Medio	Problemas que son más difíciles de aprovechar o que no generan daño directo.	Propietario: Se debe identificar a un propietario principal en un plazo de cinco días hábiles. Solución: En un plazo de 20 a 40 días hábiles (aproximadamente 1 a 2 meses).	Problemas verificados que identifican los análisis automatizados, como los parches de actualizaciones de seguridad sin vulnerabilidades conocidas Problemas de divulgación de información que probablemente ayudarían con otros ataques. Problemas de límite de frecuencia que podrían aprovecharse (p.ej., la capacidad de adivinar contraseñas para un usuario de forma continua).
Bajo	Problemas con impacto mínimo; se usan principalmente para registrar problemas conocidos.	No hay requisitos para encontrar un propietario o corregir un problema dentro de un cronograma especificado.	Divulgación de información que no presenta un riesgo probable, pero en la que no es necesario que la información sea accesible de forma externa

Errores de ciberacoso infantil

Aquí no nos referimos a cortes de pelo, sino a garantizar que los errores tengan el formato correcto para que se puedan corregir fácilmente. Con la tabla anterior como lineamiento, establece tus propias definiciones de gravedad. Estas definiciones se usan para clasificar los errores en varios niveles de gravedad y comunicarlos a los propietarios.

Además de asignar una gravedad a cada vulnerabilidad, deberás asegurarte de que los errores estén en un formato estándar que facilite el procesamiento de los equipos receptores. Las vulnerabilidades ingresarán a los procesos de administración de vulnerabilidades en diversos formatos (como los resultados de análisis automatizados o los análisis manuales de las revisiones de seguridad). Tomarse el tiempo para convertir cada vulnerabilidad en un formato estándar aumentará las posibilidades de que el equipo receptor pueda comprender y abordar el problema con rapidez.

Este formato o plantilla puede variar según la organización y la información que sea más pertinente para ayudar a los propietarios a corregir los errores que se les asignaron, pero aquí tienes una plantilla de ejemplo que puedes usar. Podrás reutilizar esta plantilla más adelante cuando crees el formulario de envío del programa de divulgación de vulnerabilidades para investigadores.

Título: <descripción de una línea del problema, por lo general, el tipo de vulnerabilidad y qué recurso, servicio/etc. se ve afectado; opcionalmente, incluye la gravedad o asigna la gravedad a un campo en tu herramienta de seguimiento de problemas> Resumen: <breve descripción de la vulnerabilidad y por qué es importante> Pasos de reproducción: <instrucciones paso a paso: cómo se puede

Este es un ejemplo de una posible vulnerabilidad de gravedad alta:

Título: [HIGH] Referencia a objetos directos no seguros (IDOR) en páginas de perfil Resumen: Se descubrió un IDOR en la funcionalidad de las páginas de perfil de nuestra app que permitiría a cualquier usuario obtener acceso no autorizado para ver y editar el perfil de otro usuario, incluidos el nombre completo, la dirección particular, el número de teléfono y la fecha de nacimiento. Revisamos los registros y este problema parece no haberse aprovechado todavía. Este problema se descubrió de forma interna. Pasos para reproducir el problema:

1. Configura un proxy, como Burp Suite) para interceptar el tráfico en un dispositivo móvil que tenga la app instalada.
2. Visita la página de tu perfil e intercepta la solicitud HTTP asociada.
3. Modifica profileID=###### para que sea profileID=000000 (este es un usuario de prueba) y envía la solicitud HTTP.
4. La app mostrará el perfil del usuario 000000 y podrás ver y editar su información.

Situación del ataque / impacto: Cualquier usuario puede usar esta vulnerabilidad para ver y editar el perfil de otro usuario. En el peor de los casos, un atacante podría automatizar el proceso de recuperación de la información de perfil de cada usuario en todo el sistema. Si bien aún no creemos que se haya explotado, es importante que lo tratemos como un problema de gravedad ALTA estándar. Si observamos evidencia de explotación, esto podría aumentar a una gravedad CRÍTICA. Pasos para la solución: Implementa verificaciones del servidor a fin de asegurarte de que el usuario que realiza la solicitud tenga acceso para ver o editar el perfil solicitado a través del valor de profileID. Por ejemplo, si Alice accedió a su cuenta con el ID de perfil 123456, pero se observa que Alice solicitó el ID de perfil 333444, el usuario debería ver un error y se debería registrar este intento de acceder al perfil de otro usuario. Para obtener más información sobre IDOR y cómo solucionarlo, consulta los materiales de OWASP sobre este error.

Puedes ahorrar tiempo y esfuerzo manual, ya que encuentra formas de automatizar las vulnerabilidades de conversión de varias fuentes en tu formato estándar. A medida que crees más vulnerabilidades, es posible que encuentres temas comunes en los pasos de corrección. Además de la plantilla genérica de formato de error, es posible que quieras crear plantillas adicionales para tipos de vulnerabilidad comunes.

Propietarios de resultados

Quizás uno de los aspectos más difíciles de la administración de vulnerabilidades es identificar a los propietarios para que ayuden a corregir errores y obtener su aceptación para dedicar recursos a fin de corregir los errores a tiempo. Si configuraste procesos de administración de recursos, esto será un poco más fácil. De lo contrario, esto podría servir como motivación para hacerlo. Según el tamaño de tu organización, encontrar un propietario puede ser bastante simple o increíblemente complejo. A medida que la organización crece, el esfuerzo para determinar quién es responsable de solucionar los problemas de seguridad recién descubiertos también aumenta. Considera implementar una rotación operativa de turnos. La persona que está de servicio es responsable de revisar las vulnerabilidades no asignadas, rastrear a los propietarios y priorizar según la gravedad. Incluso si puedes identificar quién es responsable de corregir una vulnerabilidad y asignarlo al error, también deberás persuadirlo para que invierta tiempo en corregirlo. Este enfoque puede variar según el equipo o la persona, y los otros elementos en los que trabajan. Si lograste una aceptación organizacional de tus estándares de gravedad y cronogramas de solución, puedes consultarlos, pero a veces puede requerir una persuasión adicional para conseguir que alguien corrija un error. Estas son algunas sugerencias generales para solucionar las vulnerabilidades:

• Explica por qué: Cuando a alguien se le asigna una vulnerabilidad que corregir, por lo general, es un trabajo inesperado. Explica por qué es importante solucionar este problema de manera oportuna (p.ej., la situación de impacto o ataque) y asegúrate de que el propietario lo comprenda.
• Reúne contexto: En algunos casos, solo una persona tiene el conocimiento necesario para corregir un error y es posible que tenga otras tareas en las que esté trabajando. Tómate el tiempo para descubrir cuáles son, ya que es posible que las demás tareas sean más importantes que corregir esta vulnerabilidad a corto plazo. Demostrar empatía y flexibilidad en los cronogramas de solución te ayudará a ganar buena voluntad y fortalecer tu relación con las personas que necesitas para solucionar vulnerabilidades. Solo ten cuidado de no dar demasiado margen, ya que, de lo contrario, tu organización no se tomará en serio tus cronogramas de soluciones.
• Explica cómo hacerlo: Incluso si incluyes consejos para solucionar el error, es posible que el propietario de la corrección del problema se confunda o necesite ayuda para aprender a solucionarlo. Si necesita ayuda para averiguar cómo solucionarlo, explícale cómo funciona. Enviarles errores a los propietarios sin ayudarlos perjudicará la relación de la organización con el equipo de seguridad. Ayudar a otros tanto como sea posible los fortalecerá para solucionar vulnerabilidades presentes y futuras, además de ayudar a enseñar a otros.
• Adapta tu solicitud: Es posible que varios equipos y personas tengan procesos existentes sobre la forma en que aceptan y priorizan las solicitudes de trabajo entrantes. Algunos equipos pueden querer que todas las solicitudes entrantes lleguen a través de sus gerentes. Otros querrán que las solicitudes de ayuda se envíen en un formato estándar. Algunos solo funcionarán en lo que se preestableció en un sprint. Cualquiera sea el caso, tomarse un tiempo adicional para adaptar la solicitud a fin de que se adapte al formato que el equipo o la persona suele usar para recibir las solicitudes de ayuda aumentará la probabilidad de que se priorice y tome medidas al respecto.
• Deriva el caso como último recurso: Si probaste todo lo anterior y la persona o el equipo responsable de corregir una vulnerabilidad no se tomarán el tiempo necesario para solucionar un problema de seguridad grave, considera derivar el caso al equipo directivo según sea necesario. Este siempre debe ser el último recurso, ya que puede dañar tu relación con la persona o el equipo en cuestión.

Análisis de la causa raíz

Además de encontrar y solucionar vulnerabilidades individuales, realizar un análisis de la causa raíz (RCA) puede ayudarte a identificar y abordar problemas de seguridad sistémicos. Todos los usuarios tienen recursos limitados, por lo que es tentador omitir este paso. Sin embargo, invertir tiempo en analizar las tendencias en los datos de vulnerabilidad, así como analizar en más detalle los errores críticos y de alta gravedad, puede ahorrar tiempo y reducir el riesgo a largo plazo. A modo de ejemplo, supongamos que observas que el mismo tipo de vulnerabilidad (por ejemplo, redireccionamiento de intents) aparece una y otra vez en toda la app. Decides hablar con los equipos que introducen esta vulnerabilidad en la app y te das cuenta de que la gran mayoría de ellos no comprenden qué es el redireccionamiento de intents, por qué es importante o cómo evitarlo. Organizaste una charla y una guía para educar a los desarrolladores de tu organización sobre esta vulnerabilidad. Es probable que esta vulnerabilidad no desaparezca por completo, pero es probable que disminuya la velocidad a la que aparece. Cuando inicias el VDP, cada vulnerabilidad que te informa un tercero es algo que se desliza por tus procesos de seguridad internos existentes. Si realizas el RCA por errores del VDP, obtendrás aún más información sobre cómo mejorar sistemáticamente tu programa de seguridad.

Detección y respuesta

La detección y la respuesta se refieren a cualquier herramienta y proceso que uses para detectar posibles ataques contra tu organización y responder a ellos. Podría ser mediante soluciones compradas o autodesarrolladas que analizan datos para identificar comportamientos sospechosos. A modo de ejemplo, en la sección Errores de ciberacoso infantil hablamos sobre el registro cada vez que un usuario intenta obtener acceso no autorizado al perfil de otro usuario. Es posible que tengas una señal o alerta que se genera si notas que un usuario genera una gran cantidad de intentos fallidos para acceder a los perfiles de otros usuarios en un período breve. Incluso puedes automatizar el proceso de bloquear el acceso de ese usuario a cualquiera de tus servicios durante un período determinado o de forma indefinida hasta que la situación se pueda revisar y restablecer el acceso de forma manual. Si aún no tienes mecanismos de detección y respuesta implementados, considera trabajar con un asesor experto que te ayude a crear un programa forense digital de respuesta ante incidentes (DFIR) para tu organización. Si ya cuentas con mecanismos de detección y respuesta, deberías considerar las consecuencias de tener cinco, diez o incluso cien investigadores de seguridad que realicen pruebas en tus superficies de ataque orientadas a Internet. Esto puede tener un gran impacto en cualquier IDS/IPS (sistemas de detección y prevención de intrusiones) que implementes.

Entre los riesgos posibles, se incluyen los siguientes:

• Sobrecarga de alertas: Es una gran cantidad de alertas o señales que parecen ataques maliciosos, pero que, en realidad, son pruebas normales y aprobadas de los investigadores de seguridad que participan en el VDP. Se puede generar tanto ruido que se vuelve difícil distinguir los ataques reales de las pruebas de seguridad legítimas.
• Falsas alarmas en la respuesta ante incidentes: Si tienes procesos en los que informan las personas a las 2:00 a.m. un sábado, no estarán contentos de despertarse ni de investigar una posible violación de la seguridad, que en realidad fue solo un investigador de seguridad que estaba realizando pruebas legítimas.
• Bloqueo de investigadores de seguridad: Si tienes IPS (sistemas de prevención contra intrusiones) agresivos, es posible que bloquees la dirección IP de un investigador de seguridad que intente ejecutar análisis, pruebas manuales, etc. para identificar vulnerabilidades y enviarte informes al respecto. Especialmente en el caso de un VDP, si se bloquea a un investigador de seguridad después de cinco minutos de pruebas, es posible que pierda el interés y se enfoque en el programa de otra organización. Esto puede provocar una falta general de participación en tu programa por parte de los investigadores de seguridad, lo que aumenta el riesgo de que permanezcan vulnerabilidades sin detectar (y, por lo tanto, desconocidas para tu organización). Si bien es posible que no quieras atenuar tu IPS, existen otras medidas que puedes tomar para mitigar el riesgo de inhabilitar a los investigadores.

La forma de abordar estos riesgos depende en gran medida del enfoque que quieras adoptar para trabajar con investigadores de seguridad externos. Si deseas un estilo de prueba más de caja negra que simule ataques reales, entonces es posible que no hagas nada. En este caso, el tráfico del investigador generará alertas, y tu equipo puede tomar medidas para investigar y responder según corresponda. Esto ayudará a tu equipo a practicar para responder a ataques que parecen reales, pero podría disminuir la participación de los investigadores de seguridad, en especial si se los bloquea de las pruebas. También puede provocar la pérdida de un ataque real mientras se dedica tiempo a investigar pruebas legítimas. Si prefieres un enfoque de caja gris, puedes trabajar con investigadores de seguridad para autoidentificar su tráfico de pruebas de alguna manera. Esto te permitirá incluir en la lista blanca o filtrar el tráfico de las pruebas y las alertas resultantes. Tu equipo podrá distinguir mejor los ataques reales de las pruebas aprobadas, y los investigadores podrán encontrar vulnerabilidades y enviarte informes sin que los sistemas de prevención de intrusiones los obstaculicen. Algunas organizaciones solicitan a los investigadores de seguridad que envíen un formulario para solicitar un identificador único que se puede adjuntar a los encabezados de las solicitudes que genera el investigador. Esto permite a la organización incluir el tráfico en la lista blanca para el investigador y también identificar si el investigador comienza a superar el alcance acordado de las pruebas. Si esto sucede, puedes comunicarte con el investigador y pedirle que se abstenga hasta que puedan trabajar juntos en un plan de prueba.