Faut-il investir dans la sécurité du SI ?

La sécurité est à l'ordre du jour dans de nombreuses entreprises. L'affaire Kerviel a mis à mal la sécurité du système d'information de la Générale, mais ses consoeurs savent qu'elles encourent le même risque car leurs systèmes ont les mêmes attributs....

Revenons sur deux d'entre eux. Le premier concerne la gestion des utilisateurs, c'est-à-dire les multiples login/mot de passe que vous tapez chaque jour si vous êtes utilisateur de plusieurs applications. Tout nos SI ont aujourd'hui en commun ce problème d'avoir multiplié le nombre d'annuaires, chaque application - développement spécifique ou progiciel - s'évertuant à recopier ces données d'identification. Des efforts d'intégration ont été entrepris et ont permis de répliquer cette information à peu près automatiquement dans tous ces annuaires. En revanche, l'opération inverse, c'est-à-dire la suppression des utilisateurs et de leurs privilèges après leur mutation ou leur départ, a été faiblement automatisée. Au final le système est de plus en plus désynchronisé avec le temps, nul ne voulant prendre la responsabilité de supprimer des accès qui pourraient susciter l'ire d'un collaborateur légitimement " à cheval sur deux postes pendant huit mois " ou " offrant ponctuellement son aide à son successeur "...mais aussi un accès à celui qui " utilise ces anciennes fonctions dans le contrôle pour dissimuler ces opérations dans son poste de vendeur ". L'interface de suppression des droits est difficilement automatisable, elle cause l'entropie des annuaires, notre premier trait.

Notre second trait concerne la philosophie même selon laquelle ont été bâtis les programmes de sécurité, qui ouvrent ou pas l'accès à des informations, en lecture, ou en écriture. Tous les SI des grandes entreprises obéissent à la même philosophie : tout ce qui n'est pas expressément autorisé est interdit. On vous fournira des autorisations selon vos fonctions dans l'entreprise. Du bon sens ? Dans les faits cette politique conduit à empiler les autorisations avec le temps, chaque utilisateur ayant de plus en plus de droits au fil de sa carrière et de ses différents postes. Elle conduit également à construire des systèmes complexes d'autorisations hiérarchiques ou matricielles comme " vous pouvez faire des opérations sur ces comptes, du département de l'Isère, mais vous pouvez consulter tous les comptes de la région Rhône-Alpes ". Au-delà d'être chronophage en développement informatique et en gestion quotidienne, cette micro-segmentation amplifie les risques. Il devient difficile voire impossible de garantir une quelconque interdiction, puisque rien ne garantit qu'une autorisation au fin fond d'une pile ne vous ouvre l'accès, et il faut avoir épluché la pile pour en être sûr !

Certains systèmes, par exemple Wikipedia pour le plus connu, ont opté pour une politique inverse, paradoxalement beaucoup plus efficace : tout ce qui n'est pas expressément interdit est autorisé, mais tracé. On positionnera des interdictions dans les zones sensibles. Une telle politique permet un énorme gain en simplicité - caractéristique nécessaire à la sécurité - et permet une bien meilleure maîtrise des risques, car elle garantit les interdictions, sans éplucher une pile d'informations, mais en lisant une seule ligne. Dans notre exemple nous aurions eu cette interdiction dans l'application back-office : l'accès est interdit à tout opérateur du front-office.

Enfin, une exploitation judicieuse des traces avec des outils modernes de data mining, permet de détecter des comportements suspects, comme " s'est loggué tous les jours ouvrés sans interruption pendant plus de six mois, donc sans prendre de vacances, donc en ne déléguant jamais ses positions à ses collègues ". Ces formes que les moteurs de data mining vont reconnaître représentent l'expérience accumulée en gestion des risques par l'entreprise. Celle que je cite était connue avant l'affaire.

Vous êtes un praticien de la sécurité de systèmes d'information, vous adhérez à cette vision, OCTO recrute.