Studie zum Stand der IBM i-Sicherheit

Zusammenfassung

Mittlerweile im 18. Jahr bietet diese Studie überzeugende Einblicke in die Sicherheitslage von 247 IBM i-Servern und -Partitionen – Systeme, die häufig für geschäftskritische Daten, Zahlungskartendaten und personenbezogene Daten verwendet werden.

Auch wenn die Systeme, die in der Studie vorkommen, sich von Jahr zu Jahr verändern, lassen sich allgemeine Trends erkennen. Cybersicherheit wird für die teilnehmenden Unternehmen immer wichtiger, und in den letzten Jahren haben sie schrittweise Verbesserungen bei der grundlegenden Systemsicherheit und bei der Benutzung von Kennwort vorgenommen. Allerdings befinden sich viele Unternehmen noch in der Anfangsphase der Implementierung von IBM i-Sicherheitskontrollen.

Über diese Studie

Trends bei der IBM i-Sicherheit

Cyberbedrohungen werden jedes Jahr intelligenter, wodurch angemessene Sicherheitskontrollen immer mehr an Bedeutung gewinnen. Die Studie aus dem Jahr 2021 zum Stand der IBM i-Sicherheit belegt, dass viele Unternehmen Systemeinstellungen verwenden, die Daten nicht ausreichend schützen.

In den letzten Jahren hat Fortra jedoch einen ermutigenden Trend beobachtet: Größere wie kleinere Unternehmen legen immer mehr Wert auf IBM i-Sicherheit.

Ein tieferes Verständnis der Risiken und der Sicherheitskontrollen, die in das Betriebssystem integriert sind, führt derzeit zu einer Welle des Interesses an Cybersicherheit auf IBM i.

Warum diese Studie für Sie von Bedeutung ist

Die 18. jährliche Studie zum Stand der IBM i-Sicherheit hilft Ihnen dabei, häufige IBM i-Sicherheitslücken zu verstehen und wie diese schnell und effektiv behoben werden können.

Auf Ihrem IBM i-Server laufen wahrscheinlich unternehmenswichtige Anwendungen. Da Windows- und UNIX-Plattformen jedoch häufig mehr Ressourcen benötigen, können IBM i-Sicherheitsprojekte leicht in den Hintergrund treten.

Darum werden IBM i-Sicherheitskontrollen häufig vernachlässigt, selbst wenn die Bedrohungen für Ihr System zunehmen.

Die durch unsere Scans identifizierten und in dieser Studie dokumentierten Schwachstellen werden durch schlechte oder fehlende Konfigurationen verursacht, die behoben werden können und sollten.

Diese Studie zeigt die häufigsten und gefährlichsten IBM i -Sicherheitslücken und liefert Tipps zur Verbesserung.

Methodik

Die in dieser Studie veröffentlichten Daten werden u. a. von Fortra-Sicherheitsexperten gesammelt, die IBM i-Systeme mit unserem IBM i-Security Scan auditieren. Diese kostenlose Software kann direkt von jedem an das Netzwerk angeschlossenen PC ausgeführt werden, ohne dass Systemeinstellungen geändert werden müssten. Dabei werden POWER-Systeme mit IBM i (System i, iSeries, AS/400) in sieben kritischen Bereichen untersucht:

• Sicherheitskontrollen auf Serverebene
• Profil- und Kennworteinstellungen
• Administrative Funktionen
• Vom Netzwerk initiierte Befehle und Datenzugriffe
• Öffentlicher Zugriff auf Unternehmensdaten
• Systemweite Sicherheits-Protokollierung
• Virenscans

Die diesjährige Studie umfasst 247 IBM i-Partitionen, die 2020 auditiert wurden. Im Durchschnitt hatten die für diese Studie gescannten Systeme 1.056 Benutzer und 552 Bibliotheken. Die Mehrheit der gescannten Server lief auf unterstützten Betriebssystemversionen; allerdings liefern 25 % auf 7.2. Der Support für diese Version wurde von IBM im April 2021 eingestellt.

SICHERHEITSSTUFE: QSECURITY

Best Practices für IBM i-Sicherheit beginnen mit der Konfiguration zahlreicher Systemwerte, die steuern, wie einfach oder schwierig es für jemanden ist, das System zu nutzen oder zu missbrauchen. Schlecht konfigurierte oder nicht überwachte Systemwerte sind ein inakzeptables Sicherheitsrisiko.

QSECURITY-Einstellung

Die System-Sicherheitsstufe (QSECURITY) ist die grundlegende Einstellungen, obwohl ihre Wirkung durch andere Einstellungen beeinträchtigt wird. IBM empfiehlt und liefert Sicherheitsstufe 40 als Minimum, da in Ebene 30 und darunter dokumentierte Schwachstellen gefunden wurden. Es ist jedoch zu beachten, dass trotz der Änderung der Standardeinstellung bei einer Servermigration normalerweise der gleiche Wert wie bei der vorherigen Generation des Servers weiterverwendet wird.

Abbildung 1 zeigt die Verteilung der Sicherheitsstufen auf den Systemen, die im Datensatz 2021 enthalten sind. Von den 247 untersuchten Systemen liefen 18 Prozent auf Sicherheitsebene 30 und acht Prozent auf Sicherheitsebene 20. Insgesamt erreichten 26 Prozent die von IBM empfohlene Mindeststufe nicht (Abbildung 1A). Bei vielen Systemen, die unterhalb der empfohlenen Sicherheitsstufe laufen, geschieht dies ohne bewusste Absicht. Vielmehr haben sie ihre Systemwerte von einem älteren Server migriert und erkennen nun, dass sie Korrekturmaßnahmen ergreifen müssen.

GRUNDLEGENDE SYSTEMSICHERHEIT: SCHLÜSSELWERTE FÜR DIE WIEDERHERSTELLUNG VON OBJEKTEN

Mehrere andere Systemwerte im Zusammenhang mit der Objektwiederherstellung verbleiben oft auf ihrem Auslieferungsstand, was einer typischen IBM i-„Einschalten-und-Loslegen“-Konfiguration entspricht.

Die betroffenen Systemwerte sollen gemeinsam als Filter agieren, der die Wiederherstellung bösartiger oder manipulierter Objekte verhindert. Allerdings bieten die Standardwerte von IBM  i diesen Schutz nicht, sodass das System anfällig bleiben kann.

Die nachfolgenden Systemwerte bestimmen zusammen, ob ein Objekt wiederhergestellt werden soll oder ob es während der Wiederherstellung konvertiert werden muss:

• Objekt bei Wiederherstellung prüfen (QVFYOBJRST) – Über 72 Prozent der Server laufen unter der empfohlenen Stufe 3. Dieser Wert, dessen Standardeinstellung Stufe 1 ist, steuert, ob eine Signatur validiert wird, wenn ein digital signiertes Objekt wiederhergestellt wird.
• Konvertierung bei Wiederherstellung erzwingen (QFRCCVNRST)—94 Prozent der Server laufen unter der empfohlenen Stufe 3. Dieser Wert, dessen Standardeinstellung Stufe 1 ist, steuert, ob bestimmte Objekttypen während der Wiederherstellung konvertiert werden.
• Objektwiederherstellung erlauben (QALWOBJRST)—Nur auf vier Prozent der Server war die Standardeinstellung *ALL für diesen Systemwert geändert worden. Dieser Wert steuert, ob Programme mit bestimmten Sicherheitsattributen wie System-Status und Berechtigungsübernahme wiederhergestellt werden können.

Benutzer mit umfangreichen Berechtigungen

IT-Experten benötigen Sonderberechtigungen, um Server verwalten zu können. Diese Berechtigungen können auch die Möglichkeit gewähren, Finanzanträge, Kreditkartendaten von Kunden und vertrauliche Mitarbeiterakten einzusehen oder zu ändern. In unachtsamen, fehlgeleiteten oder böswilligen Händen kann ein Benutzer mit Sonderberechtigungen ernsthaften Schaden anrichten.

IBM i-Sonderberechtigungen sind Administratorberechtigungen und stellen immer ein Sicherheitsrisiko dar. Prüfer verlangen daher von Ihnen, die Benutzer mit diesen Sonderberechtigungen einzuschränken und deren Verwendung sorgfältig zu überwachen und zu prüfen. Unter den Sonderberechtigungen ist *ALLOBJ diejenige, die Benutzern die uneingeschränkte Möglichkeit bietet, jede Datei und jedes Programm auf dem System anzuzeigen, zu ändern und zu löschen. Diese wird manchmal auch als „Root“-Berechtigung bezeichnet. Wie in Abbildung 2 gezeigt, wird diese Berechtigung unglaublich vielen Benutzern gewährt.

Nur drei Systeme hatten 10 oder weniger Benutzer mit *ALLOBJ-Berechtigung. Die Anzahl der Benutzer mit *ALLOBJ war wesentlich höher als im vergangenen Jahr – durchschnittlich 30 Prozent der Benutzer in diesem Jahr, im Vergleich zu nur 15 Prozent im vergangenen Jahr. 

Neben All Object waren die am häufigsten gewährten Sonderberechtigungen zur Jobsteuerung (*JOBCTL) und zur Spool-Steuerung (*SPLCTL), die jeweils 44 Prozent und 24 Prozent der Benutzer gewährt wurden.

Job Control bietet die Möglichkeit, die Priorität von Jobs und Druckvorgängen zu ändern und in einigen Fällen sogar Untersysteme zu beenden. Mit Spool Control können Benutzer vollständig auf gespoolte Dateien in einer Ausgabewarteschlange zugreifen, ungeachtet der für die Spooldatei geltenden Einschränkungen.

Kennwort- und Profilsicherheit: Inaktive Profile

Inaktive Profile sind Benutzerprofile, die seit 30 Tagen oder länger nicht verwendet wurden. Sie schaffen eine Sicherheitslücke, weil diese Konten von ihren Benutzern nicht aktiv verwaltet werden, was sie zu Hauptzielen für Hijacking macht.

Viele dieser inaktiven Profile gehören ehemaligen Mitarbeitern oder Auftragnehmern – Personen, die möglicherweise einen Groll hegen oder für die Daten ihres ehemaligen Arbeitgebers in ihrer neuen Rolle bei Wettbewerbern nützlich sein könnten.

Die Bedrohung bleibt auch dann bestehen, wenn ehemalige Mitarbeiter niemals versuchen, diese Profile zu verwenden. Andere Benutzer innerhalb des Unternehmens wissen möglicherweise beispielsweise, dass das Profil des ehemaligen IT-Leiters noch im System vorhanden ist. Unabhängig davon, ob ein inaktives Profil von einem ehemaligen Mitarbeiter, einem böswilligen Insider oder einem Hacker ausgenutzt wird, die ungewöhnliche Verwendung des Profils wird vom Profilbesitzer nicht erkannt und gemeldet.

Abbildung 3 zeigt, dass bei durchschnittlich 427 Profilen (40 Prozent insgesamt) in den vergangenen 30 Tagen keine Anmeldung stattgefunden hat. Von diesen bleiben 259 aktiviert und bereit für die Verwendung.

Kennwort- und Profilsicherheit: Standardkennwörter

Auf IBM i haben diejenige Profile ein Standardkennwort, bei denen Kennwort und Benutzername identisch sind. Hacker – oder sogar Ihre eigenen Mitarbeiter – können Profilnamen wie „PSCHMIDT“ erraten und Standardkennwörter ausprobieren.

Regulatorische und gesetzliche Standards schreiben in der Regel vor, dass Benutzer eindeutige Anmeldeinformationen verwenden müssen, die nur dem Benutzer bekannt sind, um sicherzustellen, dass alle Aktionen mit dieser bestimmten Person in Verbindung gebracht werden können. Unternehmen könnten Schwierigkeiten haben, illegale oder nicht autorisierte Aktivitäten strafrechtlich zu verfolgen, wenn sich herausstellt, dass die Anmeldeinformationen den Täter nicht eindeutig identifizieren.

In dieser Studie hatten fast 15 Prozent der Benutzerprofile Standardkennwörter (Abbildung 4). 44 Prozent der untersuchten Systeme haben mehr als 30 Benutzer mit Standardkennwörtern. Bei 25 % haben sogar über 100 Benutzer Standardkennwörter. Ein System hat insgesamt 5.604 Benutzerprofile mit Standardkennwörtern, von denen mehr als 2.000 aktiviert waren.

Kennwort- und Profilsicherheit: Kennwortlänge

Kürzere Kennwörter sind leichter zu merken, aber sie können von anderen auch leichter erraten werden. Obwohl kurze Kennwörter mit zufälligen Zeichen gestärkt werden können, ist die Wahrscheinlichkeit größer, ein vierstelliges Kennwort zu erraten als ein längeres.

Das amerikanische National Institute of Standards and Technologies (NIST) empfiehlt inzwischen die Verwendung von achtstelligen Kennwörtern, anstatt sechsstelliger Kennwörter.

Laut unseren Erkenntnissen erfüllen oder übersteigen fast 30 Prozent den Best-Practice-Standard von acht Zeichen oder mehr. 50 Prozent der Server in dieser Studie erfüllen die PCI-Anforderung von siebenstelligen Kennwörtern nicht. Schockierenderweise erlauben 15 Prozent der Systeme Benutzern, ein Kennwort zu wählen, das kürzer als sechs Zeichen ist, und vier Server erlaubten die Verwendung von Kennwörtern mit nur einem Zeichen.

Kennwort- und Profilsicherheit: Sonstige Kennworteinstellungen

IBM i ermöglicht Systemadministratoren die Definition einer Kennwortrichtlinie auf granularer Ebene. Kennworteinstellungen umfassen Länge, Zeicheneinschränkungen, Zifferneinschränkungen, Ablaufzeitraum und wann ein Kennwort wiederverwendet werden kann.

Mit diesen Einstellungen lassen sich Kennwörter schwieriger erraten und der Schutz Ihres Systems wird verbessert, da einfache, leicht zu erratende Kennwörter wie „123456“ und „passwort“ noch immer ziemlich verbreitet sind. Stellen Sie sich vor, was passieren kann, wenn Ihre Benutzer mit einfachen Kennwörtern Sonderberechtigungen oder Zugriff auf sensible Daten haben.

Die neuesten Daten zeigen, dass IBM i-Administratoren nicht alle Einstellungsmöglichkeiten für Kennwörter nutzen, die ihnen zur Verfügung stehen:

• 47 Prozent der Systeme erfordern keine Ziffer in Kennwörtern.
• 93 Prozent der Systeme haben keine Einschränkungen bezüglich der Zeichen. Allein das Verbieten von Vokalen würde für zusätzliche Sicherheit sorgen, indem Benutzer daran gehindert werden, einfache, leicht zu erratende Worte für ihre Kennwörter zu verwenden.
• 26 Prozent der Systeme verlangen nicht, dass sich neue Kennwörter von den vorherigen unterscheiden.

Im Bereich des Ablaufs von Kennwörtern sehen wir Fortschritte. Bei den Systemen in unserer Studie beträgt die durchschnittliche Kennwortgültigkeit 95 Tage.

Kennwort- und Profilsicherheit: Ungültige Anmeldeversuche

Kennwörter werden vergessen, falsch eingegeben oder einfach mit anderen Kennwörtern verwechselt. Helpdesk-Mitarbeiter, die diese Kennwörter zurücksetzen müssen, haben es oft mit immer denselben Benutzern zu tun. Wie können Sie nachverfolgen, welche Benutzer mehrere ungültige Anmeldeversuche haben? Was ist, wenn Ihre mächtigen Profile gezielt angegriffen werden? Größere Zahlen könnten auf einen Eindringungsversuch hindeuten, während drei, fünf oder sogar zehn Versuche wahrscheinlich auf einen frustrierten Benutzer hinweisen.

49 Prozent der Systeme hatten ein Profil mit über 100 abgelehnten Versuchen. 20 Prozent hatten mehr als 1.000 ungültige Anmeldeversuche für ein einziges Profil. Ein System in unserer Studie hatte über drei Millionen Versuche für ein Profil.

Abbildung 6 zeigt die Maßnahmen, die ergriffen werden, wenn die maximale Anzahl zulässiger Anmeldeversuche überschritten wird. In 95 Prozent der Fälle wird das Profil deaktiviert. Das wird immer empfohlen. Bei Verwendung explizit benannter Geräte (im Gegensatz zu virtuellen Gerätenamen) wird die Empfehlung um die Deaktivierung der Gerätebeschreibung erweitert. Es wird nicht empfohlen, virtuelle Geräte zu deaktivieren, da das System normalerweise ein neues Gerät erstellt, wenn der Benutzer erneut eine Verbindung herstellt. Die Geräteeinstellung gilt nicht für alle Verbindungen, wie z. B. ODBC- und REXEC-Dienste.

Die anderen fünf Prozent der Server deaktivieren das Gerät, lassen das Profil jedoch aktiviert. Dadurch entsteht ein Risiko, wenn der Benutzer eine Verbindung wiederherstellt oder möglicherweise eine Verbindung zu einem Dienst herstellt, der kein Workstation-Gerät erfordert.

*PUBLIC-Zugriff auf Daten

Auf den meisten Servern haben Benutzer normalerweise keine Berechtigung für ein Objekt oder eine Aufgabe, es sei denn, ihnen wurde ausdrücklich die Berechtigung erteilt. Bei IBM i hat jedes Objekt eine Standardberechtigung, die für nicht benannte Benutzer gilt, zusammenfassend als *PUBLIC bezeichnet. TDiese Standardberechtigung wird anfänglich von IBM mit ausreichender Berechtigung zum Lesen, Ändern und sogar Löschen von Daten aus einer Datei festgelegt. Sofern dem Benutzer keine bestimmte Berechtigung erteilt wird (erteilter oder verweigerter Zugriff), kann der Benutzer die Standardberechtigung des Objekts nutzen. Wenn *PUBLIC-Zugriffsrechte uneingeschränkt bleiben, besteht die Gefahr von unbefugten Programmänderungen und Datenbankänderungen – Alarmsignale für Prüfer.

Diese Studie verwendet die *PUBLIC-Zugriffsrechte auf Bibliotheken als einfaches Maß dafür, wie zugänglich IBM i-Daten für den durchschnittlichen Endbenutzer sind. Abbildung 7 zeigt, welchen Zugriff *PUBLIC auf Bibliotheken auf den Systemen in unserer Studie hat.

*USE: *PUBLIC kann einen Katalog aller Objekte in dieser Bibliothek erhalten und versuchen, auf Objekte in der Bibliothek zuzugreifen oder sie zu verwenden.

*CHANGE: *PUBLIC kann neue Objekte in der Bibliothek platzieren und einige ihrer Eigenschaften ändern.

*ALL: *PUBLIC kann Sicherheit für eine Bibliothek verwalten, umbenennen, festlegen oder sie gar löschen (wenn die Löschberechtigung für dieses Bibliothek vorhanden ist).)

Unsere Ergebnisse zeigen, dass IBM i-Unternehmen immer noch viel zu viele Bibliotheken haben, auf die der durchschnittliche Benutzer zugreifen kann – Bibliotheken, die oft kritische Unternehmensinformationen enthalten. Da praktisch jeder Systembenutzer Zugriff auf Daten hat, die weit über seinen nachgewiesenen Bedarf hinausgehen, benötigen Administratoren bessere Prozesse, um den Zugriff auf IBM i-Daten zu kontrollieren.

*PUBLIC-Zugriff auf neue Dateien und Programme

Wenn auf den meisten Systemen neue Dateien und Programme erstellt werden, hat der durchschnittliche Benutzer automatisch Änderungsrechte für die überwiegende Mehrheit dieser neuen Objekte. Nicht benannte Benutzer (*PUBLIC) haben die Berechtigung zum Lesen, Hinzufügen, Ändern und Löschen von Daten aus der Datei. Diese Benutzer können Daten aus der Datei kopieren oder Daten in die Datei hochladen und sogar einige der Objektmerkmale der Datei ändern.

Das liegt daran, dass die Berechtigungen von *PUBLIC für neu erstellte Dateien und Programme normalerweise vom Parameter „Default Create Authority“ (CRTAUT) der Bibliothek stammt. Abbildung 8 zeigt, dass bei 16 Prozent der Bibliotheken „Default Create Authority“ auf *USE, *CHANGE oder *ALL festgelegt war. Allerdings hatten 82 Prozent der Bibliotheken die Einstellung auf den Standardsystemwert QCRTAUT (*SYSVAL) verschoben. Abbildung 8A analysiert die Einstellung *SYSVAL auf Bibliotheksebene und zeigt, dass der Systemwert normalerweise auf der ausgelieferten Standardeinstellung *CHANGE bleibt. Nur drei Prozent der Server sind so konfiguriert, dass sie standardmäßig den Ablehnungsanforderungen gängiger behördlicher Standards wie PCI DSS entsprechen.

Ein weiteres Problem tritt auf, wenn ein Benutzerprofil mit Berechtigungen erstellt wird, die der allgemeinen Benutzerpopulation (*PUBLIC) gewährt werden. Wenn *PUBLIC-Berechtigungen die dringend empfohlene Einstellung von *EXCLUDE überschreiten, wird dies als „ungesichertes Profil“ bezeichnet. Ein alternativer Benutzer kann die Berechtigungen des ungesicherten Profils ausnutzen. Diese Aktivität wird vom Betriebssystem nicht als Sicherheitsverletzung protokolliert, da sie auf allen Sicherheitsebenen als zulässig erachtet wird. 197 Systeme haben mindestens ein ungesichertes Profil und 59 Systeme haben 10 oder mehr Profile, die öffentlich zugänglich sind.

Netzwerkzugriff

Dienste wie FTP, ODBC, JDBC und DDM können IBM i-Daten über das Netzwerk senden, sobald das System hochgefahren ist. Der Endbenutzer benötigt lediglich ein kostenloses Tool aus dem Internet oder sogar Tools, die auf einem PC vorinstalliert sind. Windows umfasst beispielsweise eine FTP-Client-Software, die problemlos Daten von einem IBM i-Server sendet oder von diesem abruft.

Einige TCP-Dienste erlauben sogar die Ausführung von Serverbefehlen. Der leicht zugängliche FTP-Dienst ermöglicht, dass Befehle wie „Delete Library“ (DLTLIB) von allen Benutzern ausgeführt werden – sogar von denen, die keine Befehlszeilenberechtigung für ihr Profil haben.

Firewall-Schutz stellt einige IBM i-Experten vor die Frage, ob auf diese Weise jemals tatsächlich auf Systeme zugegriffen wird. Das Fortra-Team wurde jedoch kürzlich Zeuge eines laufenden Angriffs, bei dem ein Eindringling erfolgreich in den Perimeter eingedrungen war und wiederholt versuchte, über FTP mit verschiedenen Benutzerprofilen, darunter ADMINISTRA und ROOT, auf das System eines Kunden zuzugreifen.

Um dieses Risiko zu reduzieren, stellt IBM Schnittstellen bereit, die als Exit Points bezeichnet werden und es Administratoren ermöglichen, ihre Systeme zu sichern. Ein Exit-Programm, das an einen Exit Point angehängt ist, kann den Netzwerkzugriff auf das System überwachen und einschränken. Ein Exit-Programm sollte zwei Hauptfunktionen haben: Zugriffsanforderungen zu prüfen und Zugriffssteuerung bereitzustellen, die die Sicherheit auf Objektebene von IBM i erhöht.

Fortra überprüfte 27 verschiedene Network Exit Point-Schnittstellen auf jedem System, um zu überprüfen, ob ein Ausstiegsprogramm registriert wurde. 70 Prozent der Systeme verfügen über keine Exit-Programme, die es ihnen ermöglichen, den Netzwerkzugriff zu protokollieren und zu kontrollieren (Abbildung 9). Selbst auf Systemen mit Exit-Programmen ist der Schutz unvollständig. Nur 13 % der Systeme haben alle 27 Exit-Programme abgedeckt.{1}Die Einführung von Exit-Programmen hat in den letzten Jahren stetig zugenommen, aber viele Unternehmen sind sich dieses offenen Netzwerkzugangsproblems immer noch nicht bewusst.

Befehlszeilenzugriff

Der traditionelle Weg, den Zugriff auf sensible Daten und wichtige Befehle zu kontrollieren, bestand darin, den Befehlszeilenzugriff für Endbenutzer einzuschränken. Und in der Vergangenheit war diese Methode effektiv.

Neben der Konfiguration des Benutzerprofils mit eingeschränkten Funktionen steuerten Anwendungsmenüs, wie Benutzer auf Daten zugegriffen haben und wann sie Zugriff auf eine Befehlszeile hatten. Da IBM jedoch neue Schnittstellen öffnet, die Zugriff auf Daten und die Möglichkeit bieten, Remote-Befehle auszuführen, ist dieser Ansatz nicht mehr so solide wie früher.

76 Prozent der Benutzer wurde der Befehlszeilenzugriff entzogen und Sie können die meisten Befehle nicht über herkömmliche menübasierte Schnittstellen ausführen. 16 Prozent der untersuchten Benutzer haben sowohl einen Befehlszeilenzugriff als auch ein aktiviertes Profil, was ein sehr klares Risiko darstellt.

Einige Netzwerkschnittstellen erkennen die in einem Benutzerprofil konfigurierten Befehlszeilenbeschränkungen nicht an und müssen auf andere Weise gesteuert werden. Das bedeutet, dass Benutzer Befehle aus der Ferne ausführen können, selbst wenn Systemadministratoren absichtlich Vorkehrungen getroffen haben, um sie an der Verwendung einer Befehlszeile zu hindern.

Prüfung von Sicherheitsereignissen

IBM i kann wichtige sicherheitsrelevante Ereignisse in einem manipulationssicheren Repository speichern – dem Security Audit Journal (deutsch „Sicherheitsprotokoll“). Mit dieser Funktion können Unternehmen die Quelle kritischer Sicherheitsereignisse ermitteln, z. B. „Wer hat diese Datei gelöscht?“ oder „Wer hat diesem Benutzer *ALLOBJ-Berechtigung erteilt?“ Diese Informationen können den Unterschied zwischen der sofortigen Reaktion auf ein Sicherheitsereignis und der späten Entdeckung einer Sicherheitsverletzung nach einem erheblichen Schaden ausmachen. Die Herausforderung besteht darin, dass die im Security Audit Journal enthaltene Datenmenge groß ist und die Inhalte kryptisch sind. Die meisten IT-Mitarbeiter haben Probleme, die protokollierten Aktivitäten zu überwachen und zu verstehen.

16 Prozent der geprüften Systeme verfügen nicht über ein Audit Journal. 19 Prozent der Systeme arbeiten mit der Systemwerteinstellung QAUDCTL im Auslieferungswert von *NONE (Abbildung 10). Dies ist der Haupt-Ein/Aus-Schalter für die Überwachung. Er blockiert global die Protokollierung aller Ereignisse auf System- oder Objektebene, unabhängig von der Existenz des System Audit Journals. Das Festlegen von QAUDCTL auf *NONE deutet darauf hin, dass Administratoren die Auditing-Funktion gestartet, aber anschließend wieder deaktiviert haben oder sich möglicherweise nicht der Notwendigkeit einer zusätzlichen Konfiguration bewusst waren.

Wenn Unternehmen das Security Audit Journal aktiviert haben, ist unklar, wie viel Einblick ihnen die umfangreichen Daten bieten. Einige Softwareanbieter bieten Auditing-Tools an, die über die im Security Audit Journal geschriebenen Systemdaten berichten und diese überprüfen. Aber nur 25 Prozent der Systeme in dieser Studie haben ein erkennbares Tool installiert.

Virus- und Malware-Schutz

Die traditionelle IBM i-Bibliotheks- und Objektinfrastruktur gilt als sehr virenresistent, aber andere Dateistrukturen innerhalb des Integrated File System (IFS) sind anfällig für das Hosten infizierter Dateien, die dann im gesamten Netzwerk verbreitet werden können. In Anerkennung dieser Realität hat IBM vor einigen Jahren Systemwerte und Registry-Exit-Points geschaffen, um native Virenscans zu unterstützen.

Ein Unternehmen scannte IBM i zum ersten Mal auf Viren und war schockiert, fast 250.000 infizierte Dateien zu finden. Sollten Zweifel an der Notwendigkeit eines Virenschutzes bestanden haben, beweist dieses Beispiel, dass das Risiko real ist. Das Scannen von IBM i auf Viren und Malware wird immer beliebter, da Administratoren erkennen, dass IBM i Dateisysteme enthält, die nicht immun gegen Infektionen sind und unter bestimmten Umständen native Anwendungen und sogar IBM i selbst betroffen sein können.

Als die Server auf Antivirenkontrollen überprüft wurden, scannten 10 Prozent die Dateien beim Öffnen, was eine deutliche Zunahme gegenüber den Vorjahren darstellt. Das bedeutet, dass für die anderen 90 Prozent das Risiko besteht, dass interne Objekte betroffen sind oder eine Infektion auf einen anderen Server in ihrem Netzwerk übertragen wird (Abbildung 11).

Schlussfolgerung

IBM i hat sich einen Ruf als eine der Plattformen erarbeitet, die am besten geschützt werden können. Einer der großen Vorteile von IBM i besteht darin, dass in das Betriebssystem ausgeklügelte Tools zur Sicherung, Überwachung und Protokollierung integriert sind. Experten sind sich jedoch einig, dass IBM i-Sicherheit nur so effektiv ist wie die Richtlinien, Verfahren und Konfigurationen, die für ihre Verwaltung eingerichtet wurden..

In dieser Studie wurden eine Reihe gängiger Sicherheitsrisiken und Konfigurationsmanagementpraktiken hervorgehoben, die zum Schutz der Daten auf IBM i-Systemen angegangen werden müssen. Kein System wurde über Nacht angreifbar, und es ist auch nicht möglich, jedes Sicherheitsproblem an einem einzigen Tag zu beheben. Wichtig ist, irgendwo anzufangen und kontinuierlich Fortschritte in Richtung eines stärkeren Sicherheitsprofils zu machen.

Wenn Sie sich nicht sicher sind, wie Sie vorgehen sollen, beginnen Sie mit den obersten Prioritäten für die IBM i-Sicherheit:

• Systemsicherheit: Überprüfen Sie die QSECURITY-Ebene und stellen Sie sicher, dass sie 40 oder höher ist.
• Sicherheitsprüfung: Aktivieren Sie QAUDJRN und finden Sie ein Tool, dass Ihnen beim Interpretieren hilft.
• Netzwerkzugriff: Registrieren Sie zunächst die häufigsten Exit Points wie FTP und ODBC.
• Reduzieren Sie unnötige Benutzerberechtigungen.

Die meisten Experten empfehlen, mit einer Bewertung von Schwachstellen zu beginnen, um zu verstehen, wo Ihre Systemsicherheit heute steht und wie sie verbessert werden könnte. Sicherheitsexperten mit IBM i-Erfahrung und benutzerfreundliche Softwarelösungen stehen zur Verfügung, um dieses Projekt schneller und einfacher zu gestalten. Fortra bietet eine Reihe von Optionen, von einer sehr gründlichen Risikobewertung bis hin zu einem schnellen, kostenlosen Security Scan.

Sobald Sie alle Informationen haben, können Sie mit der Entwicklung eines Plans beginnen, der die Sicherheitsschwachstellen Ihres Unternehmens behebt. Und von da an wird die Sicherheit zum normalen Geschäft – kein Moment der Panik nach einem fehlgeschlagenen Audit oder einer Datenschutzverletzung.