ITSM

Auf den System sammeln sich keine Altlasten durch vorherige Updates und Patches an. Falls ein Software Update nicht korrekt installiert werden kann, muss der Fehler nicht aufwendig untersucht und behoben werden.

• Leiter Datacenter Services
    o Network
    o Storage
    o Server
    o Firwalls
• Leiter Business Applikationen
• IT-Leiter (Optional)
• Security Officer
• Compliance Officer

Das Release Management hat das Ziel eine proaktive Release Planung zu implementie-ren. Dabei geht es darum, dass ein neuer Software Release getestet und eingeführt wird.

Das Change-Management hat das Ziel vor allem Konfigurationsänderungen koordiniert zu planen und durchzuführen. Zu einer Konfigurationsänderung kann das Anpassen ei-ner Konfiguration gehören, sowie das Aktualisieren von einzelnen Softwarekomponenten.

Das Change-Management wird oft auf dem Incident- und Problem-Management getrig-gert (reaktiv).

Neue Software Release können mit Hilfe der CI/CD Pipeline automatisiert bereitgestellt werden. Die Chance ist dabei relativ hoch, dass diese Software Release nicht vollstän-dig getestet werden und «halbfertige» Release in die Produktion überführt werden.
Zudem kann ein Freigabeprozess nur bedingt eingeführt werden. Vor allem im Banken Umfeld muss nachvollziehbar sein, welcher Software Release zu welchem Zeitpunkt auf den produktiven Systemen eingesetzt worden ist.

Für Applikationen, die agil entwickelt und betrieben werden müssen. Vor allem Applikati-onen die einen hohen Kundenbezug haben, wo rasch und effizient auf neue Marktgege-benheiten reagiert werden muss. (>12 Release pro Jahr)

Incident:
• Eingrenzbarer Vorfall (ein Benutzer betroffen)
• Kann in der Regel durch den 1st Level Support behoben werden
• Dokumentierte Lösungsbehebung vorhanden
• Lösungsbehebungszeit innerhalb eines gewissen Schellwertes

Problem
• Ein Incident wird zum Problem, wenn eines der folgenden Kriterien erfüllt ist:
o Incident nicht innerhalb einer gewissen Zeit lösbar
o Kein dokumentierter Lösungsbehebungsprozess vorhanden
o Mehrere Incidents zum gleichen Thema vorhanden
o Grosser Impact für einen Service oder mehrere Benutzer
o Incident kann aktuell nur über einen Workaround behoben werden

• Benutzer (inklusive Kontaktdaten: E-Mail, Telefon)
• Titel des Problems
• Beschreibung des Problems
• Asset oder CI-Informationen, wo das Problem auftritt
• Auswirkung (Service beeinträchtigt, Service nicht mehr nutzbar, komplett Ausfall)

Incident nicht innerhalb von 2h lösbar oder mehrere Incidents zum gleichem Thema von verschiedenen Benutzer vorhanden

Alle gefunden Lösungen müssen als Change Request (RFC) über den Change-Ma-nagement Prozess umgesetzt werden. Das CAB priorisiert und beurteilt die einzelnen Change Requests.

Einhaltung der Projektziele im vorgegeben Zeit- und Kostenrahmen.
- Usability
- Antwortzeitverhalten
- Einhalten Kosten- und Zeitrahmen
- Sourcecode Qualität
- Fehlerfreie Applikation durch Tests

Anforderungen nicht klar
Wechselnde Anforderungen während dem Projekt
Zu grosse Ziele
Zuständigkeiten nicht klar definiert
Einsatz komplexer und nicht erprobter Technologien

Gerichtsort
Anwendbares Recht
Zahlungskonditionen
Lieferkonditionen
Garantien und Gewährleistungen
Vertragsgegenstand inklusive Beginn und Dauer des Vertrages
Haftung

Zeigt die Abhängigkeit zwischen Ursache und Wirkung

Grundsätzlich decken Versicherungen nur Risiken ab, die ein hohes Schadensmass ha-ben aber relativ eine tiefe Eintrittswahrscheinlichkeit und eine grosse Zielgruppe mit dem gleichen Risiko vorhanden ist. Nur in diesem Fall ist es für ein Unternehmen dieses Ri-siko zu versichern. Ansonsten würden die Prämien durch die Versicherung für das Un-ternehmen keinen Sinn machen.
Dies ist auch der Grund, wieso viele Versicherungen keine Pandemieversicherungen an-bieten, oder dieses Risiko aus vielen Betriebs- und Haftpflichtversicherungen ausge-schlossen wird. Die aktuelle Situation zeigt, dass die Versicherung solcher Risiken für die Versicherungen zu einem klumpen Risiko werden können, da Sie geografisch nicht begrenzt sind, ein relatives hohes Schadenausmass annehmen können und fast alle Kunden zur gleichen Zeit treffen.

Hacker Attacken haben heute immer kommerzielle oder politische Motivationen:
• Diebstahl von Daten
• Manipulation von Daten
• Verbreitung von Falschmeldungen (Fake News)
• Störung der Verfügbarkeit eines Services (DOS- oder DDOS-Attacke)
• Schädigung der Reputation des Opfers
• Erpressung (Ransomware)

Das Security Management verfolgt die folgenden Ziele:
• Sicherstellen der Verfügbarkeit
• Sicherstellen der Privacy von Informationen
• Sicherstellen der Integrität
• Sicherstatten das Transaktionen nicht wiederholts werden (Non-Reputation)

• SPAM
• Ransomware Attacke mit Trojaner
• Socical Engineering

• ISO 27000
• CoBit
• BSI IT-Grundschutz

Die Crypto-Affäre hat dem Datenstandort Schweiz stark geschadet. Die Enthüllungen haben gezeigt, dass der Sitz eines Unternehmens kein Garant ist, ob die Daten sicher sind oder nicht.
Vor allem im Zeitalter des Cloud Computings wird es schwierig werden, diese Swissness (Datacenter) in der Schweiz den Kunden zu verkaufen und einen allfälligen Mehrpreis zu rechtfertigen. Die Erfahrungen der letzten Jahre haben gezeigt, dass Security rein durch sichere Betriebsprozesse und vertrauenswürdige Lieferantenbeziehungen sichergestellt werden kann.
Die Reputation des Lieferanten ist wichtiger, als der Firmensitz des jeweiligen Anbieters.

• Social Engineering: Hacker gibt sich als Mitarbeiter aus, mit dem Ziel wichtige Informationen für einen späteren Hacker zu erfahren oder Daten physisch zu ent-wenden.
• Phishing E-Mail: Hacker versucht mit Hilfe von Phishing E-Mails Malware und Trojaner auf die Systeme der Opfer zu laden. Oft werden infizierte Attachement in diesen E-Mails mitversendet in der Hoffnung, dass das Dokument vom Opfer aufgemacht wird und der PC anschliessend infiziert ist.
• Ransomware: Verschlüsselung des PC’s des Opfers. Der Hacker entschlüsselt die Daten nur, wenn das Opfer Lösegeld bezahlt.
• Trojaner / Malware: Der Hacker lädt auf das System des Opfers seine Malware. Anschliessend spioniert die Malware das Opfer aus und sammelt anschliessend wichtige Informationen wie Bankdaten, Passwörter, Kreditkartennummer, usw. Diese Informationen können anschliessend verkauft werden.

Name, Beschreibung, Preis, Qualität/Menge

Richtlinien für den Betrieb und die Bereitstellunge von Services. ITILv3 legt gewisse Standardwerte/Standardvorgehen vor welche
auch „Best Practices“ sind.

Performance, Securtiy, Verfügbarkeit, Kosteneffizienz, Erweiterbarkeit

Schritt 1: Design (technische Architektur, bspw. wie sollen die Daten gespeichert werden
Schritt 2: Evaluation (Suchen von eventuell bestehenden Lösungen)
Schritt 3: Bestellung
Schritt 4: Inbetriebnahme
Schritt 5: Integration
Schritt 6: Testen (Acceptance tests)
Schritt 7: Datenmigration
Schritt 8: Betrieb und Wartung

RAM, CPU, I/O Performance, Bandbreite (eher technische)
Anzahl Incidents auf einem Service (organisatorisch)
Uptime eines Services (organisatorisch)
Markanteil (organisatorisch)

SLAs grundsätzlich mit externen Partnern
OLAs unterstützen die SLAs intern

Inhalt ist mehr oder weniger derselbe

Strafe (Busse) für nichteinhalten von SLA oder OLA

Einfache Messbarkeit und es sollte für den gewünschten Business case relevant sein
Es muss/soll ein Indikator für Qualität vorhanden (Beispiel: Anzahl BUG Tickets für einen Service)

RTO - Recovery time objective - gibt an wieviel Zeit für die Wiederherstellung der Daten benötigt wird -  sollte möglichst gering sein

RPO - Recovery point objective - gibt an wieviele Daten verlorgen gehen könnten bei einem Ausfall - sollte für kritische
Systeme also 0 sein

Geschäftsbücher, Revisionsbericht, alles was mit Finanzen zu tun hat (Geschäftsabschluss, Hauptbuch (hier
sind alle Buchungen inkl. deren Belegen ersichtlich), Bilanzen, Erfolgsrechnung)

Orientierung an einem Standard oder Branchenvorgaben
—> Daraus kann man seine eigenent Sicherheitskonzepte ableiten (aber nicht zu viel verändern)

Compliance: Gesetzliche Vorgaben müssen vorhanden sein (Verstösse können Strafrechtlich relevant sein)

Governance: Best-Practice, Einhaltung von Standards, Nachhaltiges Arbeiten

Kommt zu 100% an Prüfung

Ausfallsicherheit der Infrastruktur
Kosten und Krisenmanagement
Krisenstab festlegen
Kommunikationskanäle festlegen
Kritische Prozesse sicherstellen

Business Continuity Management Bestimmt eigentlich die Führung des Unternehmens in einer Krisensituation: BCM = BCM ist ein Managementprozess, der sicherstellt, dass kritische Geschäftsprozesse und Geschäftsfunktionen auch in Notsituationen verfügbar bleiben oder schnellstmöglich wieder verfügbar sind. 

Der erste Eindruck ist entscheidend (Kompetentes Krisenmanagement)

Keine Schuldeingeständnis, Keine Schuldzuweisung gegen Externe Lieferanten oder so

Bedauern für alle Betroffenen

NICHT LÜGEN (bspw. keine absolute Zahlen geben für Vorhersagen)

Alle Elemente einer IT-Organisation werden als Asset bezeichnet. Dazu gehören:
• Hardware (PC, Server, Storage, Drucker, Router, Switch, Firewall, usw.)
• Software (Betriebssysteme, ERP und CRM)
• Lizenzen (ELA, usw.)
• Verträge (Wartungsverträge, Providerverträge)
• Rollen und Rechte (Benutzer und deren Zugehörigkeit zu einer Organisation)

Der Zusammenschluss mehrer CMDB zu einer Gesamtlösung. Diese Lösung wird heute
oft verwendet, da es unmöglich ist in einer grossen IT-Organisation alle Assets in einer
zentralen CMDB effizient zu verwalten. Oft wird das folgende Konstrukt verwendet:
• CMDB für Netzwerkkomponenten
• CMDB für Server, Storage und virtuelle Systeme
• CMDB für alle Verträge (oft SAP)
• CMDB für alle Clients und Ducker inklusive Peripheriegeräte
Das Datenmodell spielt für die Einführung einer CMDB eine zentrale Rolle. Zusätzlich
müssen Schnittstellen zwischen den einzelnen CDMB definiert werden, um einen effizienten
Austausch der Informationen zwischen den verschiedenen CMDB zu erhalten.

1. Definition Datenmodell (CI inklusive Attribute und Beziehungen)
2. Definition und Auswahl der Datenquellen
3. Einrichtung Auto Discovery Prozess im Netzwerk
4. Manuelle Erfassung von Zusatzinformationen pro CI
5. Validierung der Datenqualität mit vorhanden Excel – Eventuell müssen einzelne Parameter
vom Excel File mit einem Script in die CMDB übernommen werden. Zur
Identifikation der einzelnen Datensätze kann als Primary Key der Devicename oder
die SN des Devices benutzt werden.
6. Implementierung weiterer ITIL-Disziplinen

IaC bietet die Möglichkeit anhand eines Templates komplette Infrastrukturen bereitzustellen.
Moderne IaC-Lösungen sind in der Lage Compute-, Storage- und Netzwerkressourcen
automatisiert zu provisionieren.
In der Regel wird dazu ein Provisioning Workflow erstellt. Der User kann über ein Web-
GUI die einzelnen Ressourcen auswählen und anschliessend provisionieren. Im ersten
Schritt werden die zu konfigurierenden Ressourcen in der CMDB inventarisiert. Anschliessend
wird des Template benutzt um die Konfiguration der Elemente durchzuführen.
Grundsätzlich kann gesagt werden, dass in der CMDB die SOLL-Informationen gespeichert
sind. Dadurch wird es Möglich ungewünschte Konfigurationsänderungen in der Infrastruktur
(IST) zu detektieren und ein automatisiertes «Config Enforcement» durchzusetzen.
Im Markt gibt es entsprechende Lösungen, die das bereits heute unterstützen.
Dazu zählen zum Beispiel Puppet, Chef oder Ansible.

Das Performance Monitoring hat das Ziel die Verfügbarkeit und Antwortzeit eines IT-Ser-vices oder einer einzelnen Applikation zu messen, validieren und zu überwachen. Die meisten Unternehmen implementieren heute für die wichtigsten Applikation ein End-to-End Service Monitoring. Dabei wird die Performance (Antwortzeit) einer Applikation aus Sicht des Benutzer überwacht.