La prévention à l'ère de la surface d'attaque infinie

Une version de cet article a été publiée dans SD Times. Il a été mis à jour et syndiqué ici.

‍

Lorsque nous parlons de progrès, l'avancée numérique est généralement au cœur du débat. Nous voulons que tout soit meilleur, plus rapide, plus pratique, plus puissant, et nous voulons y parvenir avec moins de coûts, de temps et de risques. Pour la plupart, ces objectifs « impossibles » finissent par être atteints ; cela peut prendre plusieurs années et de multiples versions (ainsi qu'une équipe de développeurs prête à se révolter si on leur demande de changer de cap sur la conception d'une fonctionnalité une fois de trop), mais chaque jour, le code change le monde.

Cependant, une grande expansion logicielle implique une grande responsabilité, et la réalité est que nous ne sommes tout simplement pas prêts à y faire face sur le plan de la sécurité. Le développement logiciel n'est plus une activité isolée. Lorsque nous prenons en compte tous les aspects des risques liés aux logiciels — du cloud aux systèmes embarqués dans les appareils et les véhicules, en passant par nos infrastructures critiques et les API qui relient le tout — la surface d'attaque devient illimitée et incontrôlable.

Nous ne pouvons pas espérer une époque magique où chaque ligne de code serait méticuleusement vérifiée par des experts en sécurité chevronnés — la pénurie de compétences n'est pas près de se résorber — mais nous pouvons, en tant qu'industrie, adopter une approche plus globale de la sécurité au niveau du code.

Explorons comment nous pouvons maîtriser cette surface d'attaque infinie avec les outils à notre disposition :

Soyez réaliste quant au niveau de risque métier (et à ce que vous êtes prêt à accepter)

Une sécurité parfaite n'est pas viable, mais se voiler la face en prétendant que tout va bien ne l'est pas non plus. Nous savons déjà que les organisations déploient sciemment du code vulnérable, et il s'agit clairement d'un risque calculé basé sur les délais de mise sur le marché de nouvelles fonctionnalités et produits.

La sécurité à grande vitesse est un défi, surtout là où le DevSecOps n'est pas la méthodologie de développement standard. Cependant, il suffit de regarder la récente faille Log4Shell pour découvrir comment des problèmes de sécurité relativement mineurs dans le code ont ouvert la voie à une attaque réussie, et constater que les conséquences de ces risques calculés liés au déploiement de code de moindre qualité pourraient être bien plus graves que prévu.

Apprenez à être un maniaque du contrôle (d'accès)

Un nombre alarmant de violations de données coûteuses est causé par des environnements de stockage cloud mal configurés, et le risque d'exposition de données sensibles résultant d'erreurs de contrôle d'accès continue de hanter les équipes de sécurité dans la plupart des organisations.

En 2019, la société First American Financial Corp., classée au Fortune 500, l'a appris à ses dépens. Une erreur d'authentification — relativement simple à corriger — a conduit à l'exposition de plus de 800 millions d'enregistrements, incluant des relevés bancaires, des contrats de prêt immobilier et des pièces d'identité. Leurs liens vers les documents ne nécessitaient aucune identification ou connexion utilisateur, les rendant accessibles à quiconque disposant d'un navigateur web. Pire encore, ils étaient indexés par des numéros séquentiels, ce qui signifie qu'un simple changement de chiffre dans le lien exposait un nouvel enregistrement de données.

Ce problème de sécurité avait été identifié en interne avant d'être révélé dans les médias. Cependant, le fait de ne pas l'avoir correctement classé comme un problème de sécurité à haut risque et de ne pas l'avoir signalé à la direction pour une correction urgente a entraîné des retombées dont les conséquences se font encore sentir aujourd'hui.

Il y a une raison pour laquelle le contrôle d'accès défaillant figure désormais tout en haut du classement OWASP Top 10 : c'est un problème extrêmement courant. Les développeurs ont besoin d'une sensibilisation vérifiée à la sécurité et de compétences pratiques pour appliquer les meilleures pratiques en matière d'authentification et de privilèges dans leurs propres builds, en s'assurant que des contrôles et des mesures sont en place pour protéger les données sensibles contre toute exposition.

La nature des API les rend particulièrement pertinentes et délicates ; elles sont conçues pour communiquer intensivement avec d'autres applications, et les équipes de développement doivent avoir une visibilité sur tous les points d'accès potentiels. Après tout, elles ne peuvent pas prendre en compte des variables et des cas d'utilisation inconnus dans leur quête pour fournir des logiciels plus sûrs.

Analysez votre programme de sécurité : quelle importance est accordée à la prévention ?

Il est logique qu'une grande partie d'un programme de sécurité soit consacrée à la réponse aux incidents, mais de nombreuses organisations passent à côté d'une réduction précieuse des risques en n'utilisant pas toutes les ressources disponibles pour prévenir un incident de sécurité dès le départ.

Certes, il existe des suites d'outils de sécurité complètes pour aider à détecter les bugs problématiques, mais près de 50 % des entreprises admettent déployer du code dont elles connaissent les vulnérabilités. Les contraintes de temps, la complexité des outils et le manque d'experts formés pour traiter les rapports contribuent à ce qui est essentiellement un risque calculé. Cependant, le fait que le code doive être sécurisé dans le cloud, les applications, les fonctionnalités API, les systèmes embarqués, les bibliothèques et un paysage technologique en constante expansion garantit qu'avec l'approche actuelle, nous aurons toujours un train de retard.

Les failles de sécurité sont un problème d'origine humaine, et nous ne pouvons pas attendre des robots qu'ils règlent tout à notre place. Si vos équipes de développement ne montent pas réellement en compétences — au-delà d'un simple séminaire annuel, avec de véritables bases pédagogiques — vous courez le risque permanent d'accepter un code de faible qualité comme norme, avec les risques de sécurité qui en découlent.

Avez-vous surestimé le niveau de préparation de vos développeurs ?

Les développeurs sont rarement évalués sur leurs capacités de codage sécurisé, et ce n'est pas leur priorité (ni même un KPI dans bien des cas). Ils ne peuvent pas être tenus pour seuls responsables de mauvaises pratiques de sécurité s'ils n'ont pas été orientés vers une meilleure approche ou informés que cela faisait partie de leurs objectifs de réussite.

Trop souvent, les organisations partent du principe que les conseils fournis ont suffi à préparer les équipes d'ingénierie à atténuer les risques de sécurité courants. Selon la formation reçue et leur capacité à appliquer les bonnes pratiques, ils ne sont peut-être pas prêts à constituer cette première ligne de défense idéale (et à éviter que les rapports de tests d'intrusion ne soient saturés de failles par injection).

L'idéal est de suivre des parcours d'apprentissage de complexité croissante, avec une vérification des compétences acquises pour garantir leur efficacité réelle pour le développeur. Cela exige toutefois une culture d'entreprise où les développeurs sont pris en compte dès le départ et correctement outillés. Si, en tant qu'industrie, nous devons défendre ce vaste paysage de code que nous avons nous-mêmes créé, nous aurons besoin de toute l'aide possible… et elle est bien plus accessible que nous ne le pensons.