Wenn ein Anwender eine Fehlfunktion feststellt, kann es dafür verschiedene Gründe geben, so können Fehler des Anwenders selbst, Cybervorfälle oder Fehler im System zu Problemen führen. Bei realistischer Betrachtung der komplexen Umgebung, in der heute gearbeitet wird, müssen Fehlfunktionen in den Systemen nicht immer auf einen Cybervorfall zurückzuführen sein. Denn bei jeder Software sind auch ganz "normale" Fehlfunktionen möglich.
Das kann verschiedene Gründe haben, hier einige Beispiele:
Alterung
Jede Lösung wird auf einen gewissen Zweck hin und mit gewissen Umgebungsbedingungen definiert, die Anforderungen gehen in die Planungen für die nötige Architektur ein, auf der die final in Betrieb genommene Lösung aufbaut. Da sich das IT-Umfeld durch neue Anforderungen, Technologien, Plattformen usw. ständig ändert, sind laufend Updates und Anpassungen nötig, die ggf. nicht die geplante Architektur unterstützen oder dank zahlreicher Workarounds die Systemlast und Zugriffszeiten oder die Komplexität erhöhen und damit die Fehleranfälligkeit. Und Updates sind für ältere Lösungen, die in der Praxis (z. B. Maschinensteuerungen auf Basis Windows 95) noch im Einsatz sind, gar nicht mehr verfügbar. So steigt im Verlauf der Nutzung der Anpassungsdruck, die Lücke zwischen realem und erforderlichen System wächst, die es zu schließen gilt.
Dabei wird durch Aufschieben von Maßnahmen zur Sicherung und Erhöhung technischer Qualität die Softwareentwicklung nicht beschleunigt, sondern verlangsamt, der Aufwand der Anpassungen steigt, man spricht hier vom „Technical Debt“. Diese laufenden Anpassungsaufwende werden gerne knapp kalkuliert oder Änderungen werden – je nach Dringlichkeit – verschoben und landen irgendwann auf der „To do“ Liste weit hinten (und bleiben dort, solange nichts passiert). Es ist meist eine Frage des Kompromisses zwischen Kosten, Zeit, mangelnder Aktualität oder Stabilität (langfristig unveränderte Lösungen sind meist die stabilsten). Daher ist das Risiko der geringeren Stabilität oft der zentrale Grund, mit Änderungen so lange wie möglich zu warten.
Versteckte Fehler
Durch Änderungen können Fehler auch erst auftauchen, die zwar vorhanden sind, aber nie aufgefallen sind. Denn wenn ein Codesegment zwar entwickelt, aber dann inhaltlich doch nicht gebraucht und daher auch nicht adressiert oder genutzt wurde, wird das Segment aus Aufwandsgründen in der Entwicklung nicht immer gelöscht. Aber eben auch nicht getestet!
Erst wenn im Rahmen einer Änderung die bisher nicht adressierten Codebereiche angesprochen werden, wird der dort liegende Codierfehler transparent. Ohne erneuten Test mit angepassten Daten und Szenarien wird der Fehler oft erst in der Praxis entdeckt.
Testmängel
Im Rahmen jeder Entwicklung werden Tests durchgeführt, die auf Szenarien und Testdaten aufbauen. Wenn dann z.B. Grenzwerte für Eingabedaten nicht umfangreich und professionell getestet werden, fällt der Fehler erst spät auf, wenn ein Feld zufällig mit dem falschen Wert befüllt wird.
Beispiel: Eingabefeld „Stückzahl“ wird nur auf numerische Werte von 1-999 und ganzzahlige Werte definiert, aber nicht korrekt programmiert (Zahlen unter 1 oder über 1000 sind nicht ausgeschlossen, alphabetische Zeichen nicht ausgeschlossen, Negativdefinition nicht vorhanden). Bei Fehleingaben fällt das ggf. erst später in der Praxis auf.
Mit Praxisbeispielen aus dem Bankenbereich wartet hierzu ein Artikel auf:
Fazit
Es muss nicht immer ein Cybervorfall sein, der zu Fehlern führt, aber um Risiken auszuschliessen, empfiehlt es sich, bei neuen und unbekannten Fehlern oder Verhaltensauffälligkeiten die internen Ansprechpartner zu unterrichten. Mit deren Hilfe kann eine differenzierte Behandlung in die Wege geleitet werden. Auch die Awareness-Schulungen sollten dem Rechnung tragen und die Anwender mit der nötigen Handlungssicherheit ausstatten.