FHNW - ITSM - P2

Miscshung aus privaten und public Clouds.

Sie sind sinnvoll, wenn man sowohl Services hat, welche in der private-Cloud sinvoll sind als auch solceh, welche in der public-Cloud gut aufgehoben sind. Z.B Dateiablage auf lokalen Servern und E-Mail Anwendung.

Meist handelt es sich um Social-Engineering attacken. Diese zielen immer auf den Menschen als Schwachpunkt und umgehe nso die mühsame Aufgabe die Technick überlisten zu müssen (2 von 4 Punkten, Kommentar von Jossen: keine Signaturen)

Abschreibung von HW und SW

Betriebskosten

CAPEX

OPEX

Personalkosten

Servicekosten

Umlage Gemeinkosten

7x24 Betriebsstruktur (3 Teams a 8h, braucht 6-7 MA's, relativ kostenintensiv, macht nur sinn wenn genügend Anfragen vorhanden sind oder gewissse Kritikalität der zu betreibenden Services erreicht ist)

Picket Organisation (Mitarbeiter auf Abruf, Reaktionszeit > 1h, Weniger kostenintensiv - Piketentschädigung pauschaul plus tatsächliche Arbeitszeit)

gute Unternehmen können Beschaffungen direkt Abschreiben. Zeit das Unternehmen gute Ertagslage hat. Bilden von stillen Reserven. Aufwnad wird grösser und ein kleinerer Gewinn wird ausgewiesen (Steueroptimierung)

keine Investition

HW SW Betrieb und Wartung ist in Subscription einkakluliert

Hohe flexibliität, da monatlich oder jährlich kündbar

Zu hohe Anforderungen in SLA und oLA'S führen zu höheren Kosten.

Hohe kostentreiber:

- Verfügbar der Service

- REdundanzen

- Erreichbarkeit des Supports

- Reaktionszeit des Supports

- Anzahl Wartungsfenster pro Jahr

- Anzahl Mitarbeiter (Know How und Ausbildungsstand)

Risiken mit hohem Schadensmass und tiefer eintrittswahrscheindlichkeit und grosse Zielgruppe mit gleichem Risiko.

Viele die Zahlen, wenige die es Benötigen. Schaden ist für ein Unternehmen allein unbezahlbar.

Diebstahl von Daten

Manipulation von Daten

Verbreitung von Falschmeldungen

Störung der Verfürgbarkeit eines Services

Erpressung

Sicherstellen der Verfügbarkeit, der Privacy von Informationen, der Integrität und das Transaktionen nicht wiederholt werden (Non-Reputation)

SPAM

Ransomeware Attacke mit Trojaner

Social Engineering

ISO 27000

CoBit

BSI IT-Grundschutz

• 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.

- Usability

- Antwortszeiten

- Einhalten Kosten- und Zeitrahmen

- Sourcecode Qualität

- Fehlerfreie Applikationen durch Tests

Anforderungen nicht klar

Zu grosse ziele

Einsatz komplexer und nicht erprobt Technologien

Zuständigkeiten nicht geregelt

Wechselnde Anforderungen während dem Projekt

Gerichtsort

Zahlungsbedinung

Lieferbedingung

Haftung

Garantien und Gewährleistungen

Fishbone Diagramm: 5 mal Wieso Fragen

Zeigt die Abhängigkeit zwischen Ursache und Wirkung

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

Benuzter (Inklusive Kontaktdaten)

Titel des Problems

Beschreibung

Assed oder CI-Information, wo das Problem auftritt

Auswirkung

beim Überschreiten von Schwellwerten

z.B zeit seit das Ticket offen ist, mehrere Incidents zu mselben thema, verschiedene benutzer betroffen, gewisse kritikalität

Alle gefundenen Lösungen als Change Request über das Change-Management umsetzten. Das CAB priorisiert und beruteilt die einzelnen Change Requests.