1. Police de sécurité

Pour pouvoir sécuriser un système d'information, il convient d'en analyser les points importants, d'en identifier les failles potentielles, et de mesurer le risque induit par ces failles potentielles, et donc d'en tirer un police définissant comment les procédure doivent se dérouler, de manière à ne pas compromettre la sécurité de ce système.


L'identification des points importants peut se faire en dressant une liste, en les divisant en deux classes, d'un côté les éléments tangibles (ordinateurs, données, données sauvegardées, données personnelles) et d'un autres, les éléments intangibles (vie privée des employés, mots de passes, disponibilité du système d'information, informations de configuration, réputation de la société et image publique).


La détermination des dangers potentiels se fait en examinant chaque point important de la liste précédemment établie, et en déterminant les risques induits. Il ne faut pas avoir peur d'être trop large, et vraiment trouver tout ce qui peut représenter un risque. Par exemple, maladie d'employés clés, éclair tombant sur le bâtiment, défaillance d'un disque dur, introduction d'un virus, interception de données financières entre la société et la banque, bogues dans les logiciels, vol physique d'une cassette de sauvegarde, employés corrompus ou mal intentionnés, faillite et cessation d'activité d'un fournisseur, entrée d'un pirate dans le système d'information. On définit ce qu'on appelle un périmètre de sécurité, incluant tous les éléments devant rentrer dans la police de sécurité de ce système d'information.


La mesure du risque induit peut se faire, entre autres manières, en évaluant le coût de chaque défaillance potentielle (financièrement, durée de l'indisponibilité), et sa probabilité. Cette dernière est très dure à déterminer, mais certaines société d'assurance dispose de telle liste, détaillant ces éléments.


Enfin, un dernier éléments à calculer est le coût de prévention de chaque risque déterminé à la deuxième étape (coupure de courant -> coût financier d'un onduleur, bogue d'un logiciel -> temps passé à le déboguer....), ainsi que sa durée de vie éventuelle, ou du moins une estimation pour un élément logiciel.


On peut alors former un tableau, et multiplier le risque qu'une défaillance arrive par le coût de cette défaillance, et éventuellement le comparer avec le coût de la solution préventive.


L'analyse des risques n'est vraiment pas évidente mais permet de mettre clairement le doigt sur les éléments primordiaux du système d'information, et donc de voir sur quels éléments se focaliser.


Il est alors possible d'établir une liste de polices de sécurité, chaque règle devant spécifier ce qui est protégé, pourquoi ça l'est, qui est responsable de cet élément. On peut partir d'un principe simple, comme les deux philosophies bien connues : « Tout ce qui n'est pas autorisé est interdit » et « Tout ce qui n est pas interdit est autorisé », bien que je recommanderais à titre personnel de ne jamais choisir la première.


Il faut bien sûr appliquer cette police, et en surveiller l'application, de manière stricte, en procédant à des audits réguliers, pour voir si une personne de par un comportement dilettante ne fait pas prendre de risque aux systèmes. Ce point soulève la formation des utilisateurs à cette politique de sécurité, élément indispensable à fin que chaque collaborateur acte dans le même et bon sens en matière de sécurité.


Note : L'appel à un intervenant extérieur peut être utile, car il apporte une vue objective, tandis qu'un administrateur système ou un ingénieur aura une vue orientée de manière assez systématique sur la sécurité dans son réseau.


La sécurité à travers l'obscurité est une méthode consistant à cacher les mécanismes internes d'un système. Ce procédé est utilisé entre autres par beaucoup d'éditeurs de logiciels produisant du code propriétaire. Une philosophie de base du monde des logiciels libres est de ne rien cacher, le code se trouvant à disposition de tout à chacun de toutes façons. En matière de sécurité des système, ce type de procédé est tout aussi préjudiciable, car ce n'est pas en cachant un service défaillant que personne ne le découvrira jamais. De plus, cette philosophie de la transparence oblige à documenter tous les mécanismes présent dans un parc de machines, et donc de maîtriser ce dernier, ce qui offre un avantage certain en matière de sécurité.


Enfin, on pourra rajouter de manière inconditionnelle effectuer une veille technologique systématique sur les éléments de la distribution Gnu/Linux que l'on choisit, et mettre à jour les logiciels ou bibliothèques inconditionnellement en cas de découverte d'une faille de sécurité.


Note : Certains sites publient régulièrement les listes de vulnérabilités découvertes, comme http://www.secunia.com par exemple. LinuxFR peut également s'avérer une bonne source concernant les alertes de sécurité mais aussi l'actualité des logiciels libres.



Introduction
Sommaire
2. Utilisateurs, mots de passes, et authentification