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

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.

À 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, Fortra 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 Fortra, 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

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.

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.

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.

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.

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.

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.

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.

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.

*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.

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.

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.

Fortra 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.

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.

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.

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).

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. Fortra 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.