OSS

(Bild: iStock)

Die Entwicklung neuer Softwareanwendungen hat sich in den letzten 20 Jahren zu einem wichtigen Erfolgsfaktor für Unternehmen gestaltet. Laut einem Bericht von Forrester Research investierten  Unternehmen aus Europa, Nordamerika und Asien allein im Jahr 2015 mindestens 620 Milliarden Dollar in diesen Bereich.

Die intern entwickelten Anwendungen sichern den Unternehmen Wettbewerbsvorteile. Dabei nutzen Entwickler für die entscheidende Funktionalität häufig OSS-Komponenten (Open-Source-Software). Webbasierte, kundenseitige Anwendungen sind ein wichtiger Faktor für die Profitabilität. Doch die Nutzung von ohne umsichtige Überprüfung stellt für jedes Unternehmen ein potenzielles Risiko dar. Nach Marktforschungen von Gartner und Symantec erfolgen fast 90 Prozent der Softwareangriffe über die Anwendungsschicht.

Gleichzeitig ist ein Großteil der Chief Officers (CSOs) davon überzeugt, angemessene Lösungen für die Anwendungssicherheit einzusetzen. Hierzu investiert man in Firewalls, webgestützte Authentifizierung, Angriffserkennung und Identitätsmanagementsysteme. Doch diese Lösungen sichern nur das Umfeld der Anwendungen ab, indem sie den Datenverkehr überwachen. Keine Lösung konzentriert sich auf die Absicherung der Anwendungen von innen heraus, beispielsweise durch Verbesserung des Anwendungscodes oder durch Schwachstellenmanagement.

Wer im Rahmen seiner Open-Source-Strategie sichere Anwendungen gewährleisten will, muss über entsprechende Prozesse, Schulungen und Werkzeuge verfügen. Die gute Zusammenarbeit der Teams für und ist ein weiterer wichtiger Baustein. Hierzu gehört zum einen eine genaue Bestandsaufnahme der verwendeten Open-Source-Komponenten unter der Zuständigkeit des Engineering-Teams, zum anderen die Überprüfung der verwendeten Open-Source-Projekte auf bekannte und veröffentlichte Schwachstellen unter der Zuständigkeit des Sicherheitsteams. Um die genannten Lücken schließen zu können, bedarf es robuster neuer Werkzeuge für das Open-Source-Management und ein geschärftes Risikobewusstsein.

Kaum Support abseits von Linux

Anwendungssicherheit ist für die Risikoabwehr unverzichtbar. Das gilt ganz besonders für Open-Source-Software. Zur Open-Source gehören mehr als nur und die gängigen OSS-Unternehmensanwendungen (wie etwa SugerCRM, Pentaho, Open Office). Sicherheitsbedenken verursacht vor allem die Vielzahl der namenlosen OSS-Komponenten. Sie werden heute in den meisten Anwendungen ganz einfach deswegen genutzt, damit die Entwickler das Rad nicht zweimal erfinden müssen. Warum sollte jemand für objekt-relationales Mapping entwickeln, wenn man Hibernate nutzen kann? Oder eine Komprimierungssoftware, wenn es zlib gibt?

Im Unterschied zu kommerziell unterstützten OSS-Betriebssystemen und Anwendungspaketen steht nur hinter jedem zehnten Open-Source-Projekt eine Community mit kommerziellen Services. Entwicklungsabteilungen, die OSS-Komponenten nutzen, sind sich selbst überlassen, wenn es um Patches, Upgrades, Schwachstellenbewertung und vergleichbare Aufgaben geht, die normalerweise Teil eines kommerziellen Servicevertrags sind.

Open-Source ist nicht mehr wegzudenken

Der Nutzen von OSS liegt auf der Hand: Senkung der Entwicklungskosten, Beschleunigung der Entwicklungszyklen und Reduzierung der Gesamtkosten der Anwendung – vorausgesetzt, das Anwendungsmanagement stimmt. Und tatsächlich bezeichnet IDC den Einsatz von Open-Source Software als den umfassendsten und dauerhaftesten Trend, den die Softwarebranche seit Anfang der 1980er Jahre erlebt.

Im Zeitalter des Internet der Dinge und eines Netzwerkzugangs rund um die Uhr können Entwickler aus aller Welt auf Open-Source, Freeware, Public Domain und Evalware (Demoversionen kommerzieller Programme) zugreifen und den Code in ihre Programme einbinden, ohne sich um die üblichen Prüfmechanismen im Beschaffungsprozess kümmern zu müssen. Doch ohne diese Kontrollen lassen sich OSS-Komponenten kaum erkennen, überwachen und nachverfolgen.

IT-Organisationen wissen daher meist gar nicht genau, welche Schwachstellen in ihrer Codebasis stecken. In jüngsten Untersuchungen hat Flexera festgestellt, dass die in den vergangenen fünf Jahren erstellten Anwendungen 50 Prozent oder mehr Open-Source-Code enthalten, bezogen auf die Zahl der Codezeilen. Wiederum 50 Prozent dieses Open-Source-Codes waren nicht dokumentiert.

Verwundbare Unternehmen

Undokumentierter Open-Source-Code in Unternehmensanwendungen gefährdet die Sicherheit dieser hochsensiblen und erfolgswichtigen Ressourcen. Wenn Entwickler früher den Code von Dritten in ihre Anwendungen einbinden wollten, wurde eine Entwicklungsvereinbarung oder ein Lizenzvertrag geschlossen. Hieran waren ein Entwicklungsleiter, eine Führungskraft aus dem Einkauf und ein Jurist beteiligt.

Die dazu nötigen komplexen Prozesse wurden aus Effizienzgründen weitgehend gestrichen. Daher können Unternehmen heute kaum noch Fragen beantworten, die für die Sicherheit ihrer wichtigsten Assets – ihre Softwareanwendungen – unverzichtbar sind:

  • Was steht in meinem Code?
  • Wo befindet sich die Open-Source-Software?
  • Gibt es Schwachstellen in Verbindung mit der verwendeten Open-Source-Software?

Je stärker die Entwicklungsabteilungen auf funktionsstarke, interaktive Umgebungen setzen, umso verwundbarer werden sie durch Schwachstellen (Stichwort Cross-Site Scripting). Angreifer nutzen bekanntermaßen diese OSS-Schwachstellen. Die Umgebungskontrollen für das Web 2.0 und die Softwarelösungen für das kommende Web 3.0 reichen bei Weitem nicht aus. Nach außen gerichtete, erfolgswichtige Softwareanwendungen müssen von Grund auf unter Einsatz von Sicherheitsmerkmalen programmiert werden.

Lesen Sie auf der nächsten Seite, warum Bewertung Pflicht ist. Außerdem finden Sie dort einen Fragenkatalog für mehr Sicherheit.

Bewertung ist Pflicht

OSS

Bild 1: Die Anwendungssicherheit lässt sich auf der Quellcodeebene und auf der höheren Ebene von Komponenten des Programmcodes bewerten. Flexera

In zwei Umgebungen ist die Bewertung der Anwendungssicherheit Pflicht: Während der Programmentwicklung und nach Abschluss und Einsatz des Projekts. Die Anwendungssicherheit kann dabei auf der Quellcodeebene und auf der höheren Ebene von Modulen oder des Programmcodes bewertet werden (Bild 1). Im unteren linken Quadranten erfolgt die Analyse auf der Quellecodeebene während der Entwicklung. Hier kommen zumeist statische Analysatoren zum Einsatz. Beim eigentlichen Einsatz wird die Analyse auf Programmcodeebene meist speziellen Sicherheitsscannern der Webanwendung überlassen.

Die für Sicherheit, Entwicklung und zuständigen Teams müssen gewährleisten, dass ihre Entwickler geeignete Prozesse zur Erstellung sicherer Software nutzen. Gemeinsam können diese drei Bereiche dafür sorgen, dass die Regeln für Anwendungssicherheit auch auf Open-Source-Komponenten angewandt werden und in die Sicherheitsstrategie einfließen. Dazu sollten sie diesen Maßnahmen folgen:

  • Durchführen von Prüfungen auf Codeebene und von Penetrationstests für intern entwickelten Code vor der Bereitstellung
  • Durchsetzen von Audits auf Codeebene auf Seiten externer Entwicklungs- und Geschäftspartner
  • Sicherstellen, dass sämtlicher Code von Dritten, der in den eigenen Softwareanwendungen zum Einsatz kommt, auf Sicherheitsschwachstellen und Updates geprüft und nachverfolgt wird
  • Sicherstellen, dass intern entwickelte Anwendungen über angemessene Prüfpunkte verfügen, die gründliche Audit-Trails ermöglichen

Entwicklungsorganisationen müssen ein hohes Niveau an Sicherheits-Know-how aufbauen und halten. Bei der Erstellung, Verbesserung, und Überarbeitung von Software für eine robuste Anwendungsinfrastruktur müssen sie zudem Prozesse zur Erstellung sicherer Software ermitteln, anwenden und konsequent nutzen.

Sicherheit, Entwicklung und IT

OSS

Bild 2: Zwischen Engineering- und Sicherheitsteams besteht oft eine Lücke. Flexera

Die Anwendungssicherheit steigt, wenn die Teams für Anwendungsentwicklung, Sicherheit und IT zusammenarbeiten. Keiner dieser Bereiche würde von einer isolierten Vorgehensweise profitieren (Bild 2). Beispielsweise dürfen und Virenschutz in der Anwendungsentwicklung nicht getrennt betrachtet werden.

Leider meinen viele Entwicklungsteams immer noch, Sicherheit sei ausschließlich Sache der Sicherheitsfachleute. In vielen Unternehmen konzentriert sich der Entwicklungsprozess allein auf Entwurf, Architektur, Codierung und Test von Anwendungen mit dem Ziel, alle funktionalen Anforderungen voll zu erfüllen. Angesichts der heute oft eingeschränkten finanziellen Mittel und Ressourcen werden Anwendungen oft nicht angemessen auf Codierungsfehler, Schwachstellen oder sonstige Bedingungen geprüft, die ein Eintrittstor für Hacker bilden könnten.

Gleichzeitig beschränkt sich der Auftrag der für Sicherheit und IT zuständigen Teams nur auf die Verteidigung gegen externe Angriffe. Hierzu werden erhebliche Mittel in Firewalls, webgestützte Authentifizierung, Angriffserkennung und Identitätsmanagementsysteme investiert. Doch Sicherheitsfachleute sind keine Programmierer. Sie wissen oft nicht, dass bereits die in der Entwicklungsphase getroffene Entscheidungen wesentliche Auswirkungen auf die später zu schützenden Anwendungen haben.

Fragenkatalog für mehr Sicherheit

Kein Team kann alleine alle Aspekte der Anwendungssicherheit abdecken. Denn Hacker, die sich sowohl mit Codierungsmethoden als auch mit Sicherheitsmechanismen auskennen, nutzen Lücken konsequent aus. Um sicherzustellen, dass beide Teams zum Schutz der bereitgestellten Anwendungen zusammenarbeiten, sollten verantwortliche Mitarbeiter sich die folgenden Fragen stellen:

  • Wo wird Open-Source-Software einschließlich sämtlicher Versionen eingesetzt?
  • Wie genau sind die verfügbaren Informationen?
  • Wo genau in der Codebasis befindet sich die eingesetzte Open-Source-Software?
  • Wie wird die Open-Source-Software eingesetzt?
  • Sind in den verwendeten Versionen Schwachstellen vorhanden?
  • Werden die neuesten Version eingesetzt – und wenn nicht, warum?
  • Wird für alle OSS-Projekte in der Codebasis für eine kommerzielle Unterstützung gezahlt?
  • Falls nicht, wer ist für die Überwachung und Aktualisierung auf neuere Versionen zuständig?
  • Welche Nutzungsrichtlinien und Genehmigungsprozesse werden für unsere Open-Source-Software eingesetzt?
  • Werden unternehmenseigene Richtlinien durchgesetzt und eingehalten?

Auch kurzfristig lassen sich Sicherheitsprozesse initiieren. So sollten Unternehmen auf Basis ihres eigenen Bestands an Open-Source-Software entsprechende OSS-Projektseiten und andere Quellen im Auge behalten und hinsichtlich neuer Warnungen über Sicherheitslücken prüfen. Die Relevanz dieser Warnungen lässt sich anhand des internen Nutzungsprofils bewerten. Diese Priorisierung hilft Empfehlungen für bestimmte Versionen zu formulieren oder Patch-Upgrades durchzuführen.

Mit einer soliden Sicherheitsplanung können Unternehmen und Institutionen die Vorteile von OSS nutzen und gleichzeitig die Anwender vor inhärenten Schwachstellen schützen. Ein erfolgreicher Schutz lässt sich nur durch eine starke Partnerschaft zwischen den Teams für Sicherheit und Engineering gewährleisten.

Eck-DATEN

Die für Sicherheit, Entwicklung und IT zuständigen Teams müssen gewährleisten, dass ihre Entwickler geeignete Prozesse zur Erstellung sicherer Software nutzen. Gemeinsam können diese drei Bereiche dafür sorgen, dass die Regeln für Anwendungssicherheit auch auf Open-Source-Komponenten angewandt werden und in die Sicherheitsstrategie einfließen.

Jeff Luszcz

(Bild: Flexera)
VP of Product Management bei Flexera Software

(ku)

Sie möchten gerne weiterlesen?