Die Microsoft-Richtlinien für den SDL (Security Development Life-Cycle) für Agile empfehlen Sicherheitspraktiken während des Entwurfs, der Implementierung und der Freigabe des Projekts. Unabhängig von der verwendeten Entwicklungsmethode sollte keine Codezeile in die Produktion gelangen, bis eine Sicherheitsüberprüfung durchgeführt wurde. Wenn finanzielle Einschränkungen verhindern, dass ein Fachmann diese Sicherheitsüberprüfung durchführt, muss eine Sicherheitsüberprüfung von Kollegen durchgeführt werden, bevor eine Veröffentlichung abgeschlossen werden kann. Das Finalisieren einer Veröffentlichung kann zu einem unterhaltsamen Prozess werden. Ich habe Unternehmen gesehen, die unternehmensweite Hack-a-Thons veranstalten und Preise für interessante Fehler verteilen.

Microsoft hat viel Arbeit in SDL geleistet und die Sicherheit von Microsoft hat sich verbessert.

Die kurze Antwort lautet: Integrieren Sie Sicherheit in Ihren Softwareentwicklungszyklus. Es sollte in jede Phase integriert werden: Design, Implementierung und Test.

Es gibt viele Ressourcen, wie Sie Sicherheit in Ihren Softwareentwicklungslebenszyklus integrieren können. Siehe z. B. Cigitals SDLC (die 7 Berührungspunkte)], Microsoft SDLC, OpenSAMMs SDLC, BSIMM, CERT's Build Security In oder Fragen hier wie Sichere Softwareentwicklung, Die Erstellung sicherer Softwareentwicklungsumgebungen, Was wird als? einfachster (oder leichtester) sicherer Entwicklungslebenszyklus?, Welches Modell für den sicheren Entwicklungslebenszyklus soll ausgewählt werden?.

Eine "Sicherheitsüberprüfung" ist keine einzige Sache. Es gibt verschiedene Formen der Sicherheitsüberprüfung. Um die Sicherheit in Ihren Softwareentwicklungszyklus zu integrieren, muss die Sicherheit in jeder Phase des Weges berücksichtigt werden. Diese verschiedenen Arten der Sicherheitsüberprüfung haben unterschiedliche Auswirkungen. Diese Elemente können Folgendes umfassen:

• Sie sollten eine Überprüfung des Sicherheitsdesigns durchführen lassen, um Ihr Design zu überprüfen, um die mit dem Design verbundenen Sicherheitsrisiken auf Architekturebene und das Potenzial für Fehler auf Designebene zu verstehen ( Dies nennt Microsoft "Bedrohungsmodellierung". Sie müssen dies nicht jedes Mal überprüfen, wenn Sie die Implementierung ändern, sondern nur, wenn Sie das Design ändern.

• Sie sollten auch eine Überprüfung des Sicherheitscodes durchführen lassen, um Ihren Code zu überprüfen um potenzielle Codefehler auf Implementierungsebene zu identifizieren, die die Sicherheit gefährden könnten. Jedes Mal, wenn Sie neuen Code schreiben oder vorhandenen Code ändern, müssen Sie diesen Code auf Implementierungsfehler überprüfen.

• Sie sollten auch die Sicherheit in Ihre Testbemühungen integrieren. Bevor Sie eine neue Version veröffentlichen, können Sie deren Sicherheit testen, insbesondere wenn Sie sich auf die geänderten Funktionen konzentrieren.

Wenn Ihr Sicherheitsmodell auf dem Konzept einer externen Prüfung Ihrer gesamten Codebasis zu einem bestimmten Zeitpunkt basiert, machen Sie die Sicherheit falsch.

... und Sie verwenden sie wahrscheinlich das Audit auch falsch. Aber wir werden dazu kommen.

Ohne Frage muss der gesamte Code auf Sicherheit geprüft werden. In vielen Fällen ist dies tatsächlich eine gesetzliche Anforderung: Kein Code wird ohne Audit geliefert. Die traditionelle Weisheit legt nahe, dass eine solche Prüfung zu einem bestimmten Zeitpunkt im Lebenszyklus ein Ereignis ist. Eine sinnvollere Methode besteht jedoch darin, den Code während der Prüfung zu prüfen. Das heißt, jeder Code erhält eine Sicherheitsüberprüfung bevor er in Ihre Codebasis eingecheckt werden kann.

Die Theorie ist einfach; Das Repository ist bereits geprüft, sodass wir seine Komponenten nicht als Standardverfahren erneut prüfen müssen. Wenn jedoch eine neue Funktion, ein neuer Patch oder ein neuer Bugfix vorgeschlagen wird, muss der Diff von den entsprechenden Betreuern abgemeldet werden. Sie können sich für alles abmelden, was Ihnen wichtig ist. Zum Beispiel hat der Linux-Kernel einen ziemlich komplizierten Genehmigungsprozess, der mehrere Vermerke auf dem Weg zu Qualität, Einfachheit, Konsistenz, Leistung usw. erfordert. Ihre Anforderungen können variieren, aber ein Sicherheitsaudit sollte Teil dieses Genehmigungsprozesses sein.

In diesem Fall prüfen Sie das Produkt nicht durchgehend, sondern nur den Unterschied. Aber Tausende winziger Audits im Verlauf des Produktentwicklungszyklus werden weitaus gründlicher und umfassender sein, als es sich ein End-to-End-Audit erhoffen könnte.

Ein End-to-End für das gesamte Produkt -end Audit ist sicherlich hilfreich und sollte nicht vermieden werden. Diese Prüfung sollte sich auf das Produkt als Ganzes konzentrieren, und zwar auf eine Weise, die während der von Ihnen durchgeführten Prüfungen auf Patch-Ebene nicht so einfach durchzuführen ist. Sie möchten von Zeit zu Zeit den gesamten Wald betrachten, nicht nur die einzelnen Bäume. Der Zeitpunkt dieser umfangreichen Audits sollte wahrscheinlich größeren Releases, größeren Änderungen oder Audits zur Konformitätszertifizierung entsprechen.

Indem Sie jedoch die Überwachung auf Patch-Ebene auf dem neuesten Stand halten, können Sie sicherstellen, dass der Code immer in einem überprüfbaren Zustand gehalten wird, sodass Sie weiterhin regelmäßig und sicher versenden können.

Informationen zu Genehmigungen zur Festschreibungszeit
Wenn Ihr Unternehmen dies nicht tut, machen Sie alles falsch. Es gibt Dutzende, vielleicht Hunderte von Problemen, die gelöst werden, indem jede Codeänderung von mindestens einer anderen Person genehmigt werden muss, einschließlich (und insbesondere) während der anfänglichen Entwicklung. Sie sollten immer mindestens zwei Personen haben, die verstehen, wie jede Codezeile funktioniert, und die zustimmen, dass der Code korrekt ist.

Dies ist mindestens so wichtig wie Unit-Tests. Wenn Sie dies nicht tun, stoppen Sie alles und besuchen Sie Ihre Richtlinien zu Qualität und Sicherheit erneut.

Ja, dieser Prozess wird skaliert. Wie oben erwähnt, wird es vom größten Softwareprojekt der Welt verwendet, ebenso wie von einigen der agilsten und erfolgreichsten Softwareunternehmen der Welt.

Missbrauchsfälle hinzufügen.

Wenn das System eine Funktion aufweisen muss, verwenden Sie einen Anwendungsfall. Wenn das System eine Funktion nicht aufweisen darf, verwenden Sie einen Missbrauchsfall.

"Als Konkurrent möchte ich das Datenbank-Backend nach unternehmenssensiblen Daten abfragen. Dies darf nicht passieren."

"Als Hacktivist möchte ich die DMZ verwenden, um Angriffe zu reflektieren bei der Regierung; das darf nicht passieren ".

Der Product Owner kann diese Storys zusammen mit den anderen priorisieren, aber sie sind wie jede andere User Story testbar.

(ich frei Ich gebe zu, dass ich kein Eingeweihter der geheimen Geheimnisse von Agile bin. Agile ist so etwas wie der 77. Orden der Freimaurer geworden, voller Geheimnisse und Gebote, die aus Angst vor unbeschreiblichen Schrecken nicht gebrochen werden dürfen.

Wie andere vorgeschlagen haben, können Sie Geschichten über Sicherheit einbauen. Und ich würde Sie auf jeden Fall dazu ermutigen.

Aber wenn Sie über ein externes Team sprechen, das mehrere Wochen lang ein Audit durchführt ... dann scheint es mir eher agil zu sein als Sicherheit.

Ich weiß, dass Agile häufig großen Wert auf den Versand legt. Wie können Sie den Feedback-Zyklus verkürzen, wenn Ihre Software nicht in den Händen der Kunden liegt? Für viele Unternehmen ist die Veröffentlichung alle 2/3/4 Wochen jedoch keine Option. Oder sie haben einen langwierigen QA / QC-Überprüfungsprozess und die QA-Organisation ist nicht bereit, agil zu werden. Oder sie haben andere Zertifizierungsanforderungen (z. B. ISO), die nicht in den agilen Lebenszyklus passen.

Folglich haben viele agile Teams früh erkannt, dass sie ihre Releases von ihren Iterationen oder Sprints entkoppeln müssen.
Das heißt, anstatt die Produktion zu fördern, fördern Sie Änderungen an einer Umgebung, die der Sicherheit / Qualitätssicherung / was auch immer gewidmet ist. Wenn der Code dort zertifiziert wurde, fördern Sie ihn zur Produktion (oder zum nächsten Tor).

Wenn Sie "Missbrauchs" -Geschichten eingebaut haben, sollte Ihre Fehler- / Problemliste vermutlich kurz sein.

Wenn ein Fehler gefunden wird, kann er in den Rückstand aufgenommen werden oder Je nach Schweregrad wird eine sofortige Lösung priorisiert.

Natürlich ist die zusätzliche Umgebung nicht kostenlos ... aber meiner Erfahrung nach ist sie billiger als die Alternativen (was normalerweise dazu führt, dass Teams sich gegenseitig auf die Zehen treten ).

Sie können Audits für jede Version wie bei einem Wasserfallprojekt durchführen. Obwohl Sie dabei einige Probleme festgestellt haben, können viele Sicherheitsunternehmen sehr effektiv mit agilen Projekten arbeiten. Wenn Sie jedoch häufig veröffentlichen, sind die Kosten hierfür möglicherweise unerschwinglich.

Ein anderer Ansatz besteht darin, die Tests intern zu verschieben. Wenn Sie ein Scan-Tool kaufen, können Sie Ihre eigenen Audits durchführen. Sie sind möglicherweise nicht so gründlich wie eine spezialisierte Sicherheitsfirma, aber Sie können sie so oft ausführen, wie Sie möchten. Vielleicht integrieren Sie sie in ein nächtliches Build-System oder führen sie mithilfe der kontinuierlichen Integration sogar in einem Pre-Commit-Hook aus. Es gibt zwei Haupttypen dieser Tools: Dynamic Application Security Testing (DAST), ein automatisierter Penetrationstest, und Static Application Security Testing (SAST), ein automatisierter Quellcode-Review. Ein Vorteil von SAST ist, dass die Ergebnisse in den Bedingungen des Entwicklers angegeben werden: Quellcodedatei und Zeilennummer. Ich denke, dass DAST / SAST-Testwerkzeuge sehr gut zum agilen Modell passen. In gewisser Weise handelt es sich um Komponententests für die Sicherheit.

Ein Entwicklungsteam mit ausgereiften Sicherheitsprozessen verwendet sowohl interne Tests als auch Tests von Drittanbietern. SAST / DAST wird verwendet, um sicherzustellen, dass der gesamte Code mindestens eine grundlegende Sicherheitsüberprüfung erhält, und um Probleme frühzeitig zu erkennen. Penetrationstests werden regelmäßig durchgeführt, um komplexe Probleme zu erkennen, die durch automatisierte Tests nicht identifiziert werden können. Dies kann nach einem festen Zeitplan erfolgen oder risikobasiert sein, wenn man sich die Änderungen in jeder Version ansieht.

Ihre Frage betraf Sicherheitsüberprüfungen. Natürlich gibt es andere Aspekte für die Sicherheit einer Anwendung. Die Bedrohungsmodellierung zur Gewährleistung der Sicherheit spiegelt sich im Design wider. Wählen Sie Entwicklungstools und Frameworks aus, die die Sicherheit fördern, und schulen Sie Entwickler in der sicheren Verwendung dieser Tools. Dies ist dasselbe wie bei der Entwicklung von Wasserfällen, aber bei Agilität ist es wichtiger, diese Fähigkeiten in das Entwicklungsteam einzubetten, als das Sicherheitsteam regelmäßig hinzuzuziehen.