Software in der Organisationshierarchie neu denken

Eine Version dieses Artikels erschien in Dunkle Lektüre. Es wurde hier aktualisiert und syndiziert.

‍

Jeder hat wahrscheinlich irgendwann in seiner Karriere eines dieser operativen Berichts- oder Hierarchiediagramme gesehen, in denen definiert wird, wer in einer Organisation an wen berichtet. Manchmal einfach genannt Organigramm, es ist ein nützliches Tool, um die Leute wissen zu lassen, wer für sie arbeitet und wer ihre Chefs sind. In einem typischen Organigramm könnte beispielsweise der Leiter einer Programmiergruppe dem Direktor für Produktentwicklung unterstellt sein, der wiederum dem Vizepräsidenten für Innovation unterstellt ist. Und dann setzen sich die Zuständigkeitsbereiche in der Unternehmensstruktur fort. Wer hat sich nicht eines dieser Diagramme angesehen, um zu versuchen, seinen persönlichen kleinen Block zu finden, der sich irgendwo darin befindet?

Es ist kein Wunder, dass Menschen von Hierarchie und Struktur so fasziniert sind. Es ist das, was uns historisch gesehen als Spezies so lange am Leben erhalten hat, sogar in der Antike, als wir mit einer sehr gefährlichen Welt konfrontiert waren. Wir waren nie die stärksten oder schnellsten Kreaturen, aber wir haben in Teams gut zusammengearbeitet, wobei jeder seinen Platz und seine Verantwortung kannte, um unsere Familie, unseren Stamm oder unsere Gruppe zusammenzuhalten, am Leben und Gedeihen zu halten. Das moderne Organigramm ist eigentlich eine Fortsetzung dieser Zeiten und dieses uralten Erfolgs.

Eines hat jedoch fast jedes Organigramm gemeinsam, unabhängig von der Größe des Unternehmens oder anderen Faktoren. In den meisten Fällen stellen alle Bausteine in diesen Diagrammen Menschen oder Gruppen von Menschen dar. Wir sind noch nicht an dem Punkt angelangt, an dem Maschinen in der Lage sind, Menschen zu beaufsichtigen. Deshalb sind Organigramme vorerst eine ausschließlich menschliche Angelegenheit. Aber braucht unsere Software auch eine Organisationshierarchie?

Natürlich schlage ich nicht vor, dass wir unsere Unternehmensorganigramme um Software erweitern. Niemand möchte eine App für einen Chef haben. Wie würdest du sie überhaupt um eine Gehaltserhöhung bitten? Aber die Bedrohungslandschaft, mit der unsere Anwendungen und Programme heutzutage konfrontiert sind, ist der gefährlichen Umgebung nicht unähnlich, mit der unsere Vorfahren vor langer Zeit konfrontiert waren. Indem wir dabei helfen, die Verantwortlichkeiten unserer Apps und Software innerhalb einer engen Hierarchie zu definieren und diese Richtlinien mit den geringsten Rechten durchzusetzen, können wir sicherstellen, dass unsere Apps und Software trotz der verheerend rauen Bedrohungslandschaft, der sie ausgesetzt sind, überleben und gedeihen.

Angriffe auf Apps und Software erreichen ein Allzeithoch

Um zu verstehen, dass bessere Organisationshierarchien für Software geschaffen werden müssen, ist es wichtig, zunächst die Bedrohungslandschaft zu verstehen. Heutzutage suchen die Angreifer und die für sie geeigneten Bots und die automatisierungsgesteuerte Software ständig nach Schwachstellen in den Abwehrmechanismen, die sie ausnutzen können. Und obwohl Phishing und andere Angriffe gegen Menschen immer noch gestartet werden, haben die erfahrensten Hacker den Großteil ihrer Bemühungen auf Angriffe auf Software verlagert.

Und während die gesamte Software ins Visier genommen wird, richten sich die erfolgreichsten Angriffe gegen Anwendungsprogrammierschnittstellen (APIs). Diese unscheinbaren APIs sind winzige Softwareteile, mit denen Entwickler eine Vielzahl kleiner, aber wichtiger Aufgaben für ihre Apps und Programme ausführen. Sie sind oft flexibel und einzigartig und werden manchmal sogar spontan erstellt, wenn dies im Entwicklungsprozess erforderlich ist.

APIs sind sicherlich flexibel, aber oft auch viel zu viel erlaubt für ihre Funktionen. Entwickler neigen dazu, ihnen viele Berechtigungen zu geben, damit sie beispielsweise weiterhin funktionieren können, auch wenn sich das Programm, an dessen Verwaltung sie mitarbeiten, ständig weiterentwickelt und verändert wird. Das heißt aber, wenn ein Angreifer sie kompromittiert, dann erhält er viel mehr als nur Zugriffsrechte, zum Beispiel auf einen Teil einer bestimmten Datenbank. Sie können sogar fast Administratorrechte für ein ganzes Netzwerk abgreifen.

Es ist kein Wunder, dass mehrere Sicherheitsforschungsunternehmen angeben, dass die überwältigende Mehrheit der Angriffe zum Stehlen von Zugangsdaten heute gegen Software wie APIs erfolgt. Akamai beziffert diese Zahl auf 75% des Gesamtbetrags, während Gartner das auch sagt Sicherheitslücken im Zusammenhang mit APIs sind zum häufigsten Angriffsvektor geworden. Und der jüngste Bericht von Salt Labs zeigt Angriffe gegen APIs steigt um fast 700% verglichen mit dem Vorjahr.

Erstellen eines Organigramms für Software

Unternehmen wehren sich unter anderem gegen Bedrohungen durch den Diebstahl von Zugangsdaten, indem sie in ihren Netzwerken die geringsten Rechte oder sogar Zero-Trust durchsetzen. Dadurch erhalten Benutzer nur noch knapp genug Berechtigungen, um ihren Job oder ihre Aufgaben zu erledigen. Dieser Zugriff wird oft durch Faktoren wie Zeit und Ort weiter eingeschränkt. Selbst wenn ein Angriff zum Stehlen von Anmeldeinformationen erfolgreich ist, nützt das dem Angreifer auf diese Weise nicht viel, da er nur für kurze Zeit die Erlaubnis hat, eingeschränkte Funktionen auszuführen.

Geringste Privilegien sind eine gute Verteidigung, werden aber normalerweise nur auf menschliche Benutzer angewendet. Wir neigen dazu zu vergessen, dass APIs auch über erhöhte Rechte verfügen und oft nicht annähernd so reguliert sind. Das ist einer der Gründe dafür kaputte Zugangskontrolle ist laut dem Open Web Application Security Project (OWASP), das Cyberangriffsmuster verfolgt, heute Staatsfeind Nummer eins.

Es ist leicht zu sagen, dass die Lösung für dieses kritische Problem darin besteht, Software einfach mit den geringsten Rechten zu versehen. Aber es ist viel schwieriger zu implementieren. Zunächst müssen Entwickler auf die Gefahren aufmerksam gemacht werden. Und in Zukunft sollten APIs und andere Software entweder offiziell als Teil eines Organigramms innerhalb des Computernetzwerks, in dem sie sich befinden werden, platziert oder zumindest als Teil eines Organigramms dargestellt werden. Wenn beispielsweise eine API Flugdaten in Echtzeit als Teil einer Buchungsanwendung abrufen soll, dann gibt es keinen Grund, warum sie auch in der Lage sein sollte, eine Verbindung zu Gehaltsabrechnungs- oder Finanzsystemen herzustellen. Auf dem Software-Organigramm gäbe es keine direkten oder gar gepunkteten Linien, die diese Systeme verbinden.

Es ist wahrscheinlich unrealistisch, dass Entwickler tatsächlich ein Organigramm erstellen, das die Tausenden oder sogar Millionen von APIs zeigt, die in ihrer Organisation arbeiten. Aber sich der Gefahr bewusst zu sein, die von ihnen ausgeht, und ihre Berechtigungen auf genau das zu beschränken, was sie für ihre Arbeit benötigen, wird wesentlich dazu beitragen, die grassierenden Angriffe auf den Diebstahl von Anmeldeinformationen zu stoppen, mit denen heutzutage jeder konfrontiert ist. Es beginnt mit der Sensibilisierung und endet damit, APIs und Software mit der gleichen Sorgfalt zu behandeln wie menschliche Benutzer.
‍

Möchten Sie Ihr Entwicklungsteam erweitern? Bewältigen Sie API-Sicherheitsprobleme und mehr mit unseren agile Lernplattform und Sicherheitstools, bei denen Entwickler an erster Stelle stehen.