Nutzung von Terraform für verbesserte Asset-Sicherheit mit Mondoo - Teil 4: Custom Resources

In den vorherigen Beiträgen dieser Blogreihe haben wir die Mondoo-Plattform, ihre Terraform-Provider Ressourcen, Datenquellen und Importe vorgestellt und erkundet, wie sie die Sicherheit und Compliance von Assets verbessern. Im vierten und letzten Teil werden wir nun einen weiteren spannenden Aspekt der Interaktion von Terraform mit Mondoo entdecken: benutzerdefinierte Inhalte, auch Custom Resources genannt. Custom Resources sind entscheidend, um die Möglichkeiten von Mondoo an spezifische organisatorische Anforderungen in Sicherheits- und Compliance-Rahmenwerken anzupassen und zu erweitern.

Für detailliertere Einblicke, wie Mondoo funktioniert, empfiehlt sich unser vollständiger Artikel über Mondoo.

Einführung in Mondoo's Custom Reources

Aufbauend auf den Grundlagen, die wir in unseren vorherigen Blogs gelegt haben, konzentriert sich dieser Teil unserer Serie auf die Möglichkeiten zur Erstellung Custom Resources im Mondoo-Ökosystem: Custom Frameworks, Custom Policies und Custom Querypacks. Diese Werkzeuge ermöglichen es uns, unsere Sicherheits- und Compliance-Standards an die spezifischen Anforderungen unserer Organisation anzupassen.

Um eine Custom Resource zu erstellen, benötigen wir eine .mql.yaml Datei, in der wir die Parameter für die Resource definieren!

Custom Frameworks

Custom Frameworks ermöglichen es Organisationen, eine strukturierte Sammlung von Richtlinien in einem maßgeschneiderten Framework zu definieren, das mit ihren internen Compliance- und Sicherheitsrichtlinien übereinstimmt. Diese Flexibilität stellt sicher, dass Unternehmen ihre einzigartigen Sicherheitsanforderungen effektiver verwalten und durchsetzen können.

1. Frameworks-Abschnitt

Dies ist der Hauptcontainer für die Framework-Definitionen. Er enthält die allgemeinen Framework-Details, Tags, Autoren und gruppierte Kontrollen.

1frameworks:
2  - uid: example-framework
3    name: Example Framework
4    version: "1.0"
5    license: open-source
6    tags:
7      example.com/icon: example
8    authors:
9      - name: Example Author

• uid: Eine eindeutige Kennung für das Framework.
• name: Der Name des Frameworks.
• version: Die Version des Frameworks.
• license: Der Lizenztyp, unter dem das Framework vertrieben wird.
• tags: Metadaten-Tags für das Framework, die zur Kategorisierung oder Identifizierung verwendet werden.
• authors: Liste der Autoren oder Organisationen, die das Framework erstellt haben.

2. Gruppen-Abschnitt

Der Gruppen-Abschnitt organisiert Kontrollen in logische Kategorien. Jede Gruppe hat eine eindeutige Kennung, einen Titel und enthält eine oder mehrere Kontrollen.

1groups:
2  - uid: example-group-am
3    title: Asset Management (AM)

• uid: Eine eindeutige Kennung für die Gruppe.
• title: Der Titel der Gruppe, der ihren Schwerpunkt oder Bereich beschreibt, z.B. "Asset Management (AM)".

3. Controls-Abschnitt

Jede Gruppe enthält eine oder mehrere Kontrollen. Kontrollen sind spezifische Anforderungen oder Maßnahmen, die implementiert werden müssen, um die Einhaltung des Frameworks sicherzustellen.

 1controls:
 2  - uid: example-control-am-01
 3    title: Asset Inventory
 4    docs:
 5      desc: >-
 6        A short description        
 7    evidence:
 8      - uid: example-evidence-01
 9  - uid: example-control-am-02
10    title: Acceptable Use and Safe Handling of Assets Policy
11    docs:
12      desc: >-
13        A short description        
14    evidence:
15      - uid: example-evidence-02

• uid: Eine eindeutige Kennung für die Kontrolle.
• title: Der Titel der Kontrolle, der beschreibt, was sie adressiert, z.B. "Asset-Inventar".
• docs: Dokumentation zur Kontrolle, einschließlich einer ausführlichen Beschreibung.
  • desc: Eine Beschreibung der Anforderungen oder Erwartungen an die Kontrolle.
• evidence: Verweise auf Nachweise oder Zuordnungen, die die Einhaltung der Kontrolle validieren.
  • uid: Kennung für den Nachweis, wie z.B. eine Zuordnung zu einem anderen Standard oder Framework.

Wir können dieses Framework dann referenzieren und mithilfe von Terraform oder der Benutzeroberfläche zu einem Mondoo Space hinzufügen:

 1provider "mondoo" {
 2  region = "us"
 3}
 4
 5variable "my_custom_framework" {
 6  description = "Path to the custom policy file. The file must be in MQL format."
 7  type        = string
 8  default     = "framework.mql.yaml"
 9}
10
11resource "mondoo_custom_framework" "custom_framework" {
12  space_id = "your-space-1234567"
13  data_url = var.my_custom_framework
14}

Custom Framework Resource

Custom Policies

Mit Custom Policies können Mondoo-Nutzer detaillierte Regeln und Bedingungen festlegen, die ihre Sicherheitsanforderungen und Geschäftslogik widerspiegeln. Diese Richtlinien sind wichtig für die Durchsetzung von Sicherheitsstandards und Compliance über alle verwalteten Assets hinweg.

1. Policies-Abschnitt

In diesem Abschnitt wird eine Reihe von Richtlinien definiert, die auf verschiedene Aspekte von GitHub-Repositories und -Organisationen angewendet werden. Jede Richtlinie hat einen eindeutigen Bezeichner, einen Eigentümer, einen Namen, eine Version und andere Metadaten. Die Richtlinien werden in Gruppen eingeteilt, die jeweils verschiedene Prüfungen enthalten.

 1policies:
 2  - uid: example1
 3    name: Example policy
 4    version: "1.0.0"
 5    tags:
 6      mondoo.com/category: compliance
 7      mondoo.com/platform: github,saas
 8    authors:
 9      - name: Mondoo
10        email: hello@mondoo.com

• uid: Ein eindeutiger Bezeichner für die Richtlinie.
• name: Der Name der Richtlinie.
• version: Die Version der Richtlinie.
• tags: Metadaten-Tags, die die Richtlinie kategorisieren, z. B. Compliance oder bestimmte Plattformen (GitHub, SaaS).
• authors: Informationen über die Autoren oder die für die Richtlinie verantwortliche Organisation, einschließlich Name und Kontakt-E-Mail.

2. Groups-Abschnitt

Policies sind in logische Gruppen unterteilt, die auf ihren Schwerpunktbereichen basieren. Jede Gruppe enthält mehrere Checks und legt Bedingungen (Filter) fest, unter denen diese Checks angewendet werden.

1groups:
2  - uid: example group uid
3    title: Common checks
4    filters: asset.family.contains("unix")
5    checks:
6      - uid: example check uid

• uid: A unique identifier for the group.
• title: The title of the group, describing its focus area, e.g., "Code Changes".
• filters: Conditions specifying the platform or context where the checks should apply (e.g., asset.platform == "github-repo").
• checks: List of checks (identified by unique IDs) that are part of this group.
  • uid: A unique identifier for the check.

3. Queries-Abschnitt

Jeder Check/Überprüfung ist ein spezifisches Kriterium oder eine Anforderung, die erfüllt werden muss. Checks werden innerhalb der Gruppen durch ihre eindeutigen IDs referenziert. Sie definieren, was validiert werden soll und können eine Abfrage (MQL) enthalten, um die Validierung durchzuführen.

 1queries:
 2  - uid: example check uid
 3    title: Ensure all artifacts on all releases are signed
 4    impact: 80
 5    filters: null
 6    tags:
 7      cisecurity.org/recommendation: 2.4.1
 8    mql: |
 9      github.repository.branches.where(name == /^release/).all(isProtected == true)      
10    docs:
11      desc: |-
12        Manual
13        **Rationale:**
14        Sign all artifacts in all releases with user or organization keys...        
15      audit: For every artifact in every release, verify that all are properly signed.

• uid: Eine eindeutige Kennung für die Überprüfung.
• title: Kurzer Titel der Überprüfung, der beschreibt, was sie verifiziert.
• impact: Numerischer Wert, der die Bedeutung der Überprüfung angibt (z.B. 80).
• filters: Bedingungen, die bestimmen, wann diese Überprüfung gilt (kann null sein, wenn nicht verwendet).
• tags: Tags für zusätzliche Kategorisierung oder Referenz.
• mql: Die Abfragesprache, die zur Implementierung der Überprüfung verwendet wird (MQL) - spezifiziert die Kriterien für die Überprüfung.
• docs: Dokumentation zur Überprüfung:
  • desc: Beschreibung und Begründung der Überprüfung.
  • audit: Anweisungen zur Überprüfung der Einhaltung der Überprüfung.
  • remediation: Empfohlene Maßnahmen, falls die Überprüfung fehlschlägt.

Wir können diese Richtlinie dann referenzieren und mithilfe von Terraform oder der Benutzeroberfläche zu einem Mondoo Space hinzufügen:

 1provider "mondoo" {}
 2
 3variable "my_custom_policy" {
 4  description = "Path to the custom policy file. The file must be in MQL format."
 5  type        = string
 6  default     = "policy.mql.yaml"
 7}
 8
 9resource "mondoo_custom_policy" "my_policy" {
10  space_id  = mondoo_space.my_space.id
11  source    = var.my_custom_policy
12  overwrite = true
13}

Custom Policy Resource

Custom Query Packs

Custom Query Packs erweitern die Möglichkeiten von Mondoo, indem sie es Nutzern ermöglichen, Sammlungen von Abfragen zu erstellen, die ausgeführt werden können, um Informationen zu sammeln oder Systeme basierend auf spezifischen Kriterien zu überprüfen. Diese Pakete können verwendet werden, um benutzerdefinierte Scans und Bewertungen durchzuführen.

1. Policies-Abschnitt

Der erste Abschnitt ist identisch mit dem Policies-Abschnitt der Custom Policies.

 1policies:
 2  - uid: mondoo-example-queries
 3    name: Example Query Pack
 4    version: 1.2.0
 5    license: example-licence
 6    tags:
 7      mondoo.com/category: best-practices
 8    authors:
 9      - name: Mondoo, Inc
10        email: hello@mondoo.com

• uid: Eine eindeutige Kennung für die Richtlinie.
• name: Der Name der Richtlinie.
• version: Die Version der Richtlinie.
• license: Die Lizenz, unter der die Richtlinie verteilt wird.
• tags: Metadaten-Tags, die die Richtlinie kategorisieren, wie z.B. Best Practices.
• authors: Informationen über die Autoren oder die Organisation, die für die Richtlinie verantwortlich ist.

2. Groups-Abschnitt

Wieder können wir eine ähnliche Struktur wie bei den Custom Policies beobachten. Der einzige Unterschied besteht darin, dass wir anstelle von checks einen queries-Abschnitt haben.

1groups:
2  - type: 1
3    title: ESXi asset counts
4    filters: asset.platform == 'vmware-vsphere'
5    queries:
6      - uid: mondoo-asset-count-on-vsphere-cluster-esxi
7      - uid: mondoo-asset-count-on-vsphere-cluster-vms

• type: Typ der Gruppe, der normalerweise die Art der zu zählenden Vermögenswerte angibt.
• title: Der Titel der Gruppe, der die Asset-Kategorie angibt, z. B. „ESXi-Assets zählen“.
• filters: Bedingungen, die die Plattform oder den Kontext angeben, für den die Abfragen gelten (z. B. asset.platform == „vmware-vsphere“).
• queries: Liste der Abfragen (identifiziert durch eindeutige IDs), die Teil dieser Gruppe sind.

3. Queries-Abschnitt

Der Abschnitt Queries verweist auf jede einzelne Abfrage durch ihre uid und definiert die entsprechende mql-Abfrage.

1queries:
2  - uid: mondoo-asset-count-aws-acm-certificates
3    title: AWS ACM Certificates
4    filters: null
5    mql: aws.acm.certificates.length
6  - uid: mondoo-asset-count-aws-active-regions
7    title: AWS Regions Active
8    filters: null
9    mql: aws.regions.length

• uid: Eindeutiger Bezeichner für die Abfrage.
• titel: Ein beschreibender Titel für die Abfrage, z. B. „AWS ACM-Zertifikate“.
• filters: Bedingungen, die auf die Abfrage angewendet werden können (kann null sein, wenn nicht verwendet).
• mql: Der Ausdruck der Abfragesprache, mit dem die Zählung durchgeführt wird und der angibt, welche Assets gezählt werden sollen.

Wir können dann auf dieses Abfragepaket verweisen und es mit Terraform oder der Benutzeroberfläche zu einem Mondoo Space hinzufügen:

 1provider "mondoo" {
 2  region = "us"
 3}
 4
 5variable "my_custom_querypack" {
 6  description = "Path to custom querypack file. File must be in MQL format."
 7  type        = string
 8  default     = "querypack.mql.yaml"
 9}
10
11resource "mondoo_custom_querypack" "my_query_pack" {
12  space_id = mondoo_space.my_space.id
13  source   = var.my_custom_querypack
14}

Custom Query Pack Resource

Beachten Sie, dass Sie alle vorhandenen Frameworks, Richtlinien und Query Packs in Ihrem Bereich herunterladen und nach Ihren Wünschen anpassen können.

Zusammenfassung

Die Einführung von benutzerdefinierten Ressourcen im Mondoo Terraform-Provider ist ein bedeutender Schritt nach vorne, um maßgeschneiderte Sicherheitslösungen anbieten zu können. Diese Ressourcen ermöglichen eine größere Flexibilität und Präzision bei der Definition und Durchsetzung von Sicherheitsstandards und machen Mondoo zu einem anpassungsfähigeren und leistungsfähigeren Werkzeug für das Sicherheitsmanagement von Infrastrukturen.

Dies ist der Abschluss unserer Blogserie über die Weiterentwicklung des Mondoo Terraform Providers. Weitere Informationen zu Mondoo und anderen spannenden Themen finden Sie in unseren ausführlichen Blogbeiträgen zu diesem Thema im Infralovers Blog. Wir von Infralovers sind bestrebt, Sie immer auf dem neuesten Stand der Technik zu halten.