Software in der organisatorischen Hierarchie neu denken

Eine Version dieses Artikels erschien in Dark Reading. Er wurde hier aktualisiert und syndiziert.

‍

Jeder hat im Laufe seiner Karriere wahrscheinlich schon einmal eines dieser Organigramme gesehen, die festlegen, wer in einem Unternehmen an wen berichtet. Oft einfach nur Organigramm genannt, ist es ein nützliches Hilfsmittel, um zu verdeutlichen, wer für wen arbeitet und wer die Vorgesetzten sind. In einem typischen Organigramm berichtet beispielsweise der Leiter einer Entwicklungsgruppe an den Leiter der Produktentwicklung, der wiederum an den Vizepräsidenten für Innovation berichtet. So ziehen sich die Autoritätslinien durch die gesamte Unternehmensstruktur. Wer hat nicht schon einmal auf eine solche Grafik geschaut, um seinen eigenen kleinen Platz darin zu finden?

Es ist kaum verwunderlich, dass Menschen von Hierarchien und Strukturen so fasziniert sind. Historisch gesehen haben sie uns als Spezies über lange Zeit am Leben erhalten, selbst in der Antike, als wir einer sehr gefährlichen Welt gegenüberstanden. Wir waren nie die stärksten oder schnellsten Lebewesen, aber wir arbeiteten gut in Teams zusammen, wobei jeder seinen Platz und seine Verantwortung kannte, um unsere Familie, unseren Stamm oder unsere Gruppe zusammenzuhalten, am Leben zu erhalten und gedeihen zu lassen. Das moderne Organigramm ist eigentlich eine Erweiterung dieser alten Erfolgsgeschichte.

Doch eines haben fast alle Organigramme gemeinsam, unabhängig von der Größe des Unternehmens oder anderen Faktoren. Die Bausteine in diesen Diagrammen repräsentieren größtenteils Menschen oder Gruppen von Menschen. Wir sind noch nicht an dem Punkt angelangt, an dem Maschinen Menschen beaufsichtigen können, daher sind Organigramme derzeit eine rein menschliche Angelegenheit. Aber braucht unsere Software auch eine organisatorische Hierarchie?

Natürlich schlage ich nicht vor, Software in unsere Unternehmens-Organigramme aufzunehmen. Niemand möchte eine App als Chef haben. Wie sollte man sie überhaupt um eine Gehaltserhöhung bitten? Aber die Bedrohungslage, mit der unsere Anwendungen und Programme heutzutage konfrontiert sind, unterscheidet sich nicht wesentlich von der gefährlichen Umgebung, der unsere menschlichen Vorfahren einst gegenüberstanden. Indem wir die Verantwortlichkeiten unserer Apps und Software in einer straffen Hierarchie definieren und diese Richtlinien mit dem Prinzip der geringsten Rechte durchsetzen, stellen wir sicher, dass unsere Anwendungen trotz der verheerend rauen Bedrohungslage bestehen und gedeihen können.

Angriffe auf Apps und Software erreichen ein Allzeithoch

Um die Notwendigkeit besserer organisatorischer Hierarchien für Software zu verstehen, muss man zunächst die Bedrohungslage betrachten. Angreifer sowie die Bots und automatisierten Programme, die für sie arbeiten, suchen ständig nach Schwachstellen in der Verteidigung. Und während Phishing und andere Angriffe auf Menschen weiterhin stattfinden, haben die versiertesten Hacker den Großteil ihrer Bemühungen auf den Angriff auf Software verlagert.

Und obwohl jede Software ins Visier genommen wird, richten sich die erfolgreichsten Angriffe gegen Anwendungsprogrammierschnittstellen, kurz APIs. Diese unscheinbaren APIs sind kleine Softwarebausteine, die von Entwicklern verwendet werden, um eine Vielzahl kleiner, aber wichtiger Aufgaben für ihre Apps und Programme auszuführen. Sie sind oft flexibel und einzigartig und werden manchmal sogar spontan während des Entwicklungsprozesses erstellt.

APIs sind zwar flexibel, aber oft auch mit viel zu weitreichenden Berechtigungen ausgestattet. Entwickler neigen dazu, ihnen viele Rechte einzuräumen, damit sie beispielsweise auch dann noch funktionieren, wenn sich das Programm, das sie verwalten, weiterentwickelt und verändert. Das bedeutet jedoch: Wenn ein Angreifer sie kompromittiert, erhält er weit mehr als nur Zugriff auf einen Teil einer bestimmten Datenbank. Er könnte sogar nahezu Administratorrechte für ein gesamtes Netzwerk erlangen.

Es ist kein Wunder, dass mehrere Sicherheitsforschungsunternehmen angeben, dass die überwältigende Mehrheit der Angriffe zum Diebstahl von Zugangsdaten heute gegen Software wie APIs gerichtet ist. Akamai beziffert diesen Anteil auf 75 % der Gesamtzahl, während Gartner ebenfalls feststellt, dass Schwachstellen in APIs zum häufigsten Angriffsvektor geworden sind. Und der jüngste Bericht von Salt Labs zeigt, dass Angriffe auf APIs im Vergleich zum Vorjahr um fast 700 % gestiegen sind.

Ein Organigramm für Software erstellen

Eine der Möglichkeiten, wie Unternehmen gegen den Diebstahl von Zugangsdaten vorgehen, ist die Durchsetzung des Prinzips der geringsten Rechte (Least Privilege) oder sogar Zero Trust in ihren Netzwerken. Dies beschränkt Benutzer darauf, nur gerade so viele Berechtigungen zu erhalten, wie sie zur Erledigung ihrer Aufgaben benötigen. Dieser Zugriff wird oft zusätzlich durch Faktoren wie Zeit und Ort eingeschränkt. Auf diese Weise nützt selbst ein erfolgreicher Angriff dem Angreifer wenig, da er nur für kurze Zeit begrenzte Funktionen ausführen kann.

Das Prinzip der geringsten Rechte ist eine gute Verteidigung, wird aber normalerweise nur auf menschliche Benutzer angewendet. Wir vergessen oft, dass auch APIs über erweiterte Berechtigungen verfügen und häufig bei weitem nicht so stark reguliert sind. Das ist einer der Gründe, warum fehlerhafte Zugriffskontrolle laut dem Open Web Application Security Project (OWASP), das Cyberangriffsmuster verfolgt, heute Staatsfeind Nummer eins ist.

Es ist leicht zu sagen, dass die Lösung für dieses kritische Problem darin besteht, das Prinzip der geringsten Rechte einfach auf Software anzuwenden. Die Umsetzung ist jedoch deutlich schwieriger. Zunächst müssen Entwickler für die Gefahren sensibilisiert werden. Zudem sollten APIs und andere Software künftig offiziell als Teil eines Organigramms innerhalb des Computernetzwerks, in dem sie sich befinden, eingeplant oder zumindest konzeptionell so betrachtet werden. Wenn eine API beispielsweise Echtzeit-Flugdaten für eine Buchungsanwendung abrufen soll, gibt es keinen Grund, warum sie auch eine Verbindung zu Gehaltsabrechnungs- oder Finanzsystemen herstellen können sollte. Im Software-Organigramm gäbe es keine direkten oder auch nur gestrichelten Linien, die diese Systeme verbinden.

Es ist wahrscheinlich unrealistisch, dass Entwickler tatsächlich ein Organigramm erstellen, das die Tausenden oder gar Millionen von APIs in ihrem Unternehmen abbildet. Aber sich der Gefahr bewusst zu sein, die sie darstellen, und ihre Berechtigungen auf das notwendige Maß zu beschränken, wird viel dazu beitragen, die grassierenden Angriffe zum Diebstahl von Zugangsdaten zu stoppen. Es beginnt mit dem Bewusstsein und endet damit, APIs und Software mit derselben Sorgfalt zu behandeln wie menschliche Benutzer.
‍

Möchten Sie Ihr Entwicklungsteam voranbringen? Meistern Sie API-Sicherheitsfragen und mehr mit unserer agilen Lernplattform und entwicklerorientierten Sicherheitstools.