App Security

Moderne Apps haben hohe Sicherheitsstandards auf Basis neuester Anforderungen für Anwendungen im Gesundheitswesen. SevenD zeigt hier die wichtigsten Erkenntnisse aus der Entwicklung der medizinischen App PATRONUS Health und nennt anhand konkreter Beispiele, worauf es ankommt.

Die Sicherheit persönlicher und sensibler Daten spielt in der Appentwicklung eine große Rolle. Sobald persönliche Daten in der App erfasst oder verarbeitet werden, muss sie einen maximalen Datenschutz gewährleisten. 

Beispiele für Anwendungen, die besondere Sicherheitsanforderungen erfüllen müssen, sind Homebanking Apps (z.B. Sparkasse), Tracking Apps (z.B. Luca), Communication Apps (z.B. WhatsApp) und vor allem auch Medical Health Apps (z.B. PATRONUS Health). 

Anlässlich unserer aktuellen Entwicklung der medizinischen PATRONUS Health App haben wir uns bei SevenD in letzter Zeit noch intensiver mit den gesteigerten Security-Anforderungen an App im medizinischen Bereich auseinandergesetzt. 

Die PATRONUS Health App soll Patienten durch ein individuelles Prähabilitationsprogramm optimal auf eine bevorstehende Operation vorbereiten. Dies verringert das Risiko größerer Komplikationen nach der OP um 20-30%, senkt die Behandlungskosten und verkürzt somit die anschließende Aufenthaltsdauer im Krankenhaus. Alles in Allem: Ein tolles Projekt, das den Nutzern bzw. Patienten einen echten Mehrwert für die eigene Gesundheit bietet!

Da in der App u.a. persönliche und sensible Daten verarbeitet werden und die App als medizinische Gesundheitsanwendung angeboten werden soll, müssen bestimmte Sicherheitsstandards eingehalten werden. Diese Anforderungen gibt es inzwischen in einer zweiten überarbeiteten Version vom BSI (Bundesamt für Sicherheit in der Informationstechnik) unter dem Namen „TR-03161 Anforderungen an Anwendungen im Gesundheitswesen“.

Um die persönlichen, sensiblen Daten der Nutzer zu schützen, sichern wir unsere eigenen Apps, aber natürlich auch die unserer Kunden, speziell auf Basis vieler der in den BSI-Anforderungen genannten Maßnahmen ab. Je nach Sensibilität der verarbeiteten und gesicherten Daten, integrieren wir das darauf abgestimmte Sicherheitslevel. Dafür wir haben wir intern 4 Sicherheitsstufen definiert, die abhängig davon, ob und wie persönliche Daten genutzt werden, angewendet und mit unseren Kunden abgestimmt werden.

Unsere wichtigste Erkenntnis: App Security ist keine Rocket Science, wenn man von Anfang an in der Entwicklung die wichtigsten Sicherheitsanforderungen kennt und konsequent umsetzt.

Gerne sichern wir auch deine (medizinische) App bei der Entwicklung gegen Datendiebstahl und -missbrauch ab. Komme gerne per Mail an hello@sevend.de mit deiner App-Idee auf uns zu, wir freuen uns auf deine Nachricht!

In den OWASP (Open Web Application Security Project) Mobile Top 10 (die auch als Basis für die BSI-Richtlinien dienen) werden zum Beispiel die 10 häufigsten Schwachstellen in der Datensicherheit mobiler Anwendungen und passende Lösungswege, um die eigene Anwendung davor zu schützen, beschrieben. Diese haben wir hier einmal kurz für dich zusammengefasst: 

1. Improper Platform Usage (OWASP M1)

• Problem: 
  • Bösartige Eingaben oder unerwartete Ereignisse bringen die App bzw. das Smartphone unter die Kontrolle des Angreifers
    
• Lösungen:
  • Bereinigen von Textfeldern: Filtern von Benutzereingaben in Textfeldern auf dem Smartphone
  • Filtern von API-Aufrufen vom Smartphone

2. Insecure Data Storage (OWASP M2)

• Problem: 
  • Sensible Daten liegen zugänglich im Dateisystem

• Lösung: 
  • Daten in sicheren Bereichen des Smartphones speichern
  • Daten zusätzlich verschlüsseln
  • Schaffen von Resilienz, u.a. durch die Identifikation und Blockierung gejailbreakter/gerooteter Geräte mit regelmäßiger Statusprüfung

Als “Jailbreak” bezeichnet man das Öffnen des geschlossenen Betriebssystems iOS, um nicht nur von Apple freigegebene Anwendungen und Funktionen nutzen zu können. Auf Android-Geräten wird dieses Vorgehen “Rooting” genannt.

„Resilienz“ im IT-Umfeld bezeichnet die Fähigkeit von IT-Systemen, hinsichtlich Störungen und Problemen, wie Ausfällen einzelner Komponenten, robust zu reagieren und die Anwender weiterhin mit den benötigten Services zu bedienen.

3. Insecure Communication (OWASP M3)

• Problem: 
  • Angreifer können den Netzwerkverkehr abhören und manipulieren (sog. “Man-In-The-Middle-Attacke”)

• Lösung: 
  • Verwenden einer HTTPS-Verschlüsselung
  • Kombination mit sicheren TLS-Einstellungen auf dem Server (min. TLS 1.2)
  • Verwenden von Certificate Pinning

4. Insecure Authentication (OWASP M4)

• Problem: 
  • Zu schwache Passwörter, fehlender 2. Faktor, verwundbare Prüfung am API-Endpunkt
• Lösung:
  • Nur starke Passwörter zulassen (z.B. min. 8 Zeichen, min. 1 Großbuchstabe, min. 1 Zahl, min. 1 Sonderzeichen)
  • 2. Faktor voraussetzen (kann z.B. auch “FaceID” o.ä. sein)
  • API: Verwenden von sicheren IDs (z.B. min. 8 nicht fortlaufenden Zeichen)

5. Insufficient Cryptography (OWASP M5)

• Problem:
  • zu schwache oder fehlerhafte Verschlüsselung von Daten, sodass diese relativ einfach (z.B. durch den Einsatz von Malware) in ihre ursprüngliche, unverschlüsselte Form zurückgeführt werden können
• Lösung: 
  • Es sollte, soweit möglich, auf die Speicherung sensibler Daten auf dem mobilen Gerät verzichtet werden
  • Verwenden kryptografischer Standards nach NIST-Richtlinie

Als „Malware“ wird die Software bezeichnet, die (z.B. als Virus o.ä.) in andere Systeme eindringt und dort Schäden oder Störungen verursacht. 

6. Insecure Authorization (OWASP M6)

• Problem:
  • Über mobile Malware auf dem Gerät, Botnetze und selbst entwickelte Tools verschafft sich der Angreifer Zugang zur App und zu administrativen Funktionen
• Lösung: 
  • Rollen und Berechtigungen des Nutzers nur anhand von im Backend gesicherter Informationen überprüfen
  • Unabhängige Prüfung durch den Backend-Code, ob alle mit einer Anfrage verbundenen Identifikatoren mit der Identität übereinstimmen und eindeutig zu dieser gehören

7. Client Code Quality (OWASP M7)

• Problem: 
  • Schlechte Codequalität führt zu Pufferüberläufen und Speicherlecks, die Angreifer nutzen können, um ihren Code im Rahmen des mobilen Codes auszuführen, z.B. auf entfernten Server-Endpunkten
• Lösung:
  • Code sollte einem konsistenten Kodierungsmuster folgen
  • Code sollte gut dokumentiert werden
  • Länge eingehender Puffer sollte die Länge des Zielpuffers nicht überschreiten

8. Code Tampering (OWASP M8)

• Problem:
  • Angreifer stellt eine modifizierte Anwendung über einen Drittanbieter App Store zur Verfügung oder verleitet den Benutzer die Anwendung über einen Phishing-Angriff zu installieren
• Lösung:
  • Code-Integrität: Die eigene Anwendung muss zur Laufzeit erkennen, ob Code hinzugefügt oder geändert wurde
  • Wird eine Verletzung der Code-Integrität erkannt, muss die Anwendung reagieren, z.B. durch Meldung an den Server oder Herunterfahren des Servers
  • Prüfung auf Jailbreak- oder Root-Umgebung (da modifizierte Anwendungen meist in einer solchen ausgeführt wird)

„Phishing“ ist ein digital ausgeführter Betrugsversuch (z.B. über Mails oder Websites). Der Angreifer gibt sich als seriöser Sender aus, um an die sensiblen Daten des Empfängers zu gelangen.

9. Reverse Engineering (OWASP M9)

• Problem:
  • Angreifer lädt die Anwendung aus einem App Store herunter und analysiert diese (Stringtabelle, Quellcode, Algorithmen,…) mit verschiedenen Tools in einer eigenen lokalen Umgebung
• Lösung:
  • Verwenden eines Obfuskationstools zur Verschleierung von Methoden und Codeabschnitten

10. Extraneous Functionality (OWASP M10)

• Problem: 
  • Angreifer untersucht die heruntergeladene Anwendung in seiner lokalen Umgebung, um versteckten Test-Code oder Funktionen für seinen Angriff zu identifizieren
• Lösung:
  • Test-Code aus dem endgültigen Produktions-Build entfernen
  • Verhindern, dass Log-Statements übermäßig viel über das Backend verraten