Cinq règles essentielles au management des firewalls:
leçons tirées de notre expérience
Résumé analytique
Le management des firewalls demeure le système de protection de réseau principal de toute entreprise. Ce...
Définissez clairement votre plan
de gestion du changement
Il n’y a pas de raison de craindre une modification des règles
d...
Cas n° 2 –
Mise à niveau en direct.
« J’étais une toute nouvelle recrue au poste d’ingénieur
de réseau dans une petite soc...
Cas n° 3 –
Comment la configuration
a-t-elle été effectuée ?
« Une société de jeux en ligne avait contacté une
société de ...
Cas n° 4 –
Quo vadis ? Des elfes de sang, semble-t-il.
« Une entreprise technologique de taille moyenne
a décidé un jour d...
Cas n° 5 –
Prenez connaissance de votre
politique de sécurité.
« J’ai travaillé une fois pour une société qui
était en ple...
Conclusion
Considérés comme une première ligne de défense du réseau, les systèmes de sécurité sont essentiels pour protége...
Upcoming SlideShare
Loading in...5
×

Cinq règles essentielles au management des firewalls

523

Published on

La principale protection des entreprises reste encore aujourd’hui le pare-feu. Cependant, bien savoir le gérer demande de la part des directeurs de sécurité réseau une implication et un temps conséquent. A travers 5 cas concrets, les équipes Sécurité de Dell SecureWorks suggèrent plusieurs techniques et bonnes pratiques pour aider les directeurs informatiques à gagner en efficacité.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
523
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cinq règles essentielles au management des firewalls

  1. 1. Cinq règles essentielles au management des firewalls: leçons tirées de notre expérience
  2. 2. Résumé analytique Le management des firewalls demeure le système de protection de réseau principal de toute entreprise. Cette activité requiert une portion du temps de travail des directeurs de sécurité réseau plus importante que pratiquement n’importe quelle autre activité. De plus, il est facile de se tromper, tout particulièrement lorsque le personnel responsable sont des administrateurs qui jouent le double rôle de personnel responsable et de la sécurité et de l’administration. L’équipe de sécurité des informations de Dell SecureWorks a identifié cinq domaines d’intérêt prioritaire pour les directeurs informatiques relatifs au management des firewalls. Nos ingénieurs de sécurité mettent à notre disposition des cas concrets qui permettent de souligner l’importance de ces recommandations. Les actions énoncées ci-dessous peuvent aider les directeurs informatiques à économiser du temps, des ressources financières et leurs charges administratives. Nous conseillons aux administrateurs de prendre en considération les suggestions suivantes pour assurer un management des firewalls plus efficace : • Définissez clairement votre plan de management du changement. Une autorité de management des firewalls centralisée et un processus bien documenté peuvent aider à éviter des changements indésirables dans la configuration actuelle du réseau, limitant ainsi le risque de voir un changement affecter la fonctionnalité, empêcher des modifications ultérieures ou créer une brèche dans la sécurité du réseau. • Mettez à l’essai les principales modifications de vos firewalls avant de vous mettre en ligne. Assurez-vous de mettre à l’essai les principales modifications apportées à vos firewalls avant de les mettre en service. Si possible, créez un environnement de mise à l’essai qui reflète vos systèmes de production. Ne pas tester correctement les modifications réalisées risque d’interrompre vos activités en raison de perturbations telles que des latences ou des pannes totales de réseau. • Protégez-vous en prenant un instantané de la configuration de votre firewall avant de procéder à toute modification majeure. Il est primordial de mettre en place un système d’inversion des modifications avec des plans de basculement et de récupération intégrés avant qu’une situation d’urgence ne survienne. Les instantanés du système constants permettent de gagner du temps et de l’argent en cas de problème au niveau de la migration ou de défaillance inattendue de l’équipement. • Contrôlez le droit d’accès des utilisateurs à la configuration du firewall. Les journaux d’accès des utilisateurs peuvent jouer le rôle d’un système de détection des intrusions susceptible de révéler les tentatives d’accès non autorisé de l’intérieur ou de l’extérieur du réseau. Les journaux ont également la capacité de révéler toute modification latente, progressive et indésirable à la politique de sécurité. • Prévoyez des audits de politique réguliers. Avec le temps, les règles risquent de ne pas correspondre à la politique de sécurité et les règles inutilisées risquent de boucher le trafic et de faire obstacle à toute modification du réseau. Un système de sécurité déphasé peut également présenter des risques juridiques. Il est important de passer en revue régulièrement votre politique de sécurité, de la mettre à jour le cas échéant, puis de vérifier la conformité à cette politique en passant en revue les règles et la configuration du firewall en place.
  3. 3. Définissez clairement votre plan de gestion du changement Il n’y a pas de raison de craindre une modification des règles de votre système de sécurité. Il s’agit d’un composant naturel et nécessaire pour toute société en pleine croissance qui peut vous aider à détecter des changements dans l’environnement de sécurité ou de nouveaux besoins au niveau de votre base utilisateurs. Cependant, si vous ne définissez pas clairement votre plan de management du changement, une modification de règle toute simple dans votre système de sécurité risque d’avoir des conséquences désastreuses dans l’ensemble du réseau de votre organisation. Les plans de management du changement permettent de minimiser les risques. Un plan de management efficace a la capacité de capter des métriques essentielles pendant une modification des règles d’accès. Ces métriques – par exemple, une baisse vertigineuse du trafic IP ou une hausse considérable émanant d’un domaine particulier – permettent d’identifier les faiblesses ou les défaillances susceptibles d’intervenir pendant une modification. Ce type de contrôle permet d’avertir à l’avance du risque de pannes généralisées ou des répercussions importantes sur les systèmes vitaux et les niveaux de service. Il permet également d’obtenir un rapport d’audit mesurant le succès ou l’échec d’une série de modifications effectuées au fil du temps, utile dans un but de comparaison. Tout plan de management du changement devrait incorporer les éléments suivants : • Établir une procédure approuvée pour les demandes de changement de politique et fixer les exigences de la politique en œuvre • Implémenter des contrôles appropriés permettant d’identifier qui a ou n’a pas le droit d’autoriser un changement • Centraliser le management du système de sécurité pour créer, distribuer et appliquer efficacement les politiques • Définir les points de communication et de coordination requis pour effectuer correctement toute modification • Créer un parcours d’audits qui permettra de suivre les demandes, les implémentations et les conséquences d’une modification du système de sécurité Le Management du changement nécessite bien plus que de simples outils logiciels. Il s’agit d’un processus qui implémente une discipline déterminée sur le réseau et qui requiert l’approbation de toutes les personnes ayant accès à la configuration du système de protection. Si vous n’avez pas au préalable clairement défini la politique et les priorités du système de sécurité, un système de management du changement finira par être contrecarré par le comportement des clients réseau. Cas n° 1 – Cas d’un échec de modification. « J’ai travaillé dans une grande société de gestion des retraites où j’étais chargé du management des systèmes de sécurité. Un de nos directeurs informatiques portait le titre de professionnel agréé en sécurité des systèmes d’information mais disposait d’un sens pratique relativement limité. Un jour, je me trouvais dans notre centre d’exploitation de réseau et j’ai par hasard répondu au téléphone alors qu’il appelait le centre. « Notre firewall ne bloque pas les fenêtres contextuelles. ». Bon, c’est un fait. Notre système firewall servait d’antivirus et avait la capacité de détecter certaines intrusions, mais il n’avait jamais servi de cloison contre les fenêtres contextuelles. « Je veux que notre firewall bloque toutes les fenêtres contextuelles », fulminait-il au bout du fil. « Heu, désolé mais… le firewall n’a pas été conçu pour bloquer les fenêtres contextuelles. La seule manière de procéder serait de bloquer la sortie du port 80. Et cela risquerait fort de perturber vos utilisateurs », le mettais-je en garde. Mais il m’avait coupé la parole avant même que je n’aie l’occasion de lui expliquer. « Faites-le ». J’ai essayé une fois de plus de lui faire changer d’avis mais sans succès. Je lui ai alors demandé de rédiger une lettre de demande, signée et portant sa clé PGP, pour éviter tout risque de répudiation de sa part. Deux minutes plus tard, il envoyait sa demande de modification sous forme d’ordonnance d’urgence, stipulant que la modification devait être effectuée dans l’heure. Je procédais donc à la modification. Il suffisait désormais d’attendre. Cinq minutes passaient. Mon supérieur s’était entre temps branché sur mon téléphone, en sourdine, pour me soutenir dans ma décision de suivre les procédures qui m’étaient imposées, malgré mes tentatives d’appel à la raison. Le directeur informatique ne manquait pas de rappeler le centre d’exploitation. « QUE SE PASSE-T-IL AVEC L’INTERNET ?? » Je l’envoyais dans un site qui, comme je le savais, allait lui permettre d’utiliser le protocole HTTPS dans la première page. Il parvenait à entrer dans le site. « Très bien, donc l’Internet fonctionne, » lui dis-je. Dans une crise d’apoplexie, il me répondit en hurlant : « NOUS NE POUVONS PAS NAVIGUER DANS LES PAGES NORMALES DU WEB !» « Heu, c’est juste, » lui dis-je. «Vous m’avez demandé de bloquer tout ça.» « REMETTEZ IMMÉDIATEMENT LE SYSTÈME EN ORDRE ! » Avec mon supérieur, nous nous sommes mis à attendre patiemment le coup de téléphone qu’il ne faisait aucun doute que nous allions recevoir. Le dirigeant principal de l’information appelait quelques secondes plus tard. Je lui expliquai la situation en soulignant pourquoi j’étais obligé de suivre la procédure, mais que comme il était désormais impliqué dans la situation, je pouvais remettre les choses en place. Il mit fin à notre conversation en disant : « Ah ! Et autre chose, veuillez retirer son nom de la liste des personnes autorisées. »
  4. 4. Cas n° 2 – Mise à niveau en direct. « J’étais une toute nouvelle recrue au poste d’ingénieur de réseau dans une petite société de fabrication et on m’a demandé de mettre à niveau nos firewalls avec une version relativement nouvelle du logiciel. J’avais auparavant rencontré plusieurs problèmes pour passer à cette version, tellement d’ailleurs qu’il m’a fallu des heures de travail pour restaurer le système à cause de multiples bogues et d’une mise en œuvre inefficace de la part du fournisseur. Conscient de ces problèmes, j’ai contacté mon supérieur pour lui recommander de ne pas installer cette version particulière sauf en cas de nécessité absolue, auquel cas la mise à niveau ne se ferait pas rapidement. Nous nous sommes rendus compte que la version logicielle installée utilisée par nos firewalls avait la capacité de prendre en charge les fonctions qui nous souhaitions implémenter. Cette information n’était pas documentée dans les notes de mise à jour de la version logicielle installée ; mais le fournisseur nous avait remis une documentation écrite stipulant que cette version avait effectivement cette capacité. Malgré toutes ces informations, nos directeurs nous ont fait comprendre qu’ils souhaitaient mettre à jour le système avec cette version. Le matin suivant, nous entamions le processus de mise à niveau des firewalls. A peine avions- nous redémarré le premier firewall que nous rencontrions déjà des problèmes. Le script de mise à niveau que le fournisseur avait implémenté ne fonctionnait pas, nous avons eu affaire à de nombreux bogues et le firewall restait coincé dans une boucle continue qui ne permettait pas d’exécuter quelque commande que ce soit. Il nous a fallu redémarrer le firewall plusieurs fois de suite et passer à un mode spécial pour restaurer la machine et la ramener à la version du logiciel précédente fonctionnelle. L’ensemble du processus a mis le réseau hors disposition pendant plusieurs heures et tout ce travail aurait pu être facilement évité si nous avions pu tester suffisamment le logiciel. » Testez les modifications des firewalls avant de vous mettre en service La modification d’un système de sécurité introduit un risque commercial. Une perturbation grave du système peut créer de sérieux problèmes, ce qui rend la mise à l’essai d’une configuration avant d’entrer en service bien plus importante. Il est prudent d’éviter de modifier les règles du système de sécurité installé sur le dispositif de production qui protège vos systèmes. Une option possible consiste à tester les modifications dans un bac à sable virtuel représentatif de vos systèmes et qui fonctionnerait comme un laboratoire. Il convient de tenir ces machines à l’écart de vos systèmes actifs, soit physiquement soit en créant une configuration d’interface réseau incomplète. S’il vous est difficile de maintenir un environnement d’essai, vous pouvez implémenter les changements de politique dans une console de management centrale, puis les appliquer au firewall en tant que mises à jour de la politique. Cette méthode permet de procéder plus facilement à une inversion qu’en effectuant physiquement la permutation, qui devrait impliquer une mise à l’essai bien plus stricte avant la mise en service. Prévoyez une grande marge de temps pour pouvoir effectuer un test rigoureux avant de procéder à toute modification importante de la configuration de vos firewall. Tout plan de mise à l’essai des modifications du système de sécurité devrait incorporer les éléments suivants : • Passer en revue les politiques de sécurité de toutes les machines du réseau pour vérifier leur cohérence ainsi que les plans de basculement et de récupération • S’assurer que le firewall même dispose d’une sécurité d’accès adéquate • Effectuer un test des données d’entrée et de sortie à l’aide d’un renifleur de paquets approprié • Vérifier que le firewall autorise et bloque les données en fonction des politiques et des règles établies • Effectuer un test de performance complet pour déterminer dans quelle mesure une nouvelle configuration pourra améliorer ou dégrader l’activité du réseau, tout particulièrement dans le cas d’un réseau privé virtuel • Vérifier la compatibilité et l’interopérabilité du firewall avec les autres applications et équipements du réseau — tout particulièrement ceux provenant de fournisseurs et de sources hétérogènes • Créer un parcours d’audit destiné à l’analyse des tendances et des causes fondamentales Il semble important de mentionner que nous voyons bien trop de sociétés utiliser des systèmes de sécurité en fin de cycle de vie qui présentent une capacité de management des correctifs limitée. Un système de management des correctifs peut aider à exécuter les modifications de manière cohérente dans l’ensemble du réseau dans un délai prévu, en incluant les systèmes individuels dans le processus de modification et en interdisant les modifications multiples et simultanées sur un système de sécurité. Un système de management des correctifs permet également d’éviter les modifications indésirables de la configuration actuelle du réseau, limitant ainsi la possibilité de voir un changement nuire à la fonctionnalité du système.
  5. 5. Cas n° 3 – Comment la configuration a-t-elle été effectuée ? « Une société de jeux en ligne avait contacté une société de sécurité non pas pour établir un système de sécurité, mais pour rétablir le système existant. La société de jeux comptabilisait ses pertes en dollars par minutes le jour où le système d’accès utilisateur avait ralenti ne serait-ce qu’un peu ; inutile de préciser les conséquences lorsque l’accès utilisateur se retrouvait entièrement interrompu. De plus, quelque temps auparavant, des problèmes de réseau avaient ralenti l’accès ; en d’autres termes, les joueurs ne parvenaient pas à atteindre les tables virtuelles. Dans ce cas, la société ne faisait pas l’objet d’une attaque, même s’il semblait au début que ce soit le cas. Les clients s’étaient vus refuser l’accès pendant des heures et les directeurs craignaient que certains clients ne se tournent vers d’autres concurrents. Dans un accès de panique, ils se sont mis à changer tout ce qu’ils soupçonnaient être à la source du problème — interrupteurs, routeurs, équilibreurs de charges et… configuration des firewalls. Un jour plus tard, ils se sont rendu compte qu’une partie du problème provenait du fait qu’un de leurs disques RAID avait cessé de fonctionner, et son rétablissement avait ralenti le service. Ils ont plus tard détecté un deuxième problème : l’intrusion d’un virus qui n’avait fait qu’aggraver ce ralentissement. Toutefois, le problème le plus critique à ce point était les mesures prises en réponse au premier problème détecté. La décision de permuter sans attendre tous leurs équipements les avait laissés sans aucune mémoire de la configuration originale qui s’était après tout avérée fructueuse. Personne n’avait pensé à documenter la configuration originale, ni aucune des modifications effectuées. Il avait fallu plusieurs jours de travail pour que la société parvienne à restaurer toutes ses capacités opérationnelles, à un coût total de millions de dollars en pertes commerciales. » Protégez-vous en prenant des instantanés de la configuration de votre système de sécurité avant d’effectuer toute modification Les pires problèmes dans un changement de configuration tendent à survenir au fur et à mesure que d’autres problèmes se produisent, ce qui finit par transformer un problème en un véritable désastre. Imaginez un site Web en interface client et générateur de revenu se trouvant victime d’une attaque de déni de service distribué (DDoS), et que seule une modification de la configuration du système de sécurité ne saurait contrecarrer. Dans de telles conditions, une société n’a souvent pas le temps d’effectuer de tests. Pour cette raison et autres similaires, il est vital de disposer d’un système d’inversion des modifications accompagné de plans de basculement et de récupération avant qu’une situation d’urgence ne se produise. Bien que les instantanés de la configuration découlent souvent d’une réflexion après-coup, excepté en pleine situation de crise, ils constituent un élément essentiel dans un système d’inversion des modifications. Une majeure partie des plateformes ont la capacité d’effectuer des instantanés. Les dispositifs de sécurité adaptatifs de la gamme Cisco ASA 5500 disposent d’une capacité de capture de configuration et peuvent envoyer par email les instantanés d’une configuration à un administrateur de système. Les images et la configuration du SecurePlatform de Check Point Software peuvent être enregistrées et restaurées à l’aide de la commande Récupérer et de l’utilitaire de capture d’écran. Juniper, IBM et certains autres fournisseurs proposent également des systèmes qui disposant de capacités de capture d’écrans. Avec le temps, ces instantanés peuvent apporter bien plus qu’une transition sûre vers une nouvelle configuration — elles permettent d’établir un profil des activités du réseau. Ce profilage peut aider à contrôler l’utilisation des fonctions du réseau et à détecter tout comportement anormal, sursouscription et problèmes de charge. Les outils de capture de configuration peuvent être configurés de manière à envoyer quotidiennement un rapport automatique. Au fur et à mesure que les modifications sont effectuées, ce rapport permet aux directeurs informatiques de revoir les configurations précédentes. Il permet également aux administrateurs de cloner une machine si un dispositif tombe en panne sans préavis. Quelques conseils pour le management d’un changement de configuration : • En cas de transfert vers un nouveau firewall, renforcez votre système de sécurité pour protéger votre réseau contre tout accès non autorisé. Le processus de configuration peut présenter un risque de vulnérabilité sécuritaire temporaire. A ce niveau, installez des correctifs et des logiciels de console nécessaires pour un accès à distance. Seul l’administrateur responsable de cette tâche devrait avoir accès au management du firewall pendant la configuration. Tous les autres services de management du système de sécurité devraient être désactivés. Ne procédez pas à la création de comptes administrateurs subordonnés tant que le réseau n’a pas été correctement configuré. • Synchronisez les horloges internes de chaque firewall avec les horloges de chaque autre équipement de votre réseau pour vous assurer de pouvoir comparer les journaux sans vous trouver déphasé. • Ne conservez pas les fichiers de sauvegarde de configuration du firewall dans votre réseau ! si votre réseau tombe en panne, vous n’aurez plus accès à ces fichiers. Nous avons vu bien trop de sociétés avoir à rétablir entièrement leurs systèmes de sécurité après une panne. Même si cela semble évident, la mise à jour régulière de vos instantanés est essentielle pour tout programme de sécurité solide.
  6. 6. Cas n° 4 – Quo vadis ? Des elfes de sang, semble-t-il. « Une entreprise technologique de taille moyenne a décidé un jour d’effectuer un audit de leur réseau et se sont rendus compte que toute une cabale de joueurs de World of Warcraft (WoW) ont installé le jeu sur leurs portables (chose permise) et y jouaient pendant leurs heures de travail (chose non autorisée). Après de longues discussions, plutôt que de forcer leurs clients à désinstaller le jeu de leurs portables, ils décidèrent d’interdire le jeu au travail et de bloquer les ports WoW au niveau des firewalls des sociétés. Quelques semaines plus tard, le trafic sur leur réseau avait largement diminué. Tout d’un coup, ils remarquèrent que leur réseau avait une fois de plus ralenti. Relativement confus, l’administrateur du réseau décidait de passer en revue les journaux d’accès du système de sécurité et s’est rendu compte que quelqu’un s’était amusé à ouvrir et fermer les ports WoW à partir d’un compte fictif. Le directeur informatique était curieux de savoir qui avait corrompu leur système de sécurité ; il décidait donc de laisser les choses telles quelles pour un certain temps. Peu de temps après, en surveillant attentivement les journaux, il s’est rendu compte que l’un des stagiaires en conception graphique était responsable de l’infraction à la sécurité. Il avait usurpé le mot de passe du firewall principal pour créer un compte fictif. Apparemment, il souffrait d’une grave dépendance au jeu qui se traduisait par 60 à 70 heures de jeu par semaine, y compris le plus gros de son temps au travail. Le stagiaire a été renvoyé. Plusieurs semaines plus tard, la société a commencé à remarquer que le trafic était de nouveau dérégulé. Cette fois-ci, le problème ne semblait pas émaner du WoW. Étant donné que le trafic provenait du port 1080, les responsables ont commencé par penser que le problème venait de l’application Skype que la société utilisait pour les téléconférences vidéo et les appels à l’étranger. Les directeurs informatiques ont considéré remettre à niveau la largeur de bande, mais les journaux ne correspondaient pas vraiment aux modèles de trafic Internet. Après un certain temps de surveillance, ils finirent par déterminer le problème. Deux autres employés avaient téléchargé PuTTY, une implémentation gratuite de Telnet et SSH pour les plateformes Windows et Unix. PuTTY autorise les utilisateurs à se connecter à un PC virtuel à partir d’un tunnel dans le firewall. PuTTY utilise également le port 1080. Les deux employés s’étaient connectés de leur poste de travail à leur ordinateur personnel, à partir duquel ils s’étaient connectés aux serveurs du jeu WoW. Comme le stagiaire coupable, ces deux employés ont été mis à la porte. » Contrôlez l’accès utilisateur à la configuration du firewall Tout administrateur de sécurité informatique qui se respecte surveille de près le trafic de leur firewall. Servant de dispositif de restriction du trafic dans le système de sécurité de votre réseau, le firewall constitue un point d’entrée unique dans le réseau et détient les preuves des connexions indésirables. Le firewall peut dévoiler tout code malveillant, cheval de Troie et kit racine grâce aux alertes déclenchées par les refus de connexion ou les excès de connexions autorisées. Si la lecture d’un journal de trafic firewall peut prêter à confusion, les journaux d’accès aux utilisateurs ont tendance à être bien plus faciles à lire et peuvent servir de système primaire de détection des intrusions. Les journaux utilisateurs fournissent deux types de données de sécurité de grande importance. D’abord et avant tout, les journaux assurent le suivi de la prolifération des politiques. Si les administrateurs autorisés à modifier la configuration du système de sécurité se connectent et effectuent des modifications non autorisées du système, cela risque de compromettre la conformité générale aux exigences de sécurité et entraîner l’instabilité du système pendant les migrations. Deuxièmement, un journal peut dévoiler une tentative d’accès non autorisé de l’intérieur ou de l’extérieur du réseau. Les connexions ratées à votre firewall ou autres serveurs critiques peuvent être considérées comme un signe de tentative d’intrusion et peuvent vous inciter à bloquer ou abandonner la règle selon laquelle toute connexion doit provenir de ce domaine ou de cette adresse IP. Si vous prévoyez d’instaurer une telle règle, assurez-vous d’abord que votre adresse IP n’a pas été usurpée. De la même manière, les connexions de l’extérieur inattendues peuvent signifier qu’un utilisateur non autorisé a accédé à votre système et s’en sert comme d’une rampe de lancement pour spam ou pour attaquer les autres ordinateurs connectés à votre serveur Internet. Nous vous recommandons de vérifier régulièrement votre liste d’accès — peut-être même quotidiennement — pour vous assurer que personne n’a effectué de modification aux règles de votre système de sécurité. Les directeurs informatiques devraient avoir à leur disposition une liste de noms des personnes autorisées à effectuer des modifications de ces règles, et cette liste devrait être conservée en lieu sûr… hors ligne. La conservation d’une telle liste devrait faire partie intégrante d’un plan de management du changement général de manière à expliquer au personnel bénéficiant d’un droit d’accès administratif comment procéder pour modifier une règle. La plupart des produits et plateformes de système de sécurité majeures fournissent des journaux d’accès utilisateur. Il est évident que le journal en soi doit être sûr, pour éviter qu’un intrus expert ne s’introduise et ne modifie son contenu de manière à éliminer toute trace d’intrusion. Si vous le pouvez, pensez à créer un ou plusieurs comptes utilisateurs administratifs avec accès aux journaux en lecture seule et servez-vous de ces comptes de référence pour effectuer l’audit des journaux.
  7. 7. Cas n° 5 – Prenez connaissance de votre politique de sécurité. « J’ai travaillé une fois pour une société qui était en pleine fusion avec un concurrent de taille moyenne. Inutile de dire déjà que les fusions constituent généralement un véritable défi informatique Cette fusion particulière s’est révélée être bien plus casse-tête que la plupart. Pour commencer, bien que les deux sociétés utilisaient des plateformes Microsoft, nous n’utilisions aucun logiciel ou matériel communs. Mais le véritable problème ne venait pas du matériel utilisé. Nous souffrions d’un problème culturel, ce qui a eu des répercussions directes sur l’implémentation d’une politique de sécurité cohérente dans l’ensemble du réseau. Si les directeurs et le personnel commercial s’entendait bien sur le plan culturel, l’équipe informatique était composée de personnes de milieux culturels très différents, qui tenaient des philosophies de sécurité très différentes. Du côté de la nouvelle société partenaire, le personnel informatique provenait en majeure partie de fournisseurs de services réseau et préféraient travailler à partir de systèmes réseaux concoctés à domicile, avec tous leurs défauts. De notre côté, en revanche, nous nous étions plutôt efforcés de travailler en étroite collaboration avec nos partenaires et fournisseurs pour tout ce qui concerne l’assistance technique et les conseils en matière de sécurité. Les problèmes ont commencé à émerger quand nous nous sommes mis à établir les politiques de sécurité de notre réseau. Notre directeur informatique avait pris les rênes du service informatique et souhaitait mettre en place une politique de management de l’accès relativement uniforme. Au cours de l’année qui suivait, au fur et à mesure que nous implémentions cette politique, il devint évident que certains employés du service implémentaient librement des exceptions à court terme, au cas par cas, qui d’une certaine manière finirent par devenir des exceptions à long terme. Notre service s’était largement concentré sur le travail d’intégration des systèmes de management de nos relations clients et de nos bases de données dans notre site Internet public ; en conséquence, les questions de sécurité avaient été laissées de côté. Entre temps, notre effectif s’était amaigri après la fusion, principalement du côté du nouveau partenaire dont le personnel était parti à la recherche d’un environnement moins frénétique. Environ un an après la fusion, un voleur de données s’introduisit dans notre réseau et parvint à usurper des données clients. Les données elles-mêmes ne constituaient pas réellement un danger — noms, numéros de téléphone, pas de numéros de sécurité sociale ou d’informations de cartes de crédit — mais le fait qu’un intrus avait eu accès à notre réseau était de grande importance à nos yeux. Nous avions donc immédiatement décidés de nous pencher sur la sécurité du réseau. Le directeur de l’information passa immédiatement en revue notre politique de sécurité et se rendit compte que la moitié de notre réseau était régie par une mosaïque de règles contradictoires, ce qui avait rendue possible l’intrusion. Il a fallu trois semaines de travail sur le management du changement et la mise à l’essai pour qu’une équipe de cinq employés parviennent à résoudre nos problèmes de sécurité. » Planifiez régulièrement des audits de votre politique de sécurité La sécurité par firewall n’a aucune valeur sans une politique de sécurité cohérente — qui constitue la combinaison des règles et principes sur lesquels repose votre système de sécurité. Si votre firewall renforce cette politique de sécurité, il ne la crée pas. Sa création repose sur vos épaules. Malheureusement, la politique du système de sécurité est souvent mise à l’écart une fois établie et qui évolue en fonction de la modification des règles à court terme au lieu d’évoluer en fonction des besoins de changement de l’organisation ou de l’évolution de l’environnement de sécurité. Au fil du temps, les règles risquent de ne pas être conformes avec la politique de sécurité et les règles inutilisées risquent d’encombrer le trafic et de faire obstacle aux changements nécessaires. Un système de sécurité déphasé peut également présenter un risque juridique, étant donnée la fréquence de modification des exigences règlementaires en matière de protection des données relatives au traitement des données de cartes de crédit, au management de conformité des valeurs mobilières, à la conservation des informations médicales et financières et autres. Il convient de recueillir et d’évaluer régulièrement les données du système de sécurité en vue d’uniformiser les règles d’accès avec le système de sécurité général pour détecter toute infraction à la politique et autres violations. Le calendrier de ces révisions devrait correspondre à la fréquence de modification des règles de sécurité et devrait comprendre une liste des modifications effectuées depuis la dernière révision planifiée, des personnes responsables de ces modifications et de la raison de ces modifications. Vous pouvez par exemple procéder à une révision de votre politique chaque fois que vous: • Installez un firewall ou autre système de sécurité susceptible d’affecter considérablement les capacités de votre réseau • Introduisez de nouvelles applications IP dans le réseau • Changez de fournisseur de service Internet • Commencez à partager votre trafic réseau dû à une collaboration avec un partenaire commercial • Effectuez un changement commercial ou opérationnel important • Effectuez une rotation de personnel important Un système de sécurité réseau efficace fonctionne à partir de différentes couches qui travaillent en collaboration en vue de protéger vos biens. Toute révision de la politique de sécurité doit contrôler que ces différentes couches travaillent dans l’ordre et que le système de sécurité est réglé de manière à accepter le trafic le plus important lorsqu’il est axé vers l’extérieur et le trafic le moins important lorsqu’il est axé vers les données à protéger. Activez le filtrage du port au niveau extérieur du réseau et le filtrage du contenu aussi proche du récepteur que possible. Cette méthode permet de créer des zones de sécurité.
  8. 8. Conclusion Considérés comme une première ligne de défense du réseau, les systèmes de sécurité sont essentiels pour protéger vos biens informatiques contre la corruption et les perturbations. L’évolution des exigences commerciales et de sécurité font du management des firewalls un véritable défi pour une grande partie des sociétés, en particulier celles qui souffrent d’un manque de ressources financières et du personnel nécessaires. Les recommandations énoncées dans le présent document ne constituent pas une liste complète des tâches requises pour assurer le fonctionnement efficace de votre système de sécurité, mais elles constituent des éléments essentiels à un programme de management de la sécurité solide. En respectant ces cinq directives, vous serez à même d’éviter un des scénarios illustrés dans ce document et, en conséquence, votre système de sécurité pourra vous protéger plus efficacement et permettra de réduire les dangers menaçant votre organisation. Dell Inc. (NASDAQ: DELL) est à l’écoute de ses clients et fournit dans le monde entier une technologie innovante et des solutions commerciales qui ont leur confiance et leur appréciation. Reconnu comme un leader de l’industrie par les analystes de renom, Dell SecureWorks offre des services de sécurité de l’information de classe mondiale destinés à aider les entreprises de toutes tailles à protéger leurs biens informatiques, rester conformes aux règlementations et réduire leurs coûts en matière de sécurité. À propos de Dell SecureWorks Si vous souhaitez en savoir plus sur Dell SecureWorks et dans quelle mesure le programme peut aider votre organisation à management plus efficacement vos firewalls, veuillez contacter votre gestionnaire de compte, contactez-nous par courriel à ukenquiry@secureworks.com ou composez le +44 (0) 131-260-3044.

×