De mauvais modèles de codage peuvent entraîner de graves problèmes de sécurité... alors pourquoi les encourager ?

Une version de cet article a été publiée dans Zone D. Il a été mis à jour et diffusé ici.

‍

Pendant ce qui semble être une éternité à ce stade, nous avons discuté de la « transition vers la gauche » dans le SDLC, en tenant compte des meilleures pratiques de sécurité dès le début du développement logiciel. DevSecOps a constitué un grand pas en avant, en grande partie en raison de l'accent mis sur la responsabilité partagée en matière de sécurité et de la capacité d'un développeur soucieux de la sécurité à contrecarrer les vulnérabilités courantes lorsqu'il écrit du code.

Nous savons également, encore une fois, depuis des siècles que le type de formation au code sécurisé choisi pour impliquer et améliorer les compétences des développeurs fait toute la différence. Les solutions simples motivées uniquement par la conformité réglementaire ne permettent pas de former les meilleurs spécialistes de la sécurité de demain, et la plupart des professionnels de la sensibilisation à la sécurité ont trouvé la solution. Un apprentissage dynamique et adapté au contexte est préférable, mais il est essentiel d'en comprendre les nuances.

Si nous voulons avoir une chance de lutter contre les acteurs de la menace, et ils toujours avoir une longueur d'avance sur une organisation : les développeurs ont besoin d'un environnement de formation holistique, avec un apprentissage par étapes qui permet de développer en permanence des compétences inspirées des meilleures pratiques.

Les mesures de sécurité défensives mises en place par les développeurs ne sont pas automatiquement gagnantes.

Notre philosophie repose sur le fait que le développeur joue un rôle central dans une stratégie de sécurité préventive, dès le niveau du code. Cela va de soi, et les développeurs expérimentés en matière de sécurité constituent le moyen le plus simple de contrecarrer les types de bogues de sécurité courants qui se manifestent dans des modèles de codage médiocres (comme Log 4 Shell, comme exemple récent et dévastateur).

Cependant, les techniques défensives que nous pouvons utiliser pour améliorer les compétences des développeurs varient, même si elles peuvent à juste titre exister dans le même module d'entraînement.

Par exemple, imaginez qu'on vous explique comment faire un gâteau, en utilisant uniquement des instructions basées sur ce qu'il ne faut pas faire. « Ne le faites pas trop cuire » et « n'oubliez pas les œufs » laissent place à l'interprétation et présentent un énorme potentiel d'erreurs qui donneront un résultat final digne de ce nom. J'ai réussi !. Il en va de même pour l'enseignement de la sécurité défensive ; quoi pas to do ne constitue qu'une partie très limitée de la conversation et ne propose aucun conseil pratique pour vraiment agir avec un état d'esprit défensif. Vous pouvez dire aux développeurs de « ne pas mal configurer cette API », mais s'ils ne comprennent pas ce qui constitue une configuration correcte et sécurisée, il y a beaucoup de place à l'erreur.

Les développeurs n'auront pas d'impact positif sur la réduction des vulnérabilités sans une compréhension fondamentale de leur fonctionnement, de leurs raisons de danger, de leurs causes et des modèles de conception ou de codage qui les corrigent dans un contexte logique dans leur monde. UNE approche échafaudée permet à des niveaux de connaissances de donner une image complète de ce que signifie coder en toute sécurité, défendre une base de code et se présenter comme un développeur soucieux de la sécurité. Et oui, une partie de cet apprentissage par niveaux devrait être consacrée à l'attaque et à la compréhension de l'état d'esprit d'un attaquant ; c'est essentiel pour perfectionner les capacités de réflexion latérale, qui sont inestimables dans la modélisation des menaces et la stratégie défensive.

Renforcer les mauvais modèles de codage est un piège que nous ne pouvons ignorer.

Une triste réalité de certaines méthodes d'apprentissage pour les développeurs est que la partie « défensive », même lorsque la formation est structurée avec des techniques offensives, peut renforcer les mauvaises habitudes, même si elles valident techniquement la sécurité du code.

La production de code de haute qualité devrait être la base de tout développement logiciel, mais la définition de la « qualité » semble encore faire l'objet de débats. La réalité est qu'un code non sécurisé ne peut pas être considéré comme un code de qualité, même s'il est par ailleurs fonctionnel et beau. Le truc, c'est que sécuriser le code n'est pas intrinsèquement de haute qualité, non plus. En d'autres termes, de mauvais modèles de codage peuvent résoudre un problème de sécurité, mais ce faisant, en introduire un autre ou potentiellement détruire complètement le logiciel.

Jetons un coup d'œil à un exemple de code de mauvaise qualité sous la forme d'un correctif pour une authentification défaillante, ainsi que de la version la plus sécurisée pour les meilleures pratiques :

‍

en utilisant le système ;

en utilisant System.Collections.Generic ;

en utilisant System.Linq ;

en utilisant System.Threading.Tasks ;

à l'aide de Microsoft.AspNetCore.Authorization ;

en utilisant Microsoft.AspNetCore.Http ;

en utilisant Microsoft.AspNetCore.MVC ;

‍

espace de noms BadFixesAPI.Controllers

{

[Route (« api/ [contrôleur] »)]

[Contrôleur d'API]

classe publique AlertsController : ControllerBase

{

contexte DatabaseContext privé = new DatabaseContext () ;

‍

[HttpGet (Nom = « GetAlerts »)]

//Ne garantit pas que l'utilisateur est authentifié

public IEnumerable <Alert>Get ()

{

return Context.getAlerts () ;

}

‍

[HttpGet (Nom = « GetAlerts »)]

//S'assure que l'utilisateur est authentifié, mais ne vérifie aucun rôle

[Autoriser ()]

public IEnumerable <Alert>getBadFix ()

{

return Context.getAlerts () ;

}

‍

[HttpGet (Nom = « GetAlerts »)]

//S'assure que l'utilisateur est authentifié ET qu'il possède le rôle « Administrateur »

[Autoriser (rôles = « Administrateur »)]

public IEnumerable <Alert>getGoodFix ()

{

return Context.getAlerts () ;

}

}

}

‍

Dans le premier extrait, aucune vérification n'est effectuée pour vérifier que l'utilisateur est authentifié, ce qui est à peu près aussi dangereux que possible. Le second, bien qu'il s'agisse d'un meilleur contrôle d'authentification, ne permet pas d'examiner les rôles attribués et de déterminer si les autorisations sont suffisamment élevées pour les informations demandées. Le troisième vérifie à la fois l'authentification des utilisateurs et qu'on leur attribue le rôle « Administrateur ». À une époque où le contrôle d'accès par le moindre privilège devrait être la norme dans la plupart des cas, il est essentiel que les rôles soient définis et vérifiés afin de garantir que les informations ne sont accessibles qu'en cas de besoin.

La priorité absolue des développeurs est de créer des fonctionnalités, et même si la sécurité n'est pas intentionnellement reléguée au second plan, ils n'ont pas nécessairement les compétences nécessaires pour éviter les mauvais modèles de codage qui entraînent des bogues de sécurité, et la référence d'un bon ingénieur inclut rarement les prouesses en matière de codage sécurisé. Nous encourageons indirectement ces mauvaises habitudes si les fonctionnalités sont suffisamment géniales, et c'est cet état d'esprit qui doit changer. Le problème est que la façon dont certains parcours d'apprentissage encouragent la correction pratique du code peut également renforcer le code qui est sécurisé, mais de qualité inférieure aux normes. En appliquant une évaluation binaire « oui c'est sécurisé/non, ce n'est pas sécurisé », plutôt que d'examiner de plus près s'il s'agit vraiment de la meilleure approche pour résoudre le bogue et préserver l'intégrité du logiciel, il y a des failles dans les détails qui passent inaperçues.

Sans impliquer les développeurs tout au long du processus pour obtenir une vue complète du codage sécurisé, cette approche perpétue les mêmes problèmes qu'elle essaie de résoudre. Imaginez si nous obtenions tous nos permis uniquement sur la base de notre capacité à conduire un véhicule jusqu'à destination ; une marque de passage même si nous avons allumé des feux rouges, traversé une haie et raté de peu un piéton qui traversait la rue pour y arriver. Nous avons atteint l'objectif, mais le chemin que nous avons parcouru pour y parvenir est le plus important.

Les développeurs doivent être habilités à se soucier davantage de la création de logiciels sécurisés.

Le développeur moderne doit faire beaucoup de choses et il n'est pas surprenant qu'il trouve la formation à la sécurité ennuyeuse, en particulier lorsqu'elle n'est pas mise en œuvre en fonction de sa journée de travail et qu'elle l'éloigne de ses délais et de ses priorités. Il est également totalement injuste de modifier leurs KPI pour mettre l'accent sur le codage sécurisé, alors qu'ils ne disposent pas des compétences acquises grâce à des opportunités d'apprentissage régulières et adaptées et à des outils supplémentaires. Cependant, l'importance d'un développement logiciel sécurisé ne peut être surestimée, et il est crucial de faire participer les développeurs à cet égard.

En tant qu'ancien développeur, nous vouloir faire un excellent travail et être considéré comme un cran au-dessus des autres en termes de qualité de production est très motivant. Inciter les développeurs à développer en permanence leurs compétences en matière de sécurité va de soi, et ils devraient être récompensés pour avoir reconnu l'importance de la sécurité au niveau du code. Les programmes dédiés aux champions de la sécurité, les primes aux bugs et les hackathons peuvent être d'excellentes occasions de créer une culture de sécurité positive, et ceux qui retroussent leurs manches et s'impliquent devraient remporter le butin.