Frage:
Lehre "Secure by Design"
schroeder
2016-01-06 00:29:27 UTC
view on stackexchange narkive permalink

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. Vertraue 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 "keine Berechtigung"
  4. Sicher, auch wenn das Design bekannt / öffentlich ist
  5. Protokollieren Sie, damit jemand nicht vertraut ist Mit dem System kann jede Aktion überwacht werden.
  6. ol>

    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 erweitert werden mit Beispielen aus jeder Sprache oder Anwendung für spezifische Anleitungen. Ich glaube, dies behandelt die meisten allgemeinen Prinzipien von "Secure by Design" aus einer hochrangigen Perspektive. Habe ich etwas verpasst?

Lassen Sie bitte die Usability-Maxime von AviD nicht aus!
Bitte vergessen Sie nicht, ein "Wie finde ich mehr heraus?" Sektion. Es hört sich so an, als wäre dies ein schneller Vorgeschmack darauf, wie wichtig Standard-Sicherheit ist, und das eigentliche Lernen (der Implementierung) wird später erfolgen. Es ist wichtig, entweder sich selbst oder Kollegen oder geeignete Online-Ressourcen zu kennzeichnen, die für " später".
Wie groß ist Ihre voraussichtliche Klassengröße?
@DeerHunter grub tiefer. "Sicherheit auf Kosten der Benutzerfreundlichkeit geht zu Lasten der Sicherheit." - Avi Douglen
Wenn Sie 30 bis 45 haben, ist es sinnlos, 5 Prinzipien zu lehren. Wenn Sie das Publikum dazu bringen können, tatsächlich ein einziges Prinzip anzuwenden, wäre dies ein Erfolg.
Ich bin mir nicht ganz sicher, was Sie in Punkt 3 meinen, aber ich würde auch etwas wie "Berechtigungen nicht zwischenspeichern" einschließen - zum Beispiel könnte ein Benutzer angemeldet sein und ein Administrator ändert seine Berechtigungen und wenn sie zwischengespeichert werden Beim Anmelden können sie weiterhin auf Aktionen zugreifen, die sie nicht mehr haben sollten. Mein Rat wäre also, vor jeder Aktion zu überprüfen / zu validieren, ob der Benutzer über die erforderlichen Berechtigungen verfügt.
"Secure by Design" ist ein ziemlich vager Begriff, wenn man wirklich darüber nachdenkt. Eine Frage an Sie: Wie würde "Secure by Design" die SQL-Injection verhindern? Wenn Sie das erklären können, kann ich besser verstehen, was Sie versuchen zu tun.
@paj28 "Secure by Design" ist ein Ansatz. Ihre SQLi-Frage passt nicht. Aus dem Zen-Denken zu leihen, lautet die Antwort "mu".
Sie können sich mehrere europäische Projekte ansehen, die sich kürzlich mit den Prinzipien und Techniken von Secure by Design befasst haben. Ich habe an einem von ihnen im Bereich Trust Management gearbeitet. Das Projekt heißt NESSoS und konzentrierte sich auf Sicherheitstechnik für das zukünftige Internet. Sie können die Ergebnisse des Projekts hier lesen: http://www.nessos-project.eu/index.php?option=com_content&view=article&id=104&Itemid=126
Gehen Sie die OWASP Top 10 durch oder erwähnen Sie es zumindest? Die Menschen müssen sich bewusst sein, dass Sicherheit ein sich ständig änderndes Feld ist, und sie sollten sich lange nach dem Gespräch auf dem Laufenden halten.
Fünf antworten:
#1
+38
bonsaiviking
2016-01-06 01:09:21 UTC
view on stackexchange narkive permalink

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
  9. Diese 1974 festgelegten Grundsätze sind bis heute uneingeschränkt anwendbar.

40 Jahre und wir haben immer noch Millionen von Webapps, die blind akzeptieren, welche Eingaben ihnen zugesandt werden ...
Ich bin auf diese nützliche Perspektive gestoßen. Http://cryptosmith.com/2013/10/19/security-design-principles/
#2
+21
Adam Shostack
2016-01-06 02:04:50 UTC
view on stackexchange narkive permalink

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

Die Links http://microsoft.com/security/sdl/eop in https://blogs.microsoft.com/cybertrust/2010/03/02/announcing-elevation-of-privilege-the-threat-modeling-game/ funktioniert nicht mehr. Können Sie den Link zum Herunterladen des Kartenspiels bereitstellen?
@PiyushSaurabh Dies sieht aus wie die neue Seite: https://www.microsoft.com/en-us/SDL/adopt/eop.aspx
Danke @bonsaiviking! Ich habe nicht bemerkt, dass die Verbindung unterbrochen wurde, und da ich weitergezogen bin, ist es eine Herausforderung, das Problem zu beheben.
#3
+8
Steve Sether
2016-01-06 01:09:10 UTC
view on stackexchange narkive permalink

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.

Nach meiner Erfahrung besteht das größte Sicherheitsrisiko nicht in Angreifern, sondern in schlechtem Design. Ich muss sie über die richtigen Designprinzipien unterrichten.
@schroeder Sie können nicht in 35 Minuten gutes Design unterrichten. Vergiss es. Gib ihnen einen Haken, um mehr zu erfahren.
Ich muss nicht "gutes Design" unterrichten - ich brauche Haken, mit denen sie arbeiten können. Dann kann ich sie vergleichen und bitten zu beweisen, wie ihr Design / Code den Regeln entspricht.
@schroeder Wenn sie die Bedrohungen nicht verstehen, wie können sie dann wirklich verstehen, wie sie ihren eigenen Code bewerten? Sicherheit kommt nicht von einem Lehrer, der Sie bittet, zu beweisen, dass Ihre eigene Arbeit sicher ist. Die Person mit dem geringsten Wissen über etwas wird ihre eigenen Fähigkeiten hoch bewerten. Dies ist in den Sozialwissenschaften als Mahn-Krüger-Effekt bekannt. Werden Entwickler mit 35 Minuten Schulung wissen können, ob sie sichere Software entwickelt haben, oder werden sie ihre eigenen Fähigkeiten erheblich überschätzen? Meine Vermutung ist die letztere.
#4
+3
John Deters
2016-01-06 01:34:30 UTC
view on stackexchange narkive permalink

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!

Eine Demo ist eine großartige Sache für den Anfang - der Sicherheitsmann hat uns (vor Jahren) einen IIS-Exploit gezeigt, etwas Magie in die Adressleiste eingegeben und selbst eine Eingabeaufforderung mit Administratorrechten erhalten. Zu diesem Zeitpunkt war es offensichtlich, dass wertlose Sicherheitsfunktionen, die wir möglicherweise auf die gesamte Box angewendet haben, wertlos waren. (Trennen Sie also Ihre App-Logik mindestens auf einen anderen Server, keine direkten DB-Verbindungen vom Webserver zulässig!)
#5
+1
mostlyinformed
2016-01-06 09:56:15 UTC
view on stackexchange narkive permalink

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 ...)

Stellen Sie sich einen Zero-Day-Exploit auf dem Webserver selbst vor, mit dem ein Angreifer jede Eingabebereinigung effektiv umgehen kann. Sobald sie den Webserver besitzen, können sie "aus Benutzern auswählen" und all diese saftigen Passwörter herunterladen.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...