Kennzeichen S(icherheit): An Ausbildung führt kein Weg vorbei
Dass weitverbreitete Webtechniken immer noch gut für Sicherheitslücken zu haben sind, geht auch in die Verantwortung des Anwendungsentwicklers. Hilfreich ist hierfür der Erwerb neuer Personal- oder (Qualifizierungs-)Zertifikate für sichere Softwareentwicklung.
- Sachar Paulus
- Alexander Neumann
Dass weitverbreitete Webtechniken immer noch gut für Sicherheitslücken zu haben sind, geht auch in die Verantwortung des Anwendungsentwicklers. Hilfreich ist hierfür der Erwerb neuer Personal- oder (Qualifizierungs-)Zertifikate für sichere Softwareentwicklung.
Kennzeichen S(icherheit)
In der neuen "Kennzeichen S(icherheit)"-Kolumne auf heise Developer setzen sich die Analysten des Unternehmens KuppingerCole in regelmäßigen Abständen mit Themen wie Identity- und Access Management sowie IT-Governance aus Softwareentwicklungsperspektive auseinander. Es geht vor allem um die Frage, wie man Sicherheit für Anwendungen standardisieren und externalisieren kann, um Sicherheit und Nachvollziehbarkeit bei optimiertem Entwicklungsaufwand zu erreichen.
Die aktuellen Sicherheitsprobleme beim TLS-Protokoll (Transport Layer Security) decken es schonungslos auf: Weitverbreitete Techniken für moderne Anwendungen sind immer noch für einfache Sicherheitlücken zu haben, insbesondere unter Verwendung von Webservices und mit Ausrichtung auf Cloud Computing. Leider reagieren viele Anwendungsentwickler mit dem Hinweis, dass das nicht "ihr" Problem sei und die Technik ihre Löcher "selbst zu stopfen" habe.
Das ist Unsinn. Der Anwendungsentwickler – ob im Kontext einer Ein-Mann-Bude oder eines Weltkonzerns – ist für die Wahl der Technik verantwortlich und dadurch auch für die damit einhergehenden Sicherheitsprobleme. Erst kürzlich wurde in Fachkreisen über ein neues, ernsthaftes Problem für betriebswirtschaftliche Standardsoftware über Cross-Site-Request-Forgery-Techniken gemunkelt. Dabei verlässt sich die Software auf Standardsicherheit, handelt sich aber ein Einfallstor durch das Web ein – und steht damit im Regen. Auch die TLS-Schwachstelle ist für webbasierte Business-Software eine ernsthafte Bedrohung.
Natürlich kann man den Anwendungsentwickler nicht für die Sicherheitsprobleme der Technik verantworten. Andererseits ist aber genau genommen er der einzige, der das Risiko für seine Applikation tatsächlich einschätzen kann: Was sind die "Assets", wer sind potenzielle Angreifer, welche wahrscheinlichen Angriffsvektoren gibt es? Eine "Externalisierung" von Sicherheitsfunktionen ergibt genau dort Sinn, wo sich die Erwartung an eine bestimmte zu liefernde Sicherheitsfunktion genau beschreiben lässt: Das funktioniert schon leidlich für die Verschlüsselung von Daten (XML-ENC & Co.), für das Identitätsmanagement (LDAP und die einschlägigen Klassen bei Java EE) und für die Authentifizierung (SAML, OAuth usw.). Für andere Bereiche sind die sogenannten "Security Patterns", die sich für Externalisierung eignen, noch nicht so weit gediehen.
Letztlich bleibt nichts anderes übrig, als die Anwendungsentwickler entsprechend auszubilden. Es gibt hierfür sogar zwei (konkurrierende) Standards: zum einen den CSSLP (Certified Secure Software Lifecycle Professional) der US-amerikanischen Security-Spezialisten (ISC)2, die auch CISSP (Certified Information Systems Security Professional) verantworten, und den aus Deutschland stammenden ISSECO CPSSE (Certified Professional für Secure Software Engineering), der sich aus der Software-Qualitätsecke herausgebildet hat (Zertifizierer ist iSQI).
Beiden ist gemein, dass sie sich den Best Practices für die Prozessgestaltung bei der Softwareentwicklung annehmen, um Sicherheitslücken früh zu beseitigen – beispielsweise mit Threat Modeling – und bis zum Ende zu begleiten, inklusive sicherer Konfiguration beim Installieren der Software und Security Response, also dem Reagieren auf Sicherheitsprobleme, die in der Software gefunden werden. ISSECO widmet sich darüber hinaus Security Patterns, die sich zur Externalisierung eignen.
Eines der oben beschriebenen Zertifikate – welches ist im Grunde gleichgültig – sollten Anwendungsentwickler haben und Kunden fordern. Erst dann finden sich etablierte Sicherheitskonzepte wie "Defense in Depth" und "Input & Output Validation", die viele der aktuell diskutierten Probleme geringer in ihrer Wirkung erscheinen lassen, auch in Anwendungssoftware wieder.
Sachar Paulus ist Senior Analyst bei Kuppinger Cole, einem auf IAM, GRC, Cloud Computing und verwandten Themen spezialisierten Analystenunternehmen. (ane)
