Sicherheit ist leider immer noch eine allzu häufig vernachlässigte nicht-funktionale Eigenschaft heutiger IT-Systeme. Auftraggeber haben oft nur die implizite Erwartung an ein sicheres System. Wir als Entwickler konzipieren und bauen aber genau das, was explizit gefordert wurde. Mit manchmal unangenehmen Konsequenzen. Das Nachrüsten von Sicherheit in ein bestehendes System ist arbeitsintensiv, zeitaufwändig und teuer. Einfacher ist es, die Sicherheit bereits vom ersten Tag an mit zu berücksichtigen. Hört sich schwierig an? Das muss nicht sein. Dieser Vortrag präsentiert einfache Regeln, Tools, Technologien und Entwurfsmuster für sichere Systemarchitekturen, die ein sicherheitsorientierter Entwickler oder Architekt definitiv kennen sollte. @heise_devSec @qaware #heisedevsec

1. Mario-Leander Reimer
mario-leander.reimer@qaware.de
Das kleine Einmaleins
der sicheren Architektur
Heidelberg, 25. Oktober 2017
Dr. Simon Bäumler
simon.baeumler@qaware.de

2. Mario-Leander Reimer
Cheftechnologe, QAware GmbH
Kontakt Details
Phone: +49 89 23 23 15 121
Mail: mario-leander.reimer@qaware.de
Twitter: @LeanderReimer
Github: https://github.com/lreimer
2
Developer && Architect
20+ Jahre Erfahrung
#CloudNativeNerd
Open Source Enthusiast
QAware

3. Dr. Simon Bäumler
Sofwarearchitekt, QAware GmbH
Kontakt Details
Phone: +49 89 23 23 15 136
Mail: simon.baeumler@qaware.de
3
Secure Developer && Architect
Fan of Microservices, Clouds and
Security (of course!)
15+ Jahre Erfahrung
QAware

4. Prolog

5. HACKERS REMOTELY KILL A JEEP ON THE
HIGHWAY WITH ME IN IT!
https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

6. Sesam öffne
dich!
http://www.heise.de/security/meldung/BMW-ConnectedDrive-gehackt-2533601.html

7. QAware 7

8. QAware 8
Mit Usability als wichtigste Eigenschaft eines Systems,
wird Security häufig zu einer User Story unter vielen.

9. QAware 9
Sichere Software Architektur und Entwicklung bedeutet
Sicherheit von Tag 1 an. Immer wieder auf‘s Neue.
Infrastructure
Certificates
Tokens
Passwords
Security Testing
(DAST + SAST)
Fuzz Testing
Secure Components
Domain Driven Design
Security Patterns
Sicherheitsanforderungen
Schutzbedarfsanalyse
Angreifer-Analyse
OWASP Top 10
Security Monitoring
Dependencies
Package Signing
Container Security

10. Sichere Architektur und Design

11. Softwarearchitekturen und Architektursichten.
QAware 11
TI - ArchitekturT - ArchitekturA - Architektur
Konzeptionelle Sicht
Modulsicht
Ausführungssicht
Programmsicht
Anforderungen
Komponenten
Schnittstellen
Nachbarsysteme
Anwendungsfälle
Entitätenmodell
Rechner
Netzwerke
Infrastruktur
Produkte
Bibliotheken
Frameworks
Technologien

12. QAware 12
Die Sicherheitsarchitektur eines Systems sichert eine
normale Architektur auf verschiedenen Ebenen.
Anwendungs-Architektur
Technische Architektur
Sichere
Anwendungs-Architektur
Sichere
Technische Architektur
Sicherheits-Anforderungen
Security Targets
Externe Quellen:
OWASP Top 10, BSI, PSA,
Technische Infrastruktur
Sichere
Technische InfrastrukturSicherheits
Architektur

13. Die Sicherheitsarchitektur besteht aus abgesicherten
Sicherheitskomponenten und Kommunikationskanälen.
QAware 13
Komponente A Komponente B
Kanal A-B
Trust boundary
(Abgesicherter)
Kommunikationskanal
Komponente
Schnittstelle über einen
Gatekeeper gesichert
Ein System besteht aus Komponenten. Diese sind durch Kommunikationskanäle verbunden.
Beispiele für Komponenten: Datacenter, VMs, Applikationsserver, Datenbanken, Softwaremodule, Browser, …
Jede Komponente wird von jemanden bereitgestellt, der vertrauenswürdig oder nicht vertrauenswürdig ist.
Jede Komponente hat eine definierte Sicherheit. Von unsicher bis sehr sicher:
Wie gründlich muss der Gatekeeper sein: Vom Jedermanns-Recht bis zur Festung
Jeder Kanal hat eine definierte Sicherheit (von sehr sicher bis unsicher):
Wie robust ist der Kanal und das dabei verwendete Protokoll gegenüber den typischen Angriffen?

14. QAware 14
Sicherheitskomponenten können Sicherheitsgruppen bilden mit
harten Grenzkontrollen und laxer innerer Sicherheit.
Komponente A Komponente B
Komponente D
Komponente C
Strenge Sicherheit
Schwache Sicherheit
Keine Sicherheit
Sicherheitsgruppe

15. Entities
Hat Attribute und eine Identität
Kann andere Objekte enthalten
Operiert auf enthaltene Objekte
Value Objects
Sind durch Wert definiert und immutable.
Können andere VOs enthalten.
Können als Attribute verwendet werden
Definiert und prüft wichtige Constraints.
Aggregate Root
Kontrolliert den Zugriff von außerhalb
Sorgt für die Konsistenz innerhalb der Boundary
Zugriff erfolgt über Repositories
Einige Konzepte des Domain Driven Design sorgen für
ein robustes und sicheres Design.
QAware 15
Store
Kunde
Name
Alter
Adresse
0..*
Aggregate
Boundary
Aggregate
Root
Entity
Value
Objects

16. Secure Design Patterns

17. QAware 17
Das interne Design einer Sicherheitskomponente wird
durch die Sicherheitsanforderungen beeinflusst.
Canonicalization
Verlustlose Vereinfachung der
Representation.
Normalization
Verlustbehaftete Vereinfachung der
Representation.
Sanitization
Entfernen geschützter, unsinniger und
schädlicher Datenwerte
Stellt Datenhygiene sicher
Validation
Prüft, ob Daten einem erwarteten
Muster entsprechen
Typprüfung und Wertebereichsprüfung

18. QAware 18
Sicherheit ist eine querschnittliche Anforderung. AOP-
Interceptoren eignen sich perfekt für die Umsetzung.
Interceptor + Binding annotations
Sanitize parameters and continue
Get annotation from method or it’s
declaring class
Activate in beans.xml

19. Security Decorators erlauben die Umsetzung von
Komponentenspezifischen Sicherheitsanforderungen.
19
Activate in beans.xml
Inject the delegate instance
Do any additional security
check that my be required
QAware

20. Apply Design by Contract (DbC) to your gate keeper and
security components using the method validation API.
20
Die Schnittstelle als Vertrag
Pre- und Post-Conditions von
Methoden mit javax.validation
Annotationen.
QAware

21. Bei verteilten Systemen: Sichere
die Kommunikationswege!

22. Server
22
Kommunikationskanäle auf mehreren Ebenen
absichern.
Welches sind die logischen Endpunkte?
Client
Firewall
Reverse Proxy
Anwendung 1 Anwendung 2
HTTPS HTTP HTTP
REST/JSON REST
Security Layer
Application Layer
Sec. L.
Fachliche Kommunikationskanäle gehen über mehrere technische Abschnitte.
QAware

23. Der Gatekeeper versteckt den Security Layer vor dem
Business Code.
23
CMS-Format
Standard, kann mit OpenSSL geprüft werden
Payload-Type explizit angegeben
Nicht raten, sondern wissen und dagegen prüfen
Erst PayloadType prüfen: Passt das zur Erwartung?
Dann Payload parsen: Ist das wirklich der angegebene
Typ?
Nonces: Für Freshness, gegen Replay
Validierung: Verfügbare Prüfregeln im Security Layer
verankert
Beispiele: Enthält Nonce: Ja/Nein
Client-ID ist gleich Common-Name des Signers
Konkrete Definition erfolgt auf fachlicher Ebene
CMS Signed Data
Signature[s]
Certificate[s]
(optional)
Secure Container
DER Sequence
Nonces
Each: DER Octet String(16 octets)
payloadType
DER UTF8 String
payload
DER Octet String
Client-ID
Each: DER UTF8 String
Message
JSONDER Octet String,
containing a

24. Es gibt eine Reihe an technischen Bausteinen, die von
einem Gatekeeper genutzt werden können.
24
Security Frameworks wie PicketLink, Shiro, HDIV, OWASP ESAPI
bieten eine umfassende Sammlung an vorgefertigten
Sicherheitsfunktionen zur Integration in Web-Anwendungen, wie:
Authentifizierung und Single-Sign-On
Autorisierung
Kryptographie
Session Management
Abwehr von Angriffen gegen eingesetzte Frameworks (z.B. JSF)
Edge Server und Web Application Firewalls wie z.B. Zuul oder mod_security* schützen
den HTTP-Kanal bereits bevor ein Request beim Server ankommt mit:
Rate Limiting und Tarpits
Autorisierung und Authentifizierung
Abwehr klassischer Angriffe
*) mod_security ist ein Plugin für den Apache Webserver.
Es steht von OWASP ein Regelsatz für mod_security zur Verfügung:
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
QAware

25. Impact Reduction:
Falls etwas passiert müssen die
Angriffe erkannt werden.

26. 26
Häufig übersehen: Vorhandene Logs sind eine wertvolle
Quelle, um Angriffe zu erkennen und zu analysieren.
Logstash Kibana
Zentrale Fragen:
Was wird geloggt?
(https://www.owasp.org/index.php/Logging_Cheat_Sheet)
Wie werden die Logs eingesammelt und analysiert?
Wie werden die Logs analysiert? (Kibana, …)
Lassen sich Sicherheitsprobleme leicht erkennen?
Eine vorgefertigte Kette zur Log-Analyse gibt es z.B. von
OSSEC (http://www.ossec.net)
Ziel: Angriffe schon während einer
Ausspähungsphase erkennen und blocken:
WAFs (Web Appication Firewalls) und IDS
(Intrusion Detection Systeme) haben nur
begrenzten Einblick Anwendungsinterna.
Einfache und wichtige Informationsquelle zur
Erkennung von Angriffen: Logs.
Erlaubtes und unerlaubtes Verhalten kann
besser mit dem fachlichen Kontext
unterschieden werden.
QAware

27. Der AppSensor Ansatz:
Instrumentierung der Anwendung mit logähnlichen
Detection Points.
Auswertung der gesammelten Daten auf dem AppSensor
Server. Angriffserkennung kann damit weiter automatisiert
werden.
Rückkopplung zum System vorgesehen um z.B.
Nutzerkonten von Angreifern zu sperren.
 Automatischer Schutz bei identifizieren Angriffen
Der OWASP AppSensor erlaubt die kontext-sensitive
Erkennung und die Reaktion auf Angriffe.
QAware 27

28. QAware 28
Der AppSensor Server ist eine Infrastruktur-
Komponente der Sicherheitsarchitektur.
Component A Component B
Component D
Component C
AppSensor
Provisionierung der Komponenten
mit Detection Points

29. QAware 29
Der AppSensor Server ist eine Infrastruktur-
Komponente der Sicherheitsarchitektur.
Component A Component B
Component D
Component C
AppSensor
AppSensor
Detection Points
liefern Daten zum
Nutzerverhalten

30. QAware 30
Der AppSensor Server ist eine Infrastruktur-
Komponente der Sicherheitsarchitektur.
Component A Component B
Component D
Component C
AppSensor
Datenanalyse: Erkennung von
Angriffsmustern anhand von
Heuristiken

31. QAware 31
Der AppSensor Server ist eine Infrastruktur-
Komponente der Sicherheitsarchitektur.
Component A Component B
Component D
Component C
AppSensor
Bei erkannten Angriffsversuchen:
z.B. Sperrung des Benutzers /
der Funktionalität

32. AppSensor kennt 50 Typen von Detection Points.
QAware 32
Zugriff auf
Resourcen ohne
Berechtigung
Client-Seitige
Input Validierung
umgangen
Unerwartetes
Datenformat
Verdächtiges
Login Verhalten
Angriffsversuch
erkannt
Automatisierter
Applicationssca
n erkannt

33. Weniger als 10% der Bytecode
Instruktionen moderner JEE
Applikationen sind eigener Code!

34. Ungefähr 26% der von Maven
Central heruntergeladenen
Bibliotheken beinhalten bekannte
Schwachstellen!
https://www.owasp.org/index.php/OWASP_AppSec_DC_2012/The_Unfortunate_Reality_of_Insecure_Libraries

35. 35
OWASP Top 10 2017
A9 should be in the Top 3!
QAware

36. Der sichere Einsatz von Open Source Komponenten ist
ein wichtiger Bestandteil der Applikationssicherheit
QAware 36
Wie kann eine Applikation gegen Schwachstellen in Open Source Software geschützt werden?
Option a) Keine Open Sourcesoftware einsetzen!  Nicht realistisch!
Option b) Klare Guidelines zum sicheren Einsatz von Open Source Software.
Analyse von Sicherheitseigenschaften der Bibliotheken schon beim Auswählen der Bibliotheken.
Berücksichtigung von Schwachstellen bei der Auswahl der eingesetzten Version.
Beobachten von neuen Schwachtellen, die während des Projektlebenszyklus entstehen können. Hier helfen
öffentliche Datenbanken (CVE, NVD) und die Projektseiten.
Einbau von security decorators, um unsichere oder unbenutzte Funktionalität der Software abzusichern oder
zu deaktivieren.

37. QAware 37
Das Sicherheitslevel von Open Source Komponenten
kann anhand von klaren Kriterien entschieden werden.
Frage Alarmglocke Quelle
Wie reif ist die Software? Es gibt kein Final-Release. Das aktuelle Release hat eine
Versionsnummer unterhalb 1.0. Das Codevolumen im Projekt
steigt stark an.
Das Projekt existiert seit weniger als einem Jahr.
Projekt-Website,
mvnrepository.com,
antepedia.com
Steht ein Maven-Artefakt
zur Verfügung?
Es ist kein offizielles Artefakt veröffentlicht. Maven-Artefakt sind in
nicht vertrauenswürdigen Repositories veröffentlicht.
Projekt-Website,
mvnrepository.com
Wie gut ist die
Dokumentation?
Keine API-Dokumentation. Kein Releasenotes. Werden
Sicherheitslücken durch CVEs (Common Vulnerability
Enumeration) dokumentiert?
Projekt-Website,
cve.mitre.org
Gibt es kritische
Mängel?
Kritische Bugs oder kritische Sicherheitslöcher sind bekannt, für
deren Target-Release es noch keine Terminaussage gibt bzw. der
Release-Termin länger als 2 Monate entfernt liegt bzw. die schön
länger als 4 Monate offen sind.
Projekt-Issue-Tracker,
Projekt-Website,
Antepedia.com
cve.mitre.org,
osvdb.org
Ist das Projekt tot oder
irrelevant?
Es existiert kein Eintrag für das Projekt auf Openhub. Es gab kein
Release in den vergangenen 12 Monaten. Es gab in den letzten 12
Monaten mehr als einen Monat ohne Commit.
openhub.net,
Projekt-Website,
mvnrepository.com
Wie stabil ist die
Entwickler-Community?
Das Projekt hat weniger als 3 aktive Committer. Das
Versionskontrollsystem ist öffentlich zugänglich.
openhub.net,
Projekt-Website
OpenSourceSecurityQuickCheck
Transpanenz!
Vorraussetzung für
Tools wie
Dependency
Check
Eventuell fehlen
Sicherheitsfeatures
oder -tests
Indikator, wie lange
es dauert, bis
Sicherheitsproblem
e behoben werden
Werden
Schwachstellen
noch behoben?

38. mvn versions:display-dependency-updates
38
[INFO] The following dependencies in Dependencies have newer versions:
[INFO] com.sun.faces:jsf-api ......................................... 2.1.10 -> 2.2.12
[INFO] com.sun.jersey:jersey-client ..................................... 1.9.1 -> 1.19
[INFO] commons-fileupload:commons-fileupload ........................... 1.2.1 -> 1.3.1
[INFO] org.apache.httpcomponents:httpclient ............................ 4.2.1 -> 4.5.1
[INFO] org.apache.solr:solr-core ....................................... 4.6.1 -> 5.3.1
QAware

39. 39
mvn org.owasp:dependency-check-maven:check
QAware
49 scanned dependencies
6 vulnerable dependencies
8 found vulnerabilities

40. 40
mvn org.owasp:dependency-check-maven:check
QAware

41. 100% Sicherheit gibt es nicht!

42. Geeignete Maßnahmen auf
allen Ebenen der Architektur
können die Sicherheit eines
Systems deutlich erhöhen.

44. QAware GmbH München
Aschauer Straße 32
81549 München
Tel.: +49 (0) 89 23 23 15 – 0 github.com/qaware
linkedin.com/qaware slideshare.net/qaware
twitter.com/qaware xing.com/qaware