Die kanonische Ressource für das Konzept von Secure-by-Design ist "Der Schutz von Informationen in Computersystemen" von Saltzer und Schroeder. Die Essenz wird in ihre 8 Prinzipien des sicheren Designs eingeteilt:

1. Wirtschaftlichkeit des Mechanismus
2. Ausfallsichere Standardeinstellungen
3. Vollständige Mediation
4. Offenes Design
5. Trennung von Privilegien
6. Geringstes Privileg
7. Kleinster gemeinsamer Mechanismus
8. Psychologische Akzeptanz

Diese 1974 festgelegten Grundsätze sind bis heute uneingeschränkt anwendbar.

Es wird schwierig sein, Designprinzipien in 30 Minuten zu vermitteln. Ich stimme anderen zu, die sagen, dass man sie auf irgendeine Weise aufregen muss. Ich habe das Kartenspiel "Elevation of Privilege" entwickelt, um die Leute für die Modellierung von Bedrohungen zu begeistern. Es könnte hilfreich sein. ( https://blogs.microsoft.com/cybertrust/2010/03/02/announcing-elevation-of-privilege-the-threat-modeling-game/)

Menschen beizubringen, wie man wie ein Angreifer denkt, ist sehr herausfordernd. Es ist einfacher, ihnen einige Angriffe wie SQL-Injection oder Cross-Site-Scripting beizubringen.

Wenn Sie schließlich versuchen möchten, Prinzipien zu vermitteln, ich hat eine Reihe von Blog-Posts verfasst, in denen Saltzer und Schroeder mit Szenen aus Star Wars illustriert wurden: http://emergentchaos.com/the-security-principles-of-saltzer-and-schroeder

Anstatt sich auf Regeln zu konzentrieren und "diese 5 Regeln zu befolgen, und Sie sind sicher", würde ich mich darauf konzentrieren, Entwicklern Informationen über Angreifer und deren Denkweise zu vermitteln. Sie können nicht wirklich 5 verschiedene Dinge behandeln, von denen jedes einige gründliche Kenntnisse erfordert, um wirklich richtig implementiert zu werden. Warum also versuchen?

Die Entwickler, mit denen ich gesprochen habe, scheinen zu glauben, dass Hacking "wirklich schwer" ist ", und verstehe nicht wirklich, wie einfach es wirklich sein kann. Zu erklären, was Menschen wirklich tun, um die Sicherheit zu vereiteln, kann die Augen öffnen.

Ein Beispiel:

Vor einigen Jahren habe ich ein Web eines Drittanbieters überprüft basiertes Berichtsprodukt und wir hatten einen Entwickler vom Anbieter, der einige Berichte mit dem Produkt erstellt. Ich fragte nach Sicherheit und wie es in ihrem Produkt funktioniert. Er fuhr fort, eine "Ansichtsquelle" auf der Berichtswebseite zu erstellen und mir zu zeigen, wie alles dynamisches HTML war und daher nicht gehackt werden konnte. Ich saß eine Minute lang verblüfft da, sagte ihm aber, dass dies keine wirklich praktikable Sicherheit sei, dass man dem Kundenende nicht vertrauen könne, bla bla bla.

Er glaubte mir nicht und fragte, wie jemand dieses Produkt hacken könne. Ich dachte eine Minute nach und sagte, ich würde den Browser an einen Proxyserver anschließen und die Anfrage / Antwort untersuchen. (Heute würde ich nur das Manipulationsdaten-Plugin verwenden). Dann sagte er, dies sei "Der Hack des Jahrhunderts!" Zu diesem Zeitpunkt warf ich meine Hände nur niedergeschlagen hoch, da er bereits entschieden hatte, dass sein Produkt "sicher" sei. Die einzige Möglichkeit, ihn zu überzeugen, wäre, sein Produkt tatsächlich zu hacken, was meine Zeit nicht wirklich wert war, da ich das Produkt sowieso nicht kaufen würde.

Der Punkt ist, dass Sie mit dem Bedürfnis nach Sicherheit beginnen müssen und mit was wir alle konfrontiert sind. Wenn sie das nicht verstehen, ist das Spiel vorbei. Zumindest wirst du ihnen ein bisschen Angst einflößen, was ein guter Motivator ist. Nach dem, was ich gesehen habe, verstehen es viele Entwickler nicht wirklich und müssen erst verstehen, was sie erwartet. In erster Linie, um zu verstehen, WARUM sie sichere Anwendungen entwickeln müssen.

Bringen Sie die Leute dazu, sich tatsächlich für Sicherheit zu interessieren, und Sie könnten etwas daraus machen. Andernfalls befürchte ich, dass alles, was Sie in 35 Minuten präsentieren, nur auf taube Ohren stößt.

Vielleicht möchten Sie zuerst ihre Aufmerksamkeit erregen. Eine Demo eines SQL-Injection-Angriffs ist einfach, verständlich und kann die Bedeutung des Themas unterstreichen. Sie können während des gesamten Gesprächs darauf zurückgreifen, wenn Sie Punkte machen.

Ich finde es gut, dass Sie an Vertrauensgrenzen stoßen. Mit der Eingabevalidierung würde ich das genauer treffen. Längenüberprüfung zuerst, dann Whitelisting und Blacklisting erwähnen. Empfehlen Sie, dass sie versuchen, fehlerhafte Daten automatisch zu beheben, oder sollten fehlerhafte Eingaben abgelehnt werden? Berühren Sie Strategien, die Sie empfehlen würden.

In Bezug auf die geringsten Berechtigungen könnte dies eine Gelegenheit sein, die Ideen der rollenbasierten Zugriffssteuerung und die Vorteile gegenüber einem benutzerbasierten System vorzustellen.

Ich denke, es gibt die Möglichkeit, das Prinzip der Verteidigung eingehend zu erwähnen. Die Bereinigung von Eingaben ist von entscheidender Bedeutung, aber das Nachverfolgen im Code durch das Erfordernis von parametrisiertem SQL würde auch dann helfen, wenn jemand das Boot bei der Eingabe verpasst.

Stellen Sie in Bezug auf die Protokollierung sicher, dass er das Delta zwischen einer angezeigten Fehlermeldung versteht der Benutzer und der Inhalt der Protokolldateien. Und stellen Sie sicher, dass sie nichts Sensibles protokollieren.

Besprechen Sie auch einen Entwicklungsprozess, der sicherstellt, dass sie auf einem sicheren Weg bleiben. Stellen Sie sicher, dass Peer-Code-Überprüfungen, die Verwendung von statischen Code-Analysatoren und dynamischen Analysatoren Teil ihres Entwicklungsprozesses sind. Das mag außerhalb des Umfangs der Schulung liegen, aber Sie können ihnen beibringen, wie Überprüfungen und Tools zur Verbesserung ihres Codes beitragen.

30-45 Minuten ... autsch. Sie können zum Veranstalter zurückkehren und zwei oder drei Tage anfordern, um zu sehen, welche Art von Reaktion dies hervorruft. Oder vielleicht ein 10-Semester-Programm ... Wie auch immer, viel Glück!

Sie haben offensichtlich eine schwierige Aufgabe, und alle Überlegungen, über die Sie sprechen müssen, geben Ihnen einen sehr vollen Teller. Aber ich denke, eine Erwähnung oder ein Rückgriff auf das beliebteste Schlagwort, die weniger häufig umgesetzte übergreifende Strategie der Tiefenverteidigung, wäre sehr wertvoll, wenn man könnte. Oder vielleicht anders ausgedrückt: "Die Notwendigkeit, Sicherheitsmaßnahmen gegen einen bestimmten großen Bedrohungsvektor in einem anständigen Sicherheitsdesign zu bewerten und Redundanz zu schaffen."

Sie erstellen eine Web-App und sind ziemlich sicher, dass Sie über einen robusten Mechanismus verfügen, mit dem Sie alle Code-Injektionsbemühungen von & aus Ihren Eingaben heraus bereinigen können? Das ist schön. Nehmen wir nun an, ein kreativer Angreifer findet einen Implementierungsfehler, an den Sie noch nie gedacht haben. Dieser Fehler ermöglicht es, dass wirklich bösartiger, leistungsstarker Code vor Ihre eigentliche Anwendung gelangt. Entwerfen Sie &, um Ihre App-Logik mit der Idee zu härten, dass es möglicherweise erforderlich ist, sich diesem Szenario zu stellen, oder gehen Sie einfach davon aus, dass Sie einen starken, zuverlässigen Mechanismus zur Abwehr von Code vor Ihrer Anwendung haben Sie können Ihren Fokus auf andere Dinge verlagern? Weil der Unterschied zwischen diesen beiden Optionen häufig der Unterschied zwischen dem Erreichen eines robusten Sicherheitsdesigns und dem Entwickeln eines mit ziemlicher Sicherheit fragilen Sicherheitsdesigns ist.

(Hinweis : Während ich dies schreibe, stelle ich fest, dass das Beispiel, sich auf die Desinfektion von Eingaben als perfekte Verteidigung zu verlassen, nicht das beste ist, weil in der realen Welt, in der wir heute leben, hoffentlich nur wenige kompetente Entwickler in die Versuchung geraten würden, etwas zu unternehmen so bekanntermaßen sehr unvollkommen wie die Desinfektion von Inputs wie eine grundsolide, undurchdringliche Verteidigungslinie. Hoffentlich. Aber Sie nehmen meinen weiteren Punkt ...)