Banking Fraud

Banking Fraud: Mit App-Sicherheit Bankdaten schützen

Banking Fraud: Mit App-Sicherheit Bankdaten schützen

Vor einigen Wochen meldete IBM Trusteer eine massive Betrugsaktion gegen Banken, die zu Verlusten in Höhe von mehreren Millionen Dollar führte. Den Angreifern ist es zum einen gelungen, die Anmeldedaten von zahlreichen Endbenutzern zu stehlen. Zum anderen haben sie es geschafft, das Fraud-Management-Konzept der Banken zu umgehen, um Millionen an kleinen Transaktionen zu automatisieren, die unentdeckt alle Risikoanalyse- und Sicherheitsinfrastrukturen passieren können und potenziell auch vom User nicht bemerkt werden.

Der erste Schritt wurde offenbar mithilfe einer Art Social-Engineering-Angriff durchgeführt, bei dem Malware auf dem Gerät des Benutzers installiert wurde. Im zweiten Schritt hingegen verwendeten die Angreifer Emulatoren, um das Betrugsmanagementsystem der verschiedenen Banken „auszutricksen“. Hieraus ist zu schließen, dass das Fraud-Management-System in diesem Fall seine Aufgabe nicht richtig erfüllt hat. Denn diese besteht genau darin, vor solchen Situationen zu schützen, in denen die Benutzer getäuscht wurden.

Identifizieren der Schwachstelle

Ein Anti-Fraud-System sollte eigentlich Situationen erkennen, in denen ein Benutzerkonto auf einem anderen Gerät als dem des rechtmäßigen Benutzers verwendet wurde. So ist es ein typisches Szenario für das Fraud Management, wenn das System bemerkt, dass der Benutzer ein iPhone verwendet, während er sich normalerweise von einem Samsung-Gerät aus verbindet. Damit es den Hackern gelingt, die Anti-Fraud-Lösung zu überlisten, haben sie Emulatoren verwendet. Damit sieht es so aus, als würde das Gerät des Users genutzt, obwohl dies in Wirklichkeit nicht der Fall war.

Da die Forscher nicht genügend Details genannt haben, lässt sich die Funktionsweise nicht eindeutig bestimmen. Es ist aber anzunehmen, dass die Angreifer

  • es irgendwie geschafft haben, Malware in das Gerät des Benutzers einzuschleusen (beispielsweise über einen Phishing-Betrug).
  • diese Malware verwendet haben, um Anmeldedaten und Geräteinformationen zu stehlen und Zugriff auf SMS zu erhalten.
  • mit den erbeuteten Informationen ein automatisches Schema eingerichtet haben, das
    a) das Einrichten eines Emulators erlaubte, der (in den Augen des Anti-Fraud-Systems) genau wie das Gerät eines Benutzers aussieht.
    b) sich mit den gestohlenen Anmeldedaten bei der Banking-App angemeldet hat. Da das Gerät wie das des Users aussah, reagierte das Anti-Fraud-System nicht.
    c) das Ausführen einer kleinen Transaktion ermöglichte, die im System der Bank keinen Verdacht erregt (und wahrscheinlich vom Benutzer unbemerkt bleibt).
    d) in der Lage war, diese Schritte innerhalb weniger Tage millionenfach zu wiederholen und so effektiv Millionen von Dollar zu stehlen.

Es gibt mehrere Dinge, die in diesem Szenario hätten anders gemacht werden können. Wir wollen uns in erster Linie darauf konzentrieren, wie es den Angreifern gelungen ist, das Gerät zu „fälschen“; oder anders ausgedrückt, wie stark der Mechanismus zur Geräteidentifikation war. Um diese Frage zu beantworten, ist es sinnvoll, sich in die Lage des Angreifers zu versetzen.

Der relevante Schritt bei der „Fälschung“ des End User Device ist das Sammeln der richtigen Geräteinformationen, die später verwendet werden sollen. Denn das Wichtigste, was der Angreifer wissen muss, ist, welche Informationen das Fraud-Management-System verwendet, um ein Gerät zu identifizieren. Am Ende sind das die Informationen, die die Hacker – mit Hilfe der Malware – aus dem Endgerät extrahieren müssen, um es fälschen zu können.

Höchstwahrscheinlich verwendet das Fraud-Management-System viele verschiedene Werte zur Geräteidentifikation: Einige davon sind offensichtlich, andere eher weniger. Unter den offensichtlichen Werten finden sich Dinge wie der Gerätehersteller, das Gerätemodell, die Betriebssystemversion, die Android-ID (für Android-Geräte) oder die IDFV (für iOS-Geräte). Diese sind jedoch nicht so relevant, da jedes Geräteidentifikationssystem sie verwenden würde.

Die eigentliche Stärke des Device Identification-Systems liegt in den nicht so offensichtlichen Gerätekennungen, insbesondere darin, wie viele von ihnen verwendet werden und wie gut sie geschützt sind. Hier ist es nicht so wichtig, welcher Parameter verwendet wird, sondern wie schwierig es für einen Angreifer ist zu wissen, dass er verwendet wird. Am Ende besteht das Ziel des Angreifers darin, ein Stück Malware zu schreiben, das die Parameter sammelt – und genau das gilt es zu verhindern.

Die Schwäche ausnutzen

Die Frage ist also: Woher könnte ein Angreifer wissen, welche Gerätekennungen verwendet werden?

  • Der einfachste Ansatz wäre wahrscheinlich, die von der App an das Backend übertragenen Informationen mithilfe einer MITM-Attacke auszuspionieren. Durch die Analyse des Datenverkehrs würde der Angreifer ein gutes Verständnis dafür bekommen, welche Identifikatoren verwendet werden.
  • Eine andere Möglichkeit wäre, den Quellcode der Anwendung zu lesen, um die Routinen zu finden, die diese Informationen sammeln und an die Backend-Systeme senden. Da der Quellcode dem Angreifer vermutlich nicht vorliegt, wird die Alternative die dekompilierte Binärdatei sein. Sie ist zwar nicht so nützlich wie der Quellcode, aber durch eine statische Analyse lassen sich daraus eine ganze Reihe von Informationen extrahieren.
  • Die letzte und schwierigste Option, die dem Hacker zur Verfügung steht, wäre die dynamische Analyse. Beispiele dafür sind das Debuggen der Anwendung während der Ausführung und die Verwendung eines Hooking-Frameworks wie Frida.

All diese Optionen müssen aber nicht erfüllt sein: Der Angreifer muss nur bei einer von ihnen erfolgreich sein, um den gesamten Angriff erfolgreich durchzuführen. Lösungen, die nur eines der Szenarien verhindern, machen dem Angreifer das Leben schwer, verhindern aber nicht, dass er Erfolg hat.

Apps richtig schützen

Bedenkt man all das, lässt sich sagen, dass ein starkes Konzept zur Geräteidentifizierung Folgendes leisten sollte:

  1. Viele, nicht offensichtliche Gerätekennungen verwenden. Je mehr Device Identifier, desto besser.
  2. Schutz vor MITM-Angriffen. Das Abhören des Netzwerkverkehrs liefert eine Menge Informationen. Daher ist ein guter Schutz an dieser Stelle ein Muss.
  3. Verschleiern der sensiblen Teile der Binärdatei. Bei mobilen Anwendungen haben Angreifer immer Zugriff auf das Binärprogramm. Daher ist eine angemessene Verschleierung zur Verhinderung statischer Analysen entscheidend.
  4. Vorbeugung gegen dynamische Analyse. Wenn die statische Analyse nicht ausreicht, werden Angreifer auf die dynamische Analyse zurückgreifen: Debugging, Instrumentierung, Modifizierung der App usw. Das bedeutet, dass unter anderem der Schutz vor Debuggern, Hooking-Frameworks und Code-Injektion ebenfalls wichtig ist.

Unter einem breiteren Blickwinkel betrachtet, lässt sich schlussfolgern, dass eine angemessene Endpoint Protection ein Muss für Lösungen zur Fraud-Prävention ist, die auf der Identifizierung von End User Devices basieren. Andernfalls wird es Angreifern gelingen, „gefakte“ Daten einzuspeisen, die die im Backend implementierten Schutzmechanismen umgehen.


Sicherheit für den Digital Car Key

Digital Car Key: Sicher mit dem Smartphone das Auto öffnen

Digital Car Key: Sicher mit dem Smartphone das Auto öffnen

Die Welt wird immer digitaler. Aus unserem täglichen Leben nicht mehr wegzudenken: Smartphones und Tablets. Wie selbstverständlich greifen wir nahezu ständig zu unseren mobilen Begleitern, um etwas zu googeln, kontaktlos zu bezahlen oder das Licht im Wohnzimmer einzuschalten. Die Flut an Apps, die jeden Tag im App- oder Google Play-Store hinzukommt, ist schier unendlich. In den weiten Welten der Stores sind unter anderem auch mobile Applikationen zu finden, mit denen sich Fahrzeuge per Handy auf- und zuschließen lassen. Solche Digital Key Apps sind nicht nur bei vielen Autofahrern, sondern vor allem auch bei Hackern äußerst beliebt. Folglich gilt es, schon zu Beginn der App-Entwicklung entsprechende Maßnahmen zu ergreifen, die den praktikablen digitalen Autoschlüssel vor dem Zugriff Dritter absichern.

Aufgrund der Corona-Pandemie wird seitens der Geschäfte vermehrt zur kontaktlosen Zahlung aufgerufen. Im Zuge dessen sind viele bereits auf das Mobile Payment umgestiegen und zücken an der Kasse ihr Handy oder ihre Smartwatch, um die Rechnung zu begleichen. Was wir aus dem Finanzbereich kennen, ist mittlerweile auch in den Automobilsektor eingezogen: Der digitale Autoschlüssel erfreut sich zunehmender Beliebtheit. Über die passende installierte App lassen sich zukunftsfähige Autos ganz einfach per Smartphone öffnen und wieder schließen. Dies bietet einen angenehmen Komfort.

Einige Automobilbesitzer haben jedoch kein Vertrauen in solch moderne Technologien, da in den Medien häufig von Fahrzeugen die Rede ist, die per Fernzugriff gehackt wurden. Um derartige Bedenken aus dem Weg zu räumen, ist es essenziell, dass die Hersteller ihre Digital Key Apps ausreichend schützen. Nur so ist es möglich, Kunden Sicherheit bei der Nutzung der Technologie zu garantieren. Maximaler und nachhaltiger Schutz sollte bereits im Rahmen der Planung und frühen Umsetzungsphase eine zentrale Rolle spielen. Dabei haben viele Verantwortliche nicht auf dem Radar, dass es mehrschichtige Security-Frameworks gibt, die die Arbeit deutlich erleichtern.

Framework integrieren – Hacker aussperren

Ein Software Development Kit (SDK) wie unser Trusted Applikation Kit (T.A.K) hält eine Sammlung an Sicherheitsfunktionen bereit, die jede App braucht. Entwickler einer Mobile Car Key App können das SDK ohne großen Aufwand und in kürzester Zeit integrieren. Auf diese Weise wird dafür gesorgt, dass die geheimen Schlüssel in der mobilen App mithilfe kryptographischer Technik für keine unbefugten Personen zugänglich sind. Aufgrund der sicheren Speicherung der Schlüssel im Smartphone ergibt sich zusätzlich der Vorteil, dass kein Netzsignal für den Zugang zum Auto erforderlich ist. Selbst wenn es in einer Tiefgarage geparkt wurde und es keinen ausreichenden Empfang gibt, lässt sich das Fahrzeug problemlos öffnen. Außerdem erlaubt die Integration unseres T.A.K den Zugriff mehrerer Personen auf den digitalen Schlüssel, ohne dabei die Security zu beeinträchtigen.

Damit Hacker keine Chance haben, auf den Mobile Car Key zuzugreifen, wird das SDK Entwicklern und Providern als Bibliothek mit Code-Verschleierung zur Verfügung gestellt, was die Entschlüsselung erheblich erschwert. Zudem verwendet der App-Schutz einen sicheren Kommunikationskanal zwischen Client und Cloud und stellt jeder App, auch dem digitalen Autoschlüssel, einen eigenen sicheren Kommunikationskanal zur Verfügung. Der sichere Kommunikationskanal zum Server verhindert die Datenverkehrsanalyse (Network Sniffing). Das T.A.K sollte daher schon zu Beginn der Entwicklung in die App integriert werden, damit es später bei der Ausführung direkt auf Gefahren reagieren kann. Durch das integrierte Trusted Applikation Kit lässt sich zum Beispiel erkennen, ob der Mobile Car Key auf einem Originalgerät oder einem gerooteten Gerät ausgeführt wird. Darüber hinaus kann man den digitalen Autoschlüssel über die T.A.K-Cloud für inaktiv erklären.

Vorteile für die Nutzer

  • Sie können den Digital Car Key bedenkenlos verwenden und vom Komfort im Alltag profitieren, ohne sich Gedanken über die Sicherheitsrisiken machen zu müssen.

Vorteile für die Automobilindustrie

  • Durch das T.A.K wird die Sicherheit vieler Betriebssystemversionen erhöht und damit eine hohe Marktabdeckung/viele Kunden erreicht.
  • Sie stärken das Vertrauen in die Marke und die Technologie.
  • Man kann dem Wunsch vieler Autobesitzer nach Sicherheit bei der Nutzung solch zukunftsträchtiger Technologien nachkommen.
  • Das Hab und Gut der Autobesitzer wird geschützt.
  • Es fallen geringere Kosten an, um die Technologie rundum sicher zu entwickeln.
  • Die App kann schneller gelauncht werden, da das Kit alle wesentlichen Sicherheitsaspekte integriert, die für die In-App-Protection notwendig sind.
  • Reputationsschäden lassen sich vermeiden.

Wie das Ganze in der Praxis funktioniert, erfahren Sie in unserer Case Study mit der Chongqing Changan Automobile Company.


Security of eHealth apps

3, 2, 1 – Starten wir mit Mobile Health Security

3, 2, 1 – Starten wir mit Mobile Health Security

Ein Einstieg in die Sicherheit von Gesundheits-Apps

Nutzen Sie schon eHealth-Apps? Vielleicht haben Sie ja schon einmal Ihre Fitness über das Handy verfolgt oder Ihre Ernährung dokumentiert. Inzwischen gibt es sogar bestimmte geprüfte medizinische Apps, die von Ärzten verschrieben und von Krankenkassen übernommen werden. Bei Krankheiten wie zum Beispiel Diabetes, Tinnitus oder Adipositas informieren sie, bieten Maßnahmen zur Prävention und unterstützen bei Training und Ernährung. Manche Apps messen, speichern und werten medizinische Daten auch aus. Damit sind sie für viele Menschen eine große Hilfe: Sie motivieren, etwas für sich persönlich zu verändern, die Gesundheit im Blick zu behalten oder sogar zu verbessern. Aber wie sieht es bei all den positiven Effekten mit dem Datenschutz in solchen Apps aus? In diesem Blogbeitrag geben wir einen ersten Einblick in das Thema digitale Gesundheit, welche Arten von Apps es gibt und wie es um deren Sicherheit bestellt ist.

Haben Sie schon einmal von Diabetes-Apps gehört? Sie können Betroffenen helfen, den Alltag mit Diabetes leichter zu managen, und bündeln alle wichtigen Therapie-Informationen an einem Ort. So können die App-Nutzer ihre Werte bequem automatisch via Bluetooth in die App übertragen und sie dann mit einem Klick analysieren lassen. Zudem ist solch eine App in der Lage, den Blutzuckerverlauf anzuzeigen oder motivierende Challenges anzubieten. Aus den dabei gewonnenen Daten lassen sich übersichtliche PDF-, Excel- oder CSV-Reports erstellen, die zum Beispiel für den nächsten Arztbesuch verwendet werden können.

Diabetes-Apps sind aber nur ein Beispiel im Bereich eHealth. Es existieren noch viele weitere Apps, bei denen unsere Gesundheit im Fokus steht.

Was ist eHealth?

eHealth ist eine Unterkategorie von Digital Health (Digitale Gesundheit). Sie wurde von der Weltgesundheitsorganisation (WHO) als Oberbegriff für die Nutzung von Informations- und Kommunikationstechnologien für die Gesundheit definiert. Es handelt sich dabei um die Integration von IT-Technologien oder Anwendungen zum Zweck der Gesundheit. Hinsichtlich der digitalen Anwendungen stolpert man schnell auch über den Begriff mHealth (Mobile Health). Mit mHealth wird eine Untergruppe von eHealth-Aktivitäten und -Systemen auf mobilen Endgeräten bezeichnet. eHealth-Apps gibt es inzwischen en masse. Spätestens die Corona-Pandemie dürfte den aufsteigenden Trend weiter fortgesetzt haben.

Viele haben Gesundheits-Apps sicherlich im Alltag schon einmal ausprobiert – von der einfachen Body-Mass-Index-(BMI)-Berechnungs-App bis hin zum persönlichen Gesundheitsassistenten. Einen Großteil dieser Apps macht der Wellness-Bereich aus, also Apps für „Gesundheitsorientierte“; für Menschen, die sich Gedanken um ihre Gesundheit machen und „einfach nur“ gesund leben wollen. Dazu zählen Fitness-Apps, Lifestyle-Apps sowie Apps mit Ernährungsinformationen.

Dann gibt es noch Apps, die im konkreten Krankheitsfall genutzt werden, und solche, die ein Leben mit einer Krankheit erleichtern sollen. In diesen beiden Bereichen dreht es sich dann um die Begleitung bzw. Unterstützung bei einer Erkrankung.

Darüber hinaus wurden weitere Kategorien definiert: CE-kennzeichnungspflichtige Apps und auch die im Jahr 2020 in Deutschland eingeführten digitalen Gesundheitsanwendungen, die DiGA-Apps. Beide gehen einen wichtigen Schritt in Richtung Qualitätssicherung, denn sie werden regulatorisch kontrolliert.

Nicht zu vergessen sind auch Apps, die im Kommunikationsprozess des Gesundheitssystems zunehmend eine wichtige Rolle einnehmen. Dazu zählen zum einen Apps für das Management und die Kommunikation zwischen Krankenkasse und Kunde und zum anderen Apps, die die Effizienz im Gesundheitssystem steigern. Zu Letzteren zählen beispielsweise das eRezept und die elektronische Patientenakte (ePA). Wie für die schon genannten DiGA-Apps wurden auch hierfür mittlerweile die rechtlichen Grundlagen geschaffen.

Sicherheit, wo bist du?

Einheitliche Qualitätskriterien für eHealth-Apps gibt es noch nicht. Dabei sollten vor allem Datenschutz und Sicherheit bei der App-Entwicklung mehr in den Fokus rücken. Schließlich fordert der Patient die Sicherheit seiner Daten, und auch der Gesetzgeber möchte, dass sensitive Daten geschützt werden. Das gilt aber nicht nur für eHealth-Apps. Jede App verarbeitet personenbezogene Daten und kann sich langfristig nur erfolgreich etablieren, wenn das Vertrauen in sie gestärkt wird.

Die allgemeine Sicherheit ist also eine der wichtigsten Anforderungen von Nutzern an eine App. In Meinungsumfragen sagen Nutzer, dass ihnen Sicherheit und Datenschutz bei eHealth-Apps am wichtigsten sind. Dann folgen die Glaubwürdigkeit der App und des Herstellers, die regelmäßige Pflege der App, Integration und Datensammlung und zu guter Letzt auch, wem die Daten gehören. Was das konkret für die Sicherheit von Gesundheits-Apps bedeutet, erfahren Sie in unserem nächsten Blogbeitrag zu dieser Thematik.


In-App Protection integrated fastly and easily

In-App Protection schnell und einfach integriert

In-App Protection schnell und einfach integriert

App-Sicherheit in drei Minuten

Dinge, die man in unter zehn Minuten erledigen kann: einen Kaffee holen, diesen Blogtext lesen, sichere Apps entwickeln … Aber Moment – kostet es nicht eigentlich mehrere Monate Zeit und jede Menge Geld, eine App wirklich sicher zu machen? Wir räumen mit diesem Trugschluss auf und zeigen, wie In-App Protection in unter drei Minuten in die Anwendungsentwicklung einbezogen werden kann.

App-Sicherheit wird in der Entwicklungsphase nach wie vor häufig erst einmal vernachlässigt. Meist fehlt den Entwicklern die Zeit und die Expertise, um den Security-Layer umfassend zu entwickeln und zu integrieren. Denn nach wie vor stehen für viele Unternehmen zunächst das Design und der schnellstmögliche Launch-Termin im Fokus.

An diesem Punkt steht eine „kostengünstige“ und schnelle Markteinführung noch immer im Widerspruch zu einer umfassenden In-App Protection, die gleich von Beginn an in die Entwicklung einbezogen wird. Bislang war dies in gewisser Weise auch verständlich, denn es würde einen Entwicklungsaufwand von ungefähr 400 Monaten bedeuten (wobei hier auch die Serverseite berücksichtigt ist), eine App mit allen Finessen und bis ins kleinste Detail rundum sicher zu entwickeln. Geht man nun davon aus, dass ein Entwicklermonat ungefähr 10.000 Euro kostet, lässt sich leicht ausrechnen, welche Kosten hier auf ein Unternehmen zukommen können.

400 Monate vs. 3 Minuten – geht nicht? Und ob!

Dass es möglich ist, eine App in nur drei Minuten sicher zu machen, haben wir beispielhaft in einem Integrationsvideo unseres Software Development Kit T.A.K dokumentiert:

  • Schritt 1:

T.A.K zu einem Android Studio-Projekt hinzufügen.

  • Schritt 2:

T.A.K als Abhängigkeit zum App-Modul hinzufügen.

  • Schritt 3:

T.A.K initialisieren und im T.A.K-Service registrieren.

  • Schritt 4:

Gerätespezifische Daten wie T.A.K.-ID oder Client-Zertifikat abrufen.

  • Schritt 5:

Secure Storage verwenden, wodurch eine hochsichere Speicherung vertraulicher, sensibler oder persönlicher Daten gewährleistet wird.

  • Schritt 6:

File Protector nutzen, um Ressourcen und Assets bereits während der Entwicklung zu schützen. Die Informationen müssen nur bei Bedarf entschlüsselt werden.

  • Schritt 7:

Durch die Bewertung der Laufzeitumgebung wird gewährleistet, dass die App auf einem sicheren Gerät ausgeführt wird.

  • Schritt 8:

Den sicheren Kanal verwenden, um das Abfangen von Daten sowie Datenlecks zu verhindern und einen hochsicheren Zugriff auf den Server zu bieten.

  • Schritt 9:

T.A.K freigeben.

Diese enorme Zeitersparnis ermöglicht es einem Entwickler, sich um das zu kümmern, worum er sich eigentlich kümmern soll: eine App nach den Anforderungen des Kunden zu entwickeln – hinsichtlich Funktionalität und Design – und dennoch nicht die Sicherheit zu vernachlässigen. Gleichzeitig bietet ihm dies natürlich auch den Spielraum, mehrere Apps in kurzer Zeit zu entwickeln.

Denn worüber sich Unternehmen stets im Klaren sein sollten: Ihre Apps werden durch Enduser genutzt, ohne dass sie als App-Betreiber noch die Kontrolle darüber haben. Daher ist es unerlässlich, Anwendungen bereits ab der Entwicklung vor unbefugten Modifikationen, Datenschutzverletzungen und Malware abzusichern. Wird eine App erst einmal kompromittiert, gelangen Cyberkriminelle an private Daten oder letztlich über dieses Einfallstor in das Unternehmensnetzwerk. Dies kann mit Datenverlust, finanziellen Schäden und Reputationsschäden bereits kurzfristig negative Folgen für den App-Betreiber haben, die sich auch langfristig auf den Unternehmenserfolg auswirken können.


Shift Left Security

Shift Left Security – ein Trend, der anhalten wird

Shift Left Security – ein Trend, der anhalten wird

Sicherheitsbemühungen konzentrieren Organisationen häufig auf das Ende eines Entwicklungs- und Release-Zyklus („Shift Right“). Dadurch kann zwar sichergestellt werden, dass der Rest der Software ein gewisses Maß an Stabilität erreicht, doch bleiben dabei hohe Risiken und auch Schwachstellen bestehen.

Die Lösung für dieses Problem und der wichtigste Eckpfeiler einer sicheren App ist Shift Left Security. Sicherheit sollte so früh wie möglich in den Software-Entwicklungszyklus implementiert werden (daher Shift Left = „nach links verlagern“ genannt). Dies vermeidet ungeplante Kosten und erspart unnötigen Ärger nach Veröffentlichung der App.

Shift Right: App-Sicherheit am Ende der Entwicklung ist keine Option mehr

Die Entwicklung einer mobilen App (oder Lösung) durchläuft immer dieselben Schritte: von der Konzeption über die Entwicklung und verschiedenen Tests bis hin zum Hochladen in den App Store. An Sicherheit wird dabei oftmals erst sehr spät gedacht. Bei der nachträglichen Implementierung fallen dann zusätzliche Entwicklungszeit und -kosten an. Um eine pünktliche Markteinführung zu garantieren, wird die Sicherheit in manchen Fällen einfach komplett außen vor gelassen.

Es gibt viele Beispiele, in denen der Sicherheitsfaktor erst in der letzten Projektphase eingeführt wurde. Dies kann enorme negative Auswirkungen auf ein Projekt haben, denn unmittelbar mit der Veröffentlichung der App werden auch die Risiken und Schwachstellen veröffentlicht. Diese bleiben nicht immer unerkannt, sondern werden von Sicherheitsforschern oder Hackern gefunden. Im besten Fall geben diese ihr Feedback an die Entwickler weiter – im schlimmsten Fall wird das Wissen missbraucht. Im letzteren Fall können Compliance-Verletzungen und Reputationsschäden sofort und ohne Vorwarnung eintreten.

Shift Left Security bietet Vorteile für die Wirtschaftlichkeit

Der Trend zu Shift Left Security wird wirtschaftlich gesehen durch die Betrachtung der Software-Entwicklungsprozesse und der anschließenden Wartungsphase gestärkt. Wie eine Studie belegt, ist die Problembehebung nach der Freigabe der mobilen App in etwa 20-mal teurer, als wenn das Problem bereits in der Definitionsphase des Projekts erkannt und gelöst wird.[1]

Oftmals unberücksichtigt, vergessen oder ausgeschlossen von diesen Kostenbetrachtungen sind die finanziellen Auswirkungen einer Sicherheitsverletzung: Folgeschäden, Kosten für Cyberangriffe (und Wiederherstellungskosten) sowie Prozesskosten. Betrachtet man auch diese Kosten, so zeigt eine weitere Studie, dass nicht durchdachte Software bis zu 2000-mal teurer sein kann, als von Anfang an in hochwertige Software zu investieren.[2] In diesem Beispiel tragen die Kosten von Cyberangriffen zu etwa 45 % aufgrund von Nachlässigkeiten im Software-Entwicklungsprozess zu den Gesamtkosten bei.
In der Summe bedeutet dies, dass sich Unternehmen und App-Entwickler auf gute Software und auf die Entwicklung guter Lösungen konzentrieren müssen, anstatt hinterher Betrug aufzudecken und Geld für Abhilfemaßnahmen auszugeben. Shift Left Security bedeutet: Je früher man Sicherheit einbezieht, desto weniger Kosten hat man hinterher.

In puncto Sicherheit auf Best Practices fokussieren

Shift Left Security ist eine Best Practice. In einem Softwareentwicklungs-Lebenszyklus (SDLC) sollte bereits in einem sehr frühen Stadium über Architektur und ein sicheres Design nachgedacht werden. Letzteres sollte eine Bedrohungsmodellierung beinhalten, die die Basis für das Sicherheitskonzept und die später implementierten, sogenannten Security Controls darstellt.

„Sicherheit kann nur erreicht werden, wenn sie von Anfang an eingeplant ist. Die Einführung von nachträglichen Sicherheitsmaßnahmen ist eher der Anfang einer Katastrophe“, sagt die CSA (Cloud Security Alliance) über sicheres Softwaredesign.[3]

Auch der CEO von Build38, Christian Schläger, sagte kürzlich in einem Interview mit PwC: „Anstatt also hinterher aufzuräumen und SOC-Ressourcen und viele Analystenstunden für die Forensik aufzuwenden, würde ich mir mehr hochwertige Software und Lösungen wünschen, die nicht mehr so leicht gehackt werden können.“

Kurz gesagt: Nachdem eine App veröffentlicht wurde, ist es einfach zu spät herauszufinden, was an der App das Sicherheitsproblem verursacht hat. Es wird unnötig Geld für die Reparatur, das erneute Testen und die erneute Veröffentlichung der Anwendung ausgegeben.

Shift Left Security – von Anfang an richtig machen

Das neue Paradigma und der beste Investitionsschutz ist Shift Left Security. Diese Vorgehensweise hilft dabei, während des gesamten Lebenszyklus einer mobilen Anwendung mit dem geplanten Budget zu haushalten. Außerdem unterstützt die Methode dabei, früh darüber nachzudenken, wie, wo und wann Sicherheit in einem App-Projekt eingebettet werden sollte.

Darüber hinaus ist Shift Left Security der entscheidende Schritt zur Einhaltung von Richtlinien: der eIDAS-Verordnung, der bevorstehenden Medical Device Regulation (MDR) im Jahr 2021, der DiGA-Verordnung, der PSD2 usw. Es geht also darum, Sicherheitsanforderungen gleich von Beginn an in die Tat umzusetzen.

Build38 gibt App-Entwicklern alle Mittel an die Hand, um jetzt mit Shift Left Security zu beginnen: „Wir liefern ein umfassendes Sicherheits-SDK für Android und iOS und eine Lösung, die sich sehr schnell integrieren lässt. Darüber hinaus unterstützen wir bei der Identifizierung der sicherheitsrelevanten Themen, geben Ratschläge, wie Sicherheitskontrollen richtig gestaltet werden können und was weiterhin zu beachten ist“, sagt Christian Schläger.

Klingt interessant? Dann kontaktieren Sie Build38 und werden Sie Teil der „Shift Left Security"-Bewegung!

 

[1] Capers Jones, A short history of the cost per defect metric, 2013

[2] Capers Jones, Achieving Software Excellence, v7, 2016

[3] „The Six Pillars of DevSecOps: Automation”, 2020


mobile payment App security

Kontaktloses Bezahlen, Part 2: Gut für das Geschäft, aber nur mit der richtigen Sicherheit!

Im ersten Teil dieser Blogreihe haben wir bereits darüber informiert, dass ein starker Trend zur bargeldlosen und insbesondere zur kontaktlosen Zahlung erkennbar ist. Dabei gewinnt auch das Bezahlen per Smartphone zunehmend an Bedeutung. Hier spielen die von der PCI zur Verfügung gestellten Standards SPoC und CPoC eine wichtige Rolle.

PCI SPoC und CPoC – worum geht es hier?

SPoC (Software-based PIN Entry on COTS) ist – einfach ausgedrückt – der softwarebasierte PIN-Eingabe-Standard von PCI für mobile Geräte, in Kombination mit einem Secure Card Reader für PIN (SCRP). Der SCRP ist nichts anderes als ein zusätzliches Stück Hardware, das mit dem mobilen Gerät zum Beispiel über Bluetooth verbunden ist.

CPoC (Contactless Payments on COTS) ist der zweite und neuere Standard, der ausschließlich kontaktlose Zahlungen behandelt. Die NFC-Fähigkeit mobiler Geräte verwandelt diese in ein Lesegerät für kontaktlose Zahlungen.

Beiden Standards gemeinsam sind die mobile Kartenlese-App, die Beglaubigungs- und Kontrolldienste. All dies nur, um ein hohes Maß an Sicherheit und Vertrauen aufrechtzuerhalten. Darüber hinaus sind auch typische zahlungsbezogene Dienste Bestandteil des PCI-Standards.

Welche Rolle spielt dabei Build38?

Build38 erfüllt die strengsten Sicherheitsanforderungen der PCI:

  • Gewährleistung, dass die Anwendung in einer sicheren Umgebung (und nur dort) ausgeführt wird
  • Verschleierung
  • Anti-Repackaging-Technologie
  • Sichere PIN-Eingabe
  • Verhinderung erkannter Bedrohungen, die bereits auf dem mobilen Gerät vorhanden sind, usw.

Darüber hinaus bietet Build38 die erforderliche Beglaubigungskomponente, die den aktuellen Sicherheitsstatus der Anwendung bestimmt und verifiziert. Sie liefert zusätzliche Sicherheitssignale an das Kontrollsystem, das vermutete oder tatsächliche Bedrohungen und Angriffe erkennt, alarmiert und entschärft.

Die PCI-Sicherheitsanforderungen können mit all ihrer Komplexität recht unübersichtlich sein, Sie sollten jedoch nicht davor zurückschrecken!

 

Sie verstehen das Bezahlwesen am besten – und Build38 liefert die mobile Sicherheit!

Wir bei Build38 glauben, dass in einer sich wandelnden digitalen Landschaft die Sicherheit von Apps kein Luxus ist. Sie ist eine Notwendigkeit. Ihre Entwickler sollten sich darauf konzentrieren können, was sie am besten können: Geschäftswert und erstklassige Zahlungsanwendungen zu liefern, während Build38 die Sicherheit mobiler Anwendungen bietet. Das Trusted Application Kit (T.A.K.) von Build38 ist ein hochsicheres, ganzheitliches und einfach zu integrierendes Rahmenwerk für die Sicherheit mobiler Anwendungen.

Alles beginnt mit einem besseren Verständnis Ihrer mobilen Risiken.

Erfahren Sie, wo Sie heute stehen!
Stärken Sie Ihre Richtlinien und Ihre Compliance-Position!
Erkunden Sie Ihre Optionen und finden Sie die richtige Lösung!

 

Kontaktieren Sie uns und bringen Sie Ihre eigene CPoC- oder SPoC-Lösung schneller auf den Markt!


mobile payment App security

Kontaktloses Bezahlen, Part 1: Smartphone und App ersetzen das Kartenlesegerät

Bargeldloser Zahlungsverkehr ist beliebter denn je. Dieser Trend wurde insbesondere auch durch Covid-19 beschleunigt. So wurde in Deutschland in der ersten Hälfte des Jahres 2020 ein Plus von 20 % verzeichnet. Dabei erfolgte jede zweite Zahlung sogar kontaktlos.[1] Trotz allem gibt es in Deutschland noch Nachholbedarf im Vergleich zu anderen Ländern, die schon jetzt eine höhere Rate bargeldloser Zahlungen aufweisen.

Neben der „klassischen“ Variante der bargeldlosen Zahlung via Bankkarte wird auch das kontaktlose Bezahlen per Smartphone europaweit immer beliebter. Wie eine aktuelle Umfrage zeigt, bevorzugen bereits rund 12 % der befragten Europäer das Bezahlen per Smartphone.[2]

Kontaktlose Zahlungen werden weiter an Dynamik gewinnen

Beim kontaktlosen Bezahlen wird die Karte an der Kasse nur noch gegen das Kartenlesegerät gehalten und muss nicht mehr in das Gerät gesteckt werden. Bei kleinen Beträgen ist auch die Eingabe der PIN nicht erforderlich. Angesichts der Pandemie haben Einzelhändler ihre Kunden ermutigt, auf diese Weise zu bezahlen, um einen Kontakt und eine mögliche Ansteckung zu vermeiden.

Beim kontaktlosen Bezahlen per Smartphone ersetzt die App auf dem Smartphone die Bankkarte. Aus Sicht von Build38 werden für ein weiteres starkes Wachstum zwei Anforderungen eine wichtige Rolle spielen:

  • Einzelhändler, Kleinhändler, Markt- und Straßenverkäufer müssen in die Lage versetzt werden, mobile Zahlungen zu akzeptieren, ohne in traditionelle Kartenlesegeräte investieren zu müssen.
  • Wie von den Kunden gefordert, müssen mobile Zahlungen für kleine Summen akzeptiert werden.

An diesem Punkt stellt sich natürlich die Frage, wie gerade die erste Anforderung auf erschwingliche und einfache Weise umgesetzt werden kann.

PCI-Standards ebnen den Weg

Der PCI Security Standards Council (PCI SSC) wurde 2006 unter anderem von American Express, Visa und MasterCard gegründet. Es handelt sich um ein globales Forum, das die Interessenvertreter der Zahlungsverkehrsbranche zusammenbringt, um die Annahme von Datensicherheitsstandards und Ressourcen für sichere Zahlungen weltweit zu entwickeln und voranzutreiben. Sie sind das Leitungsgremium für die Standardisierung des Zahlungsverkehrs, die technischen Anforderungen und die Zertifizierung von Zahlungslösungen.

Die PCI hat bereits erkannt, dass kontaktlose Zahlungen für jedermann verfügbar sein müssen. Für den, der bezahlen möchte, als auch den Empfänger der Zahlung. Das traditionelle Kartenlesegerät wird in diesem Fall mit Hilfe von Smartphones oder Tablets realisiert, die die PCI in ihrem eigenen Sprachgebrauch als COTS-Geräte (commercial off-the-shelf) bezeichnet. Die PCI stellt daher zwei Standards zur Verfügung: den SPoC (Software-based PIN Entry on COTS)- und den CPoC (Contactless Payments on COTS)-Standard.

 

Erfahren Sie in unserem nächsten Blogbeitrag mehr über diese Standards und darüber, wie die Sicherheit von Zahlungs-Apps durch Build38 gewährleistet werden kann.

 

[1] https://www.handelsblatt.com/finanzen/banken-versicherungen/coronakrise-kreditwirtschaft-trend-zu-bargeldlosem-bezahlen-haelt-schon-laenger-an/26289960.html?ticket=ST-350571-XZqIrSQGq5lLGZqhcQfl-ap4

[2] https://www.handelsblatt.com/finanzen/banken-versicherungen/umfrage-in-zwoelf-eu-staaten-die-coronakrise-verstaerkt-den-trend-zum-bargeldlosen-zahlen/26185710.html


Warum Mobile Security mehr als die Sicherheitsmaßnahmen der App-Stores umfasst

Wir leben in einer Welt, die immer digitaler wird. Täglich greifen wir zu unseren Smartphones und benutzen Apps; beispielsweise um Notizen zu machen, die Wettervorhersage anzuschauen oder sich mit einem Spiel die Zeit zu vertreiben. Aber nicht nur das: Inzwischen werden mit Apps immer häufiger richtig sensitive Daten verarbeitet. Man denke nur einmal an das bei vielen beliebte Mobile Payment, den in naher Zukunft kommenden digitalen Führerschein oder die elektronische Patientenakte (ePA), die Mitte nächsten Jahres eingeführt wird. Wer möchte schon, dass derartige sensible Daten in die Hände von Dritten gelangen? Wohl niemand. Doch genau dies kann passieren, wenn das Thema App-Sicherheit nicht ernst genug genommen wird.

Die Sicherheit mobiler Apps ist aus verschiedenen Gründen wichtig. Einerseits gilt es, die persönlichen Daten der App-User zu schützen. Andererseits sollten auch die App-Betreiber darauf bedacht sein, den Zugriff auf ihre Daten beziehungsweise zu ihren Servern zu sichern. Denn ein erfolgreicher Angriff auf eine App kann verheerende Folgen für Firmen haben. Neben dem Diebstahl sensibler Unternehmensinformationen ist es im Worst Case möglich, dass das gesamte Geschäftsmodell abrupt zum Ende kommt – etwa aufgrund drohender Strafzahlungen für die Verletzung des Datenschutzes oder mangelnder Sorgfaltspflicht. Wie das Allianz Risk Barometer 2020 bestätigt[1], zählen Cybervorfälle nicht umsonst als das größte Geschäftsrisiko.

App-Sicherheit selbst in die Hand nehmen

Zunächst ist es sinnvoll, die offiziellen App-Stores zu nutzen, da diese eine essenzielle Funktion besitzen. Sie sorgen dafür, dass die Anbieter die Spielregeln einhalten und bestimmte Funktionen, darunter die Advertising ID auf Android oder iOS, nicht missbräuchlich verwenden. Außerdem wird seitens der Stores untersucht, ob sich bekannte Malware in den Apps verbirgt. Natürlich haben die App-Stores selbst Interesse daran, keine minderwertige Qualität anzubieten, weil sie letztendlich Apps verkaufen und Umsatz machen wollen.

Die Stores verhindern jedoch nicht, dass irgendjemand – sei es ein Angreifer, ein Sicherheitsforscher oder ein ehemaliger Angestellter einer Firma – beabsichtigt, die App zu manipulieren. Vor der Veröffentlichung sollte daher immer auch ein Security-Spezialist beauftragt werden, die App unter die Lupe zu nehmen und den Hersteller zu informieren, sofern eine Sicherheitslücke gefunden wurde. Darüber hinaus können die App-Stores nicht verhindern, dass sich ein Angreifer die App genauer ansieht – zum Beispiel, weil sich manipulierbare hartkodierte Passwörter oder Backdoors darin befinden. In diesem Fall muss sich die App selbst schützen und auch reagieren können. Hierzu sind die App-Stores nicht in der Lage. Als Unternehmen ist es daher notwendig, sich abseits von den App-Stores Gedanken über die App-Sicherheit zu machen und nicht davon auszugehen, das bloße Einstellen der App in einen Store sei ausreichend.

Doch was ist erforderlich, um Apps maximal abzusichern? Das erfahren Sie in unserem nächsten Blogbeitrag!

[1] https://www.agcs.allianz.com/news-and-insights/news/allianz-risk-barometer-2020-de.html


Wie Apps endlich sicher werden. Das Interview von Insider Research mit Torsten Leibner liefert Antworten.

Build38 Head of Product Management

Diese und viele andere spannende Fragen stellte Oliver Schonscheck, renomierter Technology Journalist für Security Insider, in seinem Interview mit Torsten Leibner, Build38 Head of Product Management & Technology.

Mobile Apps durchdringen mittlerweile alle Lebensbereiche, doch scheint die Sicherheit der Apps zu stagnieren. Selbst Apps aus offiziellen App-Stores können risikobehaftet sein.

Zum Hintergrund: Sicherheitsforscher des Helmholtz-Zentrums für Informationssicherheit in Saarbrücken, der Ohio State University und der New York University haben herausgefunden, dass viele mobile Apps spezielle Funktionen vor den Nutzern verstecken, die Angreifern den Zugung zu Daten des Mobiltelefon ermöglichen können. Damit ist die Sicherheit der Nutzer und letztendlich auch die Infrastruktur der Anbieter gefährdet.

Warum sind also mobile Apps immer noch unsicher? Sind die existierenden Security-Guidlines ausreichend? Wie kann die App-Sicherheit endlich besser werden? Was sind die richtigen Schritte für mehr Sicherheit? Was muß ein Unternehmen oder auch der Entwickler machen, damit sich die App-Sicherheit verbessert?
Der Podcast auf Soundcloud liefert die Antworten darauf!

Wir wünschen viel Spaß beim Reinhören!


Handout zum Online Seminar - Mobile APP Fraud

Herzlichen Dank für Ihr Interesse und Ihre Teilnahme!

Mehr als 70 Teilnehmer haben bei unserem online Seminar zu Mobile APP Fraud und was man dagegen tun kann zugehört und Fragen gestellt. Im Namen des BVMW und der Build38 herzlichen Dank!

Anbei wie versprochen der Link auf die Handout Unterlagen - eine PDF Version der gezeigten Präsentation.

Bleiben Sie uns gewogen und nutzen Sie unsere Services und Lösungen für Ihre eigenen APP Entwicklungen oder Sicherheitstests.

Empfehlen Sie uns auch gerne weiter - wir stehen jederzeit für eine Demo oder weiterführende Erklärungen zur Verfügung! Click here!