les pièges habituels (pièces jointes piégées, hameçonnage, etc.) et ils collaborent avec
la DSI en cas d’incident.
Des revues régulières sur les accès aux infrastructures (pare-feu, serveurs, bases de
données, contrôleurs de baies, de disques, etc.) et sur les accès aux applications
donnent une assurance raisonnable que seules les personnes habilitées accèdent aux
ressources.
Les points clés du SI sont surveillés, permettant de détecter et de qualifier rapidement
les événements de sécurité. Ceci se fait généralement par le moyen d’un SOC.
Chacun sait comment agir en cas d’incident de sécurité, car un processus de gestion
d’incidents est formalisé, exploité et amélioré régulièrement.
Enfin, un véritable contrôle interne de la sécurité est appliqué afin de s’assurer que les
mesures de sécurité techniques sont opérationnelles et efficaces.
Ces mesures font en sorte que le SI résiste bien aux atteintes élémentaires. Pour
compromettre le SI, l’attaquant doit maintenant concevoir des attaques bien plus
complexes, nécessitant une véritable expertise. Et même dans ce cas, les dispositifs de
surveillance et de gestion d’incidents permettent de détecter, puis de limiter l’impact de
telles attaques.
Malheureusement, certaines situations chroniques dans toutes les entreprises doivent
tempérer notre enthousiasme.
La complexité atteinte de nos jours par les SI a rendu impossible une sécurisation
complète.
Même si les identités sont très bien gérées, il est impossible d’avoir la certitude
absolue qu’aucun compte indûment privilégié n’est passé à travers les mailles des
revues.
Certains systèmes ou applications historiques échappent totalement à la sécurité, car
ils sont tellement anciens, et les compétences pour les maintenir sont tellement
absentes, qu’il est souvent plus risqué d’y toucher que de ne rien faire.
Il arrive que certaines directions de l’entreprise résistent encore aux bonnes pratiques ;
des raisons politiques nécessitent d’attendre la retraite ou la mutation de certains
responsables clés pour évoluer.
Face à cette situation, le RSSI doit procéder à un inventaire de tous ces risques résiduels
et, pour chacun, proposer soit leur acceptation, soit leur contournement. L’acceptation de
certains risques résiduels peut être motivée par des considérations économiques, ou parce
que les impacts sont jugés acceptables, ou bien encore par des considérations
conjoncturelles.
Exemple
Une vieille application métier stockant dans un fichier tous les mots de passe de tous les utilisateurs est un
danger important pour l’entreprise. Pourtant, s’il est prévu de remplacer cette application dans les six mois
qui viennent, la direction peut parfaitement juger acceptable le fait de ne rien entreprendre pour sécuriser
l’ancienne application. En effet, le coût et le risque opérationnel de modifier l’ancienne application sont
disproportionnés si l’on tient compte de sa disparition prochaine.
C’est pour cette raison qu’en général, le niveau de sécurité maîtrisée est très rarement
la DSI en cas d’incident.
Des revues régulières sur les accès aux infrastructures (pare-feu, serveurs, bases de
données, contrôleurs de baies, de disques, etc.) et sur les accès aux applications
donnent une assurance raisonnable que seules les personnes habilitées accèdent aux
ressources.
Les points clés du SI sont surveillés, permettant de détecter et de qualifier rapidement
les événements de sécurité. Ceci se fait généralement par le moyen d’un SOC.
Chacun sait comment agir en cas d’incident de sécurité, car un processus de gestion
d’incidents est formalisé, exploité et amélioré régulièrement.
Enfin, un véritable contrôle interne de la sécurité est appliqué afin de s’assurer que les
mesures de sécurité techniques sont opérationnelles et efficaces.
Ces mesures font en sorte que le SI résiste bien aux atteintes élémentaires. Pour
compromettre le SI, l’attaquant doit maintenant concevoir des attaques bien plus
complexes, nécessitant une véritable expertise. Et même dans ce cas, les dispositifs de
surveillance et de gestion d’incidents permettent de détecter, puis de limiter l’impact de
telles attaques.
Malheureusement, certaines situations chroniques dans toutes les entreprises doivent
tempérer notre enthousiasme.
La complexité atteinte de nos jours par les SI a rendu impossible une sécurisation
complète.
Même si les identités sont très bien gérées, il est impossible d’avoir la certitude
absolue qu’aucun compte indûment privilégié n’est passé à travers les mailles des
revues.
Certains systèmes ou applications historiques échappent totalement à la sécurité, car
ils sont tellement anciens, et les compétences pour les maintenir sont tellement
absentes, qu’il est souvent plus risqué d’y toucher que de ne rien faire.
Il arrive que certaines directions de l’entreprise résistent encore aux bonnes pratiques ;
des raisons politiques nécessitent d’attendre la retraite ou la mutation de certains
responsables clés pour évoluer.
Face à cette situation, le RSSI doit procéder à un inventaire de tous ces risques résiduels
et, pour chacun, proposer soit leur acceptation, soit leur contournement. L’acceptation de
certains risques résiduels peut être motivée par des considérations économiques, ou parce
que les impacts sont jugés acceptables, ou bien encore par des considérations
conjoncturelles.
Exemple
Une vieille application métier stockant dans un fichier tous les mots de passe de tous les utilisateurs est un
danger important pour l’entreprise. Pourtant, s’il est prévu de remplacer cette application dans les six mois
qui viennent, la direction peut parfaitement juger acceptable le fait de ne rien entreprendre pour sécuriser
l’ancienne application. En effet, le coût et le risque opérationnel de modifier l’ancienne application sont
disproportionnés si l’on tient compte de sa disparition prochaine.
C’est pour cette raison qu’en général, le niveau de sécurité maîtrisée est très rarement