• Artikel

Die DesktopdateienSicherheit und Einhaltung von Bestimmungen

Wes Miller

Als IT-Experte stehen Sie möglicherweise Zielen gegenüber, die sich ergänzen sollten, aber stattdessen oft miteinander konkurrieren. Sicherheit und die Einhaltung von Bestimmungen sind zwei dieser Ziele einer Organisation, die gemeinsam zu besseren Ergebnissen führen sollten. Leider ist das aber in der Regel nicht der Fall. Ich möchte Ihnen in diesem Artikel

einen Überblick darüber geben, warum Sicherheit nicht immer bedeutet, dass die von Ihnen geforderten Initiativen berücksichtig werden, und warum die Einhaltung von Bestimmungen oftmals bedeutet, dass es keine Sicherheit gibt oder dass die Sicherheit nicht so hoch ist, wie sie sein könnte, wenn die Einhaltung von Bestimmungen wirklich gleichbedeutend mit Sicherheit wäre.

Sicherheit ist keine Option zum Aktivieren

SDL-Ressourcen

Die Einhaltung von Bestimmungen ist in der Regel verbunden mit Anforderungen (Personen, Prozess, Infrastruktur, Technologie usw.), die einer Organisation, einer Branche, einem Unternehmen oder einem Produkt von außen auferlegt werden. Manchmal geht es bei der Einhaltung von Bestimmungen um Standards, die eine Branche (wie z. B. bei Datensicherheitsstandards der Kreditkartenbranche) selbst eingeführt hat. Im Idealfall sind dies Initiativen, die (zumindest zu einem gewissen Grad) bereits auf die Arbeitsweise Ihrer Organisation ausgerichtet sind. Wenn sich ein Standard durchsetzt, werden Sie ihn nicht ignorieren können, sofern Sie weiterhin im Geschäft bleiben wollen. Letztendlich müssen Sie den Standard auch bei sich implementieren und das Beste daraus machen.

Es gibt eine andere Art der Einhaltung von Bestimmungen, die meist problematischer ist. Ich beziehe mich hier auf Initiativen der US-Regierung wie z. B. den Health Insurance Portability and Accountability Act (HIPAA) und Sarbanes-Oxley, bei denen eine Implementierung und der Zeitpunkt dafür selten frei wählbar sind.

Der wichtige Punkt bei der Einhaltung gesetzlicher Richtlinien ist, dass dabei oftmals ein Top-Down-Ansatz zum Einsatz kommt. In der Regel gibt es eine Schablone, die die Initiative definiert, und Sie müssen sich Ihre Produkte und Prozesse anschauen und einen Weg finden, wie Sie sie in diese Schablone einpassen können. Sie müssen sich zu jedem Zeitpunkt nicht nur über den Zweck der Einhaltungsinitiative im Klaren sein, sondern auch (was vielleicht noch wichtiger ist) über die eventuellen rechtlichen oder finanziellen Konsequenzen, wenn Sie die Initiative nicht oder nicht richtig einhalten.

Auch wenn wir dem Zweck vieler Einhaltungsinitiativen zustimmen, ist eine Implementierung oft schwierig und erreicht u. U. nicht das gewünschte Ziel. Außerdem sind viele leider wirkungslos (d. h. es gibt keine direkten rechtlichen oder finanziellen Konsequenzen, die bei einer Nichterfüllung auferlegt werden können).

Als Patient kann ich den Nettonutzen von HIPAA für mich nicht vollständig beschreiben. Was ich Ihnen aber sagen kann, ist, dass ich bei einem Arztbesuch viel mehr Formulare ausfüllen muss. Aber noch schlimmer sind vielleicht die unbeabsichtigten Konsequenzen. Haben Sie schon einmal versucht, Ihren Arzt zu bitten, wichtige medizinische Informationen an einen anderen Arzt weiterzuleiten? Wenn hierfür keine schriftliche Erlaubnis vorliegt, passiert gar nichts, egal, wie dringend die Informationen benötigt werden.

Was ich damit sagen will, ist, dass einige Einhaltungsinitiativen bürokratische Aktionen ohne tiefern Sinn darstellen. Sie entwickeln oder ändern Ihren Prozess oder Ihr Produkt in diesem Fall nur, um die Initiative zu erfüllen. Ich frage mich in diesen Situationen oft, ob das überhaupt Sinn macht.

Sicherheit ist dagegen eine Bottom-Up-Initiative, wenn sie richtig angegangen wird. Ob Sie nun ein Softwareprodukt oder die Architektur für das neue Netzwerk Ihrer Organisation entwickeln: Vergessen Sie nie das Grundprinzip „zweimal messen, einmal schneiden“. Wenn Sie beispielsweise Produktarchitektur entwickeln, beschreiben Sie zunächst auch Kommunikation, Lokalisierung, Versionen und so weiter. Sie sollten dabei aber auch die Sicherheitselemente beschreiben, die vom ersten Tag an in die Anwendung integriert werden müssen (und Sie sollten diese Elemente während der Entwicklung im Auge behalten und optimieren).

Wenn Sie mit Anwendungen oder Architekturen arbeiten, die nicht von Ihnen entwickelt wurden (das ist sicherlich bei den meisten von Ihnen der Fall), ist es ebenso wichtig, eine detaillierte Sicherheitsprüfung durchzuführen, die ich oft in dieser Rubrik erwähne. Wenn Sie nicht verstehen, wie etwas funktioniert, wie können Sie dann wissen, wie sicher etwas ist? Mehr zum Microsoft®-Sicherheitsentwicklungszyklus (Security Development Lifecycle, SDL) finden Sie in der Randleiste unter „SDL-Ressourcen“.

Das große Ganze

Ich erinnere mich noch daran, dass mir am Anfang einmal jemand gesagt hat, dass Sicherheit nicht einfach mit der Implementierung von Verschlüsselung, Zugriffssteuerungslisten oder TLS oder einer Public Key-Infrastruktur (PKI) gleichzusetzen ist. Bei echter Sicherheit geht es darum, das große Ganze im Auge zu haben und zu verstehen: Man muss verstehen, warum eine Version eines Protokolls nicht mehr verwendet wird oder sogar nie unterstützt wurde, warum dieses neue Sicherheitselement vor Man-in-the-Middle-Angriffen schützt, weshalb Ihre Implementierung für Produktversion 2 viel sicherer als die für Version 1 ist, selbst wenn Version 1 viel schneller war. Man muss auch verstehen, wie die einzelnen Teile Ihrer Infrastruktur zusammenpassen.

Einhaltung von Bestimmungen dagegen bedeutet, sich Ihre Technologie vorzunehmen und sicherzustellen, dass die von Ihnen entwickelte Infrastruktur bestimmte Kriterien erfüllt. Einige Initiativen wie z. B. die Datensicherheitsstandards der Kreditkartenbranche oder Bestimmungen zur Sicherheit elektrischer Geräte sind gut gemeint und führen vielleicht zu echten Sicherheitsänderungen. Aber letztendlich verlieren Sicherheitsinitiativen bei dem Sammelsurium an „Einhaltungsinitiativen“, die Sie mit Ihren begrenzten Ressourcen bei Ihren eigenen spezifischen Projekten berücksichtigen müssen, an Boden.

Sicherheit ist schon seit langem das Stiefkind der Softwareentwicklung. Bestimmt haben viele von Ihnen in Organisationen gearbeitet, in denen Sicherheit etwas war, „um das man sich später kümmern würde“. Nun ja, Einhaltungsinitiativen werden hierbleiben, weil die Philosophie, dass Sicherheit warten kann, nicht funktioniert und nie funktioniert hat.

Gut genug

Ich habe vor kurzem die Stelle gewechselt. Ich arbeite jetzt für ein Startupunternehmen hier in Austin, Texas, das eine Anwendungswhitelisting-Technologie ähnlich der Technologie entwickelt, die wir bei Winternals mit unserem Protection Manager entwickelt haben. Was ich dabei sehr interessant finde, ist, mit Kunden darüber zu reden, für wie sicher sie ihre aktuellen Technologien halten bzw. wie sicher die von ihnen verwendete Technologiesuite ihre Infrastruktur ihrer Meinung nach macht. Es ist zwar sehr wahrscheinlich, dass die meisten Technologien sicher sind und in ihnen keine Sicherheitslücken klaffen, aber der Kommentar, den ich oft zu hören bekomme und bei dem mir immer ein Schauer über den Rücken läuft, ist, dass ein System „sicher genug“ ist.

Einhaltungsinitiativen sind merkwürdig: Sie können sie erfüllen oder nicht. Die Verantwortung tragen Sie. Die Kosten für die Nichterfüllung einer Initiative sind meist eine Geldstrafe, eine Vertragsstrafe oder der Ausschluss aus einer Organisation. Oftmals reicht es nicht, nur sicherzustellen, dass sich etwas wirklich ändert.

Bei behördlichen Initiativen begegne ich regelmäßig der Haltung „gut genug für den Prüfer“ oder der Bereitwilligkeit, ohne ein Einhaltungsframework zu arbeiten, weil die entsprechende Gesetzgebung (wie z. B. HIPAA) die Bestimmung nicht richtig durchsetzt, was bedeutet, dass es viel billiger ist, keine entsprechenden Maßnahmen zu implementieren und dafür spätere potenzielle Folgen in Kauf zu nehmen.

Sicherheit bewegt sich oft in die gleiche Richtung, ist aber meiner Meinung nach konkreter. Wenn Sie als Entwickler oder Implementierer Ihrer Geschäftsführung sagen, dass das Produkt am Markt potenziell mehr Sicherheitsrisiken ausgesetzt sein kann, wenn ein bestimmter Punkt nicht in die Spezifikation aufgenommen wird, können Sie zumindest später, wenn das Produkt auf dem Markt ist oder Sie es bereitgestellt haben, sagen: „Darauf habe ich von Anfang an hingewiesen.“ Meiner Erfahrung nach werden Einhaltungsinitiativen oft zu hastig und mit dem kleinstmöglichen Budget umgesetzt. Das Ziel hierbei ist, nur die Mindestanforderungen der Initiative zu erfüllen und damit vielleicht die Initiative so wie sie auf dem Papier steht zu erfüllen, was aber meiner Meinung nach nicht dem Geist der Initiative entspricht.

Analysieren Ihrer Situation

Ressourcen zur Sicherheit und zur Einhaltung von Bestimmungen

Es ist wahrscheinlich idealistisch, wenn ich Ihnen sage, dass Sie Ihr Produkt und Ihre Organisation so sicher wie möglich machen sollten, aber die Realität ist, dass die meisten Einhaltungsinitiativen einen Kompromiss infolge schlechter Entwicklungsarbeit oder noch häufiger aufgrund von Bequemlichkeit darstellen. Wir leben in einer Welt, in der „gut genug“ leider gut genug ist. In der Welt der Sicherheit ist „gut genug“ allerdings selten eine weise Entscheidung. Wir, die IT-Experten der Welt, nehmen uns vielleicht Einhaltungsinitiativen zu Herzen und versuchen, sie sowohl nach dem Wortlaut als auch ihrem Geiste nach umzusetzen, und müssen gleichzeitig dafür sorgen, dass die von uns eingerichtete Infrastruktur nicht nur so sicher ist, wie sie sein darf, sondern so sicher, wie sie sein sollte. Anders ausgedrückt: Erfüllen Sie Richtlinien durch echte Sicherheit, nicht nur dadurch, dass Sie die Initiative erfüllen.

Es ist hierbei wichtig, einen Schritt zurückzutreten und sich die Technologie anzusehen, die Sie entwickeln, egal, ob es sich hierbei um kommerzielle Software oder um eine Technologiesuite handelt, die Sie in ein größeres System integrieren möchten. Ich kann gar nicht oft genug betonen, wie wichtig es ist, die einzelnen Komponenten des Systems zu verstehen, wie sie alle zusammenarbeiten und welchen größeren Risiken Ihr System ausgesetzt ist.

In Abhängigkeit von der Branche, in der Sie arbeiten, spielen bei Ihrer Arbeit wahrscheinlich unterschiedliche Einhaltungsinitiativen eine Rolle. Eventuell begegnen Sie ihnen tagtäglich oder nur, wenn Sie neue Projekte oder Technologien entwickeln. Vielleicht sind sie nur Teil Ihrer Arbeit, wenn entsprechende Überprüfungen bevorstehen. Egal. Ich bin der Meinung, dass Einhaltungsinitiativen nicht ignoriert werden sollten, aber ich möchte Sie auffordern, den Status Quo in Frage zu stellen und statt nur auf das Ziel hinzuarbeiten, die Ihnen zugewiesenen Einhaltungsinitiativen zu erfüllen, eine vollständige Sicherheitsprüfung durchzuführen, um Ihre Technologie richtig zu verstehen, und die Technologie zum gleichen Zeitpunkt wie Ihre Einhaltungsprüfung zu modellieren.

Was haben Sie zu verlieren?

Letztendlich sind die Strafen für die Nichterfüllung einer Einhaltungsinitiative nicht hundertprozentig klar. Wenn Sie eine Initiative nicht einhalten, setzen Sie sich genau dem Risiko aus, vor dem die Initiative Sie schützen soll. Die Konsequenzen erscheinen vielleicht vage und nicht akut, sie sind aber real. Es handelt sich bei ihnen vielleicht auch nicht um persönliche Konsequenzen. Seien Sie pragmatisch, aber denken Sie immer auch an den schlimmsten Fall.

Wenn Sie einen Prozess oder ein Produkt vom Standpunkt der Sicherheit aus betrachten, sollte die Bedrohung offensichtlich sein und, was noch wichtiger ist, Sie sollten sofort die potenziellen Kosten sehen, die entstehen können, wenn die Sicherheitslücke nicht geschlossen wird.

Viele Personen, mit denen ich über dieses Thema gesprochen habe, haben mir gesagt, dass Einhaltungsinitiativen manchmal unter den Teppich gekehrt werden, weil sie oft ziemlich viel Raum für Interpretationen lassen. Nachdem Sie eine Sicherheitsprüfung durchgeführt haben, dürfte dies aber nicht mehr der Fall sein. Die unmittelbaren Sicherheitslücken müssten deutlich sichtbar sein. Wenn sie es nicht sind, sollten Sie sich vielleicht noch einmal überlegen, wen Sie in Ihre Sicherheitsprüfungen involvieren. Vielleicht fehlen wichtige Teammitglieder, die helfen können, die eigentlichen Probleme in Ihrer Lösung zu finden.

Wenig Erfolg

Im letzten Jahr habe ich zum Thema Sicherheit den Beitrag „So behalten Sie Ihre Daten“ (technet.microsoft.com/magazine/cc162325) geschrieben. Seitdem ist ein Jahr vergangen, mehr Systeme sind beschädigt worden, mehr unverschlüsselte Laptops sind verloren gegangen und mehr persönliche Informationen sind in fragwürdige Hände gefallen. Es ist schwer zu sagen, ob überhaupt Fortschritte gemacht wurden. Warum befinden wir uns immer noch in dieser Situation? Projekte werden oft nicht innerhalb des vorgegebenen Zeitrahmens erledigt, die Projektbudgets sind zu klein, die Ressourcen sind überlastet, und es wird versucht, zu viele Features in einem zu engen Zeitrahmen zu liefern.

Derartige Situationen führen leider dazu, dass nur die minimal notwendige Arbeit erledigt wird. Das ist sicher nicht der richtige Weg, um dafür zu sorgen, dass eine Lösung sicher ist und die Bestimmungen erfüllt und außerdem nicht verhindert, dass das Projekt innerhalb des festgelegten Zeitrahmens und des Budgets abgeschlossen wird.

Ich persönlich bin folgender Meinung:

  1. Sie sollten keine Lösung entwickeln, wenn Sie nicht bereit sind, sie zu sichern.
  2. Jedes Mal, wenn Sie neue Features hinzufügen, müssen Sie zuerst die Sicherheitselemente entwickeln.
  3. Wenn Ihre Organisation nicht bereit ist, Sicherheit als einen Schritt in Ihren Entwicklungsprozess einzubinden, sollten Sie die Gesamtziele Ihres Unternehmens oder Ihrer Organisation hinterfragen.

Organisationen verfügen zunehmend über Kunden- oder Partnerdaten, für deren Datenschutz sie verantwortlich sind. Leider leben wir in einer Welt, in der Sicherheit zu oft nicht selbstverständlich ist und Mitarbeiter es oft nicht wagen, die Sicherheitsrichtlinien ihrer Organisation zu hinterfragen.

Viel zu häufig wird das Thema Sicherheit erst angegangen, nachdem persönliche Daten von Kunden, Studenten, Patienten und Mitarbeitern gestohlen wurden bzw. nachdem das Unternehmen oder die Organisation finanzielle Verluste erlitten hat. Die Nichteinhaltung von Bestimmungen wird dabei gar nicht erwähnt.

Wir müssen alle zu viel, oftmals für zu wenig Geld und gewöhnlich in einer zu kurzen Zeit erledigen. Als IT-Experten sind wir aber dafür verantwortlich zu hinterfragen, warum Sicherheit nicht den Schwerpunkt bildet und warum die Geschäftsführung nur dann über Sicherheit nachdenkt, wenn es Einhaltungsinitiativen gibt oder, was wahrscheinlicher ist, wenn eine Sicherheitsverletzung mit realen oder potenziellen rechtlichen Konsequenzen eingetreten ist (was die Organisation in eine peinliche Lage bringen oder sogar gefährden könnte).

Nehmen Sie meine Aufforderung an

Mein Hauptanliegen ist, Sie aufzufordern, den Status Quo zu hinterfragen. Wenn Sie damit beauftragt werden, nur die Einhaltungsziele zu erfüllen, sorgen Sie dafür, dass Sie nicht nur Zeit verschwenden, um das Sicherheitskonzept von jemand anderem zu erfüllen. Ihr Ziel muss darin bestehen, das System zu sichern und dabei den Prozess oder Ihre Infrastruktur so zu gestalten, dass die Einhaltungsinitiative erfüllt wird. Weitere Informationen zu diesem Thema finden Sie in der Randleiste „Ressourcen zur Sicherheit und zur Einhaltung von Bestimmungen“.

Um es auf den Punkt zu bringen: Denken Sie daran, dass Einhaltung von Bestimmungen allein oft nicht reicht, um ein System wirklich sicher zu machen. Wenn dagegen Sicherheit richtig implementiert und instrumentiert wird, sind Sie oftmals schon auf dem richtigen Weg, die Bestimmungen einzuhalten.

Wes Miller ist Senior Technical Product Manager bei CoreTrace (www.CoreTrace.com) in Austin, Texas. Zuvor war er bei Winternals Software sowie als Programmmanager bei Microsoft tätig. Sie können Wes Miller unter technet@getwired.com erreichen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.