À qui appartient le firewall de l’entreprise ? Une approche service d’un sujet faussement simple

22 oct. 2024 - 08:01,

Tribune

- Cédric Cartau

Écouter l'article

0:000:00
Étrange comme accroche : à qui appartient le firewall de l’entreprise ? Ben à l’entreprise, non ? Sur le plan juridique, le FW a été acquis par une entité juridique au terme d’une procédure d’achat, la propriété est donc rattachée à un Siret, fin du sujet. Non ?
a-qui-appartient-le-firewall-de-lentreprise-une-approche-service-dun-sujet-faussement-simple

Non en fait, la question aurait plutôt dû être : à quel service il appartient. Au service achat ? À la DSI (qui ne l’a pas acheté mais qui l’utilise) ? Aux MOA (si l’on filtre des IP et des ports, c’est bien pour répondre à un besoin métier, non ?) ? Là évidemment on ressort le mantra habituel : celui qui exploite possède. La DSI exploite l’équipement, au sens d’en avoir la responsabilité/les compétences techniques, donc le matériel lui est attribué. N’est-ce pas ?

Oui, mais pas assez précis. Quelle équipe de la DSI ? L’équipe réseau ? Souvent le FW est géré par les ingénieurs réseau. Ou l’équipe cyber ? Si l’on filtre après tout, c’est pour des questions de sécurité : s’il n’y avait pas sur le Web des vilains et des méchants tout plein, nul besoin de FW, non ? Là, c’est déjà un peu plus tordu comme tournure de discussion, n’est-ce pas ? Bon, OK, je vous enfume légèrement, l’irruption de la cyber n’a aucune importance dans le débat – on pourrait attribuer le FW à cette équipe moyennant un tour de passe-passe qui n’a pas d’intérêt dans le présent article. Donc l’équipe réseau. C’est bon là, non ?

Non toujours pas. Si vous dites que le FW est la propriété du Réseau, il en administre la configuration interne (paramètres fixes que l’on va considérer comme faisant partie de la boîte, donc le contenant) ainsi que la base des règles de filtrage (donc le contenu). La présence d’un existant est généralement la norme et à chaque changement de FW on balance des moulinettes techniques. Le projet de changement est donc un BUILD qui modifie le contenant et migre le contenu. OK jusque-là. Mais imaginons que vous possédez (enfin je dis « vous », mais c’est plutôt le Réseau) un FW de niveau 4 (filtrage IP/ports) et que vous faites l’acquisition d’une nouvelle génération qui va jusqu’au filtrage de niveau 7 (les applications). Qui diable va se coltiner la revue des n applications métiers qui ont des flux passant par le FW, et pour chacune d’entre elles récupérer les éléments qui permettent de paramétrer le niveau 7 (forcément absent du précédent matos qui s’arrêtait à la couche 4) ? Toujours l’équipe réseau ? Alors là, bon courage pour que ce personnel contacte des fournisseurs qu’il ne connaît pas à propos d’applis qu’il connaît encore moins pour récupérer des éléments forcément liés à un fonctionnel dont il ignore à peu près tout. Dans un CH, on dépasse couramment les 300 règles implémentées, on y sera encore à la saint-glinglin. Si vous dites que le FW est la propriété de l’équipe réseau, il n’y a aucune solution à ce problème. On vient de réaliser ce qu’en math on appelle une démonstration par l’absurde.

On va aller directement à la solution, histoire de ne pas y passer des plombes. En aucune façon l’équipe réseau ne « possède » le FW, en tout cas pas au sens initial de l’article, car le FW est une contingence et rien de plus, de la quincaillerie si vous préférez. L’équipe réseau est propriétaire d’une seule chose : une offre de service (un processus) qui fournit des filtres sur les couches 4 et 7, à destination de ses clients internes (souvent les équipes applicatives, le biomed et les services techniques), point barre. Pour cette offre de service (qui doit être décrite, avec engagements et tout le tralala), l’équipe réseau doit :
- réaliser un projet (BUILD) d’installation du contenant (la boîte et ses paramètres) ;
- en cas de reprise d’un existant, effectuer une action BUILD de transfert des règles de filtrage ;
- assurer le RUN du contenant ;
- attribuer le plus souvent à une autre équipe processus (la MCO) le RUN (exploitation, gestion des incidents, création, modification) du contenu ;
- mettre à disposition de ses clients internes un formulaire de demande de création/modification/suppression de filtres, avec qualification et comparaison avec une doctrine interne de « saine gestion des règles » (mesures 8.20 à 8.23 de l’annexe A de la norme 27001:2022 pour les intimes) – c’est là son véritable cœur de métier ;
- former ses « clients » ;
- réaliser des contrôles en tout genre sur le contenant et le contenu, avec rapports, tickets d’incident, etc.
Dans ce schéma, l’équipe cyber est un sous-traitant du Réseau qui l’aide à définir les règles de gestion du contenant et du contenu, les contrôles, etc.

Ça paraît compliqué, mais en fait c’est beaucoup plus simple : la responsabilité de chaque processus est rendue à ceux qui n’auraient jamais dû l’abandonner. Il faut juste penser différemment. Et si vous trouvez que c’est un peu couper les bits en quatre, sachez que tout – les « clients », les organismes régulateurs, les normes, en particulier la 27001 – porte à voir les interactions de la sorte, et que vous finirez par en être impacté plus vite que vous ne le croyez.


L'auteur

Responsable Sécurité des systèmes d’information et correspondant Informatique et Libertés au CHU de Nantes, Cédric Cartau est également chargé de cours à l’École des hautes études en santé publique (EHESP). On lui doit aussi plusieurs ouvrages spécialisés publiés par les Presses de l’EHESP, dont La Sécurité du système d’information des établissements de santé.

Avez-vous apprécié ce contenu ?

A lire également.

Lettre d'information.

Ne manquez rien de la e-santé et des systèmes d’informations hospitaliers !

Inscrivez-vous à notre lettre d’information hebdomadaire.

Contact

Nos marques

Logo DSIHLogo Thema Radiologie