Sind Ihre Entwickler die erste Linie des Risikos oder der Verteidigung? Bewerten Sie Ihr Unternehmen anhand unserer Checkliste für sichere Kodierung

Wenn wir uns eine beliebige Organisation anschauen, ob öffentlich oder kommerziell, können wir zwei Dinge garantieren. Erstens, ihre Produkte und Dienstleistungen sind zunehmend digital, was bedeutet, dass sie Softwareentwickler einbeziehen, die Zeilen von Code erstellen. Zweitens stehen diese digitalen Unternehmen unter dem Druck traditioneller und nicht-traditioneller Wettbewerber, die in einer dynamischeren und globaleren Welt agieren.

In diesem Umfeld sind CIOs zu den neuen Innovatoren geworden und befinden sich in Positionen mit Macht und Einfluss. Der starke Druck, die Markteinführung zu beschleunigen, die Qualität zu verbessern und die Flexibilität zu erhöhen, hat jedoch zu komplexen, verteilten Entwicklungsteams geführt, die sich auf die schnelle Entwicklung von Merkmalen und Funktionen konzentrieren, ohne sich der Schwachstellen bewusst zu sein, die sie schaffen könnten.

Mehr als je zuvor ist eine neue Arbeitsweise erforderlich. Man muss sich nur den nuklearen Schaden bei Equifax nach deren jüngstem Verstoß ansehen, der das Ergebnis unsicherer Codierung war. CIOs und CISOs sollten sorgfältig darüber nachdenken, ob ihre Entwicklungsteams die erste Linie des Risikos sind, oder ob sie die Sicherheits-Champions des Unternehmens sind, die wahre "erste Verteidigungslinie" ihres Unternehmens.

Ich habe diese Checkliste für sicheres Coding erstellt, um CIOs und CISOs dabei zu helfen, zu prüfen, ob Sie Ihre Entwicklungsteams so aufgestellt haben, dass sie sichere Coding-Champions sind, die Ihnen helfen können, mit schnellerem, besserem und sichererem Code Innovationen zu schaffen.

1. Hat Ihre Führungskraft erkannt, dass herkömmliche Netzwerksicherheit nicht ausreicht?

Die Absicherung der Netzwerkebene mit traditionellen Sicherheitsmaßnahmen reicht nicht mehr aus und war ohnehin selten erfolgreich, selbst gegen semiprofessionelle Hacker. Neben vielen anderen übereinstimmenden Berichten stellt der 2017 Data Breach Investigations Report von Verizon fest, dass 35 Prozent der Datenverletzungen heutzutage durch Schwachstellen in Webanwendungen verursacht werden. Die Sicherheit von Webanwendungen ist genauso wichtig wie die Netzwerksicherheit.

2. Denken Sie von Anfang an an die Sicherheit?

Aktuelle Tools für die Anwendungssicherheit konzentrieren sich darauf, sich im Software Development Life Cycle (SDLC) von rechts nach links zu bewegen. Dieser Ansatz unterstützt Erkennung und Reaktion, d. h. Sicherheitsteams erkennen die Schwachstellen im geschriebenen Code und reagieren, um sie zu beheben. Laut dem National Institute of Standards and Technology (NIST) ist es 30-mal teurer, Schwachstellen in festgeschriebenem Code zu erkennen und zu beheben, als sie beim Schreiben von Code in der IDE zu verhindern. Ganz zu schweigen von den Zeitverzögerungen, die bei der Behebung des Problems entstehen. Secure Code Champions beginnen am äußersten linken Ende des SDLC und konzentrieren sich darauf, ihre Entwickler kontinuierlich in sicherem Coding zu schulen, damit sie die erste Verteidigungslinie in ihrem Unternehmen sind und Schwachstellen von vornherein verhindern.

3. Bauen Sie tatsächlich Sicherheitsfähigkeiten auf, anstatt nur Wissen zu vermitteln?

Die meisten Schulungslösungen (online und im Schulungsraum) konzentrieren sich auf den Aufbau von Wissen und nicht auf den Aufbau von Fähigkeiten. Damit Entwickler sicheren Code schreiben können, brauchen sie regelmäßigen Zugang zu praktischem Lernen, das sie aktiv einbindet, um ihre Fähigkeiten zur sicheren Programmierung zu erlernen und auszubauen. Sie müssen über kürzlich identifizierte Schwachstellen lernen, in echtem Code und in ihren eigenen Sprachen/Frameworks. Diese Lernerfahrung sollte ihnen helfen zu verstehen, wie man bekannte Schwachstellen im Code lokalisiert, identifiziert und behebt.

4. Messen Sie Ihre Fähigkeiten zur sicheren Codierung mit Echtzeitmetriken?

Es ist wichtig, Nachweise zu schaffen, die dem Entwickler und seiner Organisation beweisen, dass sich die Fähigkeiten eines Entwicklers zur sicheren Programmierung verbessern. Man kann nicht verbessern, was man nicht messen kann. Ihre Assessments sollten dabei helfen, den Fortschritt Ihrer Entwicklungsteams in Echtzeit zu identifizieren sowie deren Stärken und Schwächen im Bereich Secure Coding zu benchmarken.

5. Sind Sie sicher, dass Ihre ausgelagerten Zulieferer sichere Codierungstechniken anwenden?

Viele Unternehmen entscheiden sich dafür, Entwicklungsarbeiten an große On- oder Offshore-Entwicklungshäuser zu vergeben. Im besten Fall ist die einzige Form der Zusicherung, die ein Unternehmen in Bezug auf die Sicherheit verlangt, eine Aussage im Vertrag, die verlangt, dass die zu liefernde Software "sicher" sein muss. Nur wenige überprüfen die Fähigkeiten dieser Entwicklungshäuser im Vorfeld und erhalten am Ende Software, die nicht den guten Praktiken der sicheren Kodierung folgt. Das schlimmste Szenario ist, dass sie nichts davon wissen und die Anwendung in Betrieb nehmen. Das häufigste Szenario ist, dass sie von engagierten Spezialisten (für die Sie bezahlen) aufgegriffen werden und Sie entweder mit Verzögerungen beim Go-Live oder mit vertraglichen Diskussionen darüber konfrontiert werden, wer für die Behebung dieser Sicherheitsschwächen zahlen muss. Seien Sie von vornherein klug und bewerten Sie die Fähigkeiten der Entwickler, die Ihre nächste Anwendung erstellen sollen, hinsichtlich der Anwendungssicherheit.

6. Kennen Ihre Entwickler die häufigsten Sicherheitsschwachstellen?

85,5 % der ausgenutzten Schwachstellen in Webanwendungen sind auf nur 10 bekannte Schwachstellen zurückzuführen " die OWASP Top 10. Ihr Anwendungssicherheitstraining muss mindestens diese und viele weitere Schwachstellenarten abdecken. Die Herausforderungen, die Ihre Entwickler absolvieren, müssen kontinuierlich überarbeitet und mit neuen Herausforderungen für entweder neue Codier-Frameworks oder neue Schwachstellen-Typen aktualisiert werden.

7. Haben Sie interne Sicherheits-Champions?

Jede entwicklungslastige Organisation sollte in jemanden investieren, der sich für die Sicherheit innerhalb Ihrer Entwicklungsteams einsetzt. Ihr Zweck ist es, eine Anlaufstelle für alle zu sein, die Fragen zur Sicherheit haben, aber auch für sichere Codierung und sichere Architekturpraktiken innerhalb eines Teams einzutreten

8. Haben Sie in Tools für Ihre Entwickler investiert, um die sichere Kodierung zu erleichtern?

In einer Umgebung mit vielen Änderungen an Anwendungen oder in der agilen Entwicklung ist die Automatisierung von Teilen der Sicherheit unerlässlich, um mit dem Tempo und Volumen Schritt zu halten. Für jede Phase des Entwicklungslebenszyklus gibt es Tools, die als Ratgeber, Quality Gates oder Erkennungstools dienen. Sie sollten IDE-PlugIns haben, die sich auf bestimmte Arten von Sicherheitsfehlern konzentrieren und wie eine Rechtschreibprüfung fungieren, während der Entwickler seinen Code schreibt. Es gibt auch Tools, die sich in den Build-Prozess integrieren und bestimmte Arten von Schwachstellen erkennen, wenn der Code an ein Code-Repository übermittelt wird. Es gibt auch Tools, die automatisierte Tests über den Code laufen lassen und so Hacking-Techniken simulieren, sobald die Software in Produktion ist. Alle haben ihre eigenen Vorteile und Herausforderungen, und keines kann eine 100-prozentige Garantie bieten, dass es keine Sicherheitsprobleme gibt. Die goldene Regel lautet: Je früher Sie die Schwachstelle erkennen können, desto schneller und kostengünstiger können Sie die Schwachstelle mit den geringsten Auswirkungen auf Ihr Unternehmen beheben.

Da CIOs aggressiv ihre agilen Unternehmensfähigkeiten aufbauen, werden sichere Programmierfähigkeiten eine Waffe der Innovation sein und sie nicht zu haben, wird ein Instrument der Zerstörung sein. Denken Sie zweimal nach, bevor Sie diese kritische Fähigkeit auslassen.

Wie ist Ihre Organisation mit dieser Checkliste umgegangen?

Da CIOs aggressiv ihre agilen Unternehmensfähigkeiten aufbauen, werden sichere Programmierfähigkeiten eine Waffe der Innovation sein und sie nicht zu haben, wird ein Instrument der Zerstörung sein. Denken Sie zweimal nach, bevor Sie diese kritische Fähigkeit auslassen.