Sécurité des applications ou Comment intégrer la sécurité dans le développement personnalisé. Expérience personnelle chez AGIMA

Les agences numériques accordent de plus en plus d'attention à la sécurité de l'infrastructure dans laquelle elles se développent et commencent également à chercher à garantir la sécurité des applications. Vous avez probablement lu sur la variété et la criticité des vulnérabilités, des outils et des méthodes pour assurer la sécurité des informations. Mais comment ignorer ou garantir la sécurité des applications affecte-t-il le processus de développement personnalisé lui-même?

Contenu de l'article:

Nous ne répéterons pas pour la centième fois pourquoi la sécurité est si importante, quelles vulnérabilités existent ou comment l'équipe rouge bat l'équipe bleue dans une autre bataille. Voici une courte histoire expliquant pourquoi nous avons ajouté la sécurité au développement personnalisé et comment nous l'avons fait.

À qui s'adresse l'article?

L'article peut intéresser les chefs de projet, les directeurs techniques, les chefs d'équipe et tous ceux qui ont un lien avec l'organisation des processus de développement d'applications.

Avertissement:

Cet article n'est pas une panacée, mais seulement une opinion purement personnelle de l'auteur (Alexey Klinov, responsable de la sécurité de l'information chez AGIMA).

Comment tout a commencé

AGIMA est impliquée depuis longtemps dans le développement complet des procédures de contrôle qualité et du département QA. Tous nos produits subissent de nombreux contrôles internes:

• utiliser des listes de contrôle après chaque étape / sprint de développement de produit;
• Nous couvrons les fonctionnalités essentielles de l'entreprise avec un réseau d'autotests;
• Nous essayons de couvrir le code avec des tests unitaires autant que possible;
• nous utilisons des analyseurs de code qui répondent aux normes (par exemple, pour PHP c'est PSR 0-4, etc.);
• Nous réalisons des tests de charge sans faute.

Plus de détails sur nos processus peuvent être trouvés dans l'article . Mais pourquoi avons-nous décidé d'ajouter une autre frontière de test?

Par client

De nombreux clients recherchent eux-mêmes les vulnérabilités: ils utilisent des scanners instrumentaux ou effectuent des tests de plume. D'une manière ou d'une autre, notre code et nos projets dans leur ensemble subissent souvent divers contrôles par le client.
Le nombre de contrôles a augmenté, les rapports sur les résultats de la numérisation instrumentale et des stylos-tests sont devenus de plus en plus nombreux. L'étude, la reproduction, l'approbation et la correction des vulnérabilités ont pris beaucoup de ressources internes et pourraient être retardées de plusieurs semaines.

De main en main lorsque quelqu'un développait un projet

Parfois, les projets sont hérités d'un autre entrepreneur. Ils peuvent être en état de prévente et «en bataille». La responsabilité du travail est déjà sur nous, et tout le «panier» de bogues et de vulnérabilités, curieusement aussi.
Nous avons suggéré qu'il est plus efficace et moins cher d'avoir notre propre expertise dans ce domaine.

Qu'est-ce qui vous a gêné?

Lors du développement, nous nous concentrons sur la qualité de l'application, la rapidité de sa mise en service et son coût. En ajoutant des éléments supplémentaires sous forme d'analyse de code pour les vulnérabilités, une ligne de test ou un employé supplémentaire affectera ces indicateurs. Compte tenu de la faible marge de l'entreprise, cela est essentiel pour le développement personnalisé. Dans le même temps, pour optimiser les coûts, l'approche du contrôle de sécurité des produits doit être universelle et appliquée à tous les projets. Mais les clients ne disent généralement pas "faites-nous la même application que ces gars là-bas, seulement vert." Les clients veulent non seulement leur conception, mais aussi leurs fonctionnalités. De plus, chaque secteur d'activité a ses propres besoins: les exigences pour les applications dans le secteur financier, la médecine et la vente au détail sont différentes. L'équipe et la technologie de chaque projet peuvent être très différentes.

De toute évidence, le contrôle de la sécurité des produits améliore sa qualité. Mais comment l'analyse de sécurité affectera-t-elle le coût et le calendrier des projets?

En ajoutant une révision supplémentaire du code à l'estimation, nous rendons initialement le projet plus cher et augmentons le temps de développement, tout comme avec d'autres types de tests. Mais ce budget devrait encore être dépensé, de manière moins systémique et plus douloureuse. En fait, le produit à la sortie est plus «propre», ce qui réduit le niveau de la dette technique, élimine la nécessité de consacrer beaucoup de temps et de ressources au raffinement après les tests, et, par conséquent, le temps de mise en production du produit est réduit.
Pour l'avenir, dans notre cas, la mise en œuvre de l'analyse de sécurité s'est avérée moins coûteuse et plus rapide, en tenant compte de l'ensemble du cycle du projet. Les coûts de certains projets ont été réduits à 20%, notamment en réduisant le temps de localisation des vulnérabilités et en les éliminant avant même que le chef de l'équipe de révision du code ne les dirige.
Il a été décidé de trouver le meilleur moyen de mettre en œuvre la sécurité de l'information dans nos processus de développement.

Premiers pas

Notre avis sur l'amélioration de la sécurité des applications:



La protection WAF et DDoS sont des couches de protection supplémentaires sur le prod. Et pour nos besoins, nous avons besoin d'un analyseur de code pour les vulnérabilités et d'un test de plume.

Petit cube

En choisissant un analyseur pour commencer, nous avons exclu les produits coûteux payés. Nous nous sommes arrêtés à SonarQube - un analyseur qui a une version shareware. Il existe également une version cloud , mais la version gratuite rend les projets complètement ouverts, ce qui dans notre cas est inacceptable.
Par conséquent, pour commencer - SonarQube Community Edition. Il prend en charge 15 langages, dont Java, JavaScript, C #, PHP et Python. La solution se déploie assez rapidement et ne pose pas de problème particulier, cela est facilité par un guide détaillé.



Système pratique de différenciation des droits: vous pouvez construire une matrice d'accès à chaque projet.



SonarQube vous permet d'observer la dynamique du projet et stocke l'historique d'analyse. Nous pouvons nous-mêmes fixer un seuil de qualité pour chaque projet, ce qui nous permet d'optimiser l'analyse pour différents projets.





Nous avons testé le produit sur plusieurs projets:

1. Il a été possible de détecter plusieurs vulnérabilités non évidentes dans les projets en cours.
2. Le temps de mise en œuvre était minime.
3. Nous nous sommes assurés que dans le cadre de CI, le code est renvoyé pour révision indiquant des vulnérabilités potentielles.

Nous avons décidé que cela suffisait à nos efforts.

Et ensuite?

Pour nous, nous avons identifié trois approches qui varient selon les projets et les besoins des clients:

• Intégration complète dans le processus de développement (CI / CD).
• Audit de sécurité aux points de contrôle.
• Audit de sécurité ponctuel ou ponctuel.

Intégration complète dans le processus de développement

Nous avons intégré la solution dans GitLab. GitLab CI / CD utilisé pour automatiser le lancement des vérifications. Cela nécessitait le plugin gratuit Sonar GitLab Plugin . Le système avertit les développeurs des validations qui échouent à la vérification et ajoute des commentaires décrivant la zone à problème (type de vulnérabilité, recommandations pour la corriger, etc.).
L'un des projets a mis en œuvre l'intégration avec Bitbucket et Bamboo. Dans ce cas, les plugins payants Sonar pour Bamboo et Sonar pour Bitbucket Server étaient requis. Après l'opération de test, le client était prêt pour des coûts supplémentaires, la solution s'intégrait parfaitement dans la pile technologique.



L'option idéale est lorsque les délais, le budget et le client nous permettent d'intégrer nos processus de sécurité dans le cycle quotidien de travail avec le code. Dans la pratique, il s'est avéré que cette approche est pertinente pour le développement et le soutien à long terme de projets à diffusion fréquente.

Audit de sécurité Checkpoint

Pour nous, cette approche était optimale pour les projets où les sorties sont rares, par exemple une fois par trimestre. Les fonctionnalités ou les exigences du produit peuvent changer pendant le fonctionnement. Si vous regardez constamment chaque ligne du code pour la sécurité, beaucoup de temps supplémentaire est consacré aux pièces du produit que nous et le client pouvons refuser par la suite.

Que rapportons-nous aux points de contrôle:

• Étape logique dans le développement de MVP.
• Sortie d'une version spécifique du produit contenant une fonctionnalité d'interaction utilisateur critique.
• Une version spécifique, un sprint ou un ensemble de sprints, qui possède également des fonctionnalités essentielles pour interagir avec l'utilisateur.

Sur les projets clés, nous avons commencé à combiner l'analyse intégrée avec les audits de sécurité aux points d'arrêt. Ainsi, nous identifions des vulnérabilités qui pourraient passer inaperçues au cours du processus de développement.

En utilisant cette approche, nous réduisons le nombre d'itérations de débogage lors de la mise en service du produit. Nous préparons un pool commun de corrections et d'améliorations, qui comprend des erreurs fonctionnelles, des vulnérabilités de sécurité de l'information et des exigences d'infrastructure.

Nous avons collecté des statistiques sur les coûts de temps avec une procédure de validation SI intégrée au niveau et sans points de contrôle. Nous avons mesuré uniquement les activités de débogage et de publication dans un environnement productif.
Avec une approche globale, en moyenne, deux itérations de débogage sont nécessaires. Leur durée totale est d'environ 15 à 20% du temps de développement total.
Lors de la connexion de tiers à la validation de la sécurité des informations, une moyenne de deux itérations de débogage fonctionnel et trois itérations de débogage des vulnérabilités de sécurité des informations / exigences d'infrastructure ont été obtenues. Au total, cela représentait environ 45% du temps de développement total, à l'exclusion du temps passé par des tiers, uniquement de notre côté.

Audit de sécurité ponctuel ou ponctuel

Pour les projets simples, nous avons décidé d'appliquer l'approche avec une vérification unique de la base de code entière avant la version finale. L'atterrissage est suffisant pour vérifier une fois avant la sortie. Mettre en œuvre l'analyse de code dans un processus ou effectuer des vérifications intermédiaires sur de tels projets est coûteux et inutile.

De plus, un audit de situation a commencé à être réalisé sur des projets qui nous ont été transférés par d'autres développeurs. Avant de poursuivre le développement, nous minimisons la dette technique existante du produit. Après cela, nous déterminons quelle approche du contrôle de sécurité nous utiliserons dans la poursuite du développement du projet.

C'est le résultat de l'analyse d'un projet qui n'a pas subi d'audit complet des bugs et de la sécurité depuis plusieurs années:



Plus de 700 artefacts de vulnérabilité! Bien sûr, si vous filtrez tous les faux positifs et les artefacts mineurs, ne laissant que des bloqueurs et des critiques, l'image ne sera pas si terrible. Mais c'est le bagage de la dette technique qui doit en tout cas être traitée!



Nous classons les vulnérabilités et compilons une feuille de route, où nous notons combien d'itérations les vulnérabilités critiques doivent être éliminées. Cela dépend du morceau de code qu'ils affectent, des données qui peuvent être obtenues en utilisant ces vulnérabilités. Quelle est la probabilité qu'un attaquant exploite une vulnérabilité particulière.

Dans ce cas, nous avons passé plus de 200 heures-homme à «tamiser» et éliminer les vulnérabilités trouvées, et ce n'est qu'après que nous avons commencé le développement de produits à part entière. Parfois, il est nécessaire de résoudre de tels cas, car être dans l'ignorance est beaucoup plus cher.

Nous ne nous sommes pas arrêtés là:

• Analyse ajoutée à la plupart des projets.
• Les outils de contrôle de sécurité ont été complétés par appScreener de Rostelecom-Solar.
• Audit manuel et test de plume ajoutés pour les projets clés.
• Introduction de groupes de critères et de niveaux de criticité pour la fonctionnalité implémentée en termes d'impact sur la sécurité des applications.

Et maintenant?

Les efforts visant à implémenter la sécurité de l'information dans les processus de développement personnalisés nous ont été bénéfiques:

• Nous réduisons les risques de réputation pour nous-mêmes et pour nos clients, en minimisant les possibilités de piratage de nos applications.
• Nous avons presque disparu les longues étapes du débogage des applications après des tests de pénétration par des organisations tierces.
• Nous avons accru les compétences des employés dans le domaine de la sécurité de l'information et prévoyons de continuer à évoluer dans cette direction: développer de nouveaux leaders de la sécurité, enrichir notre base de connaissances, affiner nos approches et en essayer de nouvelles.
• Nous avons reçu un excellent avantage concurrentiel par rapport à d'autres sociétés qui fournissent des services de développement personnalisés et n'ont pas de compétences en sécurité de l'information.

Plus nous progressons vers l'amélioration de la sécurité des informations, plus nous voyons de points de croissance: ajoutez à nos procédures des contrôles non seulement pour TOP-10 OWASP et CWE / SANS, mais par exemple, accélérez le suivi des bulletins de sécurité ou apprenez à notre CI à utiliser le guide de sécurité pour nos cadres.

Nous avons déjà organisé notre premier événement IB ( Rostelecom-Solar Business Dinner - AGIMA ), avons écrit cet article et prévoyons de continuer à apporter de nouvelles pratiques sur notre marché, comme nous l'avons fait avec la conception adaptative à notre époque (voir Adaptoz ou notre dictionnaire adaptatif design , sorti en 2013) - c'est avec nous que cette tendance a commencé, et est devenue aujourd'hui la norme de facto. Nous voulons faire de même avec la sécurité de l'information, car «lorsque vous enseignez aux autres, vous apprenez vous-même».