6 risques de sécurité dans le développement de logiciels et comment y faire face – Computerworld Italia

Depositphotos

Les DSI et leurs services informatiques sont confrontés à une forte pression commerciale pour moderniser les applications.L’objectif est d’améliorer l’expérience client, de migrer les applications vers le cloud et d’automatiser les flux de travail. Le développement agile et le devops comprennent les cultures, les pratiques, les outils et les automatisations qui permettent aux équipes de développement de logiciels d’atteindre ces objectifs et ffournir une valeur commerciale avec une qualité supérieure et dans des cycles de publication plus rapides.

Les équipes de développement les plus avancées disposent de pipelines d’intégration et de déploiement continus (CI/CD) entièrement automatisés, relient les flux de travail de gestion des changements et des incidents aux outils de développement agile, et utiliser les plateformes AIops pour trouver plus rapidement les causes profondes des problèmes de production.

Cependant, les problèmes de sécurité dans le développement des logiciels persistent. Dans ESG research on security for modern application development, seuls 36 % des répondants attribuent une note de 9 ou 10 à leur programme de sécurité des applications.En outre, 66 % des personnes interrogées ont déclaré que leurs outils de sécurité des applications protégeaient moins de 75 % de leur base de code, et 48 % ont admis qu’elles inséraient régulièrement du code vulnérable dans la production.

adv

Ces lacunes en matière de sécurité ne sont pas dues à un manque de technologie, de conseil ou de fournisseurs de sécurité. Le Cybersecurity Almanac 2020 identifie plus de 3 500 partenaires de sécurité potentiels. En fin de compte, la clé pour apporter une valeur commerciale en minimisant les risques de sécurité dans le développement de logiciels consiste à consiste à définir clairement les principes de sécurité et à les communiquer aux équipes de développement de logiciels. Voici six risques sur lesquels les DSI et les responsables informatiques devraient se concentrer et les moyens d’y faire face.

Risque n° 1 : ne pas traiter la sécurité comme un citoyen de première classe de devops

Il est facile de dire que l’organisation accorde la priorité à la sécurité, et de nombreuses organisations suivent les meilleures pratiques en matière de sécurité agile et devops. Mais les équipes de sécurité informatique sont souvent en sous-effectif par rapport au nombre d’équipes de développement, il est facile de voir comment les autres priorités de la dette technique et commerciale dominent le backlog des équipes agiles et pourquoi les pratiques de sécurité ne sont pas adoptées uniformément dans toute l’organisation.

La recherche ESG soutient cette conclusion. Alors que 78% des personnes interrogées disent que leurs analystes de sécurité impliquent directement les développeurs, seulement 31% examinent les caractéristiques individuelles et le code. Il s’agit d’une lacune importante, et il est peu probable que la plupart des organisations puissent engager suffisamment d’experts en sécurité pour les affecter en permanence aux équipes de développement agile. Mais voici ce que de nombreuses organisations peuvent faire :

  • Exiger une formation continue à la sécurité pour toute l’équipe de développement de logiciels
  • Demandez à l’infosecrétariat de documenter les normes de politique d’acceptation de la sécurité dans des outils tels que Atlassian Confluence ou Microsoft Teams et demandez aux équipes agiles de s’y référer.
  • Formaliser la collaboration sur la planification agile et la gestion des versions afin que l’infosec puisse signaler les fonctionnalités à haut risque dès le début du processus de développement.
  • Enregistrez et publiez les revues de sprint afin que l’infosec puisse signaler les implémentations à risque.

Définir les principes, assurer la collaboration entre les équipes, améliorer la culture et promouvoir le bonheur des équipes. sont peut-être les moyens les plus importants dont disposent les DSI pour contribuer à améliorer la sécurité des logiciels. Dans l’enquête communautaire DevSecOps 2020, les développeurs satisfaits étaient 3,6 fois plus susceptibles de prêter attention à la sécurité.

DevOps

Risque n° 2 : développement de mises en œuvre techniques propriétaires.

Les équipes de développement logiciel adorent coder et développer des solutions, et les organisations ont besoin de leur magie, de leur innovation et de leurs compétences techniques pour relever les défis commerciaux urgents. Mais parfois les exigences conduisent les équipes de développement à résoudre des défis techniques difficiles et des mises en œuvre qu’elles pourraient éventuellement adopter à partir de sources tierces.

Le low-code et le no-code sont parfois synonymes de solutions plus sûres. Il y a au moins deux raisons à cela. D’abord, Les propriétaires de produits agiles ne connaissent pas toujours les implications en matière de sécurité de leurs fonctionnalités de base. Deuxièmement, beaucoup peinent à formuler des exigences sans dicter les éléments de la solution, ce qui conduit parfois les équipes à mettre en œuvre des solutions à forte intensité de code qui introduisent des risques de sécurité.

Risque n° 3 : mauvaise gouvernance et gestion des composants à source ouverte et commerciaux.

Savez-vous comment les équipes devops sont les mieux équipées pour choisir leurs propres outils ? C’est une conviction souvent exprimée par les équipes devops avancées. Cependant, de nombreux DSI, responsables informatiques et RSSI il faut éviter de donner carte blanche aux équipes devops pour la prise de décision concernant la sélection des outils et des composants.

En même temps, la plupart des dirigeants reconnaissent également que trop de restrictions et de processus d’approbation complexes ralentir l’innovation et frustrer les développeurs talentueux. Les DSI, les responsables informatiques et les RSSI doivent définir des règles claires, faciles à suivre et une gouvernance raisonnable autour des sélections, des mises à jour et des correctifs.

Dans une enquête menée auprès de 1 500 professionnels de l’informatique sur la gestion de la sécurité et de l’open source, seuls 72 % des répondants déclarent avoir une politique d’utilisation de l’open source et de l’open source. seulement 64% ont déclaré avoir un conseil d’administration de l’open source. Ce n’est que la partie émergée du problème, car 16% des personnes interrogées pensent qu’elles ils peuvent corriger une vulnérabilité critique d’une source ouverte une fois qu’elle est identifiée.

Ces résultats sont préoccupants compte tenu du nombre de violations signalées liées à des composants open source. Dans l’enquête de la communauté DevSecOps 2020, 21% des répondants ont reconnu des violations liées à des composants open source. Il ne s’agit pas seulement d’un problème d’open source, car tout système commercial peut également présenter des vulnérabilités de sécurité au niveau des API ou d’autres composants logiciels.

Des politiques, une gouvernance et des pratiques de gestion clairement définies concernant l’utilisation des sources ouvertes, la sélection des outils et la gestion du cycle de vie des technologies sont nécessaires pour atténuer les risques. Mais les organisations diffèrent sur les meilleures pratiques ; certains penchent pour une plus grande ouverture tandis que d’autres penchent pour une moindre tolérance au risque et des procédures plus rigoureuses. Pour établir une politique équilibrée entre sécurité et innovation, les DSI doivent créer une équipe multidisciplinaire chargée de définir des procédures de gouvernance, des normes de pratique, des outils et des mesures.

Disposer d’outils qui intègrent les capacités des développeurs aux meilleures pratiques en matière de sécurité peut atténuer certains des défis associés à la sélection de composants open source. Jay JamisonLe directeur des produits et de la technologie de Quick Base a partagé ces réflexions sur l’approche de Quick Base en matière d’innovation par le biais de l’open source :

“Nous faisons partie des premiers adoptants de GitHub Advanced Security, qui facilite l’élimination des vulnérabilités dans les projets open source gérés sur sa plateforme. Il s’agit d’une étape importante dans le déplacement de la sécurité plus tôt dans le cycle de vie du développement logiciel, ou comme on l’appelle chez les développeurs, le déplacement vers la gauche.”

devops

Risque n° 4 : accès sans restriction aux dépôts de code source et aux pipelines CI/CD.

La protection des logiciels internes consistait à verrouiller les dépôts de contrôle de version, à rechercher les vulnérabilités dans le code, à définir des privilèges minimums pour faciliter les déploiements, le cryptage des connexions et la réalisation de tests de pénétration. Le blocage du réseau et de l’infrastructure était un domaine de sécurité entièrement distinct qui comprenait des outils et des disciplines distincts gérés par les opérations informatiques.

Aujourd’hui, il y a plus de risques et plus d’outils, mais aussi de meilleures intégrations. J’ai parlé à Josh Mason, vice-président de l’ingénierie chez Cherwell, de l’approche de son entreprise en matière de protection du code. “Chez Cherwell, nous superposons les tests de sécurité avec l’analyse statique automatisée (SAST), les tests dynamiques de sécurité des applications et les tests de pénétration, qui, à l’unisson, tendent à améliorer la productivité. La mise en œuvre de SAST dans le cadre du pipeline CI/CD déplace le processus de découverte plus à gauche dans le cycle de vie du développement logiciel, ce qui permet des résolutions plus rapides et moins coûteuses.”

Rajesh Raheja, responsable de l’ingénierie chez Boomi, une société de Dell Technologies, donne des conseils sur plusieurs disciplines de la sécurité. “Si le logiciel n’est pas développé correctement, le risque de sécurité est amplifié à une échelle bien plus grande qu’une seule violation du système. Vous pouvez atténuer les risques en sécurisant le pipeline CI/CD, en verrouillant les systèmes avec le principe du moindre privilège, en mettant en œuvre des alternatives d’automatisation sécurisées avec une authentification multifactorielle, en favorisant la sensibilisation à la sécurité au sein des membres de l’équipe et en développant des pratiques de codage sécurisées.”

Risque n° 5 : protection et gestion des données sensibles.

Bien que de nombreuses équipes devops soient expertes en pratiques de sécurité pour le développement, le test et le déploiement des applications, doit également superposer les pratiques de sécurité liées à la gestion et à l’exploitation des données.

Chris Bergh, PDG de DataKitchen, explique le problème et son approche pour automatiser des opérations de données plus sûres. “Les défis en matière de confidentialité et de sécurité des données empêchent les entreprises de monétiser leurs données pour en tirer un avantage concurrentiel. Les processus manuels ne peuvent pas résoudre le problème – il y a simplement trop de données qui circulent trop rapidement. Datasecops est une méthodologie qui automatise la confidentialité et la sécurité des données en intégrant la confidentialité, la sécurité et la gouvernance dans des flux de travail automatisés qui fonctionnent parallèlement au développement, à la mise en œuvre et aux opérations d’analyse des données.”

Le principal défi pour les dataops des DSI et des responsables informatiques est d’adopter une gouvernance proactive des données, d’étiqueter les données sensibles et de former les développeurs et les data scientists aux pratiques acceptables en matière de données. Centraliser la gestion des identités, définir des droits basés sur des rôles et masquer les données sensibles dans les environnements de développement. sont des pratiques importantes pour la sécurité et la confidentialité des données.

La gestion des données sensibles va au-delà de la sécurité des données. Par exemple, de nombreuses entreprises, notamment celles des secteurs réglementés, doivent capturer la lignée des données en montrant qui, quand, où et comment les données changent. Ces entreprises utilisent souvent des plateformes d’intégration et de gestion des données qui ont des capacités intégrées de dérivation des données.

Risque n° 6 : compétences et solutions de sécurité à faire soi-même.

Mon approche de la gestion des risques et de la sécurité. a toujours été de demander conseil à divers experts. Les menaces de sécurité gagnent en intensité et en complexité, et il est peu probable que la plupart des organisations disposent de toutes les compétences nécessaires. En outre, lorsque des problèmes de sécurité surviennent, il est utile de disposer d’une liste de personnes à consulter pour réduire les risques, résoudre les problèmes, recueillir des informations médico-légales et renforcer les vulnérabilités. est essentiel pour minimiser les impacts.

Si les outils et les pratiques aident les DSI à résoudre les problèmes actuels, nous avons besoin des experts pour relever les prochains défis en matière de sécurité.

Si vous avez trouvé cet article utile, et si vous souhaitez être tenu au courant de l’actualité du secteur des TIC et de ses acteurs clés, inscrivez-vous à nos lettres d’information :

CWI : des nouvelles et des idées pour ceux qui achètent, gèrent et utilisent les technologies dans l’entreprise&#13 ;
DSI :
Perspectives et tendances pour ceux qui dirigent la stratégie et le personnel de l&#8217informatique ;
Channelworld : des nouvelles et des chiffres pour les distributeurs, les revendeurs, les intégrateurs de systèmes, les éditeurs de logiciels et les fournisseurs de services.

Inscrivez-vous dès maintenant !