Irgendwann bekommt man einen Riecher für Dinge, die sich nicht richtig anfühlen. Dinge, die vernünftig klingen, wenn man sie erklärt, aber man hat das nagende Gefühl, dass es irgendwie gegen die Natur geht. Die Arbeit mit Scrum und die Einhaltung von ISO-Standards ist eines dieser Dinge. Hier finden Sie 5 Möglichkeiten, wie Sie einen strengen Sicherheitsstandard einhalten können, ohne dabei gegen Scrum-Werte wie Fokus, Offenheit oder seine Säulen Transparenz, Anpassung und Vertrauen zu verstoßen.
Und warum? Warum? Warum?
[pullquote]"Ich bin nicht verrückt; zu gut, zu gut geht es mir" - Shakespeare, Das Leben und der Tod des König Johann Akt 3, Szene 4[/pullquote] Nun, wie bei allem: weil der Markt es verlangt. Ob zu Recht oder nicht, einige Kunden fühlen sich beruhigt, wenn sie wissen, dass ihr Anbieter über ein Verfahren verfügt, um mit ihren sensiblen Daten umzugehen. Es ist nicht verwunderlich, dass sie einen sorgfältigen Umgang mit diesen Daten verlangen. Es ist nur so, dass die Implementierung in einigen Unternehmen die agile Denkweise effektiv erstickt hat und in anderen nicht. Wenn der Markt also verlangt, dass Sie diese Medizin nehmen, was ist dann der Löffel Zucker?
Was ist ISO 27001?
Es handelt sich um einen internationalen Standard für Informationssicherheit. Aber anstatt Wikipedia zu kopieren, sollten wir uns die 5 Aspekte ansehen, die er abdeckt, und sehen, ob wir ihn mit Scrum umsetzen können:
- Kontext der Organisation
- Führungsqualitäten
- Planung
- Unterstützen Sie
- Operation
- Leistungsbewertung
- Verbesserung
1.) Kontext der Organisation
Eine oft übersehene Absicht des Standards ist es, Unternehmen die Möglichkeit zu geben, eine Zertifizierung für eine Teilmenge des Prozesses zu beantragen. Anstatt die Referenzvorlage zu kopieren, wäre es sinnvoll, zunächst herauszufinden, welche Kunden für welche Produkte und/oder Dienstleistungen eine Zertifizierung beantragen .
Möglicherweise stellen Sie fest, dass der Umfang viel kleiner ist, als Sie erwarten würden. Aber wenn Sie das herausgefunden haben, werden Sie wahrscheinlich auch das Scrum-Team in Ihrer Organisation finden, das dafür zuständig ist. Es ist
2.) Führungsqualitäten
Dies ist wahrscheinlich die gefährlichste Klausel des Standards. Sie verlangt vom Management, dass es:
- Verpflichten Sie sich zur Wahrung der Sicherheit (das sollte kein Problem sein)
- Legen Sie eine Richtlinie fest (aber geben Sie nicht das Format/die Medien an)
- Weisen Sie den zuständigen Personen Verantwortung und Befugnisse zu
Dieser Punkt ist der schwierigste, denn in Scrum sollte sich das Team selbst organisieren und hat nun diesen Informationsmanager, der mit Autorität und Verantwortung herumläuft. In einem Fall führte dies zu dem, was das Team als ISO-Gestapo bezeichnete. Aber der Standard sagt nicht, dass Sie diese Aufgabe einer Personzuweisen sollen... er will nur sicherstellen, dass wir uns an den Standard halten und melden, wenn wir es nicht tun. Prüfen und anpassen ist der Kern dessen, was wir tun. Transparenz, nun ja... Eine Sache, über die man nachdenken sollte, ist die Frage, wie man inspiziert und die Ergebnisse weitergibt, wenn Ihr Kontext größer ist als ein einzelnes Team. Es ist nichts, was ein Abschaum-Ritual nicht beheben könnte, aber Sie müssen es vielleicht zu Prüfungszwecken ein wenig dokumentieren. Seien Sie kreativ:
3.) Planung
Bei der Planung geht es nicht darum, den perfekten Plan zu erstellen, sondern um den Prozess. Finden Sie also heraus, was Sie auf konsistente Weise tun müssen. In vielerlei Hinsicht ist dies vergleichbar mit dem, was ein Product Owner tut, um herauszufinden, was wertvoll ist.
- Entwickeln Sie eine Methode, um das Sicherheitsrisiko zu bewerten.
- Sagen Sie manchmal NEIN
Ups, was habe ich da gerade geschrieben? Nun, da gutes Product Ownership dadurch definiert ist, dass man Nein zu Dingen sagt, die keinen Wert liefern, muss es eine gleiche Schwelle bei der Bewertung von Risiken geben. Wenn wir keine Schwelle haben, wird die Liste immer länger und länger und frisst all unsere Ressourcen auf.
[caption id="attachment_19683" align="aligncenter" width="450"]
Nur eine weitere Risikomatrix[/caption]
Versuchen Sie etwas in der Art. Wenn Ihre Matrix kein für Sie akzeptables Niveau aufweist, werden Sie irgendwann ertrinken. Es wird auch erwähnt, dass Sie Pläne entwickeln sollten, um Ihre Sicherheitsziele zu erreichen. Auch dafür haben wir ein agiles Rezept. Es heißt User Story, nun ja, nennen wir es die Security Story: Eine <Persona, die unter dem Risiko> leidet, wird darunter leiden, wenn <Sicherheitsereignis> eintritt. Das würde zu <Auswirkungen für die Persona> führen. Beispiel: Als Internetbanking-Nutzer würde ich darunter leiden, wenn eine externe Partei Zugriff auf mein Konto erhält. Das könnte zum Verlust von Kapital oder sogar zu Schulden führen. Die Pläne zur Lösung dieses Risikos könnten eine Zwei-Faktor-Authentifizierung beinhalten. Als Internet-Banking-Benutzer kann ich nicht ohne eine Zwei-Faktor-Authentifizierung auf mein Konto zugreifen, so dass der Zugriff auf etwas basiert, das ich kenne (Passwort) und etwas, das ich habe (z.B. eine Karte oder ein Telefon). Das ist natürlich stark vereinfacht, aber es ist leicht zu erkennen, dass die Verwaltung eines Backlogs eine geeignete Umsetzung der Planerstellung ist und der Anpassungs-Säule von Scrum entspricht.
4.) Unterstützung und Betrieb
Im Grunde heißt es: "Tun oder nicht tun, es gibt keinen Versuch." Schreiben Sie keinen Plan und legen Sie ihn in die Schublade, schaffen Sie keine Struktur und umgehen Sie sie dann, sagen Sie nicht, dass Sie Penetrationstests durchführen werden und lassen Sie sie dann aus, weil es zu schwierig ist. "Tun Sie, was Sie sagen, sagen Sie, was Sie tun". Indem Sie die Praktiken in den Scrum-Prozess einbinden, werden sie Teil des natürlichen Zyklus. Das bedeutet, dass die Mitarbeiter darin geschult werden, genau wie in jeder anderen Praxis, die das Team für notwendig erachtet. Wie bereits gesagt, müssen Sie vielleicht einen Papierpfad erstellen, um nachprüfbar zu sein, aber halten Sie es so einfach wie möglich und automatisieren Sie es so gut es geht.
5.) Leistungsbewertung
Der Standard fordert eine unparteiische Prüfung und ein internes Auditverfahren. Der Satz allein reicht schon aus, um bei agil denkenden Menschen mehrere rote Fahnen zu wecken, und als agiler Coach sehen Sie darin entweder ein Kontrolltor, das uns ausbremst, oder eine "Gestapo", die unseren Prozess unterbricht. Es ist nicht so, dass wir etwas gegen eine regelmäßige Bewertung der Leistung hätten, im Gegenteil, wir begrüßen sie. Die Kontroll- und Anpassungsschleife ist der Kern unserer Arbeit. Denken Sie an das tägliche Scrum, die Sprint Review, den jeweiligen Sprint, automatisierte Tests, Pair Programming usw. Aber die meisten dieser Rituale sind teambasiert und basieren auf Vertrauen. Ein Team ist ein sicherer Ort. Die Transparenz entsteht dadurch, dass wir keine Fehler machen dürfen und am gleichen Ziel arbeiten. Externes Auditing fühlt sich nicht wie ein Spiel an, oder doch? Ich erinnere mich an ein Projekt, bei dem 3 Teams an einer neuen Plattform arbeiteten, aber nach einigen Sprints feststellten, dass sie unterschiedliche Muster zur Lösung ähnlicher Probleme verwendet hatten. Die Teams waren sich einig, dass dies die Wartung komplexer machen würde. Anstatt einen zentralen Architekten zu ernennen, der entscheiden sollte, welches Muster verwendet werden sollte, und die Teams anzuleiten, begannen sie, sich gegenseitig zu überprüfen. Damit wurde nicht nur das Problem der Architekturmuster gelöst, sondern auch Dinge wie Integrationstests, Bereitstellungsskripte usw. Aber vor allem hat es den Kreis des Vertrauens erweitert. Anstelle eines internen Auditors sollten Sie sich für ein Sicherheitskapitel entscheiden (oder eine Gilde, wenn Sie größer sind, aber dann müssen Sie vielleicht das Kapitel über den Umfang noch einmal überarbeiten). Ashley-Christian hat eine schöne Erklärung.
Verbesserungsbedarf
Klar, wir machen Scrum. Das ist es, was wir tun. Durch die Integration von ISO in Ihren Scrum-Prozess werden viele Aspekte automatisch und auf kollaborative Weise gehandhabt, was viel besser ist als das Kopieren und Einfügen einer Kontrollstruktur, die Ihre Agilität einschränkt.
Fazit
"Ich glaube, wenn Sie sich genug anstrengen und das Beste aus einer Situation machen, wird die Situation nicht das Beste aus Ihnen herausholen." - MacGyver (Geburtstag)
Sie müssen nicht eine Standardvorlage der ISO akzeptieren und Ihre Agilität erdrosseln. In der Spezifikation gibt es genügend Spielraum, um Scrum zu stärken, anstatt es zu schwächen. Haftungsausschluss: Wir haben dies noch nicht zertifiziert. Aber mit ähnlichen Erfahrungen bei ISO 9001 und CMMI sollte es gut funktionieren.
Möchten Sie mehr über Agilität, Kampfsport und Produktmanagement erfahren? Bestellen Sie das Buch bei bol.com, wenn Sie in den Niederlanden oder Belgien leben, oder melden Sie sich an, um die internationale Ausgabe zu erhalten.
Verfasst von
Chris Lukassen
Unsere Ideen
Weitere Blogs
Contact