Technische Schulden gibt es in drei Formen. Altgeräte, die den heutigen Anforderungen nicht gerecht werden können, Softwareprojekte, bei denen Abstriche gemacht wurden, und schlecht implementierte oder völlig ignorierte Governance-Frameworks. Der rote Faden? Risiko.
Technische Schulden
Technische Schulden sind das Defizit zwischen der angenommenen Leistung von etwas und dem, was es tatsächlich liefert. Aufgrund der Disparität gibt es eine unvermeidbare Underperformance. Technische Schulden altern nicht gut. Mit zunehmender Ungleichheit wächst auch Ihr Risikorisiko.
Technische Schulden können langsam anwachsen. Alternde Hardware und Betriebssysteme rutschen schließlich rückwärts aus ihren Herstellern&8217; Zyklen unterstützen. Die technische Schuld ist das wachsende Sicherheitsrisiko, dem Sie Ihr Unternehmen aussetzen, indem Sie Systeme ausführen, die keine Sicherheitspatches erhalten.
Manchmal können Sie technische Schulden durch eine Fusion oder eine Übernahme erben. Sie können auch technische Schulden herstellen, insbesondere in Softwareentwicklungsprojekten. Design- und Implementierungsentscheidungen—die dem Entwicklungsteam oft aufgrund von Budgetbeschränkungen oder unrealistischen Fristen aufgezwungen werden—können technische Schulden einführen, die in die Anwendung eingearbeitet werden und bei der Einführung vollständig vorhanden sind.
IT Governance-Frameworks wie Cybersicherheits- und Datenschutzrichtlinien und -verfahren können technische Schulden anhäufen, können mit bereits eingebetteten technischen Schulden erstellt werden oder können unter beidem leiden.
Werbung
In allen Fällen ist die technische Schulden sind direkt mit Risiko gleichzusetzen. Dies ist ein sicherer Indikator dafür, dass dem Problem Aufmerksamkeit geschenkt werden muss.
IT-Ausrüstung und technische Schulden
Die gesamte IT-Ausrüstung muss gewartet werden. Sicherheitspatches müssen auf Software und Firmware angewendet werden, und Betriebssysteme müssen aktualisiert werden, wenn sie veraltet und nicht mehr unterstützt werden. Festplatten müssen am Ende ihrer erwarteten Lebensdauer oder bei den ersten Warnsignalen für sich entwickelnde Fehler ausgetauscht werden. Wenn die fragliche Festplatte nicht Teil eines RAID-Arrays ist, warten Sie nicht auf Warnsignale. Handeln Sie, wenn der Antrieb seinen prognostizierten Arbeitszyklus erfüllt hat.
Irgendwann werden alle Geräte und Betriebssysteme veraltet. Der Betrieb alter, nicht unterstützter Geräte ist ein Sicherheitsrisiko. Trotzdem kann es für die kommerzielle Seite des Unternehmens schwierig sein, etwas zu ersetzen, das für sie immer noch gut funktioniert. Und selbst wenn etwas aufgewertet und ersetzt werden soll, bleiben die technischen Schulden so lange bestehen, bis der Austausch tatsächlich erfolgt ist.
Manchmal liegen abgelaufene Betriebssysteme oder alte Hardware außerhalb Ihrer unmittelbaren Kontrolle. Labor- und Industrie-Steuerungs-PCs sind besonders anfällig für Betriebssystem-Lock-In. Dies kann passieren, wenn eine wichtige Software von Drittanbietern seit ihrer Veröffentlichung nicht aktualisiert wurde. Dies kann Sie dazu zwingen, das Betriebssystem auszuführen, das beim Start des Produkts aktuell war. es kann ein hardwarebasiertes Problem sein. Wenn die Software nur mit einer bestimmten, alten Schnittstellenkarte funktioniert, die nur mit einer bestimmten PC-Hardware kompatibel ist, bleiben Sie bei den Betriebssystemen hängen, die diese POCs unterstützen können.
Vollständiger Ersatz gealterte Hard- und Software ist nicht so einfach, wie es sich anhört. Es kann die Produktion oder andere geschäftskritische Maschinen oder Prozesse steuern. Sie können das alte Zeug nicht einfach wegwerfen, wenn das, was heute verfügbar ist, nicht in Ihre Produktionssysteme integriert werden kann.
Je älter die Systeme sind, desto wahrscheinlicher ist es, dass die Personen, die sie implementiert haben, das Unternehmen verlassen haben. Ihre Support-Teams verfügen möglicherweise über keine fundierten Kenntnisse über die veralteten Systeme. Oft, wenn festgestellt wird, dass diese alten Systeme tiefer miteinander verbunden und eingebettet sind, als bisher verstanden wurde.
Entwicklungsprojekte und technische Schulden
< p>Nicht-triviale Entwicklungsprojekte stellen hohe Anforderungen. Ob die Anwendung für den Eigenverbrauch oder ein Produkt, das vermarktet werden soll, die Belastungspunkte sind ähnlich. Die meisten davon drehen sich um Fristen, Spezifikationen und Budgets.
Werbung
Die Spezifikation ist eine Liste von Funktionen und Inhalten, die die Software bereitstellen muss. Die Spezifikation muss mehr sein als eine lange Wunschliste. Die für Entwicklung, Tests und Dokumentation verfügbare Zeit bestimmt, welche Inhalte realistischerweise mit den verfügbaren Entwicklungsressourcen und den Technologien, mit denen sie vertraut sind, erreicht werden können.
Eine zu optimistische Spezifikation oder eine zu kurze Entwicklungsphase bedeutet dasselbe. Die Arbeit passt nicht in die zur Verfügung stehende Zeit. Die Auswirkungen, die dies auf das Entwicklungsteam hat, sind tiefgreifend. Wenn sie unter Druck geraten, werden bekannte Techniken, Methoden und Technologien dem Zeitaufwand für die Bewertung neuer Plattformen, Frameworks oder was auch immer vorgezogen.
Wenn Sie sich auf dem Todesmarsch zu einer Frist befinden, haben Sie keine Zeit, mit neuen Technologien zu experimentieren und potenziell Risiken einzuführen. Dieses Risiko können funktionale Probleme innerhalb der Software sein, die sich auf die Benutzer auswirken, oder es kann sich um heimtückische Probleme handeln, die zu Sicherheitslücken führen.
Manchmal gerät die Entwicklung von der kommerziellen Seite des Geschäfts unter Druck. Sie können vorschreiben, dass eine neue Technologie verwendet wird, um sicherzustellen, dass sich Ihr Produkt gegenüber der Konkurrenz behauptet. Das bedeutet, dass Sie gezwungen sind, die neue Technologie zu erlernen und trotzdem die Frist einhalten.
Diese Art von selbst zugefügten Wunden beeinträchtigen die Architektur des Produkts und die Codequalität. Sie werden das Beste aus einem neuen Framework, einer neuen Sprache oder sogar einem Entwicklungsparadigma herausholen, bis Ihre Entwickler ausreichend damit vertraut sind, um seine Idiome und Best Practices zu verstehen. Zumindest ist es wahrscheinlich, dass Code erzeugt wird, der schlecht funktioniert und schwer zu warten ist. Im schlimmsten Fall kann es zu Sicherheitsrisiken kommen.
Werbung
Bibliotheken und Toolkits von Drittanbietern beschleunigen die Entwicklung, können jedoch Sicherheitslücken und eigene technische Schulden enthalten. Die Verwendung von Code von Drittanbietern vereinfacht die Entwicklung, kann die Angelegenheit für Ihr Sicherheitsteam jedoch erschweren.
Die kaufmännische und kaufmännische Seite der Organisation muss in frühzeitige Gespräche mit der Entwicklung einbezogen werden, damit eine realistische, aber für beide Seiten zufriedenstellende Produktbeschreibung und Spezifikation unter Berücksichtigung aktueller und aktueller Technologien und Fristen erstellt werden kann. Ihr Sicherheitsteam muss ebenfalls eingebunden werden. Und weil Ihr Entwicklungsteam nie untätig herumsitzt, muss für Forschung gesorgt werden. Andernfalls wird es nicht passieren.
Die formelle Planung von Zeit und Ressourcen für die Forschung —einschließlich Schulungen—ist der einzige Weg, um sicherzustellen, dass wichtige Forschungen stattfinden. Um dies zu erreichen, müssen Sie möglicherweise rekrutieren. ohne Forschung werden Sie nie in der Lage sein, kontrolliert auf neue Technologien umzusteigen. Und ohne Kontrolle bleiben Sie mit Risiken zurück.
Governance und technische Schulden
Technische Schulden können sich ähnlich wie bei der Softwareentwicklung in die Entwicklung von Governance-Frameworks einschleichen. Anstatt Software zu entwickeln, erstellen Sie Richtlinien und Verfahren wie IT-Governance oder Datenschutzsysteme. Sie würden einem Team, das noch nie zuvor Code geschrieben hat, ein Entwicklungsprojekt übergeben. Dasselbe gilt für die Governance-Dokumentation.
Sie können keine großartigen Ergebnisse erwarten, wenn Sie die Aufgabe jemandem übertragen, der nicht über die entsprechenden Fähigkeiten verfügt. Das Verfassen von Good Governance-Dokumenten ist schwierig. Ohne diese Fähigkeiten ist es verlockend, Teile aus anderen Organisationen zu kopieren. Richtlinien und Verfahren und versuchen, sie zu einem zusammenhängenden Ganzen zu bearbeiten, aber es funktioniert nicht. Das Ergebnis ist ein Patchwork-Quilt aus Dokumenten, die für andere Organisationen entworfen wurden.
Ihre Governance-Autoren müssen die Rechtsvorschriften oder Standards kennen und verstehen, die Sie erfüllen oder umsetzen möchten, und über Erfahrung in der Erstellung von Governance- und Richtliniendokumenten verfügen. Wenn Sie das nicht sind, wenden Sie sich an jemanden, der über diese Fähigkeiten verfügt.
Werbung
Ein weiteres häufiges Versagen besteht darin, Governance-Dokumente beeindruckend zu machen, anstatt sie sachlich zu machen. Sie müssen ein wahres Spiegelbild dessen sein, was Sie tun und kontrollieren müssen und wie Sie es tun werden, damit Sie die Gesetzgebung oder den Standard erfüllen, mit dem Sie arbeiten. Es ist unmöglich, eine Prüfung zu bestehen, wenn die Dokumente, gegen die Sie geprüft werden, nicht Ihre tatsächlichen Prozesse, Arbeitsabläufe und Sicherheitsvorkehrungen widerspiegeln.
Genaue und anwendbare Governance-Dokumente bringen nur sehr wenig, wenn sie nicht verwendet werden. Compliance-Selbstzufriedenheit liegt vor, wenn Sie über die Richtlinien und Verfahren verfügen, aber niemand sie verwendet. Sie müssen von Ihren Mitarbeitern übernommen und verwendet werden, andernfalls werden Ihre Verfahren nicht in Übereinstimmung mit Ihren Richtlinien durchgeführt. Das ist schon schlimm genug, bedeutet aber auch, dass Ihre Prozesse keinen Audit-Trail generieren. Schlimmer noch, die Nichtbefolgung von Verfahren kann zu Sicherheitslücken und Datenschutzverletzungen führen.
Auch die Aufrechterhaltung eines Governance-Systems erfordert Zeit und Ressourcen. Sie müssen beispielsweise interne Audits durchführen und die Gesetzeslandschaft überwachen. Die Gesetzgebung ändert sich im Laufe der Zeit und wird aufgehoben und ersetzt. Das Unternehmen kann sich entscheiden oder gezwungen sein, einen Standard einzuhalten, zu dessen Einhaltung es zuvor nicht gezwungen wurde. Beispielsweise könnten Sie beginnen, Online-Zahlungen entgegenzunehmen und müssen den Payment Card Industry Data Security Standard (PCI-DSS) einhalten. Ihre Governance-Dokumentation muss geändert werden, um die neuen Anforderungen widerzuspiegeln und sicherzustellen, dass alle Klauseln der Standards berücksichtigt werden.
Angesichts Ihrer Schulden
Technische Schulden schläft nie und es wird schlimmer, je länger Sie sie verlassen. Was es braucht, um das Problem anzugehen, reicht von einfach bis sehr schwierig. Es ist einfach, eine Patching-Richtlinie zu erstellen und einen Zeitplan festzulegen. Die Beseitigung der Bindung an Altsysteme kann unhaltbare Umwälzungen und Ausgaben erfordern.
Wenn Sie technische Schulden haben, die Sie nicht beheben können—oder die nicht behoben werden können, bis ein anderes bedeutendes Ereignis eintritt—stellen Sie sicher Sie haben das Risiko in Ihrer Operational Risk Assessment und Cyber Risk Assessment Dokumente erfasst und charakterisiert. Notieren Sie, welche Schritte unternommen wurden, um das Risiko zu mindern, und welche Notfallmaßnahmen Sie ergreifen können, falls das Risiko eintritt.