Ces derniers temps, nous avons été témoins de plusieurs violations de la sécurité des informations dans le monde : vulnérabilités, ransomware, Man-in-the-middle, entre autres problèmes qui deviennent des maux de tête non seulement pour l’équipe d’ingénierie mais pour toute l’entreprise et même pour les clients de votre produit.
Et si on disait que la plupart des problèmes de sécurité pourraient être évités ? Cet article couvrira l’importance de la sécurité de l’information et comment l’inclure tout au long du processus de développement : ce qu’on appelle le DevSecOps.
Les 3 mythes autour des informations de sécurité
Il y a trois tabous dans le domaine du développement logiciel dont nous devons parler pour commencer à aborder la sécurité de l’information de manière plus cohérente :
Les failles de sécurité sont souvent considérées comme un problème réservé aux grandes entreprises
Le premier d’entre eux est le plus simple à dire : la plupart des failles de sécurité et leurs impacts et dommages respectifs sont généralement liés aux grandes entreprises, telles que Facebook, LinkedIn, entre autres.
Cependant, ce n’est pas un problème propre aux grandes entreprises, à tel point qu’une étude de codegrip rapporte que trois applications sur quatre actuellement utilisées présentent une vulnérabilité.
La vulnérabilité ne nuit pas aux entreprises
Selon le dernier rapport de recherche sur les vulnérabilités d’IBM, cette idée est loin d’être vraie. Pour vous donner une idée, environ 38% des affaires ont été perdues par des entreprises qui ont eu une faille de sécurité. De plus, il existe des estimations de pertes moyennes :
-
Moyenne de 180 USD pour chaque enregistrement d’informations personnelles.
-
4,62 millions de dollars était la violation moyenne des ransomwares.
-
3,61 millions de dollars pour chaque violation des environnements cloud hybrides.
En pratique, la vulnérabilité a également un impact sur la confiance et la crédibilité de la marque. Un exemple récent est Target, qui a dû débourser près de 200 millions de dollars pour restaurer sa crédibilité.
Les problèmes de sécurité proviennent de grosses erreurs
De tous les mythes, c’est le plus grand sophisme de tous ! En général, les « problèmes mineurs » sont précisément ceux qui entraînent les catastrophes sécuritaires les plus étendues, et on peut dire que les défaillances présentent généralement deux lacunes :
-
Nous avons rencontré des failles telles que des problèmes de conception, d’injection et de configuration de code non sécurisés via une vulnérabilité de code intentionnellement ou non : dans le TOP 10 démontré par l’OWASP.
-
Par la vulnérabilité des opérations : parmi les problèmes les plus courants, on peut citer le choix des « mots de passe faibles », le défaut ou encore l’absence de mot de passe. Un deuxième échec courant est la mauvaise gestion de l’autorisation des personnes à un document ou à un système. Ces types de problèmes, malheureusement, sont assez standard. Pas par hasard, 75% des serveurs Redis ont des problèmes de ce type.
Par analogie, on peut dire que les failles de sécurité sont comme le cas du Titanic. Considéré comme l’une des plus grosses épaves, la plupart des gens ignorent que le navire avait un « petit problème » : l’absence d’une simple clé qui aurait pu ouvrir le compartiment avec des jumelles et d’autres dispositifs pour aider l’équipage à visualiser l’iceberg à temps et éviter un collision.
Connaître la triade de la sécurité
Nous comprenons l’importance de la sécurité de l’information et l’énorme impact de son absence. Avec cela, la question demeure : comment définir si une application est sûre ?
Bref, il existe un acronyme pour une application sécurisée basée sur la norme ISO 27002, qui est CIA, axée sur trois propriétés :
-
Confidentialité : La garantie qu’un message sera délivré à la personne qui a besoin de recevoir cette information.
-
Intégrité : s’assurer que les informations sont fournies sans changement en cours de route.
-
Disponibilité : La garantie que les données doivent toujours être disponibles pour l’utilisateur légitime.
Pour illustrer, une analogie. Si le Titanic était une « application échouée », ce qui s’est passé était un problème dans la propriété A (Disponibilité), puisque la clé qui garantissait l’accès aux jumelles n’était pas disponible pour l’équipe en amont du navire.
Comprendre la sécurité de l’information en tant que méthodologie : Devsecops
Une fois que nous comprenons les principes de sécurité, nous devons comprendre le « comment » les incorporer dans la routine de nos applications. Après tout, comment allons-nous nous assurer que chaque livraison/déploiement ne présente aucun problème de vulnérabilité ?
L’une des solutions consiste à augmenter l’intégration entre les équipes, en évitant les retards de retour d’information et, surtout, en faisant en sorte que la sécurité de l’information se produise de manière proactive et non réactive, comme cela se produit habituellement.
La réponse à cela est DevSecOps, qui se concentre sur l’ajout d’une couche de sécurité à l’opération de développement. Réfléchir à cette méthodologie est une autre étape dans l’histoire de l’intégration entre les équipes.
-
Agile : Le cône qui vient du manifeste agile de 2001, cette méthodologie se concentre sur l’intégration de l’équipe de développement et de l’équipe produit.
-
DevOps : à l’étape d’intégration suivante, l’équipe d’exploitation est ajoutée à l’équipe de développement et d’utilisation déjà intégrée.
-
DevSecOps: enfin, l’équipe de sécurité est ajoutée aux groupes qui existent déjà dans DevOps.
En tant qu’autre terminologie méthodologique, il est naturel qu’il existe plusieurs définitions pour le même terme. Certains d’entre eux:
Mais quel que soit le terme préféré, le point important est qu’avec DevSecOps, nous devons intégrer la sécurité de l’information dans le processus. En d’autres termes : une sécurité en couches, allant de l’utilisateur final, en passant par l’équipe d’ingénierie, jusqu’aux configurations de la base de données et du système d’exploitation.
En plus de la sécurité en couches, un autre cœur de la méthodologie est l’automatisation de la sécurité. Lorsque nous sommes au milieu d’un tapis roulant de développement, nous avons tendance à oublier ce que nous devions inévitablement retenir.
Les outils de sécurité de l’information peuvent être intégrés à partir de CI/CD. Autrement dit, s’il y a un défaut, cela peut casser la construction. Dans les catégories d’outils de sécurité, nous pouvons en énumérer :
-
SAST (Static application security testing) est un outil qui scanne le code de manière statique et analyse le code avant compilation.
-
DAST (Dynamic Application Security Testing) : un outil qui effectue des validations de code à l’exécution.
-
IAST (Interactive Application Security Testing) : exécute des tests d’application à partir d’une application en cours d’exécution. La différence la plus significative entre IAST et DAST est que les tests sont effectués au sein de l’application.
Comment Horusec peut vous aider à adopter la méthodologie Devsecops dans votre projet
En général, ces outils permettent de détecter les vulnérabilités, de surveiller les bogues et, surtout, de prévenir les problèmes de sécurité.
Et parmi les outils qui existent sur le marché, nous avons Horusec, l’un des projets Open Source maintenu par Zup et qui se concentre sur la sécurisation de votre application et la prévention des vulnérabilités du code.
L’une de ses différences réside dans ses outils de fonctionnalités de sécurité d’orchestration. C’est-à-dire qu’il permet l’intégration de plus d’outils. La philosophie principale du produit est Autant de sécurité que possible : mieux !
Horusec dispose également d’un tableau de bord, qui aide les équipes à comprendre les problèmes de sécurité au sein de leur application.
Il est possible de s’intégrer à Horusec de plusieurs manières, par exemple, avec un CI comme Github Action, et il peut exporter vers le tableau de bord.
La prévention est la clé, ce qui signifie que si un PR a une vulnérabilité, la construction « s’interrompt », empêchant un futur casse-tête ou un désastre de vulnérabilité d’être fusionné dans l’environnement de production.
Actuellement, Horusec a trois composantes :
-
CLI, ou le terminal classique, permet l’analyse et la visualisation des vulnérabilités directement via le terminal.
-
Le Dashboard, ou Horus-Manager, est une fonctionnalité optionnelle qui permet de visualiser ces vulnérabilités de manière plus intuitive que le terminal.
-
Une extension à l’IDE est également facultative, ce qui facilite l’analyse des vulnérabilités de l’IDE lui-même. Aujourd’hui, nous avons l’extension pour utiliser Horusec dans Visual Studio Code.
Une excellente première expérience d’installation à la fois de la CLI et du tableau de bord, mais ne vous inquiétez pas ; vous pouvez trouver toutes les informations dans la documentation officielle du projet. Ensuite, vous pouvez analyser ce référentiel qui contient plusieurs vulnérabilités et dans plusieurs langages de programmation.
Il est bon de s’appuyer sur des outils comme Horusec car ils nous permettent, en tant que professionnels du développement, d’avoir une plus grande confiance dans la création de code plus sécurisé sans vulnérabilités, nous empêchant ainsi d’être le prochain responsable de la sécurité de notre projet/produit.