- Home
- /
- Blog
- /
- Softwaremodernisierung
- /
- Security by Design: Wie...
Produktionsanlagen sind oft über Jahrzehnte im Einsatz, während Betriebssysteme, Schnittstellen und Kommunikationswege technisch altern. Genau hier wird der Cyber Resilience Act (CRA) für gewachsene Systemlandschaften zur Herausforderung.
Ein Projekt von Wilde-IT bei einem bekannten Automotive-Unternehmen zeigt, wie bestehende Systeme mit Security by Design weiter genutzt und sicher in eine moderne Architektur eingebunden werden können. Der Artikel zeigt, welche CRA-Anforderungen für bestehende Software relevant sind und wie Security by Design technisch umgesetzt werden kann.
IT-Sicherheit in gewachsenen Produktionslandschaften
Viele Produktionsunternehmen betreiben heute einen historisch gewachsenen Maschinenpark mit unterschiedlichen Betriebssystemen, Schnittstellen und Zugriffswegen. Genau diese Heterogenität erschwert es, Security-Anforderungen einheitlich über die gesamte Produktionslandschaft umzusetzen.
Typisch sind:
- ältere Betriebssysteme auf Maschinen und Anlagen
- unterschiedliche Schnittstellen und Kommunikationswege
- dezentrale Zugriffe und uneinheitliche Berechtigungen
- Systeme, die sich nicht ohne Weiteres aktualisieren oder austauschen lassen
PRAXISBEISPIELSecurity by Design für bestehende Software in Produktionsanlagen
Bei einem bekannten Automotive-Unternehmen mussten Hunderte Produktionsmaschinen unterschiedlicher Generationen weiterbetrieben werden. Unterschiedliche Betriebssysteme, Benutzerkonzepte und ältere Protokolle wie FTP oder SMB erschwerten sichere Zugriffe und eine einheitliche Administration.
Die Lösung: Die bestehenden Systeme wurden über eine zentrale Managementplattform sicher in eine moderne Architektur eingebunden.
Technische Umsetzung
Wilde-IT entwickelte eine cloud-ready Managementplattform auf Microservice-Basis mit Agents auf den Produktionssystemen. Die Authentifizierung wurde über bestehende Identity-Strukturen mit OIDC angebunden und Berechtigungen über RBAC gesteuert.
Die Kommunikation zwischen Plattform und Agents erfolgt über HTTPS. DPoP-gebundene Tokens erschweren zusätzlich die missbräuchliche Wiederverwendung abgegriffener Zugriffstokens.
Über das zentrale Dashboard können unter anderem:
- Bild- und Konfigurationsdateien übertragen werden
- Jobs und zeitgesteuerte Aufgaben gesteuert werden
- neue Maschinen über zusätzliche Agents angebunden werden
- Agent-Updates zentral ausgerollt werden
- Rollen und Zugriffsrechte verwaltet werden
Vorteile für Betrieb und Security
Bestehende Systeme integrieren
Auch Maschinen mit älteren Betriebssystemen und Schnittstellen ließen sich in die zentrale Sicherheitsarchitektur einbinden.
Zugriffe sicher zentralisieren
Autorisierte Mitarbeitende arbeiten über eine gemeinsame Oberfläche und erhalten nur Zugriff auf freigegebene Systeme und Funktionen.
Produktion flexibel erweitern
Weitere Maschinen, Betriebssysteme und Standorte können schrittweise in dieselbe Architektur integriert werden.
Für viele produzierende Unternehmen wird der CRA relevant
Ab 11. September 2026 greifen erste Meldepflichten für Schwachstellen und Sicherheitsvorfälle. Ab 11. Dezember 2027 kommt die Verordnung vollständig zur Anwendung. Für viele Unternehmen wird Security by Design damit zur konkreten Modernisierungsaufgabe.
- Automotive und Zulieferindustrie
- Maschinen- und Anlagenbau
- Metall-, Kunststoff- und Gummiverarbeitung
- Elektro- und Elektronikindustrie
- Chemie- und Pharmaindustrie
- Lebensmittel-, Verpackungs- und Baustoffindustrie
Was Unternehmen über Security by Design und CRA wissen sollten
Was bedeutet Security by Design?
Security by Design bedeutet, dass IT-Sicherheit von Anfang an in Software und Systeme eingebaut wird. Sie ist fester Bestandteil von Architektur, Entwicklung und Lebenszyklus und wird nicht erst am Ende durch zusätzliche Schutzmaßnahmen ergänzt.
Bei bestehender Software heißt das, vorhandene Risiken gezielt zu identifizieren und Sicherheit dort in Architektur, Schnittstellen und Entwicklungsprozesse zu integrieren, wo Handlungsbedarf besteht.
Warum sollten Unternehmen bestehende Software jetzt prüfen?
Bestehende Software sollte frühzeitig geprüft werden, weil veraltete Komponenten, Schnittstellen und Abhängigkeiten Sicherheitsrisiken erhöhen. Zudem gelten die CRA-Meldepflichten für bestimmte Schwachstellen und Sicherheitsvorfälle bereits ab September 2026.
Welche CRA-Anforderungen sind für bestehende Software relevant?
Der Cyber Resilience Act verlangt, dass Sicherheit über den gesamten Lebenszyklus eines Produkts berücksichtigt wird. Für bestehende Software sind dabei vor allem Risikobewertung, sichere Standardkonfigurationen, Zugriffsschutz, die Dokumentation von Komponenten und ein geregeltes Schwachstellenmanagement relevant.
Dazu gehören insbesondere:
- Risikobewertung: Sicherheitsrisiken müssen identifiziert, bewertet und bei Architektur und Entwicklung berücksichtigt werden.
- Secure by Default: Produkte sollen bereits in ihrer Standardkonfiguration möglichst sicher sein.
- Schutz vor unbefugtem Zugriff: Authentifizierung, Identitäts- und Zugriffsmanagement müssen angemessen umgesetzt sein.
- Komponenten und Abhängigkeiten: Hersteller müssen Schwachstellen und Komponenten identifizieren und dokumentieren. Dazu gehört eine maschinenlesbare Software Bill of Materials (SBOM), mindestens für die direkten Abhängigkeiten.
- Schwachstellenmanagement: Security-Tests, Updates und die Behebung bekannt gewordener Schwachstellen müssen über den Supportzeitraum hinweg organisiert sein.
Wie lässt sich Security by Design in bestehender Software umsetzen?
Bei bestehender Software beginnt Security by Design mit einer strukturierten Analyse der vorhandenen Risiken. Danach werden Architektur, Entwicklung und Release-Prozess gezielt dort angepasst, wo relevante Sicherheitslücken bestehen.
Sicherheitsrisiken und Angriffsflächen analysieren
Zuerst müssen kritische Komponenten, Schnittstellen, Zugriffswege und Abhängigkeiten bekannt sein. Threat Modeling hilft dabei, mögliche Angriffsszenarien zu bewerten und Maßnahmen nach Risiko zu priorisieren.
Architektur gezielt absichern
Je nach Ausgangslage können unter anderem Authentifizierung und Berechtigungen zentralisiert, APIs abgesichert oder kritische Bestandssysteme gekapselt und entkoppelt werden. Nicht jede Schwachstelle erfordert einen vollständigen Neuaufbau
Security in CI/CD und Release verankern
Secure Coding, Code Reviews und automatisierte Prüfungen sollten fester Bestandteil des Entwicklungsprozesses sein. Security Gates in der CI/CD-Pipeline verhindern, dass kritische Findings unbemerkt bis zum Release gelangen.
So wird Sicherheit nicht punktuell nachgerüstet, sondern Schritt für Schritt in die bestehende Softwareentwicklung integriert. Ein wichtiger Baustein für die sichere Grundkonfiguration der Software ist Secure by Default.
Was bedeutet Secure by Default?
Secure by Default bedeutet, dass Software bereits mit möglichst sicheren Grundeinstellungen ausgeliefert und betrieben wird. Sicherheitsrelevante Funktionen sollen nicht erst manuell aktiviert werden müssen.
Dazu gehören zum Beispiel:
- nur notwendige Dienste und Schnittstellen aktivieren
- sichere Authentifizierung und Rechtevergabe vorgeben
- unnötige Zugriffe und Funktionen deaktivieren
- sichere Einstellungen für Kommunikation und Updates verwenden
Was ist der Unterschied zwischen Security by Design und Secure by Default?
Security by Design beschreibt vor allem, wie Sicherheit in Architektur und Entwicklung entsteht. Secure by Default ergänzt dieses Prinzip um die Frage, wie sicher das System bereits im Auslieferungszustand konfiguriert ist.
Wie funktioniert Schwachstellenmanagement nach dem Go-live?
Security by Design endet nicht mit dem Release. Auch im laufenden Betrieb müssen neue Schwachstellen erkannt, bewertet und kontrolliert behoben werden. Genau deshalb gehört ein geregeltes Vulnerability Management zum Produktlebenszyklus sicherer Software.
Der Prozess umfasst typischerweise:
- Erkennen: neue Schwachstellen in Software, Libraries und Abhängigkeiten identifizieren
- Bewerten: Kritikalität und mögliche Auswirkungen auf das eigene System einschätzen
- Priorisieren: dringende Risiken von weniger kritischen Findings trennen
- Beheben: Patches, Updates oder technische Anpassungen umsetzen
- Testen: Änderungen vor dem Rollout auf Funktion und Sicherheit prüfen
- Ausrollen: Updates kontrolliert in die produktive Umgebung bringen
- Dokumentieren: Maßnahmen und Entscheidungen nachvollziehbar festhalten
Damit wird Schwachstellenmanagement vom punktuellen Security Check zu einem festen Bestandteil von Betrieb und Weiterentwicklung.
Wie Wilde-IT Security by Design in Softwareprojekte integriert
Wilde-IT berücksichtigt Security bereits bei Architektur, Entwicklung und technischen Freigaben und begleitet Anwendungen auch nach dem Go-live weiter. Bei bestehenden Systemen prüfen wir, welche Komponenten abgesichert werden können, wo Modernisierung sinnvoll ist und wie sich relevante CRA-Anforderungen technisch berücksichtigen lassen.
Sie möchten wissen, wie sich Security by Design in Ihrer bestehenden Software oder Systemlandschaft umsetzen lässt? Wir analysieren die Ausgangslage und entwickeln einen passenden nächsten Schritt.
Weitere Informationen zu unseren Leistungen finden Sie auf der Seite zur Softwaremodernisierung, wo wir unsere Vorgehensweise, Angebote und Modernisierungsbausteine im Detail erläutern.
