„Vielleicht gibt es in 15 Jahren auch gar keine Smartphones mehr“

Konrad und TamaraSieht mit 15 Jahren die digitale Welt ganz anders aus als mit 44? doubleSlash-Gründer Konrad Krafft und seine Tochter Tamara im Gespräch zu Technologie von damals, heute und der Zukunft.

Wie sah die Technikwelt aus, als du 15 Jahre alt warst? Was ist dir besonders in Erinnerung geblieben und war unverzichtbar?

Mehr…

Weiterbildung bei doubleSlash: Employer Branding mal anders

Techdays 14Von Mitarbeitern für Mitarbeiter – das ist das Credo der „Technology Days“, ein zweitägiger Workshop, den doubleSlash jährlich gemeinsam mit den Mitarbeitern veranstaltet.

Themen und Trends rund um technische und businessrelevante Inhalte waren Bestandteil der Fachvorträge auf den „Technology Days 2014“. In kleinen Gruppen haben wir uns rege zu Themen wie „Was tut eigentlich ein Garbage Collector?“ oder „Neues in Java 8“ ausgetauscht.
Dabei kamen auch neue Präsentationsformate zum Einsatz. Der Lightning Talk (Blitzvortrag) ist ein gängiges Format auf technischen Konferenzen. Ein Vortrag dauert nur ein paar Minuten, für jeden Slide wird eine bestimmte Sekundenzahl vorgesehen. Mehrere Referenten sprechen dann in einem vorgegebenen Slot zu unterschiedlichen Themen.[1]Mehr…

Security in Webanwendungen Teil 3: Sicherer Betrieb von Webapplikationen

In dieser Blogserie haben wir bereits die Themen Design– und Programmierung von sicheren Webanwendungen behandelt. Im letzten Teil wird beschrieben, wie der sichere Betrieb von Webapplikationen gewährleistet werden kann.

Reduzieren von Serverinformationen

Selbstverständlich möchte man einem Hacker so wenig Informationen über ein System geben wie nur möglich. Allein die Anzeige der Versionsnummer der verwendeten Server kann genutzt werden, um gezielt nach Informationen über Sicherheitslücken der spezifischen Versionen zu suchen. Dadurch wird der Aufwand, in das System einzudringen, für einen Angreifer geringer.

Das übliche sicherheitssensible System nutzt einen Proxyserver um die SSL-Verschlüsselung der Verbindung zu terminieren, damit der eigentliche Applikationsserver vor dem direkten Zugriff durch die Nutzer geschützt wird. Die Datenübertragung zwischen dem Proxy- und Applikationsserver erfolgt dann oft unverschlüsselt. Somit gibt es bereits für eine Webapplikation zwei Server, bei denen man die Versionsnummer verbergen muss. Das Verbergen der Server- und Versionsinformationen hat Auswirkungen auf zwei Ebenen. Die eine Ebene ist das HTTP-Protokoll, die zweite Ebene die Anzeige von Exceptions in der Webapplikation. In beiden Ebenen werden keine oder nur reduzierte Informationen angezeigt. Generell sollten dem Nutzer jedoch sowieso keine Exceptions oder Stacktraces angezeigt werden.

Im Folgenden wird an einer Beispielarchitektur gezeigt, wie sich die Versionsnummern abschalten lassen. Genutzt wird ein Apache Webserver in der Version 2.2 als TLS-Proxy, welcher die SSL-Verbindung terminiert und einen Apache Tomcat in der Version 7, der als Applikationsserver dient.

Im Apache Webserver lassen sich die Serverinformationen über den folgenden Eintrag in der Datei „httpd.conf“ anpassen:

ServerTokens Prod

Mit dieser Angabe wird lediglich der Name des Servers angezeigt, im Ursprungszustand würde der Apache Webserver die folgenden Informationen ausgeben:

  • Name des Servers
  • Versionsnummer
  • Name des verwendeten Betriebssystems
  • Name und Versionsnummer der verwendeten Module

Diese Informationen wären für einen Hacker sehr nützlich, denn er kann auf dem Schwarzmarkt gezielt Tools einkaufen, die ihm helfen den Server zu kompromittieren.

Die Reduzierung der Serverinformationen beim Apache Tomcat 7 gestaltet sich etwas schwieriger. Um hier die Serverinformationen zu reduzieren, muss man die Datei „ServerInfo.properties“ aus dem JAVA-Paket „catalina.jar“ entpacken. Zum Entpacken öffnet man die Konsole des Betriebssystems und wechselt in das Verzeichnis „lib“ innerhalb des Apache Tomcat. Anschließend führt man folgenden Befehl aus:

jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties

Nun befindet sich innerhalb des Bibliotheksverzeichnisses der Verzeichnispfad „org/apache/catalina/util“, in dem wiederum die Datei „ServerInfo.properties“ existiert. Im folgenden Beispiel ist der Inhalt der Datei bereits angepasst und im Eintrag „server.info“ die Versionsnummer entfernt:

server.info=Apache Tomcat
server.number=7.0.50.0
server.built=Dec 19 2013 10:18:12

Nun zeigt auch der Apache Tomcat im HTTP-Protokoll und bei Exceptions keine Versionsnummern mehr an.

Die Sicherheit in Webapplikationen kann also an mehreren Stellen optimiert werden. Schon beim Desgin wird durch die Beachtung von Sicherheitsmechanismen ein höherer Standard gewährleistet. Maßnahmen bei der Programmierung, wie beispielsweise das Escaping von Metazeichen oder die Nutzung eines Sicherheitstokens, sorgen ebenfalls für mehr Sicherheit in Webanwendungen. Durch die Reduzierung der Serverinformationen kann auch beim Betreiben von Webapplikationen das Risiko eines Hackerangriffs gesenkt werden.

Security in Webanwendungen Teil 2: Programmierung von sicheren Webapplikationen

Hacker programing in technology enviroment with cyber icons

Im ersten Teil dieser Blogserie beschäftigten wir uns dem Design von sicheren Webanwendungen. In diesem Beitrag geht es darum, wie solche sicheren Webapplikationen programmiert werden können.

Escaping von Metazeichen

Jede Auszeichnungs- oder Abfragesprache hat ihre eigenen Metazeichen, die für die jeweilige Sprache eine spezifische Bedeutung haben und entsprechend interpretiert werden. Durch die Eingabe einer Zeichenkette mit den entsprechenden Metazeichen könnte ein Angreifer beispielsweise dafür sorgen, dass innerhalb der Datenbank Tabellen gelöscht, Benutzerdaten und Passwörter verändert oder sogar ausgegeben werden (Stichwort: SQL-Injection). Durch geschickte Eingaben, die Metazeichen von HTML oder JavaScript enthalten, ist es außerdem möglich, dass anderen Benutzern ungewollte Eingabefelder angezeigt werden. Diese Eingabefelder werden vom arglosen Benutzer höchstwahrscheinlich mit vertraulichen Daten wie Kennwörtern, PINs und Kontonummern versehen, die anschließend an einen Server des Angreifers übertragen werden. Und schon befinden sich die sensiblen Daten außerhalb der eigenen Kontrolle.

Des Weiteren hat der Angreifer die Möglichkeit, die Sitzungsnummer des Benutzers in Erfahrung zu bringen und anschließend Aktionen unter dem Vorspielen einer anderen Identität durchzuführen. Das Manipulieren von Webseiten mit HTML und JavaScript wird in Fachkreisen „Cross-Site-Scripting“ kurz XSS genannt.

Um das Manipulieren von Abfragen und Ausgaben zu verhindern, müssen die entsprechenden Metazeichen bei der Ausgabe an das Zielsystem (Browser, Datenbank) ein passendes Escaping durchlaufen. So werden die Metazeichen nicht mehr als solche erkannt. Das Escaping von solchen Metazeichen kann sehr komplex werden. Darum empfiehlt sich die Nutzung einer Bibliothek, die ausreichend getestet wurde.

Nutzung eines Sicherheitstokens

Um zu verhindern, dass ein Angreifer mithilfe einer per Cross-Site-Scripting erbeuteten Sitzungsnummer im Hintergrund sofort eine Aktion ausführen kann, wird ein sogenannter Page-Token verwendet. Der Page-Token ist eine sehr schwer zu erratende Zeichenkette, die in einem Formularfeld vom Typ „hidden“ in der Webseite ausgeliefert wird. Der Angreifer kann dieses Feld nicht ohne weiteres auslesen. Sendet der Nutzer nun die Antwort an den Server, kann dieser das Token prüfen. Ist das gespeicherte und das empfangene Token identisch, sind die empfangenen Daten vertrauenswürdig. Denn ein Angreifer wäre nicht im Besitz dieses Tokens und könnte auch keine gültige Antwort an den Server senden.

Zugriff auf das Session Cookie beschränken

Damit ein Angreifer die Sitzungsnummer nicht per JavaScript über den Browsers des normalen Benutzers auslesen kann, gibt es die Möglichkeit den Zugriff auf das Sitzungscookie nur auf die HTTP-Ebene zu beschränken. Somit kann es über JavaScript nicht ausgelesen werden.

Um dieses Verhalten in einer Java-Webapplikation umzusetzen, muss innerhalb der Anwendung im Verzeichnis „WebContent/META-INF“ die Datei „context.xml“ angelegt werden und folgenden Inhalt haben:

<Context useHttpOnly="true">
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Manager pathname="" />
<Valve className="org.apache.catalina.valves.CometConnectionManagerValve" />
</Context>

Im oben dargestellten Inhalt wurde das Attribut “useHttpOnly” im Element „Context“ auf den Wert „true“ gesetzt. Dies stellt sicher, dass das Sitzungscookie nicht über JavaScript ausgelesen werden kann.

Austausch der Sitzung

Viele Webapplikationen besitzen die Möglichkeit sich „einzuloggen“ oder auf eine andere Art und Weise ein höheres Vertrauens- und Sicherheitslevel zu erlangen. Sollte es einem Angreifer gelungen sein die Sitzungsnummer (Session-ID) eines nicht angemeldeten Benutzers zu erlangen, hat er die Gelegenheit über seinen Browser die Webapplikation mit der Sitzung des bestohlenen Nutzers zu verwenden. Wenn nun eine Webapplikation die Sitzung nach dem Anmelden des ahnungslosen Nutzers nicht austauscht, könnte der Angreifer die Webapplikation mit den erweiterten Rechten nutzen und Aktionen im Namen eines anderen durchführen. Der rechtmäßige Nutzer merkt von all dem nichts. Darum müssen die Sitzungen nach dem Erlangen einer anderen Sicherheitsstufe unbedingt ausgetauscht und die alte Sitzung beendet werden.

Durch die beschriebenen Maßnahmen beim programmieren von Webapplikationen kann die Sicherheit maßgeblich erhöht werden. Lesen Sie im nächsten Teil unserer Blogserie kommende Woche, wie ein sicherer Betrieb von Webapplikationen möglich ist.

Hier geht es zum ersten Teil der Blogserie Design von sicheren Webanwendungen.

Security in Webanwendungen Teil 1: Design von sicheren Webapplikationen

Verschlüsselung_kleinVorwort

Wir alle nutzen in unserem täglichen Leben eine Vielzahl verschiedenster Webapplikationen und vertrauen ihnen unsere Daten an. Eben dieses Vertrauen in die Systeme ist eine essentielle Grundlage für „das Leben im Internet“. Wird dieses Vertrauen durch einen Sicherheitsvorfall enttäuscht, kann das erhebliche Auswirkungen auf das Image des Betreibers der Webapplikation haben. Sinkende Nutzerzahlen und Verkäufe können die Folge sein. Des Weiteren drohen möglicherweise hohe Entschädigungszahlungen für verlorengegangene Daten. Als logische Konsequenz dieser immensen negativen Auswirkungen sollte jede Webapplikation abgesichert werden, um Kriminellen einen erfolgreichen Angriff auf das System so schwer wie möglich zu machen. Eine 100%ige Sicherheit gibt es zwar nie, dennoch gibt es Mittel und Wege, Webanwendungen sicherer zu gestalten. Diese dreiteilige Blogserie beschäftigt sich mit dem Design, der Programmierung und der sicheren Benutzung von Webapplikationen.

Der Schlüssel zu mehr Sicherheit

Bereits beim Design von Webapplikationen lassen sich Sicherheitsmechanismen berücksichtigen. Gehen wir beispielsweise einmal davon aus, wir sollten ein System entwerfen, welches die Serviceanfragen von Bankkunden entgegen nimmt. Für eine Bank ist es unerlässlich, dass sie als vertrauenswürdig wahrgenommen wird. Sollte diese Vertrauenswürdigkeit in irgendeiner Form in Frage gestellt werden, droht der Bank ein hoher finanzieller Schaden, da möglicherweise weniger potentielle Kunden mit ihr zusammen arbeiten möchten. Somit müssen auch die Serviceanfragen in einer sicheren Form für die spätere Verarbeitung gespeichert werden. Es wäre vorstellbar, das zukünftige System so zu strukturieren, dass die Serviceanfragen von einer öffentlichen Webseite entgegen genommen und die Bearbeitung der Serviceanfragen in einer weiteren Webapplikation im internen Netz der Bank vorgenommen werden. Hier könnte ein asymmetrisches Verschlüsselungsverfahren zum Einsatz kommen. Die öffentliche Webseite würde die Serviceanfragen mit dem öffentlichen Schüssel der Webapplikation zum Bearbeiten der Anfragen verschlüsseln und in einer gemeinsamen Datenbank ablegen. Die interne Webapplikation für den Servicemitarbeiter, die im internen Netz der Bank betrieben wird, entschlüsselt dann die Daten mit ihrem privaten Schlüssel. Diese Variante macht es einem Angreifer, der nur im Besitz des öffentlichen Schlüssels ist, unmöglich, die Serviceanfragen zu lesen und somit wertvolle Informationen zu erlangen.

Die Absicherung von Webapplikationen unerlässlich. Schon beim Design einer solchen Applikation kann durch eine asymmetrische Verschlüsselung ein höherer Sicherheitsstandard gewährleistet werden.

Lesen Sie im nächsten Teil unserer Serie, wie man sichere Webapplikationen programmiert.

Produktiver modular arbeiten dank OSGi Blueprint

QuellcodeDie Modularisierungsspezifikation OSGi hat zwar schon ein paar Jahre auf dem Buckel, trifft aber noch immer den Zahn der Zeit. Dies zeigt sich nicht zuletzt dadurch, dass Oracle für Java 8 ein ähnliches System namens Jigsaw plant. Doch während Jigsaw noch Zukunftsmusik ist, wird OSGi bei doubleSlash bereits fleißig eingesetzt.

Während der Einarbeitung in das Thema OSGi starten in der Regel alle Lernwilligen bei einfachen Services, die händisch registriert und abgefragt werden. Dies ist ein guter Weg, um das System kennenzulernen, artet aber im produktiven Einsatz sehr schnell aus. Um diese elementaren Funktionen zu erleichtern, lohnt es sich, einen Blick in die Enterprise-Spezifikation von OSGi zu werfen.

Unter dem Begriff „Blueprint“ findet man eine zeitgemäße Behandlung der Services: Dependency Injection!

Voraussetzung dafür ist eine lauffähige Implementierung des Standards, z.B. Apache Aries. Um einen neuen Service zu registrieren, wird zunächst eine XML Datei unter OSGI-INF/blueprint/ angelegt (Beispiel von aries.apache.org):

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
   <service id="serviceOne" ref="account" interface="org.apache.aries.simple.AccountInterface" />
   <bean id="account" class="org.apache.aries.simple.Account"/>
</blueprint>

Blueprint sorgt nun automatisch dafür, dass dieser Service im OSGi Container registriert wird.

Um diesen jetzt in einer Java Klasse (im Beispiel „AccountClient“) verwenden zu können, bedarf es folgender Konfiguration:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
   <bean id="accountClient" class="org.apache.aries.simple.AccountClient">
      <property name="account" ref="accountRef" />
   </bean>
   <reference id="accountRef" interface="org.apache.aries.simple.AccountInterface"/>
</blueprint>

Damit hat man bereits alles Nötige, um den Service verwenden zu können. Der Code wird entschlackt und die Testbarkeit der Anwendung deutlich verbessert. Natürlich bietet Blueprint noch einige weitere Features – beispielsweise die Handhabung von kurzfristig ausfallenden Services über Proxies, welches ein grundlegendes Problem in einer so dynamischen Umgebung ist.

Auch wenn die Fülle an Möglichkeiten Einsteiger etwas erschlagen kann, sollte man keine Scheu haben, früh einen Einblick jenseits der Kernspezifikationen zu wagen. Die Belohnung sind oft große Produktivitätszuwächse. Durch die Modularisierung der einzelnen Bereiche einer Software werden diese kleinen Teile automatisch wartbarer. Komplexität und Abhängigkeiten werden reduziert und dadurch langfristig auch die Kosten eines Projekts.

10 Erfolgsfaktoren für das Anforderungsmanagement in agilen Software-Großprojekten

Prozess_ScrumEine der Hauptaufgaben des Product Owners in agilen Softwareprojekten ist es, die Produktanforderungen mit dem Kunden abzustimmen und in sogenannten User Stories zu beschreiben. Diese werden dann von den Entwicklern Stück für Stück in Form von darin heruntergebrochenen Tasks umgesetzt. Nach jeder Entwicklungsiteration – dem Sprint – entsteht ein auslieferfähiges Ergebnis. Die Abstimmung der User Stories und Akzeptanzkriterien ist ein zentraler Prozess der agilen Entwicklungsmethodik, der in der Praxis meist mehrere Abstimmungschleifen durchläuft.

Was aber, wenn der Product Owner und sein Team nicht alleine an einem Softwareprodukt arbeiten, sondern 17 weitere Teams mit vielen Abhängigkeiten untereinander beteiligt sind? Wenn es auch viele Kunden mit konkurrierenden Zielen gibt, die teilweise international verteilt sind und zum Teil selbst große Softwareprojekte mit eigenen Zeitplänen repräsentieren? Dann wird das Anforderungsmanagement im Projekt zu einer besonderen Herausforderung auf dem Weg vom Wunsch zur Wirklichkeit.

Mit unseren Erfahrungen aus der agilen Entwicklung webbasierter Softwareanwendungen haben wir die 10 wichtigsten Erfolgsfaktoren zusammengefasst, damit das Anforderungsmanagement auch in agilen Großprojekten gut und effizient funktioniert:

1. Die Scrum-Rollen „Kunde“ und „Product Owner“ werden beide ausgefüllt.

In Filmsprache übernimmt der Kunde die Rolle des Produzenten und der Product Owner die Rolle des Drehbuchautors. Der eine fordert das Produkt an, der andere gestaltet es. In vielen Projekten werden diese beiden Rollen vermischt bzw. eine davon wird gar nicht gelebt. Das führt zu einem Vakuum bei der Entwicklung der Produkt-Vision und der fachlichen Prioritäten.

2. Der Kunde trägt die Produkt-und Release-Vision mit.

Die Produkt-Vision ist sowohl fachliche Klammer als auch Motivationsfaktor für die Teams. Deswegen ist es eine wichtige Aufgabe des Product Owners, diese Vision permanent dem Team zu vermitteln. Aber nur wenn der Kunde diese Vision voll mitträgt, wird das Produkt letztendlich seine Anforderungen treffen.

3. Die Teams kennen die übergreifende Produkt- und Release-Vision.

Die Teams sollen nicht nur die Vision für das eigene Team, sondern für das ganze Produkt kennen. Nur so verstehen sie sich als Teil des Ganzen und unterstützen im Bedarfsfall auch gerne andere Teams.

4. Der Kunde steht für das Review zur Verfügung.

Agile Projekte leben von einem ständigen Lernzyklus. Wird das Review vom Kunden nicht wahrgenommen, fehlt eine wichtige fachliche Feedbackschleife zum Produkt und damit zum Entwicklerteam.

5. Scrum of Scrum wird für Product Owner, Scrum Master und technische Architektur gelebt.

Wenn viele Scrum Teams an einem Produkt arbeiten, werden Product Owner und Scrum Master jeweils in eigenen Gruppen – im sogenannten Scrum of Scrum – organisiert. In diesen Gruppen werden teamübergreifende Fragen geklärt. Nur wenn das Konzept des Scrum of Scrum auch die technische Architektur umfasst, können softwarearchitektonische Inkonsistenzen verhindert werden.

6. Es gibt nicht zu viele Teams.1

Nach unserer Erfahrung sind mehr als 7 Teams in einem Projekt nicht effizient mit klassischen Scrum-Methoden steuerbar. Die Gruppe der Product Owner und Scrum Master überschreitet dann die optimale Teamgröße. In einem Software-Großprojekt ist allerdings oft eine größere Skalierung notwendig. In diesem Fall sind die Teams in einzelnen Zellen z.B. nach Features oder Produktkomponenten zu organisieren, um die Komplexität beherrschbar zu machen und die Teamgrößen immer übersichtlich zu halten.

7. Die Abhängigkeiten zwischen den Teams sind gering.

Starke Abhängigkeiten zwischen den Teams führen zu ungeplanten Anforderungen, die außerhalb des Backlogs vorbeigesteuert werden. Das ist Gift für eine effiziente Abarbeitung der User Stories und demotiviert die Teams.

8. Anforderungen von abhängigen Teams werden über die Product Owner eingesteuert.

Wenn sich größere Abhängigkeiten zwischen den Teams nicht vermeiden lassen, sind diese im Scrum of Scrum über die Product Owner einzusteuern. Das bremst zwar scheinbar die schnelle Hilfe für das Nachbarteam aus, sichert aber auf Dauer eine bessere Planbarkeit des Gesamtprojekts.

9. Es gibt ein übergreifendes Anforderungsmanagement für Großprojekte mit vielen Anforderern

Wenn es nicht mehr den einen Kunden gibt sondern viele Anforderer aus unterschiedlichen Initiativen und Projekten, dann ist für große strategische Anforderungen ein vorgeschaltetes Anforderungsmanagement sinnvoll. Nur so bekommen die Product Owner die Anforderungen mit ausreichender Stabilität und fachlicher Tiefe.

Die Aufgaben eines solchen Anforderungsmanagements sind:

a.    Sicherstellung der Ende-zu-Ende-Betrachtung der Anforderungen über alle Projekte hinweg.
b.    Prüfung der unternehmerischen Relevanz angeforderter Themen.
c.    Herbeiführung der Entscheidungen im Change Control Board.
d.    fachliche Aufbereitung von Themen für die Product Owner.
e.    Verdichtung der Sprintergebnisse und Schaffung von Transparenz über den Stand der Anforderungen für die anfordernden Projekte.

10. Das übergreifende Anforderungsmanagement ist Teil des Multiprojektmanagements bei sehr großen anfordernden Initiativen.

Das Multiprojektmanagement sorgt für die richtige Auswahl und den richtigen Schnitt der Projekte. Dazu leistet das übergreifende Anforderungsmanagement einen zentralen Beitrag, da es die verschiedenen Fachbereichsanforderungen aus Unternehmenssicht strategisch zusammenführt.

doubleSlash auf dem M2M Partner Event 2013 der Deutschen Telekom AG

20130926_125022

Der jährliche Partner Event des M2M Competence Centers der Deutschen Telekom ist mittlerweile eine Pflichtveranstaltung für die Branche. Das diesjährige Motto der Veranstaltung M2Mission possible“ verdeutlichte, dass die unzähligen Möglichkeiten im M2M Markt immer mehr zur Realität werden.

Dieses Jahr fand die Veranstaltung in Belgrad, Serbien statt. Im 25. Stock des USCE Towers wurde der Event erstmals, nicht wie gewohnt, mit Vorträgen auf einer Bühne abgehalten. Im Rahmen eines neuen innovativen Konzepts fanden die Präsentationen im gesamten Veranstaltungsgebiet statt, um eine bessere Interaktion mit dem Publikum zu ermöglichen.

Unter dem Titel „From Hightech to Hightouch“ hat dieses Jahr auch doubleSlash mit einer Breakout-Session eine aktive Rolle übernommen. Im Rahmen eines Vortrags zeigte Stefan Meyer, wie M2M dazu beiträgt Touchpoints zur kontinuierlichen Interaktion mit dem Kunden zu kreieren. doubleSlash zeigte, dass durch M2M ganz neue Möglichkeiten geschaffen werden, um während der Nutzungsphase im Produktlebenszyklus vom Anwender und seinem Verhalten zu lernen. Diese Erkenntnisse können wiederum in die Produktentwicklung einfließen, um Produkte zu entwickeln, die besser und nachhaltiger auf die Bedürfnisse der Kunden eingehen.

Neben uns engagierten sich auch vermehrt große IT-Unternehmen im M2M Bereich. Neben Marktführern wie Axeda (M2M Plattform) waren auch Microsoft und IBM vertreten und zeigten uns, dass nicht nur kleine und mittelständische M2M und IT Spezialisten den Markt angehen.

Aktuelle Trends

Nach spannenden Gesprächen sowie dem aktiven Ausbau unseres M2M Netzwerks konnten wir verschiedene aktuelle Trends beobachten. Einer davon ist das Fleet-Management, ein sehr spannendes Gebiet, dass insbesondere aus dem PKW Bereich neue Impulse erhalten hat. Neue technische Geräte ermöglichen hier günstige und einfache Dienste rund um Telematik-Herausforderungen.

Der Tag wurde dann ganz getreu dem Motto „M2Mission possible“ auf der Festung von Belgrad, mit einer klassischen Abendveranstaltung im Stile „James Bonds“ abgerundet.

Wir möchten uns herzlich für die gelungene Veranstaltung bei der Deutschen Telekom bedanken und freuen uns auch im nächsten Jahr als Partner wieder teilzunehmen.

Tracking von Firmenfahrzeugen mit Augenmaß

In letzter Zeit, macht in Zeitungen und Fernsehen, immer wieder das Thema Spionage und Datenschutz Schlagzeilen. Nun ist auch die Überwachung des Fahrverhaltens ins Auge der Datenschützer geraten. „Vehicle Tracking“ nennt sich die Überwachungstechnik für Fahrzeuge, welche die Ermittlung und Analyse von GPS Koordinaten, Bremsverhalten, Geschwindigkeit und vieler anderer Daten, in Echtzeit festhalten und übertragen kann.

Car-Tracking von Firmenfahrzeugen und Datenschutz

Wie funktioniert das?

Eine kleine Box, wie das CalAmp LMU 30001, wird mit dem Bordcomputer zur Erhebung der Daten gekoppelt. Eine Mobilfunkverbindung ermöglicht es dann, die Fahrzeugdaten, live und in Farbe, zu übertragen. Dabei kann das Sendeintervall, von wenigen Sekunden über Minuten, bis hin zu Stunden oder gar Tagen frei, eingestellt werden.

Die Juristen des ADAC stehen dem Ganzen kritisch gegenüber und halten das Vehicle Tracking für „[…] die totale Überwachung des Fahrverhaltens.“2  Während der ADAC und auch andere Datenschützer um die Privatsphäre der Fahrzeugführer fürchten, bringt die Tracking-Technik aber auch viele neue Chancen. Der „Pay as you drive“  – Tarif von Versicherungen gibt schon reichlich Zündstoff für Diskussionen, aber auch für Speditionen, Mietwagenflotten oder den Firmenfuhrpark bietet die relativ neue Technik vielversprechende Möglichkeiten, wie z.B. Carsharing oder ein elektronisches Fahrtenbuch.

Elektronische Fahrtenschreiber

In den letzten fünf Jahren wurde von der italienischen Allianz –Tochter Allianz Telematics, nach eigenen Angaben, bereits in mehr als 80.000 Fahrzeuge, elektronische Fahrtenschreiber eingebaut.3  In Baden-Württemberg gab es vor ein paar Jahren bereits zwei Testläufe, allerdings wurde das Projekt wieder auf Eis gelegt, da es noch zu viele Probleme bei der Zuverlässigkeit und dem Datenschutz gab.4  Viele dieser Probleme lassen sich inzwischen minimieren. So ist Zuverlässigkeit der Tracking-Box auf das Mobilfunknetz angewiesen und kann nur dann senden, wenn auch das Mobilfunknetz verfügbar ist. Hierfür können beispielsweise Pufferspeicher einsetzen, falls der Fahrer in einem Tunnel unterwegs ist und eine verspätete Sendung der Daten ermöglicht werden. Der Datenschutz hingegen ist immer noch eine Hürde für die Einführung.

Big Data Problem

Die Gefahr, dass die Daten ausgenutzt werden ist vorhanden, kann aber durch wenig Aufwand reduziert werden. Die Rohdaten, die während der Fahrt ermittelt und gesendet werden sind zu mächtig, um sie zu speichern und oder mit Personen in Verbindung zu bringen. Diese müsste man sammeln und aggregieren, wobei nur die aggregierten Daten übertragen werden. Zudem wäre eine Massenspeicherung der Rohdaten technisch kaum möglich, da bei rund 52 Mio. angemeldeter Kfz in Deutschland (stand 20125) jeder Server überlastet wäre. Weiter ist es für die Auswertung der Daten nicht zwingend nötig den Nutzer zu identifizieren. Dieser kann anonymisiert werden und erst nach der Auswertung wieder zugeordnet werden. Im Falle einer Versicherung würde dies bedeuten, dass zuerst nur die Daten einer ID empfangen und bearbeitet werden. Nach Analyse dieser Daten kann eine neue Prämie festgelegt werden, welche dann mittels ID wieder zugeordnet werden kann. Dadurch wäre die Ermittlung und Verarbeitung sensibler Personen bezogener Daten von der Person selbst getrennt.
Zusätzlich muss der Fahrer immer darüber informiert werden, welche Daten von ihm übermittelt werden, um diese einschränken zu können. Beispielsweise könnte man Daten wie Drehzahl und Durchschnittsgeschwindigkeit übermitteln, die exakte Route würde allerdings nicht übertragen werden und bleibt privat.
Und für den Fall, dass einmal nicht der Versicherte das Fahrzeug benutzt und die Daten nicht übermittelt werden sollen, muss es eine Möglichkeit geben, das Tracking zeitweise zu deaktivieren oder einzuschränken. Beispielsweise sollte man angeben können, ob gerade der Versicherungsnehmer selbst oder ein Dritter das Fahrzeug fährt. Bei einer Firmenflotte wäre es praktisch angeben zu können, ob die Fahrt privat oder geschäftlich ist.

Datenschutz bei Firmenfahrzeugen

Ein weniger kritischer Faktor ist der Datenschutz bei Mietwagen oder dem Firmenfuhrpark, solange der Bezug zwischen Fahrer und Fahrzeug nicht hergestellt wird. Durch das Vehicle Tracking kann der Zustand von Miet- oder Firmenwagen in Echtzeit abgerufen und somit auch das Fleetmanagement stark erleichtert werden. Zudem kann das Vehicle Tracking mehr Sicherheit und eine wirtschaftlichere Fahrweise ermöglichen, da der Flottenmanager jederzeit weiß, wo sich seine Fahrzeuge befinden und wie ihre Fahrer damit umgehen. Passend dazu gibt es bereits eine Lkw-Versicherung, die ihre Prämien anhand der erhobenen Daten ermittelt.

Neuen Antrieb erhält die Automobilbranche durch ein Notrufsystem, das den Namen eCall trägt. Nach einem Unfall, bei dem der Airbag ausgelöst wird, setzt eCall selbstständig einen Notruf mit aktueller Position des Unfallwagens an die Notrufzentrale ab. Dazu wählt sich das System mit einer eigenen SIM-Karte in das Mobilfunknetz ein und übermittelt die Daten. eCall soll, nach einer neuen EU Vorschrift, ab 2015, serienmäßig in jeden Neuwagen eingebaut werden.6 Für Mobilfunk- und Telematik-Dienstleister wäre dies ein großer Vorteil im Bezug auf die Einführung des Vehicle Trackings..

Um das Vehicle Tracking flächendeckend einzuführen und alle Fahrzeuge nach zu rüsten, ist die Hardware plus Mobilfunkvertrag aktuell noch zu teuer. In Zukunft wird deshalb das Trackingsystem bereits beim Herstellungsprozess in das Fahrzeug integriert, da dadurch der Produktionspreis nur geringfügig steigt (ca. 100€ pro Fahrzeug + Mobilfunkvertrag) und sich  damit kaum im Kaufpreis bemerkbar macht. Vielleicht wird diese Technik zusätzlich mit einer 2 Zwei-Wege-Kommunikation ausgestattet werden. Zum jetzigen Zeitpunkt agiert das Fahrzeug nur als Sender, wenn nun zusätzlich auch Daten Empfangen werden könnten, wäre eine Feedbackfunktion für analysierte Fahrzeugwerte möglich. So könnte der Druckverlust der Bremsleistung oder des Reifendrucks festgestellt werden. Daraufhin könnte der Fahrer via Bordcomputer angewiesen werden, eine Werkstatt aufzusuchen bevor das Unfallrisiko zu hoch für eine Weiterfahrt ist. Eventuell direkt mit den GPS-Daten zur nächsten Vertragswerkstatt.

Die Risiken für den Datenschutz lassen sich nicht wegdiskutieren. Um die Chancen der neuen Technologie zu nutzen, müssen diese auf ein akzeptables Maß reduziert werden. Eben mit Augenmaß.

1 Calamp,www.calamp.com/products/cellular-a-gps/fleet-tracking-units/lmu-3000-location-messaging-unit, 24.09.2013
2,4 ADAC Motorwelt, Achtung: Spion fährt mit, S. 39, 08/2013
3,6 Heise Online, http://heise.de/-1952865, 20.09.2013, 09.09.2013
4   Autokiste, Hanno Ritter, http://www.autokiste.de/psg/1201/9891.htm, 23.09.2013, 25.01.2012

doubleSlash Systemtechnik ITIL zertifiziert

doubleSlash Systemtechnik ITIL zertifiziertInnerhalb einer dreitägigen Schulung, mit abschließender Prüfung, hat sich unsere vierköpfige Systemtechnik in Form von Anna Bundy, Waldemar Gassmann, Philippe Haug und Philipp Schulz unter der Leitung eines ITIL-Expert zertifizierten Trainers weitergebildet und kann sich nun ITIL-Foundation zertifiziert bezeichnen.

ITIL steht für Information Technology Infrastructure Library und ist eine herstellerunabhänigge Sammlung von Best Practices, mit denen es IT-Organisationen über einen prozessorientierten skalierbaren Ansatz ermöglicht wird, Effizienzsteigerungen innerhalb ihrer IT-Prozesse zu erzielen und somit ihren Kunden einen gleich bleibenden IT Service zu liefern.Mehr…