¿Cómo puedo ayudar a los desarrolladores a reducir la cantidad de mensajes instantáneos para mi equipo?

Muchos de los problemas descubiertos residen en el código de la aplicación y son vulnerabilidades clásicas de la aplicación, como se menciona en la documentación de OWASP. Solo corrigiendo el error dentro del código se remediarán las vulnerabilidades. Sin embargo, los desarrolladores asignaron historias con mucha frecuencia (dos dígitos en un solo día) a mí o a un miembro de mi equipo solicitando la validación de la solución, preguntas sobre la implementación, etc., de modo que interrumpe otro trabajo que tenemos: respuesta a incidentes, análisis de vulnerabilidades, revisiones de cumplimiento. etc.

Hablo con más de una década de experiencia en desarrollo de software. Si intenta resolver todas las vulnerabilidades conocidas en una sola versión, intentar validar cada solución tiene sentido, pero es extremadamente difícil escribir software que no tenga errores. Lo que significa que el equipo de desarrollo siempre reparará las vulnerabilidades, por lo que su empresa debe hacer otra cosa, de lo contrario, su equipo solo validará las correcciones de errores.

Su empresa debe identificar cómo se solucionarán estas vulnerabilidades. Su equipo de seguridad debe estar evaluando una compilación de lanzamiento potencial, antes de una fecha de lanzamiento potencial, que permita que la compilación se publique a tiempo y con la cantidad adecuada de vulnerabilidades de seguridad corregidas para esa compilación. Se debe permitir a los desarrolladores identificar qué vulnerabilidades de seguridad se han solucionado o no en esa compilación.

No quiero ralentizar el desarrollo de correcciones, ni parecer distante y poco dispuesto a ayudar. Hasta cierto punto, entiendo las acciones de los desarrolladores, ya que nuestro equipo son expertos en seguridad.

Los desarrolladores no necesitan ser expertos en seguridad para comprender cómo corregir una vulnerabilidad. Si se ha identificado una vulnerabilidad y se han identificado tanto el comportamiento inadecuado como el adecuado, entonces un desarrollador debería poder validar los resultados de una corrección de software en el comportamiento adecuado. Esto le permite a su equipo validar las correcciones, antes de una posible fecha de lanzamiento, con tiempo suficiente para que el equipo de desarrollo identifique qué errores quedarán para el próximo ciclo de lanzamiento.

¿Quizás una solución de base de conocimiento o wiki es el camino a seguir para que las preguntas se puedan compilar y responder de forma asincrónica? Los desarrolladores tienen diferentes niveles de experiencia y algunos necesitan más ayuda que otros.

Lamentablemente, no hay una respuesta única a esta pregunta, esto es algo que su empresa puede decidir.

¿Cómo puedo decir cortésmente que las solicitudes únicas a través de IM están empezando a ser inviables?

Usted tiene la capacidad de implementar cambios usted mismo, debe determinar qué sistema se utilizará para verificar si una solución potencial aborda o no una vulnerabilidad. Como líder del equipo, debe hablar con los líderes del otro equipo y determinar la mejor manera de avanzar. Debes permitir que esos líderes de equipo manejen el otro extremo de la cuerda, parece que tienes suficiente con lo que lidiar.

¿Por qué no un correo electrónico dedicado o un único chat de soporte?

Dedique a uno de sus empleados (parece ser el equivalente a un puesto de tiempo completo) a trabajar con los desarrolladores para responder esas preguntas y exija que todas las preguntas lleguen allí.

Podría ir aún más lejos y utilizar un sistema de emisión de boletos, que le permitiría consultar las preguntas respondidas anteriormente si se las vuelve a hacer.

Y probablemente pueda decirles a los desarrolladores que se requiere un cierto nivel de organización. Todos los desarrolladores que conozco se quejan de que los interrumpen, así que estoy seguro de que lo comprenderán una vez que comprendan la cantidad de preguntas que se les hace.

Horas de oficina. Designe horarios regulares en los que se le pueda contactar para hacer preguntas. O haga lo contrario, designe horarios regulares en los que su equipo apague la comunicación con el mundo exterior.

Para firmas y otras comunicaciones asincrónicas, use https://asana.com/ o use un wiki.

Pero tenga en cuenta que ninguna tecnología es perfecta. Muchos seguirán usando la mensajería instantánea debido a su conveniencia y porque creen que obtendrán una respuesta más rápida de esa manera.

Primero, no responderé a su pregunta (jeje) y sugiero que tal vez podría hacer un chat grupal en el software de mensajería instantánea que usa , donde se pueden publicar estas preguntas.

De esa manera, usted o cualquier otro miembro puede validar o responder cualquier pregunta que se haga allí, y las cosas pasadas que se han respondido se pueden consultar rápidamente.

Esto seguramente aliviará la carga de solo responder todos los mensajes.

¿Cómo puedo decir cortésmente que las solicitudes únicas a través de IM están empezando a ser inviables?

Escribiría un correo electrónico a los involucrados y les pediría cortésmente que resumieran sus preguntas o trataran de consultar primero con otros miembros.

Además, si acepta la sugerencia de chat grupal, puede escribir el correo electrónico y, en su lugar, anunciar cortésmente que dicho chat grupal ahora es el canal oficial para hacer / responder preguntas sobre las historias de los usuarios.

Parece que su sistema de trabajo remoto es lo que está mal aquí. Sugeriría tener un canal o grupo en el que puedan hacer preguntas y asignar a alguien de su equipo en un horario diario o semanal para responder estas preguntas. Dado que esta es una auditoría anual a la que me apegaría a diario y que la única responsabilidad de las personas es responder las preguntas de los desarrolladores durante ese día. ¿Reducirá la cantidad total de trabajo que su equipo puede hacer? Me arriesgaría a suponer que, a menos que su equipo esté formado por 1 o 2 personas, entonces no, seguirá haciendo mucho trabajo.

No puede generar un montón de tickets técnicos y esperar cero preguntas de la persona asignada para hacer el trabajo. Así que tienes que estar dispuesto a ayudar y eso significa ser interrumpido.

En términos de que los desarrolladores no sepan cuáles son las soluciones, esto es común, especialmente en equipos con desarrolladores menos experimentados. Así que apuntarlos a un wiki es realmente pobre. Parece que también hay muchas vulnerabilidades que usted puede detectar y que, para mí, deberían mencionarse en una de sus reuniones de administración que el trabajo no se está haciendo de acuerdo con las mejores prácticas y verificando las vulnerabilidades. Esa es realmente la responsabilidad de los gerentes de desarrollo/gerencia senior de contratar al personal correcto o capacitar al personal actual con la capacitación que considere adecuada. Digo que lo considera adecuado, ya que debe ser informado sobre qué capacitación necesitan los desarrolladores si están haciendo preguntas básicas que pueden responderse leyendo la lista OWASP.

Esta no es una situación poco común. Los equipos de desarrollo de todo el mundo ignoran XSS, inyección de SQL, etc. Como jefe del equipo de "InfoSec", es su responsabilidad enseñar a toda la organización lo importante que es la seguridad de la información y, si los desarrolladores no tienen ni idea, deben aprender. Todo esto se basa en el respaldo de la alta gerencia como si pensaran que estás haciendo una montaña de un grano de arena y que podrías convertirte en un wicket complicado.

Esta es una oportunidad tanto para los equipos de seguridad como para los de desarrollo. Los silos son muy comunes y tienes la oportunidad de romper algunos aquí. Me imagino que ambos equipos estarían muy interesados ​​en el entrenamiento cruzado y la colaboración. Pero antes de llegar tan lejos...

Creo que es muy importante recordar las dos culturas muy diferentes que tienes en esta situación.

En su ejemplo, el equipo de seguridad realizó un análisis y entregó los resultados, pero sin intención de escribir el código. Estás listo.

Los equipos de desarrollo de software tienden a ser más caóticos, colaborativos y disponibles. Incluso cuando el trabajo se completa, en realidad nunca se "termina". Siempre hay más trabajo por hacer en el proyecto y por eso los desarrolladores están disponibles pero también esperan que otros estén disponibles. Algo así como "Me pediste que hiciera algo, bueno, necesito hacerte preguntas al respecto para que lo hagamos bien". También tenga en cuenta que los desarrolladores generalmente solo tratan con personas de negocios o usuarios que tienden a estar altamente disponibles y dispuestos a hablar. Sin embargo, incluso en esta situación, especialmente en el mundo Agile, esto está organizado.

En una situación ideal, no necesitaría que todos los desarrolladores hablaran con todos todo el tiempo. Habría un gerente de proyecto organizando reuniones con solo las personas necesarias, líderes de equipo y propietarios de productos. De esa manera, los problemas y las preguntas pueden surgir en las personas adecuadas dentro de los equipos y las reuniones serán más eficientes.

La clave aquí es que necesita que alguien se haga cargo. Jefes de equipo y jefes de proyecto.

Para cualquier otra pregunta aleatoria única, cree un canal de chat grupal para que ambos equipos compartan, separado de sus propios canales, con el entendimiento de que las preguntas más importantes van a los clientes potenciales y los rápidos pueden ir a este canal informal.

Básicamente, recomiendo seguir un poco de Agile, que el equipo de desarrollo debería aprovechar. También debería poder hablar con su líder y resolver algo. A nadie le gusta cambiar de contexto o ser interrumpido y ambos equipos lo entienden.

Volviendo a la colaboración más permanente. Los espectáculos de estilo Meetup regulares y los hackathons probablemente contribuirían en gran medida a crear un vínculo de equipo serio. Prestar a una persona de seguridad para un sprint al equipo de desarrollo también sería probablemente una gran victoria. Y viceversa, hacer que un desarrollador se una al equipo de seguridad durante uno o dos sprints para ayudar con las secuencias de comandos. Realmente no puedo enfatizar lo suficiente lo valioso que es el entrenamiento cruzado. Hará que ambos equipos sean mejores.

Como desarrollador, puedo asegurarle que está experimentando algo que el equipo de desarrollo encontraría igualmente molesto, por lo que puede anteceder cualquier solicitud que haga con ese hecho. Básicamente, lo que debe hacer es ralentizar el flujo de solicitudes entrantes. Tenemos un gerente designado para recopilar las preguntas y enviarlas periódicamente, lo ideal es que elija un intervalo, digamos dos veces al día, por ejemplo, que reduce el impacto en su equipo, sin afectar indebidamente el impacto en el otro equipo.

El trabajo de su equipo no es encontrar problemas de seguridad. El trabajo de su equipo es hacer lo que pueda para reducir la cantidad de problemas de seguridad existentes. Eso no es exactamente lo mismo: significa que no solo tiene que encontrar problemas de seguridad, también debe proporcionar a los desarrolladores los medios para solucionar estos problemas de seguridad, y con la información que necesitan para priorizar lo que se soluciona primero, lo que se soluciona más tarde, lo que puede no arreglarse en absoluto.

Es por eso que recibe tantas solicitudes de información adicional: porque su equipo no hizo un buen trabajo en primer lugar. Como mínimo, esperaría para cada problema encontrado: ¿Cómo verifica un desarrollador que el problema está ahí? ¿Cómo verifica que el problema se solucionó? ¿Cuáles son las implicaciones del problema (qué puede suceder si no no se arreglará), y cualquier otra información que tenga sobre ese problema.

En lugar de preguntar "cómo manejo muchas solicitudes de información de los desarrolladores", debería preguntar "¿qué debo proporcionar a los desarrolladores para que no haya preguntas en primer lugar".

PD. "Ya hemos verificado a través de herramientas que todas las vulnerabilidades son aplicables con vectores de ataque válidos" no ayuda a los desarrolladores ni un poco. ¿Tienen las herramientas disponibles? ¿Tiene descripciones de qué hacer para provocar la vulnerabilidad, cómo verificar que se ha ido? Como dije, su problema es que no proporciona la información que necesitan los desarrolladores.

"Clasificación de la gravedad de los agujeros de seguridad": eso no me dice cuál es el impacto comercial, que es lo que decide en qué orden se deben aplicar las correcciones. Está hablando en un idioma que es extraño tanto para las empresas como para los desarrolladores. También pareces empeñado en no aprender.