Risques liés à  la gestion des profils utilisateur

Default Passwords). Avec cette commande, le responsable de la sécurité peut imprimer la liste des utilisateurs dont le mot de passe correspond à leur profil utilisateur. Une récente enquête de sécurité iSeries menée dans mon entreprise sur 181 systèmes différents a constaté que le système moyen a 116 profils utilisateur dans lesquels le mot de passe utilisateur correspond au nom du profil. La plupart des administrateurs l’expliquent par le fait que ces profils ont été créés pour des utilisateurs qui ne se connectaient jamais. Autre raison : les systèmes n’ont aucune date limite d’expiration des mots de passe, et donc ces derniers restent en l’état.

Ne créez jamais un mot de passe identique à son profil utilisateur correspondant, même si le profil utilisateur est d’abord créé avec la commande CRTUSRPRF (Create User Profile). Choisissez plutôt *NONE comme mot de passe initial pour un utilisateur. Cela l’empêche d’accéder au système en dehors d’un mode SSO (single sign-on). Quand l’utilisateur final décide de se connecter pour la première fois (parfois plusieurs mois après), il peut appeler le help desk pour convenir d’un mot de passe initial. Et, de plus, ce dernier peut être *EXPIRED, afin que l’utilisateur soit invité à changer le mot de passe lors du premier sign-on. De sorte que seul l’utilisateur final connaît le mot de passe.

Pas de partage de profil et de mot de passe ! Il ne sert à rien de recueillir des masses d’informations de sécurité si vous ne savez pas qui est à l’origine d’une transaction douteuse. Profils utilisateur inutilisés laissés en sommeil.

Quand un employé quitte l’entreprise ou change de poste ou de lieu de travail, il est fréquent de laisser le profil utilisateur sur le système pendant une période indéfinie.

Avez-vous vérifié récemment vos profils utilisateur ? Sur la plupart des systèmes, je trouve des profils utilisateur inutilisés depuis un an ou plus. L’enquête de sécurité iSeries déjà mentionnée a révélé sur chaque système une moyenne de 205 profils utilisateur qui avaient été laissés inutilisés pendant 90 jours ou plus. 141 d’entre eux étaient encore parfaitement utilisables. Pour dresser la liste des profils utilisateur en sommeil sur votre système, vous pouvez utiliser la commande ANZPRFACT (Analyze Profile Activity) et indiquer un nombre de jours. Cependant, avant de lancer cette commande, vous devez savoir exactement ce qu’elle accomplit. En effet, elle peut désactiver des profils douteux, même si ce n’est pas ce que vous souhaitez. Lisez en détail le texte d’aide de la commande par une invite (c’est-à-dire, entrez ANZPRFACT) et en appuyant sur F1=Aide. Sachez aussi que certains FAI (fournisseurs d’accès à Internet) ne mettent pas à jour les données d’utilisation des profils utilisateur iSeries, et donc le contenu du rapport peut être trompeur. Lorsque vous mettez au net ces anciens profils, faites preuve de bon sens.

Autorités spéciales excessives attribuées aux profils utilisateur. Je rabâche cela depuis des années. Pourquoi Pierre sur le quai de chargement doit-il contrôler les jobs interactifs et batch de Paul au service de la paie ? Il n’y a aucune raison ! Mais alors pourquoi avons-nous donné à Pierre l’autorité spéciale *JOBCTL (Job Control) ? Laquelle permet à un utilisateur de contrôler les jobs de tout autre utilisateur du système. Et aussi d’arrêter les sous-systèmes, voire de mettre le système hors tension si une autorité suffisante accompagne la commande PWRDWNSYS (Power Down System).

La plupart des profils utilisateur sont créés avec au moins les autorités spéciales *JOBCTL et *SPLCTL (Spool Control). Beaucoup sont aussi créés avec l’autorité spéciale *SECADM (Security Administrator). Voyons rapidement ce qu’accomplit chacune de ces autorités spéciales.

• ALLOBJ – Lire, modifier et supprimer tout objet sur le système
• AUDIT – Manipuler les valeurs d’audit du système
• IOSYSCFG – Créer et modifier les communications système
• JOBCTL – Contrôler les jobs des autres utilisateurs et ENDSBS (End Subsystem)
• SAVRST – Sauvegarder, restaurer et supprimer n’importe quel objet sur le système
• SECADM – Changer tous les profils et mots de passe
• SERVICE – Utiliser les outils de service système
• CPLCTL – Visualiser et contrôler tout rapport sur le système

Réfléchissez donc à votre rapport le plus sensible. Ce peut être le chiffre des ventes trimestrielles, les ventes par client, la paie, le tarif, ou l’information sur les patients et les diagnostics médiaux. Tout utilisateur disposant de l’autorité spéciale *SPLCTL peut consulter et même transférer ce rapport dans un fichier texte PC : il dispose pour cela de divers outils poste de travail.

D’après l’enquête sur la sécurité iSeries, toujours sur le système moyen, 133 utilisateurs ont l’autorité spéciale *JOBCTL, 104 ont l’autorité spéciale *SPLCTL et, de façon tout à fait absurde, 65 ont l’autorité spéciale *ALLOBJ (All Object), qui leur donne tout simplement le contrôle total du système et la possibilité de faire n’importe quoi !

Ces autorités spéciales mal attribuées violent clairement la séparation des tâches et des responsabilités en matière de contrôle d’accès et de secret des données. Par le passé, beaucoup d’auditeurs ne comprenaient pas les autorités spéciales iSeries ou le non-respect de la séparation des tâches que les autorités spéciales permettent. Ils sont en train d’apprendre.

Règles en matière de création et d’expiration de mots de passe sans restriction. L’OS/400 et l’i5/OS offrent de nombreux moyens pour réguler la composition des mots de passe. On peut, par exemple, en préciser la longueur minimale et maximale. Et aussi spécifier qu’un mot de passe doit contenir au moins un chiffre, ou restreindre les lettres permises. Il existe bien d’autres possibilités, comme celle d’écrire votre propre programme de contrôle de validité des mots de passe. Les valeurs système QPWD* contrôlent ces options.

A mon avis, les mots de passe devraient toujours inclure un chiffre pour les rendre plus difficiles à deviner. Ils devraient aussi expirer à intervalles réguliers, sans dépasser 90 jours. Ils ne devraient pas être réutilisables pendant deux ans au moins. Des mots de passe efficaces devraient être faciles à mémoriser mais durs à deviner. Dans la pratique, comme les gens doivent en mémoriser beaucoup, ils tendent à créer des mots de passe faciles à deviner, comme le nom d’un animal domestique, d’un enfant, d’un conjoint ou d’une équipe sportive favorite (ai-je deviné le vôtre ?). Qui plus est, pour se faciliter la tâche, les utilisateurs écrivent les mots de passe quelque part, nuisant ainsi à leur sécurité.

L’authentification est la clé de tout stratégie de sécurité. Si quelqu’un peut s’authentifier vis-à-vis d’un système en se faisant passer pour quelqu’un d’autre, donc en usurpant les autorités de ce dernier, les autres pratiques de sécurité pèsent bien peu. De faibles mots de passe peuvent laisser un utilisateur interne ou externe usurper l’identité d’un autre utilisateur, avec deux graves conséquences : violation de la séparation des tâches, mais surtout accomplissement d’autres actes déstabilisants ou illégaux, comme le vol des secrets de l’entreprise ou la fraude pure et simple.

Tout ce qui aide à réduire le nombre de mots de passe de vos utilisateurs contribuera beaucoup à sécuriser leurs mots de passe restants. SSO impose également des règles de formation de mot de passe plus strictes.

Comme il est plus facile de se souvenir de deux mots de passe que de 22, SSO peut aussi réduire sensiblement le nombre d’appels pour réinitialisation de mots de passe, reçus par votre help desk.

COBIT stipule que la direction doit réexaminer périodiquement les comptes utilisateur. En voici un fragment :

COBIT DS5.5 Management Review of User Accounts Management should have a control process in place to review and confirm access rights periodically. Periodic comparison of resources with recorded accountability should be made to help reduce the risk of errors, fraud, misuse, or unauthorized alteration.

(COBIT DS5.5: Réexamen des comptes utilisateur par la direction La direction doit instaurer un processus de contrôle permettant d’examiner et de confirmer les droits d’accès périodiquement.
Il faut comparer périodiquement les ressources avec la responsabilité enregistrée pour réduire le risque d’erreurs, de fraude, d’emploi abusif ou d’altération non autorisée.) Profils utilisateur incorrectement sécurisés. Quand un profil utilisateur est créé pour la première fois, son autorité attribuée – *PUBLIC AUT(*EXCLUDE) – interdit aux autres utilisateurs d’utiliser le profil sans connaître son mot de passe. C’est le cas classique. Cependant, il est possible de remplacer le niveau d’autorité par quelque chose de plus permissif, du genre *PUBLIC AUT(*USE) ou *PUBLIC AUT(*CHANGE).

Bien que ce problème soit généralement créé en interne, je le rencontre souvent quand j’examine les profils utilisateur procurés par le fournisseur. Pendant l’installation, les profils utilisateur procurés par le fournisseur avec l’assentiment du responsable de la sécurité système, sont créés. Les autorités spéciales du genre *ALLOBJ, *SECADM et *IOSYSCFG sont inhérentes à ces profils. Le principal problème qu’ils posent n’est généralement pas dû aux autorités spéciales puissantes qui leur sont associées mais plutôt au fait que l’autorité publique (*PUBLIC) sur ces profils est *USE ou *CHANGE au lieu de *EXCLUDE. En effet, cela permet à n’importe quel utilisateur de votre système de devenir le responsable de la sécurité : il lui suffit de savoir comment.

Un utilisateur peut facilement exploiter la faille par une simple commande SBMJOB (Submit Batch Job) assortie du paramètre USER, comme dans l’exemple suivant :

SBMJOB CMD(CPYF FROMFILE(PAYROLL))
TOFILE(*PRINT)
USER(Vendor-User-Profile)

Cette commande affiche ou imprime votre fichier de paie ! La commande exécutée (CMD) peut être n’importe laquelle, même si l’utilisateur qui exécute la commande SBMJOB ne dispose pas de l’autorité suffisante. En effet, un profil utilisateur mal sécurisé permet au premier venu de s’approprier les puissantes autorités du profil.

Utilisez la commande PRTPVTAUT (Print Private Authority) pour vérifier périodiquement les autorités de vos profils utilisateur. Si vous trouvez des profils non sécurisés, le remède consiste à donner au profil la valeur *PUBLIC AUT(*EXCLUDE). Si c’est un profil qui vient du fournisseur, demandez lui s’il accepte et supporte ce changement.
Des profils utilisateur non sécurisés permettent de transgresser les principaux préceptes de votre stratégie de sécurité et ils peuvent constituer la faille la plus dangereuse. De plus, si les profils viennent du fournisseur, il est bien plus probable que la faille soit connue.
Contrôler les utilisateurs puissants. J’ai souvent constaté que beaucoup de responsables de la sécurité et administrateurs système changent des paramètres système quand bon leur semble, sans examen ni concertation. Les programmeurs d’applications se connectent couramment à des systèmes de production pour examiner et corriger des problèmes et, dans certains cas, hélas, pour jeter un oeil sur des données de gestion et des données personnelles. A tel point d’ailleurs que certains énergumènes se vantent de pouvoir accéder à des données sensibles ou personnelles.
Toujours d’après l’enquête sur la sécurité iSeries, une installation iSeries moyenne a 65 utilisateurs avec l’autorité spéciale *ALLOBJ. Pour les équipes et auditeurs de sécurité, un tel abus est une grave déficience du contrôle.
Les utilisateurs techniques qui possèdent des privilèges sur des systèmes de production doivent toujours faire l’objet d’un audit et d’un contrôle. Pour assurer la séparation des tâches, toutes les actions qu’un utilisateur technique effectue sur le système de production doivent être enregistrées dans un journal d’audit sécurisé et doivent y être auditées. Quand un technicien doit corriger un problème de production à 3 heures du matin et remettre d’aplomb un fichier de données de production ou recompiler un programme, il doit le faire sous le contrôle d’un système d’audit. Toutes les actions effectuées doivent être visibles.

IBM a prévu l’audit des événements initiés par l’utilisateur. Des produits tiers facilitent la présentation d’un grand nombre d’enregistrements d’audit et permettent même de contrôler et de superviser toutes les activités menées par des utilisateurs sur un système de production. Votre auditeur exigera que vous contrôliez et auditiez les activités des utilisateurs puissants sur les systèmes de production. Vous seriez bien inspirés de profiter des riches fonctions d’audit incluses dans le système d’exploitation.