Eine Sicherheitsarchitektur im RFP belastbar erklären

Geltungsbereich

Die Antwort braucht eine eindeutige technische Bezugsgröße

Prüfen Sie die Frage zusammen mit Leistungsbeschreibung, Wertungsmethode, Sicherheitsanlage, Datenanforderungen, Betriebsmodell, Schnittstellen, Vertrag und Bieterinformationen. Der Auftraggeber kann eine Darstellung des Ist-Zustands, einen Zielentwurf, eine Umsetzungsmethode oder einen Prüfbericht verlangen. Kennzeichnen Sie diese Gegenstände getrennt. Eine ausführliche Beschreibung verfehlt die Aufgabe, wenn sie den falschen Zustand oder eine andere Produktvariante beschreibt.

Der Antwortkopf nennt Verfahren, Los, Bieter, Dienst, Edition, Mandantenmodell, vorgeschlagene Betriebsorte, produktive und unterstützende Umgebungen, externe Verbindungen, Datenkategorien, betrachteten Zeitraum, Dokumentversionen und Nachweisstichtag. Hinzu kommen die Stellen, die technische Richtigkeit, Risiko, Offenlegung und vertragliche Zusage freigeben dürfen. Diese Angaben bilden den Schlüssel für jede weitere Sicht und jeden Beleg.

Im fiktiven Beispiel beschafft der Verkehrsverbund Falkenried einen Dienst für Fahrgastinformation und Störungsbearbeitung. Leitstellenmitarbeiter pflegen Meldungen, Verkehrsunternehmen liefern Betriebsdaten, Fahrgäste lesen Informationen über Web und App, Servicetechniker verwalten Schnittstellen. Das Angebot umfasst eine bestimmte gehostete Ausprägung. Namen und Sachverhalt sind erfunden und belegen keine Aussage über ein echtes Verkehrsunternehmen.

Schutzkontext

Schutzbedarf verbindet Fachschaden und technische Entscheidung

Der BSI-Standard 200-2 beginnt die Sicherheitskonzeption mit Strukturanalyse, Schutzbedarfsfeststellung und Modellierung. Für eine Angebotsantwort bedeutet das: Ordnen Sie Geschäftsprozesse, Anwendungen, Informationen, Systeme, Kommunikationsverbindungen und Infrastruktur ein, bevor Sie Sicherheitsprodukte aufzählen. Begründen Sie Vertraulichkeit, Integrität und Verfügbarkeit über mögliche fachliche Schäden. Die Einstufung eines Datenbestands darf nicht automatisch auf jedes technische Objekt übertragen werden; Abhängigkeiten und Kumulation müssen erkennbar bleiben.

Falkenried schützt die korrekte und zeitnahe Fahrgastmeldung, die nicht öffentliche Betriebsinformation, die Berechtigung zur Veröffentlichung sowie die Nachvollziehbarkeit administrativer Änderungen. Relevante Pfade sind unter anderem ein übernommenes Leitstellenkonto, manipulierte Daten eines Verkehrsunternehmens, ein kompromittierter öffentlicher Dienst, missbrauchte Supportrechte und eine verfälschte Bereitstellung. Ordnen Sie pro Pfad Ausgangspunkt, Voraussetzungen, Zielobjekt, Grenzübertritte, fachliche Wirkung und verbleibendes Risiko zu.

Bedrohungskataloge helfen bei der Gegenprobe, ersetzen aber die Systemanalyse nicht. MITRE ATT&CK beschreibt beobachtete Vorgehensweisen von Angreifern. OWASP strukturiert Threat Modeling über Gegenstand, mögliche Fehler, Gegenmaßnahmen und Prüfung. Wählen Sie nur die Einträge, die zum Einsatz und zur betrachteten Abstraktion passen. Eine lange Liste ohne Verbindung zur Architektur ist keine Risikoanalyse.

Sichtenmodell

Jede Sicht beantwortet eine andere Sicherheitsfrage

Eine Kontextsicht grenzt angebotenen Dienst, Nutzergruppen, Fremdsysteme und Anbieter ab. Die Domänensicht zeigt Bereiche unterschiedlichen Vertrauens und die kontrollierten Übergänge. Die Datenflusssicht verfolgt fachliche Informationen einschließlich Richtung, Klassifikation und Ablage. Identitäts- und Administrationssichten erklären menschliche sowie technische Identitäten, Privilegien und getrennte Verwaltungswege. Eine Bereitstellungssicht zeigt Isolation, gemeinsame Abhängigkeiten und Begrenzungsbereiche auf angemessener Abstraktion.

Vergeben Sie dauerhafte Kennungen für Komponenten und wichtige Flüsse. Jede Sicht enthält Zweck, Umfang, Eigentümer, Version, Stichtag, Abstraktionsniveau und Legende. Begriffe bleiben über alle Sichten gleich oder erhalten eine eindeutige Zuordnung. Ein “Service Gateway” in der Datenflusssicht darf nicht unbemerkt drei verschiedene Komponenten der Bereitstellungssicht zusammenfassen. Die Verdichtung ist zulässig, wenn ihr Zweck und ihre Grenze genannt werden.

Ein freigegebenes Diagramm belegt zunächst einen dokumentierten Entwurf. Ob dieser Entwurf umgesetzt ist, zeigen Konfiguration, Bereitstellungsdaten oder technische Prüfung. Ob er im Betrieb funktioniert, zeigen laufende Aufzeichnungen und Übungen. Schreiben Sie den Belegstatus direkt an die Sicht. Ein Zielbild ohne diesen Hinweis kann beim Leser zu einer falschen Ist-Aussage werden.

• Kontextsichten bestimmen Systemgrenze und externe Abhängigkeiten.
• Domänensichten erklären Vertrauenswechsel und Durchsetzung.
• Datenflusssichten zeigen Zweck, Richtung und Schutzklasse.
• Identitätssichten trennen Nutzer, Dienste, Geräte und Privilegien.
• Bereitstellungssichten machen Isolation und gemeinsame Ursachen sichtbar.

Vertrauensgrenzen

Ein internes Netz erteilt noch keine Berechtigung

Beschreiben Sie für jeden wesentlichen Zugriff Subjekt, Ressource, Identitätsquelle, relevante Signale, Regel, Durchsetzungspunkt und erlaubte Aktion. Das gilt für Beschäftigte, externe Redakteure, Softwaredienste und Geräte. Zero-Trust-Leitlinien von NIST und NCSC behandeln Netzstandort oder Besitz nicht als ausreichenden Vertrauensbeweis. Eine Verbindung aus dem Verbundnetz kann deshalb weiterhin eine benannte Identität, ein freigegebenes Gerät und eine rollenbezogene Entscheidung benötigen.

Trennen Sie fachliche Datenflüsse von Administration, Steuerung und Überwachung. Die Fahrplandaten eines Verkehrsunternehmens dürfen nicht denselben Berechtigungsweg wie eine Konfigurationsänderung nehmen. Ein technischer Kontrollfluss verteilt Regeln oder Schlüssel. Ein Überwachungsfluss transportiert Sicherheitsereignisse. Die Vermischung in einem einzigen Pfeil verdeckt Privilegien, mögliche Abflusswege und die Zuständigkeit bei Störung.

Die Verwaltung erhält eine eigene Sicht. Darin stehen Vergabe und Entzug privilegierter Identitäten, starke Authentisierung, Aufgabenfreigabe, Reichweite, Sitzungs- oder Aktivitätsnachweis, Notfallzugang und Trennung vom üblichen Arbeitsplatz. Hersteller- oder Providerzugriff wird als eigener externer Pfad geführt. Die Aussage “nur Administratoren” genügt nicht, weil sie weder Herkunft noch Kontrolle dieses Privilegs erklärt.

Begrenzung

Mehrere Schutzsymbole sind noch keine unabhängigen Barrieren

Erfassen Sie jede zentrale Sicherheitsfunktion mit Zielobjekt, Platzierung, Entscheidungseingängen, Betreiber, Abhängigkeiten und Verhalten bei Ausfall. Eingangsfilterung, anwendungsbezogene Autorisierung und eingeschränkte Datenbankrechte können verschiedene Abschnitte eines Angriffspfads schützen. Nutzen alle drei dieselbe kompromittierte Dienstidentität oder dieselbe unkontrollierte Konfiguration, ist ihre Unabhängigkeit begrenzt. Die Antwort muss diese gemeinsame Ursache sichtbar lassen.

Beschreiben Sie die Begrenzung einer Kompromittierung. Eine übernommene öffentliche Darstellungskomponente darf beispielsweise Meldungen lesen, die ausdrücklich zur Veröffentlichung bestimmt sind. Sie darf keine Quelle als vertrauenswürdig registrieren, keine Redaktionsfreigabe erteilen und keinen Massenexport nicht öffentlicher Betriebsdaten starten. Diese fachliche Begrenzung ist verständlicher als eine Liste von Subnetzen. Der technische Nachweis bleibt trotzdem nötig.

Überwachung gehört in den Entwurf. Ordnen Sie privilegierte Aktionen, geänderte Regeln, abgewiesene Daten, ungewöhnliche Exporte, fehlerhafte Identitätsentscheidungen und Ausfall von Sicherheitsfunktionen konkreten Ereignisquellen zu. Nennen Sie Korrelation, Empfänger und Reaktion. Vermeiden Sie sensible Inhalte im allgemeinen Protokoll. Auch der Ausfall der Telemetrie braucht einen sichtbaren Zustand.

Bei Verfügbarkeit unterscheiden Sie zufälligen Ausfall und gezielten Angriff. Mehrere gleiche Instanzen können einen Hardwarefehler überstehen und dennoch gemeinsam durch eine Schwachstelle, eine manipulierte Bereitstellung oder den Verlust derselben Verwaltungsebene ausfallen. Verweisen Sie für Wiederanlaufziele auf den dafür freigegebenen Teil des Angebots. Die Architekturantwort benennt nur die Abhängigkeit und den geprüften Störfall.

Prüfkette

Ein Nachweis darf nur seine eigene Schlussfolgerung tragen

Ordnen Sie jedem Beleg Kennung, Objekt, Umgebung, Edition, Datum oder Zeitraum, Methode, Ergebnis, Einschränkung, Eigentümer und zugelassene Zielgruppe zu. Ein Architekturentscheid belegt eine freigegebene Gestaltung. Konfigurations- und Bereitstellungsdaten belegen Umsetzung. Betriebsaufzeichnungen zeigen wiederholte Ausführung. Ein Test belegt das Verhalten unter bestimmten Eingaben und Randbedingungen. Ein externer Prüfbericht trägt nur die Schlussfolgerungen seines festgelegten Umfangs.

Die Aussage zur getrennten Administration verweist in Falkenried auf die Identitätssicht, den genehmigten Architekturentscheid, eine Prüfung der produktiven Zugangswege und die letzte vollständige Berechtigungsrezertifizierung. Ein älterer Penetrationstest kann zusätzliche Sicherheitshinweise liefern. Er schließt die Aussage aber nicht, wenn danach der Verwaltungsweg wesentlich geändert wurde. Dann braucht die neue Ausprägung einen passenden Beleg oder eine sichtbare Lücke.

Rahmenwerke erleichtern Begriffe und Vollständigkeitsprüfung. Sie beweisen keine konkrete Implementierung. NIST SP 800-53 trennt Sicherheitsfunktion und Vertrauensmaß, SP 800-53A liefert anpassbare Prüfverfahren, das OWASP ASVS formuliert versionierte Anforderungen für Anwendungssicherheit. Nennen Sie den Prüfmaßstab und anschließend das wirkliche Prüfergebnis. Für eine atomare Zuordnung einzelner Käuferanforderungen zu Kontrollen führen Sie eine eigene Kontrollmatrix.

Offenlegung

Schwärzung braucht einen kontrollierten Ersatz für den Prüfer

Das eigentliche Angebot kann Systemgrenze, Sicherheitsdomänen, Kontrollzwecke, Zuständigkeiten und Nachweisverweise enthalten. Eine geschützte Bieteranlage kann redigierte logische Sichten und Auszüge führen. In einem zugelassenen Due-Diligence-Raum können benannte Prüfer tiefere Konfigurationen oder Berichte einsehen. Besonders sensible Feststellungen, Regeln und privilegierte Routen bleiben einem ausdrücklich genehmigten Prüferkreis vorbehalten. Ob diese Abstufung zulässig ist, bestimmen Vergabeunterlagen und anwendbares Recht.

Entfernen Sie konkrete Adressen, unnötige Produktstände, Schlüsselmaterial, Zugangsdaten, genaue Verwaltungsrouten, aktive Abwehrschwellen, ausnutzbare Schwachstellen und Kundendaten. Behalten Sie Zweck, Flussrichtung, Vertrauensentscheidung, Datenklasse, Betreiber, Beziehung zwischen Schutzschichten, Nachweisreferenz und Einschränkung. Ein stabiler Schwärzungscode zeigt, dass zwei Darstellungen dasselbe verborgene Element meinen.

Das Offenlegungsverzeichnis nennt Ursprungsartefakt, entfernte Ebene, Grund, Risiko- und Freigabeverantwortung, Zielgruppe, Ersatzcode und erlaubten Prüfweg. Reicht die redigierte Fassung für einen zwingenden Nachweis nicht aus, stellen Sie rechtzeitig eine neutrale Bieterfrage oder nutzen ein ausdrücklich akzeptiertes alternatives Beweismittel. Geschützte Dateien werden nicht eigenmächtig über einen anderen Kanal versandt.

• Kennzeichnen Sie jede Seite mit Ausprägung, Version, Datum und Offenlegungsklasse.
• Prüfen Sie Bildmetadaten und ausgeblendete Ebenen vor dem Export.
• Verwenden Sie dieselben Komponenten- und Flusskennungen in allen Stufen.
• Lassen Sie Sicherheitsbehauptung und Offenlegungsentscheidung getrennt genehmigen.
• Nennen Sie den kontrollierten Prüfweg nur, wenn das Verfahren ihn erlaubt.

Freigabe

Ein versionsgebundenes Dossier verhindert wandernde Behauptungen

Das Sicherheitsarchitektur-Dossier enthält Vergabefrage, Angebotsbaseline, Schutzkontext, Sichtregister, Angriffspfad-Entscheidungsnachweis, Verantwortungsmatrix, Nachweisindex, Restrisiken, Annahmen, offene Punkte, Schwärzungsverzeichnis, Querprüfungen, Freigaben und Änderungshistorie. Eine eindeutige Version und ein Nachweisstichtag binden diese Bestandteile zusammen. Aus der Antwort führt jede wesentliche Aussage zu einer Kennung im Dossier.

Gleichen Sie wiederholte Aussagen mit Security-Fragebogen, Datenschutzantwort, Integrationskonzept, Betriebsmodell, Notfallvorsorge, Service Levels und Vertragsanlagen ab. Ein Widerspruch bleibt offen, bis die zuständige Stelle eine Quelle oder Zusage berichtigt. Vereinheitlichen Sie die Texte nicht durch das Entfernen einer berechtigten Einschränkung.

Änderungen an Edition, Mandantenmodell, Betriebsort, Identitätsquelle, Schnittstelle, Provider, privilegiertem Weg, Sicherheitsfunktion, Bedrohungsannahme oder Prüfergebnis öffnen die betroffenen Aussagen erneut. Aktualisieren Sie Sicht und Nachweis und kennzeichnen Sie die alte Fassung als abgelöst. So bleibt die freigegebene Kurzantwort mit dem überprüfbaren technischen Stand verbunden.