Alle Beiträge von Julian Totzek-Hallhuber

Wie sich Microservices auf die Anwendungssicherheit auswirken

Microservices sind im Software Development schon seit mehreren Jahren auf dem Vormarsch. Viele kleine Services anstatt einzelner monolithischer Applikationen zu entwickeln, bietet in der Tat zahlreiche Vorzüge. Eine kleine Auswahl der positiven Effekte einer Microservices-Architektur:

  • Services in verschiedenen Apps mehrfach nutzen. Die Grenzen zwischen Anwendungen verschwinden. Das verändert auch, was eine Applikation eigentlich ausmacht. Ein Beispiel: An die Stelle von vier Apps mit jeweils einer Komponente zur Zahlungsabwicklung tritt ein Microservice für Zahlungen, den mehrere Anwendungen nutzen können.
  • Von größerer technologischer Vielfalt profitieren. Der Entwickler ist für die Dauer eines Projekts nicht länger auf eine einzige Plattform festgelegt. Vielmehr wählt er passgenau die Technologie, die die Anforderungen eines bestimmten Services am besten erfüllt.
  • Vereinfachte Wartung. Wenn ein Teil der Lösung veraltet ist oder Funktionsstörungen auftreten, muss nur ein kleiner Service aktualisiert oder ersetzt werden. Ein enormer Vorteil, denn bei großen Monolithen können schon kleinste Veränderungen gewaltige Wellen schlagen und einen Testing-Albtraum nach sich ziehen.
  • Höheres Entwicklungstempo. Anders als bei großen Plattformen lassen sich kleine Änderungen in einer Microservices-Architektur zügig planen, testen und implementieren. Dies beschleunigt Innovationen – und Unternehmen können neue Funktionen deutlich schneller auf den Markt bringen.

Neue Herausforderungen für die Application Security

Doch wie beeinflussen Microservices ein Programm zur Anwendungssicherheit – speziell im Hinblick auf das beschleunigte Entwicklungstempo, das sie mit sich bringen? Wo ergeben sich neue Herausforderungen für die Application Security? Die häufigsten Diskussionen drehen sich um folgende drei Aspekte:

  • Streben nach Hochgeschwindigkeit. Der Umstieg auf Microservices ist häufig ein Kernelement bei der Einführung von DevOps. Denn mit dem Application-Security-1.0-Ansatz – der Code wird zur Analyse an ein Sicherheitsteam geschickt und dieses liefert anschließend einen Report – bleibt entweder die Geschwindigkeit oder die Sicherheit auf der Strecke. Beides ist für eine DevOps-Kultur unakzeptabel, verspricht diese doch, qualitativ hochwertige – und umfassend gesicherte – Software schnell auf den Markt zu bringen. Das ist jedoch nur möglich, wenn die Anwendungssicherheit Softwaretests automatisiert und mit schnellen Feedbackschleifen ins DevOps-Konzept integriert.
  • Zentralisierte Sicht. Der Umstieg auf Microservices bedeutet für ein Application-Security-Team, dass es mehr – wenn auch kleinere – Anwendungen verwalten muss. Was vordem eine einzige Anwendung war, besteht nun aus Dutzenden von Microservices. Das stellt auch kleine und mittelständische Unternehmen vor eine Herausforderung, die große Firmen schon seit Jahren beschäftigt: Wie lässt sich ein effektives Anwendungssicherheitsprogramm nach Maß betreiben? Hier wird deutlich, wie wichtig eine leicht skalierbare Lösung ist, die eine zentrale Sicht ermöglicht und damit Compliance, die Pflege des Inventars sowie eine kennzahlengestützte Überwachung sicherstellt.
  • Technologisch Schritt halten. Einer der größten Vorteile von Microservices ist, dass genau die Technologie zum Einsatz kommt, die eine bestimmte Anforderung erfüllt. Entwicklungsteams sind immer seltener auf einzelne Programmiersprachen spezialisiert. Neben Java nutzen sie auch Scala oder js und beginnen, sich darüber hinaus beispielsweise GO anzueignen. Solch ein agiles Entwicklungsteam braucht ein agiles Sicherheitsprogramm, das seinen Support laufend auf zusätzliche Frameworks, Programmiersprachen und Integrationspunkte ausweitet.

Agile Anwendungssicherheit

Mit dem Umstieg auf Microservices oder noch einen Schritt weiter auf DevSecOps sollte es jedem Unternehmen möglich sein, Software schneller und in höherer Qualität zu entwickeln. Die Application Security muss diesen Wandel jedoch mitmachen und sich entsprechend anpassen. Andernfalls kommt es zum Konflikt zwischen Bereitstellungsgeschwindigkeit und Sicherheit der Software.

Die vier Etappen der DevOps-Reise

Die Umstellung auf DevOps ist kein Spaziergang. Damit ein erfolgreicher Start gelingen kann, benötigen Unternehmen ausreichend Know-how, aussagekräftige Metriken, eine durchdachte Herangehensweise und die richtige Technologie. Vier Etappen gilt es zu bewältigen, in denen jeweils andere Schwerpunkte über Erfolg und Misserfolg der Mission entscheiden:

Am Anfang war das Chaos…

Die Ausgangssituation ist in vielen Unternehmen die gleiche: IT-Betrieb und Entwicklerteam kochen jeweils ihr eigenes Süppchen. Die Zusammenarbeit beschränkt sich auf ein Minimum, Kommunikation zwischen den beiden Abteilungen erfolgt zumeist spontan und ohne feste Agenda. Die meisten Prozesse werden manuell erledigt, Automatisierung gibt es allenfalls in Ansätzen. Der Software Development Lifecycle (SDLC) ist chaotisch, unkontrolliert und unvorhersehbar. Hier beginnt die DevOps-Reise.

In der Anfangsphase ist zunächst entscheidend, erste Automatisierungsinitiativen anzustoßen und den Blick aller Mitarbeiter für das große Ganze zu schärfen. Die Botschaft muss lauten: Entwicklung und IT-Betrieb arbeiten auf das gleiche Ziel hin; alle sitzen in einem Boot.

#1: Managen

Auf der ersten Etappe der DevOps-Reise hat die Kommunikation zwischen Entwickler und IT-Betrieb bereits geregelte Formen angenommen, Entscheidungen werden vermehrt gemeinsam getroffen. Automatisierung existiert, aber verharrt in Silos. Es fehlt noch eine zentralisierte Infrastruktur. Auch die Prozesse haben weiterhin Optimierungsbedarf: Sie werden nun zwar zentral verwaltet, aber sind noch nicht standardisiert.

Zuerst sollten nun Qualitätsmaßstäbe etabliert werden, die verhindern, dass erkannte Fehler ungelöst durch den SDLC wandern. Parallel dazu müssen die IT-Verantwortlichen verhindern, dass Optimierungen von Teilen des Systems derart große Verwerfungen nach sich ziehen, dass das System insgesamt anschließend weniger effizient funktioniert als zuvor.

#2: Definieren

Auf der zweiten Etappe stellen sich erste größere Erfolge ein. Kollaboration und gemeinsame Entscheidungsfindung funktionieren, die Verantwortlichkeiten sind klar verteilt. In der Vergangenheit spielten Entwickler und IT-Betrieb gerne das sogenannte „Blame Game“, wenn etwas nicht funktionierte. Dem ist jetzt die Grundlage entzogen, alle ziehen an einem Strang. Prozesse entlang des SDLCs sind standardisiert und automatisiert.

Die Umsetzung von Bugfixes und neuen Features ist insgesamt schneller möglich, da es häufigere und kürzere Feedback-Loops gibt. Es kommt nun darauf an, die Anforderungen von internen und externen Leistungsnehmern besser zu verstehen.

#3: Messen

Auf der dritten Etappe der Reise hat sich der ehemals chaotische SDLC verwandelt: Er ist jetzt berechenbarer, transparenter und effizienter. Alle Prozesse werden an vordefinierten Erfolgsmaßstäben gemessen. Effizienzhürden und Flaschenhälse sind auf diese Weise leicht zu identifizieren und zu beseitigen. Auch die Qualitätsprüfung wird erleichtert: Qualität und Performance der entwickelten Anwendungen lassen sich leichter vorhersehen.

Jetzt geht es an den Feinschliff: IT-Verantwortliche sollten sich Zeit einplanen, um weiter an der Verbesserung der Prozesse zu arbeiten. Außerdem sollten sie weitere Erfolgsmetriken definieren, die nicht mehr nur unmittelbare Faktoren wie Verfügbarkeit oder Anwendungsperformance abbilden, sondern sich mit konkreten Geschäftszielen befassen.

#4: Optimieren

Wer sich auf der vierten Etappe der DevOps-Reise befindet, hat sein Ziel praktisch erreicht. Entwickler und IT-Betrieb ziehen an einem Strang, die Entwicklungszyklen sind verkürzt und Automatisierungswerkzeuge erhöhen in allen Bereichen die Effizienz. Die Informationsweitergabe funktioniert über den gesamten SDLC hinweg, jeder Mitarbeiter kann außerdem im Selbstbedienungsverfahren auf Lernmaterial zugreifen und sich weiterbilden.

Für Unternehmen gilt jedoch: Wer rastet, rostet. Als Teil der neuen Kultur sollten Teams fortan systematisch dafür belohnt werden, wenn sie Neues ausprobieren und dabei kalkulierte Risiken eingehen. Denn nur so lässt sich die Innovationsgeschwindigkeit dauerhaft hochhalten.

Security: Tipps von der Front

Julian Totzek-Hallhuber, Solutions Architect beim Spezialisten für Anwendungssicherheit Veracode, hat sich diesen Fragen angenommen und gibt Tipps von der Front:

  1.  Die eigenen Anwendungen kennen

Wenn Unternehmen ihre Sicherheitslücken schließen wollen, müssen sie zuerst ihre Anwendungen selbst unter die Lupe nehmen. Umso mehr Anwendungen in ein Unternehmen integriert werden, desto schwieriger wird es, den Überblick über potenzielle Schwachpunkte zu behalten. Die Unwissenheit wird größer als das Wissen – so kommt es zu Problemen. Viele Programme zur Anwendungssicherheit beginnen damit, dass sie sich auf webbasierte Applikationen oder Applikationen, die kritische Daten erfassen, konzentrieren. Dabei beachten Sie nicht, dass Vorgängerversionen, Marketing-Webseiten, Drittanbieter-Anwendungen, Open-Source-Apps oder Apps für interne Systeme einen großen Teil des Risikos ausmachen. Nur wem seine Anwendungslandschaft bekannt ist, kann auch erkennen, wo Sicherheitslücken entstehen können.

  1. Aufbau eines qualifizierten Teams

Wer will, dass seine Anwendungen sicher sind, darf sich nicht von der Außenwelt abkapseln. Die Entwickler müssen die Möglichkeit haben, sich mit anderen auszutauschen. Immer mehr Sicherheitsexperten arbeiten daran, darauf aufmerksam zu machen, wie sicherer Code auszusehen hat. Das ist besonders wichtig, weil vor allem junge Entwickler, die frisch von der Universität kommen, bis dato vermutlich keine eigenen Erfahrungen mit Cyber-Attacken gemacht haben. Indem man mehrmals im Jahr ein Training anbietet, können die Teams bald nicht nur schneller Bedrohungen erkennen, sondern wissen auch viel besser, wie sie gegen sie vorgehen können. Egal ob durch Schulungen, Konferenzen, Seminare, Messebesuche oder eLearning: Unternehmen profitieren immer davon, wenn sie ihrer IT-Abteilung helfen, sich weiterzubilden und sich mit anderen auszutauschen.  

  1. Realistische Richtlinien setzen

Um Sicherheit zu gewährleisten, müssen Sicherheitstests so einfach wie möglich sein. Unternehmen, die zu strenge Sicherheitsrichtlinie haben, stellen sich selbst ein Bein. Die Regeln sollten immer realistisch sein. Nicht jede Sicherheitslücke ist gleich ein großes Risiko und muss sofort geschlossen werden. Richtlinien für die Sicherheit von Anwendungen zu erstellen, ist ein fortlaufender Prozess. Man beginnt mit einer Rohfassung und erweitert diese dann, wenn die Entwickler im Unternehmen vor neuen Herausforderungen stehen. Mit der Zeit werden die Regeln immer komplexer. Dabei ist es wichtig, dass nicht nur große Sicherheitslücken, sondern nach und nach auch mittlere Probleme bekämpft werden und Scans mit höherer Frequenz stattfinden. Die Einführung neuer Regeln führt oft dazu, dass interne Programme zur Anwendungssicherheit langsamer laufen. Deshalb sollte man am Anfang klein beginnen und sich dann in die Details einarbeiten.

  1. Frühzeitig beginnen

Viele Hersteller warten so lange wie möglich mit einem Sicherheitstest für ihre Anwendung. Das kann aber am Ende mehr Arbeit bedeuten. Wer bereits im Entwicklungsprozess verschiedene Sicherheitstests integriert, hat es nachher um einiges leichter. Unternehmen gewährleisten so, dass sie sicheren Code verwenden, ohne dass sie ihre Produktion lange aufhalten müssen. Das IT-Team kann Sicherheitslücken sofort schließen, wenn sie gefunden werden. Viele Software-Hersteller führen zum Beispiel immer automatisch einen Sicherheitstest durch, sobald eine bestimmte Phase der Entwicklung abgeschlossen ist. Auch wenn die Erstellung von Code von Unternehmen zu Unternehmen anders aussieht, gibt es dennoch in jedem Produktionsschritt die Möglichkeit, einen Sicherheitstest einzubauen.

Fazit

Jedes Unternehmen muss letztendlich anhand seiner Ansprüche selbst entscheiden, welches Anwendungssicherheits-Programm das Richtige ist. Beachtet man allerdings die oben genannten Tipps, baut man eine sehr gute Basis – ein Schritt in die richtige Richtung. Der aktuelle Bericht zum Status der Softwaresicherheit von Veracode zeigt, dass Unternehmen, die Best Practices einsetzen und Programme mit konsequenten Strategien und Praktiken für eine sichere Entwicklung implementieren, Schwachstellen schneller und effektiver beseitigen können. Die Studie zeigt, dass das obere Quartal der Unternehmen fast 70 Prozent mehr Schwachstellen behebt als das durchschnittliche Unternehmen.

In drei Schritten zu mehr Anwendungssicherheit

1.Risiken erfassen – und angemessene Antworten finden

Hand aufs Herz: Perfekte Sicherheit wird es nie geben. Es ist unmöglich, das gesamte Anwendungsportfolio frei von Schwachstellen zu halten. IT-Verantwortliche müssen die verfügbaren Ressourcen deshalb kanalisieren und gezielt einsetzen. Die Grundlage hierfür bildet eine Strategie, die auf konkrete Risiken ausgerichtet ist – und nicht auf die Bewahrung der Illusion, dass ein System unverwundbar gemacht werden könne. Geschützt werden sollten vor allem solche Anwendungen und Teile der Infrastruktur, die von sicherheitskritischer Bedeutung sind.

Zunächst ist dazu eine Bestandsaufnahme von Nöten. Welche Anwendungen gibt es im Unternehmen – und auf welchem Entwicklungsstand befindet sich die Anwendungssicherheit? Sobald diese Fragen geklärt sind, können Richtlinien definiert werden. Diese legen fest, mit welchen Risiken das Unternehmen umgehen kann und welche es auf jeden Fall zu vermeiden gilt. Sie bilden die Basis für das weitere Vorgehen und bestimmen etwa, in welchen Bereichen die Entwickler besondere Trainings erhalten. Im Zentrum aller Bemühungen steht jedoch die Integration etablierter Tools, die dabei helfen, kritische Schwachstellen effizienter aufzuspüren und zu beseitigen.

2. Risiken beachten, die durch Anwendungen von Drittanbietern entstehen

Am ersten Tag ein Gast, am dritten eine Last: Dieses alte Sprichwort lässt sich häufig auch auf die Software von Drittanbietern übertragen. Selbst hauseigene Entwicklungen greifen häufig auf Komponenten zurück, die von externen Dienstleistern stammen oder unter einer Open-Source-Lizenz stehen. Ein solches Vorgehen ist zumeist kostengünstiger, als das Rad neu zu erfinden. Es birgt aber das Risiko, dass man sich mit dem fremden Code auch Sicherheitslücken ins Haus holt.

Um Entwicklern zu helfen, produktiver zu arbeiten und die Anwendungssicherheit dabei nicht aus den Augen zu verlieren, sollten IT-Verantwortliche ihnen einen Informationsvorsprung verschaffen. Zum Beispiel indem sie eine Technologie implementieren, die Informationen über die Komponenten von Drittanbietern sowie über die darin entdeckten Sicherheitslücken bereithält und Anwendungen markiert, die von diesen Schwachstellen betroffen sind.

3. Die richtigen Erfolgsmaßstäbe etablieren

Woher wissen IT-Verantwortliche, dass ihre Pläne aufgehen und ihre Maßnahmen greifen? Metriken und KPIs sollten bei allen Bemühungen zur Verbesserung der Anwendungssicherheit im Zentrum stehen. Denn nur wer die wesentlichen Erfolgsmaßstäbe im Blick behält, kann fundierte Entscheidungen treffen. Detaillierte Statistiken und Analysen helfen auch, ein breites Bewusstsein für die Bedeutung der Anwendungssicherheit zu schaffen – etwa bei Entwicklern, Budgetverantwortlichen und Mitgliedern der Unternehmensführung. Auf einige Metriken sollte ein besonderes Augenmerk gelegt werden:

Richtlinienkonformität: Richtlinien reflektieren, welche Risiken ein Unternehmen unbedingt vermeiden will. Veracode empfiehlt, innerhalb des Anwendungsportfolios konsistente Richtlinien durchzusetzen. Eine mögliche Richtlinie wäre etwa, dass alle Web-Anwendungen frei von den in der OWASP-Top-10-Liste genannten Schwachstellen sein müssen.

Zahl der gefundenen Mängel: Diese Metrik erfasst die Zahl der gefundenen Schwachstellen, die in Applikationen gefunden werden – SQL-Injections, Cross-Site-Scripting (XSS) oder kryptographische Unzulänglichkeiten. Sie lässt vor allem Rückschlüsse darauf zu, in welchen Bereichen Entwickler Nachholbedarf haben und durch gezielte Trainings gefördert werden können.

Erfolgsquote: Wie viele der gefundenen Schwachstellen können am Ende auch beseitigt werden? Die Erfolgsquote ist ein Gradmesser für die Qualität der etablierten Mechanismen und erlaubt es, die Ressourcenallokation besser zu steuern.

Unternehmensspezifische Erfolgsmaßstäbe: Nicht alle sinnvollen Metriken besitzen universelle Gültigkeit, manche gelten lediglich in speziellen Zusammenhängen. IT-Verantwortliche sollten deshalb nach Erfolgsmaßstäben suchen, die die innerhalb ihres Unternehmens geltenden Prioritäten optimal abbilden – etwa die Zahl der automatisiert getesteten Anwendungen oder durchgeführten Trainings.

Fazit: Anwendungssicherheit ist kein Hexenwerk

Um die Anwendungssicherheit im Unternehmen zu verbessern, benötigt die IT zwei Dinge: die richtige Strategie und die richtigen Tools. Risiken müssen erfasst, Erfolgsmaßstäbe etabliert werden. Vor allem aber gilt es, Sicherheitslücken in kritischen Anwendungen zuverlässig zu identifizieren und zu beseitigen. Wer die oben genannten Schritte vollzieht, kommt diesem Ziel schnell näher.

Forscher hacken Jeep – schon wieder

Eine solche Übernahme wäre für die mitfahrenden Personen lebensgefährlich. Julian Totzek-Hallhuber, Solution Architect bei Veracode, bezieht im Folgenden Stellung zu den Gefahren von Connected Cars:

„Die Sicherheitslücke bei Fiat ist nicht die erste Lücke in vernetzten Fahrzeugen. KFZ-Hersteller, Komponentenhersteller und unabhängige Softwarefirmen stehen gleichermaßen vor der großen Herausforderung, ein sicheres Programm zur Anwendungsentwicklung aufzusetzen. Dazu muss ihnen unbedingt bewusstwerden, wie gefährlich das Hacken der Fahrzeuge und gerade der Fahrzeugsteuerung sein kann. Sie sollten aus den aktuellen Sicherheitslücken lernen und verstärkt ihren Fokus darauf legen, die Sicherheit schon während der Entwicklung von Anwendungen zu erhöhen. Im Moment können wir froh sein, dass sich die Fahrzeuge noch in der Entwicklung – und nicht auf der Straße – befinden.

Was wir in der Automobilindustrie beobachten können, ist ein Mikrokosmos dessen, was aktuell in der Finanzbranche, dem Gesundheitswesen und praktisch jeder anderen Branche passiert – es werden unzählige Anwendungen programmiert, ohne auf die Sicherheit zu achten. Applikationen aus dem Internet erobern derzeit das Automobil, doch sie stellen ein enormes Risikofeld dar, das unbedingt in den Fokus der KFZ- und Softwarehersteller rücken muss.

Denn eine kürzlich veröffentlichte Studie von Veracode und IDC zeigt, dass Autofahrer durchaus Bedenken haben. 57 Prozent der deutschen Autofahrer macht sich Sorgen um die Sicherheit von vernetzten Assistenzsystemen im Auto. Und auch den Herstellern geht es nicht anders: sie haben große Sicherheitsbedenken gegenüber Anwendungen, die sie nicht selbst entwickelt haben. Bis Anwendungen und Systeme im Auto ausreichend vor Cyberangriffen geschützt sind, wird es wohl noch bis zu drei Jahren dauern.“

Die vier häufigsten Missverständnisse unter Cloudnutzern

Das fortschrittsfeindliche Werk von wirtschaftsfremden Bürokraten? Oder eine notwendige Modernisierung veralteter Regelungen? Die neue Datenschutz-Grundverordnung der Europäischen Union hat für einige Kontroversen gesorgt. Nun ist sie allerdings beschlossen und in Kraft getreten – mit einer Übergangsfrist bis Mai 2018. Sie ersetzt die längst eingestaubte EU-Datenschutzrichtlinie aus dem Jahr 1995. Doch was das genau bedeutet und was sich ändern wird, ist nicht jedem bewusst.

Das neue Gesetz wurde nicht zuletzt mit dem Ziel verabschiedet, den Datenschutz im digitalen Zeitalter klarer zu gestalten. Gerade auch für Cloudnutzer soll in Zukunft eindeutiger sein, was erlaubt ist und was nicht. Zunächst einmal erreichen die neuen Regelungen jedoch das genaue Gegenteil: Sie sorgen für zusätzliche Verwirrung, wie nun mit Daten in der Cloud umgegangen werden soll.

Deshalb räumen wir im Folgenden mit den vier häufigsten Missverständnissen auf:

Missverständnis Nr. 1: Die Datenschutz-Grundverordnung verbietet Unternehmen, personenbezogene Daten in der Cloud zu speichern

Was müssen Unternehmen beachten, die personenbezogene Daten erheben, archivieren und verarbeiten? Dass sie in Zukunft vollends auf Cloud-Services und SaaS verzichten müssen, ist natürlich eine Fehlinformation. Es besteht neuerdings jedoch die Pflicht, den Datenaustausch mit der Cloud exakt zu dokumentieren. Außerdem sollen Unternehmen „geeignete technische und organisatorische Maßnahmen“ ergreifen, um die unrechtmäßige Verarbeitung personenbezogener Daten und vergleichbares Fehlverhalten zu verhindern. Im Hinblick auf Daten, die nicht als personenbezogen klassifiziert werden können, ist die Richtlinie übrigens weniger strikt – spezifische Maßnahmen oder Vorkehrungen werden hier nicht gefordert.

Missverständnis Nr. 2: Unternehmen aus der Europäischen Union dürfen fortan keine Verträge mehr mit Cloud- oder SaaS-Anbietern abschließen

Die herrschende Verwirrung hat einige Unternehmen dazu bewogen, von Verträgen mit SaaS- und Cloud-Providern vorerst Abstand zu nehmen. Sie verzichten damit auf eine der wichtigsten Innovationen des digitalen Zeitalters – und das letztlich grundlos. Denn entscheidend ist lediglich, dass Unternehmen personenbezogene Daten in der Cloud angemessen schützen und den Datenaustausch dokumentieren. Sind diese Voraussetzungen erfüllt, steht der Nutzung entsprechender Services nichts im Weg.

Missverständnis Nr. 3: Unternehmen, die Daten in der Cloud speichern, erwartet eine Strafe

Wer in der Cloud mit personenbezogenen Daten hantiert, dabei seine Sorgfaltspflicht verletzt und dann Opfer eines Datendiebstahls wird, den erwartet tatsächlich eine Strafe. Sofern diese drei Bedingungen jedoch nicht gleichzeitig gegeben sind, haben Unternehmen nichts zu befürchten. Das einfache Speichern von Daten in der Cloud ist selbstverständlich nicht verboten und wird auch nicht bestraft.

Missverständnis Nr. 4: Kommt es zu einem Datendiebstahl, sehen Cloudnutzer hohen Geldstrafen entgegen

Die neue Datenschutz-Grundverordnung verlangt von Unternehmen, geeignete Maßnahmen zu ergreifen um sicherzustellen, dass alle persönlichen Daten in der Cloud ausreichend geschützt sind. Kommen sie dieser Verpflichtung nicht nach, erwarten sie im Falle einer Kompromittierung der Daten tatsächlich schwerwiegende Geldstrafen. Wer unverschuldet Opfer eines Datendiebstahls wird, hat jedoch keine zusätzliche Bestrafung zu befürchten. Es reicht deshalb aus, in Zukunft ein verstärktes Augenmerk auf Sicherheit zu legen.

Fazit: Die Cloud besser absichern

Die Datenschutz-Grundverordnung der Europäischen Union trifft Cloudnutzer weniger hart als oftmals befürchtet. Doch trotz aller Missverständnisse: Das neue Gesetz konfrontiert Unternehmen mit neuen Anforderungen. Wenn sie personenbezogene Daten in der Cloud speichern wollen, müssen sie in Zukunft verstärkt dafür sorgen, dass diese auch ausreichend geschützt sind. Außerdem muss der Datenaustausch sorgfältig dokumentiert werden. Kommen sie diesen Verpflichtungen nicht nach, erwarten sie Bußgelder in erheblicher Höhe. Das notwendige Know-how müssen entweder die eigenen Mitarbeiter bereitstellen oder externe Dienstleister, die auf Datenschutz und Sicherheit spezialisiert sind. Angesichts der gestiegenen Anforderungen auf die Cloud zu verzichten, wäre natürlich keine gute Idee: Unternehmen würden sich damit der wichtigsten Plattform für die Digitalisierung ihrer Geschäftsprozesse berauben – und somit zwangsläufig hinter ihre Konkurrenz zurückfallen.

Vier Tipps für sichere mobile Anwendungen

Das Ziel muss sein, alle Geräte abzusichern und dabei die Mitarbeiter nicht bei ihrer Arbeit einzuschränken. Da ständig neue Geräte auf den Markt kommen und die mitgebrachten Geräte stetig wechseln, ist es nicht ausreichend, die einzelnen Endgeräte im Netzwerk durch Mobile Device Management (MDM) oder Single Sign-On (SSO) abzusichern. Diese Schritte sind zwar nützlich, reichen aber nicht aus, wenn die auf dem Gerät vorhandenen Anwendungen nicht sicher sind. Hierbei hilft nur die Integration von Sicherheitskontrollen für jede mobile Unternehmens-App.

Da die Bring-Your-Own-Device-Philosophie heutzutage in kaum einem Unternehmen vermieden werden kann, gibt Julian Totzek-Hallhuber, Solution Architect beim Anwendungssicherheits-Spezialisten Veracode, im Folgenden vier Tipps für die sichere Bereitstellung von mobilen Apps und Geräten in Unternehmen:

  1. SQL Injections sind immer noch eine weit verbreitete Schwachstelle. Entwickler müssen nicht-vertrauenswürden Input davor schützen, als Teil eines SQL-Befehls interpretiert zu werden – und im Grunde ist alles, was aus dem Internet kommt, als nicht-vertrauenswürdig einzustufen. Der beste Weg, um SQL Injections zu stoppen, ist der Einsatz von parametrisierten Abfragen.
  1. Passwörter werden immer noch zu fahrlässig ausgewählt, niedergeschrieben oder gespeichert. Am sichersten ist es, aktuelle Verschlüsselungstechniken anzuwenden, um Passwörter zu schützen – beispielsweise einen nicht umkehrbaren Verschlüsselungsalgorithmus. Doch auch schon ein zufällig generierter Zahlencode hilft.
  1. Eine Anwendung sollte immer eine erneute Authentifizierung vom Nutzer erfordern, bevor eine Transaktion abgeschlossen wird. So wird ein Hijack der Nutzersitzung verhindert. Zudem sollte die App selbst Gebrauch von einer Multi-Faktor-Authentifizierung machen, sodass kein Fremder darauf zugreifen kann. Sollte dies nicht möglich sein, kann die Authentifizierung auch entsprechend in das SSO- oder MDM-Tool eingebunden werden.
  1. Zuletzt ist es unerlässlich, die Schwachstellen der gewählten Programmiersprache zu kennen und dafür zu sorgen, dass der Code vor diesen sicher ist. Die gängigsten Schwachstellen finden sich in der Top-10-Liste des Open Web Application Security Project (OWASP). Ideal wäre es, wenn die Entwickler wüssten, wie sich jede dieser Schwachstelle finden und fixen lässt. Doch es gibt auch unzählige Tools (z. B. von Veracode), die beim Aufspüren helfen können.

Für Unternehmen ist es sinnvoll, den Angestellten zu erlauben, ihre eigenen Geräte für die Arbeit zu nutzen und Unternehmensanwendungen für diese Geräte bereitzustellen. Dies spart enorme Kosten für die ständige Anschaffung aktueller Firmengeräte und die Mitarbeiter können ihre Arbeitszeit und den -ort flexibler gestalten. Auch die IT hat hierdurch keinen höheren Verwaltungsaufwand, denn auch für firmeneigene Geräte müssten die gleichen Sicherheitsvorkehrungen getroffen werden. Wichtig ist nur, dass Unternehmen sich umfassend über mögliche Risiken informieren und nicht davor zurückschrecken, Hilfe in Form von Expertenfachwissen anzunehmen. Anwendungssicherheit ist unverzichtbar, machbar und vor allem bezahlbar – man kann sich nur nicht vor Angriffen schützen, mit denen man überhaupt nicht rechnet.