Themenübersicht:
»Extremely Privileged IT Staff (EPIS)
»Security-Monitoring für z/Linux, z/VSE und z/VM
»Ihr z/OS Security & Compliance Monitoring ist zu teuer - und dabei noch unvollständig!«
»Nichterfüllung von PCI und ISO-27001/2 im Fall der Mainframe-Plattform«
Gerne diskutieren wir mit Ihnen alle Details der heutigen Gefährdungspotentiale und erfolgversprechende Lösungswege. Z.B. bei einer Präsentation in Ihrem Unternehmen, auf Wunsch auch mit einem z-Life-Hack.
Für eine automatische Benachrichtigung über Neuerungen in "IT-Security Aktuell" reicht eine E-Mail an it-sec-news@fedtke.com. Gleichermaßen bedanken wir uns für Hinweise und Themenvorschläge.
»Download-Bereich«
Lesen Sie mehr über »die 10 wichtigen Gründe weshalb die Standard-z/OS-Connectoren Ihres SIEMs nicht ausreichen!«
Lesen Sie mehr über unser innovatives EPIS-Konzept zur Identifikation und risikobezogenen "Bändigung" des sog. "Extremely Privileged IT Staff": Zeitschrift KES, Ausgabe 6/2010 (online: http://www.kes.info/aktuell/index.html -> "Epische Macht" in der linken Auswahlliste selektieren). Erfahren Sie, weshalb für EPIS-relevante Institutionen auch im Bereich des sog. Privileged-User-Monitorings neueAnforderungen zu erfüllen sind.
Ihr Unternehmen hat neben z/OS auch z/Linux, z/VSE und/oder z/VM im Einsatz und möchte diese Plattformen ebenso in ein übergreifendes Realtime-Security-Monitoring einbinden? Folgende Lösungswege stehen mit SF-Sherlock offen:
• z/Linux ohne z/VM+RACF-basierte Authentifizierung: Syslog-Scan aller z/Linux-Systeme durch eine automatische Weiterleitung an SF-Sherlock.
• z/Linux mit Authentifizierung via z/VM+RACF: Neben dem automatischen Syslog-Scan werden ebenso die SMF-Records des z/VM-RACF in das Monitoring eingebunden. Damit unterliegen auch die z/Linux-Logins der strengstmöglichen
Überwachung.
• z/VSE: Der Basic Security Manager (BSM), eine Standard-Komponente des z/VSE-Systemkerns, stellt eine Basis-Security bereit, die ab Version 4.1 auch RACF-kompatible SMF-Records erzeugt. Diese werden für eine Analyse an SF-Sherlock weitergeleitet womit auch das z/VSE seiner strengen Überwachung unterliegt.
• z/VM: RACF unter z/VM liefert entsprechende SMF-Records, die für eine Analyse an SF-Sherlock weitergeleitet werden. Damit unterliegt auch z/VM der strengen Überwachung.
Insgesamt steht einer vollständigen Überwachung der z-Plattform nichts im Wege.
»Für weitere Informationen zu SF-Sherlock«
Lesen Sie das "Ihr Security Monitoring ist zu teuer.pdf"
Für ein erfolgreiches Cross-Plattform-Monitoring werden vollständige, hochwertige und zeitnahe Daten benötigt. Die "Plug & Play"-Connection-Kits für SF-Sherlock und SF-NoEvasion erlauben Ihnen die schnelle und präzise Integration der z/OS-Plattform in Ihr Security-Monitoring, gleichgültig der verwendeten Lösung. Erst eine solche hochwertige Real-Time-Belieferung verleiht den verwendeten Detektions- und Korrelations-Mechanismen die notwendige Leistungsstärke im Kampf gegen negative Absichten, Angriffe und Betrug.
»Für weitere Informationen zu SF-Sherlock« und »SF-NoEvasion.
Lesen Sie das "Ihr Security Monitoring ist zu teuer.pdf"
Der Payment Card Industry (PCI) Data Security Standard und ISO-27001/2 repräsentieren zwei wichtige Richtlinien, an denen Finanzdienstleister ihre IT-Compliance u.a. ausrichten. Aus aktuellem Anlass möchten wir Sie zu Details der beiden Standards in Bezug auf ihre nachweisbare Umsetzung für die Mainframe-Plattform informieren. Für beide hat die Praxis mögliche Mainframe-spezifische Umsetzungsprobleme offen gelegt, aus denen Prüfer ggf. eine fehlende Compliance ableiten. Dies betrifft die
• PCI-Anforderungen:
| 10.5 | Secure audit trails so they cannot be altered, |
| 2.2.3 | Configure system security parameters to prevent misuse, |
| 6.2 | Establish a process to identify newly discovered security vulnerabilities ..., |
| 6.5.2 | Broken access control, etc. |
• ISO-27001/2-Anforderungen:
| A10.10.3 | Schutz von Protokollinformationen, |
| A11.5.4 | Verwendung von Systemwerkzeugen, |
| A12.6.1 | Kontrolle technischer Schwachstellen, etc. |
Kernprobleme der Mainframe-Plattform liegen u.a. in der fehlenden Erkennung und Abwehr dynamischer Manipulationen und von Malicious-Code-Abläufen in den Bereichen
|
a) |
Authentifizierung (Wechsel der User-ID, Berechtigungsdiebstahl, etc.), |
|
b) |
Protokollierung (Manipulation bzw. Unterdrückung von Audit-Log-Informationen, d.h. Bruch des Audit-Trails), |
|
c) |
Zugriffsschutz (Manipulation der Ressourcen-Zugriffsprüfung). |
Mit den Standard-Mitteln des Betriebs- und Security-Systems und evtl. ergänzender Standard-Tools werden obige Anforderungen nicht ausreichend erfüllt. Auch ergänzende Tools zur Bereitstellung von SMF- und Syslog-Daten in real-time reichen zur Lösung dieses Problems, d.h. zur Erfüllung obiger PCI- und ISO-Anforderungen nicht aus (für technische Details siehe auch nachfolgende Beiträge).
In der Erkennung und Abwehr dieser detailstarken Risiken liegen u.a. die umfassenden Alleinstellungsmerkmale der Realtime-Monitoring-Technologie SF-Sherlock. Eine solche Realtime-Technologie für das Security-Monitoring wird u.a. durch die ISO-Punkte A13.2.1 und A13.1.1 bzw. die PCI-Punkte 11.4, 11.5 und 12.9 gefordert.
»Für weitere Informationen zu SF-Sherlock.«
Es möge im ersten Moment "unsachlich" klingen, aber die Leistungsfähigkeit von Security-Monitoring-Lösungen bezieht sich zu einem hohen Grad auf "das Unsichtbare" in der IT, das es gilt transparent zu machen. Versteckte Sicherheitslücken, unbekannte und selbst dem Hersteller des Betriebssystems bzw. der Anwendung ggf. nicht bewusste Schwachstellen, Betrugsoperationen in einem nach außen scheinbar tadellosen operationellen Umfeld, all das gehört zu den Kernzielsetzungen und -herausforderungen des Security-Monitorings.
In diesem Punkt unterscheidet sich Security-Software eindeutig von anderen Software-Kategorien. Deshalb bedürfen diesbezügliche Entscheidungsprozesse auch einer besonderen und leicht abweichenden Behandlung. Neben dem Anspruch auf höchste Qualität und technische Tiefenschärfe, ist die Unabhängigkeit des Herstellers ein ebenso zentraler Aspekt. Denn nur unabhängige Security-Monitoring-Lösungsanbieter können frei und in gewisser Hinsicht "rücksichtslos" sämtliche Schwachstellen einer IT-Plattform adressieren, aufdecken, beseitigen und damit in die offene Diskussion bringen. Nur sie sind so frei, auf andere Aspekte des betroffenen Herstellerumfelds keine Rücksicht nehmen zu müssen, wie unter anderem Image und Sales der betroffenen Produkte.
Wie verhält es sich hinsichtlich des wichtigen Kriteriums Aktualität und Kompatibilität? Zwingt dieses Detail zur Lösung "aus einer Hand"? Es wird oft argumentiert, dass (nur) der Hersteller selbst am besten und schnellsten über Neuerungen in der gelieferten Software Bescheid weiß und damit nur in der Lage ist, die entsprechende Monitoring-Software aktuell zu liefern. Dies gilt insbesondere auf Betriebssystem-Ebene nicht. Hier stehen professionellen Software-Herstellern, auch aufgrund wettbewerbsrechtlicher Regelungen, alle notwendigen Informationen über neue Versionen und Releases rechtzeitig zur Verfügung, um die eigene Software fristgerecht dem Anwender aktualisiert bereitzustellen.
Fazit? Ein fehlender Wettstreit um die größtmögliche Erkennungs- und Erfolgsquote im Bereich Security-Monitoring führt immer zu Effektivitätseinbußen und damit zu einem weniger an Sicherheit auf der Nutzerseite, vergleichbar mit fehlender "Machtbalance" auf anderen Ebenen des Wirtschaftsprozesses. Wettbewerb ist deshalb auch in dem so wichtigen Bereich IT-Security Ihr Garant für beste Ergebnisse, Machtbalance und die Souveränität Ihres Unternehmens.
Die unternehmensinterne "Brisanz" bzgl. der Compliance-Überprüfung setzt "vielerlei Gedanken frei", um hier in keinem Fall "etwas falsch zu machen". Grundsätzlich gilt es, die mit den neuen gesetzlichen Auflagen regelmäßig stattfindenden Überprüfungen trotz des teilweise hohen Aufwands positiv zu werten. Der große Vorteil und Gewinn von SOX und anderer entsprechend konsequenzstarker Richtlinien liegt insbesondere in der Tatsache, dass die diversen "Controls" im Vergleich zu früher real gelebt werden müssen und dies ferner einer Nachweispflicht unterliegt.
Dies hat den Prozess über die Auswahl der einzusetzenden Instrumente in vielerlei Hinsicht versachlicht und vereinfacht, denn jedem Unternehmen steht der Weg zur Realisierung und Implementierung der Controls (Richtlinien) vollkommen frei. Die Spielregel ist einfach: Es besteht freie Wahl, eigene Lösung oder Fremdprodukt, und es zählt, was effektiv und nachhaltig wirkt! D.h. wichtig ist die nachweisbare Wirksamkeit und die effektive Anwendung.
WICHTIG: Für Ende September, Anfang Oktober planen wir unseren jährlichen hochkarätig besetzten IT-Security Event, bei dem auch das Thema "BSI-Grundschutz für Mainframe-Anwender" behandelt wird. Weitere Informationen finden Sie in der Rubrik »Veranstaltungen«
Erst seit ca. 2004 behandelt das Deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) auch die für die Mainframe-Plattform notwendigen Maßnahmen in seinem zentralen Werk, dem IT-Grundschutzhandbuch (www.bsi.bund.de). Kapitel 6.10 behandelt die z-Plattform und verweist auf entsprechende Unterabschnitte, die in transparenter Form die Grundmaßnahmen für eine sichere z-Plattform beschreiben.
Kernaussage ist die Forderung nach einer Realtime-Monitoring-Technologie zur Überwachung und Absicherung der Systeme gegen Manipulationen und Ausnutzen der möglichen z/OS-spezifischen Schwachstellen. Zwei Zitate stellen die hohe Bedeutung dieses Themas klar hervor: "... Praktisch unverzichtbar sind solche Detektionsmaßnahmen, wenn im Schadensfall sehr große Schäden bis hin zum Personenschaden zu erwarten sind. ..." und "... Einsatz eines Security-Realtime-Monitors für z/OS-Systeme, um Sicherheitsverletzungen schneller feststellen zu können. ..." (beide Textstellen stammen aus dem BSI-Grundschutzhandbuch Stand 2004, Abschnitt "M 6.67 Einsatz von Detektionsmaßnahmen für Sicherheitsvorfälle").
Das BSI belegt mit seinen Grundschutzanforderungen wie hochaktuell das Thema Mainframe-Security ist und untermauert, dass der Mainframe mit weiteren Maßnahmen gegen die heutigen Gefahren zusätzlich abgesichert werden muss. Die z-Plattform ist eine "ganz normale" Server-Plattform – geworden -, mit eben auch den "ganz normalen" Risiken - weniger SNA, mehr TCP/IP, nicht nur MVS, sondern auch UNIX System Services haben Folgen. D.h. Unternehmen mit erhöhtem Sicherheits- und Qualitätsbedarf benötigen über die Standard-Security hinausgehende Maßnahmen zur technischen Absicherung ihrer z-Plattform. Es ist hierbei wichtig zu wissen, dass ein Security-Realtime-Monitor nicht Auslieferungsbestandteil der z-Plattform ist. Fazit des BSI? Standard-Schutz reicht für z-Anwender mit erhöhtem Sicherheitsbedarf nicht mehr aus.
Welches sind diese Unternehmen mit erhöhtem Sicherheits- und Qualitätsbedarf? In Anbetracht der sich mit Mainframes verbindenden Investitions- und Betriebskosten sind eigentlich alle Mainframe-Nutzer betroffen, speziell natürlich Finanzdienstleister, kommerzielle Rechenzentren, Krankenkassen usw. Und welche Motivation, besser gesagt, welcher Verantwortungs- und Handlungsdruck besteht heute und künftig für derartige erhöhte Sicherheitsmaßnahmen? Ein großer, denn aus den neuen gesetzlichen Regelungen, wie Basel II, KonTraG, SOX, etc., können sich erhebliche "Unannehmlichkeiten" für die Unternehmen und auch deren Geschäftsleitung ergeben. Das neue Motto lautet "nicht wissen schützt vor Strafe nicht". Dies betrifft aber primär den bereits eingetretenen Schadensfall – wenn Entlastungsnachweise fehlen.
Aber auch bevor etwas passiert kann mangelnde Security teuer werden, vorangetrieben z.B. durch Basel-II. Dreh- und Angelpunkt ist das sogenannte "Rating" als konsolidiertes Maß für die gesetzliche Konformität, Professionalität, Stabilität und Vorsorge eines Unternehmens und dessen Prozesse. Die IT steht hierbei in doppelter Verantwortung und ist auch aus diesem Grund von besonderem Interesse. Zum einen basieren auf ihr die Business-Prozesse selbst womit die IT per se zur Risiko-Quelle wird. Zum anderen werden mittels IT Risiko-mindernde Maßnahmen umgesetzt, z.B. Konzepte zur Kontrolle und Beobachtung im Sinne der Risiko-Vorsorge und -Abwehr. IT-Security ist damit von zentraler Bedeutung und steht im besonderen Interesse der sog. Rating-Agenturen und Kontrollbehörden. Eines ist sicher, diese verfügen über sehr ausreichendes Know-how für alle Plattformen, auch für die "alten" Mainframes.
Der "Richtspruch" der Rating-Agenturen über Ihr Unternehmen drückt sich im sogenannten Rating aus. Das Rating entscheidet später beispielsweise über die Höhe der Kreditkosten – wenige Promille können hier große Beträge ausmachen. Der Grundgedanke ist, dass ein höheres Risiko durch einen "Zuschlag" berücksichtigt und kompensiert werden muss. Kurzum, für Unternehmen mit einem schlechteren Rating werden Kredite teurer, entsprechend Versicherungsprämien usw. Fazit? Fehlende Security kostet Geld, früher oder später.
Als Finanz-IT-Dienstleister – intern oder extern - fühlen Sie sich nicht angesprochen? Sie fragen sich, wie eine Bank ein Rating erhalten kann? Ist es nicht so, dass nur Banken ihre Kunden "raten" – und nicht umgekehrt? Alle Unternehmen unterliegen dem Rating, denn auch Banken sind Kreditnehmer. Ganz abgesehen von den gesetzlichen Auflagen und Kontrollinstanzen, wie die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), die eine laufende Bewertung der Banken betreiben.
Was kann und sollte für die z-Plattform gegen die Gefahr von Malicious Code and Exploits getan werden? Es gilt pro-aktiv ganzheitliche Maßnahmen zur Beseitigung und Kontrolle von Risiken aufzusetzen.
Technische Einzelmaßnahmen, selbst wenn realtime, stellen alleine keine ausreichende Maßnahme dar. Hierzu ein gutes Beispiel: kommerziell angebotene Systeme zum Life-Mitschneiden von (RACF-)SMF-Sätzen. Sie verfolgen ein gutes Ziel, reichen aber nicht aus, denn das ganze System muss übergreifend gegen Manipulationen geschützt werden. Ein einfaches Szenario untermauert diese Aussage. Manipuliert ein professioneller Angreifer seine Berechtigungen, wird er hierbei die Protokollierung mittels SMF-Sätzen gleich mit abschalten – dies ist nur ein Bit Mehraufwand. Schon gilt auch hier die alte Regel der Physik "von nichts kommt nichts" – keine Ursache, keine Wirkung -. Denn fehlende SMF-Sätze können auch in einer Life-Bewertung nicht realtime gemeldet oder für eine Reaktion genutzt werden.
In diesen Kontext fallen auch die quälenden Fragen der Malicious-Code-Thematik:
1) Was machen eigentlich all die Module (APF-)autorisiert laufender Fremd-Software?
2) Inwieweit können diese Programme für andere Zwecke missbraucht werden? Z.B. für derartige Aktionen wie das Unterdrücken und Deaktivieren der SMF-Protokollierung per dynamischer (Speicher-)Manipulation.
3) Welche undokumentierten sicherheitskritischen Funktionen befinden sich im Programmcode dieser Module, die Spezialisten mit entsprechenden Werkzeugen oder Praxiserfahrung aber bekannt sind?
4) Inwieweit können die eigenen Entwicklungsabteilungen autorisierte Module erstellen und nutzen?
Fragen über Fragen. Doch nur eines steht fest, kein z/OS-Anwender kann sie eindeutig beantworten, selbst wenn diese Software sauber mittels SMP/E installiert wurde. Fazit? Alle im System laufenden Prozesse müssen realtime auf "unsauberes Verhalten" überwacht werden.
Dieses Thema führt zu einem weiteren wichtigen rechtlichen Aspekt, und zwar die Anforderungen und Auflagen zur Ordnungsmäßigkeit und Nachvollziehbarkeit, speziell im Bereich der Buchhaltung und sämtlicher Finanzdaten. Sie fordern, kurz gesagt, die Unverletzbarkeit des Audit-Trails zwecks Vollständigkeit und Authentizität der Audit-Daten. Dies ist die Grundpflicht. Die neuen Pflichten zur Risiko-Vorsorge und –Abwehr fordern zusätzlich, dass diese vollständigen und korrekten Audit-Daten für diese Zielsetzung auch zeitnah ausgewertet und nicht nur zeitnah archiviert werden.
Welche Lösung schlagen wir vor?
Als Hersteller der in seiner ganzheitlichen Ausrichtung konkurrenzlosen z/OS-Realtime-Monitor-Technologie SF-Sherlock möchten wir Ihnen den erfolgreichen Weg der z/OS-Sicherheits- und Qualitäts-Automation in Vorschlag bringen, um die im IT-Grundschutzhandbuch gestellten Anforderungen nicht nur vollständig zu erfüllen, sondern im Sinne Ihres Unternehmens zukunftsweisend zu übertreffen. Neben dem Aspekt Sicherheit unterstützt SF-Sherlock gleichfalls das Ziel Verfügbarkeit, beispielsweise mit seiner IPL-Simulation sowie der Parmlib-Syntax- und Semantik-Prüfung und vielem mehr. Die von uns bereitgestellten Connection-Kits erlauben ferner die Integration von SF-Sherlock in plattformübergreifende Lösungen anderer Hersteller, wie Symantec, Tivoli, etc.
D.h. mittels SF-Sherlock können Sie sowohl die technischen Risiken beseitigen als auch notwendige automatisch arbeitende Kontroll- und Beobachtungskreisläufe im Sinne der anspruchsvollen gesetzlichen Auflagen erfolgreich realisieren. Beides stärkt das Rating und spart Kosten. In diesem Sinne bringt SF-Sherlock eine doppelte Wertschöpfung für Ihr Unternehmen.
Durch das Konzept der automatischen permanenten und ganzheitlichen Überwachung und das Plug&Play-Implementierungskonzept erreichen Sie dieses Ziel mit minimalem Zeit- und Kostenaufwand. Unser erprobtes Einführungskonzept wird Sie überzeugen.
Führende Banken, Versicherungen, Industrieunternehmen und IT-Dienstleister im Geltungs- bzw. Orientierungsbereich obiger BSI-Richtlinien und –Empfehlungen sichern ihre Mainframe-Plattform seit vielen Jahren mit SF-Sherlock erfolgreich ab. Unser Unternehmen und unsere Technologien verfügen über beste Referenzen. Fragen Sie uns.
»Für weitere Informationen zu SF-Sherlock.«
»z/OS-Penetration-Test zur Sicherheits-Ist-Analyse für eine
rechtliche und technische Absicherung.«
Das Thema Innen-Täterschaft ist bereits in seiner Diskussion äußerst delikat. In Kollegen und Mitarbeitern innerhalb der Firma Risiken auszumachen und diese zu kommunizieren ist keine schöne Aufgabe und zugleich rechtlich heikel. Dies ist mit ein Grund weshalb sich der Begriff "Intrusion Detektion" in seiner allgemeinen Bedeutung in den letzten Jahren so einseitig entwickelt hat. Intrusion Detection Systeme (IDS) wurden auf den Angriff von außen und zusätzlich vorrangig auf den netzwerkbasierten Angriff "reduziert".
Belehrt durch die Praxis bzw. Realität wird allgemein mehr und mehr anerkannt, wenn gleich auch nicht so ausgesprochen, dass eine Hauptgefahr in der Innentäterschaft liegt. Insiderwissen reduziert den Aufwand und die Hürden für einen erfolgreichen "Angriff" erheblich. Zweifellos ist es für den Außenstehenden wesentlich schwieriger, von außen in ein Unternehmen und darin an die richtige Datenquelle zu gelangen. Für einen Insider gilt es die Daten "lediglich" von bekannter Stelle nach draußen zu befördern.
Der relativ neu geprägte Begriff "Extrusion Detection" will genau diese reduzierte "IDS"-Begrifflichkeit durch eine Ergänzung der umgekehrten Angriffsrichtung komplettieren. Ziel eines "Extrusion Detection Systems" (EDS) ist es deshalb, Vorgänge und Ereignisse innerhalb der Firma zu verfolgen, um dem Thema Innentäterschaft entgegenzuwirken. Eine enge Nachbarschaft zum Auditing und zur Revision liegt vor.
Mit dem Aspekt "Prevention" werden insbesondere automatisch ablaufende technische Reaktionsprozesse verbunden – keine Frage, die eigentliche Prävention findet natürlich im Bewusstsein der Mitarbeiter und Verantwortlichen statt. Allgemein ist festzustellen, dass vor der technischen Prävention, d.h. der automatischen Reaktion, hoher Respekt besteht. Dies geht einher mit dem Thema Fehlalarme - "false positive" – und der damit verbundenen Gefahr, die Produktion aufgrund fehlerhafter Entscheidungen zu gefährden.
Das "logische Fallen"-Konzept von SF-Sherlock war von Anfang an auf beide Detection-Aspekte ausgerichtet, Intrusion und Extrusion, ferner Detektion wie auch optionale Reaktion. So werden beispielsweise Angriffe auf das System festgestellt, aber auch die "Flucht" wichtiger Daten nach "draußen", z.B. mittels FTP.
Die SF-Sherlock-Technologie zur Sicherheits- und Qualitäts-Automation ist
|
• |
ein Intrusion und Extrusion Detection und Prevention System, |
|
• |
Host-basiert, aber auch Netzaktivitäten (z.B. Firewall und TCP/IP) werden überwacht, |
|
• |
z/OS-spezifisch, jedoch werden nicht ausschließlich nur das Betriebssystem, sondern auch Anwendungen und Subsysteme spezifisch überwacht (z.B. DB2, LDAP etc.), |
|
• |
in der Lage SMF- wie auch alle Log-Daten auszuwerten, |
|
• |
mit notwendigen vordefinierten Angriffsmustern ("logischen Fallen") im Standard bereits ausgestattet und |
|
• |
mit eigenen Angriffsmustern bzw. installationsspezifischen Charakteristiken ergänzbar. |
Dieser ganzheitliche Ansatz unserer Sicherheits-Technologien garantiert Ihnen den maximalen Return-of-Invest und die höchste Sicherheit auch Ihrer Investitionen. »Für weitere Informationen zu SF-Sherlock.« Unsere Enterprise-Audit-Lösung »SF-RiskSaver« nimmt sich dem Thema Extrusion-Detektion und -Prevention plattformübergreifend an.
Mit den Begriffen "Buffer Overflow (Attacke)" und "Format String Attacke" wird allgemein eine Art Elementar-Risiko verbunden. Frei von ihrer Funktionsweise stehen beide für die Gefahr und Furcht, dass Anwendungen mit einer (IP-)Schnittstelle nach außen von dort angreifbar, verletzbar und missbrauchbar sind, indem ihnen gezielt "raffinierter" Input zugeführt wird, mit z.B. zu langen Strings, eingebetteten Steuerzeichen und Programmcode o.ä. Gemeinsam ist beiden Attacken das gezielte Überschreiben von Speicherbereichen durch trickreiche Spezifikation bzw. Übergabe von Parametern. Üblich ist ein Überschreiben bzw. Belegen des Speichers mit ausführbarem Maschinencode zwecks dessen Ausführung durch die angegriffene Applikation und damit unter deren – hohen – Berechtigungen. Z.B. ist der Missbrauch des Web-Servers und seiner hohen Berechtigungen durch Angriff einer Web-Applikation ein denkbares Szenario.
Technische Basis für den Angriff ist die Verwendung eines sogenannten Stapels (Stacks) als Zwischen- und Übergabespeicher durch die Runtime-Umgebung einer Anwendung - nicht zu Verwechseln mit dem TCP/IP-Stack. Allgemein dient der Stapel zur Übergabe von Parametern und zur Speicherung sog. Rücksprungadressen beim Unterprogramm- bzw. Routinenaufruf. Bevor ein Programm X eine Unterroutine Y aufruft und zu dieser verzweigt, werden die von Routine Y verlangten Argumente auf den Stapel "gelegt" (PUSH), von dem sich Routine Y diese dann "herunterholt" (POP). Entsprechend wird beim Aufruf von Y durch X die Rücksprungadresse – von Y zurück zu X - auf den Stapel gelegt. Bei entsprechender Schachtelung der Routinenaufrufe wächst der Stapel zur Laufzeit. Während der Intel-Stapel in Richtung einer kleineren Adresse wächst – von oben nach unten -, wächst der unten beschriebene "z-Stapel" zu größeren Adressen.
Der Stapel kann bereits auf Prozessor-Ebene durch dessen Design und entsprechende Instruktionen vorliegen, oder durch software-technische Nachbildung. Z.B. ist das Stapel-Konzept für die Intel-Prozessoren immanenter Bestandteil des Designs und wird auf Maschinencode-Ebene durch entsprechende Instruktionen (PUSH, POP, etc.) unterstützt. Ein eigenes Register, das Stapelregister, identifiziert den Stapel und dient zu dessen Adressierung.
Auf der z-Plattform wird der Stapel "lediglich" software-technisch nachgebildet - quasi emuliert. Der Speicher der z-Architektur ist ein großer linearer Speicher mit 32- oder 64-Bit-Adressierung; der Intel-Speicher ist dagegen segmentiert. Ein auf der z-Plattform laufendes C-Programm z.B. verfügt zur Laufzeit über einen entsprechenden Speicherbereich innerhalb dieses 32- oder 64-Bit-Adressraums, in dem es den Stapel abbildet. Ein Stapel-Pointer, der die aktuelle Spitze des Stapels identifiziert, bewegt sich mit der Nutzung des Stapels auf und ab, ganz analog zum speziellen Stapelregister der Intel-Prozessoren. Von der faktischen Wirkung und Funktion für ein laufendes Programm besteht kein Unterschied zwischen beiden Prozessor-Welten. Insgesamt wird der "z-Stapel" durch die Runtime-Umgebung des Compilers nachgebildet bzw. emuliert. Hier liegen zugleich Potentiale für eine zusätzliche Absicherung, indem die Runtime-Umgebung umfassende Plausibilitätskontrollen vornimmt. Von zentraler Bedeutung ist, dass auf der z-Plattform Programmcode im Stapel ausgeführt werden kann; es gibt dort nur "den einen" Speicher. Hier liegt seit neuestem ein Unterschied zur Intel-Welt. Zur Absicherung von Programmen gegen Stapel-basierte Schwächen verfügen die neuen Intel-Prozessoren über die Möglichkeit, die Ausführung von Programmcode im Stapel(-Speicher) zu verhindern. Damit wird eine Form des Angriffs verbaut, nämlich auszuführenden Programmcode als Aufrufargument zu übergeben.
Nun zu den beiden Attacken und ihrer Methode selbst. Beide basieren darauf, dass ein Programm bezüglich seiner erhaltenen Parameter von fixen oder maximalen Längen ausgeht und nicht abprüft, ob die übergebenen Argumente zu lang oder zu zahlreich sind, oder spezielle Formatzeichen beinhalten (z.B. "%n" o.ä.), die durch eine spezielle Interpretation durch das Laufzeitsystem (z.B. durch die printf-Funktion) eine Referenz außerhalb des eigentlich angedachten Speicherbereichs bewirken. Hierin liegt der Angriffspunkt, indem durch eine gezielte Übergabe "ungeeigneter, nicht verkrafteter" bzw. spezieller Argumente/Parameter ein gezieltes Abspeichern von Information erfolgt. Dies kann entweder zu einem vom laufenden Programm unbemerkten Überlauf des Stapel-(Speicher)s und damit voraussichtlich zum Absturz der Anwendung führen, oder bezweckt die Übernahme der Programmkontrolle. Für letzteres wird der Speicher gezielt mit Programmcode (Maschineninstruktionen, wie z.B. ein SVC-Aufruf o.ä.) überschrieben, und/oder die Rücksprungadresse in einen eigenen Programmcode "verbogen".
Wichtiges Zwischen-Fazit: Allgemein lässt sich festhalten, dass die primäre Schwäche gegenüber Buffer Overflow und Format String Angriffen die Anwendung bzw. Routine selbst ist, indem sie empfangene Eingaben nicht konsequent auf Plausibilität sowie Konformität und damit auf potentielle Gefahren hin überprüft. Es ist weniger der Prozessor und/oder das Betriebssystem. Im Fall von Eigenentwicklungen sollte hierauf konsequent durch Code-Inspektionen geachtet werden, die teilweise sogar automatisierbar sind. Bei Fremd- oder Open-Source-Software ist die Einflussnahme eingeschränkt und die Software muss "as is" zum Einsatz kommen.
Welche Möglichkeiten der Absicherung, z.B. von Web-Anwendungen, bestehen unter z/OS neben einer soliden Grund-Security mit z/OS-Standard-Mitteln? Neben einer Überwachung auf Manipulationen im Rahmen des Realtime-Monitorings besteht mit SF-Sherlock und seinem "logischen Fallen"-Konzept zusätzlich die Möglichkeit, eine Anwendung "zu kapseln". Da auf die grundsätzliche Schwäche einer bestehenden Anwendung nur bedingt oder gar nicht Einfluss genommen werden kann, muss die Anwendung in ihrer Außenwirkung eingestuft und abgeschirmt werden. Indem das "normale Verhalten" der Anwendung beschrieben bzw. erfasst wird, können Ausnahmen schnell und sicher aufgedeckt werden. Wenn beispielsweise ein Web-Server für den Kundenzugriff plötzlich auf die Gehaltsdaten und nicht mehr nur auf die für ihn relevanten Produktdaten zugreift, kann dies ein sicheres Indiz für einen möglichen Angriff sein. Das Kapseln von Anwendungen ist eine in der SF-Sherlock-Praxis erfolgreich angewandte Maßnahme. Kernüberlegung ist: Ziel jedes Angriffs ist die Erlangung hoher Berechtigungen und die anschließende Vornahme illegaler weitreichender Zugriffe oder Operationen. In diesem Missbrauchs-Kontext ist es gleichgültig, welche Angriffsmethode verwendet wird, Buffer-Overflow- und Format-String-Methode sind nur zwei mögliche Varianten unter vielen.
Insgesamt erreichen Sie mit dieser SF-Sherlock-basierten Überwachung eine zusätzliche hohe und solide Absicherung Ihrer kritischen Anwendungen.
Einen wichtigen Vortrag zu diesem Thema hat Herr Frank Breitschaft (GAI NetConsult GmbH) auf unserer SF-Sherlock User und Enterprise Security Konferenz 2004 gehalten. Er kann im Download-Bereich bezogen werden.
