3 Tipps für ein effektives Security-Training für Entwickler

„Wir leben im goldenen Zeitalter der Anwendungssicherheit“, sagt Jim Manico, Gründer von Manicode Security und Trainer für sicheres Programmieren, in Folge 26 von The Secure Developer podcast.

Vor zehn Jahren sei Sicherheitstraining, so Manico, „eine ungewöhnliche Sache gewesen – etwas, das man nebenbei machte“. Heute seien Assessment-Tools ausgereift, gute Fachliteratur zu Assessments mache Wissen leichter zugänglich, und viele kluge Menschen entwickelten sichere Anwendungen.

Das goldene Zeitalter bedeutet nicht, dass das Problem Sicherheit gelöst ist. Es bedeutet vielmehr, dass wir wissen, was gelernt werden muss, und über die Ressourcen und die Entschlossenheit verfügen, diese Schulung anzubieten.

In diesem Artikel stellen wir drei Tipps vor, mit denen Sie Ihr Schulungsprogramm zu Anwendungssicherheit für Entwickler verbessern und alle Vorteile des goldenen Zeitalters der Anwendungssicherheit nutzen können.

1. Schaffen Sie mit klaren Sicherheitsanforderungen die Grundlage fürs Lernen

Schulungen zur Anwendungssicherheit für Entwickler sind ohne ein klares, gemeinsames Verständnis davon, was Anwendungssicherheit bedeutet, nicht möglich.

Deshalb zählt es laut Manico zu den wichtigsten Maßnahmen, mit denen Unternehmen ihre Entwickler schulen können, klare Sicherheitsanforderungen festzulegen. „Ich möchte eine klare Definition der Sicherheitsanforderungen“, sagt Manico, „damit wir alle dasselbe Verständnis davon haben, was Anwendungssicherheit eigentlich bedeutet.“

Viele würden instinktiv zu den OWASP Top 10 greifen. Manico rät jedoch davon ab. Stattdessen empfiehlt er den OWASP Application Security Verification Standard, der mehr als 200 Anforderungen umfasst. Der größte Vorteil dieses Standards ist laut Manico, dass seine Anwendung sich auszahlt – ganz gleich, wie konsequent das Team ihn letztlich umsetzt.

„Auf hoher Ebene“, sagt Manico, „haben wir die Anforderungen eingeführt und sie den jeweiligen Stellen im Framework zugeordnet. Außerdem haben wir festgelegt, was wir manuell selbst erledigen müssen und wobei uns Tools von Drittanbietern helfen können.“

Doch auch wenn Teams nicht so weit ins Detail gehen, gibt es noch immer einen Nutzen. „Ich habe erlebt, wie Anforderungen eingeführt und nie gelesen wurden – und der Prozess trotzdem hilfreich war, weil die technischen Leiter vier oder fünf Stunden lang mit den leitenden Entwicklern darüber sprechen konnten, was für die Sicherheit wichtig ist“, sagt Manico.

Die gemeinsame Erarbeitung von Sicherheitsanforderungen schafft also einen nützlichen Konsens darüber, was Entwickler und Sicherheitsteams tun müssen, um ein gewisses Maß an Anwendungssicherheit zu erreichen. Selbst wenn Teams nicht alle Möglichkeiten ausschöpfen, kann ein Konsens viel bewirken.

„Ganz gleich, wie Sie die Anforderungen einführen: Irgendeinen Nutzen wird es haben“, sagt Manico.

2. Machen Sie Entwicklungsteams mit Security Champions unabhängig

Bei jedem Schul- und Hochschulabschluss fließen Tränen, obwohl der Abschluss das Ziel ist. Letztlich möchte jede Lehrkraft sehen, wie ihre Schülerinnen und Schüler selbstständig, unabhängig und erfolgreich werden – auch wenn der Abschied emotional ist.

Dasselbe gilt für Schulungen zur Anwendungssicherheit für Entwickler. Unternehmen sollten externe Sicherheitsberater und Trainer hinzuziehen, aber darauf achten, dass diese vorausschauend planen, wie die Teams nach ihrem Weggang weiterarbeiten.

Nick Vinson, DevSecOps Lead bei Pearson, geht genau so vor. In Folge 84 des Podcasts The Secure Developer erklärt Vinson, sein Hauptziel sei es, „dem Team die Tools und das Wissen an die Hand zu geben, die es braucht, um selbstständig zu arbeiten“.

Dafür integriert Vinsons Team erfahrene Security Engineers in die Teams, mit denen es zusammenarbeitet. Diese eingebetteten Fachkräfte leisten einen vollwertigen Beitrag zum Team und können Änderungen vornehmen, testen und in der Produktionsumgebung bereitstellen.

Während ihrer Mitarbeit im Team führen diese Fachkräfte Threat Modeling durch, um Sicherheitsrisiken und Schwachstellen zu identifizieren. Außerdem integrieren sie automatisierte Sicherheitstests in den SDLC und sorgen gleichzeitig dafür, dass, wie Vinson sagt, „die Teams wissen, was zu tun ist, statt nur Kästchen abzuhaken“.

Damit das neue Wissen wirklich haften bleibt, bildet die eingebettete Fachkraft parallel zur praktischen Arbeit und Beratung einen internen Security Champion aus. „Das ist unsere wichtigste Aufgabe“, sagt Vinson.

Durch die Integration eines Security Engineers kann Vinson zwei Ziele gleichzeitig erreichen: die Anwendungssicherheit schneller auszubauen und einen Security Champion auszubilden, der dafür sorgt, dass die Praktiken für sicheres Programmieren nachhaltig verankert werden.

3. Gewinnen Sie das Vertrauen der Entwickler, indem Sie Glaubwürdigkeit aufbauen

Oft begegnen Menschen der Idee, Entwickler in Sicherheit zu schulen, mit Skepsis. Werden Entwickler Sicherheit nicht einfach als Pflichtübung und Ablenkung von ihrer eigentlichen Arbeit betrachten?

Jet Anderson, Security Engineer bei Amazon, reagiert in Folge 98 des Podcasts The Secure Developer deutlich: „Das ist völliger Blödsinn – ich glaube überhaupt nicht, dass das stimmt.“

Entgegen diesen Annahmen erlebt Anderson bei Entwicklern eine große Begeisterung für Sicherheit. „Ich stelle fest, dass Entwickler sehr auf Qualität bedacht sind und gute Qualität wollen. Sie möchten das Richtige tun“, sagt Anderson. Und Sicherheit ist ein wichtiger Teil davon.

Laut Anderson liegt die Kluft zwischen Entwicklern und Security Engineers nicht an der Gleichgültigkeit der Entwickler, sondern an mangelndem gegenseitigem Verständnis.

„Es ist nicht so, dass Entwickler sich nicht dafür interessieren“, sagt Anderson. „Vielmehr verfügen Beschäftigte in der Informationssicherheit nicht unbedingt über umfassende Kenntnisse in der Softwareentwicklung. Deshalb fehlt ihnen möglicherweise die Glaubwürdigkeit oder sogar die Sprache, um Risiken oder Fehler präzise zu erklären.“

Als Beispiel nennt Anderson den Begriff „Schwachstelle“. In der Informationssicherheit ist er geläufig und wird in verschiedenen Zusammenhängen verwendet. Entwickler verstehen möglicherweise andere Begriffe besser. Anderson sagt, dass sich viele der von Sicherheitsteams gefundenen Probleme treffender als Fehler beschreiben lassen. Als Schwachstelle sollte ein Fehler erst bezeichnet werden, wenn dafür ein Exploit gefunden wurde.

„Solche kleinen Feinheiten tragen zum kulturellen Wandel bei“, sagt Anderson. Auch wenn es unbedeutend erscheinen mag: Wiederholte Änderungen der Sprache in verschiedenen Zusammenhängen können viele weitere Gelegenheiten schaffen, ein gemeinsames Verständnis zwischen Security Engineers und Entwicklern aufzubauen. Ist dieses gemeinsame Verständnis erst einmal geschaffen, können Schulungen für Entwickler deutlich erfolgreicher sein.

Shift Left – bis in die Köpfe der Entwickler

Shift Left bezeichnet den Ansatz, Sicherheitsmaßnahmen, die traditionell am Ende des SDLC stattfinden, nach links – also an den Anfang des SDLC – zu verlagern. Laut Anderson können Sie jedoch noch weiter nach links gehen und über die erste Phase des SDLC hinausdenken. „Einen früheren Ort als das Gehirn eines Entwicklers kann ich mir im SDLC nicht vorstellen“, sagt Anderson.

Unternehmen, die Shift Left umsetzen und Sicherheit zum festen Bestandteil des Anwendungsdesigns machen möchten, müssen sowohl wissen, worauf sie sich einlassen, als auch ihre Ausgangslage kennen. Viele Entwickler können ihr Studium abschließen oder eine Zertifizierung erwerben, ohne etwas über Sicherheit zu lernen. Wenn Sie Shift Left umsetzen möchten, sind Schulungen zur Sicherheit für Entwickler unverzichtbar.

Abonnieren Sie noch heute den Podcast The Secure Developer, um weitere Sicherheitstipps von Experten zu erhalten.