Security-Lösungen
Erst die Anforderung, dann das Werkzeug
Sicherheitstechnik löst kein Problem, das vorher nicht beschrieben wurde. Wir leiten Lösungen aus Risiko und Architektur ab, wählen herstellerneutral aus, integrieren in das, was bereits läuft – und bauen nur dort etwas Eigenes, wo es sich rechnet.
Worum es geht
Die meisten Häuser haben mehr Sicherheitstechnik, als sie nutzen. Produkte wurden eingeführt, weil ein Vorfall Druck erzeugte, ein Auditor etwas verlangte oder ein Angebot günstig war – und stehen heute nebeneinander, ohne voneinander zu wissen.
Diese Seite ist deshalb kein Katalog. Sie beschreibt, wie aus einer Anforderung eine Lösung wird: über Risiko, Architektur und Kontrolle zur Technologie – und von dort in Integration und Betrieb.
Herstellernamen stehen hier bewusst nicht. Welche Produkte in Frage kommen, hängt an Umgebung, vorhandenen Verträgen und Betriebsfähigkeit – und diese Auswahl gehört in ein Gespräch, nicht auf eine Werbeseite.
Von der Anforderung zum Betrieb
Die Produktfrage steht an fünfter Stelle, nicht an erster. Wer bei der Technologie beginnt, kauft eine Lösung für ein Problem, das nie beschrieben wurde – und erfährt erst im Betrieb, ob sie passt.
Ausgangslage
Kommt Ihnen das bekannt vor?
Keiner dieser Punkte entsteht durch Nachlässigkeit. Sie entstehen, weil Umgebungen wachsen und Entscheidungen einzeln getroffen werden.
Technik ohne Anforderung
Ein Produkt wurde beschafft, bevor beschrieben war, welches Risiko es senken soll. Der Nutzen lässt sich deshalb auch nicht beurteilen.
Nebeneinander statt miteinander
Jedes System hat eine eigene Konsole, eigene Meldungen, eigene Berechtigungen. Zusammenhänge zwischen ihnen sieht niemand.
Meldungen ohne Betrieb
Die Erkennung ist eingerichtet und meldet zuverlässig. Wer die Meldungen liest und was dann geschieht, ist nicht geregelt.
Lizenz statt Wirkung
Funktionen sind bezahlt, aber nicht eingerichtet. Im Audit zählt die Konfiguration, nicht der Vertrag.
Lücken zwischen den Systemen
Jedes Werkzeug deckt seinen Bereich ab. Was zwischen den Bereichen liegt – Schnittstellen, Dienstkonten, Übergaben – deckt keines ab.
Im Einzelnen
Die Themen, um die es geht
Je Bereich: worin das Problem besteht, was wir übernehmen und was danach anders ist.
Von der Anforderung zur Kontrolle
- Ausgangslage
- Die Frage lautet meist „Welches Produkt brauchen wir?" – und damit ist sie schon falsch gestellt.
- Was wir tun
- Wir arbeiten die Kette von hinten auf: Welches Risiko soll gesenkt werden, welche Kontrolle senkt es, an welcher Stelle der Architektur greift sie, und welche Technologie setzt sie um? Die Produktfrage steht am Ende dieser Kette, nicht am Anfang.
- Ergebnis
- Eine Beschaffungsentscheidung, die sich begründen lässt – auch gegenüber der Geschäftsführung.
Auswahl ohne Herstellerbindung
- Ausgangslage
- Auswahlentscheidungen folgen der Vertriebsseite: Wer zuerst da war oder am besten präsentiert hat, gewinnt.
- Was wir tun
- Wir bewerten Alternativen entlang Ihrer Anforderungen: Deckt das Produkt die Kontrolle wirklich ab, passt es zur vorhandenen Umgebung, lässt es sich mit Ihrem Team betreiben, und was kostet der Betrieb über die Laufzeit?
- Ergebnis
- Eine Auswahl mit nachvollziehbaren Kriterien statt einer Vorliebe.
Integration in das, was schon läuft
- Ausgangslage
- Neue Systeme werden danebengestellt. Meldungen laufen an einer weiteren Stelle auf, Berechtigungen werden erneut gepflegt, Zusammenhänge gehen verloren.
- Was wir tun
- Wir verbinden Sicherheitssysteme über die vorgesehenen Wege – Schnittstellen, Ereignisströme, Protokolldaten, Identitätsanbindung –, damit Meldungen zusammenlaufen und Anmeldung sowie Berechtigungen aus einer Quelle kommen.
- Ergebnis
- Weniger Konsolen, weniger doppelte Pflege, und ein Bild statt fünf Ausschnitten.
Erkennung und Betrieb
- Ausgangslage
- Ein Erkennungssystem ohne festgelegten Ablauf erzeugt Meldungen, die niemand bearbeitet – und gewöhnt die Beteiligten daran, sie zu ignorieren.
- Was wir tun
- Wir legen fest, welche Ereignisse überhaupt gemeldet werden, wer sie annimmt, was in welcher Frist geschieht und wie eskaliert wird. Dazu kommt die regelmäßige Nachschärfung, damit die Zahl der Fehlmeldungen sinkt statt zu wachsen.
- Ergebnis
- Meldungen, auf die tatsächlich reagiert wird – weil ihre Zahl beherrschbar bleibt.
Wiederanlauf als letzte Kontrolle
- Ausgangslage
- Sicherungen laufen, aber der Ernstfall wurde nie geprobt. Ob und wie schnell sich der Betrieb wiederherstellen lässt, weiß niemand.
- Was wir tun
- Wir prüfen das Sicherungskonzept gegen Ihre Zielwerte für Datenverlust und Ausfallzeit, achten auf unveränderbare oder getrennt gehaltene Kopien und begleiten eine Wiederanlaufübung.
- Ergebnis
- Eine belegte Aussage darüber, wie lange eine Wiederherstellung dauert – statt einer Hoffnung.
Zu viele Konsolen, zu wenig Überblick?
Häufig fehlt nicht ein weiteres Produkt, sondern die Verbindung zwischen den vorhandenen. Eine Bestandsaufnahme zeigt, was sich zusammenführen lässt.
Leistungsumfang
Was wir übernehmen
Nicht jedes Vorhaben braucht alles davon. Der Zuschnitt entsteht nach der Bestandsaufnahme, nicht davor.
Netz und Übergänge
- Firewalls und Übergänge nach außen
- Segmentierung und feingranulare Trennung
- Erkennung und Abwehr im Netzverkehr
- Fernzugriff und identitätsbasierter Zugang
- DNS- und Web-Filterung
Endgerät und Anwendung
- Endgeräteschutz mit Erkennung und Reaktion
- Härtung und Konfigurationsverwaltung
- Verwaltung mobiler und stationärer Geräte
- Schutz von Webanwendungen
- E-Mail-Sicherheit
Erkennung und Reaktion
- Zusammenführung und Auswertung von Protokollen
- Erkennungsregeln und Alarmierung
- Automatisierte Reaktionsschritte
- Schwachstellen- und Patchmanagement
Daten, Identität und Cloud
- Sicherung, Wiederanlauf und unveränderbare Kopien
- Verschlüsselung und Schlüsselverwaltung
- Schutz vor Datenabfluss
- Zertifikate und deren Verwaltung
- Verwaltung von Zugangsdaten und Geheimnissen
- Cloud-Konfiguration und -Überwachung
- Anbindung an Identity- und Privileged-Access-Management
Was XINOO konkret übernimmt
- Anforderungs- und Risikoaufnahme als Auswahlgrundlage
- Zuordnung Risiko → Kontrolle → Technologie
- Marktübersicht und Bewertung geeigneter Kategorien
- Auswahlkriterien und Entscheidungsvorlage
- Integrationskonzept für die vorhandene Umgebung
- Einführung mit Pilotbereich und Rückfallweg
- Betriebsablauf für Meldungen und Eskalation
- Anbindung an Protokollierung und Identitätsverwaltung
- Nachschärfung der Erkennungsregeln nach Inbetriebnahme
- Übergabe und Einweisung Ihres Teams
Was am Ende vorliegt
- Eine Entscheidungsvorlage mit Kriterien statt einer Produktempfehlung ohne Begründung
- Eine Zuordnung, welche Kontrolle welches Risiko senkt
- Ein Integrationsbild der Sicherheitssysteme untereinander
- Ein Betriebsablauf, der festlegt, wer auf welche Meldung reagiert
- Eine Liste dessen, was bewusst nicht beschafft wird – mit Begründung
Passt besonders für
- Häuser mit gewachsener Sicherheitstechnik, die nicht zusammenspielt
- Vorhaben vor einer größeren Beschaffung oder Vertragsverlängerung
- Organisationen, die Meldungen erzeugen, aber keinen Ablauf dafür haben
Entscheidung
Standardlösung, Integration oder Eigenentwicklung?
Die meisten Anforderungen lassen sich mit erprobten Produkten lösen. Interessant wird es dort, wo zwischen den Produkten Lücken bleiben – dort arbeiten wir anders als ein reines Systemhaus.
Einsetzen
Standardprodukt
Wenn ein erprobtes Produkt die Anforderung sauber abdeckt, wird es eingesetzt. Eine Eigenentwicklung wäre hier teurer, langsamer und schlechter gepflegt.
Verbinden
Integration
Vorhandene Systeme über die vorgesehenen Wege verbinden – Schnittstellen, Ereignisströme, Protokolldaten, Identitätsanbindung. Häufig der größte Hebel, weil die Technik schon da ist.
Ergänzen
Erweiterung
Eigene Adapter, Auswertungen, Abläufe, Automatisierungen oder eine Steuerungsebene über den vorhandenen Systemen – dort, wo das Standardprodukt an seine Grenze stößt.
Bauen
Eigenentwicklung
Eine eigene Komponente nur dann, wenn keine erprobte Lösung die Anforderung trägt. Nicht dazu gehören Verschlüsselungsverfahren, Erkennungsmodule oder Firewall-Kerne: Sicherheitsgrundbausteine gehören auf bewährte Technik.
Eigenentwicklung ist bei uns die Ausnahme, nicht der Normalfall – und wenn, dann vorrangig für Integrationen, Automatisierung, Auswertungen, Portale und Steuerungsebenen. Wo ein Standardprodukt reicht, sagen wir das, auch wenn dabei weniger Entwicklungsaufwand für uns anfällt.
Vorgehen
Wie wir arbeiten
Die Reihenfolge ist die Aussage: erst Anforderung und Architektur, dann Technik.
Anforderung und Risiko
Was soll besser werden, und welches Risiko steht dahinter? Ohne diese Beschreibung ist jede Auswahl beliebig.
Kontrolle und Architektur
Welche Kontrolle senkt das Risiko, und an welcher Stelle der Architektur muss sie greifen? Häufig zeigt sich hier, dass Vorhandenes genügt.
Auswahl
Bewertung geeigneter Kategorien und Produkte entlang Ihrer Kriterien – einschließlich der Frage, ob Ihr Team den Betrieb tragen kann.
Integration
Anbindung an Protokollierung, Identitätsverwaltung und vorhandene Systeme, damit das neue Werkzeug nicht als Insel endet.
Betrieb und Nachschärfung
Meldungswege, Zuständigkeiten und Fristen festlegen, danach die Regeln nachschärfen. Eine Erkennung, die zu viel meldet, wird ignoriert.
Häufige Fragen
Was uns dazu gefragt wird
Verkaufen Sie Lizenzen?
Unser Geschäft ist Beratung und Umsetzung, nicht der Weiterverkauf. Das hat einen praktischen Vorteil für Sie: Wir haben kein Interesse daran, dass eine bestimmte Lösung gewinnt. Wo Beschaffung nötig ist, unterstützen wir bei Auswahl und Anforderungen und arbeiten mit Ihrem Einkauf oder Ihrem Systemhaus zusammen.
Warum nennen Sie keine Herstellernamen?
Weil eine Produktempfehlung ohne Kenntnis Ihrer Umgebung nichts wert ist – und weil wir keine Herstellerpartnerschaft behaupten, die nicht besteht. Welche Produkte in die engere Wahl kommen, besprechen wir anhand Ihrer Anforderungen, vorhandener Verträge und Betriebsfähigkeit.
Brauchen wir wirklich ein SIEM?
Nicht zwingend. Die zentrale Sammlung und Auswertung von Ereignissen ist die Anforderung; ein vollwertiges SIEM ist eine mögliche Umsetzung davon. Für kleinere Umgebungen genügt oft eine schlankere Lösung – entscheidend ist, ob jemand die Meldungen liest und ob ein Ablauf dafür existiert.
Können Sie fehlende Funktionen selbst entwickeln?
Wo es sich rechnet, ja – vor allem bei Integrationen, Automatisierungen, Auswertungen, Portalen und Steuerungsebenen. Was wir nicht tun: eigene Verschlüsselungsverfahren, eigene Erkennungsmodule oder eigene Firewall-Kerne bauen. Sicherheitsgrundbausteine gehören auf erprobte Technik, nicht auf Eigenentwicklung.
Weitere Themen
Gehört meistens dazu
Welche Anforderung soll die nächste Lösung erfüllen?
Wenn die Antwort ein Produktname ist, lohnt sich ein Schritt zurück. Wir arbeiten die Kette von Risiko und Kontrolle her auf – und oft genügt, was bereits da ist.