Sichere Systeme: Unterschied zwischen den Versionen

Aktuelle Version vom 9. Dezember 2023, 07:46 Uhr

Sicherer Systeme - Konstruktion sicherer Systeme

Beschreibung

Entwicklungsprozess

Dezidierte Methoden bislang kaum entwickelt

Allgemeine methodische Regeln

top-down Vorgehensweise aus Software-Engineering
Schwierig, da Angreifer viele Möglichkeiten hat

1975 Saltzer und Schröder

Nach wie vor gültig

Allgemeine Prinzipien

Allgemeine Konstruktionsprinzipien

Option	Beschreibung
Erlaubnis	fail-safe defaults
Vollständigkeit	complete mediation
Need-to-Know
Benutzerakzeptanz
Offener Entwurf	open design
KISS - Prinzip
Validierung/Evaluierung

Erlaubnis

Fail-Safe Defaults

Verbot mit Erlaubnisvorbehalt
Grundsätzlich ist jeder Zugriff verboten
Default Deny
Nur durch explizite Erlaubnis wird Zugriffsrecht gewährt
Whitelisting

Vollständigkeit

Jeder Zugriff ist auf Zulässigkeit zu prüfen!

Complete Mediation

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

Systeme, in dem Administratoren unbeschränkte Rechte haben, verstoßen gegen dieses Prinzip

AppAmor
SELinux
Rollenbasierte Rechte

Benutzerakzeptanz

Sicherheitsmechanismen müssen

einfach zu nutzen sein
routinemäßig und automatisch angewandt werden
Akzeptanz (economy of mechanism)

Offener Entwurf

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

Validierung/Evaluierung

Üben und 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

Anhang

Siehe auch

Sichere Systeme

Links

Projekt

Weblinks

@@ Zeile 1: / Zeile 1: @@
-'''topic''' - Kurzbeschreibung
+'''Sicherer Systeme''' - Konstruktion sicherer Systeme
 == Beschreibung ==
 ; Entwicklungsprozess
@@ Zeile 8: / Zeile 9: @@
 * Schwierig, da Angreifer viele Möglichkeiten hat
-== Allgemeine Prinzipien ==
+; 1975 Saltzer und Schröder
-Saltzer und Schröder
 * Nach wie vor gültig
+== Allgemeine Prinzipien ==
 ; Allgemeine Konstruktionsprinzipien
-{| class="wikitable sortable options"
+{| class="wikitable options"
 |-
 ! Option !! Beschreibung
 |-
-| Erlaubnis (fail-safe defaults) ||
+| [[#Erlaubnis|Erlaubnis]] || fail-safe defaults
 |-
-| Vollständigkeit (complete mediation) ||
+| [[#Vollständigkeit|Vollständigkeit]] || complete mediation
 |-
-| Need-to-Know ||
+| [[#Need-to-Know|Need-to-Know]] ||
 |-
-| Benutzerakzeptanz ||
+| [[#Benutzerakzeptanz|Benutzerakzeptanz]] ||
 |-
-| Offener Entwurf (open design) ||
+| [[#Offener Entwurf|Offener Entwurf]] || open design
 |-
-| KISS - Prinzip ||
+| [[#KISS - Prinzip|KISS - Prinzip]] ||
 |-
-| Modellierung ||
+| [[#Validierung/Evaluierung|Validierung/Evaluierung]] ||
-|-
-| Validierung / Evaluierung ||
 |}
-=== Erlaubnis (fail-safe defaults) ===
+=== Erlaubnis ===
-* Grundsätzlich jeder Zugriff verboten (default deny)
+; Fail-Safe Defaults
-* nur durch explizite Erlaubnis wird Zugriffsrecht gewährt.
+* Verbot mit Erlaubnisvorbehalt
-* Configfiles
+* Grundsätzlich ist jeder Zugriff verboten
-* Apache
+* Default Deny
-* SMB
+* Nur durch explizite Erlaubnis wird Zugriffsrecht gewährt
+* [[Whitelisting]]
-=== Vollständigkeit (complete mediation) ===
+=== Vollständigkeit ===
-* Jeder Zugriff ist auf Zulässigkeit zu prüfen!
+; Jeder Zugriff ist auf Zulässigkeit zu prüfen!
+; Complete Mediation
 * System, das nur beim Öffnen Erlaubnis prüft, nicht bei jedem Schreiben, verletzt das Prinzip
-* Rechte können sich zwischendurch verändert haben.
+* Rechte können sich zwischendurch verändert haben
 === Need-to-Know ===
-* Prinzip der minimalen Rechte
+; Prinzip der minimalen Rechte
-* Jedes Subjekt bekommt nur genau die Zugriffsrechte, die es zur Erfüllung seiner Aufgaben benötigt.
+* 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.
+; Systeme, in dem Administratoren unbeschränkte Rechte haben, verstoßen gegen dieses Prinzip
 * AppAmor
 * SELinux
 * Rollenbasierte Rechte
-* Akzeptanz (economy of mechanism)
 === Benutzerakzeptanz ===
-* Sicherheitsmechanismen müssen einfach zu nutzen sein
+; Sicherheitsmechanismen müssen
+* einfach zu nutzen sein
 * routinemäßig und automatisch angewandt werden
+* Akzeptanz (economy of mechanism)
-=== Offener Entwurf (open design) ===
+=== Offener Entwurf ===
-* Sicherheit eines Systems darf nicht von der Geheimhaltung spezieller Verfahren abhängig sein
+; 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
@@ Zeile 69: / Zeile 74: @@
 [[Keep it simple, stupid]]
-=== Modellierung ===
+=== Validierung/Evaluierung ===
-[[Modellierung]]
+; Üben und Testen
-=== Validierung / Evaluierung ===
-;Testen
 * Methodisches Testen des implementierten Systems
 * Verifizierung der sicherheitsrelevanten Funktionen
@@ Zeile 91: / Zeile 93: @@
 ===== Weblinks =====
-[[Kategorie:Risikomanagement]]
+[[Kategorie:Entwurf]]
 </noinclude>