In einer sich ständig weiterentwickelnden Bedrohungslandschaft erreichen die Sicherheitsmaßnahmen einen Wendepunkt. Mit zunehmender Geschwindigkeit und Komplexität der Bedrohungen vergrößern sich die Teams und die verwalteten Umgebungen vervielfachen sich. Manuelle Ansätze im Regelmanagement erweisen sich häufig als Engpass. Hier kommt Detections as Code (DaC) ins Spiel, nicht nur als Werkzeug, sondern als Methodik.

DaC als Methodik wendet Softwareentwicklungspraktiken auf die Erstellung, Verwaltung und den Einsatz von Sicherheitserkennungsregeln an. Indem Erkennungsregeln als Code behandelt werden, ermöglicht es Versionskontrolle, automatisierte Test- und Bereitstellungsprozesse und verbessert so die Zusammenarbeit, Konsistenz und Agilität bei der Reaktion auf Bedrohungen. DaC optimiert den Lebenszyklus der Erkennungsregeln und gewährleistet durch Peer-Reviews und automatisierte Tests eine hohe Erkennungsqualität. Diese Methodik unterstützt auch die Einhaltung der Anforderungen an das Änderungsmanagement und fördert eine ausgereifte Sicherheitslage.

Deshalb freuen wir uns, Ihnen die neuesten Updates zu Elastic's detection-rules vorzustellen, unserem offenen Repository zum Schreiben, Testen und Verwalten von Sicherheitserkennungsregeln in Elastic, mit dem Sie auch Ihr eigenes Detections as Code (DaC)-Framework erstellen können. Lesen Sie weiter, um hervorgehobene Implementierungsbeispiele mit erweiterter Funktionalität sowie die Ankündigung des kostenlosen Elastic Detections as Code Workshops zu sehen.

Elastic Security DaC: Der Weg von der Alpha-Phase zur allgemeinen Verfügbarkeit

Mit der Funktionalität, die jetzt im Repository für Erkennungsregeln bereitgestellt wird, können Benutzer alle ihre Erkennungsregeln als Code verwalten, Regelanpassungen überprüfen, Regeln automatisch testen und validieren sowie die Bereitstellung von Regeln in ihren Umgebungen automatisieren.

Vor 2024: Interne Nutzung von DaC bei Elastic

Das Elastic Threat Research and Detection Engineering Team hat das Detection-Rules- Repository erstellt und verwendet, um vorgefertigte Regeln zu entwickeln, zu testen, zu verwalten und zu veröffentlichen. Dabei werden die DaC-Prinzipien befolgt: Regeln werden im Team überprüft, Tests und Veröffentlichungen werden automatisiert. Das Repository verfügt außerdem über eine interaktive Befehlszeilenschnittstelle (CLI) zum Erstellen von Regeln, sodass Entwickler direkt dort mit der Arbeit an den Regeln beginnen können.

Da das Interesse der Sicherheitscommunity an as-code-Prinzipien wuchs und die verfügbaren Elastic Security APIs es den Benutzern bereits ermöglichten, ihre eigenen Detections as Code-Lösungen zu implementieren, beschloss Elastic, die Funktionalität des Detection-Rules -Repositorys zu erweitern, damit unsere Benutzer von unseren Tools profitieren und bei der Erstellung ihrer DaC-Prozesse unterstützt werden können.

Hier sind die wichtigsten Meilensteine der benutzerorientierten DaC-Entwicklung von Elastic von der Alpha-Phase bis zur allgemeinen Verfügbarkeit.

Mai 2024: Alpha-Version der neuen „Selbstbau“-Funktionen

Unser Repository für Erkennungsregeln ist auf die Bedürfnisse unserer Kunden zugeschnitten und ermöglicht die Verwaltung benutzerdefinierter Regeln, die Anpassung der Testsuite an die Benutzeranforderungen sowie die Verwaltung von Aktionen und Ausnahmen neben den Regeln.

Wichtigste Neuerungen:

Unterstützung für benutzerdefinierte Regelverzeichnisse
Wählen Sie anhand Ihrer Anforderungen die gewünschten Tests aus.
Unterstützung für Ausnahmen und Aktionen

Wir haben außerdem einen ausführlichen Leitfaden für Detections as Code mit Beispielen für die Implementierung mit Elastic Security unter Verwendung des detection-rules repository veröffentlicht.

August 2024: „Selbst gestalten“-Funktionen jetzt in der Beta-Phase

Die Funktionalität wurde erweitert, um den Import und Export von benutzerdefinierten Regeln zwischen Elastic Security und dem Repository zu ermöglichen, sowie um weitere Konfigurationsoptionen und eine Versionierungsfunktionalität für benutzerdefinierte Regeln.

Neue Funktionen hinzugefügt:

Massenimport/-export von benutzerdefinierten Regeln (basierend auf Elastic Security APIs)
Vollständig konfigurierbare Unit-Tests, Validierung und Schemas
Versionssperre für benutzerdefinierte Regeln

März - August 2025: sind allgemein verfügbar und werden unterstützt

Verwendung von DaC mit Elastic Security 8.18 und höher:

Unterstützt die Verwaltung vordefinierter Regeln. Sie können alle vordefinierten Regeln aus Elastic Security exportieren und zusammen mit Ihren benutzerdefinierten Regeln speichern.
Unterstützung für Regelfilterung beim Export hinzugefügt.

Parallel zu den DaC-Aktivitäten haben wir im Zeitraum Oktober-Dezember 2025 auch neue Terraform-Ressourcen (V0.12.0 und V0.13.0) veröffentlicht, die es Terraform-Benutzern ermöglichen, Erkennungsregeln und Ausnahmen zu verwalten.

Nachdem diese Grundlagen dargelegt wurden, wollen wir nun die leistungsstarken Funktionen erkunden, die zur Verfügung stehen, um Ihren Erkennungsentwicklungsprozess zu optimieren.

Highlights der DaC-Funktionalität für Erkennungsregeln

Seit unserer letzten DaC-Veröffentlichung haben sich einige lohnenswerte Neuerungen ergeben, auf die wir im Folgenden näher eingehen werden.

Zusätzliche Filter

Die beim Exportieren von Regeln aus Kibana verfügbare Filterfunktionalität wurde erweitert, sodass Sie nun präzise festlegen können, welche Regeln in DaC synchronisiert werden sollen. Hier sind die neuen Flaggen:

Flagge	Beschreibung
-cro	Filtert den Export so, dass nur vom Benutzer erstellte Regeln (und nicht die vordefinierten Elastic-Regeln) enthalten sind.
-eq	Wendet einen Abfragefilter auf die exportierten Regeln an.

Nehmen wir als Beispiel den Fall, dass Sie Regeln nach Datenquelle organisieren und die AWS-Regeln in einen bestimmten Ordner exportieren möchten. In diesem Fall verwenden wir die Filterung nach Tags für Datenquellen und exportieren alle Regeln mit dem Tag Data Source AWS :

python -m detection_rules kibana export-rules -d dac_test/rules #add rules to the dac_test/rules folder
-sv #strip the version fields from all rules
-cro #export only custom rules
-eq "alert.attributes.tags: "Data Source: AWS"" # export only rules with "Data Source: AWS" tag

Siehe die Kibana-Dokumentation für die Abfragezeichenfolgenfilterung für den hier verwendeten zugrunde liegenden API-Aufruf und den API-Aufruf zum Auflisten aller Erkennungsregeln für Beispiele der verfügbaren Felder zum Erstellen des Abfragefilters.

Benutzerdefinierte Ordnerstruktur

Im Repository „detection-rules“ verwenden wir eine Ordnerstruktur, die auf Plattform-, Integrations- und MITRE ATT&CK-Informationen basiert. Dies hilft uns bei unserer Organisation und Regelentwicklung. Dies ist keinesfalls die einzige Organisationsmethode. Sie könnten Ihre Regeln beispielsweise nach Kunde, Datum oder Quelle organisieren. Dies hängt stark vom jeweiligen Anwendungsfall ab.

Egal ob Sie diesen Exportprozess oder die manuelle Organisation verwenden, sobald Sie Ihre Regeln an einem Ort oder in einer Ordnerstruktur Ihrer Wahl gespeichert haben, können Sie diese lokale Struktur auch beim erneuten Exportieren von Regeln beibehalten. Wichtig zu beachten ist, dass die neuen Regeln manuell an der gewünschten Stelle platziert werden müssen. Der lokale Regellademechanismus erkennt, wo die Regeln platziert sind, um zu wissen, wo sie platziert werden sollen. Falls die Regel nicht vorhanden ist, wird das angegebene Ausgabeverzeichnis verwendet, um die neue(n) Regel(n) abzulegen. Um die lokale Regelladung zum Aktualisieren bestehender Regeln zu verwenden, verwenden Sie das Flag --load-rule-loading / -lr für die Befehle kibana export-rules und import-rules-to-repo . Mithilfe dieser Flags können Sie die in Ihrer config.yaml angegebenen lokalen Ordner verwenden.

Betrachten wir ein Beispiel, bei dem die Regeln folgendermaßen in Ordnern organisiert sind:

rule_dirs:
- rules
my_test_rule.toml
- another_rules_dir
high_number_of_process_and_or_service_terminations.toml

Wir werden Folgendes in der Datei config.yaml angeben:

rule_dirs:
- rules
- another_rules_dir

Mit der neuen Option -lr werden Regelaktualisierungen aus Kibana nun diese zusätzlichen Pfade verwenden, anstatt direkt in das angegebene Verzeichnis zu exportieren.

Die Ausführung python -m detection_rules kibana --space test_local export-rules -d dac_test/rules/ -sv -ac -e -lr,exportiert Regeln aus test_local -Bereich, my_test_rule.toml wird nach dac_test/rules/ geschrieben, da es sich bereits dort auf der Festplatte befindet, und high_number_of_process_and_or_service_terminations.toml wird nach dac_test/another_rules_dir/.geschrieben.

Dies kann besonders nützlich sein, wenn Sie die gleichen Regeln in verschiedenen Unterordnerkonfigurationen für verschiedene Kunden haben. Nehmen wir beispielsweise an, Sie haben Ihre Regeln nach Plattform und Integration aufgeschlüsselt, ähnlich der vordefinierten Regelordnerstruktur von Elastic. Für Ihre Kunden, SOCs oder Threat-Hunting-Teams ist die Organisation der Regeln in diesen Plattform-/Integrationsordnern möglicherweise der nützlichste Mechanismus zur Regelverwaltung. Ihr Informationssicherheitsteam oder Ihr primäres Erkennungstechnikteam möchte die Regeln jedoch möglicherweise lieber nach Initiative oder Regelautor verwalten, sodass alle Regeln, für die eine bestimmte Person oder ein bestimmtes Team verantwortlich ist, an einem Ort organisiert sind. Mit den lokalen Regelladeflags können Sie nun einfach zwei Konfigurationsdateien und die duplizierten Regeln in jeder Struktur haben. Beim Exportieren von Regelaktualisierungen verwenden Sie die Umgebungsvariable, um die entsprechende Konfigurationsdatei auszuwählen und die Regelaktualisierungen zu exportieren. Diese Aktualisierungen werden dann auf die bestehenden Regeln angewendet, wobei die Verzeichnisstruktur erhalten bleibt.

Verschiedene lokale Ladeaktualisierungen

Zusätzlich zu den oben genannten Punkten haben wir zwei kleinere neue Funktionen hinzugefügt, die Benutzern helfen sollen, die lokale Informationen in die TOML-Dateien und das Schema der Erkennungsregeln einfügen. Dies sind folgende:

Unterstützung lokaler Datumsangaben aus den lokalen Dateien, wobei das lokale Datum aus der Originaldatei übernommen wird.
Verbesserungen an der Auto-Gen-Funktion, um bekannte Typen aus bestehenden Schemata zu übernehmen.

Die lokale Datumskomponente kann nützlich sein, wenn man mehr manuelle Kontrolle über das Datumsfeld in der Datei wünscht. Ohne Verwendung der Überschreibungsoption basiert das Datum auf dem Zeitpunkt, an dem die Inhalte der Kibana-Regel exportiert wurden. Bei Verwendung des Flags --local-creation-date wird das Datum beim erneuten Export des Dateiinhalts nicht aktualisiert.

Die automatische Schema-Generierung wurde aktualisiert, sodass sie die Typen von anderen Indizes/Integrationen übernimmt, sofern diese vorhanden sind. Dadurch ergibt sich ein potenziell genaueres Schema, und gleichzeitig verringert sich der Bedarf an nachträglichen manuellen Aktualisierungen. Beispielsweise haben Sie eine Regel, die den Index „new-integration*“ mit den folgenden Feldern verwendet:

host.os.type.new_field
dll.Ext.relative_file_creation_time
process.name.okta.thread

Anstatt dass jedes dieser Felder mit einem Standardtyp zum Schema hinzugefügt wird, werden ihre Typen von bestehenden Schemas übernommen. In diesem Fall werden die Typen für dll.Ext.relative_file_creation_time und process.name.okta.thread vererbt.

{
  "new-integration*": {
    "dll.Ext.relative_file_creation_time": "double",
    "host.os.type.new_field": "keyword",
    "process.name.okta.thread": "keyword"
  }
}

Wie Sie dies mit Ihren benutzerdefinierten Datentypen verwenden können, erfahren Sie im Abschnitt „Nutzung benutzerdefinierter Schemas“ im Teil „Implementierungsbeispiele“ dieses Blogs.

Erläuterung der Anwendungsbeispiele

Nachfolgend finden Sie weitere Beispiele für DaC-Implementierungen. Diese konzentrieren sich nicht auf neue Funktionserweiterungen, sondern vertiefen die Themen, die in der Community diskutiert werden.

Es ist erwähnenswert, dass die Detections-as-Code-Funktionen als Komponenten bereitgestellt werden, mit denen sich eine individuelle Implementierung für Ihren gewählten Prozess und Ihre Architektur erstellen lässt. Bei der Implementierung von DaC in Ihrer Produktionsumgebung sollten Sie es als Entwicklungsprozess betrachten und die bewährten Verfahren befolgen.

DaC-Implementierung mit GitLab

Bei der Implementierung von DaC geht es typischerweise darum, eine Art CI/CD-Produkt zu verwenden, um die Regelverwaltung automatisch auf Basis eines bestimmten Auslösers durchzuführen. Diese Auslöser variieren erheblich je nach gewünschter Konfiguration, insbesondere je nach der maßgeblichen Regelquelle und dem gewünschten Zustand Ihres Versionskontrollsystems (VCS). Für eine wesentlich detailliertere Auseinandersetzung mit einigen dieser Aspekte verweisen wir auf unser DaC-Referenzmaterial. Nachfolgend ein einfaches Beispiel, bei dem GitLab als Versionskontrollsystem (VCS) und dessen integrierte CI/CD-Funktion über GitLab Actions verwendet werden.

stages:                # Define the pipeline stages
  - sync               # Add a 'sync' stage

sync-to-production:    # Define a job named 'sync-to-production'
  stage: sync          # Assign this job to the 'sync' stage
  image: python:3.12   # Use the Python 3.12 Docker image
  variables:
    CUSTOM_RULES_DIR: $CUSTOM_RULES_DIR    # Set custom rules env var
  script:                                  # List of commands to run 
    - python -m pip install --upgrade pip  # Upgrade pip
    - pip cache purge                      # Clear pip cache
    - pip install .[dev]                   # Install package w/ dev deps
    - |  # Multi-line command to import rules                                        
      FLAGS="-d ${CUSTOM_RULES_DIR}/rules/ --overwrite -e -ac"
      python -m detection_rules kibana --space production import-rules $FLAGS
  environment:
    name: production   # Specify deployment environment as 'production'
  only:
    refs:
      - main           # Run this job only on the 'main' branch
    changes:
      - '**/*.toml'    # Run this job only if .toml files have changed

Dies ist sehr ähnlich zu anderen integrierten CI/CD-Systemen anderer Git-basierter Versionskontrollsysteme wie GitLab und Gitea. Der Hauptunterschied liegt in der Syntax, die das auslösende Ereignis bestimmt. Die DaC-Befehle wie kibana import-rules wären unabhängig vom VCS gleich. In diesem Beispiel synchronisieren wir Regeln aus unserem Fork des detection-rules-Repositorys mit unserem Kibana Production Space. Dies basiert auf einer Reihe zuvor getroffener Entscheidungen, beispielsweise der Anforderung, dass Unit-Tests vor dem Zusammenführen von Regelaktualisierungen bestanden werden müssen und dass die Regeln auf main bereit für die Produktion sein müssen. Eine detaillierte Erläuterung dieser Überlegungen für diesen speziellen Ansatz finden Sie in unserem Demo-Video auf GitHub.

Tipps und Beispiele für benutzerdefinierte Unit-Tests

Wenn Sie DaC als eine Funktion in Betracht ziehen, die Sie Ihrem Erkennungstoolkit hinzufügen möchten, sollten Sie die Einrichtung der CI/CD- und Basisinfrastruktur als ersten Schritt in einem fortlaufenden Prozess zur Verbesserung der Qualität und Nützlichkeit Ihrer Regeln betrachten. Einer der Hauptvorteile von „as code“-Tools besteht darin, die Möglichkeit zu schaffen, die Tools noch besser an die eigenen Bedürfnisse und die jeweilige Umgebung anzupassen.

Ein Beispiel hierfür sind Unit-Tests für Regeln. Neben der Prüfung der grundlegenden Funktionalität berücksichtigen einige andere wichtige bestehende Unit-Tests Elastic-spezifische Aspekte in Bezug auf Regelperformance und -optimierung sowie die Organisation von Metadaten und Tagging. Dies hilft Erkennungsingenieuren und Bedrohungsforschern, bei der Regelentwicklung konsistent zu bleiben. Aufbauend auf diesem Beispiel könnte man erwägen, benutzerdefinierte Unit-Tests hinzuzufügen, die auf den eigenen Bedürfnissen basieren.

Um dies zu veranschaulichen, nehmen wir eine Security Operations Center (SOC)-Umgebung, in der eine Reihe von Analysten für verschiedene Bereiche und Aufgaben zuständig sind. Wenn im SIEM-System eine Warnung ausgelöst wird, ist möglicherweise nicht sofort ersichtlich, wer für die Behebung des Problems zuständig ist oder welches Team über den Vorfall informiert werden muss. Die Regeln mit einem Team-Tag versehen: z. B. Team: Windows Servers Ähnlich wie Elastic Tags für Datenquellen verwendet, kann dem SOC direkt in der Warnung ein Ansprechpartner zur Verfügung gestellt werden, der bei der Behebung des Problems helfen kann.

In unserer DaC-Umgebung können wir schnell ein neues Testmodul erstellen, um dies für alle benutzerdefinierten Regeln (oder auch für vordefinierte) durchzusetzen. Für diesen Test werden wir erzwingen, dass alle Produktionsregeln, die nicht von Elastic erstellt wurden, mit dem Tag Team: <some name> versehen sind. Im Repository detection-rules werden unsere Tests mithilfe der Python-Testsuite pytest durchgeführt. Daher sind die Unit-Tests in Python-Module (Dateien) und nachfolgende Klassen und Funktionen in diesen Dateien unter dem Ordner tests/ organisiert. Um Tests hinzuzufügen, fügen Sie entweder Klassen oder Funktionen zu den bestehenden Dateien hinzu oder erstellen Sie eine neue Datei. Generell empfehlen wir, neue Testdateien zu erstellen, damit Sie Aktualisierungen der bestehenden Tests von Elastic erhalten können, ohne die Unterschiede zusammenführen zu müssen.

Wir beginnen damit, eine neue Python-Datei namens test_custom_rules.py im Verzeichnis tests/ mit folgendem Inhalt zu erstellen:

# test_custom_rules.py

"""Unit Tests for Custom Rules."""

from .base import BaseRuleTest


class TestCustomRules(BaseRuleTest):
    """Test custom rules for given criteria."""

    def test_custom_rule_team_tag(self):
        """Unit test that all custom rules have a Team: <team_name> tag."""
        tag_format = "Team: <team_name>"
        for rule in self.all_rules:
            if "Elastic" not in rule.contents.data.author:
                tags = rule.contents.data.tags
                if tags:
                    self.assertTrue(
                        any(tag.startswith("Team: ") for tag in tags),
                        f"Custom rule {rule.contents.data.rule_id} does not have a {tag_format} tag",
                    )
                else:
                    raise AssertionError(
                        f"Custom rule {rule.contents.data.rule_id} does not have any tags, include a {tag_format} tag"
                    )

Nun muss jede nicht-elastische Regel ein Tag im vorgegebenen Muster für ein Team enthalten, das für die Behebung der Mängel zuständig ist. Z.B Team: Team A.

Verwendung benutzerdefinierter Schemas

Die Fähigkeit von Elastic, eigene Datentypen einzubinden, erstreckt sich auch auf unsere DaC-Funktionen. Betrachten wir beispielsweise einige benutzerdefinierte Schemata für Netzwerkprotokolle. Die verschiedenen Daten, die Sie in Ihrem Stack haben, können selbstverständlich mithilfe Ihrer Regeln abgefragt werden, und wir werden auch die entsprechenden Validierungs- und Testmechanismen für alle benutzerdefinierten Regeln für diese Datentypen nutzen wollen. Hier kommen benutzerdefinierte Schemas ins Spiel.

Bei der Validierung von Abfragen wird die Abfrage in die jeweiligen Felder zerlegt und die Datentypen dieser Felder mit den Vorgaben eines gegebenen Schemas verglichen (z. B. Datentypen). ECS-Schema, die AWS-Integration für AWS-Daten usw.). Für benutzerdefinierte Datentypen wird der gleiche Validierungspfad angewendet, wobei die Möglichkeit besteht, auf lokal definierte benutzerdefinierte Schemas zuzugreifen. Diese Schemadateien können manuell als eine oder mehrere JSON-Dateien erstellt werden; falls Sie jedoch bereits Beispieldaten in Ihrem System haben, können Sie diese zur Validierung verwenden und Ihre Schemas automatisch generieren.

Sofern Sie bereits einen Ordner für benutzerdefinierte Regeln konfiguriert haben (falls nicht, siehe Anleitung), können Sie die automatische Schema-Generierung aktivieren, indem Sie auto_gen_schema_file: <path_to_your_json_file> zu Ihrer Konfigurationsdatei hinzufügen. Dadurch wird am angegebenen Speicherort eine Schemadatei generiert, die zum Hinzufügen von Einträgen für jede Feld-Index-Kombination verwendet wird. Die Datei wird bei jedem Befehl aktualisiert, bei dem Regelinhalte anhand eines Schemas validiert werden, einschließlich import-rules-to-repo, kibana export-rules, view-rule und anderer. Dies fügt es auch automatisch Ihrer stack-schema-map.yaml-Datei hinzu, wenn Sie ein benutzerdefiniertes Regelverzeichnis und eine benutzerdefinierte Konfiguration verwenden.

Mit dieser Befugnis geht eine erhöhte Verantwortung für die Regelprüfer einher, da jedes in der Abfrage verwendete Feld sofort als gültig angenommen und dem Schema hinzugefügt wird. Eine Möglichkeit zur Risikominderung besteht darin, einen Entwicklungsraum zu nutzen, der Zugriff auf die Daten hat. Im PR kann man dann auf eine erfolgreiche Ausführung der Abfrage mit Stack-Level-Validierung ihrer Datentypen verlinken. Sobald dies genehmigt ist, kann der Zusatz auto_gen_schema_file aus der Konfiguration entfernt werden, und Sie verfügen nun über ein bekanntes, gültiges Schema, das auf Ihren benutzerdefinierten Daten basiert. Dies bietet anderen Regelautoren eine Grundlage, auf der sie bei Bedarf aufbauen können, und gewährleistet die Aufrechterhaltung der Typüberprüfung.

Erfahren Sie mehr über DaC und probieren Sie es selbst aus.

Mit unserem interaktiven Instruqt-Training können Sie die Detections-as-Code-Funktionalität (DaC) von Elastic Security selbst erleben. Dieses Training bietet eine unkomplizierte Möglichkeit, die Kernfunktionen von DaC in einer vorkonfigurierten Testumgebung zu erkunden, wodurch die Notwendigkeit einer manuellen Einrichtung entfällt. Probier es aus!

Wenn Sie DaC implementieren, teilen Sie Ihre Erfahrungen, stellen Sie Ihre Fragen und helfen Sie anderen im DaC-Community-Slack-Kanal.

Testversion der elastischen Sicherheit

Um alle Vorteile von Elastic für Erkennungsingenieure voll auszuschöpfen, starten Sie Ihre kostenlose Testversion von Elastic Security. Besuchen Sie elastic.co/security , um mehr zu erfahren.

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.

Der Leitfaden für Ingenieure zur elastischen Erkennung als Code