Los ataques más exitosos de una organización se implementan a través de vulnerabilidades y marcadores en el software. Afortunadamente, las compañías ya no consideran un escáner de vulnerabilidad de software como algo exótico, sino como un elemento necesario de la infraestructura de protección. Si con pequeños volúmenes de desarrollo puede usar el escáner tal cual, entonces, cuando los volúmenes son grandes, debe automatizar el proceso. ¿Pero quién debería manejarlo? ¿Decidir con qué frecuencia verificar los lanzamientos? ¿Verificación de vulnerabilidad? ¿Decidir si vetar el lanzamiento y enviar código para corregir las vulnerabilidades? Y responde muchas otras preguntas. Aquí es donde Application Security Manager, el gerente de desarrollo de software seguro, llega a la vanguardia.
¿Pero dónde encontrar un pájaro tan raro o cómo cultivarlo usted mismo? Artem Bychkov, gerente de seguridad de aplicaciones en Raiffeisenbank JSC, y Daniil Chernov, jefe de Rostelecom Solar, Solar appScreener, hablan sobre los requisitos para el administrador de seguridad de aplicaciones dictados por las prácticas de desarrollo en las empresas rusas.
Quién es el administrador de seguridad de aplicaciones
Las organizaciones, tarde o temprano, se dan cuenta de la necesidad de contratar a esa persona en el equipo. En particular, porque ninguno de los especialistas disponibles en la empresa es directamente adecuado para este papel. Desarrolladores? Su experiencia laboral está relacionada específicamente con el desarrollo de software: les resulta muy difícil traducir las vulnerabilidades encontradas en riesgos de SI, y aún más los riesgos para las empresas. Los guardias de seguridad? La inmersión en las complejidades del desarrollo es problemática para ellos: para verificar las vulnerabilidades, uno debe ser capaz de comprender los códigos de software en diferentes idiomas, lo que requiere una experiencia de desarrollo seria.
Echemos un vistazo a las tareas que surgen durante la implementación del proceso de desarrollo seguro, que debe abordar el Administrador de seguridad de aplicaciones (AFM).
El lector puede tener la opinión de que el trabajo del AFM está relacionado únicamente con la verificación de los desarrollos de software para el cumplimiento de los requisitos de seguridad. Pero los problemas de seguridad surgen en varias etapas del ciclo de vida del sistema, desde el diseño hasta la implementación y la producción. Existen varios modelos para construir un ciclo de desarrollo seguro (Software Security Touchpoints, SDLC y otros) y varios métodos para incorporar estas prácticas en el proceso (según el enfoque utilizado: cascada, ágil). Pero todos están de acuerdo en puntos clave: debe pensar en la seguridad en todas las etapas del ciclo de vida del sistema.
Obviamente, en el marco de un proyecto más o menos grande, es poco probable que una persona pueda realizar el trabajo en todas las etapas. Es raro que alguien pueda desarrollar los requisitos de seguridad de la aplicación, realizar una revisión de su arquitectura y verificar el resultado del trabajo de los analistas, realizar una auditoría de seguridad de código, verificar que las pruebas de seguridad de la aplicación necesarias se llevaron a cabo durante las pruebas y que el sistema se implementó de manera segura y se configuró correctamente. Además, a menudo estas actividades son realizadas por representantes de diferentes equipos y unidades. Para que todo el mecanismo funcione como debería, la fuerza impulsora del proceso debe ser AFM. La tarea de AFM es garantizar la implementación de prácticas de desarrollo seguras, ya sea por cuenta propia o delegando ciertas tareas a especialistas especializados. Sin embargo, según nuestra práctica, no es posible que la AFM simplemente entregue tareas a los responsables y descanse en sus laureles.
¿Cuáles son los requisitos para AFM?
En primer lugar, debe comprender el proyecto que acompaña. Esto es especialmente importante en el desarrollo ágil, cuando, a diferencia del modelo en cascada, no tiene 2 meses para realizar una revisión antes del lanzamiento. Depende de la AFM, por ejemplo, cómo los requisitos formados en la etapa de diseño serán interpretados por el equipo, cómo caerán en la arquitectura, si son generalmente factibles y si crearán serios problemas técnicos en el futuro. Muy a menudo, AFM es el principal consumidor, intérprete y evaluador de informes de instrumentos automatizados y auditorías realizadas por terceros. Es el AFM que filtra los resultados irrelevantes y erróneos, evalúa los riesgos y participa en los procesos de gestión de excepciones y el desarrollo de medidas compensatorias.
Aquí hay un ejemplo de vida: una auditoría o un escáner de código fuente reveló el uso de una función hash insegura (MD5) en un proyecto. La política de la compañía insiste formalmente en que no se puede usar, y el proveedor acepta reemplazar la función por una más segura en 3 meses y una gran cantidad. El matiz era que, en este caso, la inestabilidad de la función hash contra colisiones no afectaba la seguridad del sistema, ya que la función no se usaba para proteger la integridad. El enfoque formal en este caso y el reemplazo de una función por otra condujo a un tiempo irrazonablemente retrasado para que la producción del proyecto sea productiva y costos significativos, dando una ganancia cero en seguridad.
En segundo lugar, además del primero, el AFM debe tener conocimiento de varios campos: debe comprender los procesos de desarrollo y los principios de seguridad de la información. Las "habilidades difíciles" también son importantes, porque es muy difícil evaluar críticamente los resultados del trabajo de especialistas especializados y herramientas automatizadas, si no puede leer el código, no comprende las posibles formas de explotar las vulnerabilidades. Seguramente, muchos se enfrentaron a una situación en la que aparece una vulnerabilidad crítica en el análisis de código o en el informe pentest, pero los desarrolladores no están de acuerdo con esto (y, por regla general, también quieren crear un sistema seguro) e indican que los auditores no pudieron operarlo. vulnerabilidades ¿Cómo evaluar quién tiene razón en una situación similar? Sin habilidades técnicas, resolver objetivamente una disputa será difícil. Si el proceso de desarrollo de software seguro es creado por manos de una organización externa y / o de acuerdo con el modelo de servicio, ¿quién y cómo evaluará el desempeño de las prácticas "técnicas"?
Otro ejemplo de vida: se está introduciendo una nueva herramienta de desarrollo, su rendimiento se verifica en un proyecto de referencia, después de lo cual se transfiere a la operación comercial. Los proyectos se conectan gradualmente a él, se dibuja un hermoso tablero verde ... y aquí ocurre un incidente de seguridad de la información. Como resultado, el "agujero" usado debería haberse detectado en la etapa de análisis dinámico. Pero esto no sucedió, porque ... nadie miró, pero ¿cómo funciona este escáner de vulnerabilidades de gama alta, que generalmente produce excelentes resultados, funciona con aplicaciones SPA utilizando el nuevo marco JavaScript. Resultó que no podía "ver" el formulario de autenticación generado dinámicamente y hacer las verificaciones necesarias. Y nadie le prestó atención, porque todo funcionó. Los desarrolladores no tuvieron necesidad de profundizar en los detalles del funcionamiento de los escáneres para llamar la atención sobre esto, y los equipos de seguridad no vieron diferencias críticas entre los diferentes enfoques para el desarrollo web.
¿Dónde conseguir un especialista?
Quienes estudiaron el mercado deben haber enfrentado una grave escasez de expertos en seguridad de aplicaciones. Por lo general, el escenario es el siguiente: los clientes internos elaboran requisitos para el candidato y los transfieren al personal. Si los requisitos son estrictos, de acuerdo con los resultados de una búsqueda gratuita, la empresa recibe cero candidatos, ya que los especialistas ya preparados rara vez publican currículums en el dominio público. Si cambian de trabajo, esto ocurre con mayor frecuencia de manera fácil y natural a través de los contactos existentes. Como ser
Puede intentar atraer a un profesional de otras compañías, pero este camino no siempre es aceptable por varias razones. Cada vez con más frecuencia, aparecen en el mercado concursos de AFM con personal externo, que con bastante éxito le permite cerrar el problema alquilando expertos de un proveedor de servicios.
Pero hay otra opción. Puedes intentar hacer crecer tu profesional. Los representantes de dos áreas pueden ser candidatos adecuados para este rol:
- personas del desarrollo que les gusta o quieren desarrollarse en el campo de la seguridad;
- Guardias de tecnología que están familiarizados con el desarrollo de software y la seguridad y desean profundizar en este tema.
Tanto esos como otros candidatos deberán dominar el paquete de conocimiento que falta. Al mismo tiempo, las personas del desarrollo que deseen "reformarse" comprenderán mejor la cultura y los procesos existentes en los equipos que conocen. Puede llevarles bastante tiempo dominar las áreas de conocimiento relacionadas con la seguridad de la información. Sin embargo, la experiencia muestra que entre los desarrolladores, evaluadores, analistas y arquitectos, puede encontrar personas interesadas en la seguridad que ya tienen un cierto conjunto de conocimientos en el campo de la seguridad de las aplicaciones. Pueden ser candidatos ideales para un trabajo de AFM.
Los guardias de seguridad profesionales tendrán que aclimatarse, cambiando los enfoques familiares existentes para organizar el trabajo y adoptar la cultura en los equipos de desarrollo. Sin embargo, si un especialista en seguridad escribe código y está familiarizado con los procesos de desarrollo, se unirá al equipo de forma rápida y sencilla.
Total
El control de seguridad del desarrollo es principalmente un proceso comercial, para el funcionamiento exitoso del cual es necesaria una interacción coordinada de todos los miembros del equipo. El "corazón" de este proceso es un AFM calificado: es a la vez el inspirador y el motor direccional, y el ejecutor de muchas tareas, y el gerente de control, y muchos otros. En general, el lector, el segador y el tipo están en la tubería. Encontrar o criar a tal especialista no es fácil, pero si tiene éxito, todos estarán felices.