# SPDX-License-Identifier: CC-BY-4.0
#
# profiles/out_of_band_server_management/fiche.yaml
# Fiche NeuralWall — Appliance d'intégration de gestion matérielle out-of-band
#
# Scénario générique (vendor-agnostic, invariant 3) abstrait d'une exigence réseau réelle :
# un appliance d'intégration relie un GESTIONNAIRE DE VIRTUALISATION au plan de gestion
# OUT-OF-BAND des serveurs (contrôleurs BMC), et joint un SERVICE ÉDITEUR de firmware sur
# Internet pour les mises à jour. Aucune marque ni nom de produit n'apparaît : les rôles
# (gestionnaire de virtualisation, appliance d'intégration, BMC, service de firmware) sont
# décrits de façon abstraite. Consulter docs/control-taxonomy.md pour le vocabulaire canonique.

# ─────────────────────────────────────────────────
# FRONTMATTER
# ─────────────────────────────────────────────────

schema_version: "1.0.0"

id: out_of_band_server_management

version: "1.0.0"

# community : contribution d'exemple non encore revue par un mainteneur (ADR-0002 §3).
trust_tier: community

title:
  fr: "Appliance d'intégration de gestion matérielle out-of-band (BMC)"
  en: "Out-of-band hardware management integration appliance (BMC)"

description:
  fr: |
    Ce scénario couvre les flux réseau d'un appliance d'intégration qui administre des
    serveurs via leur plan de gestion out-of-band (contrôleurs BMC, indépendants du système
    d'exploitation). L'appliance expose une interface web et une API à des administrateurs et
    à un gestionnaire de virtualisation ; il pilote les BMC des serveurs gérés (découverte,
    inventaire, configuration, mise à jour de firmware) ; et il joint un service éditeur sur
    Internet pour télécharger les paquets de firmware. Le plan de gestion out-of-band donne un
    contrôle matériel total (sous le système d'exploitation) : il est traité comme une zone à
    privilège élevé, segmentée et inspectée. Les protocoles de gestion en clair hérités
    (CIM-HTTP, transfert de fichiers non chiffré) sont bloqués au profit de leurs équivalents
    chiffrés. La provenance (produit éditeur d'origine) est documentée dans la section Sources.
  en: |
    This scenario covers the network flows of an integration appliance that administers
    servers through their out-of-band management plane (BMC controllers, independent of the
    operating system). The appliance exposes a web UI and an API to administrators and to a
    virtualization manager; it drives the managed servers' BMCs (discovery, inventory,
    configuration, firmware updates); and it reaches a vendor service on the Internet to
    download firmware packages. The out-of-band management plane grants full hardware control
    (below the operating system): it is treated as a high-privilege zone, segmented and
    inspected. Legacy clear-text management protocols (CIM-HTTP, unencrypted file transfer) are
    blocked in favor of their encrypted equivalents. The provenance (original vendor product) is
    documented in the Sources section.

authors:
  - name: "NeuralWall Rules Team"
    email: "rules@neuralwall.io"
    org: "NeuralWall"

# references : PROVENANCE de la fiche. C'est le SEUL emplacement où une marque ou un nom de
# produit propriétaire est admis (invariant 3) — pour permettre de retrouver et vérifier la
# source. Le contenu normatif des règles ci-dessous reste, lui, strictement vendor-agnostic.
references:
  - vendor: "Lenovo"
    product: "XClarity Integrator for VMware vCenter"
    title: "Network requirements"
    url: "https://pubs.lenovo.com/lxci-vcenter/network_requirements"
    retrieved: "2026-06-04"
    # endpoints : domaines de mise à jour documentés par la source (provenance vérifiable).
    # NON normatif — à reporter en url_filtering.allow_list (règle 6) au déploiement.
    endpoints:
      - "datacentersupport.lenovo.com"
      - "download.lenovo.com"
      - "filedownload.lenovo.com"
      - "support.lenovo.com"
      - "supportapi.lenovo.com"

# ─────────────────────────────────────────────────
# THREAT CONTEXT — Champs AUTEURÉS (invariant 5, ADR-0002 §2)
# ─────────────────────────────────────────────────

mitre_attack:
  # T1190 : l'interface web/API de l'appliance est une surface d'attaque exposée.
  - technique_id: "T1190"
    name: "Exploit Public-Facing Application"
    tactic: "initial-access"

  # T1210 : depuis l'appliance, un attaquant pivote vers les services de gestion des BMC.
  - technique_id: "T1210"
    name: "Exploitation of Remote Services"
    tactic: "lateral-movement"

  # T1542.001 : implantation de firmware système via le BMC — persistance sous l'OS.
  - technique_id: "T1542.001"
    name: "Pre-OS Boot: System Firmware"
    tactic: "persistence"

  # T1557 : interception des protocoles de gestion en clair (CIM-HTTP, IPMI) -> vol d'identifiants.
  - technique_id: "T1557"
    name: "Adversary-in-the-Middle"
    tactic: "credential-access"

threat_model:
  summary:
    fr: |
      Le plan de gestion out-of-band (BMC) confère un contrôle matériel total, indépendant et
      sous le système d'exploitation : montage de média virtuel, reconfiguration, et surtout
      écriture de firmware. C'est une cible de très haute valeur. L'appliance d'intégration est
      un point de passage privilégié car il relie le plan IT (gestionnaire de virtualisation,
      administrateurs) au plan de gestion matériel. Trois risques dominent. (1) Compromission de
      l'appliance via son interface exposée, puis pivot vers les BMC. (2) Interception des
      protocoles de gestion en clair hérités (CIM-HTTP, transfert de fichiers non chiffré) sur
      un réseau de gestion mal segmenté. (3) Chemin de mise à jour de firmware sur Internet
      détourné en vecteur de chaîne d'approvisionnement (paquet de firmware malveillant).
    en: |
      The out-of-band management plane (BMC) grants full hardware control, independent of and
      below the operating system: virtual media mounting, reconfiguration, and above all
      firmware writes. It is a very high-value target. The integration appliance is a key choke
      point because it bridges the IT plane (virtualization manager, administrators) and the
      hardware management plane. Three risks dominate. (1) Compromise of the appliance through
      its exposed interface, then pivot to the BMCs. (2) Interception of legacy clear-text
      management protocols (CIM-HTTP, unencrypted file transfer) on a poorly segmented
      management network. (3) The Internet firmware-update path hijacked into a supply-chain
      vector (malicious firmware package).
  attacker_goal:
    fr: |
      Obtenir un contrôle persistant sous le système d'exploitation en écrivant un firmware
      malveillant via le BMC, ou pivoter depuis l'appliance d'intégration vers le plan de
      gestion out-of-band pour prendre la main sur l'ensemble du parc de serveurs.
    en: |
      Gain persistent below-OS control by writing malicious firmware through the BMC, or pivot
      from the integration appliance into the out-of-band management plane to take over the
      entire server fleet.
  key_controls:
    - management_zone_segmentation   # Isoler le plan out-of-band des réseaux utilisateurs
    - ssl_inbound_inspection         # Inspecter le trafic entrant vers l'appliance
    - block_cleartext_management     # Bannir CIM-HTTP / transfert en clair au profit du chiffré
    - ssl_forward_proxy              # Inspecter le chemin de mise à jour de firmware Internet
    - firmware_sandboxing            # Détoner les paquets de firmware téléchargés
    - identity_user_group            # Restreindre l'accès admin au moindre privilège

# ─────────────────────────────────────────────────
# RULES — Scénario complet (entrée + sorties + dépendances + durcissement)
#  1. Entrant  : UI/API HTTPS vers l'appliance (admins + gestionnaire de virtualisation)
#  2. Interne  : appliance -> BMC, gestion chiffrée (Redfish/CIM-HTTPS + firmware)
#  3. Interne  : appliance -> BMC, sonde de liveness ICMP
#  4. Interne  : appliance -> BMC, découverte de service (SLP)
#  5. Interne  : appliance -> résolveur DNS (dépendance)
#  6. Sortant  : appliance -> service éditeur de firmware (Internet)
#  7. Drop     : durcissement — protocoles de gestion EN CLAIR hérités
# ─────────────────────────────────────────────────

rules:

  # ── Règle 1 : Entrant — UI web + API HTTPS vers l'appliance ─────────────────
  # Admins et gestionnaire de virtualisation accèdent à l'appliance en HTTPS (443).
  # L'appliance est un serveur que NOUS possédons : ssl_inbound_inspection permet
  # d'inspecter le trafic entrant déchiffré (exploits applicatifs, uploads malveillants).
  - application:
      app_id: infra_mgmt_web
      category: infrastructure
      default_ports:
        - tcp/443
      depends_on:
        - dns
      risk: 4

    identity:
      user_group:
        - "infrastructure_admins"
        - "virtualization_admins"
      device_posture: compliant

    zones:
      source:
        - trust
        - internal
        - management
      destination:
        - management

    direction: inbound

    service:
      protocol: tcp
      ports:
        - "443"
      app_default: true

    action: allow

    security_profiles:
      antivirus:
        action: block
      ips:
        action: block
        min_severity: medium
      url_filtering:
        # credential_phishing : empêche la soumission d'identifiants vers une page piégée.
        # Effectif grâce à ssl_inbound_inspection ci-dessous (trafic entrant déchiffré).
        credential_phishing: block

    decryption:
      mode: ssl_inbound_inspection
      exclusions: []

    logging:
      log_start: false
      log_end: true
      log_forwarding: true
      profile: "siem_high_priority"

    rationale:
      fr: |
        Cette règle autorise les administrateurs (postes conformes) et le gestionnaire de
        virtualisation à atteindre l'interface de l'appliance en HTTPS. L'appliance étant un
        serveur interne contrôlé, ssl_inbound_inspection déchiffre le trafic entrant pour
        détecter les exploits visant l'interface (T1190) et les fichiers malveillants déposés.
        L'accès est restreint par groupe annuaire (moindre privilège) et l'appliance reste dans
        la zone management. Le risque applicatif est élevé (risk 4) car compromettre l'appliance
        ouvre un pivot vers le plan de gestion matériel.
      en: |
        This rule allows administrators (compliant devices) and the virtualization manager to
        reach the appliance interface over HTTPS. Since the appliance is a controlled internal
        server, ssl_inbound_inspection decrypts inbound traffic to detect exploits targeting the
        interface (T1190) and malicious uploaded files. Access is restricted by directory group
        (least privilege) and the appliance stays in the management zone. Application risk is
        high (risk 4) because compromising the appliance opens a pivot into the hardware
        management plane.

  # ── Règle 2 : Interne — appliance -> BMC, gestion chiffrée ──────────────────
  # Pilotage des BMC : API de gestion chiffrée (Redfish sur 443, CIM-HTTPS sur 5989) et
  # transfert de firmware (6990). Flux confiné au sein de la zone management.
  # decryption: none + exclusion cert_pinned_app — on ne peut pas faire de MITM sur des
  # contrôleurs embarqués qui présentent des certificats d'équipement / TLS mutuel ; tenter
  # de les déchiffrer casse l'authentification du BMC. L'angle mort est documenté et accepté
  # car le flux est interne au plan de gestion segmenté.
  - application:
      app_id: bmc_management
      category: infrastructure
      default_ports:
        - tcp/443
        - tcp/5989
        - tcp/6990
      depends_on:
        - dns
      risk: 4

    zones:
      source:
        - management
      destination:
        - management

    direction: internal

    service:
      protocol: tcp
      ports:
        - "443"
        - "5989"
        - "6990"
      app_default: true

    action: allow

    security_profiles:
      # antivirus : inspection des paquets de firmware transférés vers le BMC (port 6990).
      antivirus:
        action: block
      # ips : détection d'exploits visant les services de gestion embarqués du BMC (T1210).
      ips:
        action: block
        min_severity: low
      # sandboxing : détonation des images de firmware avant application sur le matériel.
      sandboxing:
        enabled: true
        file_types:
          - "firmware_image"
          - "pe"

    decryption:
      mode: none
      exclusions:
        - cert_pinned_app

    logging:
      log_start: false
      log_end: true
      log_forwarding: true
      profile: "siem_high_priority"

    rationale:
      fr: |
        L'appliance pilote les BMC via une API de gestion chiffrée (Redfish/CIM-HTTPS) et
        transfère les images de firmware. Le déchiffrement est désactivé et documenté par
        l'exclusion cert_pinned_app : les contrôleurs embarqués valident des certificats
        d'équipement, et un proxy MITM romprait l'authentification du BMC. Le flux est confiné
        à la zone management segmentée, ce qui borne l'angle mort. L'antivirus et le sandboxing
        inspectent les images de firmware avant application (atténuation de T1542.001), et l'IPS
        couvre les exploits des services de gestion (T1210). Note opérationnelle : une sonde de
        liveness ICMP accompagne ces transferts (règle 3).
      en: |
        The appliance drives the BMCs through an encrypted management API (Redfish/CIM-HTTPS)
        and transfers firmware images. Decryption is disabled and documented via the
        cert_pinned_app exclusion: embedded controllers validate device certificates, and a MITM
        proxy would break BMC authentication. The flow is confined to the segmented management
        zone, which bounds the blind spot. Antivirus and sandboxing inspect firmware images
        before they are applied (mitigating T1542.001), and IPS covers management-service
        exploits (T1210). Operational note: an ICMP liveness probe accompanies these transfers
        (rule 3).

  # ── Règle 3 : Interne — appliance -> BMC, sonde de liveness ICMP ────────────
  # Vérification de connectivité (ping) pendant les mises à jour de firmware.
  - application:
      app_id: icmp_probe
      category: networking
      risk: 1

    zones:
      source:
        - management
      destination:
        - management

    direction: internal

    service:
      protocol: icmp

    action: allow

    security_profiles:
      # ips action: default — détection d'anomalies de protocole sur le flux ICMP
      # (atténue le tunneling ICMP depuis un hôte de gestion compromis).
      ips:
        action: default

    decryption:
      mode: none

    logging:
      log_end: true
      log_forwarding: true
      profile: "siem_default"

    rationale:
      fr: |
        L'appliance vérifie la disponibilité d'un BMC par ICMP avant et pendant une mise à jour
        de firmware. Le flux est interne au plan de gestion. Le profil IPS en mode default
        détecte les anomalies de protocole (ex. tunneling ICMP) sans bloquer la sonde légitime.
        Le déchiffrement est non applicable : ICMP n'est pas un flux chiffré.
      en: |
        The appliance checks a BMC's availability via ICMP before and during a firmware update.
        The flow is internal to the management plane. The IPS profile in default mode detects
        protocol anomalies (e.g. ICMP tunneling) without blocking the legitimate probe.
        Decryption is not applicable: ICMP is not an encrypted flow.

  # ── Règle 4 : Interne — appliance -> BMC, découverte de service (SLP) ───────
  # Découverte des BMC sur le réseau de gestion (Service Location Protocol, udp/427).
  - application:
      app_id: slp
      category: networking
      default_ports:
        - udp/427
      risk: 2

    zones:
      source:
        - management
      destination:
        - management

    direction: internal

    service:
      protocol: udp
      ports:
        - "427"
      app_default: true

    action: allow

    security_profiles:
      # ips action: default — SLP est un protocole de découverte amplifiable ; l'IPS
      # surveille les anomalies (abus en réflexion/amplification depuis le segment de gestion).
      ips:
        action: default

    decryption:
      mode: none

    logging:
      log_end: true
      log_forwarding: true
      profile: "siem_default"

    rationale:
      fr: |
        La découverte de service (SLP) permet à l'appliance de localiser les BMC sur le réseau
        de gestion. Le flux est confiné à la zone management. SLP étant un protocole amplifiable,
        l'IPS surveille les anomalies et les tentatives d'abus en réflexion. Le déchiffrement
        est non applicable : SLP sur UDP n'est pas chiffré.
      en: |
        Service discovery (SLP) lets the appliance locate BMCs on the management network. The
        flow is confined to the management zone. As SLP is an amplifiable protocol, IPS watches
        for anomalies and reflection-abuse attempts. Decryption is not applicable: SLP over UDP
        is not encrypted.

  # ── Règle 5 : Interne — dépendance DNS ──────────────────────────────────────
  # L'appliance résout les noms des BMC, du gestionnaire de virtualisation et du service éditeur.
  - application:
      app_id: dns
      category: networking
      default_ports:
        - udp/53
      risk: 2

    zones:
      source:
        - management
      destination:
        - internal

    direction: internal

    service:
      protocol: udp
      ports:
        - "53"
      app_default: true

    action: allow

    security_profiles:
      dns_security:
        action: block
        sinkhole: true

    decryption:
      mode: none

    logging:
      log_end: true
      log_forwarding: true
      profile: "siem_default"

    rationale:
      fr: |
        La résolution DNS est requise pour joindre les BMC, le gestionnaire de virtualisation et
        le service éditeur de firmware. Le flux est restreint vers un résolveur interne contrôlé
        (pas de résolution directe vers Internet). Le profil dns_security avec sinkhole atténue
        le tunneling DNS depuis un hôte de gestion compromis. Le déchiffrement est non
        applicable : DNS sur UDP n'est pas chiffré.
      en: |
        DNS resolution is required to reach the BMCs, the virtualization manager and the vendor
        firmware service. The flow is restricted to a controlled internal resolver (no direct
        Internet resolution). The dns_security profile with sinkhole mitigates DNS tunneling from
        a compromised management host. Decryption is not applicable: DNS over UDP is not
        encrypted.

  # ── Règle 6 : Sortant — appliance -> service éditeur de firmware (Internet) ─
  # Téléchargement des paquets de firmware/mises à jour. SEUL flux sortant vers Internet :
  # c'est un vecteur de chaîne d'approvisionnement. ssl_forward_proxy OBLIGATOIRE pour
  # inspecter le contenu (antivirus, sandboxing). La liste d'autorisation des domaines de
  # l'éditeur est SPÉCIFIQUE AU DÉPLOIEMENT et n'est pas encodée ici (invariant 3 : pas de
  # marque) — elle est gérée via allow_list au moment du déploiement.
  - application:
      app_id: firmware_update
      category: infrastructure
      default_ports:
        - tcp/443
      depends_on:
        - dns
        - ssl
      risk: 3

    zones:
      source:
        - management
      destination:
        - internet

    direction: outbound

    service:
      protocol: tcp
      ports:
        - "443"
      app_default: true

    action: allow

    security_profiles:
      antivirus:
        action: block
      ips:
        action: block
        min_severity: low
      url_filtering:
        block_categories:
          - malware
          - phishing
          - c2
          - newly_registered_domain
          - compromised
        uncategorized_action: block
        # credential_phishing : effectif grâce au ssl_forward_proxy ci-dessous (sinon LNT-004).
        credential_phishing: block
      sandboxing:
        enabled: true
        file_types:
          - "firmware_image"
          - "pe"
          - "archive"
      dns_security:
        action: block
        sinkhole: true

    decryption:
      mode: ssl_forward_proxy
      exclusions: []

    logging:
      log_start: false
      log_end: true
      log_forwarding: true
      profile: "siem_high_priority"

    rationale:
      fr: |
        L'appliance télécharge des paquets de firmware depuis un service éditeur sur Internet.
        C'est l'unique flux sortant vers Internet et un vecteur de chaîne d'approvisionnement :
        ssl_forward_proxy est obligatoire pour que l'antivirus et le sandboxing inspectent le
        contenu (atténuation de T1542.001 — firmware malveillant). url_filtering bloque les
        catégories à risque et les sites non catégorisés (durcissement). La liste blanche des
        domaines de l'éditeur reste spécifique au déploiement : les domaines documentés par la
        source figurent en provenance (references[].endpoints / section Sources), à reporter en
        url_filtering.allow_list au déploiement — sans coder de marque dans la règle. Le risque
        applicatif est moyen (risk 3) : flux sortant légitime mais sensible.
      en: |
        The appliance downloads firmware packages from a vendor service on the Internet. This is
        the only outbound Internet flow and a supply-chain vector: ssl_forward_proxy is mandatory
        so antivirus and sandboxing can inspect the content (mitigating T1542.001 — malicious
        firmware). url_filtering blocks risky categories and uncategorized sites (hardening). The
        vendor's domain allow-list remains deployment-specific: the domains documented by the
        source are recorded as provenance (references[].endpoints / Sources section), to be set in
        url_filtering.allow_list at deployment — without hardcoding a brand into the rule.
        Application risk is medium (risk 3): a legitimate but sensitive outbound flow.

  # ── Règle 7 : Drop — protocoles de gestion EN CLAIR hérités (durcissement) ──
  # CIM-HTTP (5988) et transfert de fichiers en clair (115) sont des protocoles de gestion
  # hérités non chiffrés, vulnérables à l'interception (T1557). On les bloque au profit de
  # leurs équivalents chiffrés (CIM-HTTPS 5989, gestion sur 443 — règle 2).
  # L'absence de security_profiles est correcte sur action=drop (rien à inspecter).
  - application:
      app_id: clear_text_mgmt
      category: infrastructure
      default_ports:
        - tcp/5988
        - tcp/115
      risk: 4

    zones:
      source:
        - management
      destination:
        - management

    direction: internal

    service:
      protocol: tcp
      ports:
        - "5988"
        - "115"

    action: drop

    logging:
      log_start: true
      log_end: true
      log_forwarding: true
      profile: "siem_high_priority"

    rationale:
      fr: |
        Durcissement : les protocoles de gestion en clair hérités (CIM-HTTP sur 5988, transfert
        de fichiers non chiffré sur 115) sont bloqués silencieusement. Ils sont interceptables
        sur un réseau de gestion mal segmenté (T1557 — vol d'identifiants et altération en vol)
        et doivent être remplacés par leurs équivalents chiffrés (CIM-HTTPS 5989, gestion sur
        443 — règle 2). Le log en haute priorité signale toute tentative d'usage, indice de
        matériel hérité mal configuré ou de tentative de contournement. La protection par
        gestion out-of-band en clair (IPMI hérité sur udp/623) relève de la même posture et doit
        être confinée puis éliminée.
      en: |
        Hardening: legacy clear-text management protocols (CIM-HTTP on 5988, unencrypted file
        transfer on 115) are silently dropped. They can be intercepted on a poorly segmented
        management network (T1557 — credential theft and in-flight tampering) and must be
        replaced by their encrypted equivalents (CIM-HTTPS 5989, management on 443 — rule 2).
        High-priority logging flags any usage attempt, a sign of misconfigured legacy hardware or
        a bypass attempt. Legacy clear-text out-of-band management (legacy IPMI on udp/623) falls
        under the same posture and must be confined then eliminated.
