Im letzten Monat PagerDuty und Bedrohungsstapel kamen in Seattle zusammen, um gemeinsam einen Workshop zu veranstalten – „ Vorfallmanagement im 21. Jahrhundert „Als Senior Director of Operations and Support von Threat Stack hatte ich das Vergnügen, gemeinsam mit Jonathan Wilkinson, VP of Product von PagerDuty, über Cloud-Sicherheit und Vorfallmanagement zu sprechen.

Der rote Faden, der sich durch beide Gespräche zog, war die Frage, wie Unternehmen im Falle eines wichtigen Vorfalls die richtigen Personen schnell und effektiv benachrichtigen können, indem sie die Zusammenarbeit zwischen Betriebs-, Sicherheits- und Entwicklungsteams verstärken.

Sie sehen, ähnlich wie Teams benachrichtigt werden, wenn ihre Website ausfällt, gilt derselbe Prozess, wenn ihre Website gehackt wird. In der heutigen neuen Welt der Sicherheit können Organisationen ihre vorhandenen PagerDuty Warnprozesse effektiv auf sicherheitsrelevante Probleme anwenden. Und der beste Weg, dies zu ermöglichen, besteht darin, eine Kultur aufzubauen, in der Sicherheit an erster Stelle steht und die effektive Sicherheitswarnungen, Eskalationen und Zusammenarbeit ermöglicht. Dies ist tatsächlich einer der Hauptgründe, warum PagerDuty und Threat Stack kürzlich kündigte eine Integration Damit können Kunden Cloud-Sicherheitsvorfälle wie Benutzeranmeldungen, laufende verdächtige Prozesse und Konfigurationsänderungen innerhalb von PagerDuty verwalten.

Ein Punkt, über den wir uns während des Workshops alle einig waren, war, dass angesichts der sich schnell entwickelnden Bedrohungen eine Kultur, in der Sicherheit an erster Stelle steht, kein nettes Extra mehr ist, sondern ein Muss. Bei Threat Stack haben wir uns schon sehr früh entschieden, eine Kultur einzuführen, in der Sicherheit an erster Stelle steht, indem wir unsere Sicherheits-, ITOps- und DevOps-Teams integriert haben. Hier sind einige Dinge, von denen wir gelernt haben, dass sie beim Aufbau dieser Kultur wirksam sind, und ein Blick darauf, wie wir dies erreicht haben.

Die beste Sicherheitskultur ist kollaborativ, nicht vorschreibend

Es ist keine leichte Aufgabe, Ihrem gesamten Team das Verständnis von Sicherheit und Vorfallreaktion zu vermitteln. ITOps- und DevOps-Teams werden heute mit Fragen konfrontiert, mit denen sie sich noch nie zuvor befassen mussten – mit Fragen, die bisher nur als Probleme des „Sicherheitsteams“ galten.

Hier sind einige der am häufigsten gestellten Fragen:

• Wie können wir hinsichtlich der Anwendungssicherheit proaktiver werden?
• Wie erstellen wir standardmäßig sichere Systeme?
• Welche Werkzeuge eignen sich am besten, um all dies zu erreichen?
• Wie benachrichtige ich die richtigen Personen mit den richtigen Informationen in kürzester Zeit?

Sicherheit sollte so integral und kollaborativ wie möglich sein – nicht starr und vorschreibend. Aber was, wenn Sie kein eigenes Sicherheitsteam haben? Was, wenn Sie ein kleines, ressourcenbeschränktes Startup sind? Die Realität ist, dass wir alle, wenn es um Sicherheit geht, unabhängig von der Teamgröße unter den gleichen Zeit- und Ressourcenbeschränkungen leiden und alle dasselbe wollen: bessere Sicherheit. Tatsächlich unterscheidet sich die Einführung moderner Sicherheitsrichtlinien nicht sehr von der Einführung von DevOps-Praktiken. Durch die Einbettung der Überwachung in die täglichen Arbeitsabläufe können Sicherheits-, DevOps- und ITOps-Teams die tiefen Einblicke in Dienste, Benutzer und Aktivitäten gewinnen, die sie benötigen, um die Anwendungssicherheit zu gewährleisten. Viele Unternehmen haben heute bereits Erfahrung Integration von DevOps-Methoden — GE Hauptstadt , Macy's, Ziel , Und Nordstrom waren einige der allerersten. Angesichts einiger ziemlich mächtiger und fest verwurzelter Silos beruhte der Erfolg von DevOps in jedem dieser Unternehmen auf der Ermöglichung kollaborativer Kulturen. Die gleichen Prinzipien können auch auf die Implementierung einer Kultur angewendet werden, in der Sicherheit an erster Stelle steht. Ein weiteres großartiges Beispiel ist die dreijährige Transformation der Twitter Infosec-Funktion , die mit dem Hacken des @BarackObama-Kontos begann. Es ist eine unglaubliche Geschichte darüber, wie sie Sicherheit in die tägliche Arbeit von Entwicklungs- und Betriebsteams integriert haben, mit der Hauptaufgabe, ihnen nicht im Weg zu stehen.

Sicherheitsprozesse und Transparenz gehen Hand in Hand

In den letzten Jahren habe ich mit vielen Threat Stack-Kunden gesprochen, die mehr Sicherheitstransparenz in die Aktivitäten auf ihren Systemen benötigen. Auch viele Betriebsmitarbeiter möchten dies – Einblick in das, was auf ihrem Stack passiert. Aber alle Einblicke der Welt helfen ihnen nichts, wenn sie keine definierten Prozesse zur Behandlung von Ereignissen haben.

Viele Leute sagen: „Das muss doch einfach für Sie sein. Sie können Threat Stack einfach intern verwenden.“ Das stimmt zwar, und das tun wir auch, aber wenn die interne Kultur und die Prozesse nicht darauf ausgelegt sind, die Daten zu unterstützen, die Tools wie Threat Stack und PagerDuty liefern, können Sie diese genauso gut auch gar nicht haben (obwohl wir zugegebenermaßen hoffen, dass Sie sie haben). Man kann also mit Sicherheit sagen, dass der Versuch, veraltete Tools (NIDS, irgendjemand?) in eine modernere Cloud-native Welt zu zwängen, Unternehmen unnötige Probleme bereiten würde.

Durch die Entwicklung einer Kultur, in der Sicherheit an erster Stelle steht, einschließlich des Workflows, den die PagerDuty und Threat Stack-Integration für das Vorfallmanagement und die Vorfalllösung bietet, konnten wir unsere Reaktionszeit durch die Automatisierung von Warnmeldungen und Daten zu Sicherheitsereignissen verkürzen. Die richtigen Leute so schnell wie möglich zusammenzubringen, um die Situation einzuschätzen, war ein großer Beitrag zur Verkürzung unserer Zeit bis zur Lösung. So konnten wir uns auf das Reagieren und Lösen konzentrieren, anstatt im Unkraut zu stecken.

Wie Threat Stack eine Kultur implementiert hat, in der Sicherheit an erster Stelle steht

Alarmeskalation mit PagerDuty

Wir bei Threat Stack sind große PagerDuty Fans , und ich persönlich verwende PagerDuty seit dem Jahr ihrer Einführung. Die Leute denken oft darüber nach, PagerDuty zu verwenden, wenn ihre Website abstürzt oder ihre Datenbank offline geht, aber PagerDuty ist mehr als nur dafür geeignet. Es ist ein erstaunliches Tool, das wir bei Threat Stack täglich für Produktionswarnungen, Integritätsprüfungen, Analysen und einige andere coole benutzerdefinierte Sicherheitsanwendungsfälle verwenden. Wir betrachten es als eines der wichtigsten und wertvollsten Tools, die wir intern haben.

PagerDuty hilft uns bei Threat Stack auf verschiedene Weise bei der Implementierung kollaborativer und gut sichtbarer Sicherheitsprozesse:

• Benachrichtigungen von Produktionssystemen mit hohem Warnschweregrad
• Planung und Außerkraftsetzungen
• Eskalationsgruppen pro Dienst
• Verdächtige Anmeldungen oder laufende Prozesse

Die teuflisch traurige Posaune weckt unser Team – sogar mitten in der Nacht – um uns mitzuteilen, dass es Probleme in der Cloud gibt. Wir haben eine Hassliebe zu diesem berüchtigten Alarmton; er hält uns zu jeder Tageszeit auf Trab, damit wir als Team über Transparenz und Reaktionsprozesse verfügen, um die Sicherheit unserer Anwendungen und Systeme zu gewährleisten.
Offene Kommunikation mit Slack

Ein weiterer Prozess, den wir implementiert haben, war die Integration unserer Sicherheitswarnungen in Locker — dasselbe Chatsystem, das wir intern für alles andere verwenden. Wenn jetzt eine Sicherheitswarnung ausgelöst wird, sendet Threat Stack eine Nachricht in einen dafür vorgesehenen Slack-Kanal, sodass jeder im Kanal sie sehen und reagieren kann. Das wirklich Tolle daran ist, dass wir in Slack in Echtzeit über das stattfindende Ereignis sprechen können. Wurde Code übertragen? War das ein versehentlich fehlgeschlagener Login bei einem Host?

Für das Threat Stack-Team ist die wertvollste Funktion von PagerDuty , dass es den Leuten einen Ort bietet, an dem sie ein Gespräch beginnen und etwas sagen können, wenn sie etwas sehen. Wir können dann Slack verwenden, um dies zu bestätigen, zu diskutieren und hoffentlich schnell zu verwerfen.

Einen Prozess zu etablieren – selbst wenn es nur ein einfacher ist – ist besser als gar nichts. Von dort aus können die Teams ihren Prozess jederzeit anpassen, insbesondere wenn das Unternehmen wächst und sich weiterentwickelt. In allen vorherigen Beispielen brauchten wir Tools, um „standardmäßig sichere Systeme“ zu implementieren, aber wir brauchten auch eine Unternehmenskultur, die es jedem ermöglichte, Sicherheitsprobleme anzusprechen und das Bewusstsein dafür zu schärfen.

Ich ermutige alle Unternehmen, mit der Umsetzung eines ähnlichen Ansatzes zu beginnen, damit wir als Gemeinschaft bessere Cloud-Sicherheitspraktiken demonstrieren können.