it-swarm.com.de

Lehre "Secure by Design"

Ich bin ein Sicherheitsarchitekt und ich bin es gewohnt, die Sicherheit eines Projekts als eine Spezifikation zu definieren, die von anderen ausgeführt wird. Ich wurde kürzlich beauftragt, neuen Programmierern das Entwerfen und Programmieren nach den Prinzipien von "Secure by Design" (und in naher Zukunft "Privacy by Design") beizubringen. Ich habe 30-45 Minuten (ja, ich weiß) und das Gespräch muss sprachunabhängig sein. Dies bedeutet, dass ich umsetzbare Regeln präsentieren muss, die von den Webentwicklern, Anwendungsentwicklern und Infrastrukturentwicklern angewendet werden können.

Ich habe mir 5 Grundregeln und eine Ergänzung ausgedacht:

  1. Vertrauen Sie keinen internen/externen Eingaben (deckt Hygiene, Pufferüberläufe usw. ab).
  2. Geringste Berechtigung für eine Entität, ein Objekt oder einen Benutzer
  3. Fehlschlagen "kein Privileg"
  4. Sicher, auch wenn das Design bekannt/öffentlich ist
  5. Protokollieren Sie, damit jemand, der mit dem System nicht vertraut ist, jede Aktion überwachen kann

Ergänzung: Wenn Sie gegen eine Regel verstoßen, beweisen Sie, dass die Schadensbegrenzung zukünftige Programmierer überleben kann, die Funktionen hinzufügen.

Jede dieser Regeln kann durch Beispiele aus einer beliebigen Sprache oder Anwendung ergänzt werden, um eine spezifische Anleitung zu erhalten. Ich glaube, dies behandelt die meisten allgemeinen Prinzipien von "Secure by Design" aus einer hochrangigen Perspektive. Habe ich etwas verpasst

52
schroeder

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

  1. Wirtschaftlichkeit des Mechanismus
  2. Ausfallsichere Standardeinstellungen
  3. Komplette Mediation
  4. Offenes Design
  5. Privilegientrennung
  6. Am wenigsten Privileg
  7. Am wenigsten verbreiteter Mechanismus
  8. Psychologische Akzeptanz

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

37
bonsaiviking

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 versuchen möchten, Prinzipien zu vermitteln, habe ich eine Reihe von Blog-Posts verfasst, in denen Saltzer und Schroeder mit Szenen aus Star Wars illustriert werden: http://emergentchaos.com/the-security-principles-of-saltzer) -und-schroeder

21
Adam Shostack

Anstatt mich 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 beizubringen. Sie können nicht wirklich 5 verschiedene Dinge behandeln, von denen jedes einige gründliche Kenntnisse erfordert, um wirklich richtig zu implementieren. Warum also versuchen?

Die Entwickler, mit denen ich gesprochen habe, scheinen zu denken, dass Hacking "wirklich schwer" ist, und verstehen nicht wirklich, wie einfach es wirklich sein kann. Es kann also aufschlussreich sein, zu erklären, was Menschen wirklich tun, um die Sicherheit zu vereiteln.

Ein Beispiel :

Vor einigen Jahren habe ich ein webbasiertes Berichtsprodukt eines Drittanbieters überprüft, und wir hatten einen Entwickler vom Anbieter, der einige Berichte mit dem Produkt erstellt hat. 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 hackbar war. 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). Er sagte dann, dies wäre "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, bestand darin, 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, Sie müssen mit dem Bedürfnis nach Sicherheit beginnen und mit dem, was uns allen bevorsteht. 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 verstehen zu können, WARUM sie sichere Anwendungen entwickeln müssen.

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

8
Steve Sether

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 mag es, dass man an Vertrauensgrenzen stößt. 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 Zugriffskontrolle 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 es wäre hilfreich, sie im Code zu verfolgen, indem parametrisiertes SQL benötigt wird, selbst wenn jemand das Boot bei der Eingabe verpasst.

Stellen Sie bei der Protokollierung sicher, dass sie das Delta zwischen einer dem Benutzer angezeigten Fehlermeldung und dem Inhalt der Protokolldateien verstehen. 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!

3
John Deters

Sie haben offensichtlich eine schwierige Aufgabe, und alle Überlegungen, über die Sie gesprochen haben, werden Ihnen einen sehr vollen Teller geben. 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 Sie könnten. Oder vielleicht anders ausgedrückt: "Die Notwendigkeit, Sicherheitsmaßnahmen gegen einen bestimmten Hauptbedrohungsvektor 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-Injection-Bemühungen aus Ihren Eingaben 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 und härten Sie Ihre App-Logik mit der Idee, dass sie sich möglicherweise diesem Szenario stellen muss, 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? Denn der Unterschied zwischen diesen beiden Optionen wird oft der Unterschied zwischen dem Erreichen eines robusten Sicherheitsdesigns und dem Entwickeln eines mit ziemlicher Sicherheit fragilen Sicherheitsdesigns sein.

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

1
mostlyinformed