Deine Daten schützen wir mit größter Sorgfalt und Vertraulichkeit. Dafür setzen wir hunderte umfassende Sicherheitsmaßnahmen in allen Bereichen unseres Unternehmens ein.

Wir verpflichten uns zu Transparenz und raschem Handeln in allen Sicherheitsfragen.

Maßnahmen#

Damit Deine hochsensiblen Geschäftsdaten auch im Ernstfall geschützt bleiben, setzen wir durchgehend auf höchste Verschlüsselungsstandards, bewährte Softwareentwicklungs-Praktiken, regelmäßig getestete Backups, automatisierte Fernüberwachung und noch vieles mehr. Sieh' selbst:

• Physische Sicherheit: Rechenzentren und Server
• Backups
• Netzwerksicherheit
• Betriebssystem
• Wartungszugriffe
• Transportsicherheit
• Applikationssicherheit
• Monitoring
• Authentifizierung
• Passwörter
• Sessions
• Clients
• Windows Clients
• Mobile Clients (iOS, Android)
• On-Premise / Kundenserver
• Softwareentwicklung
• Automatisierte Audits
• OpenPGP Verschlüsselung
• Die Sicherheit Deiner Daten ist unser allerhöchstes Anliegen.
• Passt das so für Dich?

Physische Sicherheit: Rechenzentren und Server#

• Alle Rechenzentren sind ISO/IEC 27001 zertifiziert
• Standort in Deutschland: Bayern (Nürnberg) und Sachsen (Falkenstein/Vogtland)
• Betrieben von Hetzer Online GmbH
• Sicherheitspersonal, Alarmanlagen, USV (Unterbrechungsfreie Stromversorgung), Dieselaggregat, Brandfrühesterkennungssystem etc.
• Alle Server sind exklusiv für uns reserviert (dediziert, nicht virtualisiert, ungeteilt)
• Privates Glasfasernetzwerk zwischen den Rechenzentren
• Rund-um-die-Uhr Telefonsupport-Vertrag (24/7) für jedes Rechenzentrum
• RAID-1 für Datensicherheit: Alle Festplatten arbeiten mindestens im RAID-1-Verbund
• Volle Festplattenverschlüsselung (Full Disk Encryption) mit LUKS (Linux Unified Key Setup) auf jedem Server
• SSH und GPG Private Keys liegen in Hardware Security Modules (HSM)

Backups#

• Werden mindestens stündlich erstellt
• Verschlüsselung mit AES-256 sofort nach Erstellung
• Verschlüsselte Übertragung off-site, danach sofort von lokaler Maschine gelöscht
• Backups werden off-site nach einem Jahr endgültig gelöscht
• Vollständiger Wiederherstellungs-Testdurchlauf mindestens ein Mal im Quartal

Netzwerksicherheit#

• VLAN im privaten Glasfasernetzwerk zwischen den Hetzner-Rechenzentren
• Gesamter Verkehr im VLAN zusätzlich mit VPN verschlüsselt (WireGuard)
• VPN verwendet Curve25519, ChaCha20, Poly1305 und symmetrische Schlüssel
• Hardware-Firewall und Software Firewall für alle Server mit strengen Regeln
• DDoS Schutz ist aktiv (Arbor)
• Failover IP, dessen BGP Announcements mit Route Origin Authorizations (ROA) signiert sind (AS 24940)
• DNS ist mit DNSSEC signiert (Cloudflare)

Betriebssystem#

• Gehärtetes (hardened) Ubuntu Linux im Long Term Support (LTS)
• Automatische Sicherheitsupdates sind aktiviert
• Canonical Livepatch ist aktiviert
• Software läuft unter unprivilegierten (non-root) Benutzern in Containern (Docker)
• Verwaltet mit einem Konfigurationsmanagement-Tool (Ansible)

Wartungszugriffe#

• Wartungszugriff mittels SSH v2 ist nur über einen weiteren Bastion Host möglich
• SSH erlaubt nur Ed25519 oder ecdsa-sha2-nistp256 Public/Private Keypairs
• Alle Private Keys liegen in einem Hardware Security Module (HSM)
• Alle Zugriffsversuche und ausgeführte Befehle werden automatisch protokolliert (Verbose)
• Konfiguration des SSH Daemons entspricht mindestens den von Mozilla empfohlenen Guidelines für Modern OpenSSH
• Root Login ist verboten
• Passwort-, Host-based-, Challenge-Response-, PAM-Authentifizierung und Rhosts sind verboten
• Key Exchange, Ciphers und MACs ausschließlich curve25519-sha256 und hmac-sha2-512-etm
• TCP Wrapper für SSH erlaubt nur Bastion Host

Transportsicherheit#

• Nur verschlüsselte Verbindungen über TLS 1.2 oder TLS 1.3 möglich
• HTTP wird permanent auf HTTPS weitergeleitet
• Reverse Proxy schützt Applikationsserver
• TLS Zertifikate von Let's Encrypt und/oder Buypass
• Verschlüsselung mit Elliptischen Kurven (EC) für Perfect Forward Secrecy (PFS)
• Ausschließliche Verwendung von P-521 (NIST FIPS 186-4) und P-384 (NSA Suite B)
• P-384 Private Key (equivalent zu 7680 bit RSA)
• Aktive TLS 1.2 Ciphers sind ausschließlich ECDHE-ECDSA-ChaCha20-Poly1305 und ECDHE-ECDSA-AES256-GCM-SHA384
• OCSP Stapling ist aktiv, und die Zertifikate haben den Must Staple Flag gesetzt
• Zertifikate sind maximal 3 Monate gültig und werden nach zwei Monaten erneuert
• Veröffentlichung im Certificate Transparency Log (CT) ist vorausgesetzt (Expect-CT Header)
• DNS CAA Record ist gesetzt mit Report-Adresse
• Entropie-Generator ist aktiv (Havege)

Applikationssicherheit#

• Die Server setzen die strengsten HTTP-Header
• Strict Transport Security für zwei Jahre, inklusive Subdomains und preload-Direktive
• Domains sind in der HTTP Strict Transport Security (HSTS) Preload Liste aufgenommen
• Content Security Policy verbietet im enforce mode mixed content, framing, media tags, object tags, worker, inline styles
• Verbindungen, Schriftarten, Frames, Bilder, Scripts, Styles nur von vollständigen HTTPS Domains (Whitelist)
• Einmalige Nonce für styles erlaubt
• Keine Wildcards in der Content Security Policy erlaubt
• Expect-CT Header für Certificate Transparency im enforce mode
• XSS Filter im mode block
• Permissions Policy Header deaktiviert alle überflüssigen Features
• Alle Policy-Aktionen werden per Report-URI Direktive zentral gesammelt (Sentry)
• Keine Referrer-Header gesetzt
• robots.txt verbietet alle Pfade für alle Bots
• security.txt enthält Kontaktinformationen und PGP Public Key
• PGP Public Key auf gängigen Keyservern veröffentlicht
• Die Datenbank läuft verteilt auf zwei Hetzner-Rechenzentren
• Datenbank ist nicht von außerhalb erreichbar (VPN)
• Datenbank-Peers authentifizieren sich untereinander mit einem 1024 Zeichen langen Keyfile
• Serverseitige Fehlermeldungen werden nicht an die Clients weitergeleitet

Monitoring#

• Ständige Überwachung aller Systeme mit verschiedenen Diensten
• Zentrales Logging und Alerting
• Zentrales Sammeln der Fehlermeldungen
• Logs, Fehlermeldungen und Performancedaten werden ausschließlich verschlüsselt übertragen
• Logs, Fehlermeldungen und Performancedaten enthalten keine persönlich identifizierbaren Informationen (pseudonymisiert und gefiltert)
• Pseudonyme sind zufällig generiert (Random IDs) und sind nicht erratbar oder vorhersagbar
• Logs werden veränderungssicher und verschlüsselt archiviert
• Der Certificate Transparency Log wird ständig auf ausgestellte Zertifikate überwacht
• Kritische Fehlermeldungen per Email und Chatbot enthalten keine Details (gefiltert)
• Mehrere Filter (Client- und Serverseitig) gewährleisten, dass auch im unvorhergesehenen Fehlerfall keine persönlichen Daten geloggt werden

Authentifizierung#

• Deine MitarbeiterInnen bekommen die jeweils geringsten Rechte, die für ihre Tätigkeit notwendig sind
• Bestimmte Gruppen von MitarbeiterInnen können sich nur an bestimmten Arbeitsplätzen (Clients) anmelden
• Rate Limiting für Login-Versuche
• Login-Fehlermeldungen ohne detaillierte Hinweise verhindern es herauszufinden, welche Benutzer im System angelegt sind (user enumeration)

Passwörter#

• Anforderungen für Passwörter orientieren sich am NIST 800-63B Standard
• Passwörter müssen mindestens zwölf Zeichen lang sein
• Passwörter dürfen nicht wiederverwendet werden
• Passwörter werden beim Erstellen und bei jedem Login auf re-use und bekannte Listen überprüft
• Der Client hasht das Passwort, und die ersten fünf Zeichen des SHA-1 Hashes werden an den Server zur Überprüfung auf bekannte Passwörter gesendet
• Der Server lädt eine Liste von HIBP mit allen bekannten Passwörtern, deren SHA-1 Hashpräfix übereinstimmt (k-Anonymität)
• In dieser Liste sucht der Server, ob der gegebene vollständige Passwort-Hash enthalten ist
• Passwörter sind in der Datenbank als Hash mit Salt gespeichert (bcrypt mit 2¹⁵ = 32768 Anwendungen)

Sessions#

• Der Session Token wird im HTML5 Local Storage auf den Clients abgelegt
• Der Session Token ist nur am selben Tag gültig
• Clients löschen den Local Storage beim Beenden
• Wenn Cookies verwendet werden, haben diese zumindest die folgenden Attribute gesetzt: Secure, HttpOnly, SameSite=strict, Path=/, sowie das Namenspräfix __Host-.

Clients#

• Erlauben nur sichere Verbindungen (HTTPS) zu bekannten URLs (Whitelist)
• Logs, Fehler und Crashes werden verschlüsselt zentral gesammelt und überwacht
• Verbieten Navigation, neue Fenster, WebView tags, und alle Permission Requests
• Plugins, Experimentelle Features, WebGL, und Audio sind deaktiviert
• Clients authentifizieren sich beim Server mit einem 512 Zeichen langen Schlüssel

Windows Clients#

• Realisiert auf Basis von Electron
• Programm und Installer sind jeweils doppelt signiert (SHA-1 und SHA-256 mit Authenticode OV oder EV Zertifikaten) mit Timestamp
• Auto-Updater (NSIS) prüft Code-Signatur und lädt nur über HTTPS
• Code läuft in Context Isolation und ohne Node Integration
• Whitelist für IPC Kommunikation
• Folgt den Electron Best Practices

Mobile Clients (iOS, Android)#

• Zentrale Konfigurationsverwaltung und Sperrmöglichkeit
• Ausschließlich sichere (HTTPS) Verbindungen zu bekannten Domains (Whitelist)
• Betriebssystem hat alle unnötigen Features deaktiviert
• Automatische Sicherheitsupdates aktiviert
• Nutzungsstatistiken deaktiviert
• Screenshots nach Möglichkeit deaktiviert
• Berechtigungen für Mikrofon, Ortung, etc. deaktiviert

On-Premise / Kundenserver#

• Gehärtetes Ubuntu LTS Linux mit automatischen Sicherheitsupdates und Canonical Livepatch (Siehe Betriebssystem)
• Vollständig verschlüsseltes RAID-1 (LUKS)
• Schlüssel zum Booten liegt nicht im selben Gebäude
• Starkes BIOS/UEFI Passwort gesetzt
• Nicht verwendete Ports deaktiviert
• Software-Firewall erlaubt nur Port 443
• Nur innerhalb des lokalen Netzwerks erreichbar
• TLS Zertifikate auch fürs interne Netzwerk (Konfiguration siehe Transportsicherheit)
• Zentralisiertes Monitoring wie oben beschrieben
• Verwaltet mit einem Konfigurationsmanagement-Tool (Ansible)
• Reverse Proxy schützt Applikation
• Authentifizierung über HMAC-Signatur (AWSv4)
• Off-site Backup vor der Übertragung lokal mit AES-256 verschlüsselt

Softwareentwicklung#

• Zwei-Faktor-Authentifizierung (2FA) ist überall aktiviert
• Es werden nur Dienste verwendet, die 2FA unterstützen
• Volle Festplattenverschlüsselung auf allen Entwicklungsgeräten
• Alle Änderungen am Code (Commits) mit PGP signiert
• PGP Private Key liegt in einem HSM (4096 bit RSA oder 3072 bit DSA)
• Zentrales Repository akzeptiert nur Commits mit gültiger Signatur
• Alle Änderungen am zentralen Repository werden geloggt
• Dependencies werden alle vier Stunden automatisiert auf bekannte Sicherheitslücken überprüft und so schell wie möglich aktualisiert
• Dependencies werden auf eine fixe Version zusammen mit dem Hash der Dateien gepinnt
• Diverse Security Advisories für verwendete Komponenten sind abonniert
• Ausschließliche Verwendung von offiziellen Docker Base Images
• Continuous Delivery mit reproduzierbaren Builds
• Minimal nötige Abhängigkeiten, durchgehend sauberer Code
• Beachtung gängiger Standards
• SANS CWE Top 25
• OWASP Top 10 (PDF)
• MITRE Common Weaknesses
• MITRE Common Vulnerabilities

Automatisierte Audits#

• A+ Mozilla HTTP Observatory
• A+ CryptCheck
• A+ Qualys SSLabs
• A+ Security Headers
• A+ High-Tech Bridge SA SSL
• A High-Tech Bridge SA Website Security
• A Mozilla SSH Observatory
• OK Report-URI Content Security Policy
• OK HSTS Preload

OpenPGP Verschlüsselung#

Bitte verschlüssle sicherheitskritische Kommunikation wenn möglich mit unserem OpenPGP Key (Rechtsklick > Ziel speichern unter).

Der Fingerprint lautet: 9B72 A8C3 71C9 6BC0 DEB9 FBC4 51BE E163 824A 7441

Die Sicherheit Deiner Daten ist unser allerhöchstes Anliegen.#

Sollte Dir etwas auffallen, kontaktiere uns bitte unter security@fixpoint.co.at.

Wir antworten Dir so schnell wie möglich.

Passt das so für Dich?#

Super! Dann schreib' uns und wir sprechen zusammen über Dein Vorhaben.

Selbstverständlich komplett unverbindlich und kostenlos.

Wir antworten Dir innerhalb von 48 Stunden.