Fraunhofer IAO | Mensch-Technik-Interaktion

Anfang Februar 2024 machte AnyDesk einen Angriff auf seine Produktionssysteme öffentlich. Heise berichtet, dass nach Einschätzung der französischen Cybersicherheitsbehörde ANSSI die Angreifer jedoch bereits seit Ende Dezember 2023 Zugriff auf die Systeme gehabt haben könnten. Laut BSI melden öffentliche Quellen, dass auch Quellcode sowie Zertifikate zum Signieren von Software abgeflossen seien. Für Kunden ist das keine Kleinigkeit. Mit solchen Zertifikaten lässt sich Schadsoftware im schlimmsten Fall ein seriöser Anstrich verpassen.

Der Fall zeigt, dass zwischen einem Einbruch und seiner öffentlichen Bekanntgabe mehrere Wochen liegen können. Für Organisationen, die einen solchen Fernzugriffsdienst einsetzen, entsteht dadurch eine schwierige Frage: Wie lassen sich mögliche Veränderungen der Sicherheitslage eines Lieferanten frühzeitig erkennen?

Spannend ist für mich an diesem Fall folgendes: öffentliche Hinweise darauf, dass bei diesem Anbieter etwas nicht stimmt, gab es schon mindestens seit Ende Januar 2024. Nutzer berichteten über Auffälligkeiten, in Security-Blogs wurde diskutiert, offizielle Aussagen und beobachtetes Verhalten ließen Fragen offen. Wer unterschiedliche öffentlich verfügbare Signale beobachtete und miteinander verband, hätte zumindest früher hellhörig werden können.

Einmal sicher, immer sicher?

Bei der Auswahl von Lieferanten betreiben Unternehmen einen erheblichen Aufwand. Es werden Fragebögen verschickt, Zertifikate geprüft, eventuell sogar Audits durchgeführt, Vertragsklauseln vereinbart und Risiken bewertet. Hat der Lieferant die Prüfung bestanden, wird er beauftragt. Damit ist das Thema zunächst erledigt.

Das Problem dabei: Cyberrisiken halten sich nicht an Auditzyklen. Ein Lieferant, der im Januar alle Anforderungen erfüllt, kann im März eine kritische Schwachstelle in einem seiner Produkte haben. Im Mai tauchen erste Exploits auf. Im Juli warnt eine Behörde vor aktiven Angriffen und im September stellt sich heraus, dass Angreifer bereits seit Monaten in Kundensystemen unterwegs sind. Der Fragebogen vom Januar kann trotzdem vollkommen korrekt ausgefüllt worden sein.

Genau dieses Problem haben wir in unserem Paper »Gap Analysis of Supplier Evaluation Processes in Critical Infrastructure Security« anhand realer Vorfälle bei Cisco Webex, Ivanti, SolarWinds, MOVEit und AnyDesk untersucht. Dabei treten immer wieder ähnliche Schwächen auf: Lieferanten werden zu selten kontinuierlich beobachtet, bekannte Schwachstellen und deren Entwicklung werden nicht ausreichend berücksichtigt und Informationen über Sicherheitsvorfälle erreichen Kunden teilweise spät oder unvollständig. Die Frage ist also nicht nur, wie wir Lieferanten bewerten. Wir müssen uns auch fragen, wann und wie oft wir sie bewerten.

Was hätte man vorher wissen können?

Bei vielen Sicherheitsvorfällen stellt sich hinterher heraus, dass es durchaus Warnsignale gab. Das bedeutet natürlich nicht, dass sich ein späterer Angriff hätte vorhersagen lassen. Eine bekannte Schwachstelle führt nicht zwangsläufig zu einem erfolgreichen Angriff, und ein Hersteller mit vielen veröffentlichten CVEs ist nicht automatisch unsicherer als einer mit wenigen. Vielleicht wird bei dem einen genauer gesucht, vielleicht kommuniziert er transparenter oder seine Produkte werden aufgrund ihrer großen Verbreitung häufiger untersucht.

Die reine Zahl der Schwachstellen ist deshalb für sich genommen wenig aussagekräftig. Interessanter wird es, wenn man Entwicklungen über einen längeren Zeitraum betrachtet und unterschiedliche Informationen zusammenführt: Häufen sich kritische Schwachstellen? Werden sie aktiv ausgenutzt? Wie schnell reagiert der Hersteller mit Patches? Treten bestimmte Fehler immer wieder auf? Und wie offen kommuniziert ein Lieferant, wenn tatsächlich etwas passiert?

Gerade der letzte Punkt wird aus meiner Sicht häufig unterschätzt. Wenn ich einen sicherheitskritischen Dienst einkaufe, verlasse ich mich nicht nur auf die technische Qualität eines Produktes, sondern im Ernstfall auch darauf, dass der Lieferant einen Sicherheitsvorfall erkennt, vernünftig darauf reagiert und mich rechtzeitig informiert. Das schönste Zertifikat hilft wenig, wenn ich erst aus der Zeitung erfahre, dass mein Dienstleister seit Wochen kompromittiert ist und noch einen privilegierten Fernzugang auf meine Systeme besitzt.

Die Versuchung ist trotzdem groß, leicht verfügbare Kennzahlen einzusammeln und daraus einen einfachen Score zu berechnen: Anzahl der CVEs, Schweregrade, bekannte Sicherheitsvorfälle – fertig ist die rote, gelbe oder grüne Ampel. So einfach sollte man es sich nicht machen. Entscheidend ist das Gesamtbild und dessen Entwicklung über die Zeit.

Dazu gehören auch nichttechnische Informationen. Unternehmen wachsen, kaufen andere Firmen zu, bauen Personal ab oder geraten wirtschaftlich unter Druck. Keine dieser Entwicklungen bedeutet automatisch, dass die Cybersicherheit schlechter wird. Bei einem Lieferanten, von dem ein kritischer Geschäftsprozess abhängt, können sie aber ein guter Grund sein, genauer hinzuschauen.

Der Lieferant meines Lieferanten

Noch komplexer wird die Sache, wenn man berücksichtigt, dass der eigene Lieferant häufig selbst von weiteren Lieferanten abhängig ist.

Der MOVEit-Vorfall aus dem Jahr 2023 liefert dafür ein schönes – beziehungsweise unschönes – Beispiel. Eine Schwachstelle in der Dateiübertragungssoftware MOVEit des Herstellers Progress Software wurde massenhaft ausgenutzt. In Deutschland traf es unter anderem Majorel beziehungsweise dessen Dienst für den Kontowechsel. Darüber waren wiederum Kunden verschiedener Banken und Krankenkassen betroffen.

Aus Sicht einer betroffenen Bank war also nicht unbedingt der direkte Vertragspartner die eigentliche technische Ursache. Das Problem lag in einem Produkt, das dieser wiederum für seine Dienstleistung eingesetzt hatte. Supply Chain heißt eben tatsächlich Supply Chain.

Für die Lieferantenbewertung bedeutet das, dass wir zumindest bei besonders kritischen Dienstleistungen verstehen sollten, welche wesentlichen Abhängigkeiten dahinterstehen. Wenn ein Dienstleister Zugriff auf zentrale Systeme hat oder ein Ausfall seiner Leistung unmittelbar zu größeren Problemen führt, sollte man wissen, von welchen weiteren Produkten und Diensten diese Leistung wesentlich abhängt. Sonst bewertet man am Ende sehr gründlich den Lieferanten – und übersieht die Abhängigkeit, über die der Angriff tatsächlich kommt.

Das Internet weiß erstaunlich viel

Die gute Nachricht ist: Viele Informationen, die für eine kontinuierlichere Bewertung hilfreich wären, sind bereits öffentlich verfügbar.

Schwachstellendatenbanken zeigen, welche Sicherheitslücken in Produkten bekannt sind. Behörden veröffentlichen Informationen zu aktiv ausgenutzten Schwachstellen und Warnungen zu konkreten Angriffskampagnen. Hersteller veröffentlichen Advisories, Sicherheitsforschende analysieren Vorfälle, Fachblogs berichten über Auffälligkeiten und in Incident-Datenbanken lassen sich frühere Sicherheitsvorfälle nachvollziehen. Dazu kommen klassische Unternehmensinformationen, etwa zu größeren organisatorischen Veränderungen.

Diese Open Source Intelligence – kurz OSINT – also öffentlich verfügbare Informationen kann man systematisch sammeln, zusammenführen und so aufbereiten, dass sie für eine konkrete Fragestellung nutzbar werden.

Beim AnyDesk-Fall wäre ein einzelner Hinweis sicherlich kein Anlass gewesen, sofort die Fernzugänge zu kappen. Mehrere voneinander unabhängige Hinweise hätten aber möglicherweise dazu geführt, noch einmal nachzufragen, Zugriffe stärker zu überwachen oder vorsorglich zu prüfen, welche Abhängigkeiten vom Dienst tatsächlich bestehen.

Von der jährlichen Bewertung zur laufenden Beobachtung

Im Forschungsprojekt AEROKI untersuchen wir, wie öffentlich verfügbare Informationen genutzt werden können, um Zulieferer im Umfeld kritischer Infrastrukturen strukturierter und vor allem aktueller zu bewerten. Unterschiedliche Quellen werden dafür zusammengeführt, relevante Hinweise herausgefiltert und Veränderungen über die Zeit sichtbar gemacht. Der Ansatz setzt ausdrücklich auf eine kontinuierliche Betrachtung anstelle einzelner Prüfzeitpunkte.

Das klingt zunächst recht naheliegend. In der praktischen Umsetzung wird es allerdings schnell schwierig. Schon für einen einzigen großen Softwareanbieter können in kurzer Zeit zahlreiche Schwachstellenmeldungen, Herstellerinformationen, Blogbeiträge und andere Hinweise anfallen. Ein Betreiber kritischer Infrastrukturen hat aber nicht einen Lieferanten, sondern möglicherweise Hunderte oder Tausende. Wer versucht, all diese Informationen manuell zu verfolgen, braucht entweder sehr viel Personal oder sehr viel Optimismus. Automatisierung ist deshalb unvermeidlich.

Sie löst das Problem aber nur teilweise, denn mehr Daten bedeuten nicht mehr Sicherheit. Zu viele Warnmeldungen überlasten nur das Security-Team und im Zweifel, übersieht man was wirklich wichtig ist.

Kritisch für wen?

Entscheidend ist deshalb der Bezug zum eigenen Unternehmen. Nehmen wir an, bei einem Softwarehersteller wird eine kritische Schwachstelle bekannt. Unternehmen A verwendet dessen Produkt für eine interne Anwendung, die im Zweifel einige Tage ausfallen kann. Unternehmen B nutzt dasselbe Produkt für den Fernzugriff auf eine Anlage, deren Ausfall innerhalb weniger Stunden die Produktion stoppt. Die Schwachstelle ist dieselbe. Das Risiko ist es nicht.

Für eine sinnvolle Lieferantenbewertung müssen deshalb externe Informationen mit der eigenen IT- und OT-Landschaft verbunden werden. Welche Produkte des Lieferanten verwenden wir überhaupt? Wo werden sie eingesetzt? Welche Zugriffsrechte besitzt der Anbieter? Welche Geschäftsprozesse hängen davon ab? Gibt es Alternativen und welche Folgen hätte ein Ausfall?

An dieser Stelle schließt sich für mich auch der Kreis zum Assetmanagement (vorhergehender Blogbeitrag). Der Satz »You can’t protect what you don’t know« gilt für die Lieferkette genauso. Ich kann das Risiko eines Lieferanten nur sinnvoll bewerten, wenn ich weiß, wo und wofür ich ihn überhaupt brauche.

Viel Noise – aber was muss ich jetzt tun?

Mit Noise2Action (N2A) gehen wir deshalb noch einen Schritt weiter. Dort verbinden wir externe Threat-, Vulnerability- und Supply-Chain-Signale mit dem konkreten Kontext eines Unternehmens, also beispielsweise mit IT- und OT-Assets, Services und Geschäftsprozessen. Daraus sollen realistische Angriffspfade und vor allem nach möglichen Geschäftsauswirkungen priorisierte Maßnahmen abgeleitet werden.

Denn am Ende interessiert Sicherheitsverantwortliche nicht, dass irgendwo auf der Welt gerade die 10 000ste neue CVE-Nummer des Jahres veröffentlicht wurde.

Sie möchten wissen: Betrifft mich das – und muss ich jetzt etwas tun?

Wenn ein Lieferant kompromittiert wurde und noch einen Remote-Zugang auf meine kritische Produktionsanlage besitzt, sollte diese Information ziemlich weit oben auf meiner Liste stehen. Wenn eine schwerwiegende Schwachstelle dagegen ein Produkt betrifft, das ich gar nicht einsetze, kann die Meldung noch so dramatisch formuliert sein – für meinen Arbeitstag ist sie erst einmal weniger relevant.

Das klingt selbstverständlich, ist in der heutigen Security-Praxis aber keineswegs selbstverständlich. Viele Teams verbringen einen erheblichen Teil ihrer Zeit damit, Informationen zusammenzutragen, zu prüfen und manuell zu priorisieren. Genau hier müssen wir durch Automatisierung besser werden. Klassische Lieferantenbewertungen werden nicht verschwinden und sie sollten es auch nicht. Aber wir müssen uns von der Vorstellung verabschieden, dass wir Cyberrisiken mit einer Prüfung für längere Zeit abhaken können.

Die Sicherheitslage eines Lieferanten kann sich innerhalb weniger Tage ändern. Gleichzeitig stehen heute mehr öffentlich verfügbare Informationen zur Verfügung als jemals zuvor, um solche Veränderungen zumindest früher zu erkennen. Die Herausforderung besteht darin, Daten automatisiert sinnvoll miteinander zu verbinden und anschließend zu herauszuarbeiten, welche davon für das eigene Unternehmen tatsächlich relevant sind.

Bei der nächsten Lieferantenprüfung sollte man sich dann nicht nur fragen: »Ist dieser Lieferant sicher?« Sondern zusätzlich: »Würden wir es rechtzeitig merken, wenn er es nicht mehr ist?«

Leselinks:

• Homepage Projekt AEROKI
• Themenwochen »Sicherheit und Resilienz«
• Abschlussveranstaltung AEROKI
• Projektwebseite »Noise2Action«
• »You can’t protect what you don‘t know«: OT-Sicherheit fängt beim Assetmanagement an – Fraunhofer IAO – BLOG
• Anydesk-Einbruch: Französisches BSI-Pendant vermutet Dezember als Einbruchsdatum | heise online

Wer schon einmal bei einer großen Burger-Schnellrestaurantkette ein Eis bestellen wollte, kennt das Problem vermutlich: Ausgerechnet die Eismaschine ist kaputt. Das Phänomen ist inzwischen so bekannt, dass die notorisch ausfallenden Maschinen fast schon zum Running Gag geworden sind. Ärgerlich für alle, die sich auf ein Eis gefreut haben, für den Betrieb des Restaurants aber zunächst verkraftbar. Burger, Pommes und Getränke können schließlich weiterhin verkauft werden.

Schwieriger wird es, wenn nicht die Eismaschine ausfällt, sondern die Versorgung mit den eigentlichen Zutaten ins Stocken gerät. Wenn Salat, Tomate oder Brötchen nicht rechtzeitig ankommen, wird aus einer Störung in der Lieferkette schnell ein Problem für den gesamten Betrieb. Ein Burger ohne Brötchen mag vielleicht die eine oder andere Low-Carb-Idee bedienen. Die Mehrheit der Kunden dürfte aber weiterhin die klassische Variante bevorzugen.

Genau diese Frage steht im Mittelpunkt der Resilienz von Transportketten: Was passiert, wenn nicht alles nach Plan läuft? Staus, Fahrzeug- oder Personalausfälle gehören seit jeher zur Logistik. Gleichzeitig wurden Lieferketten immer stärker auf Effizienz optimiert. Just-in-Time-Prozesse, geringe Lagerbestände und eng getaktete Transporte reduzieren Kosten, lassen aber auch weniger Spielraum für Störungen. Resilienz bedeutet deshalb nicht, jede Störung zu verhindern. Entscheidend ist vielmehr, ob ein System trotz einer Störung seine eigentliche Aufgabe weiterhin erfüllen kann.

Wann wird eine Transportstörung ein Versorgungsproblem?

Wie unterschiedlich die Auswirkungen einer Störung sein können, zeigt eine Simulation eines autonomen, batterieelektrischen Transportsystems, die wir am Beispiel der Distribution eines Lieferanten für Schnellrestaurants durchgeführt haben. Im Modell wurden Waren von einem Distributionszentrum zu verschiedenen Filialen transportiert. Dabei ging es nicht nur darum, ob die Fahrzeuge ihre geplanten Touren durchführen konnten, sondern vor allem darum, ob die Restaurants trotz auftretender Störungen weiterhin ausreichend versorgt wurden.

Dabei zeigte sich, dass eine Transportstörung nicht zwangsläufig sofort zu einem Versorgungsproblem führt. Verspätet sich beispielsweise eine Lieferung, können vorhandene Lagerbestände diese Verzögerung zunächst auffangen. Der Transportprozess ist in diesem Moment bereits beeinträchtigt, für den Kunden bleibt die Störung aber unsichtbar. Erst wenn Lieferungen länger ausbleiben oder mehrere ungünstige Ereignisse zusammenkommen, sinken die Bestände so weit, dass einzelne Produkte nicht mehr angeboten werden können.

Genau darin liegt ein wichtiger Aspekt von Resilienz. Ein robustes System muss nicht so ausgelegt sein, dass niemals etwas ausfällt. Es braucht vielmehr Möglichkeiten, die Folgen einer Störung abzufedern. In unserem Beispiel übernimmt die Lagerhaltung einen Teil dieser Funktion. An anderer Stelle können zusätzliche Fahrzeuge, alternative Routen oder zeitliche Reserven diese Rolle übernehmen. Solche Puffer kosten allerdings Geld und stehen damit häufig im Spannungsfeld zu den Effizienzzielen moderner Logistiksysteme. Die entscheidende Frage lautet deshalb nicht, wie möglichst viele Reserven aufgebaut werden können, sondern wo Puffer tatsächlich sinnvoll sind.

Neue Technologien schaffen neue Abhängigkeiten

Mit der Elektrifizierung des Straßengüterverkehrs verändert sich dieses System weiter. Batterieelektrische Lkw müssen nicht nur zur richtigen Zeit am richtigen Ort sein, sondern auch über ausreichend Energie verfügen. Ladepunkte müssen verfügbar sein, die notwendige Leistung bereitstellen und zu Tourenplanung und Standzeiten passen. Fällt ein Ladepunkt aus, hängt die tatsächliche Auswirkung deshalb stark vom Gesamtsystem ab. Vielleicht reicht die verbleibende Energie noch für die Tour, vielleicht steht eine alternative Lademöglichkeit bereit oder der Lagerbestand der Filiale überbrückt die Verzögerung.

Mit autonomen Lkw kommt eine weitere Ebene hinzu. Denn auch ein autonomes Fahrzeug kann nicht unter allen denkbaren Bedingungen selbstständig fahren. Baustellen, bestimmte Wetterbedingungen oder Veränderungen der Infrastruktur können dazu führen, dass der automatisierte Betrieb auf einzelnen Strecken zeitweise nicht möglich ist. Welche Bedingungen ein Fahrzeug beherrschen muss und innerhalb welcher Grenzen es autonom eingesetzt werden kann, wird durch die sogenannte Operational Design Domain, kurz ODD, beschrieben.

Auch solche Einschränkungen haben wir in der Simulation betrachtet. Fällt beispielsweise ein Streckenabschnitt für den autonomen Betrieb aus, stellt sich nicht nur die Frage, ob das betroffene Fahrzeug weiterfahren kann. Entscheidend ist vielmehr, welche Folgen daraus für das gesamte Versorgungssystem entstehen: Können Transporte verschoben oder anders disponiert werden? Reichen die Lagerbestände der betroffenen Filialen aus, um eine Verzögerung zu überbrücken? Und ab wann wird aus einer technischen Einschränkung tatsächlich ein Versorgungsproblem?

Elektrifizierung und Automatisierung bringen damit neue Abhängigkeiten in die Transportkette. Neben Fahrzeugen und Straßen werden Energieversorgung, Ladeinfrastruktur, digitale Kommunikation und automatisierte Fahrfunktionen Teil des Gesamtsystems. Gleichzeitig entstehen aber auch neue Möglichkeiten, Störungen früher zu erkennen oder Transporte flexibler neu zu planen. Neue Technologien machen Transportketten deshalb nicht automatisch weniger resilient. Sie verändern vielmehr die Frage, welche Störungen auftreten können und wie mit ihnen umgegangen werden muss.

Resilienz als Teil der Flottentransformation

Gerade deshalb sollte Resilienz bereits bei der Planung zukünftiger Transportkonzepte berücksichtigt werden. Simulationen können helfen, unterschiedliche Störungen gezielt durchzuspielen. Was passiert, wenn ein Ladepunkt für mehrere Stunden ausfällt? Welche Folgen hat eine Einschränkung des autonomen Betriebs? Welche Filialen verfügen über genügend Lagerbestand, um eine Verzögerung abzufangen? So lässt sich erkennen, welche Störungen das System verkraftet und an welchen Stellen zusätzliche Maßnahmen erforderlich sind.

Bei batterieelektrischen Fahrzeugen reicht es deshalb nicht aus, zu fragen, ob die Reichweite für eine Tour genügt. Bei autonomen Fahrzeugen reicht es nicht aus, zu prüfen, ob eine Strecke technisch befahren werden kann. Entscheidend ist, ob das daraus entstehende Transportsystem auch dann zuverlässig funktioniert, wenn nicht alles nach Plan läuft.

Am Ende interessiert den Betreiber eines Schnellrestaurants schließlich weder die technische Verfügbarkeit eines Ladepunkts noch die ODD eines autonomen Lkw. Für ihn zählt, ob seine Filiale zuverlässig mit Waren versorgt wird. Und für den Kunden ist die Sache noch einfacher: Er möchte seinen Burger so bekommen, wie er ihn bestellt hat.

Und vielleicht funktioniert danach sogar die Eismaschine.

Sie möchten wissen, wie resilient Ihre Transportprozesse gegenüber Störungen sind oder wie sich Elektrifizierung und Automatisierung auf die Robustheit Ihrer Flotte auswirken? Das Fraunhofer IAO unterstützt Unternehmen dabei, Transportprozesse datenbasiert zu analysieren, Störungsszenarien zu simulieren und geeignete Maßnahmen für robuste und zukunftsfähige Logistiksysteme zu entwickeln. Sprechen Sie uns gerne für einen fachlichen Austausch oder ein gemeinsames Projekt an.

Leselinks:

• FutureFleet-Check: Datengestützte Entscheidungsgrundlage für Ihre Flottentransformation
• Landingpage der Themenwochen »Sicherheit und Resilienz«
• Forum »Alarmstufe Rot«
• »Güterverkehr neu gedacht«

Quantencomputer könnten einmal Probleme in Chemie, Materialwissenschaften und Energieforschung lösen, die für klassische Computer nicht zu bewältigen sind. Das von Fraunhofer IAO und Fraunhofer IAF koordinierte Kompetenzzentrum Quantencomputing Baden-Württemberg (KQCBW) arbeitet daran herauszufinden, wo dieses Potenzial Realität werden kann und was dafür nötig ist. Auf der Fachmesse Quantum Effects am 6. und 7. Oktober 2026 in Stuttgart stellt das Konsortium aktuelle Ergebnisse vor und zeigt an Demonstratoren, wie Quantencomputing für Industrie und Forschung zugänglich gemacht werden kann.

Der Betriebsrat von Airbus Hamburg erhält den Deutschen Betriebsrätepreis 2026 in Gold in der Kategorie »Große Gremien« für ein gemeinsam mit dem Fraunhofer IAO entwickeltes Arbeitsweltprojekt. Mit seiner Expertise begleitete das Fraunhofer IAO den Airbus-Standort bei der Entwicklung und dem Übergang von einer klassischen Bürowelt zu einer bedarfsgerechten Arbeitsumgebung.

Mit der Eröffnung eines neuen Schani Hotels am Naschmarkt in Wien wird ein Forschungsprojekt sichtbar, das zeigt, wie Künstliche Intelligenz die Gästebetreuung in Hotels unterstützen kann. Entwickelt durch das Kreativstudio Bruce B, hat das Fraunhofer IAO einen virtuellen Gastgeber im Hotel Schani in Wien wissenschaftlich begleitet. Die Erkenntnisse aus dem Projekt sind nun in zwei neuen FutureHotel-Whitepapern veröffentlicht.

Das KI-Tool NAVA des Fraunhofer IAO automatisiert wiederkehrende Verwaltungsaufgaben und berücksichtigt dabei Sicherheits- und Datenschutzanforderungen. Als Mitglied des neuen NAVA-Clubs erhalten Behörden, öffentliche Einrichtungen und weitere Organisationen Zugang zur Technologie, fachliche Begleitung und wiederverwendbare Prozessbausteine. So können sie ihre Anwendungen in einer geschützten Umgebung entwickeln, erproben und auf weitere Prozesse übertragen.