La plupart des attaques réussies d'une organisation sont mises en œuvre par le biais de vulnérabilités et de signets dans les logiciels. Heureusement, un scanner de vulnérabilité logicielle n'est pas déjà considéré par les entreprises comme quelque chose d'exotique, mais comme un élément nécessaire de l'infrastructure de protection. Si avec de petits volumes de développement, vous pouvez utiliser le scanner tel quel, alors lorsque les volumes sont importants, vous devez automatiser le processus. Mais qui devrait le gérer? Décidez de la fréquence de vérification des versions? Vérification de la vulnérabilité? Décidez si vous souhaitez opposer votre veto à la publication et envoyer du code pour corriger les vulnérabilités? Et répondez à bien d'autres questions. C'est là qu'Application Security Manager, le responsable du développement de logiciels sécurisés, arrive au premier plan.
Mais où trouver un oiseau si rare ou comment le faire pousser soi-même? Artem Bychkov, responsable de la sécurité des applications chez Raiffeisenbank JSC, et Daniil Chernov, responsable de Rostelecom Solar, Solar appScreener, décrivent les exigences du responsable de la sécurité des applications dictées par les pratiques de développement des entreprises russes.
Qui est Application Security Manager
Tôt ou tard, les organisations se rendent compte de la nécessité d'embaucher une telle personne dans l'équipe. En particulier, car aucun des spécialistes disponibles dans l'entreprise ne convient directement à ce poste. Développeurs? Leur expérience professionnelle est liée spécifiquement au développement de logiciels - il leur est très difficile de traduire les vulnérabilités trouvées en risques SI, et plus encore les risques pour l'entreprise. Les gardes de sécurité? L'immersion dans les subtilités du développement leur est problématique: pour vérifier les vulnérabilités, il faut être capable de comprendre les codes logiciels dans différents langages, ce qui nécessite une sérieuse expérience en développement.
Examinons les tâches qui surviennent lors de la mise en œuvre du processus de développement sécurisé, qui doivent être traitées par le gestionnaire de sécurité des applications (AFM).
Le lecteur peut être d'avis que le travail de l'AFM est uniquement lié à la vérification des développements logiciels pour la conformité aux exigences de sécurité. Mais des problèmes de sécurité surviennent à différentes étapes du cycle de vie du système, de la conception au déploiement en passant par la production. Il existe différents modèles pour construire un cycle de développement sécurisé (Software Security Touchpoints, SDLC et autres) et différentes méthodes pour intégrer ces pratiques dans le processus (selon l'approche utilisée - cascade, agile). Mais ils sont tous d'accord sur des points clés: vous devez penser à la sécurité à toutes les étapes du cycle de vie du système.
De toute évidence, dans le cadre d'un projet plus ou moins important, il est peu probable qu'une personne soit en mesure d'effectuer des travaux à toutes les étapes. Il est rare qu'une personne seule puisse développer les exigences de sécurité des applications, effectuer un examen de son architecture et vérifier les résultats du travail des analystes, effectuer un audit de sécurité du code, vérifier que les tests de sécurité des applications nécessaires ont été effectués pendant les tests et que le système a été déployé en toute sécurité et correctement configuré. De plus, ces activités sont souvent menées par des représentants de différentes équipes et unités. Pour que l'ensemble du mécanisme fonctionne comme il se doit, la force motrice du processus doit être l'AFM. L'AFM a pour mission d'assurer la mise en œuvre de pratiques de développement sûres, soit par elles-mêmes, soit en déléguant certaines tâches à des spécialistes spécialisés. Cependant, selon notre pratique, il n'est pas possible pour l'AFM de simplement confier des tâches aux responsables et de se reposer sur leurs lauriers.
Quelles sont les exigences pour l'AFM
Tout d'abord, il doit comprendre le projet qu'il accompagne. Ceci est particulièrement important dans le développement agile, lorsque, contrairement au modèle en cascade, vous n'avez pas 2 mois pour effectuer un examen avant la sortie. Cela dépend de l'AFM, par exemple, de la façon dont les exigences formulées au stade de la conception seront interprétées par l'équipe, de la manière dont elles tomberont sur l'architecture, si elles sont généralement réalisables et si elles créeront de graves problèmes techniques à l'avenir. Le plus souvent, l'AFM est le principal consommateur, interprète et évaluateur des rapports d'instruments automatisés et des audits effectués par des tiers. C'est l'AFM qui filtre les résultats non pertinents et erronés, évalue les risques et participe aux processus de gestion des exceptions et d'élaboration de mesures compensatoires.
Voici un exemple concret: un audit ou un scanner de code source a révélé l'utilisation d'une fonction de hachage non sécurisée (MD5) dans un projet. La politique de la société insiste formellement sur le fait qu'elle ne peut pas être utilisée, et le vendeur accepte de remplacer la fonction par une plus sécurisée en 3 mois et une quantité importante. La nuance était que dans ce cas, l'instabilité de la fonction de hachage contre les collisions n'a pas affecté la sécurité du système, car la fonction n'a pas été utilisée pour protéger l'intégrité. L'approche formelle dans ce cas et le remplacement d'une fonction par une autre ont entraîné un délai déraisonnablement retardé pour que le projet devienne des coûts productifs et importants, donnant un gain de sécurité nul.
Deuxièmement, en plus du premier, l'AFM doit avoir des connaissances dans différents domaines: vous devez comprendre les processus de développement et les principes de la sécurité de l'information. Les compétences techniques sont également importantes, car il est très difficile d'évaluer de manière critique les résultats du travail de spécialistes spécialisés et d'outils automatisés, si vous ne pouvez pas lire le code, vous ne comprenez pas les moyens possibles d'exploiter les vulnérabilités. Certes, beaucoup étaient confrontés à une situation où une vulnérabilité critique apparaît dans l'analyse de code ou le rapport pentest, mais les développeurs ne sont pas d'accord avec cela (et, en règle générale, ils veulent également créer un système sécurisé) et indiquent que les auditeurs n'ont pas été en mesure d'exploiter ce vulnérabilités. Comment évaluer qui a raison dans une situation similaire? Sans compétences techniques, la résolution objective d'un différend sera difficile. Si le processus de développement d'un logiciel sûr est construit par les mains d'une organisation externe et / ou selon le modèle de service, qui et comment évaluera la performance des pratiques «techniques»?
Autre exemple de vie: un nouvel outil de développement est en cours d'introduction, ses performances sont vérifiées sur un projet de référence, puis transférées en exploitation commerciale. Les projets y sont progressivement connectés, un beau tableau de bord vert est dessiné ... et ici se produit un incident de sécurité de l'information. Il s'avère que le «trou» utilisé aurait dû être détecté au stade de l'analyse dynamique. Mais cela ne s'est pas produit, car ... personne n'a regardé, mais comment ce scanner de vulnérabilité haut de gamme, qui produit généralement d'excellents résultats, fonctionne-t-il avec les applications SPA en utilisant le nouveau cadre JavaScript. Il s'est avéré qu'il ne pouvait pas «voir» le formulaire d'authentification généré dynamiquement et effectuer les vérifications nécessaires. Et personne n'y a prêté attention, car tout fonctionnait. Les développeurs n'avaient pas besoin de se plonger dans les spécificités du fonctionnement des scanners pour attirer l'attention sur cela, et les équipes de sécurité n'ont pas vu de différences critiques entre les différentes approches du développement web.
Où trouver un tel spécialiste
Ceux qui ont étudié le marché ont dû faire face à une grave pénurie d'experts en sécurité des applications. En règle générale, le scénario est le suivant: les clients internes établissent les exigences du candidat et les transfèrent au personnel. Si les exigences sont strictes, alors selon les résultats d'une recherche gratuite, l'entreprise ne reçoit aucun candidat, car les spécialistes prêts à l'emploi affichent très rarement des CV dans le domaine public. S'ils changent d'emploi, cela se produit le plus souvent facilement et naturellement grâce aux contacts existants. Comment être
Vous pouvez essayer d'attirer un professionnel d'autres sociétés, mais ce chemin n'est pas toujours acceptable pour diverses raisons. De plus en plus souvent, des concours pour les AFM en surnombre apparaissent sur le marché, ce qui vous permet de résoudre le problème avec succès en louant des experts auprès d'un prestataire de services.
Mais il y a une autre option. Vous pouvez essayer de faire grandir votre professionnel. Les représentants de deux domaines peuvent être des candidats appropriés pour ce rôle:
- les personnes issues du développement qui aiment ou souhaitent se développer dans le domaine de la sécurité;
- des gardes techniques qui connaissent le développement et la sécurité des logiciels et qui souhaitent approfondir ce sujet.
Ces candidats et d'autres devront maîtriser l'ensemble des connaissances manquantes. Dans le même temps, les personnes du développement qui souhaitent «reforger» auront une meilleure compréhension de la culture et des processus existants dans les équipes qu'ils connaissent. Il peut leur falloir un certain temps pour maîtriser les domaines de connaissances liés à la sécurité de l'information. Cependant, l'expérience montre que parmi les développeurs, testeurs, analystes et architectes, vous pouvez trouver des personnes intéressées par la sécurité qui ont déjà un certain ensemble de connaissances dans le domaine de la sécurité des applications. Ils peuvent être des candidats idéaux pour un emploi AFM.
Les agents de sécurité professionnels devront s'acclimater, changer les approches familières existantes pour organiser le travail et adopter la culture dans les équipes de développement. Cependant, si un spécialiste de la sécurité écrit du code et connaît les processus de développement, il rejoindra l'équipe rapidement et simplement.
Total
Le contrôle de la sécurité du développement est avant tout un processus métier dont le bon fonctionnement nécessite une interaction coordonnée de tous les membres de l'équipe. Le «cœur» de ce processus est un AFM qualifié - il est à la fois l'inspirateur et le moteur directionnel, l'exécuteur de nombreuses tâches, le responsable du contrôle et bien d'autres. En général, le lecteur, la faucheuse et le mec sont sur le tuyau. Trouver ou élever un tel spécialiste n'est pas facile, mais si vous réussissez, tout le monde sera heureux.