Neben allen technischen L\u00f6sungen ist der organisatorische Teil der Cyber Security ein weiterer Aspekt, der im Fokus stehen muss. In einer Serie von Blogartikeln beleuchten wir verschiedene Aspekte, die technische L\u00f6sungen erg\u00e4nzen und deren Wirksamkeit erh\u00f6hen k\u00f6nnen.<\/p>\n\n\n\n
Nach den Grundlagen, der Configuration Management Data Base (CMDB) und dem Change-Prozess geht es nun um den Incident-Prozess als wichtigstes Element der IT-Serviceprozesse.<\/p>\n\n\n\n
In IT-Organisationen ist der Incident-Prozess der am weitesten verbreitete, am l\u00e4ngsten existierende und am h\u00e4ufigsten eingesetzte Prozess. Er wird in unterschiedlichen Formen und Auspr\u00e4gungen \u00fcberall dort eingesetzt, wo St\u00f6rungen gemeldet und behoben werden m\u00fcssen. Der Incident-Prozess ist der Ursprung der gesamten IT-Support-Organisation und in fast jedem Unternehmen anzutreffen, wenn auch nicht immer formal und dokumentiert.<\/p>\n\n\n\n
Wenn wir in die Vergangenheit schauen, so hat man an vielen Stellen fr\u00fch erkannt, dass man einen Prozess braucht, um die Auftr\u00e4ge abzuwickeln. Viele haben mit E-Mails begonnen und schnell gemerkt, dass ab einer gewissen Menge, Komplexit\u00e4t und Durchlaufzeit der \u00dcberblick verloren geht. So kamen die ersten Ticketsysteme zum Einsatz, wobei anfangs meist noch nicht zwischen St\u00f6rungen und Auftr\u00e4gen unterschieden wurde. In der Weiterentwicklung dieser Prozesslandschaften kamen dann nach und nach Change-, Service-Request- und Problem-Tickets hinzu. Auch die Funktionalit\u00e4ten und Workflows der Prozesse und Werkzeuge wurden kontinuierlich erweitert. Treiber ist dabei h\u00e4ufig der operative IT-Betrieb.<\/p>\n\n\n\n
Grunds\u00e4tzlich handelt es sich um sicherheitsrelevante Vorf\u00e4lle. Dies ist nat\u00fcrlich sehr weit gefasst und muss von der Organisation genauer definiert werden. Beispielsweise fordert die ISO 20000 unter \u00abInformation Security Management\u00bb eine Policy, Controls und Assessments. Daraus ergibt sich in der Praxis zumindest eine Kategorisierung der Incidents, um Operative und Security Incidents zu unterscheiden und ggf. unterschiedlich zu behandeln.
Alle Incidents, die von Sicherheitsl\u00f6sungen gemeldet werden bzw. aus dem SOC kommen, sind typischerweise als Security Incidents zu betrachten.<\/p>\n\n\n\n
Im operativen Incident-Prozess ist die Zeit bis zur Behebung der Betriebsst\u00f6rung oft der wichtigste Parameter. Ein schneller Neustart und die St\u00f6rung ist erst einmal behoben. Eine Nachverfolgung wird erst dann relevant, wenn die St\u00f6rung zu h\u00e4ufig auftritt. Unter Sicherheitsaspekten wird ein Incident jedoch anders betrachtet. Nat\u00fcrlich ist auch hier eine kurze Reaktionszeit wichtig, aber die Kl\u00e4rung der Ursache und eventuell eine weitergehende Nachverfolgung des Incidents, idealerweise nach einer Analyse, muss gew\u00e4hrleistet sein. Hier ist auch zu ber\u00fccksichtigen, dass bei schnellen L\u00f6sungen der Verlust von Informationen vorkommen kann, so dass eine weiterf\u00fchrende Untersuchung nicht mehr m\u00f6glich ist. Ein weiterer Aspekt sind die unterschiedlichen Personenkreise, die diese Aufgaben wahrnehmen. Operative und sicherheitstechnische Anforderungen stehen sich gegen\u00fcber und es gilt, beiden Aufgaben gerecht zu werden.<\/p>\n\n\n\n
Wir haben zus\u00e4tzliche Anforderungen, die adressiert werden m\u00fcssen. Die operative IT muss erkennen, dass es sich um ein sicherheitsrelevantes Thema handelt. Abgesehen von den offensichtlichen Vorf\u00e4llen ist dies nicht immer direkt ersichtlich weshalb auch f\u00fcr den Helpdesk und den operativen Support entsprechende Schulungen und regelm\u00e4ssige Sensibilisierung notwendig sind.<\/p>\n\n\n\n
Es ist zu bedenken, dass die Mitarbeitenden des Helpdesk das Ziel haben, schnell eine L\u00f6sung zu finden, und oft eine hohe Arbeitsbelastung besteht, die es ihnen verunm\u00f6glicht, weiter \u00fcber die St\u00f6rung nachzudenken. Wie kann dies angegangen werden? Je nach eingesetztem Tool hat sich ein zweistufiger Prozess bew\u00e4hrt. Im Incident wird eine Markierung f\u00fcr \u00abm\u00f6glicherweise sicherheitsrelevanter Incident\u00bb gesetzt. Damit wird das SOC-Team involviert, das in einem parallelen Prozess beurteilt, ob die Sicherheitsrelevanz gegeben ist. Wird dies bejaht, wird ein neues Security Incident Ticket er\u00f6ffnet.<\/p>\n\n\n\n
Das regul\u00e4re Incident Ticket wird zwar als \u00abSicherheitsrelevanter Incident\u00bb gekennzeichnet, die weitere Bearbeitung der St\u00f6rungsbehebung erfolgt dann jedoch unabh\u00e4ngig von der Arbeit des SOC-Teams am Security Incident. Dieses Vorgehen hat jedoch Nachteile; besser ist eine Zusammenarbeit oder mindestens Abstimmung, so dass durch die St\u00f6rungsbehebung keine Informationen f\u00fcr die weitere Analyse verloren gehen. Sinnvollerweise werden hierzu entsprechende \u00abRunbooks\u00bb f\u00fcr spezifische Szenarien vorbereitet. Zudem muss dieses Vorgehen f\u00fcr den Ernstfall mittels Tabletop-\u00dcbungen vorbereitet werden. Ein Eingreifen des SOC-Teams in die St\u00f6rungsbehebung ist jederzeit m\u00f6glich und die Awareness f\u00fcr die Sicherheitsrelevanz ist durch die Markierung ebenfalls gegeben.<\/p>\n\n\n\n
Beispiel anhand eines vereinfachten Prozessbildes<\/p>\n\n\n\n\n\n
Vorausgesetzt die Awareness im IT-Betrieb ist vorhanden, kann der regul\u00e4re operative Incident-Prozess eine wichtige Informationsquelle f\u00fcr das SOC sein. Bedingung ist eine gelebte Sicherheitskultur und eine Organisation, die f\u00fcr den Meldenden keinen Mehraufwand bedeutet.
Wichtig ist dabei auch, dass eine \u00abno blame\u00bb Kultur gelebt wird, d.h. im Zweifelsfall lieber zu viel melden als zu wenig. Im SOC-Team m\u00fcssen Sicherheitsexperten sitzen, denn so kann sich z.B. ein Helpdesk-Mitarbeiter absichern, ohne viel Aufwand zu haben oder zu erzeugen.<\/p>\n\n\n\n
Auch wenn es nicht direkt zum Incident geh\u00f6rt, sollte das Problem Management bzw. die \u00abRoot Cause Analyse\u00bb dort eigesetzt werden, wo es notwendig erscheint. Leider wird eine Root Cause Analyse meist nur dann durchgef\u00fchrt, wenn eine St\u00f6rung einen grossen Einfluss auf den Betrieb hatte. Wir sehen immer wieder, dass eine Root Cause Analyse f\u00fcr wiederkehrende, \u00e4hnliche Incidents auch zu neuen Erkenntnissen bez\u00fcglich Sicherheit f\u00fchren kann. Oft zeigt sich dann auch die Kreativit\u00e4t der Anwender, die mit viel Einfallsreichtum Policies und Restriktionen umgehen oder sogar in die Schatten-IT abwandern.
Eine systematische Vorgehensweise zur Sammlung und Bewertung von Incidents mit dem Ziel proaktives Problem Management anzuwenden, ist sicher sinnvoll.<\/p>\n\n\n\n
Zusammengefasst, die Eskalation eines Incidents zur \u00dcberpr\u00fcfung der Security-Relevanz muss<\/p>\n\n\n\n
Die CMDB ist erkl\u00e4rtermassen unsere wichtigste Datensammlung. Voraussetzung ist, dass die CMDB vollst\u00e4ndig und aktuell ist. Wie bereits im Teil 2 der Blogserie beschrieben, ist eine umfassende CMDB das Herzst\u00fcck des gesamten ITSM aber auch der Cyber Defense. Ein Incident ben\u00f6tigt in jedem Fall einen Verweis auf die betroffenen Configuration Items aus der CMDB, also auf Assets, Identities oder Services. Nur anhand der in diesen Objekten hinterlegten Klassifizierungen zu BCM und Security kann eine systematische Bewertung erfolgen.
Und ja, bez\u00fcglich CMDB wiederholen wir uns. Aber es ist nun mal so, die CMDB ist das zentrale Tool um alles andere zu bewerten und zu steuern.<\/p>\n\n\n\n
Da wir uns hier im operativen Betrieb befinden, sind auch alle Rollen des IT-Betriebs vertreten<\/p>\n\n\n\n
\nFazit: Ein Incident-Prozess mit gezielter und selektiver Erkennung von Security Incidents hilft die gesamte Security zu verbessern! Die Inputs aus diesen Incidents sind eine \u00e4usserts hilfreiche zus\u00e4tzliche Informationsquelle f\u00fcr das SOC.<\/h4>\n<\/blockquote>\n\n\n\n
Kopie meines Blogs aus www.terreactive.ch www.swiss-post-cybersecurity.ch<\/p>\n","protected":false},"excerpt":{"rendered":"
Neben allen technischen L\u00f6sungen ist der organisatorische Teil der Cyber Security ein weiterer Aspekt, der im Fokus stehen muss. In einer Serie von Blogartikeln beleuchten wir verschiedene Aspekte, die technische L\u00f6sungen erg\u00e4nzen und deren Wirksamkeit erh\u00f6hen k\u00f6nnen. Nach den Grundlagen, der Configuration Management Data Base (CMDB) und dem Change-Prozess geht es nun um den Incident-Prozess … mehr lesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,62,7,60,61,8,6],"tags":[124,127,23],"class_list":["post-479","post","type-post","status-publish","format-standard","hentry","category-gedanken","category-itil","category-leadership","category-management","category-strategie","category-technologie","category-unternehmensfuehrung","tag-isms","tag-iso-27001","tag-itil"],"_links":{"self":[{"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/posts\/479","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/comments?post=479"}],"version-history":[{"count":8,"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/posts\/479\/revisions"}],"predecessor-version":[{"id":535,"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/posts\/479\/revisions\/535"}],"wp:attachment":[{"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/media?parent=479"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/categories?post=479"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hwl-consulting.ch\/blog\/wp-json\/wp\/v2\/tags?post=479"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}