GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
Jede Organisation kennt sie, fast niemand denkt an sie: Multifunktionsgeräte, Druckerflotten, Scanner, Plotter, Etikettendrucker, Fax-Module, Kioskdrucker für Belege. Sie stehen unscheinbar im Flur, summen leise vor sich hin, produzieren zuverlässig Seiten – und werden in Security-Runden oft nur dann erwähnt, wenn es um Kosten oder papierlose Initiativen geht. Dabei sind genau diese Geräte in vielen Netzen hochprivilegierte, dauerhaft präsente, schwach gehärtete Systeme mit direktem Draht zu Fileservern, E-Mail-Gateways, Verzeichnisdiensten und manchmal sogar ins öffentliche Internet. Wer sie ignoriert, baut eine Sicherheitsarchitektur mit offener Seitentür. Zeit, das Licht einzuschalten: Warum sind Drucker, Scanner & Co. so attraktiv für Angreifer? Wo liegen die Schattenrisiken? Und wie macht man aus einem grauen Kasten im Flur ein steuerbares, belastbares Asset – statt einer vergessenen Schwachstelle?
Angreifer suchen nicht den glamourösen Weg, sondern den einfachen. Sie lieben überall verfügbare Geräte mit weit offenen Protokollen, seltenen Patches, Standardpasswörtern, großzügigen Netzwerkrechten und Administrationsoberflächen, die niemand überwacht. Multifunktionsgeräte liefern dieses Paket frei Haus:
Kurz: Drucker sind unspektakulär – und genau deshalb gefährlich. Wer hier landet, kann sich seitlich bewegen, Daten abfließen lassen, Persistenz schaffen oder schlicht eine perfekte Tarnung nutzen, während EDR-Sensoren auf Servern und Notebooks Alarm schlagen.
Drucken wirkt trivial: Daten an Port 9100 und fertig. In der Praxis landen PostScript, PCL, PJL, PDF und proprietäre Formate in komplexen Parsern. Parser sind Code – und Code hat Fehler. Mehr noch: RAW 9100 ist verbindungsorientiert ohne Authentisierung. Wer an das Gerät spricht, ist der Nutzer. In internen Netzen genügt ein Skript, um bösartige Druckjobs zu schicken, die Parser zum Absturz bringen, Speicher korrupt machen oder Statuskanäle missbrauchen. IPP über TLS entschärft manches, aber nicht, wenn Zertifikate nicht geprüft oder Selbstsignierer akzeptiert werden.
Viele Geräte liefern moderne Web-UIs – leider oft ohne erzwungenen Passwortwechsel, mit HTTP statt HTTPS, mit Werkspasswörtern in Quick-Start-Guides. Angreifer scannen interne Netze nach typischen Banner-Signaturen, probieren Standard-Creds – und sind drin. Von dort aus lassen sich E-Mail-Relays konfigurieren, Adressbücher auslesen, SMB-Zugänge setzen, Zertifikate importieren oder Firmware einspielen.
SNMP v1/v2c mit „public“/„private“ ist immer noch weit verbreitet. Ergebnis: Jeder kann Gerätenamen, Standort, Seriennummer, Konfig, teils auch Passwörter im Klartext oder Netzwerk-Topologien abgreifen, bei manchen Modellen sogar Parameter setzen. Ohne SNMPv3 (Auth/Priv), abgeschaltete v1/v2c-Profile und restriktive ACLs bleibt das Gerät durchlässig.
Viele MFPs haben Faxkarten oder T.38-Gateways. Alte Faxprotokolle sind unkompliziert, aber unkontrolliert – eine analoge, später IP-Welt mit wenig Authentisierung. Schwachstellen in Bilddecodern oder Faxstacks öffneten bereits den Sprung von der Telefonleitung ins LAN. Wer Fax braucht, muss die Karte wie einen unvertrauenswürdigen Edge behandeln und strikt isolieren.
Bequemlichkeit vs. Sicherheit: Ein globales AD-Konto für alle Geräte mit breit gefassten Share-Rechten („Scan“ hat Vollzugriff) ist Alltag. Gerät kompromittiert? Willkommen im Fileserver. Noch schöner: Adressbücher auf Geräten mit Personenbezug (DSGVO) oder SMTP-Relays ohne Authentisierung über Interne – perfekter Phishing-Multiplikator.
Viele MFPs haben HDD/SSD/Flash, auf denen Druck-/Scan-Jobs, Adressbücher, Zertifikate, Schlüssel, Faxspeicher, Job-Logs liegen. Ohne Kryptografie und sichere Löschung bleiben Daten jahrelang erhalten – bis zur Entsorgung. Zu oft verlassen Geräte das Haus ohne Datenträgerwipe oder Kassettenausbau – ein gefundenes Fressen für Datenjäger.
Wi-Fi Direct, WPS, Bluetooth, NFC – praktisch für Besucher, katastrophal ohne Segmentierung. Viele Geräte spannen eigene WLANs auf oder bewerben Dienste via mDNS/Bonjour. Wer hier rein kommt, landet schnell im Produktions-VLAN, wenn keine Trennung existiert.
Managed Print Services (MPS), Cloud-Print, Fernwartungs-Tunnel – alles bequem, aber oft mit breiten Rechten, fehlender Telemetrie und Subdienstleister-Ketten. Ein kompromittiertes MPS-Portal kann Flotten massengesteuert umkonfigurieren. Ohne vertragliche Meldefristen, Audit-Rechte, Exit-Szenarien und Echtzeit-Transparenz steuert der Dienstleister blind – und Sie noch blinder.
Viele Geräte laufen auf angepassten Linux-/BSD-/RTOS-Varianten. Patches kommen spät, manchmal nie. TLS-Stacks, OpenSSL-Versionen, Webserver – was im Serverumfeld tagesaktuell ist, altert auf Druckern jahrelang. Wer Firmware nicht planvoll aktualisiert, sammelt CVEs wie Briefmarken.
Manchmal ist die attack surface ein Ablagefach. Vertrauliche Ausdrucke liegen stundenlang im Ausgabefach, Scan-Kopien werden auf USB exportiert, Fehldrucke landen ungeschreddert im Papierkorb. Sicherheit scheitert oft vor dem Netzwerk.
Wer das verhindern will, muss die Geräte wie Server behandeln – mit Inventar, Härtung, Segmentierung, Logging, Patch-Prozess, Identitäten, Tests.
Drucker & Co. sind keine Sonderlinge, sondern normale IT-Assets – und müssen in Ihre Governance greifen:
Use-Cases, die im SIEM Sinn ergeben:
Log-Hygiene zählt: Zeitsynchronisation, eindeutige Hostnamen/Tags, einheitliches Facility/Severity-Schema.
1. Die Kanzlei und der Leasing-Rückläufer
Ein MFP geht zurück. Monate später tauchen Fallakten auf – vom Datenträger extrahiert. Ursache: keine Verschlüsselung, kein Wipe. Konsequenz: DSGVO-Meldung, Reputationsschaden, Vertragsärger. Lehre: Storage verschlüsseln, Wipe dokumentiert, Platte ausbauen, Entsorgung belegen.
2. Phishing im Kleid der Vertrautheit
Ein Angreifer kompromittiert ein Gerät, stellt Scan-to-Mail auf einen externen SMTP-Relay, schickt Mitarbeitern „Scans“ mit Link – Absender ist die legitime Geräte-Adresse, Signatur stimmt. Klickrate hoch. Lehre: SMTP-Ziele beschränken, Signaturen erzwingen, Anomalien alarmieren, Device-Absender nur intern nutzen.
3. Der Fileserver über den Seiteneingang
Globales „Scan“-Konto hat Schreibrechte auf breite Ordnerbäume. Gerät gekapert → Massenschreiben von Droppern, danach lateral movement. Lehre: Servicekonten least privilege, nur Ziel-Share, kein Durchwandern; Konten nicht interaktiv, Passwörter rotieren, Events auf NTLM/Kerberos-Fehlschläge auswerten.
Jede Kennzahl braucht Schwelle, Owner, Eskalation, Frist und Re-Check. Erst dann wird aus einem Dashboard Steuerung.
Tage 1–30 – Sicht schaffen
Automatisiertes Discovery (Netz-Scan, DHCP/DNS, Switch-CAM), exakte Gerätelisten mit Firmware, aktiven Protokollen, Zertifikaten, SNMP-Status. Sofortmaßnahmen: HTTP→HTTPS, Standardpasswörter ändern, Telnet/FTP/RAW/LPD aus, SNMPv1/v2c aus, Syslog an SIEM.
Tage 31–60 – Baseline erzwingen
Baselines als Checklisten je Modellfamilie; Massen-Rollout. TLS mit PKI, SNMPv3, Admin-Lockdown, Wi-Fi/BT aus, USB aus (wo möglich). Servicekonten neu: pro Gerät, least privilege, Ablaufdatum, kein interaktiver Login. VLAN für Druck/Scan, erste Firewall-Regeln.
Tage 61–80 – Identität & Segmentierung
802.1X (EAP-TLS) an Ports, Zertifikate per SCEP/ACME. Pull-Print pilotsieren, Ablagefächer entlasten. SaaS/MPS Scorecards definieren, Meldezeiten und Telemetrie vertraglich fixieren. Use-Cases im SIEM fertigstellen (Admin-Login, Config-Change, SMTP-Anomalie, RAW-Traffic).
Tage 81–100 – Üben & verstetigen
Tabletop „Gerät kompromittiert“ und „Phishing via MFP“. Decommission-Prozess mit Wipe/Entsorgung testen. Firmware-Fenster quartalsweise einplanen. Kohärenz-Review: Inventar, Baselines, Logs, Incidents, Lieferkette – Widersprüche → Tickets mit Frist. Awareness nachziehen: „Hol-Druck“, keine Scans an private Mails, saubere Scanziele.
Alles steht und fällt mit Gewohnheiten:
Drucker, Scanner & Co. sind keine Randnotiz – sie sind Produktivsysteme mit direkter Berührung zu Daten, Identitäten, Infrastruktur. In ihnen vereinen sich Netzwerk-, Identitäts-, Daten-, Lieferketten- und physische Risiken – und genau deshalb müssen sie in jede Sicherheitsstrategie, in jedes Risikoregister, in jede Resilienz-Übung. Die gute Nachricht: Wer sie wie Server behandelt – inventarisiert, härtet, segmentiert, überwacht, patcht, identitätsbasiert steuert und im Ernstfall geübt wiederherstellt – dreht die Gleichung um. Aus der vergessenen Schwachstelle wird ein geführtes Asset. Aus dem stillen Risiko wird ein sichtbarer Bestandteil Ihrer Verteidigung. Und aus dem grauen Kasten im Flur wird das, was er in einer reifen Organisation sein soll: unspektakulär – aber sicher.
Peripherie in den regulären Betrieb aufnehmen. Erfassen Sie bei einem ausgewählten Drucker oder Scanner Administratorzugang, Updateverantwortung, Speicherfunktion und erreichbare Netze. Testen Sie, welche Verbindungen für die Aufgabe tatsächlich benötigt werden. Auch Rückgabe oder Entsorgung müssen mit Blick auf gespeicherte Informationen geregelt sein.
Eine umfassende Auseinandersetzung mit ISO/IEC 27001 und ihrem Einsatz zur systematischen Informationssicherheitssteuerung. Im Vordergrund stehen ein wirksames ISMS, die Zuordnung von Verantwortung und belastbare Nachweise.
Von Dr. Markus Groß
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Deine Bewertung hilft bei der Einordnung der Inhalte.
Interessant für dein Netzwerk? Teile den Beitrag direkt.
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.
We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.
Comments 28
Spannend finde ich die praktische Seite: woran sich der praktische Nutzen des beschriebenen Vorgehens zuerst erkennen lässt. Reicht dafür zunächst ein kleiner Pilot oder braucht es sofort einen breiteren Ansatz?
Aus meiner Sicht sollte man mit einem kritischen, aber überschaubaren Fall beginnen. Daran werden fehlende Zuständigkeiten meist schneller sichtbar als in einer allgemeinen Bewertung.
Für mich gehört noch ein fester Zeitpunkt zur Nachprüfung dazu. Erst dann lässt sich beurteilen, ob die Maßnahme nur erledigt wurde oder tatsächlich etwas verbessert hat.
Das ist die wesentliche Abgrenzung. Eine Dokumentation zeigt zunächst nur, was vorgesehen oder getan wurde; erst die überprüfte Wirkung macht daraus einen Steuerungsimpuls.
Gerade der feste Termin zur erneuten Bewertung ist wichtig. Andernfalls wird aus einer vorläufigen Annahme schnell ein dauerhafter Status.
Das wirft eine praktische Frage auf. Welche organisatorischen Fragen sollte man neben technischen Maßnahmen früh klären?
Wer Zutritt erhält, wer Änderungen freigibt und wer Unregelmäßigkeiten meldet. Ohne klare Zuständigkeiten verlieren auch gute technische Maßnahmen an Wirkung.
Wichtig wäre für mich außerdem ein klarer Zeitpunkt, an dem man bei organisatorischen Schutzmaßnahmen prüft, ob der gewählte Ansatz tatsächlich funktioniert. Das wäre ein sinnvoller Prüfpunkt vor einer breiteren Einführung.
Wie überprüft man Zugriffsrechte, die einzeln harmlos erscheinen?
Welche minimale Lösung wäre für Prüfung der Sicherheit außerhalb regulärer Betriebszeiten vertretbar, wenn unter Zeitdruck eine Ausnahme erforderlich wird?
Ich würde die Ausnahme befristen und mit einem benannten Verantwortlichen sowie einer späteren Überprüfung verbinden. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Prüfung der Sicherheit außerhalb regulärer Betriebszeiten sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wie verhindert man, dass physische Sicherheit zwischen Gebäudeorganisation und IT liegen bleibt?
Das ist ein wichtiger Punkt. Ich würde die Übergänge ausdrücklich klären. Gerade dort kann ein Risiko entstehen, obwohl jede Funktion ihren eigenen Bereich für geregelt hält.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Eine überprüfbare Zuständigkeit wäre für mich die Basis. Dazu gehört auch, wer die notwendige Information liefert und wer handelt, wenn sie fehlt. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ich bleibe beim Aufwand etwas skeptisch. Eine kleine, überprüfbare Lösung könnte hier zunächst mehr bringen als ein umfassendes Konzept. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt?
Welche Informationen bleiben auf Geräten, die beim Austausch kaum noch beachtet werden?
Ich sehe darin vor allem eine Gestaltungsfrage. Ich würde die Datenhaltung und den geregelten Umgang bei Rückgabe oder Entsorgung prüfen. Die sichtbare Hauptfunktion eines Geräts erklärt nicht unbedingt seine gespeicherten Informationen.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Als ersten Schritt würde ich einen klar begrenzten Fall nehmen und den tatsächlichen Ablauf gemeinsam durchgehen. An diesem Fall lassen sich die offenen Zuständigkeiten meist konkreter besprechen. Auf die Ausgangsfrage bezogen: Ich würde die Datenhaltung und den geregelten Umgang bei Rückgabe oder Entsorgung prüfen. Die sichtbare Hauptfunktion eines Geräts erklärt nicht unbedingt seine gespeicherten Informationen.
Ich bleibe beim Aufwand etwas skeptisch. Eine kleine, überprüfbare Lösung könnte hier zunächst mehr bringen als ein umfassendes Konzept. Die Ausgangsfrage „Welche Informationen bleiben auf Geräten, die beim Austausch kaum noch beachtet werden?“ ist damit für mich noch nicht vollständig beantwortet.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Meine Ausgangsfrage bleibt: Welche Informationen bleiben auf Geräten, die beim Austausch kaum noch beachtet werden?
Ich würde bei der Umsetzung mit physische und organisatorische Schutzmaßnahmen beginnen und vorher festlegen, welches Ergebnis tatsächlich eine Entscheidung auslöst.
Für die praktische Anwendung zählt aus meiner Sicht physische und organisatorische Schutzmaßnahmen. Sonst wirkt formal alles vollständig, ohne Entscheidungen zu verbessern.
Was müsste bei Kontrolle physischer Zutrittsrechte in einer Übergabe unbedingt verständlich dokumentiert sein?
Zweck, Zuständigkeit und offene Punkte sollten zusammen auffindbar sein. Hilfreich wäre außerdem ein konkretes Beispiel dafür, wie mit einer Abweichung umzugehen ist. Für Kontrolle physischer Zutrittsrechte würde ich den ersten Prüfschritt bewusst klein halten.
Bei das Zusammenspiel physischer und organisatorischer Schutzmaßnahmen scheint mir die zeitliche Perspektive wichtig. Eine einmalige Prüfung sagt wenig darüber aus, ob die Lösung dauerhaft funktioniert.