Seguridad de aplicaciones o Cómo incrustar seguridad en el desarrollo personalizado. Experiencia personal en AGIMA

Las agencias digitales están prestando cada vez más atención a la seguridad de la infraestructura en la que se están desarrollando, y también están comenzando a buscar garantizar la seguridad de las aplicaciones. Probablemente leyó sobre la variedad y la importancia de las vulnerabilidades, las herramientas y los métodos para proporcionar seguridad de la información. ¿Pero cómo ignorar o garantizar la seguridad de la aplicación afecta el proceso de desarrollo personalizado en sí?

¿Qué hay en el artículo?

No repetiremos por centésima vez por qué la seguridad es tan importante, qué vulnerabilidades existen o cómo el Equipo Rojo derrota al Equipo Azul en la próxima batalla. Esta es una historia corta sobre por qué agregamos seguridad al desarrollo personalizado y cómo lo hicimos.

¿Para quién es el artículo?

El artículo puede ser de interés para gerentes de proyecto, directores técnicos, líderes de equipo y todos los que de alguna manera se relacionan con la organización de procesos de desarrollo de aplicaciones.

Descargo de responsabilidad:

Este artículo no es una panacea, sino solo una opinión puramente personal del autor (Alexey Klinov, jefe de seguridad de la información de AGIMA).

Como empezó todo

AGIMA lleva mucho tiempo involucrado en el desarrollo integral de los procedimientos de control de calidad y el departamento de control de calidad. Todos nuestros productos se someten a numerosos controles internos:

• usar listas de verificación después de cada etapa / sprint del desarrollo del producto;
• Cubrimos la funcionalidad crítica del negocio con una red de pruebas automáticas;
• Intentamos cubrir el código con pruebas unitarias tanto como sea posible;
• Utilizamos analizadores de código que cumplen con los estándares (por ejemplo, para PHP es PSR 0-4, etc.);
• Realizamos pruebas de carga sin falta.

Se pueden encontrar más detalles sobre nuestros procesos en el artículo . Pero, ¿por qué decidimos agregar otra frontera de prueba?

Por cliente

Muchos clientes buscan vulnerabilidades por su cuenta: usan escáneres instrumentales o realizan pruebas de lápiz. De una forma u otra, nuestro código y proyectos en general a menudo se someten a una variedad de controles por parte del cliente.
El número de verificaciones aumentó, los informes sobre los resultados del escaneo instrumental y las pruebas con lápiz se hicieron cada vez más. Estudiar, reproducir, aprobar y corregir vulnerabilidades consumió muchos recursos internos y podría retrasarse por semanas.

De mano en mano cuando alguien más estaba desarrollando un proyecto

A veces los proyectos se heredan de otro contratista. Pueden estar en estado de preventa y "en batalla". La responsabilidad del trabajo ya está en nosotros, y todo el "carrito" de errores y vulnerabilidades, por extraño que parezca, también.
Sugerimos que es más eficiente y más barato tener nuestra propia experiencia en esto.

¿Qué se interpuso en el camino?

Al desarrollar, nos centramos en la calidad de la aplicación, la velocidad de su puesta en marcha y el costo. Al agregar elementos adicionales en forma de análisis de código para vulnerabilidades, una línea de prueba o empleado más afectará estos indicadores. Dado el bajo margen del negocio, esto es crítico para el desarrollo personalizado. Al mismo tiempo, para optimizar los costos, el enfoque del control de seguridad de los productos debe ser universal y aplicarse a todos los proyectos. Pero los clientes generalmente no dicen "haznos la misma aplicación que esos tipos de allí, solo verde". Los clientes desean no solo su diseño, sino también su funcionalidad. Además, cada sector empresarial tiene sus propias necesidades: los requisitos para las aplicaciones en el sector financiero, la medicina y el comercio minorista son diferentes. El equipo y la tecnología en cada proyecto pueden ser muy diferentes.

Obviamente, el control de seguridad del producto mejora su calidad. Pero, ¿cómo afectará el análisis de seguridad el costo y el tiempo de los proyectos?

Al agregar una revisión adicional del código a la estimación, inicialmente hacemos que el proyecto sea más costoso y aumentamos el tiempo de desarrollo, al igual que con otros tipos de pruebas. Pero este presupuesto aún tendría que gastarse, solo que menos sistemáticamente y más dolorosamente. De hecho, el producto en la salida es más "limpio", lo que reduce el nivel de deuda técnica, elimina la necesidad de gastar mucho tiempo y recursos en el refinamiento después de las pruebas con pluma, y, en consecuencia, se reduce el tiempo para poner el producto en producción.
Mirando hacia el futuro, en nuestro caso, la implementación del análisis de seguridad resultó ser más barata y más rápida, teniendo en cuenta todo el ciclo del proyecto. Los costos en algunos proyectos se redujeron al 20%, incluso reduciendo el tiempo para localizar vulnerabilidades y eliminándolos incluso antes de que el equipo de revisión de código lidere.
Se decidió encontrar la mejor manera de implementar la seguridad de la información en nuestros procesos de desarrollo.

Primeros pasos

Nuestra opinión sobre la mejora de la seguridad de las aplicaciones:



La protección WAF y DDoS son capas adicionales de protección en el producto. Y para nuestros propósitos, necesitamos un analizador de código para vulnerabilidades y una prueba de lápiz.

Pequeño cubo

Al elegir un analizador para comenzar, excluimos los productos caros pagados. Nos detuvimos en SonarQube , un analizador que tiene una versión shareware. También hay una versión en la nube , pero la versión gratuita hace que los proyectos estén completamente abiertos, lo que en nuestro caso es inaceptable.
Por lo tanto, para comenzar: SonarQube Community Edition. Es compatible con 15 idiomas, incluidos Java, JavaScript, C #, PHP y Python. La solución se implementa con bastante rapidez y no causa ningún problema especial, esto se ve facilitado por una guía detallada.



Sistema conveniente de diferenciación de derechos: puede construir una matriz de acceso a cada proyecto.



SonarQube le permite observar la dinámica del proyecto y almacena el historial de análisis. Nosotros mismos podemos establecer un umbral de calidad para cada proyecto, lo que nos permite optimizar el análisis para diferentes proyectos.





Probamos el producto en varios proyectos:

1. Fue posible detectar varias vulnerabilidades no obvias en los proyectos actuales.
2. El tiempo de implementación fue mínimo.
3. Nos aseguramos de que dentro del marco de CI, el código se devuelva para su revisión indicando vulnerabilidades potenciales.

Decidimos que esto es suficiente para nuestros esfuerzos.

Que sigue

Para nosotros, identificamos tres enfoques que varían según los proyectos y las necesidades del cliente:

• Integración total en el proceso de desarrollo (CI / CD).
• Auditoría de seguridad en puntos de control.
• Auditoría de seguridad situacional o única.

Integración total en el proceso de desarrollo.

Integramos la solución en GitLab. Usé GitLab CI / CD para automatizar el lanzamiento de cheques. Esto requirió el complemento gratuito Sonar GitLab Plugin . El sistema notifica a los desarrolladores las confirmaciones que fallan en la verificación y agrega comentarios que describen el área del problema (tipo de vulnerabilidad, recomendaciones para solucionarlo y otros).
Uno de los proyectos implementó la integración con Bitbucket y Bamboo. En este caso, se requerían los complementos pagados Sonar para Bamboo y Sonar para Bitbucket Server . Después de la operación de prueba, el cliente estaba listo para costos adicionales, la solución encajaba perfectamente en la pila tecnológica.



La opción ideal es cuando los plazos, el presupuesto y el cliente nos permiten integrar nuestros procesos de seguridad en el ciclo diario de trabajo con el código. En la práctica, resultó que este enfoque es relevante para el desarrollo a largo plazo y el apoyo de proyectos con lanzamientos frecuentes.

Auditoría de seguridad de punto de control

Para nosotros, este enfoque fue óptimo para proyectos donde los lanzamientos son raros, por ejemplo, una vez por trimestre. La funcionalidad o los requisitos del producto pueden cambiar durante la operación. Si observa constantemente cada línea del código en busca de seguridad, se dedica mucho tiempo adicional a esas piezas del producto que nosotros y el cliente podemos rechazar más tarde.

¿Qué nos relacionamos con los puntos de control?

• Hito lógico en el desarrollo de MVP.
• Lanzamiento de una versión específica del producto que contiene la funcionalidad crítica de interacción del usuario.
• Una versión específica, sprint o un conjunto de sprints, que también tiene una funcionalidad crítica para interactuar con el usuario.

En proyectos clave, comenzamos a combinar análisis integrado con auditorías de seguridad en puntos de interrupción. Por lo tanto, identificamos vulnerabilidades que podrían pasar desapercibidas durante el proceso de desarrollo.

Con este enfoque, reducimos el número de iteraciones de depuración al poner el producto en operación comercial. Estamos preparando un conjunto común de correcciones y mejoras, que incluye errores funcionales, vulnerabilidades de seguridad de la información y requisitos de infraestructura.

Hemos recopilado estadísticas sobre los costos de tiempo con un procedimiento de validación IS integrado en y sin puntos de control. Medimos solo las actividades de depuración y liberación en un entorno productivo.
Con un enfoque integral, en promedio, se requieren dos iteraciones de depuración. Su duración total es de ~ 15-20% del tiempo total de desarrollo.
Al conectar a terceros a la validación de seguridad de la información, se obtuvieron un promedio de dos iteraciones de depuración funcional y tres iteraciones de depuración de vulnerabilidades de seguridad de la información / requisitos de infraestructura. En total, esto ascendió a ~ 45% del tiempo total de desarrollo, excluyendo el tiempo dedicado por terceros, solo de nuestro lado.

Auditoría de seguridad situacional o única

Para proyectos simples, decidimos aplicar el enfoque con una verificación única de toda la base de código antes del lanzamiento final. El aterrizaje es suficiente para verificar una vez antes del lanzamiento. Implementar el escaneo de código en un proceso o hacer verificaciones intermedias en tales proyectos es costoso y no tiene sentido.

Además, comenzó a llevarse a cabo una auditoría situacional de proyectos que otros desarrolladores nos transfirieron. Antes de continuar con el desarrollo, minimizamos la deuda técnica existente del producto. Después de eso, determinamos qué enfoque para el control de seguridad usaremos en el desarrollo posterior del proyecto.

Este es el resultado de escanear un proyecto que no ha sido sometido a una auditoría completa de errores y seguridad durante varios años:



¡Más de 700 artefactos de vulnerabilidad! Por supuesto, si filtra todos los falsos positivos y artefactos menores, dejando solo bloqueadores y críticos, la imagen no será tan terrible. Pero este es el equipaje de la deuda técnica, que en cualquier caso debe ser procesado.



Clasificamos las vulnerabilidades y compilamos una hoja de ruta, donde observamos cuántas iteraciones deben eliminarse las vulnerabilidades críticas. Depende del código que afecten, qué datos se pueden obtener utilizando estas vulnerabilidades. ¿Qué posibilidades hay de que un atacante explote una vulnerabilidad particular?

Para este caso, pasamos más de 200 horas hombre "tamizando" y eliminando las vulnerabilidades encontradas, y solo después de eso comenzamos el desarrollo completo del producto. A veces es necesario resolver tales casos, ya que estar en la ignorancia es mucho más costoso.

No nos detuvimos allí:

• Análisis agregado a la mayoría de los proyectos.
• Las herramientas de control de seguridad se complementaron con appScreener de Rostelecom-Solar.
• Se agregó auditoría manual y prueba de pluma para proyectos clave.
• Se introdujeron grupos de criterios y niveles de criticidad para la funcionalidad implementada en términos del impacto en la seguridad de la aplicación.

Entonces, ¿qué sigue?

Los esfuerzos para implementar la seguridad de la información en los procesos de desarrollo personalizado nos han beneficiado:

• Reducimos los riesgos de reputación tanto para nosotros como para nuestros clientes, minimizando la posibilidad de piratear nuestras aplicaciones.
• Casi hemos desaparecido las largas etapas de depuración de aplicaciones después de las pruebas de penetración realizadas por organizaciones de terceros.
• Hemos incrementado las competencias de los empleados en el campo de la seguridad de la información y planeamos seguir avanzando en esta dirección: formar nuevos líderes de seguridad, enriquecer nuestra base de conocimiento, refinar nuestros enfoques y probar otros nuevos.
• Hemos recibido una excelente ventaja competitiva sobre otras compañías que brindan servicios de desarrollo personalizados y no tienen competencias de seguridad de la información.

Cuanto más avancemos hacia la mejora de la seguridad de la información, más puntos veremos para el crecimiento: agreguemos a nuestros procedimientos verificaciones no solo para TOP-10 OWASP y CWE / SANS, sino, por ejemplo, agilice el seguimiento de los boletines de seguridad o enseñe a nuestro CI a usar la guía de seguridad para nuestros marcos

Ya celebramos nuestro primer evento IB ( Rostelecom-Solar Business Dinner - AGIMA ), escribimos este artículo y planeamos continuar trayendo nuevas prácticas a nuestro mercado, como lo hicimos con el diseño adaptativo en nuestro tiempo (ver Adaptoz o nuestro diccionario adaptativo). diseño , lanzado en 2013): fue con nosotros cuando comenzó esta tendencia, y ahora se ha convertido esencialmente en el estándar de facto. Queremos hacer lo mismo con la seguridad de la información, porque "cuando enseñas a otros, aprendes a ti mismo".