Agenda. Unternehmen T-Systems Multimedia Solutions Akkreditiertes Testzentrum Prüfen der Performance. Prüfen der Sicherheit

Transkript

1 T-Systems Multimedia Solutions GmbH. Test- und Integrationszentrum. Prüfen der Performanz und Sicherheit von Web-Anwendungen

2 Agenda. Unternehmen T-Systems Multimedia Solutions Akkreditiertes Testzentrum Prüfen der Performance Performancetest Diagnose Überwachung im Betrieb Prüfen der Sicherheit Das Umfeld Konzeption (Datenschutz und Datensicherheit) Sicherheitstest Referenten: Matthias Schneider Leiter Testzentrum, T-Systems Multimedia Solutions GmbH Thomas Haase Leiter Bereich Security im Testzentrum, T- Systems Multimedia Solutions GmbH Seite 1

3 T-Systems Multimedia Solutions. Web 2.0-Vordenker Tim O Reilly über uns. If web 2.0 is about harnessing collective intelligence, then a web 2.0 company is one that harnesses the intelligence of its employees and customers. T-Systems aims to be such a company! Tim O Reilly über die T-Systems MMS Seite 2

4 T-Systems Multimedia Solutions. Das sind wir. Gründung: Januar 1995 Umsatz: 64,9 Mio. Euro (2006) Geschäftsführer: Dr. Klaus Radermacher Peter Klingenburg Mitarbeiter*: Hauptsitz: Gesellschafter: 362 Eigenpersonal 291 Fremdpersonal 136 Lernende Dresden T-Systems Business Services GmbH *Stand: Dezember 2006 Weitere Informationen im Internet Seite 3

5 T-Systems Multimedia Solutions. Wir praktizieren Kundennähe. Hamburg Bonn Berlin Jena Dresden Freiburg Stuttgart München Seite 4

6 T-Systems Multimedia Solutions. Bestleistungen in punkto Umsatz, Qualität und Personalarbeit. New Media Service Ranking: zum vierten Mal in Folge auf Platz 1 als umsatzstärkstes Unternehmen der Branche (2006) EFQM Excellence Award: Preisträger in der Kategorie People Development and Involvement (2006) sowie Continuous Learning, Innovation and Improvement (2005) Ludwig-Erhard-Preis: Auszeichnung als bestes Mittelständisches Unternehmen (2005 und 2006) BestPersAward: Erster Platz in der Kategorie Entlohnung (2006) und Kommunikation (2005) Seite 5

7 Agenda. Unternehmen T-Systems Multimedia Solutions Akkreditiertes Testzentrum Prüfen der Performance Performancetest Diagnose Überwachung im Betrieb Prüfen der Sicherheit Das Umfeld Konzeption (Datenschutz und Datensicherheit) Sicherheitstest Seite 6

8 Akkreditiertes Testzentrum. Warum ein unabhängiges Testzentrum? Der Test soll von Personen durchgeführt werden, die nicht an der Programmierung der Software-Module beteiligt waren. Wenn Entwickler selbst testen, suchen sie nach einer Bestätigung der Gültigkeit ihrer theoretischen Überlegungen. Testzentren können besser ein ausgereiftes methodisches Vorgehen für den Test entwickeln und bieten alle Tests aus einer Hand an. auch spezielle Testarten (Security, Performance, Usability) können angeboten werden zur Überprüfung nichtfunktionaler Anforderungen (Toolkosten, Know How) kostengünstigere Durchführung Unabhängigkeit: Die Testergebnisse sind nicht durch Entwicklung oder andere Bereiche beeinflussbar. Seite 7

9 Akkreditiertes Testzentrum. Erstes offiziell anerkanntes Software- Prüflabor der Internet- und Multimediabranche. Das TIZ der T-Systems MMS ist das einzige akkreditierte Softwareprüflabor der Bundesrepublik in der Internet- und Multimediabranche. Die Akkreditierung erfolgte durch die Deutsche Akkreditierungsstelle Technik (DATech e.v.), die Mitglied im Deutschen Akkreditierungsrat (DAR) ist. Durch die Akkreditierung wird dem TIZ der T-Systems MMS bescheinigt: Das Testlabor arbeitet nach ausgereiften Methoden und Verfahren. Die Mitarbeiter verfügen über hervorragende Kompetenzen. Die Infrastruktur des Testlabors erfüllt die hohen technischen Anforderungen. Das Management und die Prozesse sind auf einem hohen Niveau. Seite 8

10 Akkreditiertes Testzentrum. Vorteile durch internationale Standards. Wenn unsere Kunden uns mit der Prüfung ihrer Anwendung beauftragen, profitieren Sie in mehrfacher Hinsicht: Sofern die Pflichtforderungen der Norm erfüllt sind, erhält der Auftraggeber eine Bescheinigung über die Konformität der geprüften Software zur Norm DIN ISO/IEC 12119: Über die Mitgliedschaft des Deutschen Akkreditierungsrates in internationalen Organisationen besteht weltweite Anerkennung der Testergebnisse. Auf dieser Basis kann ein Zertifikat durch den TÜV ausgestellt werden. Eine Zertifizierung schafft Vertrauen bei den Endkunden und kann ein Vorteil bei der Vermarktung sein. Seite 9

11 Akkreditiertes Testzentrum. Warum Testen? Seite 10

12 Akkreditiertes Testzentrum. Warum Testen? Standish CHAOS Report 2004: Chaos History von IT-Projekten. 2006: 35 % erfolgreich, 19 % gescheitert, 46% Zeit Budgetüberschreitung) Seite 11

13 Akkreditiertes Testzentrum. Warum Testen? Forrester Research: allein in Deutschland Ausfälle von jährlich 85 Milliarden Euro durch mangelnde oder unzureichende Testing - Maßnahmen. Giga Information Group: Softwarefehler, die erst in der Post- Production-Phase entdeckt werden, verursachen wesentlich höhere Kosten als wenn sie bereits während der Entwicklung behoben worden wären. Seite 12

14 Akkreditiertes Testzentrum. QS /Test im Applikationslebenszyklus. Audit; Prozessverbesserungen ableiten Optimierung Anforderungen Qualitätsplan tsplan aufsetzen; Kennzahlen definieren Anforderungen prüfen Geschäftsprozesse überwachen Betrieb QM Design Reviews durchführen hren Know how sichern und verteilen Einführung Realisierung Tests spezifizieren Code Quality Management etablieren Meilenstein-Reviews Quality Gates implementieren! Tests durchführen hren Lieferungen checken Seite 13

15 Akkreditiertes Testzentrum. Kernaspekte einer übergreifende Qualitätssicherung. vollständige und konsolidierte Beschreibung der Anforderungen. Etablierung von Quality Gates an den Schnittstellen der Life-Cycle- Phasen. Prüfen der korrekten Übertragung der Anforderungen in DV- Konzept, Implementierung, usw. Definition von Kriterien für die Bereitstellung zum Test und Abnahmekriterien (Fehlerkorridore). Frühzeitige Qualitätssicherung schon bei den Lieferanten (Audits, Reviews, Monitoring, Code Quality Management). Applikationsübergreifende Sicht: Berücksichtigung von Anforderungen, die sich aus der Einbettung in eine Applikationslandschaft ergeben. Seite 14

16 Akkreditiertes Testzentrum. Zu prüfende Qualitätsmerkmale. Systematik entspricht den DIN-ISO- Normen 9126 und Qualitätsmerkmale von Softwaresystemen: Funktionsumfang kann die Software alle Aufgaben erfüllen? Zuverlässigkeit wie reagiert das System auf die Fehleingaben? Benutzbarkeit ist das System verständlich und leicht bedienbar? Effizienz wie sind die Antwortzeiten? Änderbarkeit kann die Software erweitert werden? Übertragbarkeit läuft die Software unter verschiedenen Betriebssystemen oder Browsern? Seite 15

17 Akkreditiertes Testzentrum. Auswahl der anzuwendenden Testarten. Sicherheit der web- Anwendungen Lauffähigkeit unter relevanten System- Konfigurationen Antwortzeitverhalten im Normalfall Korrektheit der einzelnen fachlichen Funktionen Funktionstest Penetrationstest Konfigurationstest Lasttest Belastung bis zu den angegebenen Grenzwerten /über längere Zeit Verständlichkeit, Erlernbarkeit, Übersichtlichkeit, Bedienbarkeit und Steuerbarkeit Usabilitytest Installationstest Accessibilityevaluation Dokumentations- Prüfung Vollständigkeit, Richtigkeit, Widerspruchsfreiheit, Verständlichkeit, Übersichtlichkeit Installierbarkeit des Softwaresystems Barrierefreiheit Seite 16

18 Akkreditiertes Testzentrum. Testorganisation. Testauswertung Testdurchführung Testkonzeption Testvorbereitung Teststrategie und Testziele Testumfang Teststufen Testvoraussetzungen Testumgebung Bedarfsanalyse zur Testautomatisierung Toolauswahl QS Maßnahmen Ressourcen Fehlerklassen und Fehlerworkflow Risikomanagement Testdaten Klassifizierung Testobjekte auf Basis A/B/C-Analyse Erarbeitung Testfälle -> Testspezifikation Erstellung der Testscripte Erstellung der Testdaten Bereitstellung der Testumgebung Installation Konfiguration der Testtools Annahmetest Testdurchführung nach Testspezifikation Protokollieren der Testergebnisse Erstellung der Fehlermeldungen Re-Test Erstellung der periodischen Berichte Bewertung der Testergebnisse Überprüfen der Abnahmekriterien Dokumentation / Bericht Zertifizierung Freigabe Seite 17

19 Akkreditiertes Testzentrum. Teststufen bis zur Abnahme. Abnahmetest Durchführung von Test der Geschäftsprozesse aus Kundensicht Vollständige Geschäftsprozesse Installation und Konfiguration Schnittstellen benachbarte Systeme Reaktion auf System-Probleme Funktionalität Fehlerbehandlung Oberfläche Integrationstest Komponententest Systemtest Schnittstellen Performance Ausfallsicherheit Entwicklertest Seite 18

20 Agenda. Unternehmen T-Systems Multimedia Solutions Akkreditiertes Testzentrum Prüfen der Performance Performancetest Diagnose Überwachung im Betrieb Prüfen der Sicherheit Seite 19

21 Prüfen der Performance. Zielstellung. Beantwortung folgender Fragen: Wie viele parallele Nutzer / Sessions verkraftet die Anwendung? Welche Anzahl Transaktionen kann das System verarbeiten? Welche Wartezeiten erlebt der Nutzer dabei? Wie stabil verhält sich das System, wie ist es ausgelastet? Wo liegen die Performance- Engpässe (Server, Netz, Anwendung)? Bei welchen Belastungen muss die Hardware ausgebaut werden? Seite 20

22 Prüfen der Performance. Begriffsklärung Performancetest Messung des Antwortzeitverhaltens/Skalierungsverhaltens eines Systems steht im Vordergrund. Es werden kürzere Tests mit steigenden Laststufen angewendet. Lasttest Überprüfung des Systemverhaltens und der Stabilität stehen im Vordergrund. Es eignen sich Langzeittests mit der erwarteten Wirkbetriebslast. Seite 21

23 Prüfen der Performance. Zielstellung - Skalierbarkeit. Mit zunehmender Auslastung kommt ein exponentielles Antwortzeitverhalten zum Tragen Kleine Auslastungssteigerung hat großes Delta in den Antwortzeiten zur Folge Konsequenz: Zugesicherte SLA können nicht mehr gewährleistet werden Antwortzeitverhalten 45,00 40,00 35,00 30,00 Antwortzeit / s 25,00 20,00 15,00 10,00 5,00 0,00 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Serverauslastung Seite 22

24 Prüfen der Performance. Zielstellung Systemverhalten. Kontrolle der Systemauslastung (CPU, Speicher, I/O) Stabilität des Systems unter hoher Belastung und im Langzeitbetrieb. Memory leaks und permanent steigende Prozesszahl sind Beispiele für Probleme. Steigende Anzahl Java-Prozesse während eines Testlaufs Seite 23

25 Prüfen der Performance. Zielstellung Fehlerverhalten. Manche Fehler treten erst unter Last auf, sind also im Funktionstest nicht zu finden. Nur ein Teil der Besucher ist betroffen. möglicherweise nur sporadisches Auftreten. Seite 24

26 Prüfen der Performance. Mengengerüste. Datenbasis: Zugriffsstatistiken aus Server-Logs (Betriebsanalyse) Vertriebsprognosen Marketingsicht (Popularität, Besucherrate, Verweildauer, Besuchstiefe) Erfahrungswerte, Best Practices Größtmögliche Realitätstreue: durchschnittliches Lastaufkommen, Spitzen, Lastverteilung Burstiness (Marketing-Aktionen, spektakuläre News...) Popularität von Dokumenten, Dokumentengröße Seite 25

27 Prüfen der Performance. Lastprofile. Realistisches Lastprofil AllDay-Workload: Performance-Ermittlung unter realistischem Lastverlauf unter Berücksichtigung vorhandener Monats-, Wochen- und Tagesganglinien Hypothetische Lastprofile Ramp up - Steady state: Skalierungstest, Stresstest, Stufenweise Lasterhöhung Steady state: Dauerlasttest, Konstante Last über langen Zeitraum, Systeminstabilität aufgrund von Memory leaks Ramp up: Steiler Anstieg der Lasterhöhung, Simulation von Lastspitzen Dynamischer Workload: Agiler Antest, Kalibrierung der ermittelten Baseline Seite 26

28 Prüfen der Performance. Lastprofile - Beispiele. AllDay-Wokload ( eingedampfter Tagesverlauf) Ramp up - Steady state (in der Analyse bleiben Ramp up Phasen unberücksichtigt, diese dienen nur zur sanften Annäherung an die nächste Laststufe. Ein senkrechter Anstieg wäre unrealistisch und würde das Systemverhalten im Skalierungstest verfälschen) Seite 27

29 Prüfen der Performance. Lastprofile - Beispiele. Steady state (auch hier wird die Rampe rausgemessen) Ramp up (Simulation von Lastspitzen für Stresstest; SW-Systeme reagieren auf Lastdynamik ähnlich wie mechanische und auch elektrotechnische Systeme. Nicht nur die Höhe der Last ist ausschlaggebend, sondern auch die Steilheit der Laststeigerung, Laststöße sind extreme Belastungen für dynamische Systeme. Seite 28

30 Prüfen der Performance. Mengengerüste. Quelle: DIA-Sem. Prof. Dr. Quibeldey-Cirkel Seite 29

31 Prüfen der Performance. Mengengerüste. Quelle: DIA-Sem. Prof. Dr. Quibeldey-Cirkel Seite 30

32 Prüfen der Performance. Mengengerüste Beispiel. Lieferantenportal der Deutschen Telekom AG: Testobjekt: Auftragnehmer-Portal Auftragnehmer führen Kundenaufträge im Auftrag des Technischen Kundendienstes aus Elektronische Übergabe der Auftragsdaten an Auftragnehmer Alle Aufträge werden dem Auftragnehmer über das AN-Portal zur Verfügung gestellt und können durch den Auftragnehmer auf elektronischem Weg übernommen und zurück gesendet werden Die Leistungserfassung des Auftragnehmers wird ebenfalls auf elektronischem Weg durchgeführt und zurück an das AN-Portal Seite 31

33 Prüfen der Performance. Mengengerüste Beispiel. Die Tests werden auf folgendem Nutzer, Firmen und Auftragsbestand durchgeführt: Firmengröße Aufträge Aufträge je User Anzahl User User/Firma Anzahl Firmen klein mittel groß SUMME Tabelle 1 Verteilung der Aufträge auf User und Firmen Die Testdaten werden für die Testdurchführung in drei CSV-Files aufgeteilt, damit eine Zuordnung der Firmen auf die Testprozesse stattfinden kann. Firmengröße klein userfk.csv Firmengröße mittel userfm.csv Firmengröße groß userfg.csv Seite 32

34 Prüfen der Performance. Mengengerüste Beispiel Szenario Morgens Gruppe GP Name Firmengröß e Baselin e [s] Step s Thinktim e [s] runtim e [s] run / h / VU max. TA / h bei 100% Teststufen % % ANNAHME ANNAHME groß ABRECHNUN G ANNAHME klein ANNAHME mittel ABRECHNUN G ABRECHNUN G ABRECHNUN G Tabelle 1 Mengengerüst für den Skalierungstest "Morgens" groß klein mittel % 100 % Summe virtuelle Nutzer: Jede durchgeführte Transaktion (siehe max. TA / h bei 100 %) entspricht der Bearbeitung eines Auftrages. Seite 33

35 Prüfen der Performance. Mengengerüste Beispiel Szenario Abends Für die Durchführung des Abend Szenarios werden bereits abgearbeitete Verträge im System benötigt. Um hier keine zusätzlichen Aufwände zur Testdatenerzeugung zu generieren soll nach Durchführung eines Morgenszenarios der Datenbestand gesichert werden. Dieser kann dann je nach Bedarf neu eingespielt werden. GP Gruppe GP - Name Firmengröß e Baselin e [s] Step s Thinktim e [s] runtim e [s] run / h / VU max. TA / h bei 100% Teststufen ANNAHME ANNAHME groß ABRECHNUN G ANNAHME klein ANNAHME mittel ABRECHNUN G ABRECHNUN G ABRECHNUN G Tabelle 1 Mengengerüst für den Skalierungstest "Abends" groß klein mittel % 50 % 75 % 100 % Summe virtuelle Nutzer: Jede durchgeführte Transaktion (siehe max. TA / h bei 100 %) entspricht der Bearbeitung eines Auftrages. Seite 34

36 Prüfen der Performance. Prinzip. Überwachung der Agenten Ergebnis -analyse Erzeugung der Anfragen Serverüberwachung in Realzeit TrueLog Überprüfung der Antworten Testsystem Controller Last- Agenten Virtuelle Benutzer Seite 35

37 Prüfen der Performance. Methodisches Vorgehen Konzeption / Planung. Festlegung der Testziele Festlegung der Aufgaben, Verantwortlichkeiten und Rollen Festlegung der Testumgebung (Hardware, Softwarestände, Accounts,...) Definition der zu testenden Geschäftsvorfälle der Anwendung Definition des Mengengerüstes auf Basis aktueller Zugriffsstatistiken, Ganglinien Planung Testdatenmanagement Definition der durchzuführenden Testarten (Performancetest, Stabilitätstest, Dauerlasttest) Definition von Testszenarien Festlegung der durchzuführenden Testläufe mit den einzelnen Testszenarien Abstimmung über den Auswertungsumfang (erwartete Zeiten, Werte, Monitore) Seite 36

38 Prüfen der Performance. Methodisches Vorgehen Vorbereitung. Technische Vorbereitung Installation / Patchen der Lastagenten und Controller Netzwerktechnische Einbindung der Agenten / Controller in Testsystem Vergabe von IP-Adressen Zugänge / Accounts für das Monitoring (rexec, rstat, perfmon,...) Zeitsynchronisation Erstellung der Lasttestskripte zur Simulation der virtuellen Nutzer für die definierten Geschäftsprozesse Parametrisierung der Skripte mit den unterschiedlichen Nutzerparametern (z. B. Logins, unterschiedliche Eingaben bzw. Auswahl der Nutzer) Zusammenstellen der definierten Testszenarien im Lasttesttool unter Verwendung der Einzelskripte Kalibrierung der ermittelten Baselines mit agilem Antest Durchführung von Probeläufen mit den Testskripten und dem Testdatenbestand. Feststellen der Belastbarkeit der T&A Plattform und damit der Eignung für die Lasttests (Proof of Concept) Anlegen eines definierten Testdatenbestandes Seite 37

39 Prüfen der Performance. Methodisches Vorgehen Durchführung. Ausführung der im Testkonzept geplanten Testläufe ggf. Wiederholung der Testläufe (Reproduzierbarkeit) Beobachten von Auffälligkeiten wie bspw. hohe Auslastungsspitzen der Server aufgrund Batch-Jobs, DB-Indizierung, ungeplante Betriebsaktivitäten, die nicht kommuniziert wurden. Dokumentation der durchgeführten Testläufe (ID, Startzeit, Dauer, Auswertungsrelevanz) Seite 38

40 Prüfen der Performance. Methodisches Vorgehen Auswertung. Testaussagen Erreichung der Testziele? Erreichung der Performanceziele? Defizite: Performanceeinbrüche, -engpässe, Fehlerraten Handlungsbedarf Auswertungen Entwicklung der Antwortzeiten über die Laststufen Transaktionen / Fehlerraten über die Laststufen Zusammenhang zwischen Laststufen, Systemparameter der Server und Overall Response Time Percentile: Wie viel Prozent der Nutzer bleiben innerhalb bestimmter Antwortzeitgrenzen (bspw. 5, 8, 16 sec). Seite 39

41 Prüfen der Performance. Auswertung Entwicklung der Antwortzeiten. Beispiel: Lasttest einer Anwendung zur Online-Bewerbung. Entwicklung der Antwortzeiten Seite 40

42 Prüfen der Performance. Auswertung Entwicklung der Transaktionen. Beispiel: Entwicklung der Anzahl durchgeführter Bewerbungsprozesse. Transaktionen stagnieren, das System kommt in den Bereich der Sättigung. Seite 41

43 Prüfen der Performance. Auswertung Zusammenhang Laststufen, Systemparameter, durchschnittliche Antwortzeiten. Beispiel: Overall-Responsetime / CPU-Auslastung Webserver Seite 42

44 Prüfen der Performance. Auswertung Zusammenhang Laststufen, Systemparameter, durchschnittliche Antwortzeiten. CPU-Auslastung Datenbankserver Fazit: Systemkomponente Webserver stellt den Flaschenhals des Systems dar. Seite 43

45 Prüfen der Performance. Auswertung Antwortzeiten / Percentile. Entwicklung des Antwortzeitverhaltens bei steigender Last Anteil der Nutzer < 5s Antwortzeit, zwischen 5 und 8s, >8s Seite 44

46 Prüfen der Performance. Auswertung - Fehlerraten. Entwicklung des Durchsatzes (Anzahl durchgeführter Transaktionen) Mehr als 700 Transaktionen (im Zeitraum von 10 min) werden nicht erreicht, da die Antwortzeiten ansteigen (siehe vorhergehende Seite). bei sehr hoher Last treten schließlich Fehler auf Seite 45

47 Prüfen der Performance. Diagnose von Performanceproblemen. Gezieltes identifizieren von Performanceproblemen in Java /.NET - Applikationen Performanceanalyse bis auf Methodenebene (Laufzeit, Speicher-, CPU-Belastung...) Analyse der Datenbankkommunikation (Laufzeit der SQL-Statements...) Darstellung der Methodenaufrufe als Call-Tree Korrelation der Funktionsaufrufe über eine Prozesskette mit mehrerer J2EE Komponenten möglich. Seite 46

48 Web Servers Web Servers Web Servers Application Servers Application Servers Application Servers Data Center Data Center Data Center Backoffice Backoffice Backoffice Prüfen der Performance. Diagnose - Messaufbau. Simulierte und reale Endbenutzer Komplexe Softwareanwendungen verteilt und heterogen Java/J2EE Server.NET Server Datenbank Sensor Problem Ausführungspfad Diagnostics Agent Diagnostics Server Diagnostics Client Seite 47

49 Prüfen der Performance. Diagnose - Instrumentierung. Setzen der Messpunkte Agent Zeiten (µs), Exception Instrumentierung Java Code (unverändert) Instrumentierung Zeit Seite 48

50 Prüfen der Performance. Diagnose - Ergebnisse. Simulierte und reale Endbenutzer Komplexe Softwareanwendungen verteilt und heterogen Java/J2EE Server.NET Server Datenbank Login Suche Exception Kontotransaktion Seite 49

51 Erkenntnisse gewinnen Diagnose - Ergebnisse. Simulierte und reale Endbenutzer Komplexe Softwareanwendungen verteilt und heterogen Java/J2EE Server.NET Server Datenbank Login Suche Problem Kontotransaktion Zu viele Datenbankabfragen! Seite 50

53 Prüfen der Performance. Überwachung der Anwendung im Betrieb. Permanente Überwachung der Anwendung aus Systemund Endnutzersicht. Wie erlebt der Kunde die Anwendung? Ist die Anwendung von verschiedenen Standorten aus erreichbar? Funktionieren die wichtigen Geschäftsprozesse immer korrekt? Wie ist das Antwortzeitverhalten? Werden die SLAs der Anwendung eingehalten? Wann muss der Support proaktiv eingreifen? Seite 52

54 Web-Performance Management. Monitoring komplexer Systemarchitekturen. Systemmonitoring Applikationsmonitoring Server Netzwerk Dienste Datenbank Antwortzeiten Client (End to End) Transaction Tracking Transaction Tracking Geschäftsprozesse Datenerfassung Reporting Datenerfassung Reporting Datenerfassung Reporting Datenerfassung Reporting Datenerfassung Reporting Problemanalyse SLM Verfügbarkeit SLM Verfügbarkeit, Antwortzeiten Seite 53

55 Applikationsmonitoring. Beschreibung. Monitoring von Verfügbarkeit, Stabilität und Antwortzeitverhalten der Applikation Bei SLA-Verletzung automatische Benachrichtigung des Service Desk in Alarmfällen über , SMS. Objektive Bewertungsgrundlage (Reporting zu Verfügbarkeit, Fehlerfällen, Performance). Verfügbarkeit der Anwendung maximieren. Einhaltung von Service Levels kontrollieren. Seite 54

56 Applikationsmonitoring. Beschreibung. Seite 55

57 Applikationsmonitoring. Beschreibung. Seite 56

58 Agenda. Unternehmen T-Systems Multimedia Solutions Akkreditiertes Testzentrum Prüfen der Performance Performancetest Diagnose Überwachung im Betrieb Prüfen der Sicherheit Das Umfeld Konzeption (Datenschutz und Datensicherheit) Sicherheitstests Seite 57

59 Prüfen der Sicherheit. Das Umfeld. Warum Sicherheitsmanagement und -tests? Firewalls und Virenscanner sind inzwischen akzeptierter Standard, wenn auch oft nicht wirkungsvoll eingesetzt; sind jedoch lange nicht ausreichend: Content-Security wird wichtiger. Gefährdungs-Umfeld kommerzieller Natur: Freizeit-Hacker wird abgelöst durch geschäftsmäßiges Ausnutzen von Sicherheitslücken, wie Erpressung oder Schädigung von Konkurrenten Verschärfte Anforderungen durch Gesetzgeber und Markt (z.b. ISO / 27001, KonTraG, SOX, Basel II u. a.). Thema Sicherheit wird zukünftig, statt bisher punktuell (Hardware, Netzwerksicherheit, Tools), umfassend und prozessorientiert angegangen (umfassende Konzeption von Sicherheitsprozessen / ITIL). Bewusstsein wächst, Sicherheits-Management wird notwendig. Prozesse müssen sehr hoher Dynamik gewachsen sein (ständig neue Angriffsmethoden, Sicherheitslücken, usw.) Seite 58

60 Prüfen der Sicherheit. Das Umfeld. Tendenzen Wissen der Angreifer nimmt tendenziell ab Tools, die zum Einsatz kommen, werden zunehmend mächtiger (Quelle: Seite 59

61 Prüfen der Sicherheit. Das Umfeld. Zusammensetzung der Angreifer über 50% (ehemalige) eigene Mitarbeiter Hacker Cracker Script Kiddies Motivation Aufzeigen von Sicherheitslücken finanzielle Vorteile Frust, Langweile oder Ruhm Seite 60

62 Prüfen der Sicherheit. Security als Bestandteil des QS Prozesses. Projektphasen bis zum Wirkbetrieb Funktionale Anforderungen Fachkonzept DV Konzept Implementierung Test Sicherheitsanforderungen Sicherheits-/ Datenschutzkonzept(e) Reviews, Bereitstellung von best practices Penetrationstest Begleitphasen der IT-Sicherheit Seite 61

63 Prüfen der Sicherheit. Leistungen des CC IT-Sicherheit. Leistungen: Umfassende Beratungs- und Analyseleistungen mit gesamtheitlichem, lückenlosem Sicherheitskonzeption als Ausgangsbasis für die Wahl geeigneter Prozesse, Verfahren und Tools unter Berücksichtung von Kostenoptimierungspotentialen. Prozessberatung hinsichtlich Sicherheitsstrategie, Sicherheitspolitik und Security Masterplan; Bewußtseinmachung und Bedeutung Prozessanalyse und -entwicklung und Unterstützung bei Planung und Aufbau eines Sicherheitsmanagementprozesses (ITIL) Sicherheitsbedarfsanalysen und Sicherheitskonzepte, Datenschutzkonzepte Sicherheits-Detailplanung und Lösungsentwicklung Audits, Code Reviews Penetrationstests, Zertifizierung Seite 62

65 Prüfen der Sicherheit. Konzeption - Datenschutzkonzept. Das Datenschutzkonzept dient dazu: Allgemein: Ein Datenschutzkonzept definiert die Vorgaben für ein IV-Verfahren (bzw. Projekt) zur Gewährleistung des Datenschutzes. Rechtsgrundlage: Die Erhebung, Verarbeitung und Nutzung personenbezogener Daten bedarf einer Rechtsgrundlage (BDSG 29). Zweckbestimmung: Die Verarbeitung und Nutzung der Daten unterliegt einer konkreten Zweckbestimmung (BDSG 4). Maßnahmenkatalog: Zur Gewährleistung des Persönlichkeitsrechts beim Umgang mit personenbezogenen Daten sind die technischen und organisatorischen Maßnahmen zum Schutz dieser Daten detailliert zu beschreiben (BDSG 9). Seite 64

66 Prüfen der Sicherheit. Konzeption - Datenschutzkonzept. Das Datenschutzkonzept zeigt somit Maßnahmen auf, die u.a. zur Verhinderung des Missbrauch von personenbezogene Daten beitragen, dem Schutz personenbezogener Daten vor unberechtigten Zugriffen dienen, und die Anforderungen des Bundesdatenschutzgesetzes gewährleisten (BDSG Anlage zu 9 Satz 1). Seite 65

67 Prüfen der Sicherheit. Konzeption - Sicherheitskonzept. Das Sicherheitskonzept dient dazu: Bedrohungen zu erkennen, Risiken zu erkennen und bewusst zu machen, angemessene Maßnahmen gegen Risiken zu beschreiben, Entscheidungen des verantwortlichen Managements über Massnahmen und bewusst akzeptierte Restrisiken vorzubereiten, die sicherheitsbestimmenden Überlegungen nachvollziehbar zu machen und zu dokumentieren, den Sicherheitsstatus während der Dauer der Nutzung zu erhalten Seite 66

68 Prüfen der Sicherheit. Konzeption - Sicherheitskonzept. Bestandteile Sicherheitskonzept: Objektanalyse (Feinanalyse der Objekte und Schnittstellen) Schutzbedarfsanalyse (Herausstellen der wichtigsten Schutzziele seitens des Auftraggebers) Bedrohungsanalyse (Feststellen von Angriffs-Motivation und technischer Anfälligkeit) Risikoanalyse (Herausarbeiten der bestehenden oder erwarteten Risiken) Empfehlung von Maßnahmen, Einschätzung des Restrisikos Norm ISO (Information technology - Security techniques - Code of practice for information security management) Vorgehen nach IT-Grundschutz Seite 67

69 Prüfen der Sicherheit. Konzeption - Sicherheitskonzept. Seite 68

70 Prüfen der Sicherheit. Konzeption - Sicherheitskonzept. Objektanalyse (Feinanalyse der Objekte und Schnittstellen): Darstellung der Komponenten, Schnittstellen, Rollen, Prozesse, Informationswerte, Dienste, Protokolle, Ports usw. Ergebnis der Objektanalyse ist eine Liste der Teil-Objekte Voraussetzung für die nun folgende Schutzbedarfsanalyse. Seite 69

73 Prüfen der Sicherheit. Konzeption - Sicherheitskonzept. Schutzbedarfsanalyse (Schutzziele seitens des Auftraggebers) : Schutzanforderungen gegen mögliche Gefährdungen Schutzbedarf lässt sich im wesentlichen in die Bereiche Vertraulichkeit, Integrität und Verfügbarkeit kategorisieren Bedrohungssanalyse (Angriffs-Motivation und technische Anfälligkeit) : potentielle Bedrohungen für diese Objekte Betrachtung aller denkbaren und relevanten Gefährdungsszenarien für die Anwendungsobjekte Seite 72

75 Prüfen der Sicherheit. Konzeption - Sicherheitskonzept. Risikoanalyse (Herausarbeiten der bestehenden oder erwarteten Risiken): welche Manipulationsmöglichkeiten bzw. welche Ausfallszenarien können welchen Schaden anrichten Eintrittswahrscheinlichkeiten und potentielle Schadenshöhen Gewichtung nach niedrig, mittel oder hoch Empfehlung von Maßnahmen, Einschätzung des Restrisikos: risikosenkende Maßnahmen Betrachtung wirtschaftliche und sicherheitstechnische Gesichtspunkten Restrisiko unter Beachtung der umzusetzenden Maßnahmen Seite 74

78 Prüfen der Sicherheit. Sicherheitstest. Penetrationstest: Sicherheit ist ein Prozess und sollte in jeder Entwicklungsphase berücksichtigt werden Penetrationstests finden erst am Ende des Entwicklungsprozesses statt Penetrationsstests sind nur ein kleiner Beitrag zur Sicherheit Seite 77

79 Prüfen der Sicherheit. Sicherheitstest. Planung von Penetrationstests: Vorbereitung Informationsbeschaffung und Auswertung Bewertung der Informationen und Risikoanalyse Aktive Eindringversuche Abschlussanalyse Seite 78

80 Prüfen der Sicherheit. Sicherheitstest. Vorbereitung eines Penetrationstest Gefahrenanalyse Aggressivität festlegen Ausgangspunkt festlegen Informationsbasis festlegen Sichtbarkeit festlegen Live- oder Testsystem? Notfallmaßnahmen planen Rechtliche Fragen klären Testmodule auswählen Testdurchführung planen Seite 79

81 Prüfen der Sicherheit. Sicherheitstest. Informationsbeschaffung und Auswertung: Informations-Module ausführen Beschaffung von Dokumentation Testobjekte definieren Bewertung der Informationen und Risikoanalyse Risiken anhand der gewonnen Informationen bewerten Eindring-Module auswählen (nach Risiken) Seite 80

82 Prüfen der Sicherheit. Sicherheitstest. Aktive Eindringversuche Aktive Eindringversuche unternehmen Revisionssichere Dokumentation Abschlussanalyse Ergebnisse sammeln Ergebnisse bewerten Risiken darstellen Empfehlungen aussprechen Aktionsplan entwickeln Seite 81

83 Vielen Dank für die Aufmerksamkeit.