am 27. Mai 2009
Ich habe eine Weile überlegt welches Thema ich für meinen ersten Beitrag hier im Blog nehmen soll. Da bei phphatesme ja viel und gerne über Entwurfsmuster geschrieben wird und ich beruflich als Softwarearchitekt / Security-Analytiker tätig war dachte ich mir, ich versuch euch mal die nicht so verbreiteten Security Patterns näher zu bringen. Ihr werdet vielleicht Anfangs beim Lesen denken: „Das klingt (hoffentlich) alles interessant aber dafür habe ich eigentlich keinen Verwendungszweck“. Ich werde im letzten Teil aber versuchen aufzuzeigen wie und wieso jeder Entwickler von Security Patterns profitieren und diese anwenden kann auch wenn die Beispiele hier vielleicht persönlich nicht zutreffen.
Was sind Security Patterns?
Am wichtigsten ist es zu erst ein mal zu verstehen, dass sich Security Patterns von den klassischen Patterns in so fern unterscheiden, dass es eigentlich gar keine richtigen Design Patterns sind. Die Intention die sich hinter diesen Patterns verbirgt ergibt sich am besten aus einem Bezug zur Realität. Stellen wir uns eine große Firma vor in der wir nun zwei Abteilungen in unseren Fokus nehmen. Die Entwicklungs-Abt. und die Security-Abt. . Beide Abteilungen arbeiten gemeinsam an einem Projekt für eine interne Verwaltungssoftware, jedoch mit zwei unterschiedlichen Prioritäten. Während sich die Entwicklungsabteilung überwiegend um die Funktionalität Gedanken macht, beschäftigt sich die Securityabteilung vorwiegend damit, das festgesetzte Sicherheitsrichtlinien eingehalten werden und prozessbegleitend Sicherheitslücken vorzeitig erkannt und darauf regiert werden kann. Ein in sich übergreifender Prozess bei dem Konflikte durch die unterschiedlichen Prioritäten vorprogrammiert sind. Hier greifen die Security Patterns ein. Sie sollen einen Konsens zwischen den unterschiedlichen Prioritäten und Expertisen schaffen und einen flüssigen Entwicklungs- und Kontrollprozess garantieren. Da wir die Frage nach dem Was geklärt haben können wir uns nun dem Wie widmen.
Wann entwirft man Security Patterns?
Greifen wir unser Szenario von eben wieder auf. Logischerweise sollten die Security Patterns bereits vorhanden sein, bevor der eigentliche Entwicklungsprozess beginnt. Ich möchte jetzt nicht zu sehr in die Unternehmensprozesse eingehen und erspar euch Hinweise in der Form: „Das Projektmanagement muss den Entwurf der Security Patterns berücksichtigen…etc“. Also wir gehen davon aus es wurde bereits alles geplant, entworfen und gemanaged bis auf, genau, die Security Patterns. Schon ergibt sich das erste große Fragezeichen. Wer darf anfangen? Sollte sich erst mal die Security Abteilung über das komplette Konzept hermachen, mögliche sicherheitskritische Faktoren im Vorfeld analysieren und die nötigen Security Patterns entwerfen. Oder sollte erst mal die Entwicklungsabteilung auf Basis des kompletten Konzepts die geplanten Funktionalitäten programmiertechnisch erörtern und die Security Patterns danach entwerfen, da diese ja auch von ihnen umgesetzt werden sollen? Ihr werdet es euch sicher schon denken können, beides ist falsch. Denn bereits hier sorgt die Idee hinter den Security Patterns für den nötigen Konsens. Wie man sich genau abspricht ist egal solange beide Lager es gemeinsam an einem Tisch machen. Wie man sicherlich bemerken konnte habe ich immer von Patterns , also in der Mehrzahl gesprochen. Entscheidet man sich für dessen Einsatz benötigt man natürlich mehr als nur ein Pattern da es logischerweise viele verschiedene Security-Probleme in einem Projekt geben kann. Alle Patterns zusammen bilden das Repository anhand dessen der Entwicklungsverlauf in verschiedene Kontrollabschnitte eingeteilt wird.
Wie entwirft man Security Patterns?
Zu erst sollte man durch das Konzept die verschiedenen Patterns erörtern, mit einem eindeutigen Namen versehen und dazu eine bewusst kurzgehaltene Problembeschreibung verfassen. Die dadurch entstanden Tabelle ist also unser „Index“. Für jeden Eintrag verfassen wir nun das eigentliche Security Pattern das man am besten folgt strukturiert:
- Problemstellung
- Problemlösung
- Realisierung
- Beispiel
- Referenzen
Gehen wir die Struktur mal durch:
Die Problemstellung sollte klar definiert und detailiert sein, sprich alle Eventualitäten und Möglichkeiten des Problems sowie dessen Ursachen berücksichtigen. (Schwerpunkt der Security)
Die Problemlösung sollte keine programmiertechnischem Details enthalten und die Problemstellung theoretisch lösen. Desweitern ist es hilfreich sich an dem Schema der Problemstellung zu orientieren. Dieser Teil ist eigentlich das Herzstück des Security Patterns. Es verbindet die Anliegen beider Lager so dass sie für beide zufriedenstellend sind.
In der Realisierung darf man sich nun mit dem programmiertechnischen austoben und auf die Details eingehen. Wichtig ist hier jedoch auch die Security nicht außen vor zu lassen. Es kann nämlich auch passieren dass durch eine Problemlösung ungewollt neue Sicherheitslücken auftreten. Die Realisierung bildet also ein Design Pattern. (Schwerpunkt der Entwicklung)
Die Beispiele sind wieder ein sehr wichtiger Punkt. Es ist hilfreich aus beiden Lagern ein kleines Beispiel zu gestalten. Ein verständliches Beispiel der Security das zusammen mit der Entwicklung in Code umgesetzt wird, kann später im Entwicklungsprozess sehr nützlich sein und als Denkhilfe herangezogen werden.
Als Referenzen können interne oder externe Quellen wie z.B. Webseiten, Blogs etc. dienen und hilft dabei vieleicht überflüssige Rücksprachen zwischen der Security und Entwicklung zu vermeiden. Was natürlich nicht heißen soll das man Rücksprachen generell vermeiden soll, aber oft kann es auch einfach nur Zeit und Nerven sparen, die Antwort schneller in einer Referenz nach zu schlagen.
Wurden alle Security Patterns entworfen und die Kontrollpunkte im Projektplan eingetragen kann die Entwicklung anfangen in die Tasten zu hauen und die Security kann anfangen die Prüftechniken und Testplanung zu kreieren. Da die Security Abteilung hier wieder mit der QS-Abteilung zusammenarbeiten muss dient der entworfene Security Pattern wieder als Vermittler.
Ein (gekürztes) Security Pattern könnte nun z.B. folgt aussehen:
Eintrag im Index des Repository:
Name: Client-Session-Authentication
Beschreibung: Dieses Pattern behandelt die mit der Authentifizierung verbundene Datenübertragung vom Client zum Server und beschreibt Methoden um mögliche XSS und MITM Angriffe zu unterbinden.
Security Pattern [ Client-Session-Authentication ]
Problemstellung: Bei der Client-Session-Authentication besteht die Gefahr einer Session Fixation. Die zudem unverschlüsselte Datenübertragung ermöglicht MITM Angriffe durch Session Hijacking.
Problemlösung: Der Verbindung sollte verschlüsselt werden. Eine Kontrolle von multiplen bzw. identischen Sessions sollte prozessgebunden stattfinden.
Realisierung: Die Verbindung sollte über SSL verschlüsselt werden. Über einen gesonderten Datenbank Eintrag beinhaltend: Session ID, IP/MAC können durch eine Triggerfunktion mögliche Angriffe und Manipulationen erkannt und unterbunden werden.
Beispiel: // Schema einer super Kontrollfunktion
Referenzen: XSS www.ich –bin-hilfreich.de , MITM www.ich-auch.com
Natürlich wäre das in der Realität wesentlich detailierter und umfangreicher, aber zur Veranschaulichung sollte es reichen. Spätestens hier kann man erkennen dass Security Patterns alle Vorzüge bieten die man von Design Patterns her bereits kennt, nur das sie in einem anderen Kontext stehen. Das ganze klingt nicht nur nach viel Arbeit, dass ist es leider auch erst einmal 
.Wer sich aber einmal die Mühe gemacht hat Security Patterns für ein Projekt zu entwerfen, kann natürlich für spätere Projekte einen immens Profit aus seinem Repository ziehen und erweitert dieses ggf. nur noch um das ein oder andere Security Pattern.
Noch wach ? … Ich hoffe bisher war das alles nicht zu einschläfernd. Da wahrscheinlich die wenigsten in einem Unternehmen tätig sind das eine große Security Abteilung hat wäre es jetzt natürlich ok zu sagen: „Gähn… interessiert mich nicht, brauch ich nicht“ .
Damit mein Beitrag trotzdem seine Daseinsbrechtigung in diesem PHP Blog findet schauen wir uns mal an wie man davon auch im kleinen Team oder als Hobbyentwickler profitieren kann.
Security Patterns für Jederman
Nicht jeder Softwareentwickler ist zudem ein Experte in Punkto IT-Security, wodurch sich das erste Problem ergibt: Wie kann man ohne großartiges Know-How und Erfahrung mögliche Risiken aus einem Konzept ableiten? Am besten man nimmt sich etwas Zeit und zieht ein älteres Projekt zur Hand. Je umfangreicher das ist desto besser, da sich wahrscheinlich mehr Sicherheitslücken finden lassen. Von Cross-Site-Scripting und SQL-Injection hat wahrscheinlich schon jeder einmal gehört, aber Themen wie Cache Poisoning oder ARP-Spoofing sind vielen eher ein Fremdwort. Nun das sollte aber absolut kein Problem geschweige denn ein Hindernis darstellen. Wenn man gar nicht so recht weis wo man mit Suchen anfangen soll der kann sich an folgende kleine „Regel“ halten: Schwachstellen sind meist dort zu finden, wo Daten ausgetauscht werden. Desweiteren sollte man seinen Code auch mal kritisch hinsichtlich möglicher Fehler und Abstürze begutäugeln, oft können diese auch zu Gunsten eines Angriffes ausgenutzt werden. Weiter ist es hilfreich sich parallel ein wenig über Sicherheitslücken und Angriffsszenarien zu informieren. Dazu muss nicht unbedingt Kilo weise Fachliteratur geschmökert werden, es kann schon inspirierend wirken ein wenig bei Wikipedia zu stöbern um seinen Code noch mal kritisch zu hinterfragen. Wendet man das nun auf ein fertiges Projekt an, hat man sicher ein oder zwei Security Patterns die man entwerfen kann. In welcher Form bzw. Art man sein Repository dabei gestaltet sei jedem selbst überlassen. Aber vielleicht würde es sich empfehlen an dieser Stelle ein kleines Entwicklungsprojekt zu konzipieren dass eine eigene Reposiroty-Software zum Ziel hat. Steht das Konzept könnte man gleich mal, die aus dem alten Projekt entwickelten Security Patterns auf das neue Anwenden, sofern die Problemstellung gegeben scheint.
Ihr seht Security Pattern können für jeden hilfreich sein um Sicherheitslücken vor der eigentlichen Entwicklung zu erkennen und während des Entwicklungsprozess zu vermeiden. Eine meiner Meinung nach tolle Sache, mit vor allem langfristigem Nutzen. Zudem hat das ganze für einen Entwickler einen weiteren persönlichen Effekt. Man lernt beim Entwurf einiges über Security und kann das mit ein bisschen Routine später größtenteils auch ohne Repository berücksichtigen, da man die ganzen Security Patterns irgendwann wohl aus dem FF beherrscht.
Ich hoffe mein erster Beitrag hat euch gefallen. Natürlich kann man zu den Security Patterns noch viel mehr ins Detail gehen, aber das würde sicherlich ein ganzes Buch füllen. Daher hoffe ich das es als Einführung ausreichend genug war.
. 
