49) Concevoir la sécurité comme une discipline exclusivement technique,
mais aussi la considérer comme uniquement organisationnelle.
50) Croire aux solutions miracles. S'il existe évidemment de bonnes
solutions pour répondre à une menace, le remède absolu n'existe pas, ni le risque
zéro.
51) Pratiquer la sécurité par l'obscurantisme. Ce n'est pas parce qu'une
page est cachée que personne ne la trouvera. Dissimuler l'existence de vulnérabilités
dans le code source de son application n'est pas plus une protection. Si un développeur
a pu les déceler, il faut considérer que d'autres individus, potentiellement malveillants,
pourraient tout autant y parvenir.
52) Prendre en compte la sécurité au moment du déploiement. Une intégration
trop tardive sur une application déjà fonctionnelle risque d'être confrontée à
des freins humains. Un projet VoIP en est un parfait exemple. La voix sur IP est
souhaitée, puis déployée, et seulement alors la cellule sécurité est consultée.
On prend rarement la décision d'apporter des modifications à des solutions opérationnelles.
Cela contraint en outre à sécuriser par rustines une démarche qui n'a rien d'optimale.
53) Penser qu'une personne passera derrière et corrigera les problèmes.
Comme pour une solution temporaire non sécurisée, le projet aura tendance à demeurer
en l'état.
54) Considérer que la sécurité un jour est valable pour tous les autres.
La sécurité totale n'existe pas. Il faut identifier et contrôler son maillon faible.
En outre, la sécurité n'est pas un statut acquis Ad vitam æternam. Il faut mesurer,
réévaluer et accepter de se remettre en cause, faire une photo régulière de l'état
de sa sécurité.
55) Croire que la sécurité passe uniquement par la conformité aux normes
ISO. Si elles ne sont pas à négliger, le RSSI ne doit pas pour autant faire abstraction
des règles élémentaires, souvent simples et efficaces.
56) Confondre les parties sécurité opérationnelle et organisationnelle.
L'une est chargée de définir les politique de sécurité et l'autre de les mettre
en uvre. La sécurité opérationnelle est en outre souvent confiée à des opérationnels
du réseau dont la préoccupation principale est la disponibilité.
57) Sécuriser les parties du système d'information qui n'en ont pas besoin
et négliger celles qui le nécessitent. Il est préférable d'adopter une approche
par les risques, de s'assurer de la prise en compte des plus sensibles pour l'entreprise
et de veiller à l'adéquation des mesures correctives.
58) Rédiger des procédures verbeuses et décolérées de la réalité. Pour
pouvoir être comprises, appliquées et surtout efficaces, nul besoin d'emprunter
sa plume à Balzac. Les procédures se doivent avant tout d'être claires, synthétiques,
et d'être adaptées à la situation réelle de l'entreprise.
59) Laisser à l'abandon des domaines pour lesquels l'entreprise manque d'expertise.
Ce sont autant d'aspects liés à la sécurité qui risquent d'être oubliés et non
contrôlés. Imaginons une société X qui a recruté deux développeurs Web, sans pour
autant disposer d'un administrateur de base de données. Un responsable doit être
désigné avec une sensibilisation à la sécurité du système employé.
60) Négliger de se tenir informé des vulnérabilités et de l'évolution
des techniques d'attaque.
