|
|
Rubrik: Fachbeiträge/Grundlagen Schwachstellenfreie Programmierung: Sicherheit im Software-Entwicklungszyklus Webapplikationen gleichen heute offenen Scheunentoren mit einem groß blinkenden Schild: "Bitte Eintreten" (
Anzeige
Von Michael Kristen, IBM Rational Software Technical Sales Trotz dieser Gefahr werden immer noch 90 Prozent aller IT-Ausgaben für die IT-Sicherheit in die Netzwerkebene investiert. Nur zehn Prozent dienen der Absicherung der Applikationsebene. Vor diesem Hintergrund scheint es nicht verwunderlich, dass bis 2010 rund 80 Prozent aller Unternehmen mit Sicherheitsvorfällen in ihren Webanwendungen und -diensten rechnen müssen. Fraglich bleibt, ob die betreffenden Unternehmen die Angriffe auch bemerken werden.
Ausgabenverteilung für IT Sicherheit Meist sind es immer die gleichen Argumente mit denen Unternehmen mangelnde Sicherheitsinvestitionen rechtfertigen: - Wir haben kein Budget - Wir haben bereits Firewalls und SSL-Verschlüsselung im Einsatz - Wir sind nicht interessant genug für Hacker Die Gefahr ist unmittelbar und geht nicht nur von Angreifern aus asiatischen Ländern aus. Es ist eine neue Generation von Internetnutzern herangewachsen, die mit einer Selbstverständlichkeit die Sprache des Web wie die eigene Muttersprache beherrscht. Eine LAN-Party in den Kinderzimmern kann somit erschreckende Nebenwirkungen hervorrufen. Webanwendungen sind besonders gefährdet Webapplikationen gleichen heute offenen Scheunentoren mit einem groß blinkenden Schild: "Bitte Eintreten". Zahlreiche Studien belegen, dass mehr als 80 Prozent aller sich heute im Internet befindenden Applikationen anfällig gegenüber einfach durchzuführender Attacken sind.
Prozentuale Darstellung von Sicherheitslücken nach Typ (TOP 5) Es fehlt hier sowohl an notwendigen Sicherheitsmaßnahmen als auch am ausreichenden Wissensstand der Mitarbeiter. Rund 70 Prozent aller Unternehmen wenden heute keinerlei Sicherheitstechniken in der Softwareentwicklung an, ermittelte die Aberdeen Group. Web Application Firewalls sind nur ein erster Schritt, um kurzfristig, aber vor allem schnell, auf bestehende Lücken zu reagieren und diese zu schließen. Jedoch ist es damit nicht getan. Laut einer Umfrage von Microsoft Developer Research sind 64 Prozent aller Entwickler unsicher, ob sie die Fähigkeit haben, sichere Applikationen zu schreiben. Sicherlich ist es komfortabler und - auf den ersten Blick auch günstiger - ein Loch in der Hose mit einem Flicken zu stopfen, als eine neue Hose zu kaufen. Beim zweiten oder dritten Loch gilt das vielleicht auch noch. Aber wer will schon eine Hose tragen, die mit mehr Flicken bestückt ist als mit dem eigentlichen Stoff? In der IT besteht die Problematik darin, dass die Entwicklung in der Regel losgelöst agiert und nicht in die Sicherheitsprozesse des laufenden Betriebs eingebunden ist. Eine flüssige Kommunikation zwischen der Entwicklung und den Administratoren ist aber zwingend erforderlich, um eine Zwischenlösung wie beispielsweise eine Web Application Firewall einzuführen. Ebenfalls eintreten kann der Fall, dass die WebApplication Firewall einmal ausfällt und die Schwachstellen in Sekundenschnelle aufgespürt und ausgenutzt werden. Auf lange Sicht hilft es daher nicht, die sichtbaren Symptome zu bekämpfen. Vielmehr muss die Software bereits während der Entwicklung schwachstellenfrei programmiert werden. In einzelnen Branchen hat sich diese Erkenntnis bereits durchgesetzt. Vorreiter sind hier die Banken und Versicherungen. Diese setzen sich traditionell, aber auch aufgrund erhöhter Regularien mit dem Thema Websicherheit stärker auseinander. Am "Stellt eine nichtöffentliche Stelle (...) fest, dass bei ihr gespeicherte (...) Daten (...) unrechtmäßig übermittelt oder auf sonstige Weise Dritten unrechtmäßig zur Kenntnis gelangt sind (...), hat sie dies (...) der zuständigen Aufsichtsbehörde sowie den Betroffenen mitzuteilen. (...) Soweit die Benachrichtigung der Betroffenen einen unverhältnismäßigen Aufwand erfordern würde, insbesondere aufgrund der Vielzahl der betroffenen Fälle, tritt an ihre Stelle die Information der Öffentlichkeit durch Anzeigen, die mindestens eine halbe Seite umfassen, in mindestens zwei bundesweit erscheinenden Tageszeitungen oder durch eine andere, in ihrer Wirksamkeit hinsichtlich der Information der Betroffenen gleich geeignete Maßnahme. (...)" Durch die Wirtschaftskrise ist das Vertrauen der Menschen speziell in das Bankenwesen sowie in die neuen Technologien wie beispielsweise das Online-Banking spürbar gesunken. Die Kosten durch eine fehlende Websicherheit sind daher extrem hoch. Denn die neuen Bestimmungen des Bundesdatenschutzgesetzes führen zu einer erhöhten Kommunikation im Schadensfall. Der Imageschaden sowie der daraus folgende zusätzliche Vertrauensverlust von Kunden schlägt sich anschließend finanziell nieder. Wie schütze ich meine Webauftritte effektiv vor Angriffen von außen und innen? Sicherheit fängt bei den Anforderungen an. Unabhängig davon, ob man Software als Unternehmen selbst entwickelt oder außer Haus entwickeln lässt. Konkrete Anforderungen an die Sicherheit müssen schon vorab definiert werden. Hierunter fällt beispielsweise die ausführliche Definition von Berechtigungen bis hin zu einem stimmigen Validierungskonzept. Security ist aus Erfahrung kein Thema, das sich nebenbei erledigen lässt. Eine wesentlich höhere Bewusstseinsbildung erfährt ein Unternehmen dann, wenn Verantwortliche speziell für das Thema Websicherheit beauftragt werden, die interne Prozesse definieren und die Umsetzung überwachen. Daneben sind geeignete Schulungsmaßnahmen ein wesentliches Erfolgskriterium.
Sicherheit im Softwareentwicklungszyklus Doch wann sollte eine Applikationen hinsichtlich der Sicherheit getestet werden? White-box oder Black-box Testing? Mit Sicherheit ist dies keine Philosophiefrage. Beide Varianten nähern sich der Thematik von zwei verschiedenen Richtungen und haben ihre Vor- und Nachteile.
Gegenüberstellung Blackbox / Whitebox Empfehlenswert ist, eine Kombination aus beiden Varianten einzusetzen, d.h. erste Überprüfungen während der Entwicklung und bei der Abnahme von fertigen Webseiten durchzuführen. Daraus ableitend kann eine weitere Strategie entwickelt werden. Aufgrund der Vielzahl an Schwachstellen sowie aus Zeit und Kostengründen ist der Einsatz von automatisierten Tools zwingend erforderlich. Ein Entwickler kann, nachdem er ein Modul fertiggestellt hat, dieses Modul direkt testen und Fehler sofort beheben. Im Rahmen eines automatisierten Builds bietet sich die Möglichkeit, automatisiert Black- oder White-box-Tests durchzuführen und bei Bedarf den Build-Prozess zu stoppen, sollte die Anforderung an die Sicherheit nicht ausreichend erfüllt sein. Bevor eine Applikation in die Produktion geht, ist es essentiell, diese in der Qualitätssicherung bzw. in einer separaten Testphase hinsichtlich ihrer Sicherheit zu überprüfen. Bei bestehenden, sich bereits in Produktion befindlichen Applikationen, können die notwendigen Sicherheitstests ebenfalls durchgeführt werden, wenngleich mit entsprechend sorgsamerer Vorbereitung und Sicherungsmaßnahmen. Konsequentes Qualitätsmanagement spart Geld Letzten Endes greift auch hier der Satz aus dem Qualitätsmanagement: "Je früher, desto günstiger". Ein Entwickler, der eine Sicherheitslücke bereits während der Entwicklung entdeckt und diese schließt, spart bares Geld gegenüber dem Entwickler, der den Fehler beheben muss, nachdem ihn das interne Auditteam eine Woche vor der Liveschaltung über die gefundenen Fehler informiert. Die bei den Sicherheitstests gefundenden Schwachstellen müssen anschließend validiert werden und können über eine entsprechende Anbindung an ein Defect Tracking-System an die Entwicklung übergeben werden. Eine Sicherheitslücke ist auch nur ein Qualitätsdefekt wie ein nicht reagierender Knopf auf einer Programmoberfläche. Neben der Auswahl von geeigneten Scanwerkzeugen sowie der Definierung von Sicherheitspro-zessen sind weitere Maßnahmen zu berücksichtigen. Schulungsmaßnahmen für Entwickler und Security-Mitarbeiter stehen hier an erster Stelle. Frei nach dem Motto "A fool with a tool is still a fool" sollte schon parallel mit der Einführung der Werkzeuge an der Verbesserung des Wissenstandes der am Entwicklungsprozess beteiligten Personen gearbeitet werden. Der Einsatz von Web Application Firewalls und Intrusion Detection/Prevention-Systeme bieten einen kurzfristigen, jedoch nur scheinbar einfachen Schutz. Dieser führt nicht zu einer ganzheitlich sicheren Umgebung, sondern er dient lediglich dem sofortigen Schließen von Lücken der sich bereits in Produktion befindlichen Applikationen. Ein Tool hat immer seine Grenzen. Auch automatisierte Tools, die nach Schwachstellen scannen, können keine menschliche Logik nachbilden. Daher empfiehlt es sich, nachdem eine Applikation die verschiedenen Stufen des Entwicklungszyklus durchlaufen hat, diese vor Inbetriebnahme durch zusätzliche manuelle Penetration-Tests hinsichtlich logischer Schwachstellen zu überprüfen. Anwendungssicherheit End-to-End Auf dem Gebiet der Sicherheit von Webanwendungen ist die IBM der einzige Anbieter auf dem Markt, der seine Kunden von der Definition der Anforderungen über alle Stufen des Software-entwicklungszyklus hinweg bis hin zur produktiven Webumgebung unterstützt. IBM Rational AppScan End-to-End Anwendungssicherheit Mit "AppScan Source Edition" (ehemals Ounce Labs) bietet IBM Werkzeuge auf dem Gebiet des White-box Testings an. Hervorzuheben ist die Einbindung in die unterschiedlichsten Build-Systems. Mit "AppScan Standard & Enterprise Edition" (ehemals Watchfire) bietet IBM zudem Black-box-Scanning an: In der Standard-Edition als Desktop-Version und in der Enterprise Edition als zentralisierte, unternehmensübergreifende Lösung, die auch als Software-as-a-Service (SaaS) angeboten wird. Lesen Sie zum Thema "Software-as-a-Service" auch: SaaS-Magazin.de (www.saasmagazin.de) Eine Einführung der unterschiedlichen Tools sollte schrittweise erfolgen, um einer Anpassung von Unternehmensprozessen genügend Spielraum zu geben. Die Einführung der AppScan Suite sollte aus Erfahrung in folgenden Schritten erfolgen: · Stufe 1: Start mit der AppScan Standard Edition. Eine kleine Anzahl von Nutzern überprüft bestehende Anwendungen und gibt die kritischsten Fehler zur sofortigen Behebung an die Entwickler weiter · Stufe 2: AppScan Standard Edition wird zur Abnahme fertiger Webanwendungen vor deren Deployment genutzt · Stufe 3: Entwickler testen ihren Quellcode zusätzlich zu den Black-box-Tests bereits während des Entwicklungsprozesses mit der AppScan Source Edition. Durch Black-box-Testing und White-box-Testing haben Sie eine höchstmögliche Sicherheit der Webanwendungen bei gleichzeitiger Einhaltung von Projektterminen. · Stufe 4: Zentralisiertes Reporting per Web über die AppScan Enterprise Edition / Reporting Console. Sämtliche Scanergebnisse werden zentral verwaltet und den am Entwicklungsprozess Beteiligten zugänglich gemacht. Durch diesen Ansatz können die relevanten Informationen in Echtzeit an das Entwicklungsteam sowie an die Projektverantwortlichen verteilt werden · Stufe 5: Vollständig integrierte und automatisierte Security-Tests bereits im Build-Prozess Wie lange ein Unternehmen für die Umsetzung der einzelnen Stufen braucht, ist stark vom jeweiligen Unternehmen abhängig. Es sind vor allem die Prozesse und Verantwortlichkeiten im Unternehmen, die darüber entscheiden, wie schnell IT-Sicherheitsstrategien umgesetzt werden können. Viele Unternehmen haben bereits erkannt, dass durch eine Verbesserung ihrer Websicherheit nicht nur bestehende Regularien eingehalten werden können, sondern hierdurch auch ganz gezielt Wirtschaftsspionage begegnet wird. Dieses Bewusstsein gilt es weiter zu schärfen. Denn wer wissend, dass jede Webanwendung anfällig gegenüber Hackerangriffen ist, nicht regelmäßig seine Webapplikationen auf Sicherheitslücken überprüft, handelt je nach Bedeutung dieser Anwendung fahrlässig oder grob fahrlässig. (IBM: ra) |
|||||||||||||||||||||
|
