Alexandra Svatikova travaille en tant qu'expert en sécurité de l'information à Odnoklassniki. Il y a plus de 8 ans, elle est passée du développement en Java au test de la sécurité des applications.
Nous l'avons interviewée où nous avons discuté:
- Est-il difficile pour un développeur de passer à l'analyse d'applications?
- différences dans les performances du pentester, du rescher et de l'analyste;
- cycle de vie du développement de la sécurité ou SDLC;
- le rôle de l'homme dans la recherche de vulnérabilités;
- comment en sont les analyses de sécurité dans d'autres entreprises.
Il n'y aura pas de hardcore dans cet article - vous pouvez le suivre à Heisenbug 2019 Moscou , où Alexandra parlera de tests de sécurité statiques. Nous allons passer à son rapport à la fin du post, mais pour l'instant, bienvenue à cat.
Se connecter à la sécurité des applications n'est pas aussi difficile qu'il y paraît
"Pour qui avez-vous étudié?" Pourquoi êtes-vous devenu impliqué dans la sécurité des applications?
- Je ne suis probablement pas un exemple à suivre (rires) . J'ai étudié en tant que programmeur, et quelque chose comme «génie logiciel» est écrit dans le diplôme. A d'abord travaillé en tant que développeur mobile, puis est passé au développement Web en Java. Après avoir trouvé un autre emploi en tant que programmeur Java, je suis entré dans l'équipe qui s'occupe de la sécurité des applications - en maintenant la partie du développement liée à la sécurité. Il y avait un processus bien organisé et formulé, et ils avaient besoin de personnes pour faire des révisions de code et des analyseurs statiques. En conséquence, ils recherchaient un programmeur Java et étaient prêts à lui enseigner la sécurité. Cela m'a semblé intéressant, alors je suis resté.
- Que pensez-vous, resterez-vous dans ce domaine pendant longtemps, ou est-ce que quelque chose suivra cette étape plus loin?
- Je pense que je vais rester pour toujours, car je suis analyste en sécurité des applications depuis 2011. J'ai déjà moins d'expérience en développement, il s'avère. Le programmeur ne doit pas avoir peur des tâches de routine, corriger les bugs, mais le spécialiste de la sécurité a une spécificité différente, cela m'attire davantage.
- Quels domaines supplémentaires par rapport au développement conventionnel avez-vous dû maîtriser?
- A l'aube de ma carrière, je testais. Cela vous donne une bonne idée: vous voyez le système sous la forme non d'un tas de codes, mais d'un organisme, qui peut être influencé de différentes manières. Les testeurs et les développeurs ont donc une différence de pensée.
Par exemple, il y a 10 à 15 ans, on pensait que les testeurs devaient casser le système et trouver le bogue de quelque manière que ce soit. Les professionnels de la sécurité doivent parfois avoir un point de vue similaire. Vous devez donc comprendre comment le système fonctionne dans son ensemble.
Certains développeurs sont obsédés par les détails: ils savent comment une partie du système fonctionne, mais ils ne comprennent pas comment tout cela interagit. Par exemple, il sait comment JS est exécuté dans un navigateur, mais le développeur ne sait pas comment ce navigateur fonctionne davantage et communique avec le serveur, pourquoi cela est organisé comme ceci. Le testeur doit regarder à vol d'oiseau pour évaluer les interconnexions des composants, les changements faibles ou les vulnérabilités.
- Et quelque chose d'ingénierie, par exemple, les piles de réseau, vous avez dû apprendre à partir de zéro? Par exemple, comment fonctionne JS, front, backing?
- En principe, j'étais déjà développeur full-stack, donc je comprends le fonctionnement du backend et du frontend. Vous devez avoir une certaine perspective, mais l'approfondissement des détails dépend déjà de ce que vous faites. Les mêmes développeurs et testeurs, selon le projet, connaissent certaines choses du système (par exemple, les protocoles réseau) ou en savent plus sur l'interface. Cela dépend des circonstances.
- Dans quelle mesure vous semble-t-il réaliste qu'un développeur de pile complète abstraite ou un testeur de pile complète, engagé dans la programmation, l'automatisation et les tests, passe à l'analyse des applications, c'est-à-dire que faites-vous?
- C'est facile pour un testeur. Assurez-vous d'avoir des compétences en programmation et de comprendre comment le système est construit de l'intérieur. Mais un bon testeur sans cela n'existe plus. Si tel est le cas, alors se pose la question de la spécialisation: il doit lire sur la sécurité et certaines technologies (par exemple, Android ou le support), c'est-à-dire dans quoi il essaie de trouver des vulnérabilités.
Les développeurs voient leur participation au processus un peu différemment. Par conséquent, pour le développeur, c'est une révolution, un regard différent sur la profession. Il est important pour le développeur que quelque chose fonctionne, mais il lui sera difficile de casser.
Pentester, rescher et analyste de la sécurité des applications: quelle est la différence
- Si je comprends bien, votre spécialisation est liée aux pentesters. Comment les pentesters et les chercheurs sur la vulnérabilité du jour zéro se comparent-ils, ou est-ce que tout est mélangé dans une seule bouteille et est-il vraiment difficile de savoir qui est qui?
- Il n'y a pas de division claire en postes. Mais je vais vous dire quels termes le parti utilise.
Il y a des éclaireurs qui recherchent un produit, une technologie, un protocole, un serveur dans le but de trouver un problème intéressant. Intéressant se réfère à un problème qui n'a pas été trouvé précédemment, ou a été identifié dans un endroit inattendu, ou il s'agit d'une combinaison complexe de problèmes précédemment connus. Je peux dire qu'en règle générale, toutes les vulnérabilités 0day sont trouvées par les éclaireurs.
Pentest est un service. Vous avez un système et vous souhaitez trouver des vulnérabilités. La tâche des pentesters est de pénétrer le système. Ils ne pourront pas trouver tous les problèmes potentiels. Par exemple, une vulnérabilité peut être atténuée par d'autres mécanismes de sécurité à différents niveaux. Pentester recherchera ce qui est réellement exploité, et après cela, il émettra un rapport et partira, car il n'a pas pour tâche d'augmenter la sécurité du système ou d'ajuster les processus de développement.
Il existe également des analyses de sécurité des applications ou de sécurité des produits. Au contraire, ils regardent le système de l'intérieur. Leur tâche est de sécuriser le système. Cela signifie qu'ils ont des informations sur le système, et ce n'est pas une "boîte noire" pour eux. En revanche, ils classent les problèmes différemment. Les analystes considèrent même des vulnérabilités qui ne peuvent pas être exploitées pour le moment. Par exemple, il y a un trou critique dans le panneau d'administration, et il est clair qu'il n'est accessible que depuis le réseau interne, et donc ce n'est pas très effrayant. Mais l'initié comprend que dans certaines circonstances, une chose terrible peut arriver.
Les analystes se concentrent davantage sur le soutien du processus. Si les pentesters découvrent 20 bugs et s'en vont, et que les développeurs en train de corriger les bugs font de même, alors les pentesters n'aideront pas ici. Par conséquent, la compréhension du nombre de vulnérabilités dans le système ne sera pertinente qu'à ce moment.
- Ensuite, l'analyste de la sécurité des applications fait cela dans le processus, au jour le jour?
- Oui, et en même temps, l'activité est dirigée dans deux directions. D'une part, vous devez rechercher les vulnérabilités existantes et les combattre. D'un autre côté, il est nécessaire de rendre le système plus sûr.
Cela peut être abordé de différentes manières. Par exemple, générez le processus de développement afin qu'il y ait moins d'erreurs ou qu'elles soient rapidement détectées. Ou implémentez des mécanismes qui réduiront le risque que la vulnérabilité ne retombe en production. Il existe plusieurs façons d'assurer la sécurité du système.
- Ainsi, le travail d'analyse de la sécurité des applications est étroitement lié aux équipes et au processus de développement exactement à l'intérieur?
- Oui, un analyste de la sécurité des applications devrait poser une question sur le processus de développement. SDLC (Secure Development LifeCycle) est le premier mot à la mode que vous rencontrez lorsque vous lisez sur la sécurité des applications. En bref, le but de ces actions est de s'assurer que les considérations de sécurité du système sont prises en compte à chaque étape du développement. Dans ce cas, ce n'est pas toujours un spécialiste de la sécurité qui est engagé dans l'exécution de tâches spécifiques, parfois vous pouvez déléguer à d'autres membres de l'équipe. Après tout, plus tôt vous rencontrez un problème, moins il est coûteux de le résoudre.
L'esprit humain est toujours indispensable pour trouver des vulnérabilités
- Les problèmes avec le produit peuvent être trouvés au niveau de la spécification, de sa discussion, de son prototype, de son croquis, lorsqu'il n'y a pas une seule ligne de code. Mais les problèmes de sécurité à quel stade devient-il possible de trouver? Et est-il possible de les retrouver avant même d'écrire le code?
- Bien sûr, car il y a des problèmes directement liés à la manière dont les exigences sont formulées. Permettez-moi de vous donner un exemple fou. Vous faites un formulaire de connexion, et le concepteur vous dit: "et laissez nos utilisateurs dire qu'ils n'ont pas simplement saisi le mauvais mot de passe, mais ils ont fait une erreur dans la dernière lettre de leur mot de passe." Autrement dit, le libellé de l'exigence peut être intrinsèquement dangereux.
De plus, au stade des savoirs traditionnels, on peut supposer que le système sera soumis à certaines vulnérabilités et que certains mécanismes de protection devront être mis en œuvre. Si vous prenez le même formulaire sur le site, vous devez absolument faire un captcha pour éviter de deviner le mot de passe. Par conséquent, ces points doivent être mentionnés dans le développement de l'architecture.
- À quelle fréquence les tests de sécurité sont-ils intégrés aux processus CI / CD, et est-ce difficile? Autrement dit, afin de pouvoir «déchirer» n'importe quel pipeline dans Jenkins ou TeamCity, et il y avait une étape distincte où les tests de sécurité sont exécutés. Est-ce réel?
- Il y a des directives sur le même SDLC, il y a des exigences des régulateurs. En conséquence, les entreprises qui ont un processus de développement mature les mettent en œuvre. Il existe des outils pour automatiser une partie du processus, mais le rapport entre l'effort et le résultat dépend de la nature du projet et du stade de développement auquel ces techniques ont commencé à être mises en œuvre.
Si l'application est écrite à partir de zéro, vous pouvez proposer d'utiliser un analyseur statique pour éviter les instructions douteuses dans le code. Et si 10 ans avant d'écrire le code, et que vous y veniez avec votre outil pour de l'argent fou, alors, bien sûr, vous en trouverez un peu.
Tous les outils automatiques ont le problème de ne pas savoir comment le système fonctionne. Si un composant individuel du système peut être isolé, il peut être testé avec des outils prêts à l'emploi. Mais dans un système avec de nombreuses dépendances, les scanners automatisés peuvent perdre des informations précieuses.
Analyses de sécurité dans d'autres entreprises
- Quelle entreprise ou quel projet individuel, selon vous, est le fleuron de l'analyse de la sécurité des applications, sur la base des discours et des présentations de conférence de l'entreprise?
- Microsoft a proposé l'implémentation de SDLC, qui est devenu le canon. Mais voici comment ils fonctionnent à leur niveau le plus bas, quels outils sont utilisés, je ne sais pas.
Facebook écrit beaucoup sur la façon dont tout est organisé techniquement: comment ils analysent le code, trouvent les vulnérabilités dans les systèmes de travail, etc. Certains outils Facebook sont même des projets open source, vous pouvez donc approfondir leurs tripes.
Si nous prenons des entreprises russes, alors Sberbank a parlé de façon intéressante de la façon dont elles ont officialisé SDLC, documenté le processus. Bien que leur équipe de sécurité des applications soit assez grande, cela ne suffit pas pour de nombreux développeurs. Par conséquent, ils éduquent les champions de la sécurité en équipe, mettent dans leur tête des connaissances sur la sécurité et, dans ce cas, les champions peuvent lever le drapeau rouge.
Yandex parle lors de conférences de choses intéressantes comme "comment pirater un navigateur".
- Est-il réaliste que le testeur après la conférence, où il a entendu un rapport sur les menaces et les outils, obtienne un effet significatif après leur mise en œuvre? Par exemple, une entreprise achètera un scanner pour 10 000 $ à la recherche de trous dans le pipeline Jenkins. Ou est-il plus important de connaître les mécanismes d'exploitation des vulnérabilités afin de mettre en œuvre certaines choses?
- Vous ne pouvez pas acheter un scanner pour 10 mille dollars (rires) . Si nous parlons de la recherche de vulnérabilités, cela revient à tester des scénarios spécifiques. Les scénarios sont tirés de collections de connaissances générales.
Par exemple, OWASP (Open Web Application Security Project) publie des guides sur la façon d'effectuer des tests de sécurité, des révisions de code, etc. Par exemple, dans OWASP Application Security Verification Standard, il est écrit sur tout ce qui doit être testé. Pour lire le document, aucune connaissance particulière n'est requise, il suffit de connaître les applications Web pour que tout testeur puisse le gérer.
Les feuilles standard et de triche sont suffisantes pour exécuter des tests manuels. Il indique quels types de vulnérabilités existent et comment les rechercher. Certains tests ne peuvent pas être effectués par des scanners standard par définition: par exemple, ceux liés à la vérification de la logique métier.
D'un autre côté, si vous devez trouver XSS, vous devez ajouter un guillemet, un crochet, etc. dans chaque paramètre modifié. Et s'il y a 100 millions de paramètres dans le système, la tâche n'est plus réalisable. Mais les outils automatisés feront très bien l'affaire avec elle.
Mais lorsque vous démarrez le scanner, il peut y avoir trois scénarios:
- L'outil a publié un rapport où il y a beaucoup de bons bogues reproductibles et un peu de faux positifs (idéal, mais peu probable).
- Le rapport contient 20 mille trouvailles, dont environ 1% sont vraies. Par conséquent, vous devez vous asseoir et déterminer si les vrais problèmes.
- L'outil ne pouvait pas comprendre quelque chose dans le système, par conséquent, il a publié un rapport dans lequel tout va bien, mais ce n'est pas le cas. Par exemple, je n'ai pas pu compiler le code car je n'ai pas pu trouver la bibliothèque. Ou s'agit-il d'un scanner de vulnérabilités qui a effectué 10 demandes, s'est heurté à l'anti-flood et n'a pas reçu de réponse du serveur pour le million de demandes restantes.
Par conséquent, je pense qu'il est important de comprendre néanmoins que le scanner est «sous le capot» afin de sélectionner l'outil correspondant à la tâche à résoudre et d'évaluer correctement le résultat.
Alexander développera le sujet du bon choix et du réglage des outils dans son rapport sur Heisenbug. Elle y parlera de l'application et de la personnalisation des solutions SAST SonarQube et Find Security Bugs pour rechercher des vulnérabilités dans son projet. Quelles fonctionnalités ces outils offrent-ils «prêts à l'emploi»? Et comment étendre leurs fonctionnalités par eux-mêmes? À titre d'exemple, le conférencier examinera les vulnérabilités de XSS et IDOR.
La conférence se tiendra les 5 et 6 décembre à Moscou.