Dieser Guide richtet sich speziell an Software Entwickler wobei der Fokus hier mehr auf der Software Entwicklung bzw. dem Software Produkt liegt als am Unternehmen selbst. Für diesen Fall haben wir ein den Business Guide entwickelt.
Verwenden von statischen Code Analyse Tools
Statische Code Analysen zeigen dem Entwicklern beim schreiben des Codes innerhalb der IDE mögliche Sicherheitsprobleme an. Dies kann die Verwendung von unsicheren Cipher Modes oder auch Code Injection Anfälligkeiten sein. Entsprechende Tools gibt es für alle gängigen Sprachen und IDEs. Wir empfehlen z.B. für .net das kostenlose Open Source Tool Security Code Scan - static code analyzer for .NET. Dieses deckt u.A. die OWASP TOP 10 ab und bietet soliden Grundschutz.
Interne Code Reviews
Entwickler sollten sich untereinander ergänzen. Als Entwickler ist man gegenüber eigenem Code nicht immer ganz unbefangen, da hilft ein neutraler Blick eines Kollegen schon aus um mögliche Sicherheitsprobleme auszuschließen.
Regelmäßige White Box Penetration Tests
Ein erfahrener Penetration Tester kann Sicherheitsprobleme im Source Code nicht nur durch Erweiterte Kenntnisse z.B. in der Kryptographie erkennen, sondern hat meist durch ein neutralen Blick auf den Code die gleiche Ausgangslage wie ein Angreifer, welcher entweder durch ein Leak des Source Codes an diesen gekommen ist oder aber durch Reverse Engineering. Zudem werden professionelle Penetration Tests bei Regulatorischen Institutionen als Validierung Ihrer Sicherheitsmaßnehmen eher akzeptiert, als intern durchgeführte Penetration Tests.
Sorgfältige Auswahl von Komponenten
Es ist üblich und auch total legitim Funktionalität durch Fremdkomponenten im eigenen Produkt zu integrieren. Aber wie auch Ihr eigenen Produkt sind auch diese Komponenten nicht vor Sicherheitslücken gefeit. Sie müssen diese Komponenten also stehts im Auge behalten und am besten sehr sorgfältig auswählen. Vermeiden Sie nicht mehr aktiv entwickelte Komponenten oder Komponenten mit vielen weiteren Abhängigkeiten. Führen Sie vor Ihrer Wahl eine Recherche z.B. in den gängigen Vulnerability Datenbanken durch. Mehr zu diesem Thema erfahren Sie im Kapitel "Market Surveilance" und Dependency Check.
Dependency Checks
Analyse von gängigen Schwachstellen Datenbanken nach bekannten Schwachstellen in von Ihnen verwendeten Software Komponenten. Hierfür bietet das OWASP entsprechende Tools an: OWASP Dependency Check
Regelmäßige News Recherche gängige Security News Portale
Zusätzlich zum Dependency Check können durch regelmäßige News Recherchen Sicherheitsprobleme schneller und auch akkurater erkannt werden. Dies ist vor allem Hilfreich und Sinnvoll wenn es Schwächen in Kryptographischen Verfahren, Kommunikationsprotokollen oder Technologien allgemein gibt. In einem solchen Fall sind mehrere Dependencies betroffen und werden u.U. nicht in Vulnerability Datenbanken gelistet. Zusätzlich kann die Entwicklung einer Abhängigkeit / Komponente auch jederzeit eingestellt werden oder aber die Komponente hat selbst Abhängigkeiten welche wiederum selbst Schwachstellen haben kann.
Automatisiertes Vulnerability Scanning
Ist Ihr Produkt Bestandteil eines größeren Deploments z.B. mit speziellen konfiguriertem Betriebssystem, so bietet sich die Verwendung eines automatisierten Vulnerability Scannings an. Dies ersetzt kein Penetration Test, aber kann typische Sicherheitsprobleme, z.B. verursacht durch fehlerhafte Konfiguration, minimieren. Wir empfehlen hierfür OpenVAS oder die etwas Benutzerfreundliche, aber kommerzielle Variante Nessus. Nessus ist bis zu einer gewissen Anzahl an zu Scannenden Hosts sogar kostenlos.
Wir empfehlen, ein solches Scanning z.B. regelmäßig und automatisiert an einem Nightly Build durchzuführen.
Black Box Penetration Tests
Wollen Sie möglichst realitätsnahe Angriffsversuche durchführen wobei der Angreifer über keine internen Kenntnisse des Systems verfügt - dann sind Black Box Penetration Tests die Wahl. Hierbei sollten Sie dem Auftragnehmer aber unter Auflagen testen lassen wenn dieser Test in einer Produktiven Umgebung stattfindet. Wenn durch ein im Rahmen des Penetration Test durchgeführter Angriff Ihr Tagesgeschäft gestört wird, ist niemanden geholfen. Klare Rahmenbedingungen sind sehr wichtig, nicht nur für Sie als Auftraggeber, sondern auch für den Auftragnehmer.
White Box Penetration Tests
Hat der Auftragnehmer detaillierte Kenntnissen des zu testenden Systems, so nennt man dies ein White Box Penetration Test. Dieser Test und dessen Resultate werden naturgemäß detaillierter ausfallen. Achten Sie hierbei vor allem auf entsprechende Verschwiegenheitsvereinbarungen mit dem Auftragnehmer bzw. suchen Sie sich ein möglichst renommierten Anbieter aus welcher möglichst juristisch dem europäischen Recht unterliegt.
Code Injection Schulungen
Entwickler sollten ein solides Verständnis davon habe, wie Code Injection möglich ist, was es anrichten kann und wie man es verhindern kann. Am Besten anschaulich unterstützt durch Live Hacks.
Cryptographic Basic Schulung
Nur mit dem Wissen der Existenz von verschiedenen Kryptographischen Verfahren und dessen Vorteile und Einsatzzwecke setzen Entwickler diese bevorzugt ein und erfinden das Rad nicht neu - was in der Kryptographie ein sehr gefährlicher Ansatz wäre denn nur Algorithm, die von einer Breiten Masse eingesetzt und geprüft wurde, kann professionellen Angriffen wieder stehen.
Security Awareness Schulungen
Auch Entwickler sollten regelmäßig die Grundlagen aktueller Gefahren kennen, die Angreifer einsetzen um Unternehmen zu kompromittieren. Mit diesem Wissen im Hinterkopf wird über den Tellerrand hinaus entwickelt und das gesamte Security Konzept des Unternehmens unterstützt durch eine sicherere Unternehmenssoftware Infrastruktur.
Einsatz von spezialisierter Sicherheit Software
Dieser Punkt erfordert dem Nutzer einiges an Vorkenntnissen ab und sollte nach Möglichkeit nur von versierten Security Anwendern.