Sichere Systeme

Aus Foxwiki
Version vom 27. Oktober 2023, 09:10 Uhr von Dirkwagner (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „=== Konstruktion sicherer Systeme === * Konstruktion sicherer Systeme * Entwicklungsprozess * Dezidierte Methoden bislang kaum entwickelt * allgemeine methodische in der Regel * top-down Vorgehensweise aus Software-Engineering * Schwierig, da Angreifer viele Möglichkeiten hat ==== Allgemeine Prinzipien ==== * 1975 Saltzer und Schröder * Heute noch gültig ==== Allgemeine Konstruktionsprinzipien ==== * Erlaubnis-Prinzip * Vollständigkeits-Prinzip * Nee…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Konstruktion sicherer Systeme

  • Konstruktion sicherer Systeme
  • Entwicklungsprozess
  • Dezidierte Methoden bislang kaum entwickelt
  • allgemeine methodische in der Regel
  • top-down Vorgehensweise aus Software-Engineering
  • Schwierig, da Angreifer viele Möglichkeiten hat

Allgemeine Prinzipien

  • 1975 Saltzer und Schröder
  • Heute noch gültig

Allgemeine Konstruktionsprinzipien

  • Erlaubnis-Prinzip
  • Vollständigkeits-Prinzip
  • Need-To-Know-Prinzip
  • Prinzip der Benutzerakzeptanz
Erlaubnis (fail-safe defaults)
  • Grundsätzlich jeder Zugriff verboten (default deny)
  • nur durch explizite Erlaubnis wird Zugriffsrecht gewährt.
  • Configfiles
  • Apache
  • SMB
Vollständigkeit (complete mediation)
  • Jeder Zugriff ist auf Zulässigkeit zu prüfen!
  • System, das nur beim Öffnen Erlaubnis prüft, nicht bei jedem Schreiben, verletzt das Prinzip
  • Rechte können sich zwischendurch verändert haben.
Need-to-Know
  • Prinzip der minimalen Rechte
  • Jedes Subjekt bekommt nur genau die Zugriffsrechte, die es zur Erfüllung seiner Aufgaben benötigt.
  • System, in dem ein Admnistratoren unbeschränkte Rechte hat, verstößt gegen dieses Prinzip.
  • AppAmor
  • SELinux
  • Rollenbasierte Rechte
  • Akzeptanz (economy of mechanism)

Benutzerakzeptanz

  • Sicherheitsmechanismen müssen einfach zu nutzen sein
  • routinemäßig und automatisch angewandt werden
Offener Entwurf (open design)
  • Sicherheit eines Systems darf nicht von der Geheimhaltung spezieller Verfahren abhängig sein
  • Verwendete Verfahren und Mechanismen, die beim Entwurf des Systems verwendet werden, müssen offen gelegt werden
  • No security through obscurity
  • Sicherheit kryptografischer Verfahren sollte nicht darauf basieren, dass Verschlüsselungsverfahren nicht bekannt ist.
  • „Schlüssel unter der Fußmatte“
KISS - Prinzip

Keep it simple, stupid

Modellierung

Modellierung

Validierung / Evaluierung

Testen
  • Methodisches Testen des implementierten Systems
  • Verifizierung der sicherheitsrelevanten Funktionen
Testziele, -pläne, -verfahren festlegen, dokumentieren.
  • Vollständigkeit der Tests
  • Code Review
  • Evaluierung durch Dritte