Collecter les journaux BeyondTrust Secure Remote Access

Compatible avec :

Ce document explique comment collecter les journaux BeyondTrust Secure Remote Access à l'aide de Bindplane. L'analyseur gère deux formats syslog. Le premier format utilise des paires clé-valeur dans un message structuré, tandis que le second utilise des champs délimités par des barres verticales. L'analyseur extrait les champs pertinents des deux formats et les mappe à l'UDM. Il catégorise également les types d'événements en fonction des mots clés extraits et gère une logique spécifique pour les événements de connexion/déconnexion et les types d'authentification.

Avant de commencer

  • Assurez-vous de disposer d'une instance Google Security Operations.
  • Assurez-vous d'utiliser Windows 2016 ou une version ultérieure, ou un hôte Linux avec systemd.
  • Si vous exécutez le programme derrière un proxy, assurez-vous que les ports du pare-feu sont ouverts.
  • Assurez-vous de disposer d'un accès privilégié à un accès à distance sécurisé BeyondTrust.

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

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

  1. Accédez au fichier de configuration :

    1. 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.
    2. 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:
        udplog:
            # 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: BEYONDTRUST_REMOTE_ACCESS
                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 l'assistance à distance BeyondTrust

  1. Connectez-vous à l'interface utilisateur Web BeyondTrust.
  2. Sélectionnez Appliance > Sécurité > Administration de l'appliance.
  3. Dans la section Syslog, procédez comme suit :
    • Format du message : sélectionnez Ancien format BSD.
    • Serveur syslog distant : saisissez l'adresse IP et le port Bindplane.
  4. Cliquez sur Envoyer.

Table de mappage UDM

Champ de journal Mappage UDM Logique
datetime metadata.event_timestamp L'horodatage est analysé à partir du champ datetime au format RFC3 339 si le champ when n'est pas présent.
deviceHost target.hostname La valeur de deviceHost est directement mappée à target.hostname.
dstHost target.ip La valeur de dstHost est directement mappée sur target.ip après avoir été validée en tant qu'adresse IP valide.
dstPriv additional.fields.[key=dstPriv].value.string_value La valeur de dstPriv est placée dans le champ additional avec la clé dstPriv.
dstUid target.user.userid La valeur de dstUid est directement mappée à target.user.userid.
dstUser target.user.user_display_name La valeur de dstUser est directement mappée à target.user.user_display_name.
eventName metadata.event_type Si eventName est défini sur login (non sensible à la casse), metadata.event_type est défini sur USER_LOGIN. Si eventName est défini sur logout (non sensible à la casse), metadata.event_type est défini sur USER_LOGOUT. Sinon, si eventName n'est pas vide, metadata.event_type est défini sur USER_UNCATEGORIZED. Si eventName est vide et que le message correspond au deuxième modèle grok, metadata.event_type est défini sur GENERIC_EVENT. Si eventName est vide et que le message correspond au premier modèle Grok, metadata.event_type est défini sur GENERIC_EVENT. Si srcUid, userid ou who ne sont pas vides, metadata.event_type est défini sur USER_CHANGE_PERMISSIONS. Si deviceHost ou site ne sont pas vides, metadata.event_type est défini sur USER_UNCATEGORIZED. Sinon, metadata.event_type est défini sur GENERIC_EVENT.
event_name additional.fields.[key=event_name].value.string_value La valeur de event_name est placée dans le champ additional avec la clé event_name.
event_name metadata.product_event_type La valeur de event_name est utilisée conjointement avec le champ id pour renseigner metadata.product_event_type au format [id] -event_name``.
externalKeyLabel additional.fields.[key=externalKeyLabel].value.string_value La valeur de externalKeyLabel est placée dans le champ additional avec la clé externalKeyLabel.
id metadata.product_event_type La valeur de id est utilisée conjointement avec le champ event_name pour renseigner metadata.product_event_type au format [id] -event_name``.
jumpGroupId additional.fields.[key=jumpGroupId].value.string_value La valeur de jumpGroupId est placée dans le champ additional avec la clé jumpGroupId.
jumpGroupName additional.fields.[key=jumpGroupName].value.string_value La valeur de jumpGroupName est placée dans le champ additional avec la clé jumpGroupName.
jumpGroupType additional.fields.[key=jumpGroupType].value.string_value La valeur de jumpGroupType est placée dans le champ additional avec la clé jumpGroupType.
jumpointId additional.fields.[key=jumpointId].value.string_value La valeur de jumpointId est placée dans le champ additional avec la clé jumpointId.
jumpointName additional.fields.[key=jumpointName].value.string_value La valeur de jumpointName est placée dans le champ additional avec la clé jumpointName.
kv_data Différents champs UDM Le champ kv_data est analysé en paires clé/valeur, qui sont ensuite mappées à différents champs UDM en fonction de leurs clés (par exemple, eventName, when, who, who_ip, site, target, status, reason).
kvdata Différents champs UDM Le champ kvdata est analysé en paires clé/valeur, qui sont ensuite mappées à différents champs UDM en fonction de leurs clés (par exemple, msg, srcUser, srcUid, srcHost, dstUser, dstUid, dstHost, sessionId, jumpointId, jumpointName, jumpGroupId, jumpGroupName, jumpGroupType, externalKeyLabel, dstPriv).
message Différents champs UDM Le champ message est analysé à l'aide de modèles Grok pour extraire différents champs, qui sont ensuite mappés aux champs UDM.
msg metadata.description La valeur de msg est directement mappée à metadata.description.
product_event_type metadata.product_event_type La valeur de product_event_type est directement mappée à metadata.product_event_type.
product_log_id metadata.product_log_id La valeur de product_log_id est directement mappée à metadata.product_log_id.
process_id principal.process.pid La valeur de process_id est directement mappée à principal.process.pid.
reason security_result.description La valeur de reason est directement mappée à security_result.description.
segment_number additional.fields.[key=segment_number].value.string_value La valeur de segment_number est placée dans le champ additional avec la clé segment_number.
sessionId network.session_id La valeur de sessionId est directement mappée à network.session_id.
site target.hostname La valeur de site est directement mappée à target.hostname.
site_id additional.fields.[key=site_id].value.string_value La valeur de site_id est placée dans le champ additional avec la clé site_id.
srcHost principal.ip La valeur de srcHost est directement mappée sur principal.ip après avoir été validée en tant qu'adresse IP valide.
srcUid principal.user.userid La valeur de srcUid est directement mappée à principal.user.userid.
srcUser principal.user.user_display_name La valeur de srcUser est directement mappée à principal.user.user_display_name.
status security_result.action Si status est défini sur failure (non sensible à la casse), security_result.action est défini sur BLOCK. Sinon, security_result.action est défini sur ALLOW.
status security_result.action_details La valeur de status est directement mappée à security_result.action_details.
target target.application La valeur de target est directement mappée à target.application. rep_client est remplacé par Representative Console et web/login est remplacé par Web/Login.
target extensions.auth.type Si target est défini sur rep_client, extensions.auth.type est défini sur MACHINE. Si target est défini sur web/login, extensions.auth.type est défini sur SSO. Sinon, extensions.auth.type est défini sur AUTHTYPE_UNSPECIFIED.
timestamp metadata.event_timestamp Le timestamp du journal brut est utilisé comme solution de secours si ni datetime ni when ne sont présents.
total_segments additional.fields.[key=total_segments].value.string_value La valeur de total_segments est placée dans le champ additional avec la clé total_segments.
device_product additional.fields.[key=device_product].value.string_value La valeur de device_product est placée dans le champ additional avec la clé device_product.
device_vendor additional.fields.[key=device_vendor].value.string_value La valeur de device_vendor est placée dans le champ additional avec la clé device_vendor.
device_version metadata.product_version La valeur de device_version est directement mappée à metadata.product_version.
when metadata.event_timestamp L'horodatage est analysé à partir du champ when au format UNIX, le cas échéant.
who principal.user.userid Si le champ who correspond au modèle d'expression régulière, le userid extrait est mappé sur principal.user.userid. Sinon, l'intégralité du champ who est mappée sur principal.user.userid.
who principal.user.user_display_name Si le champ who correspond au modèle d'expression régulière, le user_display_name extrait est mappé sur principal.user.user_display_name.
who_ip principal.ip La valeur de who_ip est directement mappée à principal.ip.
(Logique de l'analyseur) metadata.log_type Le type de journal est défini sur BEYONDTRUST_REMOTE_ACCESS.
(Logique de l'analyseur) metadata.product_name Le nom du produit est défini sur BeyondTrust Secure Remote Access.
(Logique de l'analyseur) metadata.vendor_name Le nom du fournisseur est défini sur BeyondTrust.
(Logique de l'analyseur) security_result.summary La valeur est dérivée à l'aide du format User %{eventName}.
(Logique de l'analyseur) extensions.auth.mechanism Si method contient using password, le mécanisme est défini sur USERNAME_PASSWORD. Si method contient using elevate, le mécanisme est défini sur REMOTE.

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