Security Consulting

Verlässliche IT.
Sichere IT.

Bild 1 ohne Hintergrund v2

Security Consulting

MEKOS Sicherheitsstrategie

Kaum ein Thema bietet so viel Stoff für kontroverse Diskussionen, wie die Informationssicherheit. Das ist eigentlich auch nicht verwunderlich, denn häufig stellen sich die Fragen:

Wo fängt man an und wann ist man fertig?

Der sprichwörtliche Wald, den man bei all den Bäumen nicht sieht, wird schnell zum Fass ohne Boden und beides kann sich kein Unternehmen leisten.

 

Wir von der MEKOS betrachten Informationssicherheit als hierarchische Struktur, die sich nach den wirtschaftlichen Zielen des Unternehmens ausrichtet und auf diese fokussiert.

Damit können wir gewährleisten, dass Maßnahmen und damit Ressourcen, wie Manpower und Geld, dort umgesetzt werden, wo der größte Bedarf angesichts Ihrer Unternehmensziele besteht. 

Unser Team hat langjährige Erfahrungen im Bereich von Sicherheitsprojekten und kennt die einschlägigen Normen wie

  • VdS10000
  • ISO
  • 27001
  • BSI Grundschutz
  • ISAE 3402
  • ISO 20000 (ITIL)

und bringt eine Menge Erfahrung mit Audits und Auditoren mit.

Security Consulting

Risiken erkennen & auf diese reagieren

Aus der Frage „Wo fängt man an?“ ist die Frage geworden „Was macht Sie erfolgreich?“ und die konnte uns bisher jeder unserer Kunden beantworten. Bleibt die Frage „Wann ist man fertig?“… Da bekommt man oft zur Antwort „Nie!“. Das ist so nicht ganz richtig. Ja – Sicherheit ist entweder ein fortwährender Prozess oder eine Illusion! Aber Ziel ist nicht der absolute Sicherheitszustand, sondern die ökonomische Beherrschbarkeit des Risikos. Fertig ist man also, wenn man seine Risiken (er-)kennt und geordnete Wege hat, um darauf zu reagieren.

Security Consulting

Unsere Leistungsmodule

  • BIA / Risk Management

    Die Business Impact Analyse (BIA) beinhaltet ein fokussiertes und rudimentäres Risk-Management. Ausgehend von Szenarien IT-seitiger Störungen werden Wiederherstellungs- und Aufarbeitungszeiten geschätzt und auf diese Weise ermittelt, mit welcher Ausfallzeit im Falle eines Eintretens einer Störung gerechnet werden muss. Zeitgleich ergibt sich eine erste Erhebung, welche Vorkehrungen schon getroffen wurden oder welche Störungen völlig unvorbereitet zuschlagen würden. Bei einer BIA werden nicht nur die IT Bereiche hinterfragt; die Szenarien berücksichtigen auch, welche Vorkehrungen die Fachabteilungen ergriffen haben und wie hoch bspw. Belastungen für Nacharbeiten sind, die sich auf die Dauer bis zum Normalbetrieb auswirken.



    Mit einer BIA-Simulation können bei Auftreten einer Störung verschiedene Sichtweisen betrachtet werden. Was bedeutet es, wenn man z.B. noch weitere eineinhalb Stunden Fehlersuche betreibt und trotzdem keine Lösung findet; wie sieht es hingegen aus, wenn man insgesamt 3 Stunden in die Fehlersuche investiert und die Störung in dieser Zeit beheben kann…

  • IST-Zustandsanalyse

    Jedes Unternehmen lebt bereits Betriebsprozesse, die entweder nur existieren oder bereits niedergeschrieben sind. Bei der IST Stand‘s Erhebung wird ermittelt, wie viele der erforderlichen Prozesse/Regelungen bereits beschrieben sind und in welcher Qualität/Ausführlichkeit/Realitätsnähe sie vorliegen. Als Ergebnis erhalten wir das Delta zwischen IST und SOLL in Dauer und Aufwand (und infolgedessen auch in Euro). Die Dokumente, die Sie uns zur Verfügung stellen, prüfen wir auf

    • Strategie
      Eine Strategie ist vorhanden/erkennbar, wenn das Dokument Angaben über zu erfüllende Service Level oder sonstige Anforderungen enthält. Die Angaben können auch in Form einer Absicht erklärt werden, bspw. „…um <<Ziel>> zu erreichen, werden folgende Schritte durchgeführt…“. Strategisch ist, ein Ziel zu verfolgend und darauf passende Maßnahmen zu finden. Maßnahmen können überaus sinn- und wertvoll sein und erhebliche, positive Effekte erzeugen. Sie sind aber nur dann strategisch, wenn sie zur Stabilisierung der Geschäftsziele dienen.
    • Vollständigkeit
      Eine Unvollständigkeit liegt dann vor, wenn betriebsrelevante Aspekte nicht oder zu wenig beschrieben sind. So muss bspw. für ein Backup Handbuch auch beschrieben sein, wie neue Systeme oder Systemänderungen im Backup Prozess berücksichtigt werden. Es muss niedergeschrieben sein, wie Backup Fehler erkannt, gemeldet und behandelt werden. Aber das sind erst mal nur Beispiele…
    • Wording
      Dieses Kriterium bezieht sich auf die Formulierung. Anforderungen und Vorgaben müssen als solche erkennbar sein und dürfen deshalb keine Konjunktive enthalten. Umsetzungen hingegen müssen in Ist-Form beschrieben sein. Beispiele: „…Sicherungsbestände müssen ermöglichen, mindestens 3 Werktage rückwirkend Dateiversionen wiederherzustellen…“ // „…angefertigte Sicherungssätze für Fileserver werden über 3 Versionen erhalten…“.

    Selbstkontrolle
    Die Selbstkontrolle meint ein IKS (internes Kontrollsystem) und ist am ehesten auf Prozesse und technische Maßnahmen anwendbar. Bewertet wird, ob benutzte Werkzeuge und Datenflusswege auf ihre Funktionstüchtigkeit geprüft werden. Beliebtes Beispiel dafür ist das Alerting bei der Systemüberwachung (Monitoring); über die Meldewege müssen stets Testnachrichten verschickt werden um sicherzustellen, dass im Ernstfall die Meldewege noch funktionieren.

  • Notfallmanagement

    Basierend auf den Ergebnissen der BIA werden sich Szenarien ergeben, die in ihrer Ausfalldauer und/oder ihrem Datenverlust erheblich sind und deshalb nicht mit Standardverfahren (IT) und Abwarten (Fachabteilungen) „ausgesessen“ werden können. Für diese Fälle werden Wiederanlaufpläne (IT) und Geschäftsfortführungspläne (Fachabteilungen) erstellt, die es bei einem Notfall abzuarbeiten gilt, um die schnellstmögliche Wiederherstellungszeit zu gewährleisten.

  • IT-Dokumentation (Service)

    Hier geht es um die Erstellung/Fortschreibung der IT-Dokumentation mit dem Teil, der für den Anwender sichtbar ist (Störungsbearbeitung, Behandlung von Anfragen und Durchführung von Änderungen [Incident/Problem, Service Request, Change]). Der Baustein kann zumindest teilweise parallel zur Support-orientierten IT-Dokumentation erstellt werden und ist deshalb ausgegliedert. Existierende Verfahrensbeschreibungen werden genutzt, um den Aufwand zu minimieren.

  • Operative Anpassungen

    Wie umfangreich dieser Punkt wird, lässt sich erst nach der IST Stand Erhebung abschätzen. Anpassungen können hier notwendig werden, wenn ein gelebter Prozess nicht mehr zu seiner Beschreibung passt, dies aber tun sollte. Ebenso kann eine Anpassung erforderlich sein, wenn ein Verfahren nicht die Effektivität hat, die er für die erforderliche Betriebssicherheit aufweisen muss. Anpassungen können in drei Richtungen anstehen (mehr tun, anders tun, weniger tun). Letzteres bspw., wenn ein Verfahren zwar ausreichend effektiv ist aber mit weniger Aufwand oder Synergien effizienter gestaltet werden kann.

  • KVP (kontinuierlicher Verbesserungsprozess)

    Eine erreichte Sicherheit verschwindet alsbald in der Bedeutungslosigkeit, wenn sie sich veränderten Umständen und Anforderungen nicht anpasst. Die kontinuierliche Verbesserung stellt daher einen Kernprozess der Informationssicherheit dar. Mit/In ihm werden folgende Aspekte beschrieben:

    • Wie wird Veränderungsbedarf erkannt?
    • Wer und wie ist für die Maßnahmensuche und deren Umsetzung verantwortlich?
    • Wer und wie bewertet die Effektivität von Maßnahmen?

    Es ist der Prozess, der von Auditoren am häufigsten genauer unter die Lupe genommen wird, um die Vitalität und Aktualität aller anderen Prozesse und Verfahren bewerten zu können. „Ganz neben bei“ wirft der Prozess auch Management Berichte ab. Der KVP stellt den geordneten Weg dar, mit dem Sie Risiken (er-) kennen und darauf reagieren.