Vernetzung ist mehr: Was COD aus einzelnen Werkzeugen macht

In den meisten Betrieben läuft jedes Werkzeug für sich gut. Der Switch hat sein Betriebssystem. Das Monitoring hat Zabbix. Die Firewall hat ihre Oberfläche. Das Risikoregister liegt in einer Tabelle. Das Problem sitzt dazwischen. Dasselbe Gerät steht in fünf Listen, und keine kennt die anderen.

Bei COD ist das der Kern. Das Handbuch sagt es so: COD ist keine Sammlung unabhängiger Werkzeuge, die sich nur eine Anmeldung teilen. Fast jedes Modul hängt am selben Inventar. Wir nennen das Vernetzung. Die einzelnen Module sind gut. Mehr wird es durch das, was zwischen ihnen entsteht.

Was wir damit meinen

Vier Dinge halten COD zusammen:

• das Asset, also das Gerät oder der Eintrag im Inventar, als gemeinsamer Bezugspunkt
• die Location, die in der Kopfzeile gewählt wird und fast jedes Modul filtert
• eine globale Suche über mehrere Module
• ein Audit, das Änderungen über die Module hinweg zeigt

Nicht jede Verbindung geht gleich tief. Deshalb zählen wir in diesem Beitrag nur, was wir selbst am Bildschirm gesehen haben. Alle Beispiele stammen aus der Demo (COD 3.8, Stand 4. November 2026).

Was Sie haben, bleibt

Wir ersetzen nichts, was Sie behalten wollen. Was Sie haben, bleibt. Das ist der wichtigste Satz dieses Beitrags. Ihr Zabbix läuft weiter. Ihre Firewalls, Ihr vCenter, Ihr Verzeichnis, Ihre CMDB und Ihr Ticketsystem laufen weiter. COD verbindet sie auf einer Asset-Basis. Wo Ihnen etwas fehlt, etwa ein Tresor, eine Zugriffskontrolle oder eine Konfigurationssicherung, bringt COD eigene Bausteine mit. Sie fügen sich ein.

Beispiel 1: Ein Gerät, und alles, was daran hängt

Öffnen Sie in der Demo das Asset KAT-FW-01 und wechseln Sie auf den Tab „References“. Dort steht, was auf dieses Gerät zeigt: der Eintrag im Firewall-Modul, der Host in Zabbix, die Voucher-Konfiguration für den Gastzugang und zwei ToDo-Einträge, beide schon erledigt. Drei dieser Verweise tragen den Vermerk „Blocks delete“. Sie verhindern das Löschen, solange sie bestehen. Mit dem Konto Demo GRC kommt ein Geschäftsprozess dazu, der über eine Asset-Gruppe am Gerät hängt.

Wer ein Gerät tauschen oder löschen will, sieht so vorher, was daran hängt. Die Information liegt an einer Stelle.

Beispiel 2: Eine Suche über mehrere Module

Mit der Lupe oder Strg+K suchen Sie nach Name, IP oder MAC. In der Demo liefert die Suche nach „sw“ Treffer aus sieben Kategorien: Netzwerkgeräte, Topologie, Subnet Planner, Assets, Hypervisor, Kalender und Active Ports Inventory. Die Suche nach „fw“ liefert fünf, darunter die Firewalls. Ein Klick auf den Treffer öffnet den Datensatz.

Die Suche ersetzt nicht das Wissen, wo etwas liegt. Sie spart den Weg dorthin. Sie gilt für die Location, die Sie gewählt haben. Nicht durchsucht werden zum Beispiel NAC, TACACS+, Backup und Monitoring.

Beispiel 3: Am Switch-Port steht, was RADIUS gemeldet hat

„Das Gerät kommt nicht ins Netz.“ Bisher heißt das: erst im Switch nachsehen, dann im RADIUS-Protokoll. In COD öffnen Sie in der Client Overview die Zeile eines Clients. Der Dialog zeigt die Portkarte des Switches. Darunter steht „NAC sessions“ mit Benutzer, MAC, IP, NAS, Port, Start, Stop und Dauer. Daneben steht der Verlauf dieses Clients, also MAC, IP, Nachbar und Linkwechsel. COD hält diesen Verlauf standardmäßig 90 Tage.

So ist die Antwort aus RADIUS neben dem Switch-Port zu sehen. Das gilt, solange der Switch RADIUS von seiner Management-Adresse sendet.

Beispiel 4: Vom Gerät zum Risiko und zum Prozess

Im GRC liegen Prozesse, Asset-Gruppen, Assets und Lieferanten als Register. In der Demo sind es 17 Prozesse, 12 Asset-Gruppen, 124 Assets und 13 Lieferanten. Links zwischen ihnen reichen eine Stufe weiter. Die Stufe einer Asset-Gruppe kommt aus ihrer Risikobewertung. Aus der Stufe eines Lieferanten rechnet COD, welche Nachweise nötig sind.

Das beantwortet eine Frage, die sonst eine Besprechung braucht: Welcher Ausfall trifft welchen Prozess? Wer das Konto GRC der Demo öffnet, sieht am Gerät außerdem Tabs für Placement, Connectivity, Contacts, Contracts und Dependencies. Bei der Störung stehen die Ansprechpartner am Gerät. Verträge nimmt ein eigener Tab auf, in der Demo sind keine hinterlegt. Dafür braucht ein Konto das Recht auf das GRC-Modul.

Beispiel 5: Wartung im selben Kalender

Wartungsfenster der Firewall erzeugen Einträge im COD-Kalender. In der Demo findet die Suche nach „fw“ den Eintrag „KAT-FW-02 Reboot“. Wartung steht damit neben den Terminen, die ohnehin im Kalender stehen. Der Eintrag in der Demo trägt ein Datum aus dem Jahr 2025. Er zeigt die Verbindung, keinen bevorstehenden Termin.

Wie tief die Verbindungen gehen

Nicht jedes Modul ist mit jedem anderen verbunden. Wer COD einführt, soll das vorher wissen. Das Handbuch sagt selbst, welche Verbindungen echt sind und welche nur so aussehen. Wir halten uns daran und nennen hier nur die ersten. Wenn Sie wissen wollen, ob eine bestimmte Verbindung in Ihrem Fall trägt, fragen Sie uns. Wir zeigen es am Bildschirm.

Was Sie davon haben

• Weniger Wege zwischen den Werkzeugen. Die Antwort liegt oft schon im Modul, in dem Sie gerade arbeiten.
• Ein gemeinsamer Bezugspunkt für Betrieb und Informationssicherheit. Dasselbe Gerät, dieselbe Bezeichnung.
• Ihre vorhandenen Werkzeuge bleiben. COD bildet sie nicht nach, es verbindet sie.

Selbst ansehen

Beispiel 1 bis 3 und 5 gehen mit dem Konto Demo First Level. In Beispiel 1 zeigt erst das Konto Demo GRC auch den Geschäftsprozess. Beispiel 4 braucht Demo GRC. Die Zugangsdaten stehen auf extocode.com/demo. Die Konten teilen sich alle Besucher. Bitte geben Sie keine echten Daten ein. Die Oberfläche ist englisch, die Beispieldaten sind überwiegend deutsch.

Welche Funktionen Ihr Vertrag umfasst, ergibt sich allein aus der Leistungsbeschreibung in der Fassung, die für Ihren Vertrag gilt.

• Demo: cod.demo.extocode.com
• Persönliche Vorführung: Kontakt

extocode GmbH · Central Operations Dashboard