Sicherheitsarchitektur für die Hybrid Cloud

Kapitel 4. Anforderungen und Beschränkungen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Die Anforderungen für ein Informationssystem enthalten eine Spezifikation oder Beschreibung der funktionalen Fähigkeiten, die ein System bieten sollte, sowie der Eigenschaften oder Qualitäten, die es aufweisen sollte. Zwingende externe und interne Anforderungen, die an ein System gestellt werden, machen aus Anforderungen Zwänge.

Die Begriffe nicht-funktionale Anforderungen, architektonische Merkmale und Qualitäten werden oft synonym verwendet. Sie beziehen sich alle auf dieselbe Art von Anforderungen, die den Ansatz für die Systembereitstellung definieren. Darauf werden wir später in diesem Kapitel näher eingehen.

Die Dokumentation von Anforderungen erfolgt in verschiedenen Formen, je nach Art der Anforderung und der Entwicklungs- und Liefermethoden. In diesem Kapitel werden wir die verschiedenen Techniken besprechen und uns auf die Techniken konzentrieren, die für die Definition von Sicherheitsanforderungen am besten geeignet sind.

Abschließend werden wir uns ansehen, wie die Rückverfolgbarkeit der Anforderungen durch die Dokumentation der Architektur, der Betriebsdokumentation und der Tests entscheidend ist, um Vertrauen in die Umsetzung und den Betrieb der Anforderungen zu schaffen.

Kapitel Artefakte

Das Hauptziel dieses Kapitels ist es, die Definition und Dokumentation von Sicherheitsanforderungen für ein System zu diskutieren. In Abbildung 4-1 werden die Anforderungen und Einschränkungen, die sich aus dem externen und internen Kontext der Organisation ergeben, mit weißem Text in einem schwarz schattierten Kasten am oberen Rand des Artefaktabhängigkeitsdiagramms hervorgehoben. Im Anforderungsbereich heben wir die Artefakte für die Definition der funktionalen und nicht-funktionalen Anforderungen hervor, wobei die Matrix für die Rückverfolgbarkeit der Anforderungen unten rechts hervorgehoben wird .

Abbildung 4-1. Artefakt-Abhängigkeitsdiagramm des Kapitels Anforderungen und Beschränkungen

Wir beginnen mit einer Diskussion über einige Konzepte zu Anforderungen, die den Rahmen für die Diskussion über die Artefakte bilden, die zur Beschreibung von Anforderungen verwendet werden.

Anforderungen Konzepte

Anforderungen sind eine Beschreibung dessen, was ein Informationssystem leisten muss, und bieten eine Orientierungshilfe für die Entwicklung einer Lösungsarchitektur. Sie beschreiben die Funktionalität, die Architekturmerkmale und die Einschränkungen eines Systems. Lass uns das etwas genauer besprechen.

Funktionale Anforderungen

Funktionale Anforderungen beschreiben , was ein Informationssystem leisten soll. Mit anderen Worten: Sie definieren die funktionalen Aspekte des Informationssystems, wie es von der Software bereitgestellt wird. Funktionale Anforderungen beschreiben die Abfolge der Aktivitäten, wann sie beginnen und enden, die Eingaben und Ausgaben sowie das Verhalten und die Verarbeitung der Daten.

Das zweite Merkmal funktionaler Anforderungen ist, dass sie die primäre Funktionalität des Systems beschreiben, z. B. die Online-Bestellung eines Produkts. In Bezug auf die Sicherheit könnte dies die Abfolge der Schritte sein, mit denen sich ein Kunde in einem Online-Shop anmeldet, aber nicht die Anmeldesequenz für den Systemadministrator, die eine nicht-funktionale Anforderung ist. Die Techniken und Artefakte, die für die Beschreibung der Anforderungen verwendet werden, können jedoch für beide die gleichen sein.

Die Sicherheit kann zusätzliche Perspektiven einbringen, die bei der Beschreibung der funktionalen Anforderungen berücksichtigt werden müssen. Welche Entscheidungen haben Auswirkungen auf die Sicherheit des Systems? Wie zeichnen wir Aktivitäten auf, um einen Prüfpfad zu erstellen? Wie überwachen wir Aktivitäten, die eine Bedrohung für das System darstellen könnten?

Als Architekt denkst du vielleicht, dass das Sammeln von Anforderungen die Aufgabe eines Business-Analysten oder eines Sicherheitsberaters ist. Auch wenn jemand anderes diese Anforderungen sammelt, bist du für die Sicherheitsarchitektur verantwortlich und musst daher sicherstellen, dass du vollständige und hochwertige Anforderungen erhältst.

Wenn du den vollständigen Kontext kennst, musst du in der Lage sein, nicht sicherheitsrelevante Anforderungen zu hinterfragen und zu ändern, da sie sich negativ auf andere Merkmale des Systems auswirken können. Beispiele dafür sind die Frage, ob die Anwendung für die Anmeldung eine Multifaktor-Authentifizierung verwendet und ob diese für die Authentifizierung bestimmter Transaktionen obligatorisch ist.

Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen beschreiben , wie das Informationssystem die erforderliche Funktionalität bereitstellen soll. Sie werden oft als Architekturmerkmale des Systems beschrieben und umfassen Sicherheit, Datenschutz, Skalierbarkeit, Verfügbarkeit, Wiederherstellbarkeit, Benutzerfreundlichkeit und viele andere Merkmale.

Du wirst feststellen, dass viele nicht-funktionale Anforderungen eher für das Gesamtsystem als für bestimmte Teile davon gelten. Die nicht-funktionale Anforderung in Tabelle 4-1 zeigt eine Anforderung, die für das gesamte System gilt.

Tabelle 4-1. Systemweite nicht-funktionale Anforderung

ID	Anforderung
NFR_SEC_AU_001	Eine Änderung aller Authentifizierungsdaten, die bei der Kommunikation zwischen den Systemen verwendet werden, MUSS alle 30 Tage erfolgen.

Viele nicht-funktionale Anforderungen sind in Kontrollrahmen, Sicherheitsrichtlinien und Praktiken enthalten. Es kann sein, dass du am Ende Hunderte dieser unternehmensweiten, detaillierten Anforderungen hast.

Andere nicht-funktionale Anforderungen sind jedoch spezifisch für die Bereitstellung einer Fähigkeit in deiner Lösungsarchitektur. Die nicht-funktionale Anforderung in Tabelle 4-2 zeigt eine Anforderung, die für eine bestimmte Komponente eines Systems gilt.

Tabelle 4-2. Nicht-funktionale Einzelanforderung

ID	Anforderung
NFR_SEC_FW_001	Die Kanten-Firewall MUSS eine Spitzenanwendungs-Transaktionsrate von 1.000 aktiven Verbindungen und 10 MB/Sek. im ausgehenden Verkehr unterstützen.

Merkmale, Qualitäten oder nicht-funktionale Anforderungen

Organisationen verwenden verschiedene Begriffe, um nicht-funktionale Anforderungen zu beschreiben, z.B. Architekturmerkmale oder Qualitätseigenschaften.

In Kapitel 4 des Buches Fundamentals of Software Architecture plädieren Richards und Ford für die Verwendung des Begriffs " Architekturmerkmale" ( ), weil der Begriff "nicht-funktionale Anforderungen" sich selbst herabwürdigt. Mit anderen Worten: Er könnte suggerieren, dass nicht-funktionale Anforderungen nicht so wichtig sind wie funktionale Anforderungen. Das ist weit gefehlt, denn die Verwendung von nicht-funktionalen Anforderungen zur Beschreibung der Umsetzung von funktionalen Anforderungen ist genauso wichtig.

DieISO/IEC 25010:2023 über System- und Softwareentwicklung verwendet den Begriff Produktqualitätseigenschaften, die aus acht Kategorien von Merkmalen bestehen:

• Funktionale Eignung

• Leistungseffizienz

• Kompatibilität

• Benutzerfreundlichkeit

• Verlässlichkeit

• Sicherheit

• Instandhaltbarkeit

• Tragbarkeit

Die Sicherheitskategorie enthält Untermerkmale wie Vertraulichkeit, Integrität, Verfügbarkeit, Nicht-Abstreitbarkeit, Verantwortlichkeit und Authentizität. Diese Liste sollte dir bekannt vorkommen. Die acht Kategorien, die sie verwenden, sind jedoch nur eine kleine Teilmenge dessen, was in den Bereich der nicht-funktionalen Anforderungen fällt.

Wir bleiben bei dem Begriff nicht-funktionale Anforderungen, da architektonische Merkmale darauf hindeuten, dass es sich nicht um Anforderungen handelt, und die in der ISO 25010:2023 beschriebenen Qualitäten nur einen kleinen Teil der nicht-funktionalen Anforderungen ausmachen. Wenn du verschiedene Publikationen liest, solltest du dir bewusst sein, dass sie sich auf nicht-funktionale Anforderungen mit unterschiedlichen Begriffen beziehen.

Erörtern wir nun einige Kategorien nicht-funktionaler Anforderungen (oder architektonischer Merkmale), die für das architektonische Denken für sicheres Design wichtig sind:

Sicherheit

Sicherheit wird normalerweise als die Anforderung ausgedrückt, Daten vor dem Verlust von Vertraulichkeit, Integrität und Verfügbarkeit zu schützen. Man könnte sagen, dass Sicherheit eher eine Familie von Architektureigenschaften ist. Aus ihnen lassen sich weitere Anforderungen ableiten. Der Schutz vor dem Verlust der Vertraulichkeit erfordert eine Identifizierung und Authentifizierung, um die Rechenschaftspflicht zu unterstützen.

Viele dieser Anforderungen ergeben sich aus den Richtlinien, Standards und Leitlinien der Organisation, aber externe Industriestandards, die speziell für die Anwendung gelten, können zusätzliche Anforderungen stellen. Zum Beispiel kann eine Organisation die Verwendung von mindestens transport layer security (TLS) 1.2 verlangen, aber der externe Standard verlangt TLS 1.3, was die in der Lösung verwendeten Technologiekomponenten einschränken kann.

Sammle zu Beginn eines Projekts die geltenden Richtlinien, Standards und Leitlinien und identifiziere die Kontrollanforderungen, die dir Probleme bei der Einhaltung bereiten könnten. Füge diese zu deiner Liste der Risiken oder Probleme hinzu, die du in deinem Projekt managen musst. Auf das Management von Projektrisiken und -problemen werden wir später in Kapitel 10 näher eingehen.

Datenschutz

Mit kann eine Person oder eine Gruppe sich selbst oder Informationen über sich selbst schützen und kontrollieren, welche Informationen öffentlich zugänglich sind. Der Bereich der Sicherheit, der Konzepte wie die angemessene Offenlegung von Informationen umfasst, ist in gewisser Weise mit der Privatsphäre verknüpft.

Wie in Kapitel 3 erläutert, ist der Datenschutz ein wichtiger Faktor für den Schutz sensibler persönlicher Daten. Möglicherweise gibt es Gesetze oder Vorschriften wie die DSGVO, aus denen sich Anforderungen ableiten lassen.

Skalierbarkeit

Skalierbarkeit ist die Fähigkeit eines Informationssystems, seine Rechen-, Speicher- und Netzwerkkapazität zu erhöhen. Wenn das System nicht skalierbar ist, kann dies zu einem Verlust der Verfügbarkeit führen. Das ist ein wichtiger Aspekt für einen Architekten, der eine Lösung für einen Sicherheitsdienst entwickelt. Wenn ein Sicherheitsdienst nicht skaliert werden kann, um dem Wachstum der Kunden gerecht zu werden, kann dies zu einem Ausfall des gesamten Systems führen.

Ein System zur Verwaltung von privilegierten Zugängen kann zum Beispiel so konzipiert sein, dass die Passwörter beim Booten eines Servers nur selten abgefragt werden. In einer Container-Umgebung steigt die Häufigkeit stark an, und wenn der Dienst nicht skaliert werden kann, kann dies zu einem Denial-of-Service führen und die Verfügbarkeit des Dienstes beeinträchtigen. Du musst die Skalierbarkeit von Anfang an einplanen, zusammen mit der fortlaufenden Planung durch das Security Operations Team. Die Einbeziehung von Leistungs- und Kapazitätsmanagement wird zu einem wichtigen Teil der Lösung für das Privileged Access Management.

Verfügbarkeit

Verfügbarkeit konzentriert sich darauf, ein Informationssystem verfügbar zu halten. Mit dem Übergang zu cloudbasierten Anwendungen, die eine ständige Verfügbarkeit von Sicherheitsdiensten erfordern, wird dies für die Gestaltung von Sicherheitsdiensten immer wichtiger.

In der Vergangenheit haben wir einen verschlüsselten Server vielleicht alle paar Monate neu gestartet. Der Verlust eines Schlüsselverwaltungsservers hätte keine unmittelbaren Auswirkungen gehabt und ein Neustart des Servers konnte verschoben werden. In einer Container-Umgebung, die alle paar Minuten oder Sekunden neu gestartet wird, wird ein Schlüssel, der für den Start der Container benötigt wird, kritisch. Der Verlust eines Schlüsselmanagers hätte unmittelbare Auswirkungen.

Aus diesem Grund müssen Sicherheitsdienste oft eine höhere Verfügbarkeit aufweisen als die Anwendungen, die sie unterstützen. Du musst vielleicht in Betracht ziehen, einen Sicherheitsdienst auch nach mehreren Ausfällen der Infrastruktur verfügbar zu halten. Das Sicherheitsteam muss möglicherweise von einem Bereitschaftsdienst mit stundenlangen Reaktionszeiten zu einem 24×7-Support mit Reaktionszeiten von wenigen Minuten wechseln.

Wiederherstellbarkeit

Wiederherstellbarkeit ist die Fähigkeit, Daten, Dienste und Abläufe nach einer Unterbrechung eines Dienstes schnell wiederherzustellen. Wir haben bereits in der Diskussion über Skalierbarkeit und Verfügbarkeit erläutert, wie wichtig Sicherheitsdienste sind. Daraus folgt, dass die Wiederherstellung des Dienstes von entscheidender Bedeutung ist, insbesondere aufgrund des Wechsels der Compute-Architektur zu Cloud-nativen Container-Anwendungen.

Bei der Wiederherstellung eines Rechenzentrums müssen die Sicherheitsdienste oft Vorrang vor der Wiederherstellung haben, um die anschließende Wiederherstellung der Anwendungen zu ermöglichen. Stelle sicher, dass die Backups vollständig sind, die Daten synchronisiert werden und die Wiederherstellung regelmäßig getestet wird, damit du die Anforderungen der abhängigen Anwendungen erfüllen kannst.

Es gibt zwei wichtige Messgrößen für die Wiederherstellung: das Wiederherstellungspunktziel (RPO) und das Wiederherstellungszeitziel (RTO). Das RPO ist das Ausmaß des Datenverlustes bei einem Ausfall eines Informationssystems. Im Idealfall gibt es keinen, aber wenn die Daten an einen entfernten Standort mit erheblicher Latenzzeit kopiert werden, ist eine synchrone Datenreplikation möglicherweise nicht möglich und eine asynchrone Replikation führt zu Datenverlust. Überlege dir, wie du mit dem Datenverlust umgehst.

Die RTO gibt die Zeit an, die zur Wiederherstellung nach einem Ausfall benötigt wird. Wenn die Anwendung innerhalb von 30 Minuten wiederhergestellt werden muss, stehen den abhängigen Sicherheitsdiensten möglicherweise nur 10 Minuten zur Verfügung, so dass der Anwendung 20 Minuten zur Wiederherstellung bleiben. Dies kann eine Verbesserung der Verfügbarkeitscharakteristik erfordern, um den Ausfall mehrerer Komponenten zu bewältigen und die Ausfallsicherheit der Sicherheitsdienste zu erhöhen.

Deine Schlüssel im Auto einschließen

Bei der Wiederherstellung von Sicherheitsdiensten musst du die Reihenfolge der Wiederherstellung beachten. Die Wiederherstellung von Schlüsseln ist möglicherweise nur möglich, wenn die Speicherung die Entschlüsselung bereits abgeschlossen hat. Es könnte zum Beispiel sein, dass der Neustart der Firewall nicht stattfinden kann, da er die Kommunikation mit dem HSM ermöglicht, die für die Entschlüsselung der Boot-Diskette der Firewall erforderlich ist. Wenn es keine andere Methode gibt, um die Schlüssel abzurufen, können wir diese zirkuläre Abhängigkeit nicht auflösen. Das ist das Szenario mit den im Auto eingeschlossenen Schlüsseln, bei dem du das Auto nicht öffnen kannst, weil die Schlüssel darin eingeschlossen sind. Die gleiche Überlegung muss bei der Verwaltung von Geheimnissen und Zertifikaten angestellt werden.

Benutzerfreundlichkeit

Benutzerfreundlichkeit ist die Leichtigkeit, mit der ein Benutzer oder Bediener mit einem Informationssystem interagiert. Bei der Sicherheit ist sie besonders wichtig, denn wenn die Hürde für die Benutzerfreundlichkeit zu groß ist, werden die Benutzer versuchen, die Sicherheitskontrollen zu umgehen, die ihnen im Weg stehen.

So sind zum Beispiel die Regeln für die Wiederverwendung eines Passworts im Laufe der Jahre immer ausgefeilter geworden, da die Nutzer/innen einen Weg finden, sich ihre Passwörter leicht zu erinnern. Ein weiteres Beispiel sind umständliche Identitätsüberprüfungsprozesse, die dazu führen, dass Nutzer falsche Angaben machen, um die Kontrollen zu umgehen.

Wenn du Sicherheitsmaßnahmen hinzufügst, überlege, ob sie Verhaltensweisen fördern, die zusätzliche Schwachstellen oder die Umgehung von Kontrollen mit sich bringen.

Merkmale der Softwarearchitektur

Wir haben nicht versucht, alle Kategorien von nicht-funktionalen Anforderungen aufzulisten. In Kapitel 4 von Grundlagen der Softwarearchitektur findest du eine ausführlichere Diskussion über Architekturmerkmale und die verschiedenen Kategorien von Architekturmerkmalen (auch bekannt als nicht-funktionale Anforderungen).

Sicherheit wird oft als nicht-funktionale Anforderung beschrieben, aber in Wirklichkeit wird Sicherheit auch durch funktionale Anforderungen spezifiziert. Eine Anmeldesequenz für eine Anwendung erfordert Funktionen zur Identifizierung und Authentifizierung des Benutzers, bevor er auf die Anwendung zugreifen kann. Ein Beispiel für eine nicht-funktionale Anforderung, die mit der funktionalen Anforderung für die Anmeldung eines Nutzers verbunden ist, findest du in Tabelle 4-3.

Tabelle 4-3. Nicht-funktionale Anforderung

ID	Anforderung
NFR_SEC_IA_001	Die Anmeldesequenz MUSS nicht länger als 30 Sekunden dauern, wenn 70 % der Nutzer/innen an einem Werktag zwischen 8:30 und 9:30 Uhr eine Anmeldesequenz starten.

Es kann sogar noch verwirrender werden, weil eine Sicherheitsanforderung je nach Kontext sowohl funktional als auch nicht-funktional sein kann. Der Hauptunterschied besteht darin, dass sich eine funktionale Anforderung auf die Hauptfunktionalität der Anwendung bezieht, während sich nicht-funktionale Anforderungen darauf beziehen, wie die Funktionalität bereitgestellt wird.

Zum Beispiel ist die Anforderung der Identifizierung und Authentifizierung eines Kunden eine funktionale Anforderung für die Benutzeroberfläche eines Online-Shops, während die Anforderung der Identifizierung und Authentifizierung aller internen System-zu-System-Verbindungen eine nicht-funktionale Anforderung ist. Bei der ersten Anforderung kann das System die primäre Systemfunktionalität ohne sie nicht erfüllen, aber bei der zweiten Anforderung kann das System alle funktionalen Anforderungen mit nicht authentifizierten System-zu-System-Verbindungen erfüllen.

Zwänge

Viele Anforderungen von werden zu Einschränkungen für die Lösungsarchitektur. Beginne mit der Berücksichtigung von externen Gesetzen, Vorschriften und Normen, da diese zu zwingenden Anforderungen für deine Lösung werden. Du wirst diese Einschränkungen dann im Rahmen des normalen Anforderungserfassungsprozesses berücksichtigen.

Es gibt jedoch noch viele andere Einschränkungen, die durch die aktuelle IT-Umgebung und ausgewählte Softwarekomponenten verursacht werden, die vielleicht weniger offensichtlich sind und deren Entdeckung viel Arbeit erfordert. Dazu gehören die folgenden vier wichtigen Bereiche:

Software Versionen

Software-Versionsabhängigkeiten kommen von den zugrunde liegenden Betriebssystemen und der Middleware. Du kannst in eine "tödliche Umarmung" geraten, wenn deine Anwendungssoftware nur eine alte, nicht unterstützte Bibliothek unterstützt und ein Upgrade unmöglich ist, weil das Unternehmen, das die Software geliefert hat, nicht mehr existiert. Das hat zur Folge, dass das Upgrade aller anderen Software, die von der nicht unterstützten Bibliothek abhängt, nicht möglich ist. Die Sicherheitslücken werden dann mit der Zeit immer größer und du musst eventuell zusätzliche Sicherheitskontrollen finden, um das Risiko zu mindern.

Wenn du ein System mit vordefinierten Softwarekomponenten entwickelst, musst du sicherstellen, dass die Abhängigkeiten aller Softwarekomponenten in Bezug auf ihre Versionen und abhängigen Softwarekomponenten übereinstimmen.

Sicherheitsprotokolle

Auch wenn es unterstützte Versionen von Softwarekomponenten gibt, kann es sein, dass die Protokolle nicht übereinstimmen. Zum Beispiel hat das TLS-Protokoll, das für die Verschlüsselung auf Sitzungsebene verwendet wird, Upgrades erhalten, um neu entdeckte Schwachstellen zu beheben. Obwohl deine Sicherheitsstandards TLS 1.3 vorschreiben, kann es sein, dass die Software nur TLS v1.2 und niedriger unterstützt. Noch schwieriger wird es, wenn die Schnittstellen-Software ältere Protokolle oder Chiffren abwertet und TLS v1.2 nicht unterstützt, so dass sie nicht integriert werden können.

Du musst eine Überprüfung der Integrationspunkte durchführen, um sicherzustellen, dass die Softwareprotokolle übereinstimmen. Möglicherweise musst du Risiken für ältere Protokolle mit Schwachstellen aufzeichnen und Abhilfemaßnahmen ergreifen, um die Ausnutzung potenzieller Schwachstellen zu verhindern. In diesem Fall kannst du TLS in ein Internet Protocol Security (IPsec) Virtual Private Network (VPN) verpacken oder die Nutzdaten innerhalb der TLS-Sitzung verschlüsseln.

API-Versionen

Mit der Verwendung von REST-APIs in vielen Cloud-Diensten ist eine Versionskontrolle für die Entwicklung neuer Funktionen und die Beseitigung von Schwachstellen erforderlich. Die Software, die mit den APIs integriert wird, muss aktualisiert werden, um neue APIs zu unterstützen, während ältere APIs abgeschrieben werden. Du hast keine andere Wahl, als diese Änderungen vorzunehmen, da der Versionswechsel nicht deiner Kontrolle unterliegt.

Wenn deine Sicherheitsdienste auf Cloud-APIs angewiesen sind, um Sicherheitskontrollen zu implementieren, musst du sicherstellen, dass du den laufenden Support für Upgrades auf neue APIs bedacht hast. Diese Überlegung zur laufenden Unterstützung gilt für alle Sicherheitsdienste und stellt ein erhebliches Risiko dar, das während der Entwicklung deiner Lösungsarchitektur zusätzliche Arbeit erfordert.

Agentenunverträglichkeit

Für die Sicherheit werden viele verschiedene Software-Agenten benötigt, um Bedrohungen zu erkennen, die Einhaltung von Vorschriften zu überprüfen oder die Konfiguration durchzuführen. Versionsinkompatibilitäten können dazu führen, dass du die Agenten nicht auf einer älteren Version des Betriebssystems installieren kannst. Dies ist ein wichtiger Aspekt bei der Produktauswahl.

Eine weitere Herausforderung ist der Einsatz von Sicherheits-Appliances, die keine Sicherheitsagenten unterstützen, wie z. B. enterprise detection and response (EDR) agents. Diese Sicherheits-Appliances werden dann zu einem Risiko, da die Überwachung auf Bedrohungen nicht stattfinden kann. Oft handelt es sich bei diesen Appliances nur um eine Version von Linux, die die Agenten unterstützen würde, aber die Anbieter wollen dies aus Supportgründen nicht zulassen. Möglicherweise musst du kompensierende Kontrollen durchführen.

Wie du aus dieser Diskussion ersehen kannst, gibt es viele Einschränkungen, die sich aus der aktuellen IT-Umgebung und den Softwarekomponenten ergeben, die als Teil des Architekturdenkprozesses ausgewählt wurden. Diese Untersuchungen können zu neuen Anforderungen oder Aktualisierungen der Projektrisiken, Probleme, Annahmen und Abhängigkeiten führen, die wir in Kapitel 9 behandeln werden.

Im nächsten Schritt müssen wir uns überlegen, wie wir die Qualität der Anforderungen, die wir dokumentieren, sicherstellen können.

Festlegen von Qualitätsanforderungen

Wir müssen sicherstellen, dass die Definition von Qualitätsanforderungen Teil unseres architektonischen Denkprozesses ist. Ein Ansatz ist die Verwendung des SMART-Frameworks. SMART bedeutet, dass die Anforderungen spezifisch, messbar, erreichbar, relevant und zeitgebunden sind:¹

Spezifische

Die Anforderungen müssen die Bedürfnisse des Unternehmens klar beschreiben. Sie müssen klar, konsistent, einfach und eindeutig sein und einen angemessenen Detaillierungsgrad haben. Ein guter Ausgangspunkt ist die Verwendung der fünf Ws: Frage wen, was, wann, wo und warum. Sie können dir helfen, das Problem klarer zu definieren, damit du deine Anforderungen präziser formulieren kannst.

Messbar

Die Konstruktion der Anforderungen muss so beschaffen sein, dass es möglich ist, ihre Umsetzung zu überprüfen. Nicht-funktionale Anforderungen sollten oft quantifizierbar sein und die Messung des Fortschritts bei ihrer Erfüllung ermöglichen. Frage dich: Kannst du einen Test für die Anforderung erstellen? Ein Teil der Überprüfung erfolgt durch die Rückverfolgbarkeit der Anforderungen, einschließlich der Tests, die wir später in diesem Kapitel besprechen werden.

Erreichbar

Die Anforderung sollte technisch durchführbar und im Rahmen der Architektur deiner Lösung möglich sein. Bitte Fachexperten für die jeweilige technische Lösung, die Anforderungen zu überprüfen. Überprüfe, ob die Anforderung schon einmal erfolgreich umgesetzt wurde. Wenn nicht, wie sicher bist du, dass sie realisierbar ist? Vielleicht kannst du ein Risiko oder eine Annahme in das Projekt-RAID-Protokoll eintragen, um alle Bedenken festzuhalten. Wir werden dieses Artefakt in Kapitel 10 besprechen.

Einschlägige²

Die Anforderungen müssen mit den allgemeinen Geschäftszielen übereinstimmen und zu einem wertvollen Ergebnis führen. Diese Anforderungen können sich auf die Hauptfunktionalität oder auf die Sicherheits- und Compliance-Anforderungen beziehen, die für den Geschäftsbetrieb unerlässlich sind. Achte darauf, dass du keine Sicherheitsanforderungen hinzufügst, die nicht den Bedürfnissen des Unternehmens entsprechen oder nicht mit der Risikotoleranz des Unternehmens vereinbar sind.

Zeitgebundene³

In der Anforderung sollte klar festgelegt werden, wann die Fähigkeit vorhanden sein muss, um die Ausrichtung des Projektteams sicherzustellen. Soll das System zur Erkennung von Bedrohungen bereits zu Beginn des Proof of Concept vorhanden sein oder kann es bis sechs Monate nach der Inbetriebnahme des Systems warten? Die Zeitvorgaben müssen möglicherweise in einem architektonischen Entscheidungsprotokoll begründet werden. Wir werden in Kapitel 9 darüber sprechen, wie man einen architektonischen Entscheidungsdatensatz dokumentiert.

Wir haben spezifische, messbare und relevante Kriterien als Muss-Kriterien festgelegt, da alle Anforderungen diese Kriterien erfüllen sollten. Erreichbare und zeitgebundene Kriterien hingegen sollten verwendet werden, da sie von der späteren Definition der allgemeinen Abhängigkeiten, Prioritäten und Risiken des Gesamtprojekts abhängen können. Wenn du die Anforderungen als Ganzes betrachtest, kannst du diese Kriterien besser einschätzen.

Schauen wir uns ein paar Beispiele an, angefangen mit einer schlecht spezifizierten Anforderung in Tabelle 4-4.

Tabelle 4-4. Unzureichend spezifizierte Anforderung

ID	Anforderung
REQ_1	Bei Ransomware sollte sofort eine Warnung an das zuständige Team gegeben werden.

Sie ist nicht spezifisch, da sie nicht angibt, wer den Alarm auslösen sollte. Wie schnell ist sofort? Wir wissen nicht, wer das "zuständige Team" ist. Was bedeutet "für Ransomware"? Es ist nicht messbar, weil es nicht spezifisch genug ist. Wir haben keine Ahnung, ob das Ziel erreichbar oder relevant ist, weil es nicht genau definiert ist. Der Zeitaufwand ist nicht berücksichtigt. Es fehlt die Erfüllung eines der Qualitätskriterien.

Wir haben auch gezeigt, wie man eine Anforderung nicht kennzeichnen sollte. Die Bezeichnung REQ_1 verrät uns nicht, aus welchem Bereich die Anforderung stammt, und die Verwendung von 1 statt 001 erschwert die Sortierung.

Dann haben wir eine gut spezifizierte Anforderung in Tabelle 4-5 erstellt.⁴

Tabelle 4-5. Gut spezifizierte Anforderung

ID	Anforderung
NFR_SEC_TD_001	Das System zur Erkennung von Bedrohungen MUSS eingerichtet sein, bevor das System Kundendaten enthält, um innerhalb von 15 Minuten eine Warnung an das Security Operations Center (SOC) zu senden, wenn Ereignismuster erkannt werden, die auf potenzielle Ransomware hinweisen könnten.

Die Anforderung sagt uns, welche Komponente den Alarm auslöst und wer ihn erhält. Sie ist spezifischer, da es um die Erkennung von Ereignismustern geht, die auf potenzielle Ransomware hinweisen könnten. Die Muster werden Teil der detaillierten Spezifikation sein. Sie ist zeitgebunden, indem sie festlegt, wann die Erkennung von Bedrohungen erfolgen muss. Sie ist messbar, denn innerhalb von 15 Minuten nach der Erkennung muss der Alarm ausgelöst werden. Die Anforderung ist relevant angesichts der Bedrohung, die ein echtes Risiko für das Unternehmen darstellt.

Wie lange es dauert, die Bedrohung zu erkennen, lässt sich nur schwer angeben, und die Festlegung zusätzlicher Anforderungen, die die Arten der Angriffserkennung spezifizieren, ist eine Verbesserung. Wir können nicht sagen, ob sie realisierbar ist, da wir den Projektkontext nicht kennen. Es ist eine große Verbesserung gegenüber der ersten Anforderung.

Du wirst feststellen, dass die Anforderung einen komplexen Satzbau hat. Nicht jede Anforderung wird alle diese Kriterien erfüllen, aber sie dienen als Qualitäts-Checkliste, um zu sehen, ob du es versäumt hast, verschiedene Aspekte einer Lösung zu dokumentieren. Die Anwendung der Kriterien kann von Anforderung zu Anforderung unterschiedlich sein. Zum Beispiel kann das Kriterium der zeitlichen Bindung in einer einzigen Anforderung enthalten sein, die dann auf mehrere Anforderungen angewendet wird, die die Funktionalität beschreiben.

Außerdem haben wir die Anforderungen in einem besseren Format beschriftet. NFR steht für Non-Functional Requirement (nicht funktionale Anforderung), SEC für die Gruppe der Sicherheitsanforderungen, TD für Threat Detection (Erkennung von Bedrohungen) und 001 ist eine sortierbare Nummer.

Jetzt, wo wir klare Anforderungen haben, wie können wir diese priorisieren?

Anforderungen nach Prioritäten ordnen

Wir enden oft mit einer langen Liste von Anforderungen an die Lösungsarchitektur. Während einige Anforderungen sofort umgesetzt werden müssen, kann bei anderen die Priorität für die Umsetzung innerhalb eines bestimmten Zeitraums liegen.

Für ein Minimum Viable Project (MVP) müssen wir einen Benutzernamen und ein Passwort zur Identifizierung und Authentifizierung bereitstellen und könnten eine Multi-Faktor-Authentifizierung anbieten, wenn genügend Zeit zur Verfügung steht. Ein anderes Beispiel ist, dass wir bei einer kleinen Anzahl von Nutzern des Dienstes entscheiden könnten, dass wir eine RTO von 48 Stunden anbieten müssen und eine RTO von 4 Stunden anbieten könnten, wenn wir genügend Zeit hatten, sie zu implementieren.

Eine häufig verwendete Technik zur Priorisierung von Anforderungen ist die MoSCoW-Methode,, bei der die Großbuchstaben für:

Musshaben

Das Projekt wird die Anforderungen umsetzen. Die Fertigstellung des Projekts kann nicht ohne die Lieferung der als "Muss" eingestuften Anforderungen erfolgen.

Sollte

Das Projekt wird versuchen, die Anforderung innerhalb der vorgegebenen Zeit umzusetzen, hat aber möglicherweise keine Zeit dafür.

Hätte

Das Projekt könnte die Anforderung umsetzen, wird sie aber nicht unbedingt umsetzen. Höchstwahrscheinlich wird die Umsetzung der Anforderung nicht stattfinden.

Würdeoder würdenicht haben⁵

Das kann bedeuten, dass das Projekt die Anforderung einbeziehen würde, wenn die Zeit dafür da wäre, aber sie ist nicht entscheidend. Eine andere Möglichkeit ist, dass ein Projekt eine Anforderung nicht umsetzen wird. Das kann daran liegen, dass die Anforderung zusätzliche Kosten oder eine höhere Komplexität mit sich bringen würde und deshalb ausdrücklich von einer Lösung ausgeschlossen werden muss, um sicherzustellen, dass sie nicht umgesetzt wird.

In Tabelle 4-6 findest du einige Beispiele für priorisierte Anforderungen, die auf zwei Sprints eines Projekts basieren.

Tabelle 4-6. Priorisierte Anforderungen

Referenz	Sprint 1	Sprint 2	Anforderung
REQ_SEC_1	MUSS	MUSS	Alle Nutzer/innen MÜSSEN identifiziert und authentifiziert werden, bevor sie Zugang zum System erhalten.
REQ_SEC_2	SOLLTE	MUSS	Alle Nutzer/innen MÜSSEN mit einer Multi-Faktor-Authentifizierung authentifiziert werden.
REQ_SEC_3	COULD	SOLLTE	Alle Nutzer/innen MÜSSEN eine rechtliche Warnung über die unbefugte Nutzung des Systems erhalten.

Die Tabelle zeigt drei Anforderungen in Bezug auf die Identifizierung und Authentifizierung eines Nutzers durch ein System mit stufenweiser Umsetzung. Es muss immer eine Identifizierung und Authentifizierung geben, als Nächstes kommt die Multi-Faktor-Authentifizierung und später ein rechtlicher Hinweis.

Da wir nun wissen, wie wir die Qualität von Anforderungen bewerten und Prioritäten setzen können, können wir mit der Spezifikation von Anforderungen beginnen, beginnend mit den funktionalen Anforderungen.

Funktionale Anforderungen spezifizieren

Es gibt viele verschiedene Möglichkeiten, funktionale Anforderungen zu formulieren. Das Schreiben funktionaler Anforderungen kann so einfach sein wie etwas, das das System bereitstellen wird, wie in Tabelle 4-7.

Tabelle 4-7. Beispiel für die Beschreibung eines Anwendungsfalls

ID	Anforderung
FR_SEC_IA_001	Das System identifiziert und authentifiziert einen Benutzer mit einem Benutzernamen und einem Passwort.

Dies beschreibt jedoch nicht die Abfolge der Aktivitäten oder die Akteure, die an den Aktivitäten beteiligt sind. In diesem Abschnitt stellen wir eine Auswahl verschiedener Techniken vor, zeigen das Artefakt und diskutieren ihre Verwendung im Zusammenhang mit der Spezifikation funktionaler Anforderungen.

Wir werden die folgenden Techniken besprechen:

• Anwendungsfälle

• Reisekarten

• Benutzergeschichten

• Schwimmbahnen-Diagramme

• Matrizen für die Aufgabentrennung

Use Cases, eine Technik, die in den 1980er Jahren von Ivar Jacobson entwickelt wurde, der später die Unified Modeling Language (UML) mitentwickelt hat, wird unser Ausgangspunkt sein.

Anwendungsfälle

Ein Anwendungsfall ist eine Beschreibung der Systeminteraktionen durch menschliche und Systemakteure. Wir werden Anwendungsfälle im Rahmen der Definition des Systemkontextdiagramms in Kapitel 5 identifizieren. Sie müssen durch ein UML-Use-Case-Diagramm und Use-Case-Beschreibungen näher beschrieben werden.

Wir können ein UML-Use-Case-Diagramm verwenden, um das Verhalten eines Systems zu visualisieren, wobei ein Kasten die System- oder Subsystemgrenze darstellt, Menschen die menschlichen und Systemakteure und die Use Cases innerhalb des Kastens. Wir haben eine Teilmenge der Akteure und Anwendungsfälle aus der Fallstudie genommen, um ein Anwendungsfalldiagramm in Abbildung 4-2 darzustellen.

Abbildung 4-2. UML-Use-Case-Diagramm der Fallstudie

Das Diagramm zeigt die Beteiligung der Akteure an jedem Anwendungsfall, aber wir brauchen noch mehr Details über den Anwendungsfall. Wir können sie entweder als informelle Beschreibung oder in einer vorgeschriebenen Vorlage dokumentieren, wie in Tabelle 4-8 gezeigt.

Tabelle 4-8. Beschreibung des Anwendungsfalls in der Fallstudie

Name des Anwendungsfalls:	Fahrerregistrierung
Beschreibung:	Registriere die Fahrerdetails und die Fahrzeuge, die sie besitzen
Darsteller/innen:	Treiber
Voraussetzungen:	Der Fahrer darf nicht bereits registriert sein
Fluss:	Registriere einen Benutzernamen und ein Passwort für das Portal Eine Bestätigungs-E-Mail wird an den Fahrer gesendet Der Fahrer klickt auf den Link, um die E-Mail zu bestätigen Der Fahrer meldet sich wieder an Der Fahrer registriert Name, Adresse und Mobiltelefon Der Fahrer meldet die Fahrzeuge an, die er besitzt Der Fahrer registriert eine Zahlungskarte, um die Gebühr abzurechnen Ausloggen aus dem Portal
Postkonditionen:	Keine
Ausnahmen	Wenn sich der Fahrer in Schritt 1 bereits registriert hat, meldet die Benutzeroberfläche "Registrierung nicht möglich" und sendet eine E-Mail an den Besitzer, in der er über die doppelte Registrierung informiert und zum Zurücksetzen des Passworts aufgefordert wird.
Anforderungen:	Der Benutzername wird überprüft, um festzustellen, ob er wie eine E-Mail-Adresse aussieht. Das Passwort wird überprüft, um sicherzugehen, dass es nicht trivial ist.

Jeder Anwendungsfall beschreibt eine Reihe von Aktivitäten mit Vor- und Nachbedingungen. Nicht-technische Anwendungsfälle können von Geschäftsanalysten oder Beratern für Architekten und Entwickler definiert und umgesetzt werden.

Eine Anwendungsfallbeschreibung für die Systeminteraktion

Wir haben eine textuelle Anwendungsfallbeschreibung verwendet, aber wir können auch Sequenz- oder Kollaborationsdiagramme verwenden, um die Interaktion zwischen den Systemakteuren und dem System (oder Subsystem) besser zu beschreiben. Auf diese Artefakte gehen wir in Kapitel 6 ein.

In jedem System gibt es viele sicherheitsrelevante Anwendungsfälle zu definieren, von der Anmeldung der Endbenutzer-Anwendung bis zur Meldung eines Sicherheitsvorfalls. Du musst die Identifizierung der sicherheitsrelevanten Akteure sicherstellen und ihre Anwendungsfälle dokumentieren.

Weitere UML-Details

Eine ausführlichere Beschreibung von Anwendungsfalldiagrammen findest du in Kapitel 18 des Unified Modeling Language User Guide (Addison-Wesley Professional) von Grady Booch, James Rumbaugh und IvarJacobson.

Wie wir bereits besprochen haben, sind Anwendungsfälle Interaktionen mit einem System. Es ist schwierig, eine Lösung als Teil der Anforderungsdefinition zu vermeiden. In Tabelle 4-7 hat die Anforderung bereits die Notwendigkeit eines Benutzernamens und eines Passworts definiert. Wie wäre es mit einem passwortlosen System zur Identifizierung und Authentifizierung? Es wäre besser gewesen, die Multi-Faktor-Authentifizierung als Qualität zu fordern und die Lösung dem Architekten zu überlassen.

In den letzten 20 Jahren wurden daher Techniken entwickelt, die sich auf den Endnutzer konzentrieren. Wir werden mit einer Technik fortfahren, die sich auf die Bedürfnisse des Nutzers konzentriert: die Definition einer Journey map.

Reise-Karten

Wir haben in Kapitel 2 über Design Thinking gesprochen. Der Schwerpunkt liegt auf einem menschenzentrierten Ansatz, um Personas (ein anderer Begriff für Akteure) mit ihren Bedürfnissen, Schmerzen und Zielen zu verstehen. Eine Methode, um Personas besser zu verstehen, ist die Erstellung einer "Journey Map", um ihre Handlungen, Gedanken und Gefühle zu beschreiben, wenn sie mit einer Dienstleistung oder einem Produkt in Berührung kommen. Das ist ein sehr persönliches Werkzeug, um sich in die Lage eines Nutzers oder Kunden zu versetzen und seine Gedanken und Gefühle zu verstehen.

Die Journey Map wird normalerweise in einem Workshop erstellt, bei dem die Phasen, Schritte, Gefühle und Schmerzpunkte mit Hilfe von Klebezetteln an einer Wand beschrieben werden. Wir haben in Abbildung 4-3 ein Beispiel für eine Journey Map für die Fallstudie gezeigt.

Abbildung 4-3. Fallstudie Journey Map

Eine Journey Map wird auch als User Journey oder Szenariokarte bezeichnet, wobei es leichte Unterschiede zwischen den verschiedenen Formaten gibt. Wir haben das To-be-Szenario-Map-Format aus der IBM Enterprise Design Thinking-Methode verwendet.

Diese Technik ist gut geeignet, um die gesamte Reise zu zeigen und sich in den Kopf des Fahrers hineinzuversetzen, um seine Gedanken und Gefühle zu verstehen. Eine Journey Map ist jedoch nicht detailliert genug, um in die Lösungsentwicklung einzusteigen, und es wird eine zusätzliche Technik benötigt, um das Problem zu zerlegen. Wir werden nun die Verwendung von User Stories für die nächste Entwicklungsphase besprechen.

Benutzergeschichten

Bei der agilen Entwicklung werden die funktionalen Anforderungen oft in Form einer User Story festgelegt. Dieses Konzept stammt aus der eXtreme Programming-Methode, mit der die Softwarequalität verbessert und besser auf sich ändernde Kundenanforderungen reagiert werden kann. Die Nutzer drücken ihre Anforderungen und Werte durch User Stories aus. Die Nutzer sind die menschlichen Akteure, die im Systemkontextdiagramm in Kapitel 5 und als Personas im Design Thinking beschrieben werden. Es bietet einen Mechanismus, um zwischen dem Entwicklungsteam und dem Kunden über die Spezifikation der Lösung zu kommunizieren.

Wir entwickeln User Stories und fassen sie in einem Katalog zusammen, den wir Product Backlog nennen. Für jeden Sprint oder jede Iteration verschieben wir die User Stories nach Priorität in das Sprint Backlog. Der bereits erwähnte MoSCoW-Ansatz zur Priorisierung ist eine Möglichkeit, um zu entscheiden, welche Stories in das Sprint Backlog kommen.

Eine User Story wird normalerweise in dreiteiliger Form geschrieben:

Als <role> möchte ich <a feature/function>, damit ich <business reason/benefit>.

Dies deckt drei Elemente der fünf Ws für die Spezifikation einer Anforderung ab: wer, was und warum. In der Regel fügst du Hintergrundinformationen hinzu, die den Kontext der Anforderung und der Tests, die ihre Erfüllung bestimmen, darstellen.

Nehmen wir ein Beispiel für eine User Story für einen Compliance-Bericht, wie in Tabelle 4-9 dargestellt.

Tabelle 4-9. Beispiel für eine Benutzergeschichte

Benutzergeschichte	Als Compliance-Spezialist möchte ich in der Lage sein, einen Compliance-Bericht zu erhalten, der Trendgrafiken für verschiedene Perspektiven enthält , damit ich die Stakeholder identifizieren kann, mit denen ich zusammenarbeiten muss, um Compliance-Lücken zu schließen.
Kontext	Das kommt vom Compliance-Team, das dies bisher manuell mit Tabellenkalkulationen gemacht hat und es nun automatisieren muss.
Abnahmetests	Teste es mit Trendberichten für einen Geschäftsbereich, eine Anwendung, eine Technologieplattform und ein Land. Teste es mit Trendberichten für wöchentlich, monatlich, vierteljährlich und jährlich.

Nicht alle Benutzer wollen einen Benutzernamen und ein Passwort eingeben, und manchmal ist es bei Sicherheitsanforderungen sinnvoller, I want in I'm required zu ändern und die so that-Klausel zu entfernen. Das wichtigste Prinzip, an das du dich erinnern solltest, ist, dass die User Story für eine bestimmte Benutzerrolle bestimmt sein muss. Beginne eine Benutzergeschichte nicht mit "Als Benutzer"; ein bestimmter Benutzer muss identifiziert werden.

Größere User Stories, die mehr als einen Sprint in Anspruch nehmen können, bezeichnen wir als ein Epos. Sie müssen oft in mehrere User Stories aufgeteilt werden und sind ein Zeichen dafür, dass weitere Arbeit nötig ist, um das Problem zu zerlegen. Daher definieren einige Tools ein Epos als eine Gruppe von User Stories und nicht als eine große User Story. Es lohnt sich, sich innerhalb des Teams, mit dem du zusammenarbeitest, darauf zu einigen, was ein Epos ist.

Ein Thema ist eine Sammlung von zusammenhängenden User Stories und Epics, die in einer Gruppe organisiert sind. Ein Thema mit dem Namen "Compliance Reporting" könnte zum Beispiel Stories und Epics für jeden einzelnen Bericht enthalten.

Bei der Entwicklung einer Anwendung vergessen die Entwickler leicht die Benutzer, die für die Sicherheit und die Einhaltung der Vorschriften verantwortlich sind. Deshalb ist die Definition dieser Akteure (oder Benutzer) im Systemkontextdiagramm, das wir in Kapitel 5 besprechen, wichtig, denn es erinnert daran, dass die Benutzer nicht nur die Benutzer der primären Geschäftsanwendung sind. Das gesamte Informationssystem muss auch die Bedürfnisse vieler anderer Nutzer erfüllen, z. B. des "Compliance Teams". In diesem Fall sollten wir bedenken, dass eine der Hauptfunktionen der Anwendung darin besteht, externe gesetzliche Anforderungen zu erfüllen.

Weitere User Stories Detail

Weitere Einzelheiten zur Anwendung von User Stories findest du in User Stories Applied: For Agile Software Development (Addison-Wesley Professional) von Mike Cohn.

An diesem Punkt haben wir eine Möglichkeit, die End-to-End User Journey und die funktionalen Anforderungen durch User Stories zu spezifizieren. Es fehlt aber noch eine Möglichkeit, die verschiedenen Nutzer zu beschreiben, wie sie interagieren und die Aufgabentrennung zu beschreiben. Deshalb greifen wir auf eine Technik zurück, die es schon viel länger gibt: das Swimlane-Diagramm .

Schwimmbahn-Diagramme

gibt es viele verschiedene Diagramme, die einen Prozessablauf oder eine Abfolge von Aktivitäten beschreiben, die von einem Akteur oder Benutzer ausgeführt werden. Es gibt Flussdiagramme und UML-Aktivitätsdiagramme, die die Schritte in einem Prozess beschreiben, aber keines von beiden zeigt klar die Rollen, ohne dass eine Tabelle hinzugefügt wird, die die Abfolge der Aktivitäten beschreibt.

Deshalb verwenden wir Swimlane-Diagramme, um die Schritte in einem Prozess zu beschreiben, wobei jede "Swimlane" eine Zeile oder Spalte ist, die die Aktivitäten eines Akteurs darstellt. Anhand des Diagramms kannst du zeigen, wer welche Schritte ausführt, wie die Übergabe zwischen den Akteuren erfolgt und welche Entscheidungen getroffen werden. Das Diagramm kann auch zeigen, wie die Aufgabentrennung aufrechterhalten wird. Abbildung 4-4 zeigt ein Beispiel für ein Swimlane-Diagramm.

Abbildung 4-4. Swimlane-Diagramm

Wir haben einen einfachen Satz von Diagrammteilen verwendet; du wirst komplexere Diagramme finden, aber du wirst diese Teile wahrscheinlich die meiste Zeit verwenden. Lasst uns die Teile besprechen:

Schauspieler

Diese sind die Akteure, Personas oder Nutzer, die an der Ausführung des Prozesses beteiligt sind. Es kann sowohl menschliche als auch Systemakteure als Teil eines Systems geben.

Swimlane

Eine Schwimmbahn ist eine Reihe oder Spalte mit den Aktivitäten, die ein Akteur durchführt. Sie sehen aus wie Schwimmbahnen in einem Schwimmbad, in dem die Schwimmer in ihrer eigenen Bahn bleiben, daher auch der Name des Diagramms.

Terminator

Ein Terminator ist der Anfang oder das Ende des beschriebenen Prozesses.

Prozessschritt

Ein Prozessschritt ist eine Aktivität, die von einem Akteur ausgeführt wird.

Entscheidung

Eine Entscheidung tritt auf, wenn jemand im Prozess eine Wahl trifft. Normalerweise handelt es sich um eine zweiseitige Entscheidung, z. B. ja/nein oder OK/nicht OK, aber du kannst das Diagramm auch mit mehr als zwei Optionen zeichnen. Wenn eine Entscheidung getroffen wird, muss ein Ereigniseintrag in ein Protokoll geschrieben werden.

Unterprozess

Ein einzelner Prozessschritt kann zu komplex für ein einzelnes Diagramm werden und ein separates Teilprozess- (oder Swimlane-) Diagramm wird den Schritt detaillierter beschreiben.

Schritt Nummern

Auf werden die Schritte nummeriert und es ist eine nützliche Methode, um auf die Schritte im Prozess zu verweisen. Es ist eine Konvention, dass Swimlane-Diagramme immer von links nach rechts oder von oben nach unten verlaufen sollten, da sie die Ausführung eines Prozesses im Laufe der Zeit darstellen.

Das Swimlane-Diagramm allein bietet oft keine ausreichende Beschreibung, deshalb benötigen wir eine Textbeschreibung in einer Tabelle. Tabelle 4-10 enthält ein kurzes Beispiel, in dem die ersten beiden Schritte aus Abbildung 4-4 ausgefüllt sind.

Tabelle 4-10. Beschreibung des Swimlane-Diagramms

Aktivität	Schauspieler	Titel	Beschreibung
1.	Privilegierten Zugang beantragen	Angestellte	Der Mitarbeiter öffnet zunächst die Webseite des IAM-Anfragetools und füllt einen Antrag auf privilegierten Zugang aus. Der Antrag enthält die erforderliche ID und eine geschäftliche Begründung für den Erhalt dieser Zugriffsstufe. Sie muss mit einem Vorfall, Problem oder Änderungsticket verknüpft sein.
2.	Entscheidung	Manager	Die Führungskraft prüft den Antrag des Mitarbeiters und stellt sicher, dass es eine ausreichende Begründung für den Zugang gibt und dass die beantragten Berechtigungen für die Aktivitäten angemessen sind.
n.	usw.	usw.	usw.

Beachte, dass die Tabelle die Nummer der Aktivität, den Akteur und den Titel enthält und zusätzlich eine Beschreibung. Wenn du ein Flussdiagramm oder ein UML-Aktivitätsdiagramm verwenden willst, kannst du in dieser Tabelle die Akteure aufzeichnen, anstatt Swimlanes zu verwenden.

In der nächsten Phase müssen wir sicherstellen, dass ein Akteur keine unangemessenen Rechte erhält, um einen Prozessschritt auszuführen. Dazu verwenden wir eine Matrix zur Trennung der Aufgaben.

Matrizen zur Aufgabentrennung

In Kapitel 3, haben wir die Aufgabentrennung als wichtiges Leitprinzip besprochen. Es gibt viele sicherheitsrelevante Prozesse, bei denen ein Benutzer keine Kombination von Tätigkeiten ausführen darf und die dem Grundsatz der Aufgabentrennung folgen müssen.

Zum Beispiel sollte ein Benutzer, der einen privilegierten Zugang beantragt, nicht in der Lage sein, den Zugang zu genehmigen oder sich selbst einen privilegierten Zugang zu erteilen. Wir verwenden eine Matrix zur Aufgabentrennung, um darzustellen, was sie tun können und was nicht. Abbildung 4-5 ist ein Beispiel für das Swimlane-Diagramm in Abbildung 4-4.

Abbildung 4-5. Matrix der Aufgabentrennung

Die Teile des Diagramms sind:

Prozessschritt

Dies sind alle Prozessschritte im Swimlane-Diagramm.

Rolle

Dies ist die Nummer der Rolle, die einen Prozessschritt ausführt, wie durch den Schlüssel angezeigt.

ID

Die ID ist die Nummer des Prozessschritts, der im Swimlane-Diagramm verwendet wird. Die ID steht sowohl vertikal als auch horizontal in der Matrix.

Risiko-Matrix

In der Mitte der Tabelle befindet sich eine 7 × 7-Matrix, die zeigt, welche Prozessschritte eine Rolle zusammen ausführen kann/kann. Wenn eine Kombination von Prozessschritten ein erhöhtes Risiko darstellt, markiert ein "X" eine Kombination von Aktivitäten, die eine Rolle nicht zusammen ausführen darf. Wenn ein "*" anzeigt, dass die Kombination ein geringes Risiko darstellt, sollte die Rolle die Kombination vermeiden. Es handelt sich nicht um einen Showstopper und die Rolle könnte die Kombination ausführen, wenn es keine andere Möglichkeit gäbe. Ein Häkchen kennzeichnet eine Kombination von Tätigkeiten, die von derselben Person ausgeführt werden kann.

Wie funktionieren die Artefakte der funktionalen Anforderungen mit der Fallstudie, die wir verwenden?

Fallstudie: Prozessdefinition

Wir haben in Abbildung 4-3 eine Journey Map für einen Fahrer erstellt, aber diese ist zu detailliert, um funktionale Anforderungen an das System zu stellen. Die erste sicherheitsrelevante Aktivität auf der Journey Map ist die Registrierung des Fahrerkontos.

Wir haben ein Swimlane-Diagramm verwendet, um den Prozess der Fahrerkontoanmeldung zu beschreiben (siehe Abbildung 4-6). Wir verwenden eine vertikale Form des Diagramms, damit wir alle Prozessschritte auf einer Hochformat-Seite darstellen können, ohne sie in weitere Swimlane-Diagramme aufzuteilen.

In diesem Beispiel gibt es einen einzelnen menschlichen Akteur und zwei Systemakteure. Wir haben zwei technische Komponenten unter den beiden Systemakteuren identifiziert und mit dem architektonischen Denkprozess begonnen. Wir haben nicht mehrere menschliche Akteure, also brauchen wir auch keine detaillierte Analyse der Aufgabentrennung.

Der Identitäts-Provider und der E-Mail-Provider könnten zwei verschiedene Cloud-Dienste sein. Es kann sein, dass wir die Anforderung haben, dass der Identitätsanbieter alle identitätsbezogenen Entscheidungen trifft und nicht der E-Mail-Anbieter. Es könnte sein, dass wir mehr Vertrauen in den Identitätsanbieter gewonnen haben und die Geschäftslogik für identitätsbezogene Entscheidungen nicht auf mehrere Dienste verteilen wollen. Ein architektonischer Entscheidungssatz sollte dokumentieren, dass nur der Identitätsanbieter diese Entscheidungen trifft. In diesem Fall können wir im Swimlane-Diagramm sehen, dass der E-Mail-Provider nur E-Mails versendet und geschäftslogische Entscheidungen durchführt.

Dies ist ein Beispiel für einen Geschäftsprozess, der Entscheidungen trifft, die sich auf die Sicherheit auswirken. Wir müssen nicht für jeden Prozess ein Swimlane-Diagramm erstellen. Wir empfehlen dir, jeden Prozess, der an einer Sicherheitsentscheidung beteiligt ist, mit einem Swimlane-Diagramm zu dokumentieren, um die Abfolge der Aktivitäten und Sicherheitsentscheidungen zu verdeutlichen. In Kapitel 11 zeigen wir dir weitere Details zur Prozesszerlegung und wie du die Aufzeichnung von Sicherheitsereignissen in einem Audit-Log dokumentierst.

Abbildung 4-6. Swimlane-Diagramm der Fahrerkontenregistrierung

QA-Checkliste für funktionale Anforderungen

• Nutze das Systemkontextdiagramm, das in Kapitel 5 besprochen wurde, um Anwendungsfälle zu identifizieren, die weiter spezifiziert werden müssen.

• Überprüfe die Ermittlung der Geschäftsanforderungen, wie z.B. die Journey Map und die User Stories, um Aktivitäten oder Stories zu identifizieren, die Sicherheitskontrollen beinhalten.

• Erarbeite sicherheitsspezifische Aktivitäten mithilfe von Swimlane-Diagrammen und Matrizen zur Aufgabentrennung.

• Stelle sicher, dass der Eigentümer der Geschäftsprozesse die Verantwortung für die Definition der Geschäftsprozesse behält (nicht der Sicherheitsarchitekt).

Kommen wir nun zur Spezifikation der nicht-funktionalen Anforderungen.

Nicht-funktionale Anforderungen spezifizieren

Wir haben bereits darüber gesprochen, wie nicht-funktionale Anforderungen beschreiben, wie das Informationssystem die Funktionalität liefern soll. Dann haben wir über einige Kategorien von nicht-funktionalen Anforderungen gesprochen, wie man ihre Qualität misst und wie man sie nach Prioritäten ordnet. Woher kommen diese Anforderungen und wie kann man sie am besten festhalten?

Quellen für nicht-funktionale Anforderungen

In Kapitel 3 haben wir über die externen und internen Quellen für Anforderungen gesprochen. Externe Gesetze, Vorschriften und bewährte Methoden der Branche oder von Fachorganisationen ermöglichen es einer Organisation, ihre internen Richtlinien, Standards und Leitlinien zu entwickeln. Aus diesen Dokumenten muss ein Architekt die relevanten nicht-funktionalen Anforderungen extrahieren. Diese nicht-funktionalen Anforderungen sind oft eine Einschränkung für dein Projekt, da sie die Wahl der Sicherheitslösung einschränken können. Abbildung 4-7 zeigt, wie der externe, interne und Projektkontext die Lösungsarchitektur mit den Sicherheitskontrollen beeinflusst.

Wir haben den externen und internen Kontext in Kapitel 3 besprochen. Sobald es ein Projekt gibt, haben wir jetzt einen Projektkontext, der uns zusätzliche Anforderungen liefert, mit denen wir arbeiten können, einschließlich der Projektziele und des Projektumfangs. Ressourcen, Fähigkeiten, Werkzeuge, Standards, Budget und Zeitrahmen haben alle einen Einfluss auf die Lösung, die wir in Betracht ziehen.

Abbildung 4-7. Externer, interner und Projektkontext

Der Projektkontext bringt das Projektmanagementdreieck mit dem Ausgleich von Kosten und Zeit mit Umfang, Qualität und Risiko in Betracht, wie in Abbildung 4-8 dargestellt. Das Diagramm sollte sich jedoch nicht nur auf Umfang und Qualität konzentrieren, sondern auch den Ausgleich von Kosten und Zeit mit Eigenschaften wie Sicherheit, Belastbarkeit und Verfügbarkeit berücksichtigen.

Abbildung 4-8. Dreieck des Projektmanagements

Dieses Gleichgewicht musst du berücksichtigen, wenn du die Anforderungen festlegst, denn es kann sein, dass die Erfüllung aller Anforderungen aus Kosten- oder Zeitgründen nicht machbar ist. Möglicherweise musst du nach alternativen Sicherheitskontrollen suchen, die kostengünstiger sind und sich schnellerumsetzen lassen.

Nicht alle Anforderungen sind explizit, daher leiten wir implizite nicht-funktionale Anforderungen aus anderen Quellen ab, z. B. aus den Anwendungen oder Arbeitslasten, die die Sicherheitsdienste sichern. Wenn eine Anwendung eine RTO von acht Stunden hat, müssen die Sicherheitsdienste im Falle eines weitreichenden Ausfalls vielleicht in viel kürzerer Zeit verfügbar sein. Oder wenn sich bei einer Anwendung 80 % der Nutzer/innen innerhalb kurzer Zeit anmelden müssen, muss der Sicherheitsdienst, der die Anwendung unterstützt, so skaliert werden, dass er die Anforderungen der Anwendung erfüllt. Daraus ergeben sich eine Reihe von nicht-funktionalen Anforderungen an die Sicherheit in Bezug auf Verfügbarkeit und Ausfallsicherheit.

Je nachdem, wie die Sicherheitsfunktionen bereitgestellt werden, hast du möglicherweise keine Kontrolle über die Funktionen und Architekturmerkmale der Sicherheitsdienste. Sie sind auch eine Einschränkung, mit der du arbeiten musst.

Nicht-funktionale Anforderungsabhängigkeiten

Du kannst die Kontrolle über die Umsetzung der Sicherheitsanforderungen durch das von dir geleitete Projekt haben oder du bist von Sicherheitsdiensten abhängig, die anderswo bereitgestellt werden. Bei Sicherheitsdiensten, die außerhalb deines Projekts erbracht werden, musst du prüfen, ob diese Workloads die Sicherheitsdienste nutzen können, um die nicht-funktionalen Anforderungen des Projekts zu erfüllen.

Wenn die Anwendung zum Beispiel eine bestimmte Technologie verwendet, unterstützt der Sicherheitsdienst diese auch? Wenn nicht, muss der Arbeitsaufwand geändert werden oder du musst die Lücke schließen? Ein guter Ausgangspunkt ist eine Liste der wichtigsten Softwarekomponenten, ihrer Softwareversionen und der Plattformen, auf denen sie laufen. Das Diagramm zur geteilten Verantwortung, das wir in Kapitel 7 besprechen, hilft dir bei der Analyse, da du es nutzen kannst, um die verschiedenen Ebenen der Lösung für jede Plattform zu betrachten.

Identifizieren von Softwareversionen

In der On-Premises-Architektur wurde die Überprüfung der Softwareversionen möglicherweise erst später im Prozess vorgenommen. Wir haben festgestellt, dass dies bei der hybriden Cloud früher der Fall ist, da die Softwareversionen größere Änderungen in der Architektur und im Betrieb erfordern.

Zum Beispiel könnte die Lösung eine Softwareversion oder -funktion erfordern, die der CSP nicht unterstützt, was dazu führt, dass ein Cloud-Service durch Software auf einem virtuellen Server ersetzt werden muss. Die Kosten werden dann wahrscheinlich steigen und die Durchführbarkeit des Projekts kann in Frage gestellt sein. Infolgedessen kann das Projekt beschließen, einen alternativen Dienst zu nutzen.

Auch wenn es sich bei der Lösung bereits um Software und nicht um einen Dienst handelt, kann es sein, dass du die Sicherheitssoftware von einem Anbieter zu einem anderen wechseln musst. Je früher du eine Versionskontrolle durchführst, desto unwahrscheinlicher ist es, dass du zu einem späteren Zeitpunkt von einer größeren Änderung der Softwarekomponenten überrascht wirst.

Du solltest alle wichtigen Softwarekomponenten durchgehen und prüfen, welche Sicherheitsdienste integriert werden müssen und ob sie kompatibel sind. Einige Fragen, die du dir stellen könntest, sind:

• Welche Betriebssysteme gibt es und werden Sicherheitstools wie Antivirus und Endpoint Detection and Response (EDR) unterstützt?

• Erfordert das Messaging-Tool eine Verschlüsselung der Nutzdaten innerhalb der verschlüsselten Netzwerksitzung, und gibt es einen Sicherheitsdienst, der dies unterstützt?

• Benötigt die Datenbank eine Aktivitätsüberwachung, um den Missbrauch der Daten durch einen Mitarbeiter oder einen externen Bedrohungsakteur zu erkennen? Gibt es eine unterstützte Lösung?

Für Cloud-Dienste kann es sogar noch mehr Einschränkungen geben, was die in den Workloads verwendeten Dienste, wie z. B. Datenbanken, und die Sicherheitsdienste, wie z. B. die Zugriffskontrolle, angeht, die der Cloud-Provider anbietet.

Dokumentieren nicht-funktionaler Anforderungen

Wir haben auf darüber gesprochen, woher die nicht-funktionalen Anforderungen kommen und wie man Anforderungen aus abhängigen Technologien ableitet. Weiter oben in diesem Kapitel haben wir auch über die Ableitung und Erstellung von Qualitätsanforderungen mit SMART gesprochen. Jetzt brauchen wir eine Liste von Anforderungen, mit der wir die Einhaltung der Richtlinien und aller anderen Anforderungen, die aus verschiedenen Quellen stammen, nachweisen können. Es wäre einfach, wenn wir nur ein einziges Dokument hätten, in dem alle Anforderungen aufgelistet sind, aber so funktioniert das normalerweise nicht.

Wir finden, dass es am besten ist, eine Tabelle mit allen Anforderungen zu erstellen und die Qualität der Ausgangsanforderungen zunächst zu ignorieren. Dann kategorisierst du sie anhand der nicht-funktionalen Kategorien, und für die Sicherheitsanforderungen verwendest du die Sicherheitsdomänen, wie in "Technik" beschrieben : Sicherheitsarchitektur für Unternehmen" beschrieben. Dann fügst du die ursprüngliche Anforderung mit einem Verweis auf das Quelldokument ein, gefolgt von der vorgeschlagenen Lösung und dem Service Owner der Anforderung, wie in Tabelle 4-11 dargestellt.

Tabelle 4-11. Beispiel für die Zuordnung von Steuerimplementierungen

NFR	Domain	Kategorie	Prio	Anforderung	Ext. Ref.	Lösung	Eigentümer der Dienstleistung
SEC	IAM	PAM_003	MUSS	Das schnelle Abrufen von privilegierten Passwörtern ist notwendig.	EXT_REF_nn	Das Hosting des Privileged Access Management (PAM)-Dienstes erfolgt auf Infrastrukturkomponenten, die von der Kerninfrastruktur unabhängig sind und während eines DDoS-Angriffs über einen Break-Glass-Remote-VPN-Dienst verfügbar sind.	Manager für Sicherheitseinsätze

Wenn du aber ein Programm mit vielen Projekten oder eine Organisation mit vielen Projekten betreibst, bedeutet das Erstellen einer Anforderungsliste aus allen verschiedenen Quellen viel doppelten Aufwand. In diesem Fall lohnt es sich, die Qualität des Anforderungskatalogs zu verbessern. Schauen wir uns einige Techniken zur Verbesserung der Anforderungen an.

Verbesserung der Anforderungsspezifikation

Es kann sein, dass du Anforderungen aus verschiedenen Quellen ziehst, was zu einer Vielzahl von unterschiedlichen Formaten und Qualitäten führt. Wenn du dir die Kontrollanforderungen aus NIST SP 800-53r5 Security and Privacy Controls for Information Systems and Organizations (Sicherheits- und Datenschutzkontrollen für Informationssysteme und Organisationen) ansiehst, sind die Anforderungen richtlinien-, technologie- und branchenneutral, was viele Menschen nicht verstehen würden, und es gibt Parameter, die ausgefüllt werden müssen.

Die zusammengetragenen Anforderungen können oft in ein konsistentes Set umgeschrieben werden, das von allen verstanden wird, ohne dass es zu widersprüchlichen Interpretationen kommt. So kannst du die hochwertigen Anforderungen projekt- und kontextübergreifend verwenden.

Wir haben eine Reihe nützlicher Ansätze für die Ableitung eines konsistenten und qualitativ hochwertigen Katalogs von Sicherheitsanforderungen entwickelt, die du immer wieder verwenden kannst. Nutze jede Technik iterativ, um die notwendigen Anforderungen abzuleiten, und verwende sie in der Reihenfolge, die für dich am besten geeignet ist.

Stelle dabei sicher, dass du eine Zuordnung zwischen der neuen Anforderung und der ursprünglichen Anforderung erstellst. Wenn du Änderungen vornimmst, überprüfe die Zuordnung zu den ursprünglichen Anforderungen, um sicherzustellen, dass sie noch gültig ist. Wenn du Anforderungen umformulierst, aufteilst oder zusammenlegst, könnten sie nicht mehr mit den ursprünglichen Anforderungen übereinstimmen.

Wir beginnen damit, die Anforderungen nach Bereichen und Kategorien zu sortieren, um verwandte Anforderungen zu gruppieren. Dann bearbeitest du die Anforderungen auf folgende Weise:

Nachbestellen

Obwohl du die Anforderungen in Gruppen gemeinsamer Arten von Anforderungen sortiert hast, machen sie oft nur in einer bestimmten Reihenfolge Sinn. Du hast z.B. zwei Anforderungen: Die erste verlangt eine Authentifizierung mit einer Multifaktor-Authentifizierung, die zweite eine Identifizierung und Authentifizierung, bevor ein Benutzer auf ein System zugreift. Diese beiden Anforderungen müssen getauscht werden, damit die eine auf der anderen aufbauen kann.

Split

Möglicherweise findest du heraus, dass du eine Anforderung in mehrere Anforderungen aufteilen kannst . Eine Anforderung mit "und" im Satz ist ein Hinweis auf eine Anforderung, die du eventuell aufteilen musst. Nimm zum Beispiel die folgende Anforderung AC-2 a. aus NIST SP 800-53r5. Der erste Teil ist eine Dokumentationsanforderung, und der zweite Teil könnte eine Anforderung für eine technische Kontrolle sein, die durch Werkzeuge erzwungen wird. Die Aufteilung der Anforderung in zwei Anforderungen ermöglicht es, sie verschiedenen Teams zuzuweisen, um bei Bedarf eine klare Verantwortlichkeit zu gewährleisten:

AC-2 a. Definiere und dokumentiere die Arten von Konten, die für die Nutzung innerhalb des Systems erlaubt und ausdrücklich verboten sind.

Zusammenführen

Wenn du neu sortiert und zerlegt hast, findest du vielleicht zwei Anforderungen, die im Grunde dieselbe Anforderung sind. An diesem Punkt kannst du sie zu einer gemeinsamen Anforderung zusammenführen. Achte vor dem Zusammenführen auf feine Unterschiede in der Formulierung der beiden Anforderungen und vergleiche sie mit den Ausgangsanforderungen.

Neu kategorisieren

Manchmal kann eine Anforderung der falschen Kategorie zugeordnet werden und muss neu zugeordnet werden. In NIST SP 800-53r5 heißt es zum Beispiel, dass viele Kontrollfamilien die Entwicklung einer Richtlinie erfordern, die in der Regel unabhängig von dem Team geschrieben wird, das für die Umsetzung der Anforderung verantwortlich ist.⁶ Wahrscheinlich gibt es bei dir ein Team, das für die Entwicklung aller Richtlinien verantwortlich ist. Diese Anforderungen müssen einem anderen Bereich und einer anderen Kategorie zugeordnet werden, um eine bessere Abstimmung mit dem verantwortlichen Eigentümer zu erreichen.

unterkategorisieren

Du kannst am Ende eine lange Liste von Anforderungen haben, die du neu sortiert, aufgeteilt und zusammengeführt hast. Du wirst feststellen, dass sich die Anforderungen zu gemeinsamen Themen zusammenfügen. Wenn du die Anforderungen in weitere Unterkategorien einteilst, lassen sie sich leichter verwalten.

Abmessungen

Die Anforderungen sollten so neutral wie möglich sein, damit du sie, wenn sich der Kontext und die Technologie ändern, auf den entsprechenden Bereich anwenden kannst, ohne die Anforderungen zu ändern. Dennoch ist ein gewisser Kontext erforderlich. Nimm zum Beispiel die Anforderung SI-3 a. aus NIST SP 800-53r5. Sie besagt, dass der Mechanismus zum Schutz des Codes beim Betreten und Verlassen des Systems zu implementieren ist. Man könnte meinen, dass damit nur die Implementierung einer Kontrolle auf einem Server gemeint ist, aber die Implementierung dieser Kontrolle erfolgt an vielen Kontrollgrenzen:

SI-3 a. Implementiere [Auswahl (eine oder mehrere): signaturbasiert; nicht-signaturbasiert] Schutzmechanismen gegen bösartigen Code an den Ein- und Austrittspunkten des Systems, um bösartigen Code zu erkennen und zu beseitigen;

In den Erläuterungen zur Kontrolle heißt es: "Zu den Ein- und Ausgangspunkten des Systems gehören Firewalls, Remote Access Server, Workstations, E-Mail-Server, Webserver, Proxy-Server, Notebooks und mobile Geräte." Diese Anforderung erfordert, dass diese verschiedenen Dimensionen ausdrücklich mit der Anforderung dokumentiert werden. Andernfalls kann es zu Missverständnissen über den erwarteten Umfang kommen.

Da dies für alle Anforderungen im Zusammenhang mit bösartigem Code gilt, empfehlen wir dir, die Abmessungen der Anforderung in einer von der Anforderung unabhängigen Liste aufzubewahren, um auf mehrere Anforderungen verweisen zu können. Wenn sich die Dimensionen ändern, musst du sie nur einmal aktualisieren.

Parametriere

Anforderung SI-3 a. Die, die wir im vorherigen Beispiel verwendet haben, hat Parameter, die für die Art der Erkennungsfunktion für bösartigen Code ausgefüllt werden müssen. Wie bei den Dimensionen empfehlen wir dir, diese Liste außerhalb der Anforderung zu führen, damit du die gleichen Parameter bei Bedarf auf mehrere Anforderungen anwenden kannst.

Nicht ausrichten

Die Sicherheitsbranche kreiert viele neue Begriffe für neue Funktionen und leider können diese Begriffe in den Anforderungen landen. Der Begriff " intelligenter Schutz"⁷, der von mehreren ISVs verwendet wird, sagt uns zum Beispiel nicht, was die Anforderung ist. Handelt es sich um einen KI-basierten Markenschutz oder eine Technologie zum Schutz vor Malware?

Eine Anforderung sollte ein Unternehmen nicht an ein einziges Produkt binden. Du musst diese erkennen und sie durch eine Anforderung ersetzen, die nicht auf Markenangebote ausgerichtet ist. Möglicherweise musst du deine eigenen Begriffe definieren und ein Glossar erstellen, um die Begriffe im Kontext deines Unternehmens zu beschreiben.

Lass uns ein Beispiel durchgehen, um dir eine Vorstellung von den Verbesserungen zu geben, die durch die Verbesserung der Spezifikation eines Anforderungskatalogs für die projektübergreifende Nutzung erzielt werden.

Fallstudie: Spezifikation eines Anforderungskatalogs

Auf haben wir über die Spezifikation der funktionalen Anforderungen mithilfe eines Prozesses und die Verbesserung der Qualität der Anforderungen gesprochen. In einem Projekt, in dem die Anforderungen nicht wiederverwendet werden, ist es unwahrscheinlich, dass ein erheblicher Aufwand zur Verbesserung der Anforderungen gerechtfertigt ist.

Wenn dieselben Anforderungen in mehreren Projekten wiederverwendet werden müssen, wird durch die Verbesserung ihrer Qualität weniger Zeit für Diskussionen über die Bedeutung minderwertiger Anforderungen aufgewendet. Wenn die Anforderungen über verschiedene Sicherheitsdokumente verstreut sind, ist es außerdem schwierig, ohne eine einzige Liste, die man abarbeiten kann, ihre Einhaltung nachzuweisen. In diesen Fällen ist ein einziger Anforderungskatalog sehr wertvoll.

Technische Entwurfsbehörde oder Architekturausschuss

Wir sprechen über die Erstellung von Dokumenten, die in einem Unternehmen für viele Projekte verwendet werden. Dazu brauchen wir eine Technical Design Authority (TDA), in der technische Führungskräfte aus dem gesamten Unternehmen mit unterschiedlichen Fähigkeiten und Erfahrungen zusammenkommen, um bewährte Methoden zu bewerten, zu beraten und sich darauf zu einigen. Ein Anforderungskatalog ist eines dieser Artefakte, auf dessen Verwendung in der gesamten Organisation sie sich einigen werden. Der TOGAF-Standard von The Open Group ist ein guter Ausgangspunkt für das Verständnis der Architektur-Governance und der Rollen und Funktionen eines Architekturausschusses oder TDA.

Identifizierung von Sicherheitsanforderungen

Die Fallstudie fordert uns auf, die 10 bis 20 wichtigsten Anforderungen für die Umsetzung als Teil des MVP zu dokumentieren. Es wird vorgeschlagen, dass wir das NIST Cybersecurity Framework (CSF) als Ausgangspunkt für die Anforderungen verwenden. Beginnen wir zum Beispiel damit, die Anforderungen für das Schwachstellenmanagement aus dem Rahmenwerk zu erstellen, wie in Tabelle 4-12 gezeigt.

Tabelle 4-12. NIST CSF - Schwachstellenmanagement

Funktion	Kategorie	Unterkategorie	Informationen Referenzen
SCHÜTZEN (PR)	Prozesse und Verfahren zum Schutz von Informationen (PR.IP): Sicherheitsrichtlinien (die den Zweck, den Umfang, die Rollen, die Zuständigkeiten, das Engagement des Managements und die Koordinierung zwischen den Organisationseinheiten betreffen), Prozesse und Verfahren werden gepflegt und genutzt, um den Schutz von Informationssystemen und Vermögenswerten zu verwalten.	PR.IP-12: Ein Plan zum Management von Schwachstellen wird entwickelt und umgesetzt	CIS CSC 4, 18, 20 COBIT 5 BAI03.10, DSS05.01, DSS05.02 ISO/IEC 27001:2013 A.12.6.1, A.14.2.3, A.16.1.3, A.18.2.2, A.18.2.3 NIST SP 800-53 Rev. 4 RA-3, RA-5, SI-2
ENTDECKEN (DE)	Kontinuierliche Sicherheitsüberwachung (DE.CM): Das Informationssystem und die Anlagen werden überwacht, um Cybersecurity-Ereignisse zu erkennen und die Wirksamkeit der Schutzmaßnahmen zu überprüfen.	DE.CM-8: Schwachstellen-Scans werden durchgeführt	CIS CSC 4, 20 COBIT 5 BAI03.10, DSS05.01 ISA 62443-2-1:2009 4.2.3.1, 4.2.3.7 ISO/IEC 27001:2013 A.12.6.1 NIST SP 800-53 Rev. 4 RA-5

Zwei Unterkategorien innerhalb der NIST CSF, die jeweils unterschiedliche "Funktionen" erfüllen, führen zu den Anforderungen. Unternehmen integrieren diese Anforderungen oft in einen Schwachstellenmanagement-Service. Beachte, dass es keine Eins-zu-Eins-Übereinstimmung zwischen den Sicherheitsdienstleistungen und den Funktionen des NIST CSF gibt, was zeigt, dass du die Funktionen des CSF nicht zur Beschreibung von Sicherheitsdienstleistungen verwenden kannst.

Die Unterkategorien definieren die "Bausteine" der Sicherheit im NIST CSF, sind aber als Anforderungen unzureichend und lassen viele Fragen unbeantwortet und offen für Interpretationen. Sie eignen sich gut für eine übergeordnete Checkliste, aber nicht für die Spezifikation von Sicherheitsanforderungen, die für den Nachweis der Einhaltung erforderlich sind. Sie sagen zum Beispiel nichts über die Dimensionen aus, die wir zuvor besprochen haben. Sie haben keine Parameter, die die Häufigkeit der Schwachstellenüberprüfung oder die für die Beseitigung einer Schwachstelle erforderliche Zeit festlegen.

Ausarbeitung von Sicherheitsanforderungen

Jede der Unterkategorien hat Verweise auf NIST SP 800-53r5, Security and Privacy Controls for Information Systems and Organizations. Es handelt sich dabei um einen Kontrollkatalog, der einen umfassenderen Satz von Kontrollanforderungen enthält, mit denen du arbeiten kannst.

In NIST SP 800-53r5 lautet die erste Anforderung für die Überwachung und Überprüfung von Schwachstellen RA-5 (a), wie in Tabelle 4-13 dargestellt.

Tabelle 4-13. NIST SP 800-53r5 Überwachung und Scannen von Schwachstellen

ID	Anforderung
RA-5 (a)	Überwache und scanne das System und die gehosteten Anwendungen auf Schwachstellen [Zuordnung: von der Organisation festgelegte Häufigkeit und/oder zufällig in Übereinstimmung mit dem von der Organisation festgelegten Prozess] und wenn neue Schwachstellen, die das System betreffen könnten, identifiziert und gemeldet werden;

Der RA-5 (a) ist zwar umfassender, enthält aber viele Kontrollanforderungen, Abmessungen und Parameter im selben Satz. Hier ist die Liste dessen, was wir gefunden haben:

• Ein Schwachstellen-Scan-Tool zur Identifizierung von Schwachstellen-DE.CM-8 im NIST CSF

• Ein Prozess zum Management von Schwachstellen - PR.IP-12 im NIST CSF

• Ein Parameter für die Häufigkeit des Scannens gemäß der Richtlinie

• Eine Dimension zum Scannen von "System und gehosteten Anwendungen"

• Eine neue Anforderung zur Benachrichtigung des Schwachstellenmanagementdienstes, wenn neue Erkenntnisse Schwachstellen oder Bedrohungen für Schwachstellen im System aufgedeckt haben.⁸

Wir können RA-5 (a) nicht als integrierte, mehrdimensionale Anforderung belassen, um die Einhaltung effektiv nachzuweisen, und müssen ihn in einzelne Komponenten umschreiben.

Sicherheitsanforderungen neu schreiben

Wenn mehrere Anforderungen, Parameter und Dimensionen in eine Kontrollanforderung integriert werden, ist es schwierig, die Verantwortlichkeit zuzuweisen und die Einhaltung zu messen. Die RA-5 (a) Kontrollanforderung lässt sich am besten in einzelne Anforderungen, Dimensionen und Parameter zerlegen, wie in Tabelle 4-14 dargestellt.

Tabelle 4-14. Umgeschriebene Anforderungen an das Schwachstellenmanagement

Thema	ID	Beschreibung	Mapping kontrollieren
Kontrolle Anforderungen	VM-01	Definiere und implementiere Prozesse und Verfahren für das Bedrohungs- und Schwachstellenmanagement.	NIST SP 800-53 RA-5 (a) NIST CSF PR.IP-12
	VM-02	Schwachstellenprüfungen MÜSSEN mit einer Häufigkeit von {VM-P-01,02,03,04} für die Systemkomponententypen {VM-D-01} durchgeführt werden.	NIST SP 800-53 RA-5 (a) NIST CSF DE.CM-8
	TIM-01	Die Benachrichtigung des Vulnerability Management-Dienstes über eine potenzielle Schwachstelle in einer Systemkomponente MUSS innerhalb von {TIM-P-01} erfolgen.	NIST SP 800-53 RA-5 (a)
Steuerung Abmessungen	VM-D-01	Netzwerkkomponenten, Server (physisch und virtuell), Container, Cloud-Plattform, Container-Plattform, Anwendung	NIST SP 800-53 RA-5 (a)
Kontrolle Parameter	VM-P-01	nicht weniger als wöchentlich	NIST SP 800-53 RA-5 (a)
	VM-P-02	nach einer wesentlichen Änderung der Systemkomponente	NIST SP800-53 RA-5 (a)
	VM-P-03	innerhalb von 24 Stunden nach der Meldung einer potenziellen Schwachstelle einer Systemkomponente	NIST SP 800-53 RA-5 (a)
	VM-P-04	bei Penetrationstests	NIST SP800-53 CA-8
	TIM-P-01	innerhalb von 24 Stunden	NIST SP 800-53 RA-5 (a)
Schlüssel	VM = Vulnerability Management TIM = Überwachung von Bedrohungsdaten {} = Parameter/Dimension Substitution

Wir begannen mit der Erstellung der Anforderung VM-01 für Prozesse und Verfahren, die eine grundlegende Anforderung für alle Dienste ist und in der RA-5 (a) Zuweisung gefordert wird. Dann verlangt RA-5 (a) eine Kontrollanforderung, VM-02, für das Scannen von Schwachstellen und dann eine abgeleitete Anforderung, TIM-01, für den Überwachungsdienst für Bedrohungsdaten, um sie über potenzielle Schwachstellen zu informieren. Die Kontrollanforderung TIM-01, die in keiner der Anforderungen für das Schwachstellenmanagement oder die Bedrohungsanalyse ausdrücklich erwähnt wird, ist entscheidend für die erfolgreiche Erfüllung der Kontrollanforderung VM-01.

Die Dimensionen oder der Umfang des Dienstes fehlen. RA-5 (a) spricht von einem "System und gehosteten Anwendungen", aber das ist unvollständig und hängt von den in der Umgebung verwendeten Technologiekomponenten ab. Wenn wir RA-5 (a) lesen, könnten wir denken, dass wir nur einen Schwachstellen-Scan von Servern und Anwendungen durchführen müssen, aber das schließt das Netzwerk, die Cloud-Plattform, Container und Schwachstellen der Container-Plattform nicht ein. Durch die Hinzufügung der Dimension VM-D-01 wurde der Umfang der Schwachstellenprüfung verbessert.

Abweichung zwischen Kontrollfamilie und Domäne

Du hast vielleicht bemerkt, dass die Kontrollfamilien und -bereiche im NIST CSF und SP 800-53 nicht vollständig mit den daraus resultierenden Sicherheitsanforderungen, Dimensionen und Parametern übereinstimmen. Wir haben eine neue Anforderung für Threat Intelligence Monitoring abgeleitet und eine neue Anforderung für Vulnerability Management im Zusammenhang mit Penetrationstests entdeckt. Das Ergebnis ist, dass du die Verantwortlichkeit für Sicherheitsprozesse und die Erbringung von Dienstleistungen nicht einfach dadurch zuweisen kannst, dass du diesen Rahmenwerken die Verantwortung für Kontrollfamilien oder Bereiche zuweist.

Es fehlen die Parameter für den Dienst. Es wird nicht definiert, wie oft die Scans durchgeführt werden müssen oder wie schnell die Besitzer der Schwachstellen benachrichtigt werden müssen. Wie lange werden die Schwachstelleneinträge gespeichert? Viele dieser Parameter könnten aus einer Richtlinie stammen, aber wenn sie dort nicht festgelegt sind, ist nicht klar, wann wir die Anforderungen erfüllt haben. Das Hinzufügen der Parameter VM-P-01, VM-P-02, VM-P-03 und TIM-P-01 hat das Verständnis der Anforderungen verbessert.

Wir haben einen Parameter VM-P-04 hinzugefügt, weil wir festgestellt haben, dass die Anforderung CA-8 die Fähigkeit erfordert, Schwachstellen-Scans für Penetrationstests durchzuführen. Diese Anforderung muss dokumentiert werden, weil sie die Anzahl der unterstützten menschlichen Akteure verändern und eine Erhöhung der Kapazität des Sicherheitsdienstes erfordern kann.

QA-Checkliste für nicht-funktionale Anforderungen

• Berücksichtige alle Quellen: externer Kontext, interner Kontext und Projektkontext.

• Identifiziere abhängige Anwendungs- und Servicekomponenten und bestimme damit die Anforderungen an die Sicherheitsintegration, einschließlich

  • Abhängigkeiten von Softwareversionen

  • Workload-spezifische Sicherheitsanforderungen

  • Kapazitätsanforderungen

• Bewerten Sie die Qualität jeder Anforderung mithilfe von SMART

• Beurteile die Priorität jeder Anforderung anhand des MoSCoW

• Stelle sicher, dass die Anforderungen erfüllt sind:

  • Ein Etikett mit einer eindeutigen Kennung

  • Ein Etikett zur Identifizierung der Quelle

  • Dimensionen, die den Anwendungsbereich definieren

  • Parameter, die die variablen Aspekte definieren

• Versuche bei der Anforderungsspezifikation ein Gleichgewicht zwischen Kosten, Umfang/Qualität/Risiko und Zeit zu finden.

Bis jetzt haben wir darüber gesprochen, wie man einen Anforderungskatalog für einen Workload oder eine Anwendung erstellt. Aber wie können wir diesen Katalog nutzen, um sicherzustellen, dass die Implementierung und der Betrieb der Sicherheit mit den Anforderungen übereinstimmen? Darüber sprechen wir im folgenden Abschnitt.

Rückverfolgbarkeit von Anforderungen

Sobald wir die Anforderungen dokumentiert und die Lösung identifiziert haben, müssen wir sicherstellen, dass die Lösung sowohl auf logischer als auch auf vorgeschriebener Ebene dokumentiert wird, dass die Tests abgeschlossen sind und dass die Betriebsdokumentation verfügbar ist. Zu diesem Zweck erstellen wir eine Zuordnung zwischen den Anforderungen und der spezifischen Dokumentation, wie in Tabelle 4-15 dargestellt.

Tabelle 4-15. Matrix für die Rückverfolgbarkeit von Anforderungen

ID	Anforderung	HLDa	LLDb	Testplan	Dokumentation
SEC_IAM_PAM_003	Die Reaktionszeit des Systems in allen Phasen des Abrufs einer privilegierten Zugangsberechtigung MUSS weniger als 5 Sekunden betragen, um eine Seite zu laden, selbst wenn die Infrastruktur des Kernsystems extrem belastet ist.	4.2 Privileged Access Management (PAM)	11.3 Privileged Access Management (PAM)	6.5 Einheitstest 7.8 Integrationstest 9.7 Ausfallsicherheitstest	Betriebshandbuch-5.6 Notfall-Glasbruch VPN-Prozess
a High-Level-Design b Low-Level-Design

Die Tabelle enthält eine Spalte für jede Phase der Dokumentation der Lösungsarchitektur, einschließlich Tests und Betrieb. Deine Tabelle kann weitere Spalten für dein Projekt enthalten, aber dies sind die Mindestanforderungen, die wir erwarten.

Dann können wir uns auf die dokumentierte Lösungsarchitektur und die Umsetzung und den Betrieb der Fähigkeiten zur Aufrechterhaltung der Sicherheit verlassen. Wir werden in den Kapiteln 6 und 8 mehr über die Entwicklung der Design- und Betriebsartefakte in der Designdokumentation, in Kapitel 10 über die erforderlichen Tests und in Kapitel 11 über die Betriebsdokumentation sprechen.

Indizierungsanforderung Referenzen

Wir haben jeder Anforderung einen eindeutigen Identitätscode gegeben, der als Referenz dient. Um zu überprüfen, ob alle Anforderungen in einem Entwurfsdokument enthalten sind, ist es sinnvoll, die Kennung in einen Satz einzubauen, z. B. [SEC_IAM_PAM_003], und ihn dann als Eintrag für einen Index zu markieren. So kannst du herausfinden, wo in der Entwurfsspezifikation eine Anforderung dokumentiert ist und sicherstellen, dass alle Anforderungen abgedeckt sind, indem du den Index auf Vollständigkeit überprüfst.

Lass uns mit einer Zusammenfassung dieses Kapitels abschließen.

Zusammenfassung

Einige Autoren haben die Ansicht vertreten, dass die Dokumentation von Anforderungen in einer agilen Arbeitsumgebung nicht mehr notwendig ist. Ich hoffe, wir haben gezeigt, wie wichtig es ist, sowohl die funktionalen als auch die nicht-funktionalen Prozesse zu dokumentieren. Du kannst den Umfang der Dokumentation an die Größe der Organisation und des Projekts anpassen. Wir haben aufgezeigt, wie du das für die größten Organisationen tun kannst und wie du die Arbeit für kleinere Projekte reduzieren kannst.

Sicherheitsanforderungen sind nicht nur nicht-funktionale Anforderungen, sondern werden zu funktionalen Anforderungen, wenn sie die Hauptfunktion des Systems darstellen.

Funktionale Anforderungen folgen oft einem iterativen Prozess, der mit einer Journey Map beginnen kann, um User Stories zu identifizieren, die Kontrollentscheidungen enthalten können. User Stories sind die nächste Stufe der Dekomposition in einer agilen Umgebung, aber für manche Prozesse reichen sie nicht aus, und hier helfen die Swimlane-Diagramme und die Matrix der Aufgabentrennung.

Nicht-funktionale Anforderungen brauchen eine klare Definition, und wir sprachen über die verschiedenen Ansätze zur Verbesserung der Qualität und zur Priorisierung. Wir haben die Herausforderungen bei der Integration von Kontrollrahmen und Projektanforderungen anhand einer Reihe von Verbesserungen bei der Definition der Anforderungen für die Fallstudie aufgezeigt.

Wir sind am Ende der Diskussion über die Dokumentation von Anforderungen und Einschränkungen angelangt, aber noch nicht am Ende der Verwendung der Anforderungen zur Definition der Sicherheit für eine Lösungsarchitektur. Das sollte dich auf die folgenden Kapitel vorbereiten, in denen wir damit beginnen, die Grenzen des Systems, die Akteure, die mit dem System interagieren, und die Daten, die geschützt werden müssen, zu definieren.

Übungen

1. Eine funktionale Anforderung ______. Wähle alles aus, was zutrifft.

   1. Beschreibt die Hauptfunktionalität der Lösung

   2. Legt fest, wie das System geliefert werden soll

   3. Definiert, was das System leisten soll

   4. Definiert keine Sicherheitsanforderungen

2. Welche Begriffe werden für Anforderungen verwendet, die beschreiben, wie das Informationssystem die gewünschten Funktionen bereitstellen soll? Wähle alles aus, was zutrifft.

   1. Nicht-funktionale Anforderungen

   2. Architektonische Merkmale

   3. Nicht-funktionale Merkmale

   4. Eigenschaften der Produktqualität

3. Welche der folgenden Aussagen zu den Anforderungen an Sicherheitsdienste trifft zu?

   1. Bei der Disaster Recovery sollten die Anwendungen vor den Sicherheitsdiensten wiederhergestellt werden.

   2. Der Wechsel von Client-Server- zu Container-Workloads erfordert keine Änderung der Sicherheitsdienste.

   3. Bei der Umstellung auf die Cloud muss die Art und Weise, wie die Sicherheitsmaßnahmen durchgeführt werden, nicht angepasst werden.

   4. Der Verlust der Verfügbarkeit von Sicherheitsdiensten kann sich fast unmittelbar auf die Verfügbarkeit der Arbeitslast auswirken.

4. Was bedeutet "die Schlüssel im Auto einschließen"? Wähle alles aus, was zutrifft.

   1. Deine Schlüssel können versehentlich in deinem Auto eingeschlossen werden, wenn sie nicht durch die Schlüsselnähe im Auto erkannt werden.

   2. Das Abrufen von Schlüsseln ist möglicherweise erst möglich, wenn die Speicherung die Entschlüsselung bereits abgeschlossen hat.

   3. Verschlüsselungsschlüssel werden versehentlich in einem physischen Safe eingeschlossen.

   4. Der Neustart der Firewall kann nicht erfolgen, da er die Kommunikation mit dem Hardware-Sicherheitsmodul (HSM) ermöglicht, das zur Entschlüsselung der Boot-Diskette der Firewall erforderlich ist.

5. Welche Eigenschaften sollten bei den Sicherheitsanforderungen beachtet werden?

   1. Wer, Was, Wann, Wo und Warum

   2. Müsste, sollte, könnte und wird nicht

   3. Spezifisch, messbar, erreichbar, relevant und zeitgebunden

   4. Nachvollziehbar, prüfbar und zeitnah

6. Welches ist die beste Methode, um die funktionalen Anforderungen der Endnutzer zu ermitteln? Wähle alle zutreffenden Antworten aus.

   1. Anwendungsfälle

   2. Eine Reisekarte

   3. Schwimmbahnen-Diagramme

   4. Benutzergeschichten

7. Welches ist die beste Technik zur Definition funktionaler Anforderungen für die formale Definition der Abfolge von sicherheitsrelevanten Aktivitäten, die zwischen verschiedenen Endnutzern stattfinden?

   1. Anwendungsfälle

   2. Anfahrtsplan

   3. Schwimmbahnen-Diagramme

   4. Benutzergeschichten

8. Welche Faktoren muss das Projektmanagement-Dreieck berücksichtigen, wenn es um die Balance zwischen Umfang, Kosten und Zeit geht? Wähle alles aus, was zutrifft.

   1. Fertigkeiten

   2. Qualität

   3. Lebensfähigkeit

   4. Risiko

9. Was sind die Hauptgründe dafür, dass du schon früh im Anforderungsprozess für eine hybride Cloud eine Software-Versionsprüfung durchführst? Wähle alles aus, was zutrifft.

   1. Versionsinkompatibilität kann eine größere Änderung der Architektur erfordern.

   2. Es kann sein, dass ein Cloud-Dienst die erforderliche Software-Version nicht unterstützt.

   3. Die SIEM-Lösung (Security Information and Event Management) wurde möglicherweise nicht für die Verarbeitung dieser speziellen Softwareversion getestet.

   4. Das Sicherheitsprodukt unterstützt keine Version des verwendeten Betriebssystems.

10. Welche Schritte werden bei der Verbesserung von Anforderungsspezifikationen durchgeführt, um den Umfang der Anforderungen zu berücksichtigen?

    1. Split

    2. Abmessungen

    3. Zusammenführen

    4. Parametriere

¹ Es gibt viele verschiedene Definitionen dafür, was SMART bedeutet. Wir haben uns für diese Definition entschieden, weil wir glauben, dass sie die besten Voraussetzungen für Sicherheit und Einhaltung von Vorschriften bietet.

² Manchmal wird das R in SMART als angemessen definiert. Mit diesem Kriterium soll sichergestellt werden, dass die Anforderung über die entsprechenden Ressourcen verfügt, um die Lösung zu liefern. Wir verwenden das nicht, da vernünftige Zeitrahmen in das zeitgebundene Kriterium einbezogen werden und dann die Gesamtanforderung als Teil der Priorisierung der Anforderungen auf Angemessenheit geprüft wird.

³ Manchmal ist das T in SMART rückverfolgbar. Rückverfolgbarkeit von Anforderungen durch die Anforderungsspezifikation, die Lösungsarchitektur, die Umsetzung und das Testen hat mehr mit der Sicherstellung der Qualität der Umsetzung der Anforderungen zu tun als mit der Qualität der geschriebenen Anforderungen selbst. Wir werden später in diesem Kapitel über die Rückverfolgbarkeit von Anforderungen sprechen.

⁴ Wir sind sicher, dass du die Anforderungen verbessern könntest, wenn du mehr Kontext und Zeit hättest.

⁵ Die Autoren bevorzugen die Verwendung von won't, da Anforderungen, die aufgrund einer niedrigeren Priorität nicht umgesetzt werden, wahrscheinlich als Could have eingestuft werden. Manchmal musst du vielleicht angeben, dass eine Anforderung nicht umgesetzt wird, weil du jemanden kennst, der die Anforderung außerhalb des unmittelbaren Projekts haben möchte, und du willst klarstellen, dass die Anforderung nicht umgesetzt werden darf.

⁶ Dies ist ein Beispiel dafür, warum die Rechenschaftspflicht auf der Grundlage einer Kontrollfamilie innerhalb eines Kontrollrahmens nicht effektiv ist. Es gibt noch viele andere Beispiele, aber das hier ist das offensichtlichste Beispiel.

⁷ Das hat nichts mit der Anwendung des SMART-Ansatzes zur Verbesserung der Qualität der Anforderungen zu tun.

⁸ Das kann eine neue Software-Schwachstelle sein, die in der CVE-Datenbank gemeldet wird, oder eine Bedrohungsmeldung über die Ausnutzung einer Schwachstelle. Idealerweise solltest du eine Anforderung für das automatische Patchen eines Softwareprodukts hinzufügen.