Fallstricke bei der Berechnung von Verfügbarkeit … · BTS NR. 21 INHALT 3 EDITORIAL 4 BASIS-IT-SICHERHEITSANALYSE – Risikomanagement in KMUs 8 TEAMWORK – Das IT-Sicherheitsteam

ADACOR BRANCHENINFORMATION

AUSGABE 21 JULI 2014

NR. 21

Domain ManagementICANN sperrt mehr als 6,8 Millionen Domains

SicherheitEffektive Weiterbildung schützt vor Hackerangriffen

Cloudbase ProxySaaS für höchste Flexibilität, Skalierbarkeit und Performance

Fachbeitrag von Thomas Wittbecker, CEO ADACOR Hosting GmbH

Fallstricke bei der Berechnung von Verfügbarkeit

BTS NR. 21

INHALT

3 EDITORIAL

4 BASIS-IT-SICHERHEITSANALYSE – Risikomanagement in KMUs

8 TEAMWORK – Das IT-Sicherheitsteam der ADACOR

11 FACHBEITRAG – Thomas Wittbecker: Fallstricke bei der Berechnung von Verfügbarkeit

14 HACKATTACK – Systemadministratoren von ADACOR besuchen Hacking-Seminar

18 WEB VULNERABILITY SCANNER – Acunetix und Netsparker im Vergleich

22 KANBAN – Verknüpfung des Kanban-Tools mit der Helpdesk-Software OTRS

26 CLOUDBASE – Fortschrittsbericht

29 DOMAIN MANAGEMENT – ICANN sperrt mehr als 6,8 Millionen Domains

30 VERSCHLÜSSELUNGSTECHNIKEN II – E-Mail Verschlüsselung

34 HEARTBLEED BUG (OPENSSL) – Retrospektive aus Sicht der ADACOR

36 TEAMEVENTS – Gemeinsam auch mal abschalten!

39 ADACOR AKTUELL – UN Bericht II und Vorstellung von Mitarbeiter Marc Heinz

Effektive Weiterbildung schützt vor Hackerangriffen (ab Seite 14)

Systemadministratoren von ADACOR besuchen Hacking-Seminar

Liebe Leserinnen und Leser,

es wird nicht das letzte Mal gewesen sein: ein Hackerangriff auf eine bekannte Internetplattform. Erst Ende Mai rief das Online-Auktionshaus Ebay seine Nutzer zum Passwortwechsel auf, nachdem Hacker mithilfe gestohlener Mitarbeiter-Log-ins eine Kundendatenbank geknackt hatten. Die Aktion zeigt, dass nicht immer die Technik versagt. Manchmal handeln die Nutzer selbst fahrlässig – ob gewollt oder nicht. Unabhängig davon, wie genau die Hacker an die Log-in-Daten gekommen sind, eins ist klar: Sicherheit im Internet ist das höchste Gebot für jeden Nutzer – ob privat oder im Job.

Nun lauern nicht nur im Internet Gefahren, die uns vertrauliche Daten kosten können. Ebenso hat die Datensicherheit bei der Kommunikation via E-Mail eine hohe Relevanz. Welche genau, das erfahren Sie in unserem Artikel zur E-Mail-Verschlüsselung ab Seite 30.

Beim Schutz vor Hacking setzt die ADACOR als Teil ihres Sicherheitskonzepts auf die Weiterbildung ihrer Mitarbeiter. So besuchen die Systemadministratoren regelmäßig Hacking-Se-minare. Was dabei auf dem Lernplan steht, lesen Sie ab Seite 14.

Penetrationstests sind nicht nur fester Bestandteil jeder Ha-cking-Schulung, die ADACOR setzt auch im eigenen Unterneh-men auf entsprechende Tools zur Überwachung ihrer Systeme. Eine Maßnahme zum Schutz vor Angriffen umfasst die Überprü-fung von Internetseiten und –anwendungen auf Sicherheitslü-cken und Schwachstellen mittels Web Vulnerability Scanner. Die Softwareentwickler der ADACOR haben zwei Produkte getestet und berichten ab Seite 18 von ihren Ergebnissen.

Hackerangriffe und Datenklau bleiben uns in Zukunft 100-pro-zentig als sicherheitsrelevante Themen erhalten. Damit Sie für den Fall der Fälle gerüstet sind, versorgen wir Sie in dieser Ausgabe des ADACOR-Kundenmagazins mit zahlreichen Tipps zur Vorbeugung vor Hacking-Angriffen. Wir freuen uns, wenn Sie diese für sich nutzen können.

Wir wünschen Ihnen viel Spaß beim Lesen!

Ihre Kiki Radicke

expect more

KIKI RADICKE

Leitung Marketing ADACOR Hosting GmbH

IMPRESSUMHerausgeber:ADACOR Hosting GmbHEmmastraße 70 A 45130 Essen

Geschäftsführung:Thomas Wittbecker Andreas Bachman Patrick FendAlexander Lapp

Kontaktdaten:Telefon: +49 69 905089-0Telefax: +49 69 905089-29E-Mail: [email protected]: www.adacor.com

Chefredakteurin:Kiki Radicke, ADACOR

Redaktion:Josephine Alberts, HamburgCarla Breidenstein, Frankfurt

Bildnachweis:Stocksy istockphoto Thinkstock

© 2014 ADACOR

Design:kinoblau, Düsseldorfwww.kinoblau.de

Druck:Althoff Druck, Soestwww.althoff-druck.de

4 BTS NR. 21

Basis-IT-Sicherheitsanalyse

Risikomanagement in KMUs Kaum jemand wird bestreiten, dass Compliance-Anforderungen mehr und mehr auch in das Blickfeld kleiner und mittelgroßer Unternehmen (KMUs) rücken. Sei es durch rechtliche Vorgaben, wie das Bundesdatenschutzgesetz (BDSG), das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (KonTraG) und die Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS), oder durch Anforderung im Zuge spezieller Zertifizierungen, wie z. B. den Normen ISO 27001 (Informationssicherheit) oder IDW PS 951 (internes Kontrollsystem).

π Risikomanagement ist ein Thema, an dem auch kleine und mittelgroße Unternehmen in diesen Tagen nicht mehr vorbei-kommen. Denn all diese Gesetze, Verordnungen, Richtlinien und Normen beinhalten, dass ein Unternehmen ein aktives Risiko-management implementiert haben muss, wenn es seine Sorg-faltspflicht gegenüber seinen Mitarbeitern und Kunden ernst nehmen sowie eine wert- und erfolgsorientierte Unternehmens-führung etablieren will. Aber wie können KMUs auf einfache, effiziente und skalierbare Art und Weise ein Risikomanagement implementieren?

Aller Anfang ist schwer

Wenn man in seinem Unternehmen noch kein Risikomanagement eingeführt hat, scheint die Aufgabe erst einmal sehr komplex und man fragt sich, wie sich Risikomanagement „vernünftig“ imple-mentieren lässt. Schließlich sollten Aufwand, Kosten und Nutzen in einem angemessenen Verhältnis zueinander stehen. In einem solchen Fall liefern die Normen „ISO 31000 (Risikomanagement)“, „ISO 27005 (Information Security Risk Management)“ sowie die

Standards „Mindestanforderungen an das Risikomanagement (MaRisk)“ der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) und der „BSI-Standard 100-3 (Risikoanalyse)“ des Bun-desamtes für Sicherheit in der Informationstechnik (BSI) hilfrei-che Ansatzpunkte. Jeder dieser Standards hat in Bezug auf die Einführung eines aktiven Risikomanagements Vor- und Nachteile, die es generell abzuwägen gilt. Im Kontext unserer Suche nach einem geeigneten Risikostandard für die ADACOR Hosting GmbH haben wir diese Standards analysiert und auf brauchbare, einfach zu realisierende Ansatzpunkte hin untersucht und ausgewertet. Dabei haben wir letztlich ein Modell entwickelt, das sich an ISO 27005 und BSI 100-3 orientiert, aber über die reinen IT-Risiken hinaus nutzbar ist (z. B. auch in der Risikobewertung von Kunden-projekten und Lieferanten).

Nachfolgend stellen wir einen Ansatz vor, der kleinen und mittelgroßen Unternehmen einen einfachen und ressourcen-schonenden Einstieg in ein betriebliches Risikomanagement ermöglicht. Der Ansatz erhebt jedoch keinen Anspruch darauf, einen der vorgenannten Standards komplett zu erfüllen.

5

2.

Wie funktioniert Risikomanagement?

Will ein Unternehmen erfolgreich ein effizientes Risikoma-nagement implementieren, ist es von Anbeginn wichtig, die bestmöglichen Voraussetzungen für die Einführung des Instru-mentariums zu schaffen. Hierfür sollten alle mit der Implemen-tierung zusammenhängenden Aufgaben bereits im Vorfeld klar definiert und die entsprechenden personellen Verantwortlich-keiten zugewiesen werden. Sind diese Voraussetzungen erfüllt, dann ist Risikomanagement im Wesentlichen sehr einfach, denn es folgt immer dem gleichen Ablauf:

1. Firmenwerte identifizieren und Risikoszenarien zuordnen

2. Rahmenparameter definieren und Punktwerte festlegen

3. Risiken bewerten und Handlungsvorgaben differenzieren

4. Risikoanalyse durchführen und Gegenmaßnahmen definieren plus umsetzen

5. Wertaktualität überwachen und Prozesskontinuität sicherstellen

Firmenwerte identifizieren und Risikoszenarien zuordnen

Unter den Begriff „Firmenwert“ fällt alles, was für das Unter-nehmen für den Fortbestand des Geschäftsbetriebes relevant ist, wie z. B. Räume, Anwendungen, IT-Systeme, Prozesse, Personal, Lieferanten usw. Bei der Auflistung der Firmenwerte ist unbedingt auf Vollständigkeit zu achten. Es müssen alle Werte identifiziert werden, die potenziell einem Risiko aus-gesetzt sind und somit Einfluss auf den Geschäftsbetrieb nehmen können. Die vollständige Firmenwertliste bildet das Fundament eines tragfähigen Risikomanagements.

Dann gilt es, einen Katalog von Risikoszenarien (z. B. Feuer, Überschwemmung etc.) zu erstellen, denen die Firmenwer-te ausgesetzt sind. Um hier nicht bei null anfangen zu müs-sen, legten wir bei ADACOR die Elementargefährdungen aus den Gefährdungskatalogen des BSI zu Grunde. Diese ent-halten 47 Risikoszenarien von Feuer über Verschmutzung bis Ressourcenmangel und stellen einen guten Grundstock dar, der ggf. individuell, problemlos und ohne viel Aufwand erweitert werden kann.

Rahmenparameter definieren und Punktwerte festlegen

Um einen Rahmen zu schaffen, der es ermöglicht, Risiken angemessen zu bewerten, müssen zuerst die Parameter des Rahmens definiert werden. Dabei wird Risiko klassisch gemäß der Formel berechnet: Risiko = Häufigkeit x Schaden.

Damit bei der Risikoanalyse später jede einzelne Risi-kobewertung nachvollziehbare, gleichbleibende Ergebnisse hervorbringt, müssen für die Parameter Häufigkeit und Schaden verschiedene Stufen festgelegt und sogenannte Punktwerte vergeben werden. Konkret gestaltet sich das bei den einzelnen Parametern wie folgt:

Häufigkeit

Für die Häufigkeit, mit der ein Schadensszenario potentiell eintreten kann, unterscheiden wir hier bei ADACOR drei Stu-fen, denen wir entsprechende Punktwerte zugeordnet haben:

› Hoch – täglich bis wöchentlich (3 Punkte)

› Mittel – monatlich bis jährlich (2 Punkte)

› Niedrig – seltener als jährlich (1 Punkt)

Relevant ist hierbei die tatsächliche Häufigkeit, mit der das Ereignis zu erwarten ist. Wenn während des 10-jährigen Bestehens des Standortes z. B. der nahegelegene Fluss noch nie über die Ufer getreten ist, kann dieses Szenario nur mit „Niedrig“ bewertet werden. Dass er potentiell jedes

Jahr im Frühjahr übertreten könnte, rechtfertigt keine Ein-stufung auf „Mittel“.

Schaden

Bei der Einschätzung der Folgen eines Schadens stützen wir uns auf die im BSI 100-3 Standard vorgeschlagenen Stufen:

› Niedrig – keine Folgen (1 Punkt)

› Mittel – geringe Folgen (2 Punkte)

› Hoch – hohe Folgen (3 Punkte)

› Sehr hoch - existenzbedrohende Folgen (4 Punkte)

Allerdings können Schäden in verschiedenen Bereichen eines Unternehmens in sehr unterschiedlicher Qualität entstehen. Um dies in die Risikoanalyse mit einzubeziehen, müssen zusätzlich die Auswirkungen auf die potenziell beeinträchti-gen Bereiche für jede Schadensstufe detailliert beschrieben werden. Denkbar sind z. B. Auswirkungen in Bezug auf:

› 1. Gesetze, Vorschriften, Verträge › 2. Selbstbestimmungsrecht › 3. Unversehrtheit › 4. Aufgabenerfüllung › 5. Innen-/Außenwirkung › 6. Finanzen

1.

6 BTS NR. 21

Schadstoffstufe: Niedrig

Bereich Schadensdefinition

› Gesetze,Vorschriften, Verträge

› Verstöße gegen Verträge, Vorschriften und Gesetze sind nicht zu erwarten bzw. ohne Folgen.

› Selbstbestimmungs- recht

› Es ist keine Beeinträchtigung des informationellen Selbstbestimmungsrechts zu erwarten.

› Unversehrtheit › Es ist keine Beeinträchtigung zu erwarten.

› Aufgabenerfüllung › Die Beeinträchtigung würde von den Betroffenen als tolerabel eingeschätzt werden.

Die maximal tolerierbare Ausfallzeit des IT- Systems ist größer als 72 Stunden.

› Innen-/Außenwirkung › Es ist keine bzw. nur eine geringe interne Ansehens- oder Vertrauensbeeinträchtigung

zu erwarten.

› Finanzen › Der finanzielle Schaden ist kleiner als 5.000,- €.

HÄUFIGKEIT

SCHADEN NIEDRIG MITTEL HOCH

NIEDRIG 1 2 3

MITTEL 2 4 6

HOCH 3 6 9

SEHR HOCH 4 8 12

X › Risiko wird akzeptiert, keine weitere Behandlung.

(Punktzahl 1-2)

X › Risiko muss behandelt werden. Risiko kann akzeptiert

werden (Punktzahl 3-7)

X › Risiko muss behandelt werden. Risiko kann nicht

akzeptiert werden. (Punktzahl 8-12)

HÄUFIGKEIT

SCHADEN NIEDRIG MITTEL HOCH

NIEDRIG 1 2 3

MITTEL 2 4 6

HOCH 3 6 9

SEHR HOCH 4 8 12

Risiken bewerten und Handlungsvorgaben differenzieren

Aus den oben beschriebenen Definitionen für Schaden und Häufigkeit lässt sich jetzt entsprechend der Formel (Risiko = Häufigkeit x Schaden) die entsprechende Risikomatrix folgern:

In Bezug auf den Umgang mit den einzelnen Risiken ist die-se Matrix jedoch leider noch nicht aussagekräftig genug. Denn was bedeutet es nun, wenn ein spezifisches Risiko (z. B. ein Blitzschlag) den Wert 2 hat? Um aus den Werten eine konkrete Handlungsanweisung ableiten zu können, müs-sen noch dazugehörige Handlungsvorgaben unterschieden und konkreten Punktzahlen zugewiesen werden. So kann

die unternehmensspezifische „Risikotoleranz“ individuell abgebildet werden.

Die Grundlage für die Implementierung eines Risikoma-nagements ist hiermit gelegt. Nun geht es an die eigent-liche Risikoanalyse.

3.

Die genauen Schadensdefinitionen je Schadensstufe müssen für jedes Unternehmen individuell formuliert werden, denn hier kann es zu signifikanten Unterschieden kommen. Man vergegenwärtige sich nur einmal, dass z. B. in der Schadens-

stufe „Sehr hoch“ das eine Unternehmen ab einer Schadens-summe von 5.000.000 EUR existenziell gefährdet ist, ein anderes jedoch möglicherweise bereits ab einer Summe von 500.000 EUR.

Nachfolgend sehen Sie, wie die detaillierte Schadensdefinition beispielsweise für die Schadensstufe „Niedrig“ aussehen könnte.

7

ANDREAS BACHMANN

Geschäftsführer I CIO

ADACOR Hosting GmbH

Kaiserleistraße 51

63067 Offenbach am Main

TELEFON +49 69 905089-22

TELEFAX +49 69 905089-29 E-MAIL [email protected]

INTERNET www.adacor.com

Risikoanalyse durchführen und Gegenmaßnahmen definieren plus umsetzen

Für die konkrete Durchführung der Risikoanalyse reicht es für den ersten und einfachen Einstieg, die drei bereits genannten Schritte (Firmenwerte identifizieren, Risikosze-narien zuordnen und Risiken bewerten) in einer schlichten Excel-Tabelle abzubilden.

Mithilfe dieser Risikoanalyse sehen Sie anhand des zuge-wiesenen Risikowerts direkt, wo der größte Handlungs-

bedarf besteht, und können entsprechende Maßnahmen einleiten, um das Risiko zu senken. Die einzelnen Maß-nahmen - die in der Liste als zusätzliche Spalten gepflegt werden können - sollten dann entweder die Häufigkeit und/oder den Schaden verringern und im normalen Aufgaben-management der Firma verankert sein. Die tatsächliche Umsetzung ist entsprechend zu überwachen.

Wertaktualität überwachen und Prozesskontinuität sicherstellen

Risikomanagement wird als ein fortlaufender zirkulärer Prozess verstanden, in dem Planung, Umsetzung, Überwa-chung und Verbesserung kontinuierlich stattfinden. Dies in Verbindung mit der Tatsache, dass Unternehmen sich im ständigen Wandel befinden und ggf. auch kurzfristig auf sich verändernde Anforderungen reagieren können müssen, verdeutlicht, weshalb es in demselben Maße für eine systematische und fundierte Risikoanalyse wichtig ist, die einzelnen Bestandteile regelmäßig auf ihre Aktualität und Stimmigkeit hin zu kontrollieren. Hinzu kommt, dass sich im Laufe der Zeit möglicherweise auch die Risiko-toleranz eines Unternehmens verändert. Die Stufen der

Rahmenparameter und die dazugehörigen Punktwerte, die Schadensdefinitionen, die Risikobewertungen und die Handlungsanweisungen müssen daher konsequent und fortlaufend validiert werden.

Um eine permanente Überwachung der Werte und Prozesse sicherzustellen, hat es sich für die ADACOR Hosting GmbH als gut in den Arbeitsalltag integrierbarer Weg erwiesen, jeden Monat turnusmäßig nur eine bestimmte Anzahl von Firmenwerten zu prüfen, anstatt die gesamte Analyse an einem Stück durchzuführen.

4.

5 .

FazitEin einfaches Risikomanagement, das den Ressourcen und Anforderungen kleinerer und mittlerer Firmen ge-recht wird, ist – das haben wir am Beispiel der ADACOR Hosting GmbH gezeigt - mit vertretbarem Aufwand implementierbar und liefert wertvolle Einsichten in das Risikoprofil des eigenen Betriebes. Für ein möglichst realistisches Abbilden der Risiken in einem anderen Unternehmen ist es jedoch unerlässlich, den vorge-stellten Ansatz der ADACOR mit Blick auf das eigene Unternehmen zu überprüfen und dort wo notwendig ggf. zu erweitern oder zu modifizieren.

8 BTS NR. 21

KUNDE

RECHENZENTRUM

INFRASTRUKTUR - TEAM

MANAGEMENT

IT-SICHERHEITS- TEAM

ENTWICKLUNGS- TEAMBETRIEBSTEAM

9

Die Teams der ADACOR

Das IT-Sicherheitsteam: Bindeglied in der Daten-sicherheit zwischen strategischer Planung und operativer Umsetzung

Insgesamt vier Teams stellen den reibungslosen Betrieb der verschiedenen Kundenprojekte sicher. Drei davon – das Infrastruktur-, Betriebs- und Entwicklungsteam – haben wir Ihnen bereits vorgestellt. Last but not least wollen wir in dieser Ausgabe nun die Aufgaben des IT-Sicherheitsteams näher betrachten und damit unsere Reihe „Die Teams der ADACOR“ abschließen. Das IT-Sicherheitsteam arbeitet eng mit dem IT-Sicherheitsbeauftragten zusammen und bildet in Bezug auf alle sicherheitstechnischen Fragen quasi die Schnittstelle zwischen strategischer Planung und operativer Umsetzung.

π Ursprünglich entstanden ist das IT-Sicherheitsteam im Zuge der aufkommenden Zertifizierungsthematik nach ISO 27001 sowie vor dem Hintergrund der immer wieder öffent-lich diskutierten Thematik des Datenschutzes in Deutschland. „Sicherheitstechnische Fragestellungen sind für ein Unterneh-men wie ADACOR von essentieller Bedeutung“, erklärt Andreas Bachmann, Geschäftsführer und IT-Sicherheitsbeauftragter des Unternehmens. „Unsere Kunden müssen sich 100-prozentig darauf verlassen können, dass ihre Anwendungen vor unberech-tigten Zugriffen geschützt sind und Daten in keiner Weise von Unbefugten gelesen oder gar manipuliert werden können. Das Thema Sicherheit ist also für unsere Kunden und somit auch für die ADACOR Hosting GmbH ein kritischer Erfolgsfaktor.“

ADACOR hat deshalb verschiedene Maßnahmen ergriffen, um die Themen Datenschutz und Datensicherheit sowohl auf der strategisch-organisatorischen Ebene als auch im operati-ven Tagesgeschäft systematisch und strukturell zu verankern. Bereits seit 2010 organisiert und implementiert die ADACOR das Thema Sicherheit mithilfe eines Datenschutzbeauftragten, dem IT-Sicherheitsbeauftragten und dem IT-Sicherheitsteam. Die Aufgaben sind klar verteilt. Während der Datenschutzbe-auftragte des Unternehmens die Verfahren und Prozesse mit personenbezogenen Daten überprüft und sicherstellt, dass die Vorgaben des Bundesdatenschutzgesetzes (BDSG) eingehalten werden, zeichnet der IT-Sicherheitsbeauftragte für Planung und Koordinierung der technischen und organisatorischen IT-

Sicherheitsmaßnahmen im Unternehmen verantwortlich. Er legt die notwendigen Verantwortlichkeiten fest und erarbeitet konkrete Handlungsanweisungen und Maßnahmen.

Primäre Aufgabe des IT-Sicherheitsteams ist es in diesem Kontext, dem IT-Sicherheitsbeauftragten zuzuarbeiten, d. h., es versorgt den IT-Sicherheitsbeauftragen mit den nötigen Informationen aus den Abteilungen. Dies ist nicht nur für die Analyse des Bedarfs wichtig, sondern auch für die konkrete Planung und Initiierung von Sicherheitsmaßnahmen. Aber das Team leistet mehr als nur Rapport. Es unterstützt zudem die operative Implementierung von Maßnahmen und kommuniziert die Neuerungen rund um das Thema Sicherheit zu den einzelnen Mitarbeitern in den jeweiligen Abteilungen. Hierdurch leistet das Team einen wesentlichen Beitrag zur kontinuierlichen Verbes-serung aller sicherheitsrelevanten Prozesse und Kommunikati-onswege. Außerdem führt es interne Audits, Systemprüfungen und Protokollkontrollen durch und verfolgt die einzelnen Sicher-heitsvorfälle. Hierdurch unterstützt das Team aktiv die Imple-mentierung eines professionellen Risikomanagements und füllt das ADACOR-Sicherheitskonzept mit Leben.

Eine weitere wichtige Aufgabe des Teams besteht in der Administration von sicherheitskritischen und schutzbedürftigen Systemen (z. B. Buchhaltungssysteme oder andere Systeme mit Personendaten). Diese werden nicht vom Betriebsteam als Gesamtes gemanagt, sondern vom IT-Sicherheitsteam sowie speziell für diese Fälle berufenen Systemadministratoren iso-

BTS NR. 2110

Verantwortlichkeiten rund um das Thema Sicherheit

WER … … MACHT WAS?

DATENSCHUTZBEAUFTRAGTE - Kontrolle der Verfahren und Prozesse mit personenbezogenen Daten und Sicherstellung, dass die Vorgaben des BDSG eingehalten werden

IT-SICHERHEITSBEAUFTRAGTE - Planung und Konzeption der IT-Sicherheitsorganisation, Maßnahmen, Richtlinien und Verantwortlichkeiten

IT-SICHERHEITSTEAM - Bereitstellung von sicherheitsrelevanten Informationen aus den einzelnen Teams- Unterstützung des IT-Sicherheitsbeauftragten bei der Bedarfsanalyse,

Planung, Initiierung und Umsetzung von sicherheitssteigernden Maßnahmen- Administration sicherheitskritischer Systeme

liert betreut. Auch in Bezug auf die Entwicklung hat ADACOR ein Sicherheitsnetz eingezogen. So haben die regulären Entwickler keinen Zugriff auf kritische Produktivsysteme der ADACOR. Hier wurden ebenfalls drei speziell verpflichtete Mitarbeiter abgestellt, die über exklusiven Zugriff auf die Produktivsysteme verfügen und sich um das Deployment, sprich die Softwarever-teilung kümmern.

Das IT-Sicherheitsteam setzt sich bei der ADACOR aus den drei Geschäftsführern der operativ-technischen Bereiche Betrieb, Entwicklung und Infrastruktur, den dazugehörigen Teamleitern und einem Systemadministrator zusammen. Bei allen Beteiligten handelt es sich um langjährige Mitarbeiter, die in puncto Geheimhaltung und Verantwortlichkeiten gesondert verpflichtet wurden. Das Team trifft sich einmal im Monat und bespricht aktuelle Vorfälle, den Stand unterschiedlicher Maß-nahmen, fortlaufende Verbesserung und geplante Projekte. Typische Projekte sind z. B.:

› Die Implementierung eines neues Passwort-Safes

› Die Aufnahme neuer Systeme in die bestehenden Überwachungsverfahren

› Evaluierung neuer Software- und Sicherheitssysteme

› Organisatorische Maßnahmen zur Erhöhung der Awareness für die IT-Sicherheit

„Wir ziehen einen Großteil unserer Motivation daraus, unseren Kunden und ihren Projekten die bestmöglichen Rahmenbe-dingungen in Bezug auf die Sicherheit anbieten zu können, und nehmen unsere Sorgfaltspflicht diesbezüglich sehr ernst. Unserem hohen Sicherheitsanspruch kommen wir u. a. durch deutsche Rechenzentrumsstandorte und der Orientierung an etablierten Sicherheitsstandards wie ISO 27001 und 22301 sowie COBIT (einem international anerkannten Framework zur IT-Governance) nach. Denn nur durch die enge Verzahnung und Kombination von verschiedenen Konzepten können wir den kom-plexen Anforderungen an die Sicherheit Rechnung tragen und wir unseren Kunden heute und in Zukunft ein Höchstmaß an Sicher-heit garantieren“, fasst Andreas Bachmann abschließend das Sicherheitsverständnis der ADACAOR Hosting GmbH zusammen.

ANDREAS BACHMANN


ADACOR Hosting GmbH

Kaiserleistraße 51


TELEFON +49 69 905089-22

TELEFAX +49 69 905089-29 E-MAIL [email protected]


11

Fachbeitrag von Thomas Wittbecker, CEO ADACOR Hosting GmbH

Fallstricke bei der Berechnung von Verfügbarkeiten

In der Praxis werden im Rahmen von Service Level Agreements (SLAs) häufig Aussagen zu Verfügbarkeiten gemacht, die technisch nicht verifiziert sind. Der folgende Beitrag zeigt anhand konkreter Beispiele, wie sich Verfügbarkeiten genau berechnen lassen.

π Während der Angebotsphase stellt sich bei unseren Hosting-projekten häufig die Frage nach der Verfügbarkeit einzelner Services. In meinen Gesprächen mit den Kunden stelle ich dann häufig fest, dass die konkrete Vorstellung von Verfügbarkeit recht vage ist.

Meistens wird die Verfügbarkeit eines Services mit einer Prozentzahl beschrieben. Dabei wird jedoch häufig außer Acht gelassen, dass bei der Berechnung dieser Prozentzahl, die dann in den Service Level Agreements (SLA) festgeschrieben wird, einige Fallstricke lauern.

Solche Fallstricke sind beispielsweise der Bezugspunkt der Berechnung der Ausfallzeiten (Jahr oder Monat), die Definition des zugrundeliegenden Services (Server, Firewall, Netzanbin-dung) oder die potentielle Verknüpfung von Verfügbarkeiten.

Wie lässt sich die Verfügbarkeit von IT-Plattformen sinnvoll berechnen?

Häufig bekommen wir Anfragen mit der Aussage “Wir hätten gerne einen Server mit der Verfügbarkeit von z. B. 99,5 %.”

OK, dann nehme ich das einfach so in ein Angebot auf, unter-stelle es ist pro Jahr gemeint und bezieht sich ausschließlich auf den Server.

Was dem Kunden jetzt wahrscheinlich nicht klar ist, ist, dass der Server durchaus einen ganzen Tag am Stück ausfallen kann und die Verfügbarkeit trotzdem eingehalten wird. Oder,

12 BTS NR. 21

Verfügbarkeit (Prozentual)

Minimale erwartete Verfügbarkeit (Stunden)

Maximale erlaubte Ausfallzeit (Stunden)

99 % 8672,4 87,6

99,1 % 8681,16 78,84

99,2 % 8689,92 70,08

99,3 % 8698,68 61,32

99,4 % 8707,44 52,56

99,5 % 8716,2 43,8

99,6 % 8724,96 35,04

99,7 % 8733,72 26,28

99,8 % 8742,48 17,52

99,9 % 8751,24 8,76

99,99 % 8759,124 0,876

dass die Verfügbarkeit des Servers nicht berührt ist, wenn die Firewall oder die Netzanbindung weg ist, der Server noch läuft, aber von außen nicht mehr erreichbar ist.

Berechnung der Ausfallzeiten

Eine gute Übersicht darüber, wie sich die prozentuale Verfügbar-keit eines Services in der Praxis auswirkt, bekommt man mit einer Tabelle der auf das Jahr gerechneten möglichen Ausfallzeiten.

Alternativ kann man die Verfügbarkeit bei kritischen Projekten auch auf den Monat bezogen angeben. Z. B. 99,9 % Verfügbar-keit auf den Monat gerechnet, bedeutet einen Maximalausfall von 43:48 Min./Monat.

Wenn man über die Verfügbarkeit eines Services spricht und prozentual ausdrückt, muss man sich also überlegen, ob man mit der maximal möglichen Ausfallzeit leben kann.

Eine weitere Variante ist es, zusätzlich die maximale Aus-falldauer zu beschränken. Gerade bei nicht ganz so kritischen Projekten kann es sein, dass zwei oder drei Ausfälle pro Jahr nicht ins Gewicht fallen. Sie sollten jedoch nicht länger als vier Stunden am Stück dauern. Also definiere ich z. B. 99,5 % Ver-fügbarkeit pro Jahr bei maximal vier Stunden Ausfall am Stück.

Worauf bezieht sich die Verfügbarkeit konkret?

Eine weitere Quelle von Missverständnissen ist die Definition des Services. Nehmen wir an, einem Kunden wird die Verfügbarkeit eines Servers garantiert und er lässt von einer Webagentur eine Website auf diesem Server betreiben. Aus der Sicht des Betrei-bers ist der Server solange verfügbar, wie er einwandfrei läuft. Das kann auch dann der Fall sein, wenn der Webserver aus ir-gendeinem Grund kein http mehr ausliefert. Sprich, die Website nicht mehr erreichbar ist.

Aus Kundensicht ist der Server dann aber nicht mehr verfügbar, weil seine Website weg ist. Da aber eine Agentur die Website betreibt und auch für die Konfiguration zuständig ist, kann der Hoster keine Verfügbarkeit oberhalb des reinen Be-

triebssystems garantieren. Als Webagentur oder Softwaredienstleister, die als General-

unternehmer gegenüber dem Kunden auftreten, ist zu beachten, dass die SLAs des Hosters nicht einfach an den Kunden für das Gesamtsystem weitergegeben werden können. Die Ausfallrisiken auf Appllikationsebene müssen ebenfalls bestimmt werden und zu den Ausfallrisiken von Seiten des Hosters hinzugerechnet werden.

Dieses Beispiel zeigt, dass es wichtig ist, sich genau darüber zu verständigen, worauf sich die Verfügbarkeit bezieht.

Aus Kundensicht ist es am sinnvollsten, wenn die Verfügbarkeit des kompletten Dienstes, der betrieben werden soll, vereinbart wird.

Dies ist bei etwas komplexeren Projekten allerdings nicht mehr so einfach. Häufig wird hier dann ein Kompromiss geschlossen und der Dienstleister garantiert die Verfügbarkeit des gesamten Projektes, so wie der Kunde es möchte, aber eigentlich weiß zu diesem Zeitpunkt niemand, wie hoch die Verfügbarkeit wirklich ist.

Einflüsse bei der Verknüpfung von Verfügbarkeiten

Wenn wir über die Verfügbarkeit eines kompletten Dienstes reden, müssen wir uns Gedanken über die Verknüpfung und die Abhängigkeiten von verschiedenen Verfügbarkeiten machen.

Ein kompletter Dienst setzt sich meistens aus mehreren Services zusammen. Ein einfaches Beispiel ist unsere hoch-verfügbare VMware-Umgebung. Durch die Möglichkeiten, die VMware in verteilten Umgebungen bietet, haben wir bei den einzelnen virtuellen Servern eine sehr hohe Verfügbarkeit. Die Verfügbarkeit liegt in etwa bei 99,99 % auf das Jahr. Dabei ist allerdings zu beachten, dass bei der Miete einer nackten VMware- Resource die Verfügbarkeit der laufenden Projekte auch noch von anderen Faktoren beeinflusst wird.

› 1. Die Verfügbarkeit bezieht sich nur auf die virtuelle Hardware. Bei einem Ausfall eines VMware-Knotens ist die virtuelle Hardware durch die Redundanzen und die Failover-Technologien innerhalb weniger Minuten wieder verfügbar. Nun booten die Server bei einem Failover einmal neu. Je nach Installation kann es einige Zeit dauern, bis alle Dienste wieder verfügbar sind. Dies ist dabei nicht in der Verfügbarkeit der VM abgebildet.

› 2. Die Verfügbarkeit der Applikationen auf dem virtuellen Server hängt in der Regel nicht nur von der virtuellen Hardware, sondern auch von der Verfügbarkeit des internen und externen Netzes ab.

In unserem Beispiel sind beide mit ebenfalls 99,99 % sehr hoch verfügbar. Die für den Kunden aber letztendlich absolute Ver-fügbarkeit von Applikationen kann dabei maximal nur bei 99,97 liegen.

Bei der Verknüpfung von Verfügbarkeiten reden wir von einer Addition des Ausfallrisikos. Bei einer Verfügbarkeit von

13

99,99 % liegt diese bei 0,01 %. Haben wir drei Services, die für die Gesamtverfügbarkeit verfügbar seien müssen, haben wir ein Ausfallrisiko von 3 x 0,01 % = 0,03 % Das ergibt eine Gesamtver-fügbarkeit von 100 % – 0,03 % = 99,97 %.

Wenn in unserem Beispiel noch Risiken aus den betriebenen Applikationen hinzukommen, wird die realistische Verfügbarkeit einer Applikation auch unter optimalen Bedingungen sicher nicht über 99,95 % liegen.

Redundanzen erhöhen die Verfügbarkeit Im umgekehrten Falle erhöhen wir die Verfügbarkeit über Redundanzen. Das funktioniert rechnerisch so: Habe ich zwei Systeme, die das gleiche leisten und jeweils eine Ver-fügbarkeit von 98 % haben und sich sofort voll ersetzen können, multipliziere ich die Ausfallrisiken miteinander 0,02 x 0,02. Denn es kommt nur zu einem kompletten Aus-fall, wenn die zweite Ressource ebenfalls zur gleichen Zeit wie die erste Ressource ausfällt. Daher ergibt sich die hohe Verfügbarkeit von 99,9996 %.

Die Tücke liegt jetzt in der praktischen Umsetzung. Wenn wir in diesem Beispiel über Dateien reden, die in zwei unterschiedlichen Rechenzentren liegen (z. B. Sicherheits-kopien) und diese nicht abgeglichen oder verändert werden müssen und der Zugriff völlig unabhängig erfolgen kann, dann hat man eine Verfügbarkeit von 99,9996 % auf diese Daten. Das passiert in der Praxis allerdings sehr selten.

Ein typischer Einsatz von Redundanzen ist z. B. ein Datenbank-Cluster. Um die Verfügbarkeit eines Daten-bankservers zu erhöhen, wird ein zweiter Server daneben gestellt. Gehen wir hier von einer einfachen Aktiv/Passiv-Lösung aus. Wenn der aktive Datenbankserver ausfällt, übernimmt der passive und wird zum aktiven. Damit das Konstrukt funktionieren kann, müssen die Daten kontinu-ierlich synchronisiert werden. Dieser Prozess ist nun aber selber eine Fehlerquelle und bringt eine zusätzliche Aus-fallwahrscheinlichkeit für das System mit. Außerdem be-nötigt man einen Failover-Mechanismus, der den Übergang von dem einen auf den anderen Server regelt. Auch dieser hat wieder eine Ausfallwahrscheinlichkeit. Dazu kommen noch Ausfallrisiken, die durch die gemeinsame Umgebung geprägt sind: Stromversorgung, internes und externes Netz, Klima usw.

Man sieht hier, dass die Bestim-mung der wirklichen Verfügbarkeit der redundanten Lösung alles andere als trivial ist.

Im nächsten Schritt kann man dann sagen, wir packen den zweiten Server in ein anderes Rechenzentrum und haben damit eine viel höhere Verfügbarkeit, weil die ge-meinsamen Risiken dann entfallen. Dies ist grundsätzlich richtig, aber die Synchronisation der Daten wird erheblich schwieriger, da es zwischen den beiden Rechenzentren zu Latenzen kommt. Außerdem muss die Verbindung zwischen den beiden Rechenzentren absolut stabil sein. Kommt es

jetzt zu kleinen Problemen, weil die Verbindung abbricht oder die Latenzen zu groß sind, hat das wieder massive Auswirkungen auf die Verfügbarkeit der Lösung.

Gerade bei großen Datenbank-Clustern, die als zentra-le Lösung für Unternehmensdatenbanken dienen, kann es sein, dass die höhere Verfügbarkeit mittels Redundanzen durch eine deutlich höhere Komplexität der Gesamtarchi-tektur und den dadurch entstehenden Fehlern konterkariert wird. Im Problemfall kann die Fehlersuche bei einer großen und komplexen zentralen Lösung sehr viel länger dauern, als bei einfachen Architekturen. Das kann zu längeren Ausfällen und somit zu einer schlechteren Verfügbarkeit führen, auch wenn die Lösung redundant ausgelegt ist.

Umgang mit SLAs

In der Praxis werden häufig im Rahmen von SLAs Aussagen zu Verfügbarkeiten gemacht, die technisch nicht verifiziert sind. Die gelten in der Praxis dann nur solange, wie alles rund läuft, und sind nicht an Worst-Case-Szenarien aus-gerichtet. Als Kunde muss man sehr genau hinterfragen, unter welchen Bedingungen die Verfügbarkeit gilt und welche Risiken berücksichtigt werden. Katastrophensze-narien werden häufig nicht mit berücksichtigt. Sollte eine Flugzeug auf das Rechenzentrum stürzen, hat man keine 99,9 % Verfügbarkeit mehr, sondern eher für lange Zeit einen 100 % Ausfall. Zugegeben, das passiert auch selten, genauso wie starke Erdbeben in Deutschland oder Terror-angriffe. Aber man muss im Hinterkopf haben, dass solche Totalausfallrisiken nicht abgedeckt sind. Es sei denn, der Anbieter betreibt das Projekt komplett verteilt an zwei Standorten, was in der Regel im Standard aus Kostengrün-den nicht gemacht wird.

Häufig werden SLAs auch einfach aus einer kaufmän-nischen Überlegung heraus definiert und der Anbieter lebt damit, dass bei jedem x-ten Kunden die SLAs nicht eingehalten werden können. Solange keine empfindlichen Vertragsstrafen vereinbart sind, ist das meistens kein großes Problem für den Anbieter. Insofern ist immer zu hinterfragen, wie belastbar die SLAs in der Praxis sind.

THOMAS WITTBECKER

Geschäftsführer I COO

ADACOR Hosting GmbH

Kaiserleistraße 51


TELEFON +49 69 905089-24

TELEFAX +49 69 905089-29

E-MAIL [email protected]


14 BTS NR. 20

Effektive Weiterbildung schützt vor Hackerangriffen

Hackattack - Systemadministra- toren von ADACOR besuchen Hacking-Seminar

Weiterbildung zahlt sich aus! Für Mitarbeiter und Unternehmen. Daher bietet die ADACOR nicht nur ihren Angestellten vielseitige Möglichkeiten zur beruflichen Weiterentwicklung, sondern setzt selbst auf qualifiziertes Personal. Z. B. in der IT-Sicherheit. Damit die Administratoren die Systeme und Netzwerke bestmöglich schützen können, müssen sie diesbezüglich stets auf dem neuesten Stand der Technik sein. In diesem Zusammenhang spielt das Thema „Absicherung vor Hacking“ eine wichtige Rolle, sodass die ADACOR Ende 2013 zwei Mitarbeiter zum Hacking-Pro-Seminar der Hackattack IT Security GmbH entsandte. Dieser Artikel berichtet von ihren Erfahrungen.

15

π Im März veröffentlichte der Bundesver-band Informationswirtschaft, Telekom-munikation und neue Medien e. V. (Bitkom) die Ergebnisse einer Befragung von mehr als 400 deutschen Unternehmen zum Thema „Cyberangriffe“. Danach verzeich-nete fast jedes dritte Unternehmen in den Jahren 2012 und 2013 Angriffe auf seine IT-Systeme. Überraschend: Knapp 60 % der betroffenen Unternehmen erklärten, dass die Angriffe direkt vor Ort erfolgten. Z. B. wurden Daten gezielt gestohlen oder Schadprogramme per USB-Stick einge-schleust. Bei 30 % der Firmen erfolgten die Angriffe über das Internet.

Wirksamer Schutz vor Hacking

Unabhängig davon, ob der Angriff über das Web oder einen mit Malware infi-zierten USB-Stick erfolgt, wenn es den Cyberkriminellen gelingt, sich Zugriff auf Teile der IT-Infrastruktur einer Firma zu verschaffen, dann können sie Passwörter knacken, Geschäftsgeheimnisse entwen-den oder Administratorenkonten hacken und das gesamte IT-System kompromit-tieren. Um sich vor äußeren Angriffen durch unbefugte Dritte zu schützen, lohnt sich die Investition in diverse Sicherheitsmaß-nahmen. Diese schließen die Identifizie-rung sicherheitskritischer Daten genauso mit ein wie die regelmäßige Sicherheits-überprüfung aller IT-Systeme oder die Sensibilisierung und Qualifizierung der Mitarbeiter durch Weiterbildung. Für die ADACOR gehören entsprechende Mitarbeiterschulungen seit jeher zum fes-ten Bestandteil des Sicherheitskonzepts. So schickt der Hosting-Experte seine Systemadministratoren regelmäßig zu Hacking-Seminaren. Dort erfahren die IT-Fachleute, welche Techniken, Vorgehens-weisen und Tools die Hacker verwenden, um sich Zugriff auf Firmensysteme und Netzwerke zu verschaffen. Denn nur wer die aktuellen Angriffstechniken sowie sei-ne eigenen Schwachstellen kennt, kann sich wirksam dagegen wehren.

Hacking Pro: Penetra-tionstests wissenswert und praxisnah

Ende 2013 besuchten zwei ADACOR-Mitarbeiter die Hacking-Pro-Schulung der Hackattack Security GmbH. Diese bietet geballtes Wissen und praxisnahe Hacking-Simulation vier Tage lang, sieben Stunden täglich. Das konkrete Ziel legte Kursleiter Alfred Grabner, der ebenfalls Geschäftsführer von Hackattack ist,

gleich zu Beginn fest: Zum einen wies er auf inhaltliche Highlights wie das Hacking von Firewalls, LANs und Servern sowie die Schwachstellenermittlung in den Netz-werk- und Software-Systemen hin. Zum anderen informierte er die Teilnehmer, dass die Praxis im Mittelpunkt stehen und sich die Theorie auf das Notwendigste beschränken wird.

Tag 1: Social Engineering, Web- und Firewall-Hacking

Bereits das Szenario am ersten Tag wies eine enge Beziehung zur Praxis auf: Die Teilnehmer wurden von der „Fantasy GmbH“ für die Überprüfung der IT-Sicher-heit des Unternehmens als Penetrations-tester engagiert. Die Modellinfrastruktur ließ dabei keine Wünsche offen. Sämt-liche Technik befand sich auf dem neu-esten Stand: Active Directory Windows Server 2008/2012, Windows 7 Clients, SAP-System, Cisco VLAN sowie aktuelle Firewall-Systeme. Um festzustellen, wie sicher das IT-Netzwerk der „Fantasy GmbH“ ist, soll-ten die Teilnehmer Mittel und Methoden einsetzen, die ein Hacker normalerweise anwenden würde, um unbefugt in ein Sys-tem einzudringen. Konkret umfasste der Auftrag fünf Schritte:

1. Durchdringen der Firewall

2. Überlistung der DMZ (Demilitarized Zone)

3. Eindringen in das Local Area Network

4. Hacking der Windows-2012-Do-mäne und der Administratoren-konten

5. Austricksen der ERP-Server und der verschiedenen Virtual Local Area Networks

Während der Zeit, in der die Schulungsbe-sucher diese Aufgaben lösten, wurden sie kompetent von Alfred Grabner begleitet.

1 Die DMZ ist ein isoliertes Zwischennetz mit sicherheitstechnisch kontrollierten Zugriffsmöglichkeiten auf die daran angeschlossenen Server. Firewalls schirmen die in die DMZ eingebundenen Systeme vor anderen Netzen (z. B. Internet, LAN) ab. Diese Trennung ermöglicht den Zugriff auf öffentliche Dienste über das Internet und schützt gleichzeitig das LAN vor unberechtigten Zugriffen von außen. (Quelle: www.wikipedia.de)

2 ERP steht für Enterprise Resource Planning, d. h. die Einsatzplanung der in einem Unternehmen vorhandenen Ressourcen (Quelle: www.wikipedia.de). Hier ist die eingesetzte Software gemeint.

16 BTS NR. 21

Dieser stellte z. B. nebenher verschiede-ne Hacking-Programme und Penetrati-onstools wie Maltego, Nessus, OpenVAS oder Armitage vor.

Ebenso spielte das Thema „Social Engineering“ am ersten Tag eine Rolle. Die Teilnehmer lernten, wie man mittels Sammlung von unternehmens- und personenbezogenen Informationen im Internet Passwortlisten personalisieren kann. In diesem Zusammenhang wurde auch auf die Rolle sozialer Netzwerke wie Facebook und Google hingewiesen. Denn

über diese Plattformen bzw. die entspre-chenden Nutzerprofile lassen sich Infor-mationen zu Hobbys, Lebenspartnern, Kindern, Freunden, Telefonnummern und Geburtstagen leicht herausfinden. Diese Daten können wiederum Rückschlüsse auf Passwortkombinationen geben.

Ein weiterer Punkt auf der Tages-ordnung lautete „Web Hacking mit auto-matisiertem Web Security Scanner“. Hier erfuhren die Teilnehmer, wie man mit einem Scanner, mit dem man normaler-weise Webapplikationen auf ihre Sicher-heit testet, Schwachstellen ausnutzt und hackt.

Eine zusätzliche Angriffsvariante, über die gesprochen wurde, nennt sich DNS Zone Stealing (Zonendiebstahl des Domain Name Systems). Hier bringt der Angreifer eine nicht autorisierte Übertra-gung der gesamten DNS-Zonendatenbank in Gang. Die daraus gewonnenen Informa-tionen werden anschließend für Attacken auf den DNS-Cache der anfragenden DNS-Clients genutzt. Gelingt es dem Kri-minellen, sich direkt zwischen den Client und den Server zu hacken, kann er den gesamten Daten- und Nachrichtenver-kehr zwischen beiden Systemen abfangen und manipulieren, z. B. durch das Umlei-ten einer Domain auf eine Fake-Seite, um darüber Nutzerdaten abzufangen.

Der erste Schulungstag endete mit der Antwort auf verschiedene Fragen: Z. B wie man mittels Vulnerability Scans, d. h. durch das softwarebasierte Scan-nen eines Computers oder Netzwerks, Schwachpunkte in Servern und Firewalls erkennt oder wie man mittels Pivoting eine Firewall überwinden und dadurch Zugriff auf die DMZ erhalten kann.

Tag 2: Exploiting PRODer zweite Tag des Hacking-Pro-Seminars stand im Zeichen des Themas „Exploi-ting“, d. h. die systematische Möglichkeit, Schwachstellen auszunutzen, die bei der Entwicklung eines Programms nicht berücksichtigt wurden. Um das Thema besser zu veranschaulichen, stellte Alfred Grabner mehrere Windows Exploitings bei Windows Servern vor und erklärte wichti-ge Funktionen und Zugriffsmöglichkeiten mithilfe des Metasploit-Projekts. An-schließend probierten die Penetrations-tester die Exploitings selbst aus, indem sie einen Angriff auf die DMZ-Server der „Fantasy GmbH“ starteten.

Nachdem die Server erfolgreich gehackt waren, lag schon das nächstes Ziel vor Augen: ein weiterer Exploit-Angriff

auf einen FTP-Server (FTP: File Transfer Protocol). Als die Maschine überlistet war, konnten die Teilnehmer auf vertrauliche Mitarbeiterinformationen zugreifen und ihre Passwortlisten mit diesen weiter personalisieren.

Für das finale Massen-Exploiting im Intranet der „Fantasy GmbH“ per Drag-&-Drop-Technik kam Armitage zum Einsatz. Hierbei entdeckten die Tester innerhalb des LANs weitere Systeme, welche sich als Angriffsziele eigneten. Besonderes Interesse weckten die Windows Active Directory Server. Denn nachdem die Pass-wörter aus der Windows Active Directory dieser Systeme gehackt waren, lag sogar der Zugang auf einzelne Mitarbeiterpass-wörter frei.

Tag 3: Interne SystemeAm dritten Tag drangen die Teilnehmer noch tiefer in die interne Infrastruktur der „Fantasy GmbH“ ein. Beim Tagesziel ging es um die Infiltrierung der ERP-Systeme am Beispiel von SAP. In diesem Zusam-menhang spielte auch der Online-Zugriff über die DMZ in das LAN mittels Reverse Proxy Chains eine Rolle. Die Probanden tunnelten dabei die Ports bestimmter in-terner Systeme zu den Client-Systemen. Anschließend lernten sie Techniken ken-nen, mit denen Angreifer mit normalen Nutzerprivilegien erweiterte Administra-torenrechte erreichen können (Privilege Escalation).

Weiterer Tagesordnungspunkt war

1 Bei einem Pass-the-Hash-Angriff meldet sich der Angreifer statt mit einem Klartext-Passwort mit einem Passwort-Hash an. So kann sich der Angreifer den Zugriff auf einen Server verschaffen, ohne das Passwort als Klartext zu kennen. Zusätzlich kann man die gestohlenen Hash-Zugangs-daten auf weitere Systeme und Dienste übertragen und sich damit weitreichende Zugriffsmöglichkeiten verschaffen. (Quelle: www.heise.de)

17

ALEXANDER WICHMANN

Systemadministrator

ADACOR Hosting GmbH

Kaiserleistraße 51


TELEFON +49 69 905089 2119

TELEFAX +49 69 905089 29



der unberechtigte Zugriff auf ein Win-dows 7 System mittels Pass-the-Hash-Methode, bei der die Zugangsdaten von einem Rechner entwendet und für die Authentifizierung an anderen Zugangs-punkten in einem Netzwerk eingesetzt werden.Überdies gehörten die Man-in-the-Midd-le-Attacke und der Brute-Force-Angriff zum Themenspektrum des dritten Ta-ges. Hier lernten die Teilnehmer, wie der Angreifer beim Mittelsmann-Angriff die vollständige Kontrolle über den Nachrich-ten- und Datenverkehr zwischen zwei oder mehreren Kommunikationsteilnehmern übernehmen und manipulieren kann. Beim Brute-Force-Angriff auf Terminal Server und Browser hingegen versuchen die Kriminellen, Passwörter mithilfe einer Software zu knacken, welche in schneller Abfolge unzählige Buchstaben-Zahlen-Zeichenkombinationen ausprobiert.

Abschließend wurde das Thema „Browser-Hijacking“ durchgenommen.

Dabei ging es um die Übernahme einer fremden Browser Session, bei welcher der Angreifer die Startseite ändert bzw. die Suchseite eines Browsers auf eine vom Nutzer nicht gewünschte Seite durch ein bösartiges Manipulationsprogramm austauscht.

Tag 4: Specials und Capture The Flag (CTF)

Am letzten Schulungstag ging es um das VLAN Hopping sowie das Hacking von WLANs mittels zusätzlichem Rogue Access Point. Dieser sitzt an der Schnitt-stelle zwischen LAN und WLAN, sodass der Angreifer ungestört Informationen aus den internen Datenübertragungen sam-meln und nach außen weiterleiten kann. Darüber hinaus informierte die Schulung über den Einsatz von Hardware- und Software-Keyloggern in der Praxis. Hacker verwenden diese gerne, um per-sönliche Daten wie PIN oder Kennwörter

mitzuschreiben. Die Teilnehmer erfuhren außerdem, wie einfach es ist, Telefonate des Standards DECT (Digital Enhanced Cordless Telecommunications) abzuhö-ren, und welche Mobile Devices sich am besten zum Hacken eignen.

Bei der finalen Capture the Flag Chal-lenge konnten schließlich alle Teilnehmer zeigen, was sie gelernt hatten. Bei diesem Wettbewerb traten die verschiedenen Unternehmensteams gegeneinander an. Bei der Lösung themenbezogener Aufga-ben konnten diese Flaggen (engl. flags) erbeuten, die Punkte brachten. Die Teil-nehmer der ADACOR waren die Ersten, die CTF erfolgreich beendeten. Dafür gab es ein dickes Lob von Kursleiter Alfred Grab-ner und zum Abschluss für die erfolgrei-che Teilnahme ein Zertifikat für alle.

Es hat sich gelohntDie Mitarbeiter der ADACOR, die am Hacking-Pro-Seminar teilnahmen, sind sich einig: Der Besuch hat sich gelohnt! „Durch die Teilnahme an den Hackattack-Workshops wurde meine Awareness so geschärft, dass ich im Tagesgeschäft – bei der Konfiguration und Administration der IT-Systeme – den Fokus stärker auf die Systemsicherheit setze und diese auch dem Team gegenüber kommuniziere. Viele interne Prozesse können so immer wieder auf die aktuellen Gegebenheiten angepasst und erweitert werden“, erklärt Alexander Wichmann. Sein Chef ADACOR-CTO Patrick Fend zeigt sich ebenso zu-frieden: „Seit meiner ersten Teilnahme an einer Hackattack-Schulung ist mein Bewusstsein für die Gefahren, die von Hackern ausgehen, geschärft. Im Unter-nehmen haben wir seitdem bereits etliche Sicherheitskomponenten etabliert, die es Hackern schwer machen, unsere Systeme zu infiltrieren.“

18 BTS NR. 21

19

Sicherheitssoftware auf dem Prüfstand

Netsparker oder Acunetix: ADACOR führt Vergleichstest von Web Vulnerability Scannern durch

Wie sicher der eigene Internetauftritt gegen Hackerangriffe geschützt ist, lässt sich mithilfe eines Web Vulnerability Scanners herausfinden. Die ADACOR setzt in diesem Bereich u. a. erfolgreich die Software „Acunetix“ ein. Aufgrund einer Empfehlung von einem Sicherheitsberater probierten die Softwareentwickler des Hosting-Spezialisten vor kurzem eine Variante aus: Netsparker. Dieser Artikel handelt vom ersten Teil des Vergleichstests zwischen den Produkten.

π Web Vulnerability Scanner (WVS) sind Programme, die eine Internetanwendung bzw. -seite automatisiert auf bekannte Schwachstellen und Sicherheitslücken überprüfen. Die Scaner-gebnisse bilden die Basis für entsprechende Maßnahmen, mit denen sich die aufgedeckten Sicherheitslücken schließen lassen. Meistens testet die Software nicht nur die Anwendung selbst, sondern sie deckt auch Schwachstellen im Webserver auf und überwacht allgemeine sicherheitsrelevante Einstellungen. So zeigt das Tool z. B. automatisch an, wenn bei der Einbindung von Log-in-Formularen auf einer Website der Einsatz des SSL-Netz-werkprotokolls (SSL: Secure Sockets Layer) fehlt. Dieses ist jedoch Grundvoraussetzung für eine sichere Datenübertragung.

Nutzen eines Web Vulnerability Scanners

Die Sicherheit einer Internetanwendung hängt von verschiede-nen Faktoren ab: z. B. vom Alter, von der Größe und Komplexität der Seite oder von den eingesetzten Frameworks und Webser-vern. Aufgrund der zahlreichen Einflussgrößen wäre es unwirt-schaftlich, würde man nach jedem Update oder Deployment auf der gesamten Anwendung eine Sicherheitsüberprüfung per Hand ausführen. Ohnehin hätten Hacker immer noch genügend potenzielle Angriffsmöglichkeiten sowie daraus resultierende Kombinationen, als dass ein solcher Aufwand personell abdeck-bar wäre. Ein Web Vulnerability Scanner bietet deshalb für diese Themenstellung die richtige Lösung.

Prüfungskriterien im Vergleichstest

Bei dem nachfolgenden Vergleichstest stand die Prüfung folgender drei Kriterien im Fokus:

› 1. Zuverlässigkeit

› 2. Flexibilität

› 3. Funktionsumfang

Grundsätzlich ist es nicht sinnvoll, einen Web Vulnerability Scanner in einer Produktivumgebung zu testen, weil dann womöglich die Datenbank oder andere kritische Teile der ge-testeten Webseite zerstört werden würden. Aus diesem Grund sollten die Vulnerability Scans in einer sicheren Testumgebung ausgeführt werden, die man problemlos in ihren ursprünglichen Zustand zurückversetzen kann.

Bezogen auf den Testablauf ließen die Programmierer die Scanner zunächst gegen die von Acunetix zur Verfügung gestellte und oft empfohlene Testseite vulnweb.com laufen. In einem zweiten Schritt werden die Tools zusätzlich auf einer selbst eingerichteten Umgebung (OWASP Mutillidae1) geprüft, um in einer kontrollierten, anbieterunabhängigen Umgebung präzisere Testergebnisse zu erhalten.

1 Das Mutillidae-Projekt simuliert eine Webanwendung, in welche die in der OWASP-Top-10-Liste aufgelisteten Sicherheitsschwachstellen eingebaut sind (s. a. https://www.owasp.org/index.php/Top_10_2013-Top_10).

20 BTS NR. 21

FAKTEN

ENTWICKLER Netsparker Ltd.

WEBSITE https://netsparker.com

PREIS Standard: 1.950 €Professional:5.950 €

AKTUELLE VERSION 3.2.7.0

ZIELSYSTEM Unbekannt

LIZENZ Jährlich

Netsparker: Web Vulnerability Scanner mit False Positive-Erkennung

Sowohl die Oberfläche als auch der Konfigurationsumfang von Netsparker überzeugen durch eine intuitive und übersichtliche Handhabung, die besonders unerfahrenen Nutzern den Vorteil bietet, das Tool auch mit wenig Erfahrung mit Penetrationstests effektiv bedienen zu können.

Bereits die Standardinstallation von Netsparker ermöglicht den direkten Anschluss des Scanners an das weit verbreitete Jira-Ticketsystem von Atlassian. Mithilfe der webbasierten Anwendung kann ein Ticket mit allen nötigen Einstellungen wie „zugewiesen an“ oder „Kategorie“ direkt erzeugt werden, sobald der Scanner eine Schwachstelle oder Sicherheitslücke findet.

Ein großer Nachteil bei der Ausführung von Netsparker war die extrem lange Testdauer. Der Scan dauerte bis zu acht Stun-den lang. Das lag sicher daran, dass die Software versuchte, Blind-SQL-Injections3 gegen die Testseite auszuführen. In der Probeversion von Netsparker ließ sich dieses Scan-Template jedoch nicht abschalten.

Die Prüfungskriterien

1. Zuverlässigkeit

Der Test dauerte bei 9.580 Requests etwa fünfeinhalb Stunden. In diesem Zeitraum hat Netsparker 21 kritische, 24 wichtige, vier mittelschwere, acht niedrige und zehn informelle Funde angezeigt.

2. Flexibilität

Es ist möglich, das Scanprofil mit Log-in-Daten und/oder einem Custom-Cookie zu speisen. Damit lassen sich beispielsweise auch Seiten prüfen, die sich hinter dem Log-in befinden. Des Weiteren kann man die Scans zu festen Zeiten mit bestimmten Scanprofilen planen. Die verschiedenen Templates lassen sich über ein Menü einzeln an- und abschalten. Im Test reagierte diese Funktion allerdings nicht, eventuell lag dies an der Evalua-tionsversion der Software.

3. Funktionsumfang

Bis auf den eigentlichen Vulnerability Scan bietet Netsparker keine weiteren Funktionen.

1 Uniform Resource Identifier2 Bei einer SQL-Injection nutzt der Angreifer eine Sicherheitslücke im Zusammenhang mit einer SQL-Datenbank aus. Diese entsteht durch fehler-

hafte Maskierung oder Überprüfung von Metazeichen bei der Nutzereingabe. Der Hacker versucht über die Anwendung, die den Datenbankzugriff steuert, eigene Datenbankbefehle einzuschleusen. Bei einer Blind-SQL-Injection liefert der Server keine Fehlermeldung, die besagt, ob die Abfrage erfolgreich war oder nicht. Anhand von Anzeichen wie unterschiedliche Fehlermeldungen oder Antwortzeiten des Servers kann ein Angreifer trotz-dem feststellen, ob eine Abfrage erfolgreich war oder einen Fehler zurückmeldet (Quelle: www.wikipedia.de).

3 SOAP (ursprünglich für Simple Object Access Protocol) ist ein Netzwerkprotokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. SOAP ist ein industrieller Standard des World Wide Web Consortiums (W3C). (Quelle: www.wikipedia.de)

Informationen zu den Testumgebungen

In einem ersten Schritt erfolgte der Scan (Netsparker und Acunetix) gegen testphp.vulnweb.com.

vulnweb.com OWASP Mutillidae 2

URI2 testphp.vulnweb.com http://sourceforge.net/projects/mutillidae/

HERAUSGEBER Acunetix OWASP

TYP Remote-hosted(durch Acunetix)

Self-hosted

VERSION N/A 2.6.10

ANZAHL VULNERABILITIES

Unbekannt Ca. 150

21

FAKTEN

ENTWICKLER Acunetix

WEBSITE http://acunetix.com

PREIS 2.500 – 4.700 €

AKTUELLE VERSION 9.5

ZIELSYSTEM Windows

LIZENZ Subscription / jährliche Zahlweise

Acunetix: All-in-One-Software-Scanner

Beim Start von Acunetix bietet der Tool-Explorer auf der linken Seite eine ganze Reihe von Konfigurationsmöglichkeiten und Tools. Um das gesamte Potenzial, das die Software im Bereich der Penetrationstests bietet, effizient auszuschöpfen, bedarf es für den Nutzer einiges an Erfahrung und Einarbeitung.

Die Einstellungsmöglichkeiten von Acunetix sind fein gra-duiert. Daraus ergeben sich interessante Möglichkeiten für die Erstellung von unterschiedlichen Scanprofile für sehr spezifi-sche Anwendungsfälle. Zusätzlich verfügt Acunetix über einen Extramodus speziell für Webservices. Mit diesem kann man z. B. SOAP4-Schnittstellen überprüfen.

Interessant für allgemeine Tests, beispielsweise im eigenen Firmennetzwerk, ist der Target-Finder, der mittels IP/Port-Ranges potenzielle Angriffsziele im aktuellen Netzwerk aufspürt und anzeigt.

Softwareplus: der Acunetix-Sensor

Acunetix bietet eine zusätzliche Softwarekomponente, die sich in den serverseitigen Code integrieren lässt und die di-rekt mit dem Scanner kommunizieren kann. Der sogenannte Acunetix-Sensor ermöglicht es mithilfe des auf dem Server eingebundenen Codes/Moduls, die kritischen Codestellen direkt zu identifizieren. Der sich daraus ergebende Vorteil ist ein hoher Detailierungsgrad beim Scannen. Etwa zeigt das Programm ein Stacktrace („Stapelspeicher-Zurückverfolgung“: Ausgabe und Interpretation des Stack-Inhalts) vom Zeitpunkt der Ausnut-zung der Sicherheitslücke sowie die entsprechende Codezeile und den Name der betroffenen Datei an.

Die Prüfungskriterien

1. Zuverlässigkeit

Der Test dauerte bei 51.267 Requests ungefähr drei Minuten und 41 Sekunden. Acunetix hat im Testdurchlauf 94 kritische, 49 wichtige, vier mittelschwere, acht niedrige und zehn informelle Funde angezeigt.

2. Flexibilität

Die Einstellungsmöglichkeiten für Scans sind vielfältig. Außer-dem lassen sich Header und Cookies definieren, es kann ein Proxy dazwischen geschaltet werden (SOCKS5 oder HTTP) und es können Standardwerte für Eingabefelder gesetzt werden.

3. Funktionsumfang

Neben dem normalen Scan auf Sicherheitslücken bietet Acune-tix zusätzlich die Möglichkeit, SOAP-Webservices zu scannen. Außerdem entpuppte sich der Acunetix-Sensor als nützliches Zusatz-Feature.

1 Das SOCKS-Protokoll ist ein Internetprotokoll, das Client-Server-An-wendungen erlaubt, protokollunabhängig und transparent die Dienste eines Proxyservers zu nutzen. Clients hinter einer Firewall verbinden sich erst zu einem SOCKS-Proxy statt direkt zu einem externen Server. Der SOCKS-Proxy prüft die Berechtigung des Clients, den externen Server zu kontaktieren, und leitet die Anfrage an den Server weiter. SOCKS-Proxies sind universell einsetzbar z. B. zum Abrufen von Web-seiten oder zum Mailversand. SOCKS steht als Abkürzung für Sockets (Softwaremodul, mit dessen Hilfe sich ein Computerprogramm mit einem Rechnernetz verbinden und mit anderen Computern Daten austauschen kann). (Quelle: www.wikipedia.de)

TOBIAS FISCHER

Softwareentwickler

ADACOR Hosting GmbH

Kaiserleistraße 51


TELEFON +49 69 905089 0

TELEFAX +49 69 905089 29



Unterschiedliche Ergebnisse erfordern weitere Tests

Die Scanergebnisse sind speziell im Hinblick auf die Testlänge und die Endresultate sehr unterschiedlich. Das bedeutet im Umkehrschluss, dass im Hinblick auf eine Entscheidung ein Test gegen eine Seite mit unbekannter Anzahl an Vulnerabilities nur als grober Anhaltspunkt (z. B. bezüglich Bedienkonzept, Programmdesign, Funktionsum-fang oder Konfigurierbarkeit) dienen kann. In Bezug auf die Zuverlässigkeit waren die Ergebnisse nicht ausreichend.

Aufgrund der genannten Ursachen werden die ADA-COR-Softwareentwickler im zweiten Teil der Testserie beide Tools gegen eine selbst eingerichtete Testumgebung mit der OWASP Mutillidae 2 laufen lassen. Über die Ergebnisse werden wir in der Herbstausgabe unseres Kundenmagazins berichten.

22 BTS NR. 20

23

Prozessoptimierung: 6. Teil der Kanban-Artikelserie

Last but not least: Verknüpfung des Kanban-Tools mit der Helpdesk-Software OTRS

Im zweiten Quartal 2014 schloss die ADACOR im Rahmen der unternehmensweiten Einführung einer softwaregestützten Aufgabenverwaltung auf Basis der Kanban-Methode einen letzten Meilenstein ab: die Verbindung des Taskmanagements mit dem Ticket-System. Da in nächster Zeit keine Neuerungen anstehen, sondern allenfalls graduelle Anpassungen notwendig werden, endet unsere Artikelserie mit dieser Ausgabe fürs Erste. Erfahren Sie abschließend die Details über die Vermählung des Kanban-Systems mit dem Open Ticket Request System (OTRS), welches die ADACOR im IT-Service-Management (ITSM) einsetzt.

π Folgende Erkenntnis führte überhaupt erst zu der Notwen-digkeit, beide Systeme miteinander zu verknüpfen: Nachdem die Kanban-Software eingeführt war, erhielten die Mitarbeiter des Betriebsteams ihre Arbeitsaufträge aus zwei verschiedenen Quellen: zum einen aus dem Kanban-Board über die Karten, zum anderen aus dem Ticket-System in Form von Kundenanfragen (Service Requests und Incidents). Dabei ging das Bearbeiten der Karten übersichtlich und strukturiert von der Hand. Denn die Teamleiter verteilen die Aufgaben direkt an die Mitarbeiter, sodass diese genau wissen, welcher Task in welcher Reihenfolge bis zu welchem Zeitpunkt zu erledigen ist. Eröffnet dagegen ein Kunde ein Ticket, werden alle Mitarbeiter, die das OTRS nutzen, informiert. Vor der Verschmelzung der Systeme übernahm ein Kollege mit freien Kapazitäten das Ticket. Danach standen die Mitarbeiter vor einem Dilemma: Sie waren plötzlich Diener zweier Herren.

Die folgende Betrachtungsweise führte zu anfänglichen Irri-tationen bei den betroffenen Mitarbeitern: Wenn wir ausschließlich unsere Kanban-Karten bearbeiten und uns darauf verlassen, dass ein Kollege das Ticket übernimmt, dann bleibt die Kundenanfrage im schlechtesten Fall liegen. Da ein Ticket aber mindestens genauso wichtig ist, wie ein Auftrag in Form einer Karte, müssen wir das even-tuelle Nichtbearbeiten einer Serviceanfrage auf jeden Fall vermei-den. Konzentrieren wir uns hingegen vorrangig auf die Anfragen im Ticket-System, würden unsere Kanban-Karten liegen bleiben, also die Aufgaben, an denen uns unsere Vorgesetzten messen.

Mit der Zusammenlegung beider Systeme haben wir die Arbeit unserer Mitarbeiter weiter vereinfacht. Sie brauchen weder zwei

Tools zu bedienen noch Aufgaben doppelt zu erledigen. Zusätzlich stehen sowohl die Tasks, die aus den Tickets resultieren, als auch die Aufträge aus den Kanban-Karten, nach Dringlichkeit und Rei-henfolge sortiert, zur Verfügung“, erklärt Sebastian Krack, Teamleiter Softwareentwicklung bei der ADACOR. Darüber hinaus dient das Kanban-System den Teamleitern als Steuerungsinstrument, da es sinnvolle Strukturen vorgibt, mit denen die Mitarbeiterführung übersichtlich gestaltet werden kann. Mittlerweile haben die meisten ADACOR-Teams eine Größe erreicht, bei der man die Arbeitsprozesse ohnehin nicht mehr per E-Mail oder auf Zuruf steuern kann. Dement-sprechend führte die Verbindung von OTRS und Kanban-Board dazu, dass sämtliche genannten Herausforderungen zufriedenstellend gemeistert werden konnten.

Manuelles Übertragen der Aufgaben von Ticket auf Karte

Bevor das Projektteam mit der technischen Verknüpfung der Systeme starten konnte, galt es herauszufinden, wie man aus einem Ticket, bei dem der Verlauf im Zweifelsfall aus 10-20 E-Mails besteht, den einen wichtigen Arbeitsauftrag herauslöst, der Grundlage für die Kanban-Karte ist. Im Hinblick darauf prüfte man zunächst die Möglichkeit, den Vorgang zu automatisieren. Warum dieser Plan in der Praxis scheiterte, erklärt Sebastian Krack: „Wir zogen beispielhaft Tickets aus dem System und überprüften diese auf Regelmäßigkeiten hinsichtlich des Auf-findens der Aufgabenbeschreibung. Aber selbst nach über 20

24 BTS NR. 2124 BTS NR. 20

Tickets konnten wir kein wiederkehrendes Prinzip feststellen, an welcher Stelle im Ticketverlauf die entsprechenden Inhalte hätten zu finden sein können.“ Am Ende siegte die Erkenntnis, dass die Lösung nur aus der manuellen Übertragung der Auf-gabenbeschreibung vom Ticket auf eine Karte bestehen kann.

Karten aus dem OTRS generieren

Im nächsten Schritt fokussierte man sich auf folgende Frage: Wie erreichen wir, dass ein Mitarbeiter, der das Ticket-System nutzt, von dort aus eine Karte erzeugen kann, ohne in das Kanban-Board wechseln zu müssen? Eine doppelte Erfassung wäre zu aufwendig gewesen. Dann hätte ein Mitarbeiter bei jeder neuen Karte einen zweiten Screen öffnen, sich ins Intranet ein-loggen, dort das Taskmanagement-System aufrufen und darin eine neue Karte anlegen müssen. Anschließend hätte er zurück ins Ticket-System wechseln und von dort per Copy-and-paste die Aufgabenbeschreibung, die Priorität sowie den Inhaber in die Aufgabenverwaltung übertragen müssen. Das Ziel lautete daher, die mindestens benötigten Informationen (Felder) aus dem OTRS zu erhalten, um daraus automatische eine Karte im Kanban-Tool anlegen zu können.

Dynamische Felder übertragen Kartennummer und Aufgabeninhalt

Bei der Lösungsfindung nutzte das Projektteam die Board-Mittel des OTRS. So ermöglicht das Ticket-System neben den feststehenden Feldern (z. B. E-Mail-Inhalt, Priorität, Verant-wortlicher) das Einfügen von eigenen dynamischen Feldern, die aus verschiedenen Typen (z. B. Text, Checkbox, Dropdown-Menü, Datum und Zeit) bestehen. Diese Felder lassen sich flexibel in die verschiedenen Masken einbinden, benennen und mit Inhal-ten füllen. Aufgrund der Strukturen beider Systeme sind einige Felder im OTRS und im Kanban deckungsgleich (z. B. Priorität, Verantwortlicher, Besitzer). Daher stehen die benötigten Infor-mationen für die Karte teilweise schon im Vorfeld zur Verfügung.

Über die dynamischen Felder mussten nun noch die fehlenden Informationen (Board, Kartentyp, -titel, Auftrags-beschreibung) erfasst werden. Damit man aus dem Ticket

schnellstmöglich eine Kanban-Karte machen kann - egal wel-che Maske man gerade öffnet (z. B. Notiz hinzufügen, Priorität ändern, Ticket einem Verantwortlichen zuweisen) – lassen sich die dynamischen Felder in verschiedene Masken einbinden. Für eine übersichtliche Informationssammlung bzw. als Basis für die Kartenerstellung wurden drei Felder angelegt:

› 1. Kanban-ID (Kartennummer)

› 2. Kanban-Karte (Select-Box, worüber die Boards mit den Kartentypen in einer Baumstruktur abgelegt sind)

› 3. Freitext (kurze Aufgabenbeschreibung, die sich aus dem Ticket ergibt)

In der Praxis verifiziert zunächst der Teamleiter bzw. der für ein Ticket verantwortliche Service-Delivery-Manager die Anfrage. Anschließend priorisiert er sie, ordnet sie einem Mitarbeiter zu und füllt zwei der drei dynamischen Felder mit den notwendigen Informationen aus. Die Kanban-ID wird später automatisch hin-zugefügt. Ist dieser Vorgang abgeschlossen, stehen im OTRS alle Informationen für das Erzeugen einer neuen Karte zur Verfügung.

Automatischer Job schafft Verknüpfung

Das OTRS bietet eine API (Programmierschnittstelle), über die alle Funktionen des Ticket-Systems vom Kanban-Tool aus aufgerufen und angesteuert werden können. Damit die Soft-ware erkennt, wann ein neues Tickt im OTRS generiert wurde, implementierte man einen automatischen Cron-Job ins XPMS, in welches das Taskmanagement eingebunden ist. Danach wer-

2525

SEBASTIAN KRACK

Teamleiter Softwareentwicklung

ADACOR Hosting GmbH

Kaiserleistraße 51


TELEFON +49 69 905089-2107

TELEFAX +49 69 905089-29



den über die API alle zwei Minuten neue Informationen aus dem OTRS abgefragt: Wird z. B. bei einem neuen Ticket im dynami-schen Feld „Kanban-Karte erstellen“ eingetragen, dann erfolgt der Abruf der restlichen Inhalte wie Priorität, Verantwortlicher und Besitzer automatisch. Damit stehen im Handumdrehen alle Pflichtangaben zur Erstellung einer Karte zur Verfügung. Des Weiteren wird die Aufgabenbeschreibung aus dem Freitextfeld des Tickets und der Kartentitel aus dem Betreff extrahiert. Un-wichtige Ticket-Bestandteile wie „Antwort“ oder „Weitergeleitet“ sowie die Ticket-ID werden herausgefiltert. Am Schluss verbleibt für das Benennen der Karte der ursprüngliche Betreff des Kun-den. Gleichzeitig wird in der Karte gespeichert, welches Ticket mit ihr verknüpft ist. Ist die Karte im System angelegt, wird ihre Nummer mithilfe des Cron-Jobs im OTRS in das Feld Kanban-ID übertragen.

Verlinkung erleichtert Systemwechsel

Sobald der Kartenerstellungsvorgang abgeschlossen ist, kann man im OTRS im dazugehörigen Ticket auf einen Link in den dynamischen Feldern klicken und wird direkt auf die entsprechende Karte im Verwaltungstool geleitet. Das Verlinken funktioniert auch umgekehrt: Klickt man auf den Link in einer Karte, die aus einem Ticket generiert wurde, wird man auf das betreffende Ticket im OTRS geroutet. Eine solche Verknüpfung bietet den Vorteil, dass weitere manuelle Eingaben entfallen und man mit einem Klick im jeweils anderen System landet, ohne sich durch zwei Systemen hangeln zu müssen.

Mehr Transparenz und Produktivität

„Erst nach der Implementierung des Kanban-Systems haben wir festgestellt, wie viele Vorteile uns das Tool gebracht hat. Beson-ders beeindruckt hat uns die gestiegene Transparenz in unseren Workflows. Wir sehen jetzt exakt, woher ein Task stammt und können demnach unsere Aufgabenplanung wesentlich besser strukturieren als vorher. Wir wissen genau, welcher Mitarbeiter an welchem Job arbeitet und wann er voraussichtlich damit fer-tig ist, um eine neue Aufgabe zu übernehmen. Als positive Folge dieser Prozessstraffung hat sich sowohl die Übersichtlichkeit als auch die Gesamtproduktivität erhöht“, bringt es Sebastian Krack auf den Punkt. Damit die Mitarbeiter den Blick für das gro-

ße Ganze nicht verlieren, weil sie primär Karten abarbeiten, bei denen die Priorisierung bereits vorgegeben ist, führt die ADA-COR im Rahmen des kontinuierlichen Verbesserungsprozesses (KVP) in den Teams tägliche Stand-up-Meetings sowie einen wöchentlichen Jour fixe durch.

Für jede Firma das passende Modell

„Ob Scrum, agiles Projektmanagement oder (Software-)-Kan-ban, wir haben schon früh festgestellt, dass die dogmatische Einhaltung von Management- und Produktivitätsmodellen, wie sie in den Lehrbüchern stehen, für die ADACOR nicht funktioniert. Vielmehr haben wir bei der Realisierung der Taskverwaltung ein bestehendes System als Basis genommen und es mit anderen Modellen sowie mit unseren eigenen Erkenntnissen kombiniert und weiterentwickelt. Mit diesem Vorgehen sind wir sehr gut durch das Projekt gefahren“, erklärt Andreas Bachmann, CIO der ADACOR, die flexible Interpretation und Anwendung des Kanban-Tools für seine Firma.

Eine Vielzahl von Anfragen nach unserer Berichterstattung in der Behind The Scene bestätigt, dass viele Kunden und Inter-essierte gerne wissen möchten, wie die ADACOR die Implemen-tierung des Taskmanagements im Unternehmen vollzogen hat und wie sie den Spagat zwischen der freien Interpretation von Software-Kanban und den individuellen Anforderungen der Or-ganisation geschafft hat. Das entsprechende Wissen geben die Experten gerne weiter. Auf Anfrage oder bei Fachvorträgen, wie beispielsweise am 15. Mai, als COO Alexander Lapp beim Best-Management-Practice-Congress in Bad Neuenahr erfolgreich über „Kanban als Methode der Produktionsprozesssteuerung im IT-Servicemanagement“ referierte.

26 BTS NR. 21

Die beste Methode, eine gute Idee zu bekommen, ist, viele Ideen zu haben! (Linus Pauling)

27

Cloudbase Proxy – SaaS für höchste Flexibilität, Skalierbarkeit und Performance

Modulentwicklung liegt im Plan: Parameter-Hashing und Grafikoptimierung im Fokus

Es geht voran: Noch drei Monate und das Projekt “Cloudbase Proxy” tritt in seine heiße Endphase. Dann wird die Einführung des SaaS-Produktes im Mittelpunkt stehen. Im Moment konzentrieren sich die Entwickler erst einmal auf die Modulprogrammierung. Jüngst wurde das Sicherheitsmodul “Parameter-Hashing” final abgeschlossen, dessen Funktionalitäten werden gerade unter Live-Bedingungen getestet. Parallel dazu stellt das Team das Modul zur Grafikoptimierung fertig. Den genauen aktuellen Status in der Modulentwicklung fasst der folgende Artikel zusammen.

π Bereits bei der Planung des Proxy-Kerns haben die Soft-wareentwickler der ADACOR viel Wert auf eine solide und flexi-ble Basis für die spätere Modulprogrammierung gelegt. Dafür ernten sie jetzt die Früchte: Die Entwicklungsarbeiten gehen planmäßig voran und die letzten Module inklusive ihrer Features werden zurzeit step-by-step in das große Ganze eingebunden.

Mittlerweile sind die drei Sicherheitsmodule genauso komplett wie die Performance-Einheiten. An den drei Optimie-rungsbausteinen arbeitet das Team gerade mit Vollgas, der Schwerpunkt liegt aktuell auf der Grafikoptimierung. Als positives Fazit lässt sich festhalten: Die Programmierung der verschiede-nen Module entwickelt sich sehr Erfolg versprechend!

Selbst bei komplexen Modulen wie dem Parameter-Hashing zieht das Entwicklerteam am Ende des Tages eine positive Bilanz: „Bei den Tests im Live-Betrieb funktioniert das Parameter-Hashing besser als erwartet. Das ist besonders erfreulich, denn die Kom-plexität des Moduls hat sich erst im Verlauf der Programmierung herausgestellt“, erläutert Andreas Bachmann, CIO der ADACOR.

Hashing: Schutz vor Manipulation von URL-Parametern

Mittels URL-Parametern werden Daten vom Webbrowser an den Server übertragen, sodass dieser daraufhin die korrekten Seiten an den Browser zurückgeben kann. Ebenso können Benutzer-daten über solche Parameter übergeben werden. Folglich lautet die oberste Priorität für Webanwendungen: Parameter und deren Werte müssen vor ihrer weiteren Verwendung geprüft werden, um Veränderungen durch Dritte wirksam abzufangen. Vergisst man nämlich diesen Schutzmechanismus, stehen einem Angreifer im wahrsten Sinne des Wortes alle Manipulationstüren offen.

Nehmen wir als fiktives Beispiel den Online-Banking-Bereich eines Kreditinstituts. Dort sind im Adressfeld einer

personalisierten Kundenseite bestimmte Parameter hinterlegt. Sollte die Kontonummer mit in der URL oder ID stehen, könnte man durch Ausprobieren versuchen, die Seite zu manipulieren. Man könnte die bestehende Kontonummer durch eine beliebige andere ersetzen, darauf hoffen, dass die Daten des anderen Kontoinhabers angezeigt werden, und vielleicht erfolgreich einen Angriff starten. Heutzutage sind die Online-Systeme ent-sprechend geschützt, sodass sich ein derart simpler Trick nicht mehr so leicht umsetzen lässt. So steht in keiner URL mehr die Kontonummer, sondern ein Hash-Wert verbirgt die eigentlichen Daten. Aber was passiert, wenn der Entwickler vergisst, die URL-Parameter mittels Hashing zu schützen oder eine Sicherheitslü-cke durch einen Programmierfehler entsteht?

› Um sich gegen die Manipulation von URL-Parametern und die daraus möglicherweise resultierenden Hacking-Attacken zu wappnen, bietet der ADACOR Cloudbase Proxy das passende Sicherheitsmodul: das Parameter-Hashing bzw. die Validierung.

Hash-Wert schützt reale Daten

Beim Parameter-Hashing legt ein Generator über eine kryptolo-gische Hash-Funktion einen Hash-Wert fest. Diese Buchstaben-Zahlen-Folge adressiert eine bestimmte Parameterkombination in einer Datenbank, in der die eigentlichen Daten hinterlegt sind. Mithilfe der Hash-Funktion lässt sich aus einer bestimmten gleichen Zeichenfolge immer wieder der gleiche Hashwert errechnen. Umgekehrt kann daraus aber nicht wieder der Ursprungswert ermittelt werden. Man spricht hier von einer sogenannten Einwegfunktion. In der Folge kann der „echte“ URL-Parameter nicht mehr manipuliert werden, denn bei einer Veränderung des Hash-Werts würde kein passender Datenbank-eintrag gefunden werden. Vielmehr landet man auf der Startseite

28 BTS NR. 21

ANDREAS BACHMANN


ADACOR Hosting GmbH

Kaiserleistraße 51


TELEFON +49 69 905089-22

TELEFAX +49 69 905089-29



oder auf einer speziellen Fehlerseite, da die URL so interpretiert wird, als wären gar keine Parameter übertragen worden.

Das Parameter-Hashing-Modul soll eine große Bandbreite an individuellen Webapplikationen unterstützen. Deshalb mussten die Entwickler auf Seiten der ADACOR viel Feintuning betreiben. „Wir wussten von Anfang an, dass wir fachlich bestens gerüstet sind, das Modul aber so seine Tücken hat. Der tatsächliche Um-fang stellte sich erst im Verlauf der Modulentwicklung heraus. Die letzten Tests haben aber gezeigt, dass die Entwickler die Aufgabe mit Bravour gelöst haben“, erklärt Andreas Bachmann.

Testing unter Live-Bedingungen

Nach seiner Fertigstellung wird das Hashing-Modul jetzt im Live-Einsatz intensiv auf seine Funktionstüchtigkeit geprüft. Eine Maßnahme ist dabei die interne Auslieferung von realen Internetseiten über den Proxy. Dabei wurde das Parameter-Hashing für zwei Webseiten (ibash.de, golem.de) aktiviert. D. h., die Softwareentwickler surfen über den Proxy im Internet und testen das Tool dort unter realen Bedingungen, indem sie vorge-ben, dass z. B. Golem ein Kunde des Cloudbase Proxy ist. Durch dieses Vorgehen kann das Modul ausgiebig getestet werden. Sollte die Auslieferung einer Seite fehlschlagen, bemerken die Entwickler das sofort und können die Ursache schnell ermitteln.

Grafikoptimierung: kurze Ladezeiten und hohe Internet-Performance

Parallel zum Testing des Parameter-Hashing steht die Vollen-dung des Moduls zur Grafikoptimierung an. Dabei erwarten die Entwickler ebenso wie beim Parameter-Hashing einige spezi-elle Herausforderungen. Diese liegen nicht, wie man annehmen möchte, bei der Programmierung selbst, sondern es gilt auch hier einige Sonderfälle zu beachten, damit das Modul für die meisten Webseiten funktioniert. Zudem sind diese Besonder-heiten dem Anspruch der ADACOR geschuldet, bei der Grafiko-ptimierung ein Ergebnis zu liefern, was nah an dem ist, was ein Webdesigner bei der individuellen Gestaltung einer Internetseite erreichen kann. „Wir befinden uns mit den Cloud-Proxy-Modulen oft nicht auf den komfortablen Netzwerk- oder HTTP-Ebenen, wo alles strukturiert und genormt ist. Vielmehr schalten wir uns vor die sehr individuelle Ebene der Oberflächenimplementierung, wo die Module auf die verschiedenen Herangehensweisen der Ap-plikationsentwickler reagieren müssen“, so Andreas Bachmann.

Mit dem Reverse-High-Performance-Proxy will die ADACOR ab Ende 2014 eine SaaS-Lösung anbieten, welche Funktiona-litäten für den Betrieb und die Optimierung von Applikationen und Webseiten automatisch bereitstellt. Für Unternehmen bietet das Produkt den Vorteil, dass sie Funktionen aus neun gebräuchlichen Entwicklungsbereichen weder selbst program-mieren noch installieren müssen.

Die Programmierung eines Proxy-Prototypens entwickelt sich sehr positiv, das Projekt befindet sich zeitlich im Plan und die Einführung der SaaS-Lösung Ende 2014 ist sicher.

Die Projektmitarbeiter arbeiten hochkonzentriert an ihren Aufgaben. Nach und nach kommen immer wieder neue Ideen dazu, welche Features die Module ergänzen könnten. Alle Ein-fälle werden auf einer Wunschliste gesammelt. Direkt nach dem

Produktlaunch des Proxys wird eine Analyse gestartet, die im Ergebnis zeigen soll, welche Funktionalitäten tatsächlich sinn-voll sind. Die besten Vorschläge werden in die entsprechenden Module implementiert. „Wir sind ein innovationsfreudiges Un-ternehmen und unsere Mitarbeiter werden nicht müde, immer wieder neue Ideen einzubringen. Die Basis für ein neuartiges Produkt haben wir gelegt. Um dessen Erfolg langfristig zu hal-ten, wird es in Zukunft für uns darum gehen, die solide Grundlage stetig zu verbessern“, resümiert Andreas Bachmann.

Wie funktioniert die Grafikoptimierung?

Mithilfe des Browser-Identifikators sowie der Beobachtung der Verbindungsgeschwindigkeit zwischen Endnutzer und Proxy analysiert dieses Modul, über welchen Zugang (Mobil, DSL) auf das Internet zugegriffen wird. Das Modul ist anschlie-ßend in der Lage, Grafiken wie JPG, PNG oder GIF für die jeweiligen Nutzererwartungen und das Endgerät zu optimieren sowie die Bilder in ver-schiedenen Größen zu erstellen.

9 Entwicklungsbereiche in der Übersicht

Sicherheitsmodule

1. IPS/IDS (Intrusion Prevention System/Intrusion Detection System)

2. Code Filtering

3. Parameter Hashing/Validation

Performance-Module

4. Hochverfügbarkeit

5. Automatische CDN-Anbindung

6. Caching

Optimierungsmodule

7. Grafikoptimierung

8. Minify

9. Kompression

29

Domain Management

ICANN lässt mehr als 6,8 Millionen Domains sperren

Im Zuge der Einführung der neuen generischen Top-Level-Domains (gTLDs) hat die Internet Corporation for Assigned Names and Numbers (ICANN) auf Empfehlung des Security and Stability Advisory Committee (SSAC) beschlossen, aus Sicherheitsgründen zunächst mehr als insgesamt 6,8 Millionen Domains für zwei Jahre zu sperren. ICANN ist eine gemeinnützige international agierende Internetorganisation mit Hauptsitz in Kalifornien, die für die Zuteilung des IP-Adressraums, die Zuteilung der Protokoll-Identifier, die Verwaltung der generischen und länderspezifischen Top-Level-Domains im Domain Name System (DNS) sowie für die Managementfunktionen des Root-Server System zuständig ist.

π Seit jeher verwenden IT- und Netzwerk-Administratoren für die Benennung von Seiten in internen Netzwerken und ange-schlossenen Geräten eingängige Namen. Beispiele für solche Namen sind fritz.box, netz.berlin, server.web, .vpn, .host oder .local. Auf der technischen Basis eines sogenannten Domain Name Systems (DNS) können diese Adressen direkt in die Brow-ser-Adressleiste eingegeben werden. Das DNS arbeitet dabei ähnlich wie ein Telefonbuch, welches die Namen der Teilnehmer (Domainname) in ihre Anschlussnummer (IP-Adresse) auflöst. Da Menschen sich in der Regel an Namen viel besser erinnern können als an Zahlenkolonnen, wie sie in IP-Adressen Verwen-dung finden, vereinfacht ein DNS das Surfen im Internet für User enorm. Denn man kann sich einen Domainnamen wie example.org einfach viel besser und leichter merken als die dazugehörige IP-Adresse 123.0.45.06.

Da es weltweit unzählige private, öffentliche und kommer-zielle Netzwerke gibt, kann es nun gemäß ICANN im Rahmen der Einführung der neuen Top-Level-Domains zu Konflikten zwischen den neuen Domains und solchen Internetadressen kommen, bei denen die neuen Bezeichnungen bereits als interne Adressen verwendet werden. Einhergehend mit der Aktivierung der neuen Domainendungen wie z. B. .berlin, .auto oder .club ist es möglich, dass netzinterne Anfragen einer bestimmten Domain nun versehentlich von einem öffentlicher DNS-Server und nicht dem internen Server beantwortet werden, für den die Anfrage eigentlich bestimmt war. In einem solchen Fall spricht man von Namenskollision. Anfragen an Ressourcen in privaten Netzwerken können auf diese Weise im öffentlichen Netz landen. Derartige Lecks in das öffentliche DNS entstehen meist durch fehlerhafte Netzkfonfigurationen oder die Nutzung veralteter Software.

Welcher Schaden den Betroffenen durch eine Kollision möglicherweise genau entsteht, ist bislang noch nicht abschlie-ßend geklärt. ICANN arbeitet jedoch aktuell daran, das Problem

zu entschärfen, und ist bemüht, sowohl Domaininhaber als auch Domainanwärter bestmöglich zu unterstützen. Die Organisati-on veröffentlichte zwischenzeitlich z. B. einen zwanzigseitigen „Guide to Name Collision Identification and Mitigation for IT Professionals“. Er wendet sich an IT-Profis wie Netzwerkadmi-nistratoren und beschreibt Strategien, um Routing-Konflikte zu vermeiden. Ein weiterer Ansatz sieht auf der Basis ausführlicher Analysen und Untersuchungen vor, ein sogenanntes „New gTLD Collision Occurrence Management Framework“ zu entwickeln. Bis es soweit ist, hat die ICANN individuelle „Collision Lists“ he-rausgegeben, welche die Begriffe aufführen, die für jede neue TLD zu sperren sind. Um ohne Verzögerung mit der Einführung der neuen TLDs beginnen zu können, müssen die Registries der neuen TLDs diese Sperrlisten komplett übernehmen, d. h., die dort enthaltenen Begriffe stehen zur Registrierung vorerst nicht zur Verfügung.

Währenddessen wird New-gTLD-Anwärtern die Möglichkeit eingeräumt, ihre Bewerbung fortzusetzen. Zwischen der Un-terzeichnung der Verträge mit ICANN und der Aktivierung der gesperrten Domains muss aber eine Wartezeit von mindestens 120 Tagen eingehalten werden. Danach können die meisten Registries ihre Domains anbieten, auch wenn das Rahmenwerk noch nicht vorliegt.

Kaum zu glauben, aber wahr: Durch die beschriebene Prob-lematik stehen eine große Zahl der interessanten Begriffe unter den neuen TLDs vorerst nicht zur Verfügung. Eine bittere Pille u. a. auch für alle Autohersteller, da es z. B. die Domains bmw.auto, mercedes.auto oder porsche.auto bis auf Weiteres erst einmal nicht geben wird.

› Weiterführende Informationen unter: www.icann.org

.WIKI

.LOVE

.CLOUD

.ECO

30 BTS NR. 21

2. Teil der Artikelserie „Verschlüsselung digitaler Kommunikation“

TLS, S/MIME + GnuPG: sicherer E-Mail Verkehr dank bewährter Verschlüsselungsverfahren

E-Mail-Verschlüsselung lohnt sich, wenn man sensible Daten wie Kontoinformationen, Zugangspasswörter oder Geschäftsgeheimnisse digital übertragen möchte. Geraten solche vertraulichen Inhalte in die Hände von Netzbetrügern, könnten diese beispielsweise die Kontrolle über das Mail-Konto ihres Opfers übernehmen, sich Zugang zu Online-Bank- und -Shop-Accounts verschaffen oder eine komplette digitale Identität auf sich übertragen. Mit welchen Fallstricken man beim E-Mail-Versand rechnen muss und welche Verschlüsselungsverfahren den besten Schutz bieten, zeigt der folgende Artikel.

31

π Die weltweiten Abhörskandale diverser Geheimdienste haben ebenso wie die enorme Anzahl an Hacking-Attacken im letzten Jahr dazu geführt, dass viele Nutzer sich bewusster um ihre Sicherheit im Netz kümmern. Bezug nehmend auf die Verstän-digung per E-Mail besteht allerdings noch Puffer nach oben. Aktuell scheuen immer noch viele Privatnutzer und Unterneh-men das Thema „E-Mail-Verschlüsselung“ und versenden ihre digitalen Nachrichten lieber ungeschützt. Dabei ist der Versand einer E-Mail vergleichbar mit dem einer Postkarte: Jeder, den die Nachricht passiert, kann mitlesen und den Inhalt verändern. Aufgrund dessen verdienen vertrauliche Nachrichten besonde-ren Schutz. Beim Postversand übernimmt diese Aufgabe der Briefumschlag, beim E-Mail-Verkehr die Verschlüsselung.

Ob eine Verschlüsselungslösung sinnvoll oder nötig ist, hängt speziell im privaten Bereich vom individuellen Nutzer-verhalten ab. Falls man dort ausschließlich belanglose E-Mails verschickt und auch sonst darauf achtet, dass im Internet keine vertraulichen Informationen über einen stehen, dann wird sich wahrscheinlich kein Hacker oder Geheimdienst für einen inter-essieren. Bei den meisten Nutzern ist es jedoch ein Leichtes, ein genaues Profil über sie zu erstellen: Geburtstagsdatum, Beruf und Firma stehen in Facebook und in der E-Mail für die Sam-melaktion eines Hochzeitsgeschenks schickt man schnell mal seine Kontoverbindung an zwanzig Empfänger. Das sind alles In-formationen, die ein gewiefter Angreifer missbrauchen könnte. Die Frage, ob man jetzt als Privatmann oder –frau E-Mail-Ver-schlüsselung braucht, muss daher grundsätzlich jeder für sich selbst beantworten. Bei Unternehmen hingegen ist die Sache klar: Von Kunden-Logins über Verschwiegenheitserklärungen und Angebote bis zu geheimen strategischen Plänen werden in der Praxis tagtäglich vertrauliche Informationen per E-Mail übertragen. Deshalb empfiehlt sich für Firmen grundsätzlich eine Verschlüsselungslösung. Diese orientiert sich daran, was und wie verschlüsselt werden soll: TLS codiert die Verbindung zum E-Mail-Anbieter und zurück. S/MIME und GnuPG verschlüs-seln die gesamte E-Mail.

TLS: Verschlüsselungsverfahren für die Verbindungssicherheit

Das TLS-Protokoll (Transport Layer Security, zu deutsch: Trans-portschichtsicherheit) geriet im April 2014 in die Schlagzeilen, als der Heartbleed Bug, ein äußerst gravierender Programmier-fehler, die Verschlüsselung, Schlüssel und Daten der mit der freien Software für TLS (OpenSSL) gesicherten Verbindungen im Internet gefährdete. Auch für die E-Mail-Kommunikation mit TLS wurde Alarm geschlagen, denn der Bug erlaubte es Angrei-fern, bestimmte Speicherbereiche auszulesen, in denen sich mitunter auch Schlüssel, Passwörter sowie andere vertrauliche Daten befunden haben. Der Fehler konnte zwar behoben werden, aber niemand weiß, wie viele Daten in der Zwischenzeit unfrei-willig ihren Besitzer gewechselt haben. Dennoch ist TLS als sicheres Verschlüsselungsverfahren anzusehen, speziell wenn es um die sichere Kommunikation zwischen zwei Nutzern bzw. Unternehmen geht. Voraussetzung dafür ist, dass ein Zertifikat einer öffentlichen Zertifizierungsstelle die Identität des Post-ausgangsservers bzw. dessen Betreibers auf Echtheit geprüft hat.

Beim Einsatz der TLS-Verschlüsselung wird die gesamte Kommunikation auf dem Weg zwischen zwei Servern zum Zeitpunkt der Übertragung (Tunnelverschlüsselung) codiert. D. h., dass neben dem eigentlichen Mail-Inhalt auch Metadaten wie Absender, Empfänger und Betreff verschlüsselt übertra-gen werden. Funktional betrachtet schiebt sich TLS als eigene Schicht zwischen das Übertragungssteuerungsprotokoll (TCP: Transmission Control Protocol) und die Anwendungs- und Dar-stellungsprotokolle. Ob SMTP (Simple Mail Transport Protocol), POP3 (Post Office Protokoll, Version 3) oder IMAP (Internet Message Access Protocol), TLS ist mit allen E-Mail-Protokollen vereinbar.

Mit TLS wird die E-Mail also „nur“ auf ihrem Weg zwischen dem Client des Nutzers und dem Mail-Server sowie auf dem Weg zu-rück verschlüsselt. Das bedeutet im Umkehrschluss, dass die Nachrichten auf den Servern unverschlüsselt bleiben, da die-se nicht mit TLS verschlüsselt sind. Das Gleiche gilt für unver-schlüsselte Verbindungen. Das ist z. B. der Fall, wenn man von einem GMX-Account eine E-Mail an einen Empfänger schickt, dessen Provider nicht mit TLS verschlüsselt. Will man hier einen Rundum-Schutz erreichen, ist man mit der Verschlüsselung des gesamten E-Mail-Verkehrs am besten bedient.

End-to-end-Verschlüsselung: die E-Mail wird zur Geheimnachricht

Durch die Verschlüsselung der kompletten E-Mail können nur noch der Absender und der Empfänger den Inhalt lesen, nicht aber unbefugte Dritte. Die folgende Tabelle zeigt eine Übersicht der symmetrischen, asymmetrischen und hybriden Verschlüsselung.

Dank TLS: sichere E-Mail „Made in Germany“

› Mit dem Ziel, die Sicherheit ihrer E-Mail-Nutzer zu erhöhen, lassen die vier deutschen Mail-Anbieter T-Online, GMX, Web.de und Freenet seit dem 1. April 2014 nur noch über TLS verschlüsselte Verbindungen für den Abruf und Versand von E-Mails zu.

32 BTS NR. 21

1 Das Bundesamt für Sicherheit in der Informationstechnik (BSI) erklärt das Prinzip der asymmetrischen Verschlüsselung anschaulich: Man hat einen Tresor mit einem Schnappschloss. Jeder kann etwas einschließen, da sich die Tür automatisch schließt (Public–Key-Prinzip). Zum Öffnen ist allerdings ein Schlüssel (Secret Key) erforderlich, über den nur der Tresor-Besitzer verfügt.

2 Den Public Key verteilt man am einfachsten, indem man jede E-Mail signiert. Der Schlüssel wird dann automatisch angehängt. Alternativ kann man den Schlüssel per E-Mail, über eine Website, auf CD oder über einen Key-Server verbreiten. Im Gegensatz zum öffentlichen Schlüssel muss der Secret Key geheim bleiben. Bevor man ihn auf dem PC ablegt, speichert man besser eine Kopie auf einem externen Datenträger. Für zusätzliche Sicherheit sorgt ein Ausdruck des Schlüssels im Tresor.

3 Die digitale Signatur bestätigt die Identität von Absender und Empfänger und prüft die Integrität einer E-Mail-Nachricht. Für jede digitale Signatur wird ein Hash-Wert ermittelt, der mit dem privaten Schlüssel des Absenders codiert, an die unverschlüsselte E-Mail angefügt und mit dieser übertragen wird. Der Empfänger überprüft die digitale Signatur, indem er selbst einen Hash-Wert erzeugt und diesen mit dem Wert des Absenders vergleicht.

4 Digitale Zertifikate sorgen bei der digitalen Signatur dafür, dass der öffentliche Schlüssel des Absenders authentifiziert werden kann. Um die Ausstellung, Verteilung und Prüfung der Zertifikate kümmert sich die Public-Key-Infrastruktur. Das komplexe System umfasst zahlreiche Bestandteile wie eine Zertifizierungsstelle, eine lokale Registrierungsstelle, eine Liste mit ungültigen Zertifikaten, Verzeichnis- und Validierungsdienste und eine Dokumentensammlung mit Arbeitsprinzipien.

Verschlüsselungsverfahren im Überblick

Verfahren Symmetrische Verschlüsselung (Secret-Key-Methode)

Asymmetrische Verschlüsselung (Public-Key-Methode)

Hybride Verschlüsselung

Merkmale › Ein Schlüssel für Ver- und Entschlüsselung

› Zwei Schlüssel für Ver- und Entschlüsselung

› Schlüsselpaar besteht aus öffentlichem und privatem Schlüssel

› Codierung erfolgt durch öffentlichen Schlüssel (Public Key)

› Decodierung erfolgt durch privaten Schlüssel (Secret Key)1

› Kombiniert symmetrische und asymmetrische Verschlüsse-lung

› Erzeugung eines zufälligen, digitalen Schlüssels (Session Key) für Ver- und Entschlüs-selung

› Symmetrische Codierung des Mail-Inhalts mit dem Session Key

› Asymmetrische Codierung des Session Key mit dem öffentlichen Schlüssel

› Versand der verschlüsselten Daten mit dem öffentlichen Schlüssel des Empfängers

› Asymmetrische Decodierung des Session Key mit dem privaten Schlüssel des Empfängers

› Entschlüsselung der Inhalte mit dem decodierten Session Key

Vorteile › Einfache Schlüsselverwaltung

› Schnell

› Bei ausreichender Schlüssel-länge sicher

› Sicher

› Weniger Schlüssel nötig als bei symmetrischen Verfahren

› Weniger Aufwand beim Geheimhalten des Schlüssels

› Einfache Schlüsselverteilung2

› Kombiniert die Vorteile von symmetrischer und asymmet-rischer Verschlüsselung

Nachteile › Secret Key darf nicht in die falschen Hände gelangen

› Umständliche Schlüsselüber-gabe (persönlich, per Post)

› Sehr aufwendig bei mehreren Beteiligten

› Hoher Rechenaufwand

› Zusätzliche Authentifizierung durch digitale Signatur3 und Public-Key-Infrastruktur (PKI)4 notwendig

› Keine

33

S/MIME oder GnuPG: Wer die Wahl hat, hat die Qual

Für die Verschlüsselung von E-Mails haben sich in der Praxis die hybriden Verfahren durchgesetzt. Aufgrund des hohen Verbrei-tungsgrades beschränkt sich der Artikel auf die Vorstellung der zwei gängigsten Hybridsysteme: S/MIME (Secure/Multipurpose Internet Mail Extensions) und GnuPG (GNU Privacy Guard).

Beide Verfahren nutzen eine Public-Key-Infrastruktur und werden sowohl für client- als auch serverbasierte Lösungen verwendet. Zwar funktionieren S/MIME und GnuPG nach dem gleichen Prinzip der hybriden Verschlüsselung, einige Unter-schiede machen die Systeme jedoch inkompatibel. Die größte Abweichung liegt in der Methode zur Authentifizierung: Bei S/MIME bestätigt eine vertrauenswürdige Zertifizierungsstelle die Echtheit der öffentlichen Schlüssel der Kommunikationsteilneh-mer per Zertifikat. Im Gegensatz dazu gewährleisten bei GnuPG die anderen Nutzer die Schlüsselidentitäten (Web of Trust).

Ob S/MIME oder GnuPG, letztlich bietet keines der beiden Verschlüsselungsverfahren mehr Vorteile als das andere. Ein großer Vorteil von S/MIME für Privatnutzer ist, dass die Software in den meisten E-Mail-Programmen schon vorinstalliert ist, während GnuPG nachträglich in den E-Mail-Client eingebunden werden muss. Dafür erfreut sich GnuPG im Firmenumfeld großer Beliebtheit. Das liegt zum einen an der Flexibilität und Praxis- tauglichkeit der freien Open-Source-Lösung, zum anderen am einfachen Aufbau der PKI.

Übrigens nutzt auch die ADACOR für die E-Mail-Verschlüs-selung eine GnuPG-basierte Lösung. Intern kommunizieren die Mitarbeiter seit jeher sicher miteinander und verschlüsseln Nachrichten und Dateien bei der Übertragung per E-Mail. Das Problem der unverschlüsselten E-Mail-Kommunikation stellte sich bisher nur beim elektronischen Nachrichtenaustausch mit Kunden und Partnern ohne PGP-Verschlüsselung. Zukünftig gibt es dafür eine Lösung, die sich auch kundenseitig implementie-ren lässt: Cloudbase Secure Transfer. Die letzte Ausgabe von ADACOR Behind The Scene beinhaltete dazu einen ausführlichen Bericht (http://resource.adacor.com/uploads/2014/04/BTS-20-Webedition2.pdf).

Hacker am Werk: das Kompromittieren von E-Mail-Verschlüsselung

Wenige Hacker sind technisch so perfekt ausgerüstet, dass sie aufwendige Berechnungen durchführen, Schlüssel ausprobieren oder eine Brute-Force-Attacke starten können, um an vertrau-

liche Informationen ihrer Opfer zu kommen. Häufiger folgen die Datendiebe einer perfideren Strategie, indem sie menschliche Schwachstellen ausnutzen. Der folgende Fall bietet dafür ein Paradebeispiel:

Die Erpressung ereignete sich im Januar und der Fall erregte in der Internetgemeinde großes Aufsehen. Die Reaktionen waren so stark, dass Twitter mittlerweile nichts anderes übrig blieb, als Naoki Hiroshima seinen Namen zurückzugeben. Trotzdem zeigt der Vorfall, wie leicht man ohne Expertenkenntnisse, nur aufgrund von krimineller Energie und menschlicher Fehlbarkeit, an die digitale Identität von anderen Nutzern kommen kann. Sol-che und ähnliche Hiobsbotschaften kursieren täglich durch die Medien. Das ist auf der einen Seite erschreckend, erhöht aber andererseits das Sicherheitsbewusstsein der Nutzer im Netz. Denn nur wer weiß, was mit seinen Daten passieren kann, wird sorgfältig mit ihnen umgehen und beim Schreiben von E-Mails das Thema „Verschlüsselung“ berücksichtigen.

So verlor Naoki Hiroshima seinen Twitter-Namen

Der Programmierer Naoki Hiroshima besaß einen Twitter-Namen, der aus nur einem Buch-staben bestand: @N. Für diesen Namen bekam er viele Kaufangebote. Bis zu 50.000 US-Dollar wurden ihm geboten. Ein dreister Betrüger wollte nicht so viel Geld ausgeben und versuchte mittels Erpressung an den Namen zu kommen. Er überlistete zunächst die Hotline des Be-zahldienstes PayPal, trickste anschließend den Domainanbieter GoDaddy aus und übernahm am Ende die digitale Identität seines Opfers. Mit der Drohung sämtliche Daten zu löschen, erpresste der Angreifer Naoki Hiroshima, ihm seinen Twitter-Account zu übertragen. Hiro-shima willigte ein, als er einsah, dass er keine Chance hatte, die Kontrolle über seine digitale Identität zurückzuerhalten. Der Angreifer gab ihm daraufhin alle seine Accounts zurück. Die ganze Story gibt es unter: https://medium.com/cyber-security/24eb09e026dd

ALEXANDER LAPP

Geschäftsführer I COO

ADACOR Hosting GmbH

Kaiserleistraße 51


TELEFON +49 69 90 50 89 26

TELEFAX +49 69 905089 29



5 1991 entwickelte Phil Zimmermann Pretty Good Privacy (PGP). PGP ist heutzutage nur noch als kostenpflichtige Software erhältlich. Alternativ zu PGP gibt es eine kostenfreie und quelloffene Variante namens OpenPGP bzw. GnuPG.

34 BTS NR. 21

IT-Sicherheit auf dem Prüfstand

Der OpenSSL Heartbleed Bug aus Sicht der ADACOR

Der 8. April 2014 startete mit einem Super-GAU für die Betreiber von Servern und Webseiten: Ein gravierender Fehler in der OpenSSL Library gefährdete die Verschlüsselung, Schlüssel und Daten der mit OpenSSL gesicherten Internetverbindungen. Da bei der ADACOR viele Kunden Betriebssysteme und Webserver auf ihren Systemen einsetzen, die mit OpenSSL arbeiten, brachte die Sicherheitslücke den Hoster in eine besondere Situation. Wie die ADACOR mit dieser umgegangen ist, erfahren Sie im folgenden Artikel.

π Am frühen Morgen des 8. April verbreiteten die IT-Nach-richtendienste Golem und Heise die schlimme Botschaft: Unabhängig voneinander hatte ein Team der finnischen Sicher-heitsfirma Codenomicon sowie das Sicherheitsteam von Google eine schwere Sicherheitslücke in OpenSSL entdeckt. Diese steckte im Code für die Heartbeat-Erweiterung von SSL, die zwei Jahre zuvor in OpenSSL eingeführt worden war. Der Bug betraf sämtliche Versionen von 1.0.1 bis einschließlich 1.0.1f.

Aufgrund des Softwarefehlers konnte der Client einen Teil des Arbeitsspeichers des Servers auslesen. Angreifer hätten da-durch zum Beispiel an private Keys zum Entschlüsseln der SSL-gesicherten Daten gelangen können. Besonders erschreckend: Von heute auf morgen war die bis dato als sicher geltende Verschlüsselung von Verbindungen via SSL (HTTPS) damit nicht mehr gewährleistet. Zum Glück stand sehr schnell ein Update „OpenSSL 1.0.1g“ zur Verfügung, mit dem sich die Sicherheits-lücke schließen ließ. Allerdings weiß man bis heute nicht, wie viele Personen die Sicherheitslücke bereits vorher entdeckt und ausgenutzt haben. Denn auf Server-Seite gab es keine Mög-lichkeit, einen in der Vergangenheit stattgefundenen Angriff zu erkennen. Das heißt, selbst wenn kein Einbruch bemerkt wurde, musste man aus Vorsorgegründen aktive Schutzmaßnahmen durchführen. Denn im schlimmsten Fall hätten alle Systeme kompromittiert sein können.

OpenSSL wird von einer Vielzahl von Server- und Client-software verwendet. Da der Verschlüsselungsdienst auch auf den Kundensystemen der ADACOR verbreitet ist, war der Hoster aufgerufen, nach Kenntnisnahme der Sicherheitslücke ein entsprechendes Notfallmanagement in die Wege zu leiten, die Systeme schnellstens zu sichern sowie die bestehenden Schlüsselzertifikate gegen neue auszutauschen.

Worst-Case-Szenario bei der ADACOR

Die Meldungen über das Vorhandensein des Heartbleed Bugs verbreiteten sich am Morgen des 8. April mit rasender Ge-schwindigkeit über die Medien. Auch die ADACOR-Kunden erfuh-

ren frühzeitig von der Sicherheitslücke. Die Frage, die sich ihnen stellte, lautete: „Sind meine Systeme betroffen und ist meine SSL-Kommunikation noch sicher?“ Zahlreiche Kunden kontak-tierten deswegen direkt den ADACOR Service Desk. Die Mitarbei-ter dort waren gefragt: Zum einen bestand ihre Aufgabe darin, die Kunden zu beruhigen, zum anderen mussten sie schnellst-möglich die Systeme sichern und weitere Schutzmaßnahmen wie den Zertifikatstausch in die Wege leiten. Denn die Kritikalität der Lücke war hoch. Trotzdem war es wichtig, im Rahmen der System-Updates mit Ruhe und Bedacht vorzugehen. Denn die zu patchenden Systeme waren allesamt produktiv. Somit hätte eine überstürzte Aktualisierung ohne rechtzeitige Ankündigung die Systemstabilität gefährden können.

Die Kunden der ADACOR konnten in jedem Fall schnell aufat-men. Als Anbieter von Managed Hosting übernimmt die ADACOR das Patch- und Systemmanagement der betreuten Kunden-systeme. Selbstverständlich auch in Ausnahmesituationen wie dieser, bei der die Administratoren die vielen heterogenen Kun-densysteme zum Großteil komplett individuell prüfen mussten, um anschließend individuelle Umsetzungspläne zu entwickeln, um die Systeme zu aktualisieren und um im Nachgang die SSL-Zertifikate auszutauschen.

Erschwerend kam hinzu, dass die Administratoren viele Systeme innerhalb kürzester Zeit prüfen und patchen mussten. Der Umfang der Tätigkeiten überstieg das reguläre Change- und Patch-Volumen pro Tag um ein Vielfaches. Gleichzeitig muss-ten die Mitarbeiter darauf achten, dass das Tagesgeschäft mit seinen planmäßigen Wartungen, Changes und Setup-Projekten reibungslos funktionierte.

Das gesamte service-orientierte Vorgehen der ADACOR war für die Kunden ein großer Vorteil. Denn bei einem Standard-Hoster wären die Systeme nicht individuell, sondern einfach vollautomatisch aktualisiert worden.

35

ANDREAS BACHMANN

Geschäftsführer | CIO

ADACOR Hosting GmbH

Kaiserleistraße 51


TELEFON +49 69 905089-22

TELEFAX +49 69 905089-29



Behandlung des Super-Incidents im Zeitraffer

08:00 Uhr Die Administratoren der ADACOR lesen die Nach-richt zum Heartbleed Bug mit Beginn ihres regulä-ren Arbeitstages. Ihnen ist sofort klar: Die Lücke ist kritisch und sie betrifft die ADACOR umfassend. Die zuständigen Mitarbeiter reagieren unverzüglich, indem sie das ADACOR IT-Sicherheitsteam (SEC-Team) informieren.

15:14 Uhr Eine erste Informationsmail wird an alle ADA-COR-Kunden verschickt. Die Nachricht enthält den Hinweis, dass der Hoster gerade untersucht, welche Systeme betroffen sind und dass alle be-troffenen Kunden separat über das weitere Vor-gehen informiert werden.

09:00 Uhr Eine eigens gebildete Taskforce (bestehend aus dem SEC-Team und zwei Administratoren) nimmt ihre Arbeit auf. Im ersten Schritt steht die Untersu-chung und Analyse der Meldungen aus den Medien sowie der Informationen von Codenomicon an. Die daraus resultierenden Ergebnisse fließen in einen Einschätzungsbericht zu den Auswirkungen auf die ADACOR-Kunden ein.

15:55 Uhr Die Systemanalyse ist abgeschlossen. Es liegt eine vollständige Liste der betroffenen Systeme vor.

11:00 Uhr Die Taskforce diskutiert die Analyseergebnisse und legte die nächsten Arbeitsschritte fest: die präzise Ermittlung der betroffenen Kundensyste-me inklusive einer Priorisierung nach Kritikalität.

16:20 Uhr In einem weiteren Meeting der Taskforce werden die Priorisierung der Systeme sowie der genaue Ablauf der Wartungsfenster und Patch-Installa-tionen festgelegt.

12:15 Uhr In einem Meeting der Taskforce mit der Geschäfts-führung und den Teamleitern wird das weitere Vorgehen festgelegt. Zusätzlich bestimmen die Be-teiligten die erforderlichen Kommunikations- und Dokumentationsmaßnahmen. Beispielsweise wer-den erste Texte für die Informationsmails an die Kunden erstellt sowie die System-Updates geplant.

18:00 Uhr Es erfolgt ein zentraler Patch der betroffene Sys-temmanagement-Server der ADACOR.

13:38 Uhr Alle ADACOR-Mitarbeiter werden per Rundmail über die Situation in Kenntnis gesetzt und dar-über informiert, wie sie Kunden bei Anfragen am besten unterstützen können.

19:00 Uhr Alle betroffenen Kunden erhalten eine Wartungs-ankündigung für die nächsten 24 Stunden. Da-rin wird auch eine weitere Mail avisiert, die zwei Stunden vor dem Wartungsfenster verschickt wird und in der das Wartungsfenster und die zu pat-chenden Systeme genauer spezifiziert werden.

13:44 Uhr Im internen Wiki der ADACOR werden Wissensar-tikel zur Dokumentation der Abläufe, der Update-Prozesse der verschiedenen Systeme sowie der Kommunikation mit den Kunden angelegt und mit Inhalt gefüllt.

Ab 19:10 Uhr

Die Wartung startet nach Rücksprache und Defini-tion von Wartungsfenstern mit den ersten Kunden entsprechend der priorisierten Systemliste. Ab die-sem Zeitpunkt werden binnen 48 Stunden zahlrei-che Wartungsfenster mit Kunden vereinbart und durchgeführt und alle betroffenen Systeme aktua-lisiert und getestet. Nach Abschluss der Systemak-tualisierungen wurde mit jedem Kunden individuell der Austausch der SSL-Zertifikate angegangen.

Eine der bisher gravierendsten Sicherheitslücken

Trotz der Brisanz des Heartbleed Bugs, konnten die OpenSSL-Entwickler die Sicherheitslücke mit Unterstützung einiger zu-sätzlicher Codezeilen relativ leicht korrigieren. Für die ADACOR war es zusätzlich eine Hilfe, dass das betriebsinterne Notfallma-nagement einwandfrei funktionierte. Am Ende zeigt sich Andre-as Bachmann, CIO und Geschäftsführer der ADACOR, zufrieden: „Sämtliche internen Mechanismen, Prozesse und Verantwort-lichkeiten, die in unserem Notfallmanagement eingebunden sind, wurden am 8. April 2014 durch den Heartbleed Bug einem Stresstest unterzogen. Die Reaktionen aller Beteiligten führten jedoch dazu, dass wir die Situation jederzeit unter Kontrolle hatten: Zunächst wurde die Situation über die implementierten Prozesswege erfasst und gemeldet. Sofort nach Bekanntwerden des Bugs wurde eine Taskforce aus den für die IT-Sicherheit ver-antwortlichen Personen gebildet. Unsere Lage und die Auswir-kungen des Fehlers wurden ausreichend analysiert, sodass die

Updates innerhalb kürzester Zeit eingespielt werden konnten. Es hat alles so funktioniert, wie es sollte!“

Übrigens gingen nicht alle Unternehmen so professionell mit der Beseitigung des Heartbleed Bugs um, wie die ADACOR. Laut golem.de waren im Juni immer noch mindestens 300.000 über das Internet erreichbare Server aufgrund fehlender Patches an-fällig für die Sicherheitslücke.

36 BTS NR. 21

TEAMADACOR EVENTS

37

Team-Events

Gemeinsam auch mal abschalten!Nach der Arbeit mit den Kollegen gemeinsam noch etwas unternehmen und so den Teamgeist stärken? Ja klar! Das dachten sich zumindest die Geschäftsführer der ADACOR Hosting GmbH und erarbeiteten gemeinsam mit Kiki Radicke, Marketingverantwortliche bei ADACOR, eine Reihe von Veranstaltungen, zu denen die Mitarbeiter fortan alle sechs bis acht Wochen eingeladen werden. Die Teilnahme ist selbstverständlich freiwillig.

π „Die tägliche Mittagspause, das alljährliche Sommerfest und die Weihnachtsfeier waren uns einfach nicht genug, um mit Kollegen und Mitarbeitern auch mal über die Arbeit hinaus ins Gespräch zu kommen“, erklärt Kiki Radicke die Beweggründe für die Einführung der Team-Events. „Mit den neuen Events wollen wir einen lockeren Rahmen für ein zwangloses Zusammensein jenseits von Hierarchien und stressigen Projekten schaffen. Denn die Teams arbeiten hart und konzentriert, da ist es wichtig, hin und wieder aktiv einen Ausgleich anzubieten.“

Hinzu kommt, dass viele der technikbegeisterten Mitarbei-ter auch einen Großteil ihrer Freizeit vor dem Computer verbrin-gen. Dabei ist es mit Blick auf die Gesundheit wichtig, den Fokus regelmäßig auch mal auf etwas anderes zu richten, die Arbeit hinter sich zu lassen und sich gezielt zu erholen. ADACOR setzt deshalb bei den Team-Events ganz bewusst auf Veranstaltun-gen fernab jeglicher Computerthematik. Das Angebot ist vielfäl-tig und reicht vom Bogenschießen über Weinproben bis hin zum gemeinsamen Besuch eines Klettergartens. Es ist also für jeden etwas dabei.

38 BTS NR. 21

Neues von ADACOR

Das Infrastrukturteam bekommt Verstärkung

Seit Februar dieses Jahres unterstützt Marc Heinz das Infrastrukturteam der ADACOR Hosting GmbH. Mit seiner Ausbildung zum Fachinformatiker für Systemintegration hat der 30-Jährige bereits vor einigen Jahren sein Hobby zum Beruf gemacht und seitdem umfassende Berufserfahrung gesammelt. Bei ADACOR wirkt er aktuell an der Entwicklung der neuen Cloudbase-Plattform mit. Zu seinen Aufgaben zählen u. a. das Einrichten und die Konfiguration der dazugehörigen Infrastruktur für den Bereich CLOUDBASE-vServer.

π Auf die ADACOR aufmerksam geworden war er durch einen befreundeten Kollegen. Eine Bewerbung war schnell geschrie-ben und nach dem Vorstellungsgespräch war er sich sicher: Die Kollegen sind nett, die Aufgaben spannend und ADACOR bietet interessante Entwicklungsperspektiven. Von seiner Seite stand einem Wechsel zur ADACOR nichts mehr im Weg. Auch für ADACOR war nach dem Gespräch klar. Das passt!

„Wir suchen immer wieder qualifizierte Mitarbeiter, die sich gut ins Team integrieren und keine Angst davor haben, technisches Neuland zu betreten.“

„Marc hat schon einige Jahre Berufserfahrung, während derer er sich bereits ausgiebig mit ähnlichen Technologien beschäftigt hat, wie sie auch hier bei uns zum Einsatz kommen. Davon pro-fitieren wir natürlich“, erklärt Alexander Lapp, Geschäftsführer und COO bei ADACOR. „Er arbeitet strukturiert und ist motiviert, sich selbstständig und eigeninitiativ in neue Themen einzuarbei-ten. Ein echter Autodidakt. Deshalb haben wir ihn auch von Anfang an mit Aufgaben betraut, bei denen er diese Fähigkeiten und sein

fachliches Know-how, das dank seiner regen Aktivität in Spezia-listenforen immer up to date ist, bestmöglich einbringen kann.“

VORSCHAUAuch in der Herbstausgabe der Behind The Scene erwarten Sie wieder viele abwechslungsreiche Themen rund um das Thema Hosting. Wir stellen Ihnen z. B. die adesso hosting services GmbH vor - ein Joint Venture von adesso und ADACOR. Im Interview erklärt Joachim Seidler, wie es dazu kam und welche Entwicklungen die Themen Complex Hosting und Cloud Computing zu-künftig vermutlich einschlagen werden. Außerdem mit dabei: Teil 3 unserer Serie zu Verschlüs-selungstechniken, Neuerungen bei der Helpdesk-Software OTRS, ein Bericht zur Beta-Testphase unserer Cloudbase und vieles mehr.

39

UN Global Compact - ADACOR veröffentlicht 2. Fortschrittsbericht π Mit ihrem Beitritt zum UN Global Com-

pact im Mai 2012 hat sich ADACOR zur jährlichen Erstellung eines Fortschritts-berichts verpflichtet. Der UN Global Com-pact ist eine Initiative für Unternehmen, die sich verpflichten wollen, ihre Ge-schäftstätigkeiten und Strategien an zehn universell anerkannten Prinzipien aus den Bereichen Menschenrechte, Arbeitsnor-men, Umweltschutz und Korruptions-bekämpfung auszurichten. Die ADACOR Hosting GmbH bekennt sich öffentlich zu diesen Prinzipien und beschreibt in ihrem

diesjährigen Fortschrittsbericht wieder mannigfaltige Maßnahmen, die das Un-ternehmen zwischenzeitlich implemen-tiert hat, um Nachhaltigkeit fest in der Unternehmensstrategie zu verankern und die Handlungsgrundsätze des UN Global Compact unternehmensintern mit Leben zu füllen.

Der vollständige Bericht kann auf der Homepage der ADACOR Hosting GmbH oder auf der Internetseite des UN Global Compact (www.unglobalcompact.org) eingesehen werden.

WIR SAGEN DANKE!Diesmal geht ein großes Dankeschön für die inhalt-liche Unterstützung und die konstruktive Zusam-menarbeit bei der Erstellung dieser Ausgabe an das gesamte ADACOR-Team.

ADACOR wird Mitglied der Umweltallianz HessenSeit Juni 2014 ist die ADACOR Hos-

ting GmbH Mitglied bei der Umweltallianz Hessen, eine Kooperation der hessischen Landesregierung, der hessischen Wirt-schaft und den Kommunen. Ziel der Allianz ist es, ökologische, ökonomische und soziale Ziele in Übereinstimmung zu bringen und die nachhaltige Entwicklung des Bundeslandes Hessen zu unterstüt-zen. Und dies alles ohne zermürbende Bürokratie. Vielmehr verfolgt man den

Ansatz, alle Beteiligten zu konstruktiven und partnerschaftlichen Gesprächen an einen Tisch zu bitten. Im Fokus stehen Umweltschutz und Ressourcenschonung sowie eine langfristig nachhaltige Wirt-schaftsentwicklung.

Im Zuge der Kooperation verpflichtet sich die hessische Wirtschaft neben der Einhaltung gesetzlicher Umweltvorschrif-ten zu freiwilligem Engagement in Sachen Umweltschutz. Der Beitrag der hessi-

schen Landesregierung besteht in der Vereinfachung von Umweltvorschriften und der Schaffung umweltfreundlicher und wirtschaftsfördernder politischer Rahmenbedingungen. Hierdurch soll der Wirtschaftsstandort Hessen nachhaltig gestärkt werden und langfristig wettbe-werbsfähig bleiben.

Weiterführende Informationen unter: www.umweltallianz.de

expect more

Herausgeber:ADACOR Hosting GmbHEmmastraße 70 A 45130 Essen

Geschäftsführung:Thomas Wittbecker Andreas Bachman Patrick FendAlexander Lapp

WWW.ADACOR.COM

Documents

Fallstricke bei der Berechnung von Verfügbarkeit … · BTS NR. 21 INHALT 3 EDITORIAL 4 BASIS-IT-SICHERHEITSANALYSE – Risikomanagement in KMUs 8 TEAMWORK – Das IT-Sicherheitsteam