Software in der Organisationshierarchie neu denken

Eine Version dieses Artikels erschien in Dunkles Lesen. Er wurde aktualisiert und hier syndiziert.

‍

Wahrscheinlich hat jeder im Laufe seiner beruflichen Laufbahn schon einmal eines dieser betrieblichen Berichts- oder Hierarchiediagramme gesehen, in denen festgelegt ist, wer wem in einer Organisation unterstellt ist. Es ist ein nützliches Instrument, um den Mitarbeitern mitzuteilen, wer für sie arbeitet und wer ihre Vorgesetzten sind. In einem typischen Organigramm berichtet beispielsweise der Leiter einer Programmiergruppe an den Leiter der Produktentwicklung, der wiederum an den Vizepräsidenten für Innovation berichtet. Und dann setzen sich die Autoritätslinien in der Unternehmensstruktur nach oben und unten fort. Wer hat nicht schon einmal in eines dieser Diagramme geschaut und versucht, seinen persönlichen kleinen Block zu finden, der irgendwo darin eingebettet ist?

Es ist kein Wunder, dass der Mensch von Hierarchie und Struktur so fasziniert ist. Das ist es, was uns als Spezies so lange am Leben gehalten hat, selbst in der Antike, als wir mit einer sehr gefährlichen Welt konfrontiert waren. 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 zu fördern. Das moderne Organigramm ist eigentlich eine Erweiterung dieser Zeiten und dieses alten Erfolgs.

Eines haben jedoch fast alle Organigramme gemeinsam, unabhängig von der Größe des Unternehmens oder anderen Faktoren. In den meisten Fällen handelt es sich bei den Bausteinen in diesen Diagrammen um Menschen oder Gruppen von Menschen. Wir sind noch nicht an dem Punkt angelangt, an dem Maschinen in der Lage sind, Menschen zu beaufsichtigen, also sind Organigramme im Moment eine ausschließlich menschliche Angelegenheit. Aber braucht unsere Software auch eine Organisationshierarchie?

Natürlich schlage ich nicht vor, dass wir unsere Unternehmensorganigramme mit Software ergänzen. Niemand möchte eine App für seinen Chef haben. Wie könnten Sie ihn überhaupt um eine Gehaltserhöhung bitten? Aber die Bedrohungslage, mit der unsere Anwendungen und Programme heutzutage konfrontiert sind, ist nicht unähnlich der gefährlichen Umgebung, mit der unsere menschlichen Verwandten vor langer Zeit konfrontiert waren. Indem wir die Zuständigkeiten unserer Anwendungen und Software innerhalb einer strengen Hierarchie festlegen und diese Richtlinien mit dem geringsten Recht durchsetzen, können wir sicherstellen, dass unsere Anwendungen und Software auch in einer verheerend rauen Bedrohungslandschaft überleben und gedeihen.

Angriffe auf Apps und Software erreichen ein Allzeithoch

Um zu verstehen, warum es notwendig ist, bessere Organisationshierarchien für Software zu schaffen, muss man zunächst die Bedrohungslandschaft verstehen. Angreifer und die Bots und automatisierte Software, die für sie arbeiten, sind ständig auf der Suche nach Schwachstellen in der Verteidigung, die sie ausnutzen können. Und während Phishing- und andere Angriffe auf Menschen immer noch durchgeführt werden, haben die geschicktesten Hacker den Großteil ihrer Bemühungen auf Angriffe auf Software verlagert.

Zwar wird jede Software angegriffen, doch die erfolgreichsten Angriffe richten sich gegen Anwendungsprogrammierschnittstellen (APIs). Bei diesen unscheinbaren APIs handelt es sich um winzige Softwarekomponenten, die von Entwicklern zur Ausführung einer Vielzahl kleiner, aber wichtiger Aufgaben für ihre Anwendungen und Programme verwendet werden. Sie sind oft flexibel und einzigartig, und manchmal werden sie sogar während des Entwicklungsprozesses nach Bedarf erstellt.

APIs sind sicherlich flexibel, aber sie haben auch oft viel zu viele Berechtigungen für ihre Funktionen. Die Entwickler neigen dazu, ihnen viele Berechtigungen zu erteilen, damit sie beispielsweise auch dann noch funktionieren, wenn sich das Programm, das sie zu verwalten helfen, weiterentwickelt und verändert. Das bedeutet jedoch, dass ein Angreifer, wenn er sie kompromittiert, viel mehr als nur die Rechte für den Zugriff auf einen Teil einer bestimmten Datenbank erhält. Er kann sogar nahezu Administratorrechte für ein ganzes Netzwerk erlangen.

Es ist kein Wunder, dass mehrere Sicherheitsforschungsunternehmen sagen, dass die überwältigende Mehrheit der Angriffe zum Diebstahl von Zugangsdaten heute gegen Software wie APIs erfolgt. Akamai beziffert diese Zahl auf 75 % der Gesamtzahl, und auch Gartner sagt, dass Schwachstellen in APIs zum häufigsten Angriffsvektor geworden sind. Und der jüngste Bericht von Salt Labs zeigt, dass die Angriffe auf APIs im Vergleich zum letzten Jahr um fast 700 % gestiegen sind.

Erstellen eines Organigramms für Software

Eine Möglichkeit für Unternehmen, sich gegen den Diebstahl von Anmeldeinformationen zu wehren, besteht darin, in ihren Netzwerken ein Minimum an Berechtigungen oder sogar ein Null-Vertrauen durchzusetzen. Dadurch erhalten die Benutzer nur gerade genug Rechte, um ihre Arbeit oder Aufgaben zu erledigen. Dieser Zugriff wird häufig durch Faktoren wie Zeit und Standort weiter eingeschränkt. Selbst wenn ein Angriff zum Diebstahl von Anmeldeinformationen erfolgreich ist, nützt er dem Angreifer nicht viel, da er nur für kurze Zeit die Erlaubnis hat, begrenzte Funktionen auszuführen.

Least Privilege ist ein guter Schutz, wird aber normalerweise nur auf menschliche Benutzer angewendet. Wir neigen dazu, zu vergessen, dass auch APIs über erhöhte Privilegien verfügen und oft nicht annähernd so reguliert sind. Das ist einer der Gründe, warum eine unzureichende Zugriffskontrolle laut dem Open Web Application Security Project (OWASP), das Cyberangriffsmuster verfolgt, zum Staatsfeind Nummer eins geworden ist. 

Es ist leicht zu sagen, dass die Lösung für dieses kritische Problem einfach darin besteht, das geringste Recht auf Software anzuwenden. Aber es ist viel schwieriger, sie umzusetzen. Zunächst müssen die Entwickler für die Gefahren sensibilisiert werden. Und dann sollten APIs und andere Software entweder offiziell als Teil eines Organigramms innerhalb des Computernetzwerks, in dem sie sich befinden werden, platziert oder zumindest vorgesehen werden. Wenn eine API beispielsweise als Teil einer Buchungsanwendung Flugdaten in Echtzeit abrufen soll, gibt es keinen Grund, warum sie nicht auch eine Verbindung zu Lohn- oder Finanzsystemen herstellen können sollte. Im Software-Organigramm gäbe es keine direkten oder gar gestrichelten Linien, die diese Systeme verbinden.

Für Entwickler ist es wahrscheinlich unrealistisch, ein Organigramm mit den Tausenden oder gar Millionen von APIs in ihrem Unternehmen zu erstellen. Aber wenn man sich der Gefahr bewusst ist, die von ihnen ausgeht, und ihre Berechtigungen auf das beschränkt, was sie für ihre Arbeit benötigen, kann man die grassierenden Angriffe zum Diebstahl von Anmeldeinformationen, mit denen heutzutage jeder konfrontiert ist, schon lange stoppen. 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 aufwerten? Navigieren Sie durch API-Sicherheitsprobleme und mehr mit unserem agilen learning platform und entwicklerorientierten Sicherheitstools.