blue padlock graphic
Guide

Étude 2020 sur l’état de la sécurité d’IBM i

 
Partout dans le monde, les entreprises commencent à se rendre compte de l’impact économique des politiques laxistes en cybersécurité, des temps d’arrêt imprévus, des pertes de productivité, des ressources bloquées dans des poursuites judiciaires et des notifications de violation de la sécurité.
Sans surprise, 77 % des professionnels IBM i citent la cybersécurité comme leur principale inquiétude.
La 17e (et dernière) édition de l’Étude sur l’état de la sécurité d’IBM i comporte des données concrètes et impartiales sur la façon dont les systèmes IBM i sont protégés, mais aussi sur les insuffisances qui subsistent.

RÉSUMÉ ANALYTIQUE

RÉSUMÉ ANALYTIQUE

Dans sa 17e édition, l’étude fournit des éléments probants sur la posture de sécurité de 255 serveurs et partitions IBM i — des systèmes souvent utilisés pour des données métiers critiques, des données de carte de paiement et des données personnelles.

Cette étude, bien que ne portant pas sur les mêmes systèmes d’une année à l’autre, identifie cependant des tendances générales. La cybersécurité occupe une place croissante au sein des organisations participantes et, ces dernières années, les entreprises ont progressivement amélioré la situation concernant la sécurité de base des systèmes et le contrôle des mots de passe. Toutefois, bon nombre d’organisations sont encore dans les premières phases de mise en oeuvre de contrôles de sécurité d’IBM i.

LES DONNÉES DE SEPT DOMAINES STRATÉGIQUES DE LA SÉCURITÉ D’IBM i (RÉSUMÉES CI-DESSOUS) RÉVÈLENT L’AMPLEUR DU RISQUE:

Niveaux de sécurité de base des systèmes

75 % des systèmes suivent des meilleures pratiques de sécurité globale des systèmes.

Utilisateurs dotés de droits élevés

Une écrasante majorité des serveurs IBM i étudiés ici comptent un trop grand nombre de profils dotés de droits élevés. Cela peut entraîner la perte, le vol ou l’altération des données. La recherche de droits spéciaux excessifs fait partie de la mission des auditeurs dans le cadre d’un audit IBM i standard.

Sécurité des mots de passe et des profils

Dans 27 % des systèmes étudiés, les cas où le mot de passe est identique au nom d’utilisateur concernent plus de 100 profils utilisateur.

Accès aux données

La quasi-totalité des utilisateurs système ont accès à beaucoup plus de données que nécessaire.

Accès réseau

Le contrôle et l’audit de l’accès réseau étant inexistants dans la plupart des entreprises dotées d’IBM i, des accès autorisés et non autorisés ont lieu sans aucune traçabilité. Bien que la technologie de point d’exit d’IBM i permette de contrôler et de surveiller l’accès aux données du réseau, ses taux d’adoption restent faibles.

Détection des violations de la sécurité

La plupart des systèmes sont dépourvus d’une stratégie efficace de surveillance et d’interprétation des données d’événements de sécurité, permettant aux infractions de passer inaperçues.

Protection anti-malware

Si le nombre de serveurs IBM i analysant la présence de malware et de virus a augmenté ces dernières années, 86 % d’entre eux présentent encore un risque de propagation de programmes malveillant par le biais de leur réseau.

À PROPOS DE CETTE ÉTUDE

À PROPOS DE CETTE ÉTUDE

Tendances de la sécurité d’IBM i

Les cybermenaces gagnent en complexité d’une année à l’autre, soulignant l’importance de contrôles de sécurité adaptés. L’Étude 2020 sur l’état de la sécurité d’IBM i prouve que de nombreuses organisations se basent sur des paramètres système qui laissent leurs données vulnérables.

Ces dernières années cependant, HelpSystems a observé une tendance encourageante: pour les organisations de toutes tailles, la sécurité d’IBM i devient une priorité croissante.

Une analyse approfondie des risques et des contrôles de sécurité intégrés au système d’exploitation suscite actuellement une vague d’intérêt afin que les problèmes de cybersécurité d’IBM i deviennent des enjeux prioritaires.

Pourquoi cette étude est importante pour vous

La 17e Étude annuelle sur l’état de la sécurité d’IBM i vise à vous aider à comprendre les failles de sécurité courantes d’IBM i, mais aussi comment les corriger rapidement et efficacement.

Votre serveur IBM i exécute probablement des applications de gestion critiques pour votre activité.

Cependant, les plates-formes Windows et UNIX étant généralement plus gourmandes en ressources, il serait tentant de reléguer les projets de sécurité d’IBM i au second plan.L’administration des contrôles de sécurité d’IBM i est ainsi devenue obsolète — alors même que les menaces sur votre système se multiplient.

Les points faibles identifiés via nos analyses et documentées dans cette étude sont dus à des configurations insuffisantes ou manquantes, qui peuvent — et doivent — être corrigées.

Cette étude vous montre les failles de sécurité d’IBM i les plus courantes et dangereuses, tout en fournissant des suggestions d’amélioration.

Méthodologie

Les données de cette étude ont été collectées par les experts en sécurité de HelpSystems, chargés d’auditer des systèmes IBM i à l’aide de notre Security Scan. Ce logiciel gratuit s’exécute directement sur n’importe quel PC relié au réseau (sans modification des paramètres système) et analyse les serveurs Power Systems exécutant IBM i (System i, iSeries, AS/400) dans sept domaines d’audit stratégiques:

  • Contrôles de sécurité de niveau serveur
  • Paramètres des profils et des mots de passe
  • Fonctionnalités d’administration
  • Commandes émises par le réseau et accès aux données
  • Accessibilité du public aux données d’entreprise
  • Audit des événements du système
  • Analyse antivirus

Le système moyen analysé durant cette étude compte 1 075 utilisateurs et 557 bibliothèques. La majorité des serveurs analysés s’exécutaient sur des versions prises en charge du système d’exploitation; toutefois, 12 % d’entre eux s’exécutaient sur V7.1, dont la prise en charge par IBM a cessé en avril 2018.

SÉCURITÉ DE BASE DU SYSTÈME: NIVEAUX QSECURITY

SÉCURITÉ DE BASE DU SYSTÈME: NIVEAUX QSECURITY

Les meilleures pratiques de sécurité d’IBM i commencent par la configuration de nombreuses valeurs système qui établissent la difficulté ou facilité avec laquelle un individu peut utiliser votre système à des fins légitimes ou malveillantes. Des valeurs système mal configurées ou non surveillées constituent un risque de sécurité inacceptable.

Niveau QSECURITY

Bien que le niveau de sécurité du système (QSECURITY) donne le ton général, il est souvent mis en difficulté par d’autres paramètres. IBM recommande et fournit un niveau de sécurité minimal de 40, étant donné que des vulnérabilités documentées ont été détectées jusqu’au niveau 30. Il convient de noter que malgré le changement du paramètre par défaut, une migration de serveur chargera de nouveau la valeur détectée sur la génération précédente du serveur.

La Figure 1 illustre la répartition des paramètres de sécurité sur les systèmes inclus dans les données 2020. Sur les 255 systèmes étudiés, 18 % s’exécutaient à un niveau de sécurité système de 30, tandis que 7 % s’exécutaient à un niveau de sécurité de 20. Au total, 25% des serveurs étudiés ne répondaient pas au niveau minimal recommandé par IBM (Figure 1A). Pour bon nombre de ces entreprises, cette non-conformité était involontaire et était apparue après une migration de leurs valeurs système depuis un ancien serveur. Par ailleurs, ces entreprises reconnaissaient désormais la nécessité de mener des actions correctives.

CONSEIL

CONSEIL

Élevez votre système à un niveau QSECURITY de 40 minimum. En confiant cette tâche à des professionnels de la sécurité d’IBM i comme ceux de l’équipe HelpSystems, vous éliminerez rapidement toute conjecture liée à ce processus.

SÉCURITÉ DE BASE DU SYSTÈME: VALEURS CLÉS DE LA RESTAURATION D’OBJETS

SÉCURITÉ DE BASE DU SYSTÈME: VALEURS CLÉS DE LA RESTAURATION D’OBJETS

Un certain nombre d’autres valeurs système liées à la restauration d’objets restent souvent à leurs niveaux par défaut, reflétant une configuration IBM i « prête à l’emploi ». 

Les valeurs système concernées sont conçues pour fonctionner ensemble et agir tel un filtre, empêchant la restauration d’objets malveillants ou falsifiés. Les valeurs par défaut d’IBM i ne permettent cependant pas cette protection, ce qui laisse le système vulnérable.

Les valeurs système ci-dessous s’exécutent de manière successive afin de déterminer si un objet doit être restauré ou est converti lors de la restauration:
 

  • Vérification de l’objet à la restauration (QVFYOBJRST): plus de 60% des serveurs s’exécutent en dessous du niveau 3 recommandé. Cette valeur (prédéfinie sur le niveau 1) contrôle si une signature sera validée lorsqu’un objet signé numériquement est restauré.
  • Forçage de la conversion lors de la restauration (QVFYOBJRST): 96% des serveurs s’exécutent en dessous du niveau 3 recommandé.
    Cette valeur (valeur par défaut : niveau 1) contrôle si certains types d’objet sont convertis lors d’une restauration.

  • Permission de restauration d’objet (QALWOBJRST): seulement 8 % des serveurs avaient modifié cette valeur système par rapport à son réglage par défaut *ALL. Cette valeur contrôle si des programmes dotés de certains attributs de sécurité, comme l’état du système et l’adoption du droit, peuvent être restaurés.

CONSEIL

CONSEIL

Une approche proactive des valeurs système commence par la définition et le déploiement d’une politique de sécurité intégrant les paramètres les plus sécurisés que votre environnement pourra tolérer. (En cas de doute sur l’impact de certains paramètres, demandez conseil à un professionnel.). Gratuite et open source, la norme de sécurité IBM i proposée par HelpSystems vous aide à définir votre propre politique.

UTILISATEURS DOTÉS DE DROITS ÉLEVÉS

UTILISATEURS DOTÉS DE DROITS ÉLEVÉS

Les professionnels informatiques exigent souvent des droits spéciaux pour pouvoir gérer les serveurs. Ces droits peuvent également permettre la consultation/modification des applications financières, des données de carte de crédit des clients, ou encore des fiches d’employés confidentielles. Un utilisateur doté de droits spéciaux peut provoquer de graves dommages en cas d’approche imprudente, malavisée ou malveillante.

Les droits spéciaux IBM i étant des privilèges administratifs et représentant toujours un risque pour la sécurité, les auditeurs vous demandent de limiter les utilisateurs dotés de tels droits, mais aussi de surveiller et d’auditer attentivement l’utilisation de ces mêmes droits. Parmi ces droits spéciaux, *ALLOBJ est celui fournissant aux utilisateurs une capacité illimitée d’affichage, de modification et de suppression de tous les fichiers et programmes sur le système — on parle parfois de droit « root ». Comme l’illustre la Figure 2, ce droit est accordé à un nombre anormalement élevé d’utilisateurs.

Parmi les systèmes étudiés, seuls trois d’entre eux comptent dix utilisateurs ou moins dotés du droit *ALLOBJ. Les droits spéciaux les plus fréquemment accordés étaient le contrôle des travaux (*JOBCTL) et le contrôle du spoule (*SPLCTL), octroyés à environ 30% des utilisateurs. Le contrôle des travaux permet de changer la priorité des travaux et des impressions, voire, dans certains cas, de mettre fin à des sous-systèmes. Le contrôle du spoule fournit aux utilisateurs un accès complet à tout fichier spoule situé dans la file d’attente de sortie, quelles que soient les restrictions imposées en matière de spoule.

CONSEIL

PRO TIP

Faites en sorte que le nombre d’utilisateurs dotés de droits spéciaux reste inférieur à dix ou représente moins de 3 % de la communauté d’utilisateurs. Nous vous recommandons de travailler avec un expert en sécurité IBM i, qui pourra vous aider à déterminer si des droits sont
nécessaires, et vous suggérer des alternatives dans des cas limites.

Voici certaines meilleures pratiques destinées aux utilisateurs puissants :

  • Documenter et appliquer la séparation des fonctions pour les utilisateurs privilégiés.
  • Éviter à tout moment la présence d’utilisateurs privilégiés.
  • Surveiller, consigner et rapporter l’utilisation de droits élevés.
  • Être prêt à justifier l’utilisation de droits élevés auprès des auditeurs et des responsables.

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS: PROFILS INACTIFS

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS: PROFILS INACTIFS

Les profils inactifs sont des profils utilisateur inutilisés au cours des 30 derniers jours ou plus. Ces profils créent une faille de sécurité car leurs comptes correspondants ne sont pas activement maintenus par leurs utilisateurs, ce qui en fait des cibles privilégiées des pirates.

Bon nombre de ces profils inactifs appartiennent à d’anciens employés ou sous-traitants — des individus qui peuvent rester rancuniers ou utiliser les données de leur ex-employeur au profit de leur nouveau poste chez la concurrence.

La menace persiste même si les ex-employés ne tentent jamais d’utiliser ces profils. D’autres utilisateurs au sein de l’organisation peuvent, par exemple, être informés que le profil de l’ancien directeur informatique existe toujours dans le système. Qu’un profil inactif soit exploité par un ex-employé, un initié malveillant ou un pirate, une utilisation inhabituelle de ce profil ne sera ni détectée, ni signalée par son propriétaire.

La Figure 3 montre qu’aucune connexion n’a été effectuée durant les 30 derniers jours ou plus sur 400 profils (37 % du total) en moyenne. Parmi
ces 400 profils, 194 sont toujours actifs et prêts à être utilisés.

CONSEIL

CONSEIL

Développez un processus pour ces profils inactifs. Commencez par définir le délai d’inactivité d’un profil (par ex. 60 jours) au bout duquel une
action sera menée, les profils inactifs désactivés, puis tous les droits spéciaux et attributions de profil de groupe supprimés. Attendez
30 jours supplémentaires pour vous assurer que le profil est réellement inactif avant de le supprimer du système, ou jusqu’à ce que le nom
de l’utilisateur ne soit plus demandé en vue du rapprochement avec la piste d’audit.

Ce processus peut être manuel ou automatique, à l’aide des outils de sécurité intégrés d’IBM.

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS: MOTS DE PASSE PAR DÉFAUT

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS: MOTS DE PASSE PAR DÉFAUT

Sur les profils IBM i dotés d’un mot de passe par défaut, ce dernier est identique au nom d’utilisateur. Des pirates — et même vos propres employés — peuvent deviner les noms de profil (par ex. jmartin) et essayer des mots de passe par défaut.

Les normes réglementaires et législatives imposent généralement à l’utilisateur l’usage d’identifiants connus de lui seul, afin que toute action puisse être associée à cet individu précis. Les organisations peuvent éprouver des difficultés à sanctionner les activités illégales ou non autorisées s’il s’avère que les identifiants ne permettent pas d’identifier le coupable.

Dans cette étude, près de 11 % des profils utilisateur possèdent des mots de passe par défaut (Figure 4), tandis que 58% des systèmes étudiés comptent plus de 30 profils utilisateur avec des mots de passe par défaut. Pire : 27% des systèmes comptent plus de 100 utilisateurs avec des mots de passe par défaut ! On a même constaté dans un système l’existence de 2 184 profils utilisateur (dont plus de 2.000 actifs) avec des mots de passe par défaut.

CONSEIL

CONSEIL

Établissez et appliquez des politiques de mot de passe fort. La valeur système QPWDRULES peut interdire les mots de passe par défaut. Il convient cependant d’accorder une attention particulière aux applications ou aux logiciels de fournisseurs qui créent des profils lors de l’installation.

Les outils de reporting tels que Powertech Compliance Monitor for IBM i facilite la génération de rapports d’audit réguliers, qui comparent les informations de nom d’utilisateur et de mot de passe IBM i à la politique mise en place.

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS: LONGUEUR DES MOTS DE PASSE

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS: LONGUEUR DES MOTS DE PASSE

Les mots de passe courts sont plus faciles à retenir, mais sont également plus faciles à deviner par des tiers. S’il est possible de renforcer des mots de passe courts avec des caractères aléatoires, les chances de deviner un mot de passe de quatre caractères restent plus élevées qu’avec un mot de passe plus long.

Le NIST recommande désormais d’utiliser des mots de passe à huit caractères — soit deux caractères de plus que sa recommandation précédente.

La Figure 5 détaille le paramétrage de la longueur minimale du mot de passe sur les systèmes passés en revue. Nos résultats montrent que près de 30 % de ces systèmes satisfont ou dépassent la meilleure pratique de huit caractères ou plus. 60 % des serveurs dans cette étude échouent à satisfaire la norme PCI de mots de passe à sept caractères. Chose surprenante, 15 % des serveurs autorisent les utilisateurs à choisir un mot de passe de moins de cinq caractères, tandis que 12 serveurs permettent l’utilisation de mots de passe à un seul caractère.

CONSEIL

CONSEIL

Établissez une politique de mots de passe demandant aux utilisateurs de créer des mots de passe de huit caractères ou plus. Envisagez le remplacement des mots de passe par des phrases secrètes, lesquelles comptent généralement de 20 à 30 caractères et rendent impossibles les attaques par force brute.

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS: AUTRES PARAMÈTRES DES MOTS DE PASSE

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS: AUTRES PARAMÈTRES DES MOTS DE PASSE

IBM i autorise les administrateurs système à définir des mots de passe à un niveau granulaire. Les paramètres des mots de passe comprennent :
longueur, restrictions de caractères, exigences relatives aux chiffres, délai d’expiration, délai de réutilisation d’un mot de passe.

Ces paramètres contribuent à rendre les mots de passe difficiles à deviner et accroissent la protection de votre système — les mots de passe
simples et faciles à deviner de type « 123456 » et « motdepasse » étant malheureusement monnaie courante. Imaginez les conséquences si vos utilisateurs dotés de mots de passe simples disposaient de droits spéciaux ou pouvaient accéder à des données sensibles…

Selon les données les plus récentes, les administrateurs IBM i n’utilisent pas tous les contrôles de mot de passe mis à leur disposition :

  • 52% des systèmes n’imposent pas l’ajout d’un chiffre dans les mots de passe.
  • 95% des systèmes n’imposent aucune restriction relative aux caractères. L’interdiction des voyelles permettrait, à elle seule, de renforcer la sécurité en empêchant les utilisateurs de choisir des mots simples et faciles à deviner pour leurs mots de passe.
  • 35% des systèmes n’obligent pas l’utilisateur à choisir un mot de passe différent du précédent.

L’expiration du mot de passe est un domaine où des progrès ont été réalisés. Sur les systèmes étudiés ici, l’intervalle moyen d’expiration du mot de passe est de 90 jours.

CONSEIL

CONSEIL

Demandez des mots de passe d’au moins huit caractères. IBM i peut même prendre en charge des mots de passe comptant jusqu’à 128 caractères — qu’il serait plus approprié d’appeler « phrases secrètes ». L’authentification multi-facteurs peut également protéger vos systèmes face aux tentatives d’accès non autorisé. Une autre option consiste à éliminer complètement les mots de passe en appliquant la connexion unique (SSO), basée sur une technologie intégrée au système d’exploitation IBM i.

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS:TENTATIVES DE CONNEXION NON VALIDES

SÉCURITÉ DES MOTS DE PASSE ET DES PROFILS:TENTATIVES DE CONNEXION NON VALIDES

Un mot de passe peut être oublié, mal saisi ou tout simplement confondu avec un autre. Le personnel d’assistance chargé de réinitialiser ces mots de passe traite souvent avec les mêmes utilisateurs. Comment savoir quels utilisateurs effectuent des tentatives de connexion non valides ? Que faire si vos profils privilégiés sont visés? Si trois, quatre, voire dix tentatives signalent probablement un utilisateur frustré, des plus grands nombres de
tentatives peuvent être le signe d’une tentative d’intrusion.

58 % des systèmes comportaient un profil ayant fait l’objet de plus de 100 tentatives refusées. 28 % des systèmes incluaient plus de
1 000 tentatives de connexion non valides sur un seul profil. Un système étudié comptait même plus de 900 millions de tentatives sur un seul profil!

La Figure 6 illustre l’action menée en cas de dépassement du nombre maximal de tentatives de connexion autorisées. Dans 91% des cas, le profil est désactivé — ce qui est toujours recommandé. En cas d’utilisation explicite d’appareils nommés (par opposition aux noms d’appareils virtuels), il est recommandé de désactiver également la description des appareils. Il n’est pas recommandé de désactiver les appareils virtuels, car le système crée généralement un appareil lors de la reconnexion de l’utilisateur. Le paramètre relatif aux appareils ne s’applique pas à toutes les connexions (par
ex. les services ODBC et REXEC).

Les 9% restants de serveurs désactivent l’appareil, mais laissent le profil activé. Cela engendre des risques si l’utilisateur rétablit la connexion, voire se connecte à un serveur ne nécessitant pas d’appareil de poste de travail.

CONSEIL

CONSEIL

Pour protéger votre système, veillez à ce que les profils soient désactivés par défaut en cas de dépassement du nombre maximal autorisé de
tentatives de connexion. Un outil de réinitialisation de mot de passe en libre-service peut aider les utilisateurs ayant réellement oublié leur mot de passe. Password Self Help for IBM i est une option qui permet aux utilisateurs IBM i de réinitialiser facilement un mot de passe, et envoie des alertes instantanées au
personnel désigné en cas d’échec de la réinitialisation.

*ACCÈS PUBLIC AUX DONNÉES

*ACCÈS PUBLIC AUX DONNÉES

Sur la plupart des serveurs, les utilisateurs ne disposent généralement d’aucun droit vis-à-vis d’un objet ou d’une tâche, à moins qu’une
autorisation leur ait été expressément accordée. Avec IBM i, chaque objet possède une autorisation par défaut applicable aux utilisateurs non authentifiés, connus sous le nom de *PUBLIC. Cette autorisation par défaut est initialement définie par IBM avec des droits suffisants pour
lire, modifier, voire supprimer des données d’un fichier. Sauf s’il dispose d’un droit spécifique (accès accordé ou refusé), l’utilisateur peut profiter de l’autorisation par défaut de l’objet. Lorsque les droits d’accès *PUBLIC sont exempts de toute restriction, il y a un risque de modifications non autorisées de programmes et de bases de données — autant de signes d’alarme pour les auditeurs.

Cette étude utilise les droits d’accès *PUBLIC aux bibliothèques comme outil de mesure simple afin d’évaluer le degré d’accessibilité des données
IBM i à l’utilisateur final moyen. La Figure 7 détaille les niveaux d’accès aux bibliothèques du droit *PUBLIC constatés lors de notre étude.

*USE: *PUBLIC peut obtenir un catalogue de tous les objets dans cette bibliothèque, et tenter d’utiliser ou d’accéder à n’importe quel objet dans
cette bibliothèque

*CHANGE: *PUBLIC peut placer de nouveaux objets dans la bibliothèque et modifier certaines caractéristiques de la bibliothèque

*ALL: *PUBLIC peut gérer, renommer, spécifier la sécurité de, voire supprimer une bibliothèque (si l’utilisateur dispose du droit de suppression des objets de la bibliothèque)

D’après nos résultats, les entreprises dotées d’IBM i laissent encore beaucoup trop de bibliothèques accessibles à l’utilisateur moyen — des bibliothèques comprenant souvent des informations critiques sur l’entreprise. Dans un contexte où la quasi-totalité des utilisateurs système ont accès à beaucoup plus de données que nécessaire, les administrateurs ont besoin de processus plus performants pour contrôler l’accès aux données IBM i.

CONSEIL

CONSEIL

Dans la mesure du possible, sécurisez les données à l’aide d’une sécurité de niveau ressource afin de protéger les objets d’application
et de données individuels. Si cette tâche s’avère impossible ou peu pratique, utilisez la technologie de programme d’exit pour réglementer l’accès aux données.

Veillez à ce que les bibliothèques d’applications soient protégées des utilisateurs généraux sur le système. (Envisagez de régler les
valeurs Système et Bibliothèque du droit de création par défaut sur le paramètre le plus restrictif [*EXCLUDE]. Attention : cette tâche exige
une certaine planification.)

ACCÈS *PUBLIC AUX NOUVEAUX FICHIERS ET PROGRAMMES

ACCÈS *PUBLIC AUX NOUVEAUX FICHIERS ET PROGRAMMES

Lorsque de nouveaux fichiers et programmes sont créés sur la plupart des systèmes, l’utilisateur moyen dispose automatiquement de droits de modification sur la grande majorité de ces nouveaux objets. Les utilisateurs non nommés (PUBLIC) ont le droit de lire, d’ajouter, de modifier et de supprimer des données du fichier. Ils peuvent copier des données depuis le fichier ou y télécharger des données, et même modifier certaines caractéristiques d’objet du fichier.

Cela est dû au fait que le droit *PUBLIC sur les fichiers et programmes nouvellement créés est généralement issu du paramètre de droit de création par défaut (CRTAUT) de la bibliothèque. La Figure 8 montre que pour 15 % des bibliothèques, le droit de création par défaut est défini sur *USE, *CHANGE ou *ALL. Pour 83 % des bibliothèques cependant, le paramètre est reporté sur la valeur système (*SYSVAL) de QCRTAUT. Dans la Figure 8A détaillant l’attribution de niveau bibliothèque de *SYSVAL, on constate que la valeur système par défaut *CHANGE est généralement conservée. Seuls 8 % des serveurs sont configurés par défaut sur l’exigence de refus par défaut des normes réglementaires courantes, comme la norme PCI DSS.

Un autre problème se produit lorsqu’un profil utilisateur est créé avec des autorisations accordées aux utilisateurs généraux (*PUBLIC). Lorsque les autorisations *PUBLIC dépassent le paramètre fortement recommandé *EXCLUDE, on parle de « profil non sécurisé ». Un autre utilisateur a la possibilité d’exécuter une tâche qui exploite les privilèges du profil non sécurisé. Cette activité ne sera pas consignée par le système d’exploitation comme une violation de la sécurité, car elle est considérée comme admissible à tous les niveaux de sécurité. 175 systèmes possèdent au moins un profil non sécurisé, tandis que 40 systèmes comptent dix profils publiquement accessibles ou plus.

CONSEIL

CONSEIL

Il est évident qu’il faut faire de la cybersécurité une priorité, mais aussi déployer des outils de sécurité offrant aux utilisateurs un accès sécurisé et aisé aux données dont ils ont besoin. Les outils Powertech peuvent être utiles dans ce cas.

Veillez à surveiller les modifications apportées aux informations de votre base de données, de façon à respecter les exigences de conformité.

ACCÈS RÉSEAU

ACCÈS RÉSEAU

Les services tels que FTP, ODBC, JDBC et DDM peuvent transmettre des données IBM i sur le réseau, et ce, dès la mise sous tension de la machine. Les utilisateurs finaux ont simplement besoin d’un outil gratuit (disponible sur Internet) ou d’outils pré-installés sur un PC. Par exemple, Windows est livré avec un logiciel client FTP qui permet d’envoyer et de récupérer facilement des données depuis un serveur IBM i.

Certains services TCP autorisent même l’exécution de commandes de serveur. Le service FTP facilement accessible permet à tous les utilisateurs — même ceux ne disposant pas d’une autorisation de ligne de commande sur leur profil — d’exécuter des commandes telles que Supprimer une bibliothèque (DLTLIB).

Pour atténuer cette vulnérabilité, IBM fournit des interfaces, appelées « points d’exit », grâce auxquelles les administrateurs peuvent sécuriser
leurs systèmes. Un programme d’exit relié à un point d’exit peut surveiller et limiter l’accès du réseau au système. Un programme d’exit doit offrir deux fonctions principales : auditer les demandes d’accès et fournir un contrôle d’accès augmentant la sécurité de niveau objet d’IBM i.

HelpSystems a passé en revue 27 interfaces de point d’exit réseau différentes sur chaque système, afin de vérifier la présence de programmes d’exit inscrits. 69 % des systèmes ne disposent d’aucun programme d’exit qui leur permettrait de consigner et de contrôler l’accès réseau (Figure 9). Même sur les systèmes dotés de programmes d’exit, la couverture est souvent incomplète. Parmi tous les systèmes ayant déployé des programmes, 10 % d’entre eux ne comptent qu’un ou deux programmes d’exit inscrits, et 8 % seulement sont dotés de programmes inscrits sur tous les points d’exit d’accès réseau. L’adoption de programmes d’exit a régulièrement augmenté ces dernières années, mais bon nombre d’entreprises ignorent encore ce problème d’accès réseau libre.

CONSEIL

CONSEIL

Dans les organisations dépourvues d’une solution commerciale de programme de sortie, celle-ci a tendance à compter parmi les priorités majeures en matière de résolution. En l’absence de programmes de sortie, IBM i ne fournit aucune piste d’audit de l’activité utilisateur provenant d’outils d’accès réseau courants (par ex. FTP ou ODBC).

Les organisations peuvent écrire leurs propres programmes de sortie ou utiliser un logiciel pour réaliser cette tâche. Les solutions commerciales comme Powertech Exit Point Manager for IBM i offre un avantage : une couverture élargie qui protège tous les points de sortie critiques.

ACCÈS PAR LIGNE DE COMMANDE

ACCÈS PAR LIGNE DE COMMANDE

La méthode traditionnelle de contrôle de l’accès aux données sensibles et aux commandes puissantes consiste à limiter aux utilisateurs finaux l’accès à la ligne de commande — une méthode qui s’est avérée efficace par le passé.

En plus de limiter les capacités du profil utilisateur, les menus des applications permettaient de contrôler la façon dont les utilisateurs accédaient aux données, mais aussi quand ces derniers avaient accès à une ligne de commande. Cette approche a toutefois perdu en solidité lorsqu’IBM a ouvert de nouvelles interfaces permettant d’accéder aux données et d’exécuter des commandes à distance.

76 % des utilisateurs se sont vu refuser l’accès par ligne de commande, et sont incapables d’exécuter la plupart des commandes via des interfaces de menu traditionnelles. 17 % des utilisateurs étudiés ici disposent à la fois d’un accès par ligne de commande et d’un profil activé, ce qui présente un risque évident.

Plusieurs interfaces réseau ne reconnaissant pas la configuration des limites de ligne de commande dans un profil utilisateur, elles doivent être contrôlées d’autres manières. En d’autres termes, les utilisateurs peuvent exécuter des commandes à distance même si les administrateurs système ont pris expressément des précautions pour les empêcher d’utiliser une ligne de commande.

CONSEIL

CONSEIL

À partir du droit *PUBLIC au sens large décrit dans les sections précédentes, tout utilisateur sur ces systèmes peut accéder à des données, commandes et programmes sans que le système d’exploitation n’en garde une trace.

Pour résoudre ce problème, commencez par rechercher les activités inappropriées ou dangereuses dans les transactions d’accès aux données
réseau. Veillez à établir des directives claires de téléchargement de fichiers et d’autorisations de partage de fichiers. Supprimez l’accès DB2
par défaut dans les outils tels que Microsoft Excel et IBM i Client Access.

AUDIT DES ÉVÉNEMENTS DE SÉCURITÉ

AUDIT DES ÉVÉNEMENTS DE SÉCURITÉ

IBM i peut consigner les événements importants liés à la sécurité dans un référentiel inviolable : le journal d’audit de sécurité. Cette fonctionnalité permet aux organisations de déterminer la source d’événements de sécurité critiques, en répondant à des questions telles que « qui a supprimé ce fichier ? » ou « qui a accordé le droit *ALLOBJ à cet utilisateur ? ». Ces informations peuvent faire toute la différence entre une réponse rapide à un événement de sécurité et la découverte d’une faille après un dommage important. La difficulté réside dans le fait que le volume de données contenu dans le journal d’audit de sécurité est important et que le contenu est codé. La plupart des membres du personnel informatique peinent à surveiller et à comprendre l’activité consignée.

20 % des systèmes passés en revue ne disposent d’aucun référentiel de journal d’audit. 24 % des systèmes s’exécutent avec la valeur système QAUDCTL laissée par défaut sur *NONE (Figure 10). Ce paramètre agit comme l’interrupteur principal marche/arrêt de l’audit, et empêche globalement la consignation de tous les événements de niveau système ou objet, qu’un journal d’audit système existe ou non. Le paramétrage de QAUDCTL sur *NONE laisse penser que les administrateurs ont lancé la fonction d’audit avant de la désactiver ensuite, ou qu’ils ignorent qu’une configuration supplémentaire est requise.

Lorsque les organisations ont activé le journal d’audit de sécurité, le volume de connaissances fournies par les données étendues à ces organisations reste inconnu. Plusieurs fournisseurs logiciels proposent des outils d’audit qui rapportent et passent en revue les données système écrites dans le journal d’audit de sécurité. Cependant, 19 % des systèmes seulement étudiés ici disposent d’un outil reconnaissable.

CONSEIL

CONSEIL

Utilisez le journal d’audit de sécurité et automatisez le processus d’analyse des données brutes. Les outils d’audit réduisent les coûts du
reporting de conformité et augmentent les chances que le travail sera effectué. Les données de sécurité d’IBM i peuvent même être envoyées en temps réel à votre solution de gestion des informations et des événements de sécurité (SIEM).

PROTECTION ANTIVIRUS ET ANTI-MALWARE

PROTECTION ANTIVIRUS ET ANTI-MALWARE

Bien que l’infrastructure des bibliothèques et des objets IBM i traditionnelle soit considérée comme très résistante aux virus, d’autres structures de fichiers dans le système de fichiers intégré (IFS) peuvent héberger des fichiers infectés, qui peuvent ensuite se propager sur le réseau. Pour répondre à ce problème, IBM a créé, il y a quelques années, des valeurs système et des points de sortie du registre afin de prendre en charge l’analyse virus native.

Lors de sa toute première analyse antivirus d’IBM i, une entreprise a eu la désagréable surprise de trouver près de 250 000 fichiers infectés — un exemple qui prouve la réalité du risque auprès de ceux qui douteraient encore de la nécessité d’une protection antivirus. La recherche de virus et de malware dans IBM i est de plus en plus répandue, à mesure que les administrateurs prennent conscience du fait qu’IBM i contient des systèmes de fichiers qui ne sont pas à l’abri des infections, mais aussi que dans certains cas, les applications natives et IBM i lui-même peuvent être touchés.

Lors de l’évaluation des contrôles antivirus sur les serveurs, 14 % de ces derniers analysaient les fichiers ouverts, ce qui est une amélioration notable par rapport aux années précédentes. Cela signifie que les 86 % restants risquent de subir des impacts sur les objets internes ou de contaminer un autre serveur situé sur leur réseau (Figure 11).

CONSEIL

CONSEIL

Inscrivez un programme d’exit au point d’exit QIBM_QP0L_SCAN_OPEN pour intercepter les tentatives d’ouverture de fichier depuis le réseau et analyser les fichiers avant leur ouverture. Vous empêcherez ainsi les virus de se propager hors de l’environnement IBM i.

Installez une solution antivirus s’exécutant nativement sur IBM i, par exemple Powertech Antivirus for IBM i, afin de détecter et éliminer les infections, mais aussi empêcher les malware de se propager au-delà de l’environnement en cours.

En outre, l’utilisation d’un programme d’exit inscrit au point d’exit QIBM_QPWFS_FILE_SERV peut contribuer à limiter l’action de virus distants opérant sur d’autres serveurs du réseau.

CONCLUSION

CONCLUSION

IBM i a la réputation d’être l’une des plates-formes les plus sécurisées du marché. Les outils avancés de protection, de surveillance et de consignation intégrés au système d’exploitation constituent l’un des avantages majeurs d’IBM i. Cependant, les experts s’accordent à dire que la sécurité d’IBM i ne peut être plus efficace que les politiques, procédures et configurations mises en place pour gérer cette même sécurité.

Cette étude a révélé certaines failles de sécurité et pratiques de gestion des configurations courantes, qui doivent être abordées afin de protéger les données sur les systèmes IBM i. De même qu’aucun système ne se révèle vulnérable en une seule nuit, il est impossible de résoudre tous les problèmes de sécurité en une seule journée. Ce qui importe, c’est de commencer à un moment donné, puis de progresser continuellement vers un profil de sécurité renforcé.

En cas de doute sur la procédure à suivre, commencez par les grandes priorités de sécurité d’IBM i :

  • Sécurité du système: contrôlez le niveau QSECURITY et veillez à ce que sa valeur soit égale ou supérieure à 40
  • Audit de sécurité: activez QAUDJRN et trouvez un outil facilitant son interprétation
  • Accès réseau: Commencez par inscrire les points d’exit les plus courants, comme FTP et ODBC
  • Réduisez les privilèges d’utilisateur non nécessaires

La plupart des experts conseillent de commencer par évaluer les vulnérabilités, afin de déterminer la sécurité actuelle de votre système, et de savoir comment l’améliorer. Des professionnels de la sécurité sont à votre disposition pour vous proposer leur expertise IBM i et des solutions logicielles conviviales, afin d’accélérer et de faciliter la mise en oeuvre de ce projet. HelpSystems propose un éventail d’options, allant d’une évaluation des risques ultra-rigoureuse jusqu’à la solution Security Scan rapide et gratuite.

Une fois toutes les informations en main, vous pouvez élaborer un plan qui aborde toutes les vulnérabilités de votre organisation en matière de sécurité. À partir de là, la sécurité deviendra une activité de routine pour votre entreprise — et ne sèmera plus la panique après un audit raté ou une faille de données.

HELPSYSTEMS PEUT VOUS AIDER AVEC IBM i

Vérifiez le degré de sécurité de votre système IBM i en exécutant un Security Scan HelpSystems. Gratuit et rapide, Security Scan révèle les lacunes de sécurité de votre système. Nos conseillers en sécurité peuvent ensuite vous aider à élaborer un plan pour résoudre vos vulnérabilités de sécurité.

Solutions récentes