Une vulnérabilité dans un service présent sur l'appareil, mais qui ne fonctionne pas et qui n'est pas utilisé du tout, doit-elle être mentionnée dans le rapport de vulnérabilité?
Disons que j'ai analysé notre routeur Cisco et qu'il a renvoyé 20 vulnérabilités. Cependant, la plupart d'entre eux sont liés à des services spécifiques que ce routeur ne fonctionne pas, par exemple CVE-2016-6380 - nous n'exécutons pas de serveur DNS sur notre Cisco, nous n'y sommes donc pas vulnérables.
D'une part, je devrais exclure cette vulnérabilité du rapport - nous ne sommes pas réellement vulnérables, et tout ce bruit blanc s'additionne rapidement et le rapport devient inutile, car personne ne le lit.
D'un autre côté, que se passe-t-il si un jour nous décidons d'activer le DNS ou un autre service? Nous ne saurons pas que nous sommes vulnérables car il n'est plus dans le champ d'application.
Je me demande donc si vous pouvez m'orienter dans la bonne direction ici. Je parcourt actuellement le NIST 800-115, mais je ne trouve pas encore la réponse. Le NIST en dit-il quelque chose?
TLDR
Une vulnérabilité dans un service présent sur l'appareil, mais qui ne fonctionne pas et qui n'est pas utilisé du tout, doit-elle être mentionnée dans le rapport de vulnérabilité?
Cela dépend de la façon dont votre organisation utilise ce type de rapports.
Si les personnes responsables de la planification et/ou de la mise en œuvre des contrôles de sécurité lisent une fois ces documents et ne les consultent plus jamais OR les considèrent davantage comme des directives que des règles réelles sur la configuration d'un environnement, Je peux voir que vous voudrez peut-être vous abstenir d'ajouter trop d'informations dans le rapport. Tout simplement parce que vous voulez vous assurer que les vulnérabilités qui sont réellement présentes sont satisfaites par des mesures de sécurité.
D'un autre côté, s'il s'agit de documents "vivants" qui fixent des règles sur la façon dont les contrôles doivent être planifiés et mis en œuvre ET les personnes responsables mettent à jour ces documents si l'infrastructure change à un certain moment, vous voulez certainement inclure ces vulnérabilités.
À mon humble avis, en tant que personne qui organise la sécurité des informations dans une institution, c'est le type de culture que vous devriez promouvoir.
Si vous avez peur que votre document devienne trop encombré, vous pouvez toujours travailler avec sa structure. Quelque chose qui a été fait dans une organisation avec laquelle j'ai travaillé, c'est que des vulnérabilités comme celle-ci ou d'éventuelles vulnérabilités futures ont été ajoutées dans une annexe au document principal. Si l'infrastructure était modifiée de quelque façon que ce soit, les administrateurs pourraient d'abord vérifier l'annexe, si l'un des changements apportait les vulnérabilités qui y sont répertoriées.
Un dernier point que je voudrais souligner: bien que VOUS n'ayez pas activé ces fonctionnalités, cela ne signifie pas qu'un attaquant ne le fera pas après avoir accédé au routeur. Il est donc raisonnable de mettre en œuvre des mesures de sécurité au cas où. Cela pourrait être quelque chose qui devrait être évalué dans une analyse des risques.
Pour citer ISO/IEC 27005:
La présence d'une vulnérabilité ne cause pas de préjudice en soi, car il doit exister une menace pour l'exploiter. Une vulnérabilité qui n'a pas de menace correspondante peut ne pas nécessiter la mise en œuvre d'un contrôle, mais doit être reconnue et surveillée pour les changements.
En tant que client de rapports de vulnérabilité, je dirais que oui, mais c'est certainement une perte de temps de lui donner le même poids que les autres vulnérabilités. Par exemple, des trous d'accès à distance massifs exploitables en direct ou des backdoors malveillants actifs n'obtiendraient pas la même couverture que quelque chose comme une vulnérabilité DoS ou dans ce cas une vulnérabilité dans un logiciel désactivé.
À mon humble avis, le rapport devrait avoir un résumé analytique, des conclusions techniques, puis entrer dans les détails fastidieux.
Quelque chose comme ce que vous décrivez serait une ligne dans les résultats techniques et aurait quelques informations dans la section des détails fastidieux.
CVE-2016-6380 signifierait cependant que vous ne corrigez pas régulièrement les appareils, ou que vous avez un cycle de correctif très lent. Cela pourrait être un risque accepté de la part du client, mais il devrait être examiné. Il peut mérite d'être mentionné dans le résumé. Pas de trucs CVE #, les dirigeants s'en moquent.
Voir plus loin dans NIST 800-115 7.3
...
Bien que les vulnérabilités individuelles doivent être identifiées et résolues, l'identification de la cause première des vulnérabilités est essentielle pour améliorer la sécurité globale de l'organisation, car une cause profonde peut souvent être attribuée à des faiblesses au niveau du programme. Certaines causes profondes courantes comprennent:
- Gestion insuffisante des correctifs, comme le fait de ne pas appliquer les correctifs en temps opportun ou de ne pas appliquer les correctifs à tous les systèmes vulnérables
...
Tout d'abord, vous devez avoir une idée de ce que vous recherchez et de ce que vous rapportez.
Par exemple, l'étendue de l'analyse permet de découvrir et de signaler toutes les vulnérabilités, y compris les vulnérabilités à faible risque, ou simplement à haut risque, ou peut-être simplement les vulnérabilités critiques. Cela aurait dû être défini avant même de lancer l'analyse des vulnérabilités.
S'il s'agit d'un faux positif confirmé, supprimez-le du rapport.
S'il s'agit d'un service présent mais non utilisé et qu'il s'agit d'une vulnérabilité de portée confirmée, incluez-le dans le rapport afin que le service puisse être supprimé de la cible.
Si quelqu'un prend une décision d'achat, il pourrait dire "ce routeur prend en charge la résolution DNS dans le routeur. Nous ne l'utilisons pas maintenant, mais nous pourrions le faire à l'avenir, alors nous achetons ce routeur et pas un peu moins cher sans le fonctionnalité".
Cette vulnérabilité signifie que le routeur ne peut pas être utilisé de cette façon, donc la fonctionnalité ne doit pas être utilisée pour la décision d'achat. En d'autres termes, cela devrait figurer dans votre rapport pour cette raison. Et si le service peut être supprimé de l'appareil, il doit être supprimé. (Vous pourriez découvrir que votre supposition selon laquelle il n'a pas été utilisé était en fait erronée si le service est supprimé et que les gens se plaignent).