30) Se reposer sur un seul moteur antivirus, voire sur une seule technologie.
Les antivirus ne détectent pas les virus avec la même efficacité, tout comme les
sondes IDS n'apportent pas nécessairement les mêmes performances. En outre si
le logiciel est victime d'une faille ou d'une intrusion, l'autre solution assurera
une garantie.
31) Regrouper tous les hôtes sur un réseau unique. Il doit être divisé
en sous-réseaux, notamment afin d'empêcher la propagation d'un code malveillant
ou un intrus d'accéder à l'ensemble des ressources. La segmentation permettra
un contrôle centralisé et l'élaboration de règles d'accès par segment. Les serveurs
en premier lieu doivent être isolés des stations utilisateurs et n'exposer à ceux-ci
que les services qui leurs sont utiles.
32) Considérer que la sécurité physique est facultative. Un IPBX rangé
dans un placard à balais ou un serveur critique rangé sous un bureau font courir
des risques. En outre, les consoles doivent être verrouillées par mesure de prudence,
même pour des absences brèves. Un accès physique à une machine peut mener à sa
compromission en quelques minutes.
33) Laisser non configurés des Switchs ou des appareils disposant des
fonctionnalités sensibles sous prétexte qu'elles ne seront pas utilisées. Certes
l'appareil est fonctionnel mais l'accès administrateur au périphérique reste celui
par défaut. Or, une simple recherche sur Google suffit pour lister les identifiants
par défaut de chaque constructeur. Il n'est ainsi pas rare que l'authentification
se fasse via le couple admin et password. Par ailleurs, de nombreux dispositifs
contiennent des fonctionnalités permettant de prendre pied sur le réseau, sans
pour autant être détecté : switchs et imprimantes présentent tout deux un système
d'exploitation minimaliste, mais existant.
34) Mettre en place une solution temporaire - imparfaite - sur le réseau
pour pallier rapidement à un déficit de fonctionnalité. Le temporaire a la fâcheuse
tendance à devenir permanent. Par exemple, héberger temporairement un environnement
de test et un autre de production sur un même serveur, où figure notamment les
codes d'accès des développeurs, peut se solder par une compromission du site de
production.
35) Ne collecter aucuns logs. Les sources doivent être multiples et
réparties sur le réseau. Les logs doivent de plus être stockés et archivés sur
un support en dur. Attention toutefois à rester en conformité avec la CNIL et
les différentes dispositions légales. Les logs ne servent cependant à rien s'ils
ne sont pas lus ou exploités. Un volume excessif n'est pas exploitable sans un
outil classant les informations pour que l'administrateur n'ait à se préoccuper
que de ce qui est sensible. A défaut, mieux vaut peu de logs pertinents et consultés
régulièrement qu'une grande masse qui ne sera jamais passée en revue.
36) Centraliser les composants de sécurité sur les mêmes entités. Firewall
et IDS devraient être des éléments distincts notamment. Une faille dans un service
de l'appareil risquerait sinon d'être exploitée pour court-circuiter les autres.
Cette séparation des fonctions et pouvoirs permet de minimiser les risques en
ne mettant pas tous ses ufs dans le même panier.
