Sécurité des systèmes d'information

Extraits

[...] Celui-ci aurait restreint les accès à certaines adresses IP internes ou via certains VPN. Ensuite, une segmentation réseau stricte aurait pu être réalisée. En effet, le serveur de données ne doit jamais être directement exposé à Internet. Pour limiter le risque, il aurait fallu revoir l'architecture en faisant une architecture en couches avec une zone d'accès (front-end), une zone applicative, et une zone de données cloisonnées. Quatrièmement, il aurait fallu réaliser une analyse régulière de la surface d'exposition soit un scan de vulnérabilités. [...]

[...] Tout cela permettra de minimiser les fuites de data. En cas de non-conformité aux règles de sécurité, je développerai l'argumentaire suivant. Dans un premier temps, je mettrais en avant le risque majeur de compromission interne. En effet, tous les comptes avec des privilèges qui seraient trop étendus serait des cibles idéales pour une élévation de privilège ou une exploitation en cas de phishing ou malware. De là, je conseillerai aux clients de limiter les accès pour éviter les possibilités d'être attaqué par les employés. [...]

[...] Un serveur Elasticsearch contient des données clients. Il est déployé en production avec une configuration par défaut, sans authentification, et accessible depuis Internet. Lors de la mise en ligne, la configuration a été oubliée ou modifiée par erreur sans vérification. L'attaquant réalise un scan de ports. Il peut le faire par Shodan par exemple. Il trouve le serveur puis trouve facilement et librement toutes les données. Il existe plusieurs protections possibles et envisageables pour que ce problème n'existe pas. Premièrement, une mise à jour des composants ainsi qu'une gestion des vulnérabilités peut être envisagée. [...]

[...] Il faudrait aussi vérifier les fichiers de configuration du serveur. Enfin, il serait préférable de réaliser une recherche sur les forums et bases de données de vulnérabilités. Question 2 : Si je suis missionné pour auditer le SI d'un client qui héberge et exploite lui-même une partie de ses systèmes dans ses propres datas centers, je commencerai d'abord par me concentrer sur la gestion des accès et des privilèges des utilisateurs. Dans le cas d'un SI hébergé en propre, le point dit critique que je regarde est premier est la gestion des accès. [...]

[...] Cela aurait pu passer par l'ajout d'un second facteur d'authentification via OTP ou une application mobile. Ce procédé aurait empêché l'accès et même dans le cas présent d'un vol d'identifiants puisque l'information ne serait pas arrivée. Ensuite, il y aurait pu y avoir une formation plus importante des employés du service client, et des autres services. Grâce à celle-ci, l'employé aurait pu détecter les indices montrant d'un faux mail que soit l'adresse mail, l'URL, le langage mobilisé ou les fautes? [...]