Collecter les journaux Avaya Aura

Compatible avec :

Ce document explique comment ingérer les journaux Avaya Aura dans Google Security Operations à l'aide de Bindplane. L'analyseur extrait d'abord les champs des messages syslog Avaya Aura bruts à l'aide d'expressions régulières et du filtre "grok". Il mappe ensuite les champs extraits à un modèle de données unifié (UDM), normalise les valeurs telles que la gravité et identifie des types d'événements spécifiques tels que la connexion ou la déconnexion d'un utilisateur en fonction de mots clés.

Avant de commencer

Assurez-vous de remplir les conditions suivantes :

  • Instance Google SecOps
  • Windows 2016 ou version ultérieure, ou un hôte Linux avec systemd
  • Si vous exécutez le programme derrière un proxy, les ports du pare-feu sont ouverts.
  • Accès privilégié à Avaya Aura

Obtenir le fichier d'authentification d'ingestion Google SecOps

  1. Connectez-vous à la console Google SecOps.
  2. Accédez à Paramètres du SIEM > Agents de collecte.
  3. Téléchargez le fichier d'authentification d'ingestion. Enregistrez le fichier de manière sécurisée sur le système sur lequel Bindplane sera installé.

Obtenir l'ID client Google SecOps

  1. Connectez-vous à la console Google SecOps.
  2. Accédez à Paramètres SIEM> Profil.
  3. Copiez et enregistrez le numéro client de la section Informations sur l'organisation.

Installer l'agent Bindplane

Installation de fenêtres

  1. Ouvrez l'invite de commandes ou PowerShell en tant qu'administrateur.

  2. Exécutez la commande suivante :

    msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

Installation de Linux

  1. Ouvrez un terminal avec les droits root ou sudo.

  2. Exécutez la commande suivante :

    sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

Ressources d'installation supplémentaires

Pour plus d'options d'installation, consultez le guide d'installation.

Configurer l'agent Bindplane pour ingérer Syslog et l'envoyer à Google SecOps

  1. Accédez au fichier de configuration :
    • Recherchez le fichier config.yaml. En règle générale, il se trouve dans le répertoire /etc/bindplane-agent/ sous Linux ou dans le répertoire d'installation sous Windows.
    • Ouvrez le fichier à l'aide d'un éditeur de texte (par exemple, nano, vi ou le Bloc-notes).

  2. Modifiez le fichier config.yaml comme suit :

    receivers:
    udolog:
        # Replace the port and IP address as required
        listen_address: "0.0.0.0:514"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        # Adjust the path to the credentials file you downloaded in Step 1
        creds: '/path/to/ingestion-authentication-file.json'
        # Replace with your actual customer ID from Step 2
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        # Add optional ingestion labels for better organization
        ingestion_labels:
            log_type: 'AVAYA_AURA'
            raw_log_field: body

service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - udplog
            exporters:
                - chronicle/chronicle_w_labels

  3. Remplacez le port et l'adresse IP selon les besoins de votre infrastructure.

  4. Remplacez <customer_id> par le numéro client réel.

  5. Mettez à jour /path/to/ingestion-authentication-file.json en indiquant le chemin d'accès où le fichier d'authentification a été enregistré dans la section Obtenir le fichier d'authentification pour l'ingestion Google SecOps.

Redémarrez l'agent Bindplane pour appliquer les modifications.

  • Pour redémarrer l'agent Bindplane sous Linux, exécutez la commande suivante :

    sudo systemctl restart bindplane-agent

  • Pour redémarrer l'agent Bindplane sous Windows, vous pouvez utiliser la console Services ou saisir la commande suivante :

    net stop BindPlaneAgent && net start BindPlaneAgent

Configurer Syslog dans Avaya Aura

  1. Connectez-vous à la console Avaya Aura.
  2. Accédez à EM> Configuration du système> Paramètres de journalisation> Syslog.
  3. Activez l'option SYSLOG Delivery of Logs (Envoi des journaux SYSLOG).
  4. Cliquez sur Ajouter.
  5. Fournissez les informations de configuration suivantes :
    • Adresse du serveur : saisissez l'adresse IP de l'agent Bindplane.
    • Port : saisissez le port d'écoute de l'agent Bindplane.
  6. Cliquez sur Enregistrer.
  7. Cliquez sur Confirmer.
  8. Redémarrez Avaya Aura.

Table de mappage UDM

Champ du journal Mappage UDM Logique
data{}.@timestamp metadata.event_timestamp L'horodatage de l'événement est analysé à partir du champ de données à l'aide du modèle Grok et attribué au champ "event_timestamp" dans la section des métadonnées de l'UDM.
data{}.host principal.hostname La valeur de l'hôte est extraite du champ de données à l'aide du modèle Grok et attribuée au champ "hostname" (nom d'hôte) dans la section "principal" de l'UDM.
data{}.portal security_result.about.resource.attribute.labels.value La valeur du portail est extraite du champ de données à l'aide du modèle Grok et attribuée en tant que valeur du libellé Portal dans la section about.resource.attribute.labels de security_result dans l'UDM.
data{}.prod_log_id metadata.product_log_id La valeur prod_log_id est extraite du champ de données à l'aide du modèle Grok et attribuée au champ product_log_id dans la section des métadonnées de l'UDM.
data{}.sec_cat security_result.category_details La valeur sec_cat est extraite du champ de données à l'aide du modèle grok et attribuée au champ category_details dans la section security_result de l'UDM.
data{}.sec_desc security_result.description La valeur sec_desc est extraite du champ de données à l'aide du modèle grok et attribuée au champ de description dans la section security_result de l'UDM.
data{}.severity security_result.severity La valeur de gravité est extraite du champ de données à l'aide du modèle Grok. Si la gravité est warn, fatal ou error (sans tenir compte de la casse), elle est mappée sur HIGH dans le champ security_result.severity de l'UDM. Sinon, si le niveau de gravité est info (non sensible à la casse), il est mappé sur LOW.
data{}.summary security_result.summary La valeur récapitulative est extraite du champ de données à l'aide du modèle Grok et attribuée au champ récapitulatif de la section "security_result" de l'UDM.
data{}.user_id target.user.userid La valeur user_id est extraite du champ de données à l'aide du modèle grok et attribuée au champ userid dans la section target.user de l'UDM.
extensions.auth.type Le champ auth.type est défini sur AUTHTYPE_UNSPECIFIED si le champ event_name contient log(in|on) ou logoff (sans tenir compte de la casse), ou si le champ summary contient login ou logoff (sans tenir compte de la casse) et que le champ user_id n'est pas vide.
metadata.description Le champ "description" est renseigné avec la valeur du champ "desc" s'il n'est pas vide.
metadata.event_type Le champ "event_type" est déterminé selon la logique suivante : - Si le champ "event_name" contient log(in|on) ou si le champ "summary" contient login (sans tenir compte de la casse) et que le champ "user_id" n'est pas vide, le champ "event_type" est défini sur USER_LOGIN. - Si le champ event_name contient logoff ou si le champ summary contient logoff (sans tenir compte de la casse) et que le champ user_id n'est pas vide, event_type est défini sur USER_LOGOUT. - Si le champ has_principal est défini sur true, event_type est défini sur STATUS_UPDATE. - Sinon, event_type reste défini sur GENERIC_EVENT (valeur par défaut).
metadata.log_type Le log_type est codé en dur sur AVAYA_AURA.
metadata.product_event_type Le champ product_event_type est renseigné avec la valeur du champ event_name s'il n'est pas vide.
metadata.product_name Le product_name est codé en dur sur AVAYA AURA.
metadata.vendor_name Le vendor_name est codé en dur sur AVAYA AURA.
security_result.action Le champ "action" de la section "security_result" est défini selon la logique suivante : - Si le champ "summary" contient fail ou failed (sans tenir compte de la casse), l'action est définie sur BLOCK. - Si le champ "summary" contient success (non sensible à la casse), l'action est définie sur ALLOW.
security_result.severity_details Le champ "severity_details" est renseigné avec la valeur du champ "severity_details" s'il n'est pas vide.
timestamp.nanos metadata.event_timestamp.nanos La valeur en nanosecondes du champ d'horodatage est directement mappée au champ en nanosecondes de la section "event_timestamp" des métadonnées dans l'UDM.
timestamp.seconds metadata.event_timestamp.seconds La valeur en secondes du champ d'horodatage est directement mappée au champ des secondes dans la section event_timestamp des métadonnées de l'UDM.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.