#631 Informationssicherheit – Guiding Questions

Bei dem ganzen Hype, der dem Thema Informationssicherheit in den letzten Jahren widerfahren ist, darf man eines nicht vergessen: Informationssicherheit ist kein Selbstzweck, sie dient lediglich zur Sicherstellung des eigentlichen Geschäftszweckes/des eigentlichen Auftrags. Demnach gilt: Business first!

Beim Thema Informationssicherheit darf es nicht um die Befriedigung aus Normen abgeleiteter Anforderungen gehen, sondern es ist stets eine Abwägung aus Business Sicht. Dies gilt insbesondere, da es eine 100%-Sicherheit nicht gibt, insofern ist Informationssicherheit immer auch ein Risikomanagement-Prozess.

Bei einem großen Rollout-Projekt zur Implementierung eines IT-Security-Prozesses im IT Service-Management, mussten wir lernen, dass wir die Kollegen immer wieder überfordert haben. Zum Einen ging die eben erwähnte Business-Perspektive in den Köpfen immer wieder verloren, zum Anderen verloren die Kollegen bei der Vielzahl der Security Requirements schnell den Überblick und haben den Wald vor lauter Bäumen nicht mehr gesehen. Da wurden dann technische Betriebs-Details  formal mit dem Provider geklärt, anstatt sich grundsätzlich mit der Frage auseinander zu setzen, was (im konkreten Fall) eine Cloud-Lösung überhaupt ist und ob man die eigenen Daten wirklich in fremde Hände geben möchte. Natürlich braucht es auch dedizierte Anforderungen, aber ohne ein entsprechendes Mindset wurde die Bearbeitung schnell zum sinnentleerten Papiertiger.

Vor diesem Hintergrund habe ich eine Reihe von Guiding Questions formuliert, um die Kollegen wieder „abzuholen“. Natürlich gilt als oberster Grundsatz die Orientierung am Geschäftszweck (1), dann ist ein generelles Lösungsverständnis erforderlich (2) um überhaupt die klassischen Dimensionen der Informationssicherheit bearbeiten zu können (3-5). Zur Visualisierung habe ich mich des IT Security Canvas bedient:

(1) Business first!

(2) Lösung & Architektur
Um ein allgemeines Verständnis unserer Lösung zu entwickeln:

  • Wie sieht das generelle Design/die Architektur der Lösung aus?
  • Gibt es Schnittstellen zu anderen Systemen?
  • Wo sind diese Systeme räumlich angesiedelt?
  • Wo werden Daten gespeichert, verarbeitet oder transportiert?
  • Welche Parteien sind involviert (Benutzer, Administratoren, Dienstleister,…)?
  • Gibt es ein IT-Service-Management?


 
 
 
 
 

(3) Vertraulichkeit / Confidentiality
Wenn Vertraulichkeit von besonderer Relevanz für unsere Lösung ist:

  • Welche Personengruppen und Systeme sind beteiligt bzw. haben Zugriff?
  • Deckt die Zugriffskontrolle all diese ab?
  • Werden Verschlüsselungstechniken eingesetzt? Bei der Speicherung? Bei der Übertragung?


 
 
 
 
 

(4) Integrität / Integrity
Wenn Integrität von besonderer Relevanz für unsere Lösung ist:

  • Wie kann ein Integrationsverlust bemerkt werden?
  • Gibt es Optionen zur Wiederherstellung?
  • Werden unterstützende Features wie Plausibilisierungen, Verschlüsselung, Backups, etc. genutzt?


 
 
 
 
 

(5) Verfügbarkeit / Availability
Wenn die Verfügbarkeit von besonderer Relevanz für unsere Lösung ist:

  • Ist unsere Lösung in einem IT Disaster Recovery und/oder in einem Business Continuity Management zu berücksichtigen?
  • Decken Disaster Recovery und Business Continuity Pläne alle beteiligten Systeme und Parteien ab?



bernhardschloss.de