Donnerstag, 11. Mai 2023

SAP Systeme absichern

Risiko = Bedrohnung x Verletzung x Konsequenz 

Der ehemalige General und NSA-Direktor Michael Hayden hat es auf einem SAP-CRM Kongress in Richtung der anwesenden SAP-Kunden direkt formuliert:

Jedes Risiko ist letztlich das Produkt aus einer Wahrscheinlichkeit ihres Eintretens, multipliziert mit den Kosten des Schadens, wenn sie eintritt.

Open Web Applikation Security Projekt

Die Organisation Open Web Applikation Sekurity Projekt (OWASP) beschreibt ihr Selbstverständnis in einem Wiki-Beitrag folgendermaßen:

„Das Open Web Application Security Project (OWASP) ist eine Non-Profit-Organisation mit dem Ziel, die Sicherheit von Anwendungen und Diensten im World Wide Web zu verbessern. Durch Schaffung von Transparenz sollen Endanwender und Organisationen fundierte Entscheidungen über wirkliche Sicherheitsrisiken in Software treffen können. An der OWASP-Community sind Firmen, Bildungseinrichtungen und Einzelpersonen aus aller Welt beteiligt. Innerhalb der Gemeinschaft werden frei verfügbare Informationsmaterialien, Methoden, Werkzeuge und Technologien erarbeitet.“

Eine Funktion , die jedes Jahr mit Spannung erwartet wird, ist die Top-10-Liste der in dem entsprechenden Jahr erkannten Schwachstellen von Webanwendungen genießt unter Sicherheitsexperten und Webentwicklern einen hohen Stellenwert. Für die neue Rankliste wurden über 500.000 Schwachstellen in mehreren Hundert Unternehmen und Tausend von Applikationen beobachtet. 2013 waren dies z.B. die folgenden (die Zahlen in Klammern zeigen die Vorjahresplatzierung):

1. Injection (1)
2. Broken Authentication und Session Management (3)
3. Cross-Site Scripting (XSS) (2)
4. Insecure direct Object References (4)
5. Security Misconfiguration (6)
6. Sensitive Data Exposure (7/9)
7. Missing Funktion Level Access Control (8)
8. Cross-Site Request Forgery (CSFR) (5)
9. Using Known Vulnerable Components(…)
10. Unvalidated Redirect and Forwards (10)

SAP-Sicherheit in der klassischen Sicht

Im Gegensatz zu früher stehen heute SAP-Systeme und SAP-Landschaften im Fokus der Cyber-Angriffe. Den hier findet man den „Schatz“ der Unternehmen in Form von Unternehmensdaten.

Bei der Umstellung auf die R/3 Architektur die aus einer klassischen 3-Tier-Landschaft besteht, also einen klassischen Client-Server-Umgebung. Und auf die basiert bis heute die SAP-NetWeaver-Architektur - auch wenn SAP HANA diese Welt nun wieder grundlegend verändert.

Tier 1: SAP-GUI-Client

Der Hauptzugang zu SAP-Systemen basiert in allen Systemen auf dem SAP GUI. Dieser Zugang basiert auf einem Rich-Client.Konzept, das ein proprietären Netzwerkprotokolle verwendet. Das Konzept ,das das SAP GUI verwirklicht , kommt ursprünglich aus der Terminal-Steuerung.

Aus Sicht eines Angreifers ist das SAP GUI sehr interessant. Zum einen bietet die auf dem Client liegende SAPINI-Datei einen hohen Informationswert, denn dort sind SAP-Systeme mit Adressen und Zielrouten hinterlegt. Zum anderen kann man sicher sein, das die Strecke vom Client zum SAP-System für diesen Desktop freigeschaltet ist.

Tier 1: Zugang aus dem Internet und Übergang ins Intranet

Dieses Netzwerksegment ist der Übergang vom Benutzer im anonymen Internet zum authentifizierten Internet-Benutzer und kennzeichnet auch die Grenze zum Unternehmensnetzwerk. Traditionall nennt man eine solche Zone auch Demilitarisierte Zone (DMZ), abhängig von der jeweiligen Architektur.

Für die Kommunikation zwischen SAP GUI und dem Anwendungsserver wurde das Dynamic Information and Action Gateway Protocol (kurz DIAG) entwickelt. Es ist ein proprietären Protokoll, dessen Spezifikation nicht veröffentlicht wurde - einige Details sind jedoch inzwischen bekannt geworden. DIAG übertragt binär Daten , die im Standard komprimiert sind, es findet jedoch ohne die zusätzliche Verschlüsselung per SNC keine Absicherung des Datenverkehrs gegen Sniffing statt.

Tier 2: Übergang von Intranet zur SAP-Tier

Der Übergang von Tier 1 (der DMZ) nach Tier 2 funktioniert in der Regel wieder durch eine Firewall, die das DMZ-Intranet gegen das interne Netzwerk, manchmal auch Campusnetzwerk genannt, abgrenzt. In Tier 2 liegen oft die Mitarbeiter-Systeme, auf denen dann auch der SAP Rich Client (SAP GUI) läuft. Aber auch externe Programme und nicht unternehmenskritische Anwendungen  können hier laufen. Aus dieser Ebene 2 werden dann die Verbindung zu den SAP-Systemen im inneren Tier 3 aufgebaut.

Tier 3: Die SAP-Systeme

Bis zur Einführung von SAP HANA hatte SAP zu Datenbanken eine ähnliche Haltung wie zu den Netzwerken. SAP wollte weitestgehend unabhängig von Datenbanken sein und implementierte nur eine Schnittstelle zu den Datenbanken hin und nannte diese Open SQL. Es war letztlich eine klassische Implementierung einer Datenbankschnittstelle, wie man sie auch im Bereich ODBC kennt, einem Protokoll, das letztlich von und zu Datenbanken redet.

Komponenten:

Schutz von SAProuter und SAP Web Dispatcher

SAProuter ist eine der ältesten Peripherie-Komponenten in der Welt der SAP-Kommunikation und war ursprünglich dazu gedacht, dem SAP-Support-Zugang zu den Kundeninstallationen zu ermöglichen.
Der Einsatzzweck hat sich im Laufe der Zeit deutlich gewandelt. Aus diesem Grund ist auch der Umfang der Sicherheitsthemen rund um den SAProuter mit den Jahren gewachsen.

Wann wird der SAProuter eingesetzt?

Der SAPRouter wird - neben der Rolle als Verbindung zu den Kundendiensten der SAP im SAP Help Portal - hauptsächlich zur Kontrolle und zur Protokollierung von Verbindungen von SAP-GUI.-Clients zu SAP-Servern eingesetzt. Hier ist es wichtig zu beachten, dass der SAProuter keine Funktion im Sinne einer Firewall oder als ein Paketfilter hat. Der SAProuter kann nur Verbindungen von und zu SAP-Systemen Verbindungen entweder zulassen (Allow) oder verweigern (Deny).

SAProuter und Secure Network Communications SNC

SNC ist in den letzten Jahren als Verschlüsselung auf Netzwerkebene immer wichtiger geworden, die Forderungen der Auditoren nach Verschlüsselung in Produktivnetzwerken sind immer häufiger in aktuellen Prüfberichten zu sehen.

Der SAP Web Dispatcher im SAP-Netzwerk

Der SAP Web Dispatcher steht zwischen dem Internet und Ihrem SAP-System und dient als eine SAP-spezifische Trennung von dem „Außen“ des Internets und dem „Innen“ einer Zone wie der Dermilitarisierten Zone (DMZ). Er ist ein Einstiegspunkt für HTTP-Requests an Ihr System, das aus einem oder mehreren SAP NetWeaver Application Servern besteht. In diesem Sinne ist der SAP WebDispatcher auch ein optionaler Terminator für HTTPS-Verbindungen. Als „Software-Web-Switch“ kann er Verbindungen abweisen oder annehmen und nimmt dann die Request-Verteilung für eine gleichmäßige Serverauslastung vor. Diese Last-Steuerung, die auch in einer klassischen SAP-Landschaft von spezifischen Load Balancern als Hardware-Appliance realisiert ist, kann hier softwareseitig realisiert werden.

Den SAP Web Dispatcher können Angreifer als Brücke verwenden, da hier SSL-Verbindungen terminiert sind und der SAP Web Dispatcher Zugriff auf die Backend-Systeme und SAP Gateway hat. Die Brücke ist ein Übergang, der es erlaubt , von einer gesicherten Kommunikation auf eine ungesicherte zu wechseln, ohne dass man selbst die verschlüsselte Verbindung auflösen oder terminieren muss. Wenn man beabsichtigt, den Netzverkehr unerlaubt mitzuschneiden, also zu sniffen, braucht man nur den Datenverkehr vom SAP Web Dispatcher zum SAP-System mitzuschneiden. Die verschlüsselte Verbindung davor kann man unangetastet lassen. Ähnlich dem SAProuter fungiert der SAP Web Dispatcher als Router und Load Balancer für alle angeschlossenen SAP-Systeme und adressiert diese meistens unverschlüsselt, das heißt ohne SSL-Zertifikate. Diese Verbindungen können auch gut mitgeschnitten , also gesnifft werden.

SAP-Prozesse und Dienste


Alle Applikationsserver eines SAP-Systems bilden eine logisch geschlossene Einheit Einheit. Daher müssen die Aufgaben der jeweiligen Server genau definiert werden. Die Aufgaben, die in einem SAP-System anfallen und die auf die einzelnen Applikationsserver verteilt werden müssen, werden Prozesse und Dienste genannt.

In einem SAP-System mit genau einem Applikationsserver werden diese Prozesse und Dienste von diesem einen Server ausgeführt. Wenn sich die SAP-Anwendung aus mehreren Applikationsserver zusammensetzt , werden sie auf die einzelnen Server verteilt. MIt Transaktion SM50 können Sie einsehen, welche Prozesse aktiv laufen.

Zu dern einzelnen Prozessen und Diensten gehören:

Dialogprozess - Der Dialogprozess nimmt die Anforderungen der laufenden Benutzersitzungen entgegen. Es sind mehrere Dialogprozesse pro SAP-System erforderlich. Auf jeder Instanz laufen mindestens zwei Dialogprozesse.

Ein Dialogprozess wird nicht genau einem Benutzer zugeordnet . Der Prozess nimmt immer genau eine Anforderung entgegen und wartet dann auf die nächste Anforderung, egal von welchem Benutzer sie ist. Der Dialogprozess wird von der jeweiligen Instanz mit Anforderungen versorgt. Ein Dialogschritt im SAP-System stellt genau eine Bildschirmmaske dar.

Verbuchungsprozess
Die meisten verändernden Zugriffe auf die Datenbank erfolgen asynchron. Das bedeutet , dass die Daten nicht direkt von einem Dialogprozess in die Datenbank geschrieben, sondern in Tabellen zwischengespeichert werden . Der Verbuchungsprozess übernimmt die Aufgabe , diese Tabellen auszulesen und die Daten in die Datenbank zu übertragen. Durch dieses Prinzip werden große Performanceverbesserungen erzielt.

Enqueue-Prozess/Enqueue-Server
Der Enque-Prozess stellt die Sperrverwaltung des SAP-Systems dar. Innerhalb eines SAP-Systems kann es nur einen einzigen Enqueue-Prozess geben, was häufig bei älteren ABAP-Systemen so konfiguriert wurde. Enqueue-Server kann er in einer eigenen Instanz installiert werden. Als Standalone-Enqueue-Server bildet er zusammen mit dem Message-Server die ASCS-Instanz (ABAP Server Central Services). Durch Einrichtung eines Enqueue Replication Servers kann er Hochverfügbarkeit ausgelegt werden.

Der Enqueue-Prozess verwaltet die Sperrtabelle. Bearbeitet ein Benutzer z.B.den Stammsatz des Debitors, wird in der Tabelle ein Eintrag vom Enqueue-Prozess auf die Anforderung eine negative Antwort. somit werden Inkonsistenzen in der Datenbank vermieden. Das Entsperren einer logischen Tabelle oder eines logischen Datensatzens übernimmt der Dequeue-Prozess.

Diese Sperre ist ein rein logische Sperre; es werden von diesem Prozess keine Tabellen in der Datenbank gesperrt. So ist es durch einen direkten Zugriff auf die Datenbanktabellen möglich, einen Datensatz zu ändern, der über das SAP-System durch den Enqueue-Prozess gesperrt ist.

Batchprozess
Der Batchprozess ist zuständig für die Hintergrundverarbeitung. Wiederkehrende Aufgaben, die keiner Dialogeingabe bedürfen, sollten im Hintergrund ausgeführt werden. Sie werden als Jobs eingeplant. Diese Jobs können von einem Benutzer ereignisgesteuert oder zu einem bestimmten Zeitpunkt ausgeführt werden. Auf jeder Instanz können mehrere Batchprozesse gestartet werden.

Message-Server
Der Message-Server ist für die Kommunikation der verschiedenen Instanzen untereinander verantwortlich. In jedem SAP-System gibt es genau einen Message-Server-Dienst, der auf der ASCS-Instanz (ABAP Server Central Services) läuft. Im Wesentlichen ist der Message-Server für das Routen von Mitteilungen zwischen den Servern verantwortlich. Bei diesen Mitteilungen kann es sich z.B. um das Starten von Batch-Jobs, das Starten einer Verbuchung oder um Enqueue- oder Dequeue-Prozesse handeln. Er übernimmt auch die Lastverteilung bei Anmeldung über SAP GUI und RFC mit Logon-Gruppen.

Gateway
Das Gateway (vormals SAP NetWeaver Gateway) übernimmt die Kommunikation zwischen Anwendungen auf verschiedenen SAP-Systemen oder zu Nicht-SAP-Systemen über das Protokoll Transmission Control Protocol/Internet Protocol (TCP/IP). Er ist auch zuständig für die Protokolle Remote Function Call (RFC) und Common Programming Interface for Communications (CPI-C). Es nutzt das Open Data Protocol (OData) und wird von allen Systemen benötigt, in denen SAP-Fiori-Applikationen und SAP-UI5-Oberflächen verwendet werden. Es ist somit die zentrale Komponente für die Anbindung eines SAP-Fiori-Frontend-Systems an ein SAP-S/4HANA-Backend.

Spool-Prozess
Der Spool-Prozess übernimmt die Verwaltung der Ausgabeaufträge eines SAP-Systems. Die Druckaufträge werden bis zur Ausgabe in den TemSe-Objekten (temporäre sequenzielle Objekte) zwischengespeichert. Die TemSe-Objekte können entweder in der Datenbank (unter Verwendung der RDBMS-Sicherheitsmechanismen) oder im Betreibssystem abgelegt werden. Es können beliebig viele Spool-Prozesse je Server gestartet werden.

Allgemeine Systemsicherheit

In der allgemeine Systemsicherheit fließen die Themen ein, die im Rahemen jeder Prüfung eines SAP-Systems zu betrachten sind.

Folgende Fragen können zum Thema allgemeine Systemsicherheit gestellt werden.

- Welches SAP-Release wird eingesetzt? Wie ist der aktuelle Stand der Support Packages?
- Existieren Vorgaben für die Einstellungen der Systemparamter?
- Entsprechen die aktuellen Paramaterwerte den Unternehmensverbände?
- Existieren Vorgaben für die Kontrolle der Parametereinstellungen nach Releasewechsel, Kernel-Updates usw?
- Wurden Änderungen an Parameterwerten nur von berechtigten Personen durchgeführt?
- Wurden Parameter sowohl im Instanz- als auch im Default-Profil gesetzt?
- Wurden für Parameter auf verschiedenen Instanzen unterschiedliche Werte gesetzt?

Montag, 8. Mai 2023

DevOps - NoOps - DevSecOps SRE aus der Sicht der Architektur Teil I

 DevOps

DevOps hat in den letzten Jahren stark an Bedeutung gewonnen, insbesondere in Unternehmen. Die Umsetzung von DevOps hat einige Fallstrike aufgezeigt. Der Grund dafür ist, dass die Unternehmen nicht in einer Struktur organisiert sind, die für DevOps geeignet ist. DevOps wird schwieriger wenn die Entwicklung von einem Softwarehaus durchgeführt wird und der Betrieb an einen Systemintegrator ausgelagert ist.

Die Vorteile von DevOps sind wie folgt:

Es bringt Geschäft , Entwicklung und Betrieb zusammen , ohne Silos.

Unternehmen können schneller auf die Anforderung des Marktes reagieren, da sie kontinuierlich Feedback erhalten

Die Produkte werden laufend verbessert und mit neuen Funktionen ausgestattet, anstatt die nächsten großen Versionen zu planen.

Durch die Automatisierung in DevOps-Pipelines können Unternehmen die Kosten für Entwicklung und Betrieb senken und gleichzeitig die Qualität ihrer Produkte verbessern.

SRE


- Der Betrieb ist ein Softwareproblem

Dies ist der Ausgangspunkt von SRE. Software wird sich ändern, aber der Betrieb muss stabil bleiben, damit die Dienste nicht unterbrochen werden. Das bedeutet, dass die Software belastbar sein und intensiv getestet werden muss.


Bei DevOps wird sehr oft Dev betont: Schaffung von Agilität durch Beschleunigung der Entwicklung.

Site Reliability Engineering (SRE) befasst sich sehr stark mit OPs. Wie überlebt OPs bei ständig steigenden Geschwindigkeit und Anzahl der Produkte, die DEV liefert? 

Die Schlüsselthemen von SRE sind Zuverlässigkeit, Skalierbarkeit, Verfügbarkeit, Leistung , Effizienz und Reaktion. 

Diese sind in sieben architekturrelevante Grundsätze integriert, die dem SRE Workbook entnommen sind:


NoOps

Ist es möglich, den IT-Betrieb ohne praktischen Einsatz durchzuführen? 

Forschungs-und Beratungsunternehmen wie Gartner und Forrester prognostizieren eine IT-Zukunft, die auf NoOps basiert. Die große Idee hinter NoOps ist, das buchstäblich alles automatisiert werden kann. Das bedeutet eine noch größere Rolle für KI und die so genannte heuristische Automatisierung. Wie kann ein Unternehmen zu NoOps übergehen, und welche Rolle spielt ein Architekt in diesem Bereich? 

Das werde ich in einem weiteren Post erörtern.

Die wichtigste Lektion, die wir lernen werden, ist, dass es bei NoOps nicht einfach darum geht, überhaupt keine Operation mehr zu benötigen.


In den vorangegangenen Teilen werden wir über eine Automatisierung von Entwicklung und Betrieb gesprochen haben, nun geht es darum Security mit zu automatisieren.

DevSecOps

Es integriert die Sicherheit in jeden Schritt der Entwicklung und der Freigabe an den Betrieb. DevSecOps umfasst das Testen, die Bereitstellung und die endgültige Auslieferung. In diesem Post werden sie erfahren, wie die Architektur aussieht und wie die Sicherheit in DevOps integriert werden mus.


Folgende Teile werden folgen

Teil II: DevOps Erklärungen und nähere Erläuterung

Teil III: SRE

Teil IV:Architektur von NoOps für Unternehmen

Teil V: Architektur von DevSecOps



Mittwoch, 3. Mai 2023

Resilienz von Systemen Teil IV - Durchsetzung und Verstärkung der Struktur

 Solange während des gesamten Lebenszyklus eines Systems immer wieder ideale Bedingungen erwartet werden, kann es sinnvoll sein , auf Lean Design zu setzen. Die Vorbereitung auf ungünstige Bedingungen (Eventualitäten) erfordert jedoch überschüssiges Material, Energie, Arbeitskräfte, Programmierung usw. Im besten Fall wird ein solcher Überschuss nie benötigt - er steht einfach still und verursacht nur Kosten.

Wenn bestimmte Funktionen geschäftskritischer sind, ist es ratsam, sich nicht ständig auf Best-Case-Annahmen zu verlassen, insbesondere wenn es externe Faktoren gibt, die nicht kontrolliert oder gar genau vorhergesagt werden können. Überschussstrategien berücksichtigen das Potenzial für ungünstige Bedingungen, auch wenn sie unsicher und schwer vorhersehbar sind. Es kann relativ sinnlos sein, in solchen Situationen nach wahrscheinlichen Ursachen zu suchen.

Genau wie die Reduktionsstrategien konzentrieren sich die Überschussstrategien auf Funktionalität und Ressourcen, die für den normalen Betrieb unter normalen Bedingungen nicht benötigt werden. Überschussstrategien sind in gewisser Weise das Gegenteil von Reduzierungsstrategien , da es bei ihnen nicht darum geht, das Vorhandene zu reduzieren, sondern hinzuzufügen, was bereits vorhanden ist und was in einer perfekten Welt ausreichend sein könnte. Hier geht es jedoch um die Fähigkeit , den Betreib auch unter Berücksichtigung von Evantualitäten fortzusetzen.

Überflüssige Strategien liefern nicht mehr Funktionalität und erhöhen nicht die Leistung, aber sie liefern Kernfunktionen unter mehr Bedingungen. Es sind „fette“ Strategien - das Gegenteil von „schlanken“ Strategien. Reduzierungsstrategien werden dort eingesetzt , wo das Potenzial zur Optimierung von Zuverlässigkeit und Wartbarkeit besteht; Überschussstrategien werden dort eingesetzt, wo es notwendig ist. Als weiterer Unterschied zwischen Überschussstrategien und Reduzierungsstrategien gibt es keine absolute Obergrenze für Überschussstrategien.Reduzierungsstrategien müssen aufhören, wenn die nackten Knochen der geforderten Funktionalität erreicht sind. Darüber hinaus ist die Reduktion konterproduktiv. Bei Überschussstrategien ist mehr immer besser. So ist beispielsweise die Hot-Standby-Redundanz besser als ein Ersatzteillager für jedes System, was besser ist als nur ein Ersatzteil pro Modell. Dreifache Redundanz ist besser als doppelte Redundanz; für die Ausfallsicherheit ist es besser, eine Million Testfälle für das Fuzzing zu verwenden als zehntausend und so weiter.

Dennoch haben Reduktionsstrategien und Überschusstrategien gemeinsam, dass es das Ziel ist, Lücken zwischen beobachteter und erforderlicher Systemkonfiguration zu schließen. Bei Reduktionsstrategien wird dies durch den Wegfall nicht benötigter Funktionalität erreicht, während bei Überschussstrategien durch Hinzufügen von Ressourcen und anwendungsneutraler Funktionalität für Zuverlässigkeit in Notfallsituationen. Da überschüssige Funktionen und Ressourcen im Normalfall nicht genutzt werden, sollte die Verfügbarkeit und Genaugkeit dieser Funktionen und Ressourcen regelmäßig über überwacht udn verifiziert werden. Das ist aus Sicherheitsgründen bekannt: Die Zuverlässigkeit einer Funktion, die nur einmal alle tausend Stunden ausgeführt wird, ist schwer zu beurteilen. Insbesondere prozedurale Überschüsse (z.B. Backup/Restore) sollten regelmäßig überprüft werden.

Überschussstrategien lassen sich in grundsätzlich in drei Kategorien einteilen, bezogen auf den Problembereich, den sie behandeln:

1. Fehler auf Systemebene und Spannungszustände

Diese Gruppe von Strategien zielt auf binäre und analoge Kontingenzen ab.

1. Erkennen und Behandeln von fehlerhaften Laufzeitdaten, Konfigurationsänderungen und Programmcode.

Diese Gruppe von Strategien zielt auf die digitale Kontingenzschicht ab.

1. Vermeidung unerwünschter Effekte aus unbestimmten Problemquellen


Belastbarer Code und Architektur

Der Begriff Resilienz im Rahmen des vernetzten Systems bezieht sich in der Regel auf die Fähigkeit, fehlerhafte oder anderweitig unerwartete Daten zu tolerieren. Bei diesen Daten kann es sich um Online-Daten handeln, die auf die Netzwerkschnittstellle des Systems treffen - sowohl deformierte als auch gut gebildete (aber vom Entwickler unerwartete), oder um korrupte Konfigurationsdateien, die beispielsweise durch versehentliche Fehlansprache des Netzwerks entstehen können.

—————————————————————————————————————————

Steckbrief


Zerbrechlichkeit beobachtet: Fehlgestaltete Daten und/oder Daten, die gut geformt, aber für die SUC unerwartet sind (z.B. leere UDP-Pakete, ICMP, Broadcast), können die Systemleistung und das Systemverhalten negativ beeinflussen. Das betrachtete System gilt auch dann als fragil, wenn seine Widerstandsfähigkeit unbekannt ist.

Strategie der Robustifizierung: Die Robustheit wird erhöht, indem die syntaktische Gültigkeit der Daten vor der Verarbeitung überprüft wird, indem Code zur Behandlung von Ausnahmen hinzugefügt wird und durch eine Systemarchitektur, die unerwarteten (wenn auch legitimen) Netzwerkverkehr toleriert.

Prinzip der Robustifizierung: Funktionsumfang der Limitübertragung (Anwendungsebene).

Ziel der Robustheit: Die Netzwerk- und Konfigurationsstabilität wird getestet und dokumentiert. Basierend auf Testergebnissen wird die Systemleistung nicht durch beschädigte oder unerwartete, nicht protokollierte Daten beeinträchtigt, die das vernetzte System und die Subsysteme betreffen.

—————————————————————————————————————————-

Resiliente Architektur bezieht sich auf eine Systemarchitektur, die nicht empfindlich auf gut geformte und legitime, sondern irrelevante - und damit unerwartete - Daten reagiert. Beispiele sind ICMP-Pakete , Broadcast-Pakete oder TCP-SYN-Pakete mit einer Datenlänge von Null. All dies sind typische Daten, die Netzwerk-Scanner übertragen können und die in modernen Netzwerken nicht als bösartig oder gefährlich gelten. System-Komponenten können Probleme haben, wenn sie von solchen Daten getroffen werden, nur aus Performance-Gründen (analoge Kontingenzschicht).
Dies gilt insbesondere für Produktarchitekturen, die die Verarbeitung von Netzwerkarchitekturen durchführen, die die Verarbeitung des Netzwerkverkehrs auf derselben CPU durchführen, die die Anwendung ausführt.



Robustifizierungsverfahren

Schritt 1. Dokumentiere, was du hast. Dokumentieren Sie für das betrachtete System die vorhandene Belastbarkeit. Definieren und verwenden Sie dazu geeignete Testwerkzeuge..

Schritt 2. Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System die Art der Belastbarkeit , die tatsächlich benötigt wird. Dies kann beispielsweise Anforderungen an ein ungestörtes I/O-Verhalten beinhalten, während die Netzwerkschnittstelle des Systems durch Broadcast-Stürme und Fuzzer belastet wird.

Schritt 3. Lücken identifizieren und schließen. Wenn möglich , erhöhen Sie die Belastbarkeit des betrachteten Systems. In vielen Fällen kann dies nur durch den Lieferanten erfolgen. Wenn dies nicht möglich, kann es notwendig sein, eine stark eingeschränkte Netzwerkumgebung zu beauftragen.

Schritt 4. Dokumentänderungen. Dokumentieren Sie die neue Systemkonfiguration.

Schritt 5. Streben Sie nach Beständigkeit und Nachhaltigkeit. Stellen Sie sicher, dass jedes neue identische oder ähnliche System von Anfang an die elastische Konfiguration oder das Produkt verwendet.

Codeausführung und Konfiguration Manipulationssteuerung/-Überwachung

Die Code- und Konfigurationskontrolle ist komplementär zur Systemhärtung. Obwohl das Ziel der Code- und Konfigurationskontrolle darin besteht, einzuschränken, welche Anwendungen auf dem Zielsystem ausgeführt werden können und wer Änderungen an Konfigurationsdateien vornehmen kann, wird eine zusätzliche (überschüssige) Logik installiert, um genau das zu kontrollieren. Es wird eine Überfunktionalität eingeführt , die Code und Konfigurationsdaten auf dem Zielsystem steuert, um sicherzustellen, dass nur legitimer Code ausgeführt wird und dass die Konfiguration weder versehentlich noch böswillig geändert wird.

—————————————————————————————————————————-

Steckbrief


Zerbrechlichkeit beobachtet: Keine Barriere verhindert, dass nicht autorisierte Software auf dem betrachteten System installiert und ausgeführt wird. Konfigurationsänderungen werden nicht auf Berechtigung geprüft. Das betrachtete System gilt auch dann als fragil, wenn es nicht dokumentiert ist, in welcher Weise Software auf die Installation und Ausführung beschränkt ist.

Strategie zur Robustifizierung: Einschränkungen bei Code- und Datenänderungen auf dem System in der Konfiguration verhindern, dass sowohl böswillige als auch versehentliche Änderungen verarbeitet werden.

Prinzip der Robustifizierung: Funktionsumfang der Limitübertragung (Systemebene).

Ziel der Robustifizierung: Auf dem betreffenden System dürfen keine nicht autorisierten oder nicht validierten Softwareprogramme, Konfigurationsdateien usw. Installiert und verarbeitet werden.

—————————————————————————————————————————-

Robustifizierungsverfahren

Schritt1. Dokumentiere, was du hast. Dokumentieren Sie für das betrachtete System die bestehenden Methoden der Codeausführung und der Manipulationskontrolle.

Schritt 2. Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System die Art der Codeausführung und die erforderliche Manipulationskontrolle.

Schritt 3. Identifizieren und schließen Sie die Lücken. Testen und installieren Sie zusätzliche Methoden zur Codeausführung und Konfigurationsverwaltung. Das Testen kann entfallen, wenn der Anwendungsanbieter die ausgewählte(n) Lösung(en) zertifiziert hat.

Schritt 4. Die Dokumentierung ändert sich. Dokumentieren Sie die neue Systemkonfiguration.

Schritt 5. Streben Sie nach Konsistenz und Nachhaltigkeit. Stellen Sie sicher, dass jedes identische oder ähnliche System die gewählte Methode der Code- und Konfigurationsverwaltung verwendet.

Kodierung und Verifizierung von Metainformationen für die End-to-End-Gültigkeitsprüfung

Resilience tut nichts bin Bezug auf gut geformte , legitime Daten, die aus dem Zusammenhang gerissen sein können, versehentlich an das falsche System gesendet wurden, versehentlich eine falsche Konfiguration angenommen haben oder böswillige Absichten haben. Solche Situationen können durch die Kodierung von Metainformationen leicht verhindert werden. Metainformationen können digitale Signaturen, Befehlsfolgenummern, Datenquelle- und Zielbezeichnung oder Bestätigungsmeldungen auf Anwendungsebene beinhalten.

—————————————————————————————————————————-

Steckbrief


Zerbrechlichkeit beobachtet: Aufgrund der geschichteten Architektur gängiger Netzwerkprotokolle können Metainformationen, die es dem empfangenden System oder der Anwendung ermöglichen würden, die Gültigkeit von Befehlen zu überprüfen, über verschiedene Schichten des Protokollstapels verteilt sein.

Dies kann dazu führen, das fehlerhafte Nachrichten von der Zielanwendung nicht erkannt werden können und, wenn sie verarbeitet werden, wahrscheinlich zu einem Cybertrip führen.

Strategie zur Robustifizierung: Die Robustheit wird erhöht, indem die Inhaltsvalidität von Firmware, Code, Befehlen, Parametern usw. Vor der Verarbeitung überprüft wird. Dies kann durch die Kodierung von Metainformationen erreicht werden.

Robustifizierungsprinzip: Funktionsumfang der Limitübertragung.

Ziel der Robustheit: Fehlerhafte (syntaktisch korrekte, aber falsche) Dateien und Nachrichten können durch die Überprüfung von Metainformationen erkannt und nicht verarbeit werden.

—————————————————————————————————————————-

Robustifizierungsverfahren

Schritt 1. Dokumentiere, was du hast. Dokumentieren Sie für das betrachtete System die vorhandenen Methoden zur Überprüfung von Code und Konfigurationsoptionen-Authentizität durch Metainformationen.

Schritt 2. Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System die erforderlichen Methoden zur Überprüfung der Code- und Konfigurations-Authenzität durch Metainformationen.

Schritt 3. Identifizierung und schließen Sie die Lücken. Wenn möglich, integrieren Sie bessere Methoden zur Überprüfung von Code und Authentizität der Konfiguration anhand von Metainformationen, wahrscheinlich durch den Wechsel zu einem anderen Produkt oder einem anderen Anbieter.

Schritt 4. Dokumentänderungen. Dokumentieren Sie die neue Systemkonfiguration

Schritt 5. Streben Sie nach Beständigkeit und Nachhaltigkeit.


Stellen Sie sicher, dass jedes neue identische oder ähnliche System die ausgewählte Methode zur End-to-End-Validätsprüfung von Code und Befehlen verwendet.

Kontextbezogene Einschränkungen der Kontrollbehörde (Eigensicherheit)

Kontextbasierte Einschränkungen der Kontrollbefugnisse ähneln rollenbasierten Berechtigungskonzepten. Der Hauptunterschied besteht darin, dass die Einschränkungen der Autorität nicht nur auf der Identität des Akteurs basieren (wie durch Authentifizierung und Zuordnung zu einer bestimmten Rolle bestimmt), sondern sich auch auf den Systemzustand erstrecken.

—————————————————————————————————————————

Steckbrief


Zerbrechlichkeit beobachtet: Cyber-befehlen können jederzeit die gesamte eingestellte Funktion ausführen, auch wenn die Ausführung der Funktion im gegebenen Zustand keinen Sinn ergeben würde oder völlig unsicher wäre. Das betrachtete System gilt auch dann als fragil , wenn es undokumentiert ist, ob der gesamte Funktionssatz unabhängig vom Systemzustand ausgeführt werden kann.

Strategie zur Robusitifizierung: Die Verhinderung von Betriebsarten, die nur zu unerwünschten Verhalten führen können, reduziert die Wahrscheinlichkeit von unerwünschten Eingaben, die zu unerwünschten Folgen führen , unabhängig davon, wer es getan hat (d.h ohne Berücksichtigung von Authentifizierung und Autorisierung).

Prinzip der Robustifizierung: Begrenzung des Übertragungsfunktionsumfangs.

Ziel der Robustheit: Das betrachtete System beschränkt die Kontrollbefugnis technisch auf Funktionen, die für die jeweilige Betreibsart oder den jeweiligen Systemzustand sicher und legitim sind. Der Fernzugriff kann nicht zu Prozessmanipulationen führen, die den lokalen Bedienern nicht bekannt sind, oder die das System in Betracht ziehen oder den kontrollierten Prozess in einen unsicheren Zustand bringen würden.

—————————————————————————————————————————

Robustifizierungsverfahren

Schritt 1. Dokumentiere, was du hast. Dokumentieren Sie für das betrachtete System alle bestehenden kontextbezogenen Einschränkungen der Kontrollbehörde.

Schritt 2. Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System alle erforderlichen kontextbezogenen Einschränkungen der Kontrollbehörde.

Schritt 3. Identifizieren und schließen Sie die Lücken. Beschränken Sie die Kontrollbefugnis auf der Grundlage des Kontextes, in dem sie erforderlich ist und nicht bereits erfolgt . In vielen Fällen kann dies nur durch den Lieferanten erfolgen.

Schritt 4. Dokumentänderungen. Dokumentierne Sie neue Systemkonfiguration.

Schritt 5. Streben Sie nach Beständigkeit und Nachhaltigkeit. Stellen Sie sicher, dass jedes neue identische oder ähnliche System die gewählte Methode zur Einschränkung der Kontrollbefugnis von Anfang an verwendet.


Sicherheitsvorkehrungen und Prozessüberwachung


Schutzvorrichtungen werden manchmal als „physikalisch-chemische Ausnahmebehandlung“ bezeichnet.
Es handelt sich um Kontrollsysteme, die sicherstellen, dass die Folgen von Störungen keine physischen Schäden verursachen oder Menschen verletzen.

Im besten Fall werden die Sicherheitsvorkehrungen nie aktiviert, was ein hervorragendes Argument für die Art der Überschussstrategien ist. Die Sicherheitsvorkehrungen sind gut verstanden, und ihre Verwendung ist in verschiedenen Konfigurationen und Anwendungen geregelt und vorgeschrieben. Sie werden heir erwähnt, um darauf hinzuweisen, dass Sicherheitssysteme ein weiterer Weg sind, die Robustheit eines Prozesses zu erhöhen.

——————————————————————————————————————————

Steckbrief


Zerbrechlichkeit beobachtet: Gefährliche Grenzwertüberschreitungen besagen, dass das Erreichen des geregelten Prozesses nur dann Manuel(wenn überhaupt) verhindert werden kann, wenn geschultes Personal die richtigen Verfahren zur richtigen Zeit durchführt. Das betrachtete System gilt auch dann als zerbrechlich, wenn nicht bekannt ist, ob es ausreichende Sicherheitsvorkehrungen gibt und wie sie funktionieren würden.

Strategie zur Robustifizierung: Die hier definierten Sicherheitsvorkehrungen sind Kontrollen, die die Auswirkungen von Out-of-Bound-Situation begrenzen, die unter normalen Bedingungen niemals auftreten sollten. In Anbetracht der Ungewissheit der Umweltbedingungen und des Schadenspotenzials bestimmter Auswirkungen außerhalb der Grenzen können Schutzvorkehrungen getroffen werden, um zu verhindern, dass solche Auswirkungen auftreten.

Prinzip der Robustifizierung: Ungültige Ausgabe sperren

Ziel der Robustheit: Möglicherweise gefährliche Prozesszustände außerhalb der Grenzwerte werden automatisch verhindert, letztendlich durch Auslösung und automatisierte kontrollierte Prozessabschaltung.

——————————————————————————————————————————

Gleichtaktausfälle 

Kurz gesagt , der Zweck eines digitalen Sicherheitssystems besteht letztendlich darin, den Prozess organisiert abzuschalten, wenn bestimmte Parameter ihre Schwellwerte überschreiten oder wenn andere gefährliche Ereignisse erkannt werden. Es muss sichergestellt werden, dass die Scherheitsvorkehrungen nicht durch einen Gleichtaktausfall des Systems beeinträchtigt werden können - Grund genug für einige, zu argumentieren, dass die jeweiligen Controller nicht das gleiche Netzwerk mit System-Komponenten teilen sollen.

Überwachung

Das Monitoring gibt es in zwei Varianten: Prozessüberwachung und Zustandsüberwachung. Während die erste Prozessvariablen und deren Schwellwerte überwacht, überwacht die zweite den Anlagenzustand und wird in der Regel als Baustein der vorbeugenden Instandhaltung implementiert.

Die Prozessüberwachung durch Anwendungen ist eine kostengünstige Alternative zu automatisierten Sicherheitsvorkehrungen. Solche Anwendungen haben die Möglichkeit, Schwellwerte für Prozessvariablen zu definieren, die bei Überschreitung Alarme auslösen. Im Gegensatz zu automatisierten Sicherheitsvorkehrungen beruht diese Architektur auf dem Vorhandensein, der Wachsamkeit und der Ausbildung von menschlichen Bedienern, die Korrekturmaßnahmen ergreifen können, wenn Alarme ausgelöst werden.

Die Zustandsüberwachung hingegen überwacht Anlagenparameter (z.B. Schmierpegel) und nicht Prozessvariablen.

Robustifizierungsverfahren

Schritt 1. Dokumentiere, was du hast. Dokumentieren Sie für das betrachtete System die bestehenden Sicherheitsvorkehrungen. 

Schritt 2. Dokumentieren Sie, was sie brauchen. Dokumentieren sie für das betrachtete System die erforderlichen Schutzvorrichtungen oder Überwachungs- und Alarmfunktionen. Eine Leitlinie könnte die Fehlerbaumanalyse sein.

Schritt 3. Identifizierung und schließen Sie die Lücken. Implementierung zusätzlicher Sicherheitsvorkehrungen oder Überwachungs-/Alarmfunktionen. In vielen Fällen kann dies nur durch den Integrator erfolgen.

Schritt 4. Dokumentänderungen. Dokumentieren Sie die neue Systemkonfiguration.

Schritt 5. Streben Sie nach Beständigkeit und Nachhaltigkeit. Stellen Sie sicher, dass neue identische oder ähnliche Systeme von Anfang an die gleichen Sicherheitsvorkehrungen treffen.

Redundanz

Praktisch jedes System, jeder Dienst oder Datensatz, der einem nicht-trivialen Zweck dient , erfordert eine Redundanzstrategie, denn null Redundanz bedeutet, dass die Funktionalität im Fehlerfall verloren geht und nicht wieder aufgenommen werden kann. Damit ist die Funktionalität dieses Systems nicht mehr verfügbar . Im wirklichen Leben sollte dies nur für nicht wesentliche Systeme gelten, die wenig Grund haben, in einer Umgebung überhaupt zu existieren. Systeme, die die erforderliche Funktionalität ohne Redunzstrategie bereitstellen, weisen auf ein schwerwiegendes Fragilitätsproblem hin.

Redundanz kann auf Datenverarbeitungs-, Datenübertragungs- und Datenspeicherressourcen angewendet werden. Im Wesentlichen beruht es auf der Duplizierung eines Systems oder von Teilen davon, um im Falle eines Ausfalls den Betrieb fortzusetzen. Es ist ein bekanntes Konzept im Engineering, das auch für Cyber gilt. 

——————————————————————————————————————————

Steckbrief


Zerbrechlichkeit beobachtet: Ein System, Dienst, Datensatz, eine Anwendung oder ein Transport hat keine Sicherung und kann im Fehlerfall nicht rechtzeitig und ausreichend ersetzt oder wiederhergestellt werden.
Das betrachtete System gilt auch dann als fragil, wenn nicht bekannt ist, wie und wann die Funktionalität nach einem Ausfall wiederhergestellt werden kann.

Strategie zur Robustifizierung: Bieten Sie eine Backup-Funktion für den Fall, dass ein System oder Teile davon aus irgendeinem Grund nicht verfügbar sind. Das Backup wird die Funktionalität des Originalsystems wiederherstellen (versuchen).

Prinzip der Robustifizierung: Angemessene Zuweisung von Ausführungsressourcen (binäre Kontingenzschicht)

Ziel der Robustheit: Es ist eine ausreichende Redundanz vorhanden, um sicherzustellen, dass das erforderliche System  jederzeit erreichbar ist.

——————————————————————————————————————————

Gleichtaktausfälle (Common Mode Failures)


Ebenso wie bei den Sicherheitsvorkehrungen sollten Redundanzstrategien die Analyse und Spezifikation von Ausfallmodi beinhalten, die vom System behandelt werden, und von solchen, die keine Gleichtaktausfälle sind. 

Robustifizierungsverfahren

Schritt 1. Dokumentiere, was du hast. Bestimmen und dokumentieren Sie für das betrachtete System und für die betrachtete Funktion oder Anlage die mittlere Erholungszeit. Verwenden Sie eine Schätzung , wenn keine Statistiken verfügbar sind. Je nach Systemtyp kann die MTTR-Bestimmung getrennt für Datenverarbeitung, Datenspeicherung und Datenübertragung durchgeführt werden.

Schritt 2. Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System und für die betrachtete Funktion oder Anlage die erforderliche mittlere Erholungszeit.

Schritt 3: Identifizieren und schließen Sie die Lücken. Installieren sie bei Bedarf zusätzliche Redundanz.

Schritt 4. Dokumentänderungen. Dokumentieren Sie die neue Systemkonfiguration.

Schritt 5. Streben Sie nach Beständigkeit und Nachhaltigkeit. Stellen Sie sicher, dass jedes neue identische oder ähnliche System von Anfang an identische Redundanzstrategien verwendet.

Derating (Leistungsreserven)

Zu den bekanntesten Robustheitsstrategien gehört die Zuweisung von Reserven und Leistungssicherheitsmargen. Im Normalbetrieb und unter normalen Umständen werden die Reserven niemals verbraucht  - definitionsgemäß sind sie der Überschuss, der über das hinausgeht, was für den Normalbetrieb erforderlich ist. Sollten die Bedingungen aus irgendeinem Grund nicht ideal sein, erlauben die Reserven den weiteren Betrieb.

——————————————————————————————————————————

Steckbrief


Zerbrechlichkeit beobachtet: Das betrachtete System oder seine Subsysteme verfügen über unzureichende oder unbekannte Ressorucenreserven; jede zusätzliche Belastung kann dazu führen, dass das System ausfällt. Das betrachtete System hielt es auch für fragil, wenn es undokumentiert ist, welche Art von Ressourcenreserven es gibt.

Strategie zur Robustifizierung: Verhindern des Erreichens oder Überschreitens unzulässiger Systemgrenzen durch Bereitstellen von mehr Ressourcen, als unter normalen Bedingungen benötigt würden, oder durch Verwenden von Ressourcen unterhalb bestimmter Grenzen.

Prinzip der Robustifizierung: Angemessene Ausführung der Ressourcenallokation (analoge Kontingenzschicht).

Ziel der Robustheit: Das betrachtete System und seine Subsysteme verfügen über genügend Ressourcenreserven, um während des gesamten Lebenszyklus des Systems, wie angegeben, unter jeder projizierten zusätzlichen Last voll funktionsfähig zu sein.

——————————————————————————————————————————

Robustifizierungsverfahren

Schritt 1. Dokumentiere, was du hast. Dokumentieren Sie für das betrachtete System und das betrachtete Leistungsmerkmal das bestehende Leistungsargument. Wählen und verwenden Sie dazu geeignete Überwachungswerkzeuge. 

Schritt 2. Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System und das betrachtete Leistungsmerkmal die tatsächlich benötigten Performance Margins, basierend auf Prognosen und Worst-Case-Szenarien.

Schritt 3. Identifizieren und schließen Sie die Lücken. Erhöhen Sie die Leistungsspannen des betrachteten Systems, damit sie den Anforderungen entsprechen oder die Belastung begrenzen.

Schritt 4. Dokumentänderungen. Dokumentieren Sie die neue Systemkonfiguration.

Schritt 5. Streben Sie nach Konsistenz und Nachhaltigkeit. Stellen Sie sicher, dass jedes neue identische oder ähnliche System die gewählte Methode der Zuteilung von Leistungsreserven verwendet.


Erster Teil:

https://einsiedlerkreps.blogspot.com/2023/04/resilienz-von-systemen.html

Zweiter Teil:

https://einsiedlerkreps.blogspot.com/2023/05/resilienz-von-systemen-teil-ii.html

Dritter Teil:

https://einsiedlerkreps.blogspot.com/2023/05/resilienz-von-systemen-teil-iii.html

Dienstag, 2. Mai 2023

Resilienz von Systemen Teil III - Struktur durchsetzen

 In vielen Systemen gibt es viele Funktions- und Zugänglichkeitsoptionen, die nicht erforderlich sind , um den Zweck des Systems zu erfüllen , und die keinen Mehrwert für.das betrachtete System darstellen. 

Reduzierungsstrategien können auch als Auferlegung einer Struktur auf das jeweilige System betrachtet werden. Die Verringerung der Variabilität (und Entropie) ist fast identisch mit der Schaffung und Ordnung. 

Die folgenden Bereiche sind Kanditaten für Reduzierungsstrategien:

- Funktionsweise: Die statischen Anwendungen ist es nicht sinnvoll, mehr Funktionalität als erforderlich zu verbesserten. Das Prinzip der Begrenzung des Übertragungsfunktionsbereichs kann hier angewandt werden und wird zu einem robusteren System führen.

- Zugänglichkeit: Es ist nicht von Vorteil, ein System für mehr Systeme und Benutzer als erforderlich zugänglich zu machen. Das Prinzip der Sperrung ungültiger Eingaben kann hier angewandt werden und führt zu einem robusteren System.

- Durchführung und Verfahren: Es ist nicht von Vorteil, identische Probleme auf unterschiedliche Weise zu lösen. Das Konsistenzprinzip kann hier angewendet werden und wird zu einem robusteren System führen.

Unnötige Anwendungen, Dienste und Funktionen entfernen (Systemhärtung)

Anwendungen und Dienste , die nicht auf dem eigenen Server installiert sind, können nicht abstürzen oder anderweitig die primäre (und oft auch nur) Aufgabe des Systems beeinträchtigen. Sie können keine Ressourcen (Speicher, CPU, Festplatte) verbrauchen, keine Daten übertragen , die für die Funktionalität nicht erforderlich sind, nicht von Malware zum absturtz gebracht werden können usw., mit dem damit verbundenen Potenzial für Nebenwirkungen für die Anwendung.Jede Softwareanwendungen, jeder Service und jede Schnittstelle und damit verbundene Netzwerkonnektivität bringt einen neuen Freiheitsgrad für das System mit sich und erhöht somit das Potenzial für die Fragilität. 

Zu den praktischen Problemen, die mit solchen nicht erforderlichen Freiheitsgraden verbunden sind, gehören der Verbrauch von CPU-Leistung und Speicher, die Netzbandbreite , die Verschwendung von Personalzeit und mögliche Implementierungsfehler, die zum Absturz des Hostsystems führen können.
—————————————————————————————————————————

Steckbrief:


Zerbrechlichkeit beobachtet: Das betrachtete System ist mit unnötigen Anwendungen und Diensten gefüllt, oder es ist nicht bekannt, ob unnötige Anwendungen und Dienste auf dem betrachteten System installiert und aktiviert sind.

Strategie zur Robustifizierung: Unnötige Anwendungen und Dienste erhöhen die Wahrscheinlichkeit einer unbefugten Systemnutzung , Implementierungsfehler und Nebenwirkungen (Speicher/CPU/Netzerschöpfung), ohne einen Nutzen zu bieten.

Das Entfernen oder Deaktivieren solcher Funktionen und Dienste reduziert das Potenzial für unerwünschte Nebenwirkungen.

Prinzip zur Robustifizierung: Funktionsumfang der Limitübertragung (Systemebene).

Ziel der Robustheit: Das betrachtete System ist frei von unnötigen Anwendungen und Diensten, oder solche Anwendungen und Dienste wurden deaktiviert.

—————————————————————————————————————————-

Anwendungsprogramme: Das durchschnittliche Computersystem ist mit vielen Anwendungsprogrammen bestückt, die keinen sinnvollen Zweck für den vorgesehenen Betrieb erfüllen. So sind beispielsweise viele Produktionsanlagen mit Spielen, Internet Relay Chat-Software, Bild- und Dokumentbetrachtern und Office-Anwendungen ausgestattet. Es besteht die Möglichkeit, dass solche unerwünschten Anwendungen während der Lebensdauer des Systems mehrere Sicherheitspatches auslösen.

Komponentensoftware und „offene“ Schnittstellen: Anwendungsprogramme sind nicht in monolithischen Blöcken implementiert. Stattdessen nutzt die durchschnittliche Anwendung mehrere Softwarekomponenten, die in der Regel als Dynamic Link Libraries implementiert sind. Manchmal können solche Komponenten Schnittstellen für Drittanwendungen implementieren, die eine signifikante Manipulation des Programm- und Prozessverhaltens ermöglichen.


Netzwerkdienste: Die Identifizierung nicht benötigter Netzwerkdienste ist schwieriger als das Auffinden unerwünschter Anwendungsprogramme, da diese Dienste keine Benutzeroberfläche haben. Sie laufen schweigend im Hintergrund . Der durchschnittliche Computernutzer hat keine Ahnung wie er überprüfen kann, welche Netzwerkdienste ausgeführt werden und was passieren würde, wenn dieser Dienst deaktiviert würde.

Nicht ausführbare Dateien: Viele Computersysteme sind mit unnötigen, nicht ausführbaren Dateien überladen, wie z.B.

- Nicht benötigte Dokumentation
. Obsolete Konfiguraitonsdateien
- Tabellenkalkulationsdaten-und Datenbankdateien

Diese Dateien könnten einmal zu entwicklungs- oder Testzwecken erstellt worden sein, wurden aber ohne triftigen Grund auf dem System belassen. Solche Dateien werden in der Regel regelmäßig gesichert. Jahre später kann die Wartung keine Ahnung haben, ob sie erforderlich ist.

Robustifizierungsverfahren


Schritt 1: Dokumentieren Sie, was Sie haben. Dokumentieren Sie für das betrachtete System die wichtigsten Anwendungsprogramme, Softwarekomponenten und Netzwerkdienste, die installiert und aktiviert sind. Der Lieferant kann hier eine große Hilfe sein. Bei neuen Systemen sollte eine Auflistung  der erforderlichen Anwendungsprogramme, Komponentensoftware und Netzwerkdienste Teil der vom Hersteller gelieferten Systemdokumentation sein.

Schritt 2: Dokumentieren Sie , was Sie brauchen. Dokumentieren Sie für das betrachtete System, welche Anwendungsprogramme, Softwarekomponenten und Netzwerkdienste benötigt werden und warum.

Schritt 3: Identifizieren und schließen Sie die Lücken. Entfernen oder deaktivieren Sie so viele unnötige Anwendungsprogramme, Softwarekomponenten und Netzwerkdienste , wie es sinnvoll ist. Bei neuen Systemen sollte diese Aufgabe vom Lieferanten oder Integrator übernommen werden.

Schritt 4: Dokumentänderungen . AktualisierenSie die Systemdokumentation, um die neue Systemkonfiguration zu berücksichtigen.

Schritt 5: Streben Sie nach Beständigkeit und Nachhaltigkeit . Übernehmen Sie die Änderungen konsistent auf identische oder ähnliche Systeme. Stellen Sie sicher, dass alle neuen identischen oder ähnlichen Systeme. Stellen Sie sicher, dass jedes neue identische oder ähnliche System von Anfang an die reduzierte Konfiguration verwendet. Machen Sie es zu einer gemeinsamen Politik, dass neue Systeme vor der Inbetriebnahme vom Hersteller oder Integrator verhärtet werden.

Bau eines strukturellen Systemmodells

Die empfohlene Strategie zum Aufbau eines strukturellen Systemmodells ist von oben nach unten, beginnend mit einem Modell des automatisierten Prozesses über Systeme und Prozesse, die an der Steuerung des Prozesses beteiligt sind. Die Modellierung des betrachteten Systems erfordert analytischen Aufwand.

Definition von Zweck, Umfang und Grenzen

Ein Systemmodell kann verschiedenen Zwecken dienen. Es kann für die Planung konstruiert werden, indem es ein nicht existierendes System beschreibt , das kurz vor dem Bau steht. Es kann so konstruiert werden, dass es die Struktur und Funktionalität eines bestehenden Systems dokumentiert. Nicht zuletzt ist es für die Robustheit eine interessante Aufgabe , das Modell eines bestehenden Systems mit seinem ursprünglichen konzeptionellen Modell zu vergleichen; Unterschiede können auf Systemeigenschaften hinweisen, die über mehrere Jahre „gewachsen“ sind und nun die Qualität der Systeme gefährden.

1. Zuverlässigkeit und Wartbarkeit des Systems

In funktionaler und prozessorientierter Sicht ist das betrachtete System nie in sich geschlossen. Es verbindet sich mit anderen Systemen und Prozessen. Die Grenzendes betrachteten Systems müssen in einem Systemmodell eindeutig festgelegt werden. Solche Schnittstellen oder Grenzen existieren in drei unabhängigen Bereichen, wie im Folgenden dargestellt.


Reduzieren oder Entfernen von universellen Softwareservices und Schnittstellen

Einige Softwareservices bieten viel mehr Funktionalität als andere. Im Namen von Flexibilität und Komfort sind sie leistungsfähiger. Aber weil sie so mächtig sind, sind sie auch oft das Ziel von Malware.
Paradebeispiele auf IT-Plattformen sind Services, die die Ausführung von Code ermöglichen. Wenn solche Dienste und Schnittstellen aktiviert sind, kann es schwierig oder unmöglich sein, die Variation des Ausgabeverhaltens zu begrenzen. So können beispielsweise einfache Parameteränderungen (absichtlich oder versehentlich) zu einem stark unterschiedlichen Ausgabeverhalten führen.
Der Nachteil ist, dass dort, wo mehr Funktionalität als erforderlich ist, die Möglichkeit besteht, dass sie tatsächlich an einem bestimmten Punkt eingesetzt wird - entweder als Teil eines schnellen und schmutzigen Workarounds oder versehentlich oder sogar bösartig.
Unabhängig davon, aus welchem Grund , zeigt die Erfahrung immer wieder , dass die de-facto-Nutzung von universellen Software-Diensten weit über das hinausgeht , was der Betreiber oder Planer beabsichtigt hatte.

—————————————————————————————————————————

Steckbrief


Zerbrechlichkeit beobachtet: Das betrachtete System Hoster Allzweckdienste und Anwendungsfall-Hooks, die eine beliebige Codeausführung ermöglichen, oder es ist nicht bekannt, ob das betrachtete System Allzweckdienste und Anwendungsbereich-Hooks Hoster, die eine beliebige Codeausführung ermöglichen.

Strategie zur Robustifizierung: Der Funktionsumfang eines implementierten Softwaredienstes sollte nicht größer sein als die erforderliche Funktionalität. Wenn ein universeller Softwaredienst durch einen eingeschränkten Software-Client ersetzt werden kann, ohne dass die erforderliche Funktionalität verloren geht, verringert sich das Variationspotenzial und damit die Fragilität.

Prinzip der Robustifizierung: Das Blockout-Prinzip (Funktionsumfang der Limitübertragung).

Ziel der Robustheit: Das betrachtete System Hoster keine universellen Dienste und Anwendungs-Hooks, die eine beliebige Codeausführung ermöglichen.

—————————————————————————————————————————

Das Reduzieren oder Entfernen von universellen Softwareanwendungen und - Diensten kann als Strategie ähnlich der Systemhärtung angesehen werden, bei der die Härtung auf einer funktionalen Ebene pro Anwednung oder Dienst und nicht auf Systemebene durchgeführt wird. In Situationen, in denen die betreffenden Schnittstellen aus praktischen Gründen nicht deaktiviert werden können, sollte der Schwerpunkt auf die Verringerung der Zugänglichkeit solcher Schnittstellen durch Netzwerkzonierung und -Authentifizierung gelegt werden. 

Robustifizierungsverfahren:

Schritt 1: Dokumentierte , was du hast. Dokumentieren sie für das betrachtete System die vorhandenen universellen Schnittstellen und Dienste, die installiert, aktiviert und genutzt werden. Der Anbieter oder Integrator kann hier eine große Hilfe sein.

Schritt 2: Dokumentieren Sie, was Sie brauchen Dokumentieren Sie für das betrachtete System, welche Schnittstellen und Dienste tatsächlich benötigt werden und warum.

Schritt 3: Identifizieren und schließen Sie die Lücken. Stellen sie fest, ob die erforderliche Funktionalität auch durch anwendungsspezifische Schnittstellen bereitgestellt werden kann.

Ersetzen Sie so viele universell einsetzbare Schnittstellen und Dienste durch anwendungsspezifische Schnittstellen und Dienste wie möglich.

Schritt 4: Dokumentänderungen. Aktualisieren Sie die Systemdokumentation, um die neue Systemkonfiguration zu berücksichtigen.

Schritt 5: Streben Sie nach Beständigkeit und Nachhaltigkeit. Stellen Sie sicher , dass jedes neue identische oder ähnliche System die heruntergerissene Konfiguration verwendet. Aktualisieren Sie die eingeschränkte Systemkonfiguration widerzuspiegeln.

Verwendung von anwendungsspezifische Schnittstellen mit geringster Funktionalität

Die Beschränkung der Funktionalität von Schnittstellen auf das, was für eine bestimmte Anwendung benötigt wird, ähnelt dem Konzept der rollenbasierten Autorisierung aus der IT-Sicherheit, mit dem großen Unterschied, dass es hier nicht darum geht, die Fähigkeiten von Human Users, sondern die von spezifischen Anwendungen einzuschränken. Eine Alternative zur Verwendung unterschiedlicher technischer Protokolle für so unterschiedliche Schnittstellen (auch Port-Partionierung genannt) ist daher die Implementierung von Authentifizierungsprotokolle- und Autorisiserungslogik, die es dem Zielsystem ermöglicht , die barrierefreie Funktionalität pro Client auf Basis von autorisierungsvorlagen einzuschränken. Bereiche, auf die man sich konzentrieren sollte, schließen die folgenden aus.

—————————————————————————————————————————-

Steckbrief


Zerbrechlichkeit beobachtet: Das betrachtete System bietet universell einsetzbare Schnittstellen, die von mehreren Anwendungen für unterschiedliche Zwecke verwendet werden, wobei einige Anwendungen nur einen Bruchteil der Funktionalität nutzen, verglichen mit dem, was technisch möglich ist. Das betrachtete System gilt auch dann als fragil, wenn nicht bekannt ist, ob Universalschnittstellen zur Verfügung stehen.

Strategie zur Robustifizierung: Bereitstellung von Schnittstellen mit geringer Funktionalität für verschiedene Anwendungsarten (Use Cases).

Prinzip der Robustifizierung: Das Blockout-Prinzip (Limit Input Variability).

Ziel der Robustheit: Das betrachtete System bietet verschiedene Schnittstellen für verschiedene Anwendungsarten mit geringster Funktionalität oder unterstützt die Authentifizierung/Autorisierung, um Anwendungsarten auf die geringste Funktionalität zu beschränken. Ein System eines bestimmten Anwendungstyps hat nicht die Möglichkeit, mit betrachteten System in einer Weise zu interagieren, die von einem anderen Anwendungstyp verwendet würde.

—————————————————————————————————————————-

Technische Schnittstellen: Engineeering-Schnittstellen werden für die Entwicklung der Steuerungslogik sowie für die Rekonfiguration und Steuerung verwendet.  

Schnittstellen für Benutzeranwendungen (schade, Qualitätskontrolle, MES): Bei den Schnittstellen für Anwenderanwendungen 

Robustifizierungsverfahren

Schritt 1: Dokumentiere , was du hast. Dokumentieren Sie für das betrachtete System die vorhandenen Schnittstellen zu IT-Anwendungen und Peer-Peripheriegeräten. Der Verkäufer oder Integrator kann helfen.

Schritt 2: Dokumentieren Sie was Sie brauchen. Dokumentieren Sie für das betrachtete System die Art der Funktionalität, die solche Anwendungen tatsächlich benötigen.

Schritt 3: Identifizieren und schließen Sie die Lücken. Ersetzen Sie so viele Universalschnittstellen durch anwendungsspezifische Schnittstellen mit geringster Funktionalität wie möglich. Dies ist in der Regel nur durch den Lieferanten möglich.

Schritt 4: Dokumentänderungen. Dokumentieren Sie die neue Systemkonfiguration.

Schritt 5: Streben Sie nach Konsistenz und Nachhaligkeit. Ähnliche Produkte anderer Hersteller verwenden ebenfalls anwendungsspezifische Schnittstellen oder Schränken die Schnittstellenfunktionalität durch Authentifizierung und Autorisierung ein.

Reduzieren von statischen offenen Dateiaustausch (Shared Folders)


Das Standard-Dateisystem hat sich kulturell als zentrales Paradigma für den Informationsaustausch etabliert. Informationen, die in Dateien gespeichert sind, können nicht nur auf transportable Medien kopiert werden, sie können auch auf einfache Weise strukturiert werden (durch die Verwendung von Ordnern), und die Struktur kann mit Hilfe von allgegenwärtigen Softwareanwendungen wie dem Windows Explorer einfach betrachtet und geändert werden.

Gemeinsame Ordner werden hier als statisch bezeichnet , da sie nicht transaktionsbasiert sind. Die Datei bleibt dort , nachdem sie an ihr Ziel kopiert wurde. Sie muss manuell gelöscht werden. Oft ist es das nicht. Gemeinsame Ordner sind nicht wegen der Funktionalität beliebt, sondern wegen der Benutzerfreundlichkeit. Die Funktionalität kann auch durch Transactional Dienste bereitgestellt werden. Eien weitere, nicht technische Lösung besteht darin, die Richlinie durchzusetzen, dass freigegebene Ordner regelmäßig jede Woche oder jeden Monat gelöscht werden.

Robustifikationsverfahren:

Schritt 1: Dokumentieren Sie, was Sie haben. Dokumentieren sie für das betrachtete System die vorhandenen Allgemeinen Mappen und deren Verwendung.

Schritt 2: Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System, wofür der Informationsaustausch über die allgemeine Ablage tatsächlich benötigt wird.

Schritt 3: Identifizieren und schließen Sie die Lücken. Ersetzen Sie so viele Vorgänge in gemeinsamen Ordnern wie möglich durch Transaktionsprotokolle und/oder erzwingen Sie Reinigungsrichtlinien.

Schritt 4: Dokumentänderungen. Dokumentieren Sie die neue Systemkonfiguration.

Schritt 5: Konsistenz und Nachhaltigkeit. Gemeinsame Ordner sind ein Problem für alle IT-Systeme. Versuchen Sie, freigegebene Ordner von so vielen Systemen wie möglich zu entfernen, und stellen Sie sicher, dass neue Systeme ohne freigegebene Ordner konfiguriert sind. Versuchen Sie zu verhindern, dass Sie IT-Anwendungen beschaffen oder entwickeln, die die Verwendung von Allgemeinen Ordnern vorschreiben.

Eliminieren von versteckten Hubs

Ein versteckter Hub ist ein Computersystem oder Dateisystem, das oft als vertrauenswürdiger Endpunkt angesehen wird, aber es ist in Wirklichkeit keins. Erste Beispiele sind technische Notebooks, die für den lokalen Zugriff auf sensible Systeme verwendet werden und dann zu anderen Standorten reisen, und Computersysteme,die über Modem oder Internet-VPN-Verbindungen für die Fernwartung mit sensiblen Systemen verbunden sind.

—————————————————————————————————————————

Steckbrief


Zerbrechlichkeit beobachtet: Das betrachtete System ist für Agenten zugänglich, die sich auf unkontrollierte Weise mit nicht vertrauenswürdigen und unbekannten Systemen verbinden können. Das betrachtete System gilt auch dann als fragil, wenn es nicht weiß, ob es versteckte Hubs gibt.

Strategie der Robustifizierung: Sicherstellen, dass der Zugriff Dritter auf das betrachtete System an einem bekannten und vertrauenswürdigen Fremdsystem endet.

Prinzip der Robustifizierung: Sperrung ungültiger Eingaben (aus technischen Systemen).

Ziel der Robustheit: Es gibt keine unkontrollierten Zugangspunkte zum betrachteten System. Von kontrollierten Zugangspunkten aus ist kein unkontrollierter Verkehr zu anderen Systemen möglich.

—————————————————————————————————————————-

Robustifizierungsverfahren

Schritt 1 Dokumentiere , was du hast. Dokumentieren Sie für das betrachtete System bestehende Systme, die als potenzielle Zugangspunkte dienen können. Die wichtigsten zu berücksichtigenden Systeme sind die Entwicklung von Notzbüchern und Systemen zur Fernwartung durch Fremdfirmen oder Mitarbeiter. Dokumentieren Sie, ob es sich um echte Endpunkte oder versteckte Hubs handelt.

Schritt 2. Dokumentieren Sie , was Sie brauchen. Dokumentieren Sie für das betrachtete System die potenziellen Zugangspunkte , die wirklich Endpunkte sein müssen. Dazu gehören in der Regel als potenziellen Access Points.

Schritt 3. Identifizieren und schließen Sie die Lücken. Entfernen Sie so viele versteckte Naben wie möglich. In vielen Fällen erfordert dies die Zusammenarbeit von Auftragnehmern und Lieferanten.

Schritt 4. Dokumentänderungen. Nehmen Sie die notwendigen Richtlinienänderungen in das bestehende Dokumentenmanagementsystem auf.

Schritt 5. Streben Sie nach Beständigkeit und Nachhaltigkeit. Kommunikation der Richtlinienänderungen an alle Personen, die von ihnen betroffen sind, einschließlich Dritter wie Auftragnehmer und Verkäufer, falls zutreffend. Regelmäßige Überprüfung der Einhaltung der Richtlinien, einschließlich Vor-Ort-Audits bei Auftragnehmern und Anbietern mit Fernzugriffsmöglichkeit.

Einschränkungen des Benutzerzugriffs und der Benutzerinteraktion


Menschliche Benutzer stellen eine der größten Herausforderungen für die Systemzuverlässigkeit dar, da die Bandbreite des menschlichen Verhaltens bei der Interaktion mit Systemen extrem hoch ist - von der vorteilhaften Fehlersuche bis hin zu absichtlichen bösartigen Angriffen. Menschen können ein System physisch zerstören, neue Software installieren, Konfigurationen ändern, 
Im schlimmsten Fall ist hier der uneingeschränkte Benutzerzugriff: Jeder kann alles tun.

—————————————————————————————————————————-

Steckbrief


Zerbrechlichkeit beobachtet: Der Benutzerzugriff und die Benutzerinteraktion sind uneingeschränkt; das betrachtete System oder seine Subsysteme sind für anonyme Benutzer zugänglich. Das betrachtete System gilt auch dann als fragil, wenn nicht bekannt ist, ob es für anonyme Benutzer zugänglich ist.

Strategie der Robustifizierung: Menschliche Nutzer stellen eine der größten Variationsquellen für Cybersysteme dar. Wenn sich die Benutzerinteraktion auf das im Hinblick auf die Berechtigung Notwendige beschränkt, reduziert sich der Variationsbereich und damit auch die Chance auf Cybertrips.

Prinzip der Robustifizierung: Blockierung ungültiger Eingaben (von menschlichen Akteuren).

Ziel der Robustheit: Das betrachtete System ist nur autorisierten Benutzern für Interaktionen zugänglich, die durch den Umfang der Berechtigung begrenzt sind. Alle Benutzer , für die ein Systemzugriff erforderlich ist, unterliegen einer schriftlichen Richtlinie oder SOPs. Der Zugang und die Interaktion werden durch technische Mittel (z.B. verschlossene Schränke , Authentifizierungsverfahren) in einem angemessenen Umfang eingeschränkt. Richtlinien und technische Einschränkungen sind prüfbar und werden regelmäßig überprüft. Richtlinienverletzungen werden aufgezeichnet und sanktioniert.

—————————————————————————————————————————-

Robustifizierungsverfahren

Schritt 1. Dokumentiere , was du hast. Dokumentieren Sie für das betrachtete System bestehende Systemzugriffsmöglichkeiten, Benutzerinteraktionsmuster und Anwendungsfälle, idealerweise gruppiert nach Rollen.

Schritt 2. Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System die tatsächlich benötigten rollenbasierten Benutzereingriffsmuster.

Schritt 3. Identifizieren und schließen Sie die Lücken. Installieren und Durchsetzen von Richtlinien, um den Benutzerzugriff auf das erforderliche Maß zu beschränken.

Schritt 4. Dokumentänderungen. Dokumentieren Sie die neue Richtlinie im entsprechenden Dokumentenmanagementsystem.

Schritt 5. Streben Sie nach Beständigkeit und Nachhaltigkeit. Kommunikation und Audit der neuen Richtlinie.

Reduzierung von Abweichungen in der Vorgehensweise (Standardarbeitsanweisung)


Wenn die Verantwortung für die Auswahl geeigneter Verfahren zur Erfüllung einer bestimmten Funktion dem lokalen Personal überlassen wird, kann vorhergesagt werden, dass die Verfahren mit erheblicher Variabilität durchgeführt werden. Diese Variabilität kann zu höheren Schulungskosten, höheren Auditkosten (wenn überhaupt möglich) und zu vorhersehbaren Fehlern bei der Versetzung von Mitarbeitern führen.

Daher ist es eine gute Idee , Unternehmensintegration Standards für wiederkehrende Aufgaben festzulegen, insbesondere in Bereichen, in denen offizielle Standards oder Best Practices unabhängiger Branchenorganisationen nicht verfügbar sind. Es ist einfacher , einen Aktionsplan zu verstehen und zu merken als zwei oder zwölf. Je mehr Lösungen es gibt , desto größer ist die Wahrscheinlichkeit, dass früher oder später jemand nicht mehr herausfinden kann, wie etwas gemacht wird.

—————————————————————————————————————————-

Steckbrief


Zerbrechlichkeit beobachtet: Für typische , häufig wiederkehrende Aufgaben wie Fernzugriff und Backup gibt es keine Standards. Solche typischen Operationen werden nach persönlichen Vorlieben oder gar nicht durchgeführt. Das betrachtete System gilt auch dann als fragil, wenn nicht dokumentiert ist, wie häufig wiederkehrende Aufgaben ausgeführt werden.

Strategie der Robustifizierung: Die Lösung ähnlicher Aufgaben mit unterschiedlichen Ansätzen ist eine unnötige Variation, die zu Problemen führen kann. Identische oder zumindest ähnliche Verfahren sind viel einfacher zu überprüfen.

Prinzip der Robustifizierung: Das Konsistenzprinzip

Ziel der Robustheit: Soweit möglich (d.h ohne Einschränkung der erforderlichen Funktionalität unter gegebenen Umständen), verwendet das Unternehmen dokumentierte, standardisierte und auditierbare Verfahren (SOPs), um identische oder ähnliche sich wiederholende Aufgaben wie Backup, Fernzugriff oder IP-Adressvergabe zu lösen. Die Normen/Dokumente ermöglichen es anderen Mitarbeitern oder Auftragnehmern, das Verfahren in gleicher Weise durchzuführen. Normen und Verfahren werden geprüft und Verstöße sanktioniert.

—————————————————————————————————————————-

Robustifizierungsverfahren

Schritt 1. Dokumentiere , was du hast. Überprüfen Sie für das betrachtete System die vorhandenen Standardarbeitsanweisungen. Dokumentieren sie Prozeduren, die von mehreren Personen unabhängig voneinander ausgeführt werden, oder die wiederholt oder beides ausgeführt werden. Ein guter Ausgagspunkt sind anwendungsunabhängige Verfahren, wie die oben genannten. Dokumentieren Sie eventualle Unterschiede in der Vorgehensweise für identische Zwecke. Validieren und dokumentieren Sie , ob bestehende Anweisungen von typischen Mitarbeitern ausführbar und auditierbar sind.

Schritt 2. Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System, wie viele verschiedene Verfahrungsvarianten für eine repetitive und/oder universelle Aufgabe benötigt werden oder ob eine Variablilität durch Anforderungen vorgeschrieben ist.

Schritt 3. Identifizieren und schließen Sie die Lücken. Definieren so wenig Anweisungen wie möglich und stellen Sie sicher, dass sie praktisch sind.

Schritt 4. Dokumentänderungen. Dokumentation der überarbeiteten oder neuen Anweisungen in einem geeigneten Dokumentenmanagementsystem.

Schritt 5. Streben Sie nach Beständigkeit und Nachhaltigkeit. Sicherstellen, dass die überarbeitete oder neue Anweisung von allen relevanten Akteuren , einschließlich neuer Mitarbeiter und Auftragnehmer, kommuniziert, verstanden und befolgt wird.

Reduzierung der Netzwerkbelastung


Die Netzbelastung eines Systems mit anonymen Agenten kann dazu führen, dass es nicht in der Lage ist, Cyberbetriebsparameter zu kontrollieren, da unbekannte Agenten ein System mit unvorhersehbaren Eingaben darstellen können, die von fehlerhaften Netzwerkrauschen bis hin zu gut geformten , aber illegitimen Befehlen reichen. Die Verringerung der Netzbelastung bedeutet also , die Variablilität der Eingaben über das Netzwerk zu reduzieren, einschließlich Cyber-Rauschen.

—————————————————————————————————————————-

Steckbrief


Zerbrechlichkeit beobachtet: Das betrachtete System ist für anonyme Agenten in einer offenen Entwicklung netzwerkfähig und kann Netzwerkverkehr zu beliebigen Systemen erzeugen. Das betrachtete System gilt auch dann als fragil, wenn die Netzzugänglichkeit undokumentiert ist.

Strategie der Robustifizierung: Je mehr Systeme es gibt, die innerhalb eines Netzwerks kommunizieren können, desto größer ist das Potenzial für unerwünschten und potenziell gefährlichen Netzwerkverkehr, eine bestimmte Komponente zu erreichen. Die Begrenzung der Netzwerk-Exposition reduziert dieses Potenzial.

Prinzip der Robustifizierung: Sperrung ungültiger Eingaben (aus technischen Systemen)

Ziel der Robustheit: Das betrachtete System kann nur von erforderlichen Anwendungen oder Diensten auf dem erforderlichen System erreicht werden, wobei sowohl Systeme als auch Anwendungen/Dienste durch Authentifizierung auf Anwendungsebene (falls erforderlich) verifiziert werden. Das betrachtete System kann andere Anwendungen oder Dienste nur über ein Netzwerk erreichen, zu dem eine Konnektivität erforderlich ist.

—————————————————————————————————————————-

Beispiele sind unter anderem:

Ein proadcast Sturm, der durch eine defekte Netzwerkschnittstellen ausgelöst wird (z.B. bei dem Vorfall Browns Ferry).

Eine legitime Anwendung im Netzwerk, die versehentlich auf das betrachtete System zugreift, weil sie falsch adressiert ist.

Malware im Netzwerk, die das betrachtete System durch einen DoS-Angriff, Wurmübertragung oder ähnliches beeinträchtigt.

Robustifizierungsverfahren

Schritt 1. Dokumentiere, was du hast. Dokumentieren Sie für das betrachtete System die vorhandenen Schnittstellen zu vernetzten Systemen (=Netzwerkereichbarkeit). Der Integrator kann hier eine große Hilfe sein.

Schritt 2. Dokumentieren Sie, was Sie brauchen. Dokumentieren Sie für das betrachtete System die tatsächlich benötigten Netzwerkkommunikationswege.

Schritt 3. Identifizieren und schließen Sie die Lücke. Reduzieren Sie so viele nicht benötigte Netzwerkverkehrspfade wie möglich durch Zugriffskontrolllisten, Zoning oder Firewalls auf Anwendungsebene.

Schritt 4. Dokumentänderungen. Dokumentieren Sie die neue Systemkonfiguration.

Schritt 5. Streben Sie nach Beständigkeit und Nachhaltigkeit. Stellen Sie sicher, dass jedes neue identische oder ähnliche System von Anfang an eine „least reachability“-Konfiguration verwendet.


Reduzierung von Abweichungen in Gerätetyp, Produktversion und Konfigurationsoptionen


—————————————————————————————————————————

Steckbrief


Zerbrechlichkeit beobachtet: Keine Norm schränkt die Möglichkeiten der Gerätebeschaffung und -Konfiguration ein.

Strategie der Robustifizierung: Die Verwendung verschiedner Geräte oder Konfigurationen für ähnliche Zwecke führt zu unnötigen Abweichungen. Es kann auch zu Versionskonflikten führen.

Prinzip der Robustifizierung: Das Konsistenzprinzip

Ziel der Robustifizierung: Im Rahmen des Möglichen und Sinnvollen, ohne die erforderliche Funktionalität unter den gegebenen Umständen einzuschränken, verfährt das Unternehmen eine möglichst geringe Anzahl verschiedener Geräte und Produktversionen von einer möglichst geringen Anzahl von Anbietern. Es gibt formale und detaillierte Spezifikationen (Standard) für die Konfiguration von Systemen, einschließlich Software und Middleware , wodurch die Konfigurationsmöglichkeiten auf die Anzahl beschränkt werden, die erforderlich ist, um die gestellten Anforderungen zu erfüllen.

—————————————————————————————————————————-

Robustifizierungsverfahren

Schritt 1. Dokumentiere , was du hast. Dokumentieren Sie für das betrachtete System, wie viele verschiedene Varianten der Geräterart für ähnliche oder identische Zwecke existieren.

Schritt 2. Dokumentieren Sie , was Sie brauchen. dokumentieren Sie für das betrachtete System, wie viele verschiedene Varianten der Equipmentart erforderlich sind.

Schritt 3. Identifizieren und schließen Sie die Lücken. Stellen Sie sicher, das am Ende der Lebensdauer das System und die Produkte , die den Schnitt nicht durchgeführt haben, durch die neue Norm ersetzt werden.

Schritt 4. Dokumentänderungen. Dokumentieren Sie die neue Systemkonfiguration.

Schritt 5. Streben sie nach Beständigkeit und Nachhaltigkeit. Integrieren Sie den neuen Standard in Ihre Beschaffungsspezifikation.



Erster Teil:

https://einsiedlerkreps.blogspot.com/2023/04/resilienz-von-systemen.html

Zweiter Teil:

https://einsiedlerkreps.blogspot.com/2023/05/resilienz-von-systemen-teil-ii.html

Montag, 1. Mai 2023

Resilienz von Systemen Teil II - Anforderungen und Systemspezifikationen

 Die Systemspezifikation spielt bei der Robustheit eine entscheidende Rolle. Noch mehr als ein Systemmodell hat die Erfüllung bestimmter formaler Merkmale einen großen Einfluss auf den Wert einer Spezifikation. Eine Systemspezifikation ist beispielsweise unerlässlich, um Designvariationen zu reduzieren. Ähnlich wie bei einer Richtlinie kann eine Spezifikation so vage sein, dass viele technisch unterschiedliche mögliche Systemdesigns noch spezifikationskonform sein können, was zu unnötigen Abweichungen führt. Was Compliance für Richtlinien ist, ist Konformität für Spezifikationen.

Die Kriterien für die Systemspezifikation sind wie folgt:

- Eine Systemspezifikation steht als schriftliches Dokument zur Verfügung.

- Subjekt-Experten können überprüfen, ob die angegebenen Funktionalitäten , Implementierungen, Konfigurationen und Ausführungsverfahren zu einer Lösung führen, die die angegebenen Anforderungen erfüllt.

- Die Anwendung der Systemspezifikation führt zu einer funktionierenden Lösung.

- Die Anwendung der Systemspezifikation durch verschiedene Personen führt zu identischen Ergebnissen.

- Die Feststellung durch verschiedene Personen, ob ein bestimmtes Systemdesign spezifikationskonform ist, führt zu identischen Ergebnissen.

- Die Systemspezifikation ist in das Änderungsmanagement integriert.

Die Rolle der Anforderungen an die Robustifizierung

Die Anwendung von robustifizierungsstrategien verändert ein System. 
Eine solche Änderung ist nur dann sinnvoll, wenn die Funktionalität des Systems nicht beeinträchtigt wird, und wenn die neuen Systemeigenschaften - hoffentlich eine bessere Robustheit unter ihnen - als Fortschritt angesehen werden können.

Robustifizierung ist eine technische Disziplin, die lehrt , wie man ein technisches Problem besser als bisher löst. Dies ist nur möglich, wenn ein klares Verständnis der erforderlichen Funktionalität vorhanden ist, was in der Regel nicht Teil eines Systemmodells ist. Ein gutes Systemmodell sagt zwar, wie ein bestimmtes System gestaltet ist, erklärt aber in der Regel nicht, warum dieses spezielle Design gewählt wurde. Die Unfähigkeit, die Gründe für bestimmte Systemdesign-Entscheidung zu identifizieren, ist dagegen ein Hinweis auf ein unvollständiges Systemverständnis.

Anforderungen unterliegen nicht dem Aufwand für die Robustheit, und die Robustheit versucht nicht zu überprüfen, ob dokumentierte Anforderungen angemessen sind. In konkreten Robustheitsprojekten ist dies ein wichtiges Thema für die Kommunikation mit den Endanwendern, die in der Regel befürchten, dass ihre Anforderungen nicht mehr erfüllt werden, nachdem ihr System von Dritten „verbessert“ wurde.

Spezifikationsartikel

Ein Pflichtenheft verbindet Anforderungen, Funktion, Implementierung, Konfiguration und Ausführungsverfahren.


Spezifikationsfehler #1: Die Spezifikation endet vorzeitig nach unten.
Dies lässt Raum für Variabilität, wobei verschiedene Funktionen, Implementierungen (Produkte) oder Verfahren (Konfigurationen) verwendet werden können, die alle Spezifikationskonform sind.

Die Anforderung nach schneller Fehlerbehebung wird oft durch Fernzugriff erfüllt. Es bleibt jedoch offen, wie der Fernzugriff gestaltet und ausgeführt werden soll. In realen Installationen wird daher ein Mix aus Dial-in-Modelms und Internet/VPN-Zugang mit unterschiedlichen Protokollen und Produkten verwendet.

Spezifizierungsfehler #2: Die Spezifikation endet vorzeitig nach oben.
Dies erfordert lediglich ein bestimmtes Produkt, eine bestimmte Technologie oder Funktionalität , ohne zu sagen, warum. Da Anforderungen und Funktionalität nicht detailliert beschrieben sind, gibt es wenig Möglichkeiten, die vorgeschriebene Verwässerung durch eine Alternative zu ersetzen, z.B. wenn das betreffende Produkt oder die betreffende Technologie veraltet ist und nicht mehr zum Kauf angeboten wird.

Der Spezifikationsbaum

Für jede Anforderung gibt es in der Regel mehr als eine Möglichkeit , ihre Funktion zu erfüllen. Für jede Funktion gibt es in der Regel mehr als eine Möglichkeit , sie zu implementieren. Und für jede Implementierung gibt es in der Regel mehr als eine Möglichkeit, sie in Bezug auf Konfiguration, Umgebung, Kontext usw auszuführen.
Daher ist die Spezifikation, einem Entscheidungsbaum ähnlich, bei dem jeder neue Zweig einen neuen Satz von Variabilität eröffnet.

Eine gute Spezifikation begrenzt die Anzahl der möglichen Funktionen, Implementierungen, Konfigurationen und Verfahren - idealerweise auf eine einzige Instanz in jedem Knoten, wodurch die Variabilität reduziert wird. Eine gute Spezifikation erlaubt keine beliebigen alternativen Funktionen, Implementierungen und Prozeduren. Im Idealfall sollte es nur eine mögliche spezifikationskonforme Implementierung geben, d.h. Nur einen bestimmten Pfad von der Anforderung (root) zur Prozedur (leaf).

Eine gute Spezifikation ermöglicht es aber auch, festzustellen, ob alternative Verfahren, Implementierungen und Funktionen, die robuster sein können als die ursprüngliche Lösung , die Anforderungen noch erfüllen. Dies ist eine wesentliche Grundlage für die Robustheit.

Spezifische Betreibsbedingungen

Die Betriebsbedingungen legen fest, unter welchen Bedingungen eine bestimmte Implementierung und/oder ein bestimmtes Verfahren getestet und zuverlässig ist und unter welchen nicht. 

Ressourcenanforderungen und Abhängigkeiten

Die Spezifikation muss alle Ressourcen identifizieren, die von der Systemumgebung bereitgestellt werden müssen, damit das System wie angegeben funktionieren kann.
Zum Beispiel, wenn es einen Bedarf gibt an

- Ein DHCP-Server, DNS-Server oder NTP-Server, der über das Netzwerk zugänglich ist.
- Ein bestimmtes Produkt eines Drittanbieters, wie beispielsweise eine Datenbankmaschine.
- Eine bestimmte Softwarekomponente , wie z.B. eine DLL in einer bestimmten Version.

Damit das System funktioniert , höchstwahrscheinlich mit speziellen Konfigurationseinstellungen, muss dies dokumentiert werden.

Betriebsgrößen: Bedingungen , die für eine ordnungsgemäße Ausführung zu vermeiden sind.

Jedes technische System hat Betriebsgrenzen, über die hinaus die Funktionalität beeinträchtigt ist, und Betriebsvoraussetzungen, die erfüllt sein müssen, damit das System funktioniert. Der Planer und Implementierer des Systems erwartet, dass das System innerhalb dieser Grenzen betrieben wird. Leider bedeutet dies nicht, dass solche Grenzwerte, die genauso real sind wie ihre elektrischen Gegenstücke, zwangsläufig ordnungsgemäß dokumentiert werden müssen.

Variation sind nicht dasselbe wie ungültige Eingaben, Stress und Fehler.
Fehler und Störungen sind Verstöße gegen vorgegebene Parameter. Wenn keine Spezifikation existiert , kann sie nicht verletzt werden - dennoch versagen reale Systeme auch ohne Spezifikation, sie können nicht versagt werden - dennoch versagen reale Systeme auch ohne Spezifikation aufgrund einer de facto-Verletzung von Betriebsbedingungen.

Ein System ohne vorgegebene Betriebsgrenzen ist fragil, da die Leistung des Systems unter bestimmten Bedingungen nicht vorhergesagt oder garantiert werden kann.


Erster Teil:

https://einsiedlerkreps.blogspot.com/2023/04/resilienz-von-systemen.html

Freitag, 28. April 2023

SAP Data Intelligence - Ein möglicher wichtiger Part in der Systemlandschaft

 Ich beschäftige mich ja schon seit einiger Zeit mit der Integration von Systemen , hier geht es aber um den Fluss von Daten. Das Thema der Daten in einer vernetzten Firma ist in aller Munde und einige Softwarehersteller bieten ihre Lösungen an.

SAP führte eine neue Plattform für die Verarbeitung komplexer Datenmengen in Echtzeit ein um für zukünftige Anforderungen ausgerichtet zu sein.

Für SAP war mit Sicherheit die Einführung von SAP HANA einer der größten Meilensteine. Sie bildet die Grundlage für die heutigen Möglichkeiten zur Verarbeitung von Informationen - neben einem höheren Erkenntnisgewinn führt das auch zu einer höheren Komplexität der Verarbeitung und Bereitstellung von Daten.

Für SAP - Abteilungen gewinnen die Fragestellungen immer mehr an Bedeutung:

- Welche Muster und Zusammenhänge lassen sich pro Datenquelle sowie quellübergreifend identifizieren? 

- Können auf Basis der Erfahrungen aus der Vergangenheit gegebenenfalls auch Aussagen über zukünftige Fehler getroffen werden?

- Können daraus resultierend vorbeugende Wartungsmaßnahmen eingeplant , ausbleibende Ausfälle berücksichtigt oder absehbare Kostensteigerungen eingeplant werden?

SAP Data Intelligence verfolgt einen ganzheitlichen Lösungsansatz für all diese Anforderungen.

Durch die Leistungsfähigkeit von SAP Data Intelligence verschwinden Systemgrenzen, und neue Möglichkeiten der übergreifenden Informationsbereitstellung und Zusammenarbeit können erschlossen werden.

Zukunftsgerichtete Organisationen haben bereits bei der Einführung von SAP HANA die Potenziale identifiziert und damit begonnen, die Geschwindigkeitsvorteile von In-Memory-Systemen nutzbar zu machen.

Was ist SAP Data Intelligence?

Die vier großen Leistungsfelder sind laut SAP:

- Data Pipelining und Prozessierung

- Datenorchestrierung und Monitoring

- Data Governance

- Data Science


Diese Platform lohnt sich im Auge zu behalten und in die Systemlandschaft einzuplanen.

Ich werde sicher noch mal was schreiben um auf Details näher einzugehen.