Welche speziellen Sicherheitslösungen braucht ein Unternehmen wirklich?

Ein Unternehmen braucht nicht möglichst viele Sicherheitslösungen, sondern diejenigen, die seine wichtigsten Geschäftsprozesse, Daten und Zugänge wirksam schützen. Für Schweizer KMU bedeutet das häufig: vorhandene Schutzfunktionen konsequent nutzen, kritische Schwachstellen schliessen und zusätzliche Spezialwerkzeuge nur dort einsetzen, wo ein konkretes Risiko bestehen bleibt.

Eine Firewall, ein Endpunktschutz oder eine Security-Suite allein gewährleistet noch keine Sicherheit. Entscheidend ist, ob die Werkzeuge richtig konfiguriert sind, zusammenarbeiten und im Alltag betreut werden können. Ein Produkt, dessen Warnmeldungen niemand prüft, kann trotz umfangreicher Funktionen wenig zur tatsächlichen Risikoreduktion beitragen.

Die Auswahl beginnt deshalb nicht mit einem Produktkatalog, sondern mit drei Fragen: Welche Betriebsunterbrechungen wären besonders schädlich? Welche Informationen benötigen erhöhten Schutz? Und welche Risiken decken bestehende Massnahmen bereits ab? Erst daraus lässt sich ableiten, ob eine neue Lösung, eine bessere Konfiguration oder eine organisatorische Veränderung notwendig ist.

Warum können zu viele Sicherheitslösungen neue Schwachstellen schaffen?

Zu viele Sicherheitslösungen können neue Schwachstellen schaffen, weil jedes zusätzliche Werkzeug eigene Zugänge, Schnittstellen, Updates und Betriebsaufgaben mitbringt. Wenn ein kleines IT-Team diese Komponenten nicht zuverlässig verwalten kann, entstehen Sicherheitslücken trotz wachsender Produktauswahl. Mehr Werkzeuge verbessern den Schutz deshalb nur, wenn ihr zusätzlicher Nutzen den Integrations- und Wartungsaufwand rechtfertigt.

Jede Security-Plattform benötigt eine sichere Verwaltung. Dazu gehören Administrationskonten, Management-Konsolen, API-Schlüssel, Agenten auf Endgeräten und teilweise Verbindungen zu Cloud-Diensten. Jede dieser Komponenten erweitert die technische Umgebung, die inventarisiert, aktualisiert und überwacht werden muss. Besonders problematisch sind veraltete Agenten oder Schnittstellen, deren Zugriffsberechtigungen nach einer Integration nicht mehr kontrolliert werden.

Hinzu kommt die Überschneidung von Funktionen. Beispielsweise können E-Mail-Schutz, Endpunktschutz und Netzwerküberwachung denselben verdächtigen Vorgang melden. Ohne geregelte Korrelation und Priorisierung werden wiederholte Warnungen zur Belastung.

Gerade bei begrenzten personellen Ressourcen ist deshalb eine vollständige Bestandsaufnahme sinnvoll. Für jedes Werkzeug sollten Zweck, Hersteller, verantwortliche Person, Integrationen, Aktualisierungsstatus und tatsächliche Nutzung dokumentiert sein. Anschliessend lässt sich prüfen, ob mehrere Produkte dieselbe Aufgabe erfüllen oder wesentliche Funktionen ungenutzt bleiben.

Die NIST-Einführung zum Cybersecurity Framework 2.0 für KMU beschreibt einen flexiblen Ansatz, bei dem Organisationen ihre Sicherheitsmassnahmen an Risiken, Ressourcen und Unternehmenszielen ausrichten. Das Framework schreibt keine bestimmte Anzahl von Sicherheitswerkzeugen vor.

Eine Konsolidierung ist allerdings kein Selbstzweck. Wenn zwei Werkzeuge unterschiedliche kritische Risiken zuverlässig abdecken, kann ihr paralleler Einsatz gerechtfertigt sein. Entscheidend ist, ob beide nachweisbar benötigt und zuverlässig betreut werden. Daraus ergibt sich unmittelbar die Frage, welche Massnahmen ein begrenztes Budget zuerst finanzieren sollte.

Wie priorisiert man Sicherheitslösungen bei begrenztem IT-Budget?

Bei begrenztem IT-Budget sollten Unternehmen zuerst diejenigen Sicherheitslücken schliessen, die kritische Geschäftsprozesse gefährden oder besonders schwerwiegende Schäden verursachen können. Dazu werden wichtige Systeme und Daten erfasst, relevante Bedrohungen bewertet und bestehende Schutzmassnahmen geprüft. Erst danach werden Investitionen nach erwarteter Risikoreduktion, Kosten und rechtlichen Anforderungen geordnet.

Eine zweckmässige Risikoanalyse beginnt mit konkreten Geschäftsfolgen. Für einen Produktionsbetrieb kann der Ausfall der Auftragssteuerung besonders gravierend sein. Bei einem Dienstleistungsunternehmen kann hingegen der unberechtigte Zugriff auf vertrauliche Kundendaten im Vordergrund stehen. Die technische Schwachstelle allein sagt wenig darüber aus, wie dringend eine Investition ist.

Für die erste Priorisierung genügt häufig eine einfache Matrix mit den Dimensionen Schadenshöhe und Eintrittswahrscheinlichkeit. Dabei müssen bestehende Sicherheitsmassnahmen und Unsicherheiten der Einschätzung berücksichtigt werden.

Diese Einstufungen sind praktische Planungsbeispiele, keine verbindlichen Fristen oder mathematisch exakten Risikoberechnungen. Eine geringe Eintrittswahrscheinlichkeit darf insbesondere dann nicht beruhigen, wenn die möglichen Schäden existenzbedrohend sind.

Auch die tatsächlichen Kosten verdienen Aufmerksamkeit. Neben Lizenzgebühren entstehen Aufwendungen für Einführung, Systemintegration, Schulung, Aktualisierungen, Überwachung und Incident Response. Eine vermeintlich günstige Speziallösung kann teuer werden, wenn sie dauerhaft zusätzliche Fachkenntnisse benötigt. Der Vergleich sollte daher die Gesamtbetriebskosten über einen einheitlichen Betrachtungszeitraum erfassen.

Für Schweizer Unternehmen sind ausserdem datenschutzrechtliche Anforderungen relevant. Die Erläuterungen des EDÖB zum neuen Datenschutzgesetz erklären unter anderem die Grundsätze Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen nach Artikel 7 DSG. Daraus folgt keine Pflicht zum Kauf eines bestimmten Produkts. Erforderliche technische und organisatorische Massnahmen müssen sich jedoch am konkreten Bearbeitungskontext orientieren.

Eine fundierte Prioritätenliste verhindert nicht jede Sicherheitslücke, schafft aber eine nachvollziehbare Entscheidungsgrundlage. Sobald klar ist, welche Risiken zuerst adressiert werden müssen, lässt sich die geeignete Kombination aus integrierten und spezialisierten Werkzeugen bestimmen.

Security-Suite oder Speziallösung: Was passt zu einem kleinen IT-Team?

Für ein kleines IT-Team ist eine integrierte Security-Suite häufig eine praktikable Basis, wenn sie die wichtigsten Risiken ausreichend abdeckt und zentral verwaltet werden kann. Eine Speziallösung ist sinnvoll, wenn eine konkrete Schutzlücke besondere Funktionen erfordert. Ausschlaggebend sind nicht allein technische Leistungsmerkmale, sondern Integration, Bedienbarkeit, Wartungsaufwand und tatsächliche Reaktionsfähigkeit.

Security-Suites bündeln verschiedene Funktionen, beispielsweise Endpunktschutz, Bedrohungserkennung oder zentrale Richtlinienverwaltung. Das kann die Administration vereinfachen und die Zahl unterschiedlicher Oberflächen reduzieren. Allerdings ist nicht jede enthaltene Funktion gleich leistungsfähig, und eine enge Herstellerbindung kann spätere Wechsel erschweren.

Speziallösungen konzentrieren sich dagegen auf klar umrissene Probleme. Sie können sinnvoll sein, wenn ein Unternehmen besondere Anforderungen an seine Identitätsverwaltung, den Schutz einer bestimmten Anwendung oder die Überwachung einer komplexen Umgebung hat. Mit ihnen entstehen allerdings zusätzliche Schnittstellen und möglicherweise separate Betriebsprozesse.

Besonders wichtig ist die Interoperabilität mit vorhandener Geschäftssoftware. Eine technisch überzeugende Lösung kann ungeeignet sein, wenn sie relevante ERP- oder CRM-Prozesse beeinträchtigt, bestehende Identitätssysteme nicht unterstützt oder notwendige Ereignisdaten nicht zuverlässig verarbeitet.

Vor einer Kaufentscheidung sollte deshalb ein Praxistest mit realistischen Szenarien stattfinden. Ein Team kann beispielsweise in einer isolierten Testumgebung einen verdächtigen Anmeldeversuch simulieren, eine Warnmeldung untersuchen und die vorgesehenen Reaktionsschritte durchführen. Dabei zeigt sich, welche Aufgaben ohne externe Unterstützung gelingen und wo unklare Abläufe bestehen.

Ein möglicher Kompromiss ist eine Basissuite für den allgemeinen Schutz, ergänzt durch eine gezielt ausgewählte Speziallösung für das grösste verbleibende Risiko. Die Begrenzung auf eine Ergänzung kann als interne Vereinfachungsregel dienen, ist aber keine allgemeingültige Sicherheitsvorgabe. Mehrere Spezialwerkzeuge können erforderlich sein, wenn ihre Aufgaben tatsächlich unterschiedlich und relevant sind.

Bei der Entscheidung sollte zudem geklärt werden, ob Überwachung und Reaktion intern geleistet oder teilweise an einen qualifizierten Dienstleister übertragen werden. Die technische Produktauswahl ersetzt keine verlässliche Betriebsorganisation.

Nach der Auswahl beginnt die eigentliche Bewährungsprobe: Eine Lösung muss korrekt eingerichtet und dauerhaft betrieben werden. Ohne geeignete Konfiguration bleiben selbst sorgfältig ausgewählte Sicherheitsfunktionen unter Umständen wirkungslos.

Welche Konfigurationsfehler machen Security-Tools wirkungslos?

Security-Tools verlieren ihre Schutzwirkung, wenn wichtige Funktionen deaktiviert bleiben, Zugriffsrechte zu weit gefasst sind oder Warnmeldungen keine Reaktion auslösen. Besonders kritisch sind unveränderte Standardeinstellungen, dauerhaft deaktivierte Schutzmechanismen und fehlende Zuständigkeiten. Entscheidend ist deshalb nicht, ob ein Produkt installiert ist, sondern ob seine Sicherheitsfunktionen überprüfbar wirken.

Ein häufiger Fehler besteht darin, ein Werkzeug nach der Installation als abgeschlossenes Projekt zu betrachten. Dabei müssen Sicherheitsrichtlinien häufig erst an die Unternehmensumgebung angepasst werden. Beispielsweise kann eine Monitoring-Lösung Ereignisse zuverlässig erfassen, ohne dass die relevanten Benachrichtigungen bei einer verantwortlichen Person ankommen.

Weitere problematische Konfigurationsmuster sind:

• Ungeprüfte Standardeinstellungen: Allgemeine Produktvorgaben berücksichtigen nicht automatisch den spezifischen Schutzbedarf und die Berechtigungsstruktur eines Unternehmens.
• Dauerhaft abgeschaltete Schutzfunktionen: Nach Softwarekonflikten oder Fehlalarmen werden Kontrollen deaktiviert, ohne die Ursache zu beheben oder einen erneuten Aktivierungstermin festzulegen.
• Unkoordinierte Doppelaktionen: Zwei Systeme isolieren beispielsweise denselben Endpunkt unabhängig voneinander und erschweren dadurch die Untersuchung oder Wiederherstellung.
• Unzureichende Protokollierung: Relevante Ereignisse werden nicht erfasst, sind schwer auffindbar oder werden von niemandem regelmässig geprüft.

Die Lösung besteht nicht darin, jede verfügbare Einstellung maximal restriktiv zu setzen. Eine wirksame Erstkonfiguration beginnt mit dokumentierten Anforderungen, nachvollziehbaren Administrationsrechten und der Aktivierung der benötigten Schutzfunktionen. Danach müssen Konfigurationsänderungen kontrolliert getestet werden.

Der EDÖB stellt Informationen zur Informationssicherheit sowie Hinweise zu technischen und organisatorischen Datenschutzmassnahmen bereit. Dazu gehören unter anderem Authentifizierung, Verschlüsselung und geeignete Protokollierungsverfahren. Welche Massnahmen angemessen sind, hängt von der Verarbeitung und dem Schutzbedarf der betroffenen Personendaten ab.

Für einen Wirksamkeitstest sollte das IT-Team in einer autorisierten Testumgebung einen definierten Sicherheitsvorfall simulieren. Anschliessend wird geprüft, ob die Lösung das Ereignis erkennt, korrekt protokolliert, die vorgesehene Benachrichtigung auslöst und eine dokumentierte Reaktion ermöglicht. Ein erfolgreicher Funktionstest ist dabei nur ein begrenzter Nachweis und ersetzt keine umfassende Sicherheitsprüfung.

Auch Mitarbeitende und Verantwortlichkeiten gehören zur Konfiguration im weiteren betrieblichen Sinn. Wenn Sicherheitseinstellungen Arbeitsprozesse unnötig behindern oder niemand den Umgang mit Warnmeldungen erklärt, können Umgehungslösungen und nicht freigegebene Anwendungen entstehen. Schulungen und praktikable Freigabeprozesse sind daher ebenso wichtig wie technische Einstellungen.

Erst wenn vorhandene Funktionen korrekt eingerichtet, getestet und betreut werden, kann zuverlässig beurteilt werden, ob das bestehende Werkzeug weiterhin genügt oder ersetzt werden muss.

Wann sollte ein Unternehmen seine Security-Tools ersetzen oder erweitern?

Ein Unternehmen sollte seine Security-Tools ersetzen oder erweitern, wenn bestehende Lösungen relevante Risiken nicht mehr ausreichend abdecken, der Herstellersupport endet oder veränderte Geschäftsprozesse neue Schutzanforderungen schaffen. Vor einer Neuanschaffung muss jedoch geprüft werden, ob Konfigurationsmängel, fehlende Integrationen oder organisatorische Probleme die eigentliche Ursache sind. Nicht jede Sicherheitslücke erfordert ein neues Produkt.

Ein besonders eindeutiger Auslöser ist das Ende des Herstellersupports. Wenn für eine sicherheitsrelevante Komponente keine notwendigen Sicherheitsupdates mehr verfügbar sind, kann ihr Weiterbetrieb ein nicht mehr vertretbares Risiko darstellen. Die erforderliche Reaktion hängt von der Exposition, möglichen Ersatzmassnahmen und der Bedeutung des betroffenen Systems ab.

Auch Veränderungen der Geschäftsorganisation können neue Sicherheitsanforderungen begründen. Beispiele sind zusätzliche Standorte, eine Cloud-Migration, die Einführung von Remote-Arbeit oder eine stärkere Vernetzung mit Geschäftspartnern. Dabei können neue Identitäts-, Zugriffs- und Überwachungsanforderungen entstehen, die eine bestehende Lösung nur teilweise erfüllt.

Weitere Warnsignale sind wiederholt unbehandelte kritische Alarme, nicht mehr unterstützte Integrationen und ein wachsendes Datenvolumen, das vorhandene Sicherheits- oder Betriebsprozesse überfordert. Entscheidend ist jedoch die Ursache: Werden Warnmeldungen mangels Personal nicht bearbeitet, löst ein zusätzliches Monitoring-Produkt dieses Problem möglicherweise nicht.

Vor einem Ersatz sollten IT-Verantwortliche deshalb drei Möglichkeiten vergleichen:

• Behalten: Die Lösung deckt das aktuelle Risiko ausreichend ab und kann zuverlässig betrieben werden.
• Anpassen: Fehlende Schutzwirkung lässt sich durch bessere Konfiguration, Schulung, Integration oder organisatorische Massnahmen erreichen.
• Ersetzen oder erweitern: Ein wesentlicher Schutzbedarf bleibt trotz zumutbarer Verbesserungen ungedeckt.

Ein häufiger Produktwechsel hat ebenfalls Risiken. Während einer Migration können Sicherheitsrichtlinien verloren gehen, Integrationen ausfallen oder Überwachungslücken entstehen. Ausserdem benötigt das IT-Team Zeit, um eine neue Oberfläche, neue Eskalationswege und geänderte Betriebsabläufe kennenzulernen. Ein Wechsel sollte daher eine dokumentierte Übergangsplanung einschliesslich Tests, Verantwortlichkeiten und Rückfallmöglichkeiten umfassen.

Eine jährliche Überprüfung bietet für viele KMU einen praktikablen Ausgangspunkt. Dafür werden sämtliche eingesetzten Sicherheitswerkzeuge mit dem aktuellen Risikoprofil verglichen. Kritische Ereignisse, wesentliche Systemänderungen oder angekündigte Support-Enden können zusätzliche, frühere Prüfungen erforderlich machen. Das NIST Cybersecurity Framework 2.0 unterstützt eine solche fortlaufende, an Veränderungen angepasste Risikobetrachtung.

Das Ergebnis sollte nicht bloss eine erneuerte Produktliste sein, sondern eine nachvollziehbare Entscheidung mit Begründung, Verantwortlichen und nächsten Prüfterminen. Dadurch wird sichtbar, welche Massnahmen tatsächlich zusätzlichen Schutz schaffen und welche lediglich laufende Kosten verursachen.

Eine wesentliche Grundlage dieser Entscheidungen ist die Kenntnis der geschützten Informationen. Erst wenn deren Bedeutung und Zugriffsrisiken bekannt sind, lässt sich beurteilen, ob vorhandene Sicherheitsfunktionen ausreichen.

Wie klassifiziert man Unternehmensdaten nach Schutzbedarf und Zugriffsrisiko?

Unternehmensdaten lassen sich nach den möglichen Folgen eines Verlusts, einer Offenlegung oder einer unzulässigen Veränderung klassifizieren. Für KMU eignet sich beispielsweise ein Modell mit den Stufen öffentlich, intern, vertraulich und kritisch. Zusätzlich muss geprüft werden, wer auf die Informationen zugreifen kann. Erst die Verbindung von Schutzbedarf und Zugriffsrisiko ermöglicht angemessene Sicherheitsmassnahmen.

Eine Klassifizierung muss nicht mit einer komplexen Spezialsoftware beginnen. Zunächst genügt es, wichtige Datenbestände zu erfassen und deren Bedeutung für den Geschäftsbetrieb einzuschätzen. Dabei sind neben wirtschaftlichen Folgen auch vertragliche Verpflichtungen sowie datenschutzrechtliche Anforderungen zu berücksichtigen.

Das folgende vierstufige Modell ist ein praktischer Vorschlag für die interne Organisation, keine gesetzlich vorgeschriebene Einteilung nach Schweizer Datenschutzrecht.

Der Schutzbedarf ergibt sich nicht allein aus der Bezeichnung einer Datei. Ausschlaggebend sind die möglichen Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Ein veröffentlichtes Dokument kann beispielsweise öffentlich zugänglich sein und dennoch hohe Anforderungen an den Schutz vor Manipulation haben.

Ebenso wichtig ist die Trennung von Schutzbedarf und Zugriffsrisiko. Eine vertrauliche Datei, die ausschliesslich einer kleinen berechtigten Personengruppe zugänglich ist, weist eine andere Zugriffssituation auf als dieselbe Datei in einem breit freigegebenen Cloud-Ordner.

Ein praktikabler Ansatz ist die gemeinsame Betrachtung zweier Fragen: Wie schwerwiegend wäre eine unberechtigte Nutzung oder ein Verlust? Und wie wahrscheinlich ist ein entsprechender Vorfall angesichts der tatsächlich eingerichteten Zugriffe und bestehenden Schutzmassnahmen?

Daraus lassen sich konkrete Verbesserungen ableiten. Dazu gehören das Entfernen unnötiger Freigaben, die Einrichtung rollenbasierter Berechtigungen, eine angemessene Authentifizierung und die regelmässige Überprüfung privilegierter Konten. Nicht jede Datenklasse erfordert dafür eine eigenständige Sicherheitssoftware.

Für die Bearbeitung von Personendaten ist das revidierte Schweizer Datenschutzgesetz relevant. Unternehmen müssen angemessene technische und organisatorische Massnahmen vorsehen und die datenschutzrechtlichen Grundsätze berücksichtigen. Besonders schützenswerte Personendaten verlangen eine sorgfältige Risikobetrachtung. Je nach Branche können zusätzliche rechtliche oder regulatorische Anforderungen gelten, beispielsweise im Finanz- oder Gesundheitswesen.

Die betriebliche Klassifizierung und die gesetzlichen Kategorien sind dabei nicht gleichzusetzen. Insbesondere bedeutet die interne Bezeichnung «kritisch» nicht automatisch, dass ein Datensatz rechtlich als besonders schützenswerte Personendaten gilt. Umgekehrt können auch Daten einer internen Kategorie rechtlich relevante Schutzanforderungen auslösen.

Das Ergebnis sollte eine verständliche Übersicht sein, in der Datenbestände, Eigentümer, Schutzklassen, Zugriffsgruppen und vorgesehene Massnahmen zusammengeführt werden. Eine solche Übersicht schafft die Grundlage für Sicherheitsentscheidungen bei Cloud-Anwendungen, Endgeräten und Netzwerkverbindungen.

Aus dieser Einstufung lässt sich anschliessend ableiten, welche Systeme miteinander kommunizieren dürfen. Bei Firewalls wird besonders deutlich, weshalb Sicherheitsregeln auf tatsächlichen Datenflüssen beruhen müssen und nicht pauschal möglichst viele Verbindungen blockieren sollten.

Wie erstellt man Firewall-Regeln, ohne den normalen Geschäftsbetrieb zu stören?

Firewall-Regeln lassen sich mit geringeren Betriebsrisiken einführen, wenn zunächst der tatsächliche Netzwerkverkehr analysiert, notwendige Verbindungen dokumentiert und neue Einschränkungen schrittweise getestet werden. Vor der Aktivierung sollten betroffene Anwendungen geprüft, zuständige Mitarbeitende informiert und ein Rückfallverfahren vorbereitet sein. So können unerwünschte Zugriffe begrenzt werden, ohne geschäftskritische Datenflüsse unbeabsichtigt zu unterbrechen.

Der häufigste konzeptionelle Fehler ist, Netzwerkregeln ausschliesslich nach technischen Kriterien wie Portnummern oder IP-Adressen zu gestalten. Eine Verbindung kann technisch unauffällig erscheinen und dennoch unerwünscht sein. Umgekehrt kann eine ungewöhnliche Verbindung für eine bestimmte Geschäftsanwendung notwendig sein.

Deshalb sollte jede relevante Firewall-Regel einen nachvollziehbaren fachlichen Zweck besitzen. Vor einer Änderung ist zu klären, welches System mit welchem Ziel kommuniziert, welche Anwendung betroffen ist und wer diese Verbindung benötigt.

Für die schrittweise Einführung bietet sich folgendes Vorgehen an:

1. Ist-Zustand erfassen: Bestehende Regeln, Netzbereiche und relevante Datenflüsse dokumentieren. Dabei besonders geschäftskritische Anwendungen identifizieren.
2. Auswirkungen abschätzen: Prüfen, welche legitimen Verbindungen durch die geplante Änderung betroffen sein könnten und welche Abhängigkeiten bestehen.
3. Regeln kontrolliert testen: Wo die eingesetzte Firewall es unterstützt, neue Bedingungen zunächst im Protokollierungs- oder Simulationsmodus prüfen, bevor tatsächlich blockiert wird.
4. Schrittweise aktivieren: Änderungen in einem vereinbarten Wartungsfenster umsetzen und repräsentative Anwendungstests durchführen.
5. Ergebnisse überwachen: Blockierungsprotokolle und Rückmeldungen aus den Fachabteilungen auswerten. Fehlkonfigurationen gezielt korrigieren.

Nicht jede Firewall verfügt über einen geeigneten reinen Beobachtungsmodus. In diesem Fall können eine Testumgebung oder eng begrenzte Pilotregeln helfen, Auswirkungen vor einem breiteren Rollout zu beurteilen.

Eine wichtige Voraussetzung ist ein vorbereiteter Rollback-Plan. Er sollte festlegen, welche Konfiguration vor der Änderung aktiv war, wie sie wiederhergestellt werden kann und wer die Rücknahme freigibt. Besonders bei Änderungen an Administrationszugängen muss ein unabhängiger Wiederherstellungsweg berücksichtigt werden.

Wartungsfenster sollten zudem anhand des tatsächlichen Geschäftsbetriebs gewählt werden. Ausserhalb der üblichen Bürozeiten können beispielsweise automatisierte Datensicherungen, Bestellübertragungen oder ERP-Schnittstellen aktiv sein. Ein vermeintlich ruhiger Zeitpunkt ist deshalb nicht automatisch ein risikoarmes Änderungsfenster.

Vor der Aktivierung müssen betroffene Abteilungen über mögliche Einschränkungen informiert werden. Ein klar benannter Notfallkontakt und ein definierter Eskalationsweg verkürzen die Zeit bis zur Fehlerbehebung, falls legitime Zugriffe beeinträchtigt werden.

Zu restriktive Regeln können Geschäftsprozesse unterbrechen und Mitarbeitende dazu verleiten, nicht freigegebene Alternativen zu nutzen. Zu grosszügige Regeln lassen dagegen unnötige Kommunikationswege bestehen. Der sinnvolle Kompromiss ist eine möglichst eng begrenzte, fachlich begründete Freigabe, deren Wirksamkeit überprüft wird.

Nach der Aktivierung beginnt die laufende Regelpflege. Jede Regel sollte einen dokumentierten Zweck, eine verantwortliche Stelle und gegebenenfalls ein Ablaufdatum besitzen. Temporäre Freigaben, die nach Abschluss eines Projekts nicht zurückgenommen werden, können langfristig unnötige Zugriffsmöglichkeiten schaffen.

Eine periodische Überprüfung sollte deshalb feststellen, welche Regeln noch benötigt werden, ob Verantwortliche weiterhin zuständig sind und ob sich die zugrunde liegenden Anwendungen verändert haben. Veraltete Regeln können nach angemessener Prüfung entfernt werden.

Diese Dokumentation ist nicht nur für die Sicherheit wichtig. Sie erleichtert Fehlersuche, Systemmigrationen und den Wissenstransfer, falls die verantwortliche IT-Fachperson das Unternehmen verlässt.

Damit einzelne Änderungen dauerhaft sinnvoll bleiben, braucht es allerdings ein übergeordnetes Regelkonzept. Dieses muss festlegen, welche Verbindungen grundsätzlich zulässig sind und wie legitime Zugriffsanforderungen sicher berücksichtigt werden.

Wie schützen Firewalls Unternehmensnetzwerke, ohne legitime Zugriffe zu blockieren?

Firewalls schützen Unternehmensnetzwerke, indem sie erlaubte und unerwünschte Datenverbindungen anhand definierter Regeln unterscheiden. Legitimer Geschäftsverkehr bleibt möglich, wenn Freigaben auf notwendige Anwendungen, Benutzergruppen und Kommunikationsziele abgestimmt sind. Wirksamer Schutz entsteht somit nicht durch möglichst umfassendes Blockieren, sondern durch kontrollierte Zugriffswege, kontinuierliche Überwachung und gezielte Anpassungen.

Eine Firewall prüft Netzwerkverbindungen nach den Fähigkeiten und Regeln des eingesetzten Produkts. Dazu können Quell- und Zieladressen, Ports, Protokolle, Verbindungszustände sowie bei geeigneten Systemen zusätzliche Anwendungsinformationen gehören. Auf dieser Grundlage wird Verkehr erlaubt, abgewiesen oder für weitere Untersuchungen protokolliert.

Das Grundprinzip ist der minimale notwendige Zugriff. Eine Anwendung erhält nur die Netzwerkverbindungen, die sie für ihre vorgesehene Funktion benötigt. Nicht erforderliche Verbindungen werden eingeschränkt. Dadurch sollen unerwünschte Zugriffe und die unkontrollierte Kommunikation zwischen Netzbereichen begrenzt werden.

Eine Firewall sollte jedoch nicht isoliert von der übrigen IT betrachtet werden. Ihre Regeln müssen zu Identitätsverwaltung, Netzwerkarchitektur, eingesetzten Anwendungen und vorhandenen Schutzmassnahmen passen.

Ein typischer Anwendungsfall ist die Trennung von Arbeitsplätzen, Servern und administrativen Systemen. Mitarbeitende benötigen beispielsweise Zugriff auf eine interne Geschäftsanwendung, während direkte Administrationsverbindungen nur für berechtigte IT-Verantwortliche vorgesehen sind. Geeignete Netzwerksegmentierung und abgestimmte Firewall-Regeln können diese Unterschiede technisch abbilden.

Besondere Herausforderungen entstehen bei dynamischen Netzwerkumgebungen:

• Dynamische IP-Adressen: Wenn Kommunikationspartner wechselnde Adressen verwenden, können starre Einzeladressregeln legitime Verbindungen unterbrechen. Geeignete, vom Hersteller unterstützte Objektgruppen oder dynamische Adressmechanismen können Abhilfe schaffen.
• Cloud-Dienste: Cloud-Plattformen können ihre Kommunikationsendpunkte verändern. Freigaben sollten deshalb auf verlässlichen Dienstinformationen und unterstützten Aktualisierungsmechanismen beruhen, statt dauerhaft grosse Adressbereiche ungeprüft zu öffnen.
• Remote-Arbeit: Mitarbeitende benötigen unter Umständen gesicherte Verbindungen zu internen Anwendungen. Abhängig von der Architektur können geeignete VPN- oder identitätsbasierte Zugangslösungen eingesetzt werden, ohne interne Dienste allgemein aus dem Internet erreichbar zu machen.

Entscheidend ist, wie die Firewall-Regeln überwacht und verbessert werden. Blockierungsprotokolle können Hinweise auf unerwünschte Verbindungsversuche geben, aber auch auf technische Probleme legitimer Anwendungen. Allein aus einem blockierten Paket lässt sich nicht immer erkennen, ob ein Angriff oder eine betriebsnotwendige Verbindung vorliegt.

Deshalb benötigen IT-Verantwortliche einen Rückkopplungsprozess mit den Fachabteilungen. Meldet eine Person, dass eine Anwendung nicht funktioniert, sollten die betroffenen Verbindungen mit den Firewall-Protokollen und den dokumentierten Zugriffsanforderungen abgeglichen werden.

Wird eine legitime Verbindung fälschlich blockiert, sollte die Korrektur möglichst präzise erfolgen. Eine pauschale Freigabe ganzer Netzbereiche oder zahlreicher Ports kann zwar eine Störung kurzfristig beseitigen, zugleich aber unerwünschte Kommunikationswege schaffen.

Auch die Auswertung der Protokolle muss angemessen organisiert sein. Relevante sicherheitsbezogene Ereignisse sollten nachvollziehbar sein; gleichzeitig sind Datenschutz, Zugriffsberechtigungen und die erforderliche Aufbewahrungsdauer zu berücksichtigen. Unbeschränkte Datensammlung ist kein Ersatz für eine zweckmässige Überwachungsstrategie.

Die zuvor erstellte Datenklassifizierung liefert dafür eine wesentliche Grundlage: Systeme mit besonders schutzbedürftigen Informationen können strengere Kommunikationsbeschränkungen benötigen als weniger sensible Anwendungen. Die Risikoanalyse wiederum entscheidet, welche Anpassungen vorrangig umgesetzt werden sollten.

Auf diese Weise greifen drei Aufgaben ineinander: Der Schutzbedarf beschreibt, was geschützt werden muss. Die Risikopriorisierung bestimmt, wo Investitionen den grössten Nutzen erwarten lassen. Firewall-Regeln setzen einen Teil dieser Entscheidungen technisch um.

Eine Firewall allein kann jedoch weder sämtliche Bedrohungen erkennen noch Fehler in Anwendungen, unzureichende Berechtigungen oder fehlende Datensicherungen ausgleichen. Sie bleibt Bestandteil eines mehrschichtigen Sicherheitskonzepts, das zur tatsächlichen IT-Umgebung passen muss.

Als nächster Schritt empfiehlt sich eine gemeinsame Überprüfung der geschäftskritischen Anwendungen, ihrer Datenflüsse und der bestehenden Firewall-Regeln. Werden dabei konkrete Schutzlücken festgestellt, lassen sich gezielte Anpassungen planen, testen und dokumentieren. So entsteht ein Sicherheitskonzept, das notwendige Geschäftsprozesse unterstützt, statt sie durch unkoordinierte technische Einschränkungen zu behindern.