Microsoft Developer Days

Software sicherer entwickeln

12. Juli 2006, 23:15 Uhr | Johann Baumeister/wj

IT-Sicherheit muss sich schon in der Konzeption von Anwendungssoftware niederschlagen, weil klassische Security-Konzepte modernen Bedrohungen nicht mehr gewachsen sind. Microsoft erweitert deshalb sein Entwicklungs- und Evaluierungsmodell.

Ein Mehr an Sicherheit in der IT entsteht heute erst durch das Zusammenspiel von
Softwareentwicklern, Administratoren und Benutzern – dies war das Mantra, das Microsoft während
seiner Developer Days im Mai beständig wiederholte.

Die Basistechniken der IT-Sicherheit, wie etwa die klassischen Firewalls, sind auf Angriffe über
den prinzipiell offenen Webkanal nicht ausgelegt, weshalb die gewohnten Methoden der IT-Sicherheit
schrittweise umgestellt werden müssen. Dies gilt für die Netze selbst, ihre Protokolle, die
Datenbanken, die Programmiersprachen und all ihre Werkzeuge. Eine einfache Nachrüstung von
Sicherheitsfunktionen gelingt allerdings nicht überall. Daher ist mehr Sicherheit bei den
Anwendungen nur im Zusammenspiel aller an der IT-Sicherheit beteiligten Disziplinen zu erreichen.
Dies wird auch deswegen notwendig, weil Angreifer mittlerweile alle Ebenen nach ISO/OSI-Modell
nutzen. Die Palette reicht vom Ping of Death, DoS-Attacken oder Sniffing auf der Netzwerkebene über
Angriffe auf Applikationsplattformen durch Buffer Overflows und SQL Injections bis hin zu
Phishing-Angriffen auf die Benutzer.

Die Maßnahmen beginnen nach Microsoft schon bei den Anforderungen an ein IT-Produkt, die häufig
in einem Requirements-Modell beschrieben sind. Microsoft will dieses Modell im Rahmen seiner
Dynamic System Initative (DSI) erweitern.

DSI soll alle Phasen von der Modellierung über die Programmierung, die Testphase, den Rollout
und auch den Einsatz in der IT-Administration erfassen. Wird etwa in einer Servicevereinbarung
(SLA) eine bestimmte Reaktionszeit oder minimale Benutzeranzahl festgelegt, gelten diese
Anforderungen bereits als Kriterium für die Entwicklung. Dies war prinzipiell zwar schon immer so,
konnte aber selten in der von DSI geforderten Konsequenz umgesetzt werden. Der Ansatz von DSI ist,
möglichst viel Wissen über die entwickelte Applikation und ihren Betrieb in diese Modelle
einzubinden. Dazu zählen Laufzeitbedingungen, Installationsabläufe oder Abhängigkeiten von weiteren
IT-Bausteinen. DSI bringt diese Definitionen in eine standardisierte Form, das Service Definition
Modell (SDF). Das SDF wiederum beschreibt die Anforderungen der Applikation und dient als
Kommunikationsmittel zwischen Entwicklung und Administration.

In die Modelle einfließen werden außerdem Laufzeitparameter für die Applikati-onen. Dazu gehören
die Version des Betriebssystems und der Service-Packs, Definitionen der Datenzugriffspfade (JDBC,
ODBC) und der Datenbanken sowie Infrastrukturdienste wie etwa Pfade, Berechtigungen oder
Namensdienste wie DNS.

Aus den Modellen soll die optimale Konfiguration abgeleitet werden. Dieses als "Desired State
Management" bezeichnete Verfahren beschreibt den Sollzustand des Gesamtsystems, während der
Ist-Zustand von den erneuerten und in Zukunft erweiterten Modulen des System Centers überwacht
werden muss. Hierbei spielt der Microsoft Operations Manager (MOM) eine zentrale Rolle, der Systems
Management Service (SMS) wird erweitert und umbenannt in "Configuration Manager". Neu ist der
Virtual Machine Manager. Darüber hinaus soll der Capacity Manager, der heute nur für Exchange 2003
und MOM 2005 verwendet werden kann, für weitere Serversysteme herangezogen werden können.

Neben diesen mittelfristigen Perspektiven diskutierte man auf den Developer Days auch aktuelle
Maßnahmen. Fast schon selbstverständlich sind die Aufforderung, Benutzer nicht in die Gruppe der
lokalen Admins aufzunehmen, mit minimalen Berechtigungen zu operieren, keine Dateien in den
kritischen Programmpfaden wie etwa "Systemroot" oder bei den Programmdateien abzulegen, diese Pfade
zu schützen und Patches regelmäßig einzuspielen.

Darüber hinaus empfahl man Netzwerksegmentierung und den Einsatz von Firewalls, die auch auf
Applikationsebene (Layer 7) operieren. Immer einbezogen werden muss außerdem "Layer 8": Der
Benutzer.


Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Lampertz GmbH & Co. KG

Matchmaker+