Policy-basierter Schutz fürs ganze Netzwerk

Die Arbeit mit den Policies

Nachdem wir unser CounterACT-System in das Netz integriert hatten, wandten wir uns im Test zunächst der Arbeit mit den Policies zu. Alle Policies haben einen Namen, einen Bereich in dem sie gültig sind – zum Beispiel eine Gruppe von Host-Systemen – und Konditionen, die festlegen, welche Aktionen CounterACT im Bedarfsfall durchführt, wie etwa das Unterbinden von P2P-Verkehr.

Im Test verwendeten wir den „Policy Manager“, um unsere Regeln zu erzeugen und in Betrieb zu nehmen. Die erste eingesetzte Regel diente dazu, die im Netz vorhandenen Komponenten zu klassifizieren. Dadurch verbesserte sie die Übersicht, vereinfachte die Verwaltung und schuf die Grundlage für die richtige Behandlung der Systeme durch CounterACT. Die Regel sortierte alle überwachten Geräte nach ihrem Typ, beziehungsweise ihrer Aufgabe. So landeten beispielsweise Windows-Rechner in einer anderen Gruppe als Unix/Linux-Systeme oder Netzwerkkomponenten.

Eine entsprechende Regel lässt sich relativ einfach konfigurieren. Zunächst einmal müssen die zuständigen Mitarbeiter die Segmente angeben, in denen die Policy Anwendung finden soll. Das waren in unserer Testumgebung alle Bestandteile des Netzes. Danach kommen diverse Konditionen zum Einsatz. So gibt es zum Beispiel ein Kriterium, das untersucht, ob es sich bei dem gerade analysierten Gerät um ein Windows-Device handelt. Trifft das zu, so führt CounterACT eine Aktion durch, in diesem Fall das Hinzufügen des Devices zur Windows-Gruppe.

Lässt sich ein Gerät nicht zuordnen, so geht das System zum nächsten Kriterium über, in unserem Fall der Abfrage zu den Handhelds. Handelt es sich bei dem Gerät um ein Handheld-Device, so landet es in der dazugehörigen Gruppe, wenn nicht, geht es weiter zur nächsten Abfrage. Das geht dann immer so weiter, bis alle Stufen abgearbeitet sind. Die dann immer noch nicht klassifizierten Geräte sortiert CounterACT in einer Gruppe namens „Unclassified“ ein. Diese Gruppe ermöglicht es dann später, die Regeln so lange zu verfeinern, bis alle Devices im Netz klassifiziert wurden.

Regelwerk für interne Rechner und Gastsysteme

Die zweite bei uns eingerichtete Regel – die Corporate/Guest-Policy – trennte die Unternehmensrechner von den Guests. Dazu fragten wir ab, ob die Systeme Domänenmitglieder waren oder sich bei einem Authentifizierungsserver im Netz anmelden konnten. Traf das zu, so wurden sie in die Gruppe „Corporate Hosts“ verschoben. Alle anderen Komponenten landeten in der Gäste-Gruppe.

Die Aktionen müssen sich in diesem Zusammenhang keineswegs darauf beschränken, die Systeme irgendwelchen Gruppen zuzuweisen. Sie lassen sich unter anderem gleichzeitig auch dazu nutzen, um das Netz abzusichern, beispielsweise durch das Einschränken des Datenverkehrs der Devices mit Hilfe von Firewall-Regeln.

Mit der nächsten Regel gingen wir genauer auf die Handhelds ein. Die in unserem MDM-System (im Test verwendeten wir an dieser Stelle die Lösung „MaaS360“) angemeldeten Handhelds landeten in der Gruppe „MaaS360 Enrolled Devices“ und durften voll auf unser Netz zugreifen. Die anderen erhielten beim Netzzugriff eine HTTP-Nachricht, die besagte, dass sie dem MDM nicht bekannt seien und sich deshalb registrieren müssten, bevor sie Zugriff erhalten könnten.

Mit einer weiteren Regel führten wir zusätzlich auch noch eine Klassifizierung der MDM-Geräte durch und unterschieden beispielsweise Android- von iOS-Komponenten. Die Regelerstellung läuft in allen Fällen nach dem gleichen Schema ab, mit den betroffenen Segmenten, den Konditionen, die bestimmen, was zu tun ist, und den durchzuführenden Aktionen. Nachdem wir alle unsere Netzwerkkomponenten zugeordnet hatten, machten wir uns daran, diverse Compliance Policies aufzustellen, um unser Netz abzusichern.

(ID:42633342)