Cinq règles essentielles au management des fi rewalls: 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. 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éfinissezclairementvotreplandemanagementduchangement. 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’essailesprincipalesmodificationsdevosfirewallsavantdevousmettreenligne.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-vousenprenantuninstantanédelaconfigurationdevotrefirewallavantdeprocéderàtoutemodificationmajeure.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ôlezledroitd’accèsdesutilisateursàlaconfigurationdufirewall.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évoyezdesauditsdepolitiqueré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.

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. »

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.

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.

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.

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é.

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.