Security by Design Decisions (German Version)

Warum brauchen wir eigentlich Security by Design?

  • Wir versuchen mit „Warnschildern“ (Awareness-Trainings), Nutzer vor dem Klicken auf böse Links zu bewahren.
  • Wir versuchen mit „Eimern“ (Virenschutzprogrammen), Schadsoftware aufzufangen, bevor sie ausgeführt wird.
  • Wir versuchen mit „Pflastern“ (Software-Updates) Schwachstellen zu schließen.
  • Wir versuchen mit „Dichtungsmasse“ (User Policies), die Benutzung der Systeme sicherer zu machen.

Definition: Security by Design

  • Bei der Verschmelzung wird der Basis-Workflow so modifiziert, dass er Security Engineering enthält.
    Beispiele aus dem Software-Engineering sind Microsofts „Security Development Lifecycle“ oder auch — etwas moderner — DevSecOps.
  • Bei der Harmonisierung wird der Security-Engineering-Workflow dem Basis-Workflow so ähnlich wie möglich gemacht, sodass er einfach integrierbar ist.
    Beispiele finden sich hier im Model-based Systems Engineering: Für die Modellierung mittels UML gibt es die Security-Ergänzung “UMLsec”, für SysML gibt es “SysMLsec”.
  • Bei der Kopplung bleiben beide Workflows unverändert, aber es werden feste Kopplungspunkte im Basis-Workflow definiert, an denen Informationen ins Security-Engineering eingebracht werden und Ergebnisse aus dem Security-Engineering in den Basis-Workflow zurückfließen — und zwar vor den wichtigen Design-Entscheidungen (den grünen Punkten):
    Beispiele sind im Bereich Security for Safety zu finden. Sowohl der IEC TR 63069:2019 als auch der noch im Entwurf befindliche ISA TR84.00.09 Ed3 verwenden diesen Ansatz des „Co-Engineerings”.
  • Die Auslösung ist ein Spezialfall der Kopplung mit nur einem Kopplungspunkt: wenn der Basis-Workflow an einem bestimmten Punkt ist, wird auf Basis dort vorhandener Informationen der Security-Engineering-Workflow ausgelöst.
    Beispiele kommen auch hier wieder aus dem Bereich Security for Safety (Security PHA), aber auch aus dem Bereich Security kritischer Infrastrukturen mit INL’s Consequence-driven, Cyber-informed Engineering (CCE).

Security by Design muss unabhängig von der Art des Automation-Engineering-Workflows gelingen.

Security by Design Decisions — Einführung ins Konzept

  1. Im ersten Teil schauen wir nur von außen auf den Entscheidungspunkt, quasi auf sein Etikett und beantworten die Frage, WANN wir eine Security-Entscheidung treffen.
  2. Im zweiten Teil machen wir den Entscheidungspunkt transparent, schauen ins Innere und bentworten die Frage, wie wir die Security-Entscheidung treffen.

1. Wann treffe ich eine Security-Entscheidung?

2. Wie treffe ich eine Security-Entscheidung?

Es ist unmöglich, KEINE Security-Entscheidungen zu treffen. Wichtig ist, sie sichtbar zu machen.

Ausblick: Ein Tool für Security by Design Decisions

Die Vielzahl von relevanten Informationen, um Security-Entscheidungen zu treffen, ist für Menschen am besten visuell erfassbar.

  • Security by Design muss unabhängig von der Art des Automation-Engineering-Workflows gelingen.
  • Es ist unmöglich, keine Security-Entscheidungen zu treffen. Security by Design muss sie sichtbar machen.
  • Die Vielzahl von relevanten Informationen, um Security-Entscheidungen zu treffen, ist für Menschen am besten visuell erfassbar.

--

--

Friction generates heat — true for writing and engineering. Fluchsfriction generates writings on security engineering. Heated debates welcome! CTO@admeritia

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store