In der Praxis ist es für Hersteller keine leichte Aufgabe, einen ausgeprägten Sicherheitsgedanken kontinuierlich in komplexe Softwareprojekte zu integrieren. Stephan Neumann, Head of usd HeroLab, und Torsten Schlotmann, Head of PCI Security Services, sprechen in unserer Blogserie über praktikable Ansatzpunkte und Möglichkeiten, die Sicherheit von Software dennoch wirksam zu verbessern.
- Teil 1: Gründe für mehr Sicherheit
- Teil 2: Sicherheit in die Unternehmenskultur verankern
- Teil 3: Anforderungs- und Bedrohungsanalyse
- Teil 4: Statische Codeanalyse
- Teil 5: Dynamische Codeanalyse und Vulnerability Management
Nachdem wir uns in Teil 3 mit der Anforderungs- und Bedrohungsanalyse beschäftigt haben, gehen wir einen Schritt weiter: Ansätze für mehr Sicherheit im Code.
Stephan Neumann: „Bisher sprachen wir über vorbereitende Maßnahmen für mehr Sicherheit. Nun sollten wir uns anschauen, wie es während und nach der Implementierung weiter geht. Wir werden oft gefragt, welche Programmiersprache man für die größtmögliche Sicherheit nutzen sollte. Meine Antwort ist zusammenfassend immer die gleiche: Die Programmiersprache, die man gut kennt und mit der man am meisten Erfahrung hat. Auch wenn zu einem bestimmten Zeitpunkt mehr Schwachstellen in Java bekannt sind als in PHP, oder ein Framework besser bewertet ist als ein anderes, so kann sich das bereits wenige Tage später wieder ändern. Daher ein Tipp von uns: OWASP Web Applications bieten zahlreiche Cheat Sheets zu unterschiedlichen Programmiersprachen an, in denen man Hinweise zu Schwachstellen in diversen Themengebieten wie beispielsweise Authentifizierung, Verschlüsselung oder Passwortmanagement finden kann. Darüber hinaus kann ich allen Unternehmen ans Herz legen Mitarbeiter*innen rund um Secure Coding zu schulen. Es ist essenziell die Vorgehensweise eines Angreifers und die wichtigsten Schwachstellen sowie geeignete Gegenmaßnahmen zu verstehen – noch bevor diese ausgenutzt werden können.
Denken wir nun einige Wochen oder Monate später: Vor der Ausführung der Software hat man tausende Zeilen geschriebenen Code vor sich. Was kann man an dieser Stelle tun, um Fehler im Code zu identifizieren, die von Angreifern ausgenutzt werden können? Hier haben sich verschiedene Tools etabliert, ich möchte aber mit der statischen Codeanalyse beginnen. Dabei wird der Quellcode mehreren Tests unterzogen, die nicht nur Codestyle und Kommentare prüfen, sondern auch nach potenziellen Schwachstellen suchen. Nach der vollständigen Prüfung des Codes erhält der Entwickler oder die Entwicklerin einen zusammenfassenden Bericht mit Hinweisen und potenziellen Schwachstellen. Natürlich muss man erwähnen, dass es anfangs häufig zu False Positives kommen kann. Das Tool schlägt zunächst überall an und findet somit auch potenzielle Fehler, die vielleicht letztendlich nicht relevant oder gar keine Fehler sind. Hier ist es wichtig, trotzdem auch diese Meldungen zu kontrollieren und sie gegebenenfalls mit entsprechenden Regeln aufzunehmen. Da ein statisches Code Analyse Tool jedes Mal wieder automatisiert den gesamten Quellcode prüft, können diese Findings aufgrund niedriger Relevanz durch geeignete Einstellung entweder nie wieder oder beim nächsten Mal mit einer Meldung sichtbar gemacht werden. Deswegen ist es unter anderem so wichtig, dass Tool nicht nur einmalig einzusetzen, sondern es kontinuierlich anzupassen, damit es weder zu fein anschlägt noch wichtige Dinge übersieht.“
Torsten Schlotmann: „Bei einer solchen Analyse ist es wichtig, sich nicht von den Ergebnissen überwältigen zu lassen. Gerade wenn man das Code Analyse Tool zum ersten Mal nutzt, führt dies zu einer Vielzahl an Meldungen - auch viele False Positives, wie Stephan eben beschrieben hat. Daher sollte man sich schon im Vorfeld über den Aufwand bewusst sein, um nicht den Ergebnisbericht nach dem ersten Öffnen direkt wieder zu schließen, weil die hohe Anzahl an Funden zunächst überfordernd wirkt. Ich kann auch hier nur wieder empfehlen: Einfach anfangen. Starten Sie mit den kritischsten Punkten und machen Sie sich bewusst, dass jeder Schritt hilft. Legen Sie den Anspruch ab, alle gemeldeten Ergebnisse innerhalb einer Woche zu prüfen und noch beheben zu können. Das ist schlichtweg nicht realistisch.
Bei den Ergebnissen der statischen Codeanalyse ist es auch wichtig, dass jemand mit entsprechendem Knowhow draufschaut. Für die Ausführung des Tools sind zunächst zwar keine tiefgreifenden Sicherheitskenntnisse erforderlich, aber wenn es darum geht die Ergebnisse in den richtigen Kontext einzuordnen und bewerten zu können, greifen Sie am besten wieder auf Ihre Security Champions zurück. Nur ein entsprechend ausgebildeter Kollege oder Kollegin kann die Ergebnisse fachmännisch prüfen, auswerten, gegebenenfalls mit weiteren Kolleginnen und Kollegen besprechen und im besten Fall sogar auch beheben.“
Stephan Neumann: „Abschließend möchte ich noch ergänzen, dass es neben den erwähnten Tools auch möglich ist, ein manuelles Verfahren zu wählen. Auch dieses hat Vor- und Nachteile: Während ein automatisiertes Tool eine große Masse an Quellcode durchsuchen kann, sind einzelne, manuelle Prüfungen natürlich von Vorteil, um besonders kritische Codeteile zu prüfen. Das ist selbstverständlich wesentlich zeitintensiver. Meiner Meinung nach schließt sich aber beispielsweise nicht aus, beides zu integrieren - zunächst komplett automatisiert zu arbeiten und dann einzelne Stellen nochmals manuell zu prüfen.“
In der CST Academy bieten wir für Ihre Mitarbeiter*innen passende Schulungen an: usd Basic Seminar: Sichere Entwicklung von Webanwendungen, usd Advanced Seminar: Sichere Entwicklung von Webanwendungen oder Understanding A Hacker’s Mind.
Sie benötigen Unterstützung bei der manuellen Prüfung von kritischen Codeteilen? Sprechen Sie uns an, wir unterstützen Sie gerne mit einem Code Review.
