Ce document explique comment configurer le plugin Amazon Security Lake v2.0.0 dans la plateforme Cloud Exchange. Ce plugin récupère les alertes (DLP (Prévention des pertes de données), Malware, Policy, Compromised Credential, Malsite, Quarantaine, Remediation, Security Assessment, Watchlist, UBA, CTEP, périphérique et Content), les événements (Page, Application, Audit, Infrastructure, Network, Incident, Endpoint et Client Status) et les journaux WebTx [via Netskope LogStreaming]. Les données seront ingérées dans le seau Amazon Security Lake Custom Source. Ce plugin ne prend pas en charge l'ingestion de données au format JSON brut.
Note
Pour l'authentification IAM Roles Anywhere, nous avons validé ce plugin avec un seul compte AWS.
Conditions préalables
Pour compléter cette configuration, vous avez besoin de :
- Un locataire Netskope (ou plusieurs, par exemple des instances de production et de développement/test).
- Un locataire Netskope Cloud Exchange avec le plugin Tenant et le plugin Log Shipper déjà configurés.
- Un locataire Netskope Cloud Exchange avec le plugin AWS Netskope LogStreaming ou Azure Netskope LogStreaming déjà configuré.
- Un compte AWS activé par Amazon Security Lake.
- Godet S3 généré automatiquement pour Amazon Security Lake
- Références :
https://docs.aws.amazon.com/security-lake/latest/userguide/
https://aws.amazon.com/security-lake
- Accès à AWS Athena, AWS Glue, AWS Lake formation, Creating Policy and Role on AWS.
Prise en charge du plugin Amazon Security Lake
Ce plugin prend en charge l'ingestion d'alertes, d'événements et de journaux WebTx. Les données seront ingérées dans le seau Amazon Security Lake Custom Source. Ce plugin ne prend pas en charge l'ingestion de données au format JSON brut.
| Type de données | Support |
|---|---|
| Événements | Oui (Page, Application, Audit, Infrastructure, Réseau, Point final, Incident et Statut du client) |
| Alertes | Oui (DLP (Prévention des pertes de données), Malware, Policy, Compromised Credential, Malsite, Quarantine, Remediation, Security Assessment, Watchlist, UBA, CTEP, périphérique et Content) |
| WebTx | Oui (via Netskope LogStreaming) |
Note :
- CLS WebTX basé sur Google Pub Sub Lite est obsolète. Veuillez vous référer aux annonces EOL/EOS des produits Netskope - Netskope Knowledge Portal
- Pour ingérer les logs WebTX vers vos destinations de livraison de logs comme SIEM, SOAR, XDR, données Lake, utilisez le plugin AWS Netskope LogStreaming ou Azure Netskope LogStreaming.
Matrice de performance
Cette mesure de performance concerne une pile Large Cloud Exchange avec ces spécifications de VM.
| Description | Spécifications |
|---|---|
| Taille de la pile | Grandes dimensions RAM : 32 GB Cœur : 16 |
| Alerts/Events | ~ 50k EPM |
Remarque : Chaque donnée brute a une taille moyenne de 2 Ko.
Mises en correspondance
OCSF Class Mappings pour le fichier de correspondance par défaut
Le tableau suivant décrit les mappages de classes OCSF pour le fichier de mappage par défaut appliqué aux types Alert, Event et WebTx de Netskope lorsque les données sont ingérées à partir d'un locataire Netskope.
Remarque : le fichier de mappage par défaut utilisera OCSF v1.3.0
Note
Dans le fichier de mappage par défaut, raw_data n'est pas mappé pour toutes les alertes, tous les événements et toutes les transactions Web. Si un utilisateur souhaite envoyer des alertes/événements/transactions Web brutes, il doit créer un mappage personnalisé avec le champ raw_data mappé sur la valeur par défaut « raw_data » pour chaque type d'alerte/événement/transaction Web. Voici un exemple où les informations d'identification compromises ont un champ raw_data mappé avec la valeur par défaut « raw_data » :
Correspondance des types de données
Voici la méthodologie suivie pour la mise en correspondance des champs Netskope avec les champs OCSF, ainsi que les transformations correspondantes utilisées. Si des champs New doivent être ajoutés, ils peuvent être utilisés de la même manière pour des raisons de cohérence.
| Exemples de champs Netskope | Transformation | Type de champ OCSF prévu | Example Values |
|---|---|---|---|
| Valeurs avec chaînes de caractères, par exemple chemins d'accès aux fichiers, noms de domaine, UUID, descriptions, commentaires et objets complexes imbriqués | String | string_t | “\\printserver\\printer”,5182808a2a99fc688d4a8057,”{\”access_method\”: \"Connecteur API", "Type de compte" : \"SAML" }" |
| Valeurs avec date, par exemple src_time, last_event_timestamp, last_update_timestamp | Horodatage | timestamp_t (Entier) | 1768804071000 |
| Valeurs avec des nombres entiers. Par exemple le port, le seuil, le nombre d'événements ou l'identifiant de la transaction | Integer | integer_t | 404, 27017 |
| Values requiring precision, For e.g. src_latitude, src_longitude | Point flottant | float_t | -3.6029212e+24,2.77645e+23 |
Configuration sur AWS lors de l'utilisation de mappages personnalisés
Security Lake attend un schéma de parquet cohérent pour tous les fichiers téléchargés sur S3. Cela permet de s'assurer que les Glue Crawlers sont en mesure de déduire sans erreur les schémas des tables à partir des fichiers Parquet.
Si vous utilisez un mappage personnalisé ou si vous mettez à jour le schéma de mappage fourni alors que des parquets ont déjà été téléchargés, il est possible que le schéma des fichiers ne soit plus cohérent. Cela signifie que des colonnes existant dans certains fichiers n'existent pas dans d'autres, ou que certains fichiers contiennent des colonnes supplémentaires. Lorsque vous interrogez de telles partitions dans Athena, vous risquez de rencontrer des erreurs HIVE_PARTITION_SCHEMA_MISMATCH. Veillez à modifier les Glue Crawlers avant de passer à une cartographie personnalisée afin d'éviter ces erreurs. Cette mise à jour doit être effectuée pour les Crawlers de chaque type d'événement/alert/webtx qui ont des schémas différents entre les fichiers parquet :
- Pour modifier le Crawler, allez sur Set Output and Scheduling > Advanced Options.
- Lorsque le robot d'exploration détecte des modifications de schéma dans le magasin de données, comment AWS Glue doit-il gérer les mises à jour de table dans le catalogue de données ?, sélectionnez Add new columns only.
- Activez la case à cocher pour Mettre à jour toutes les New et les partitions existantes avec les métadonnées de la table.
- Cliquez sur Next > Update.
Détails de l'API
Library: Le SDK AWS pour Python (Boto3)
Utilisation : Le SDK AWS pour Python (Boto3) pour créer, configurer et gérer les services AWS, tels que Amazon Security Lake, Amazon Simple Storage Service (Amazon S3) et Amazon Security Token Service (STS). Le SDK fournit une API orientée objet ainsi qu'un accès de bas niveau aux services AWS.
Le plugin utilise le SDK pour effectuer des actions telles que lister les sources de journaux personnalisées, créer des sources de journaux personnalisées dans le lac de sécurité, assumer le rôle de fournisseur qui permet le téléchargement vers S3, puis télécharger des fichiers de parquet vers S3.
Création d'un client Security Lake
securitylake_client = boto3.client(
"securitylake",
aws_access_key_id=self.aws_public_key,
aws_secret_access_key=self.aws_private_key,
aws_session_token=self.aws_session_token,
region_name=self.configuration.get("region_name").strip(),
config=Config(
proxies=self.proxy,
user_agent=USER_AGENT,
read_timeout=READ_TIMEOUT,
retries={"max_attempts": MAX_RETRIES, "mode": "standard"},
),
)
Utilisation du client Security Lake pour lister/créer des sources de logs personnalisées
securitylake_client.list_log_sources() securitylake_client.create_custom_log_source(**request_params)
Création d'un client STS
sts_client = boto3.client(
"sts",
aws_access_key_id=self.aws_public_key,
aws_secret_access_key=self.aws_private_key,
aws_session_token=self.aws_session_token,
region_name=self.configuration.get("region_name").strip(),
config=Config(
proxies=self.proxy,
user_agent=USER_AGENT,
read_timeout=READ_TIMEOUT,
retries={"max_attempts": MAX_RETRIES, "mode": "standard"},
),
)
Utilisation du client STS pour assumer un rôle de fournisseur
response = sts_client.assume_role(
RoleArn=role_arn,
RoleSessionName=role_session_name,
ExternalId=external_id,
DurationSeconds=ASSUMED_ROLE_DURATION_SECONDS,
)
Création d'un client S3
s3_client = boto3.client(
"s3",
aws_access_key_id=self.aws_public_key,
aws_secret_access_key=self.aws_private_key,
aws_session_token=self.aws_session_token,
region_name=self.configuration.get("region_name").strip(),
config=Config(
proxies=self.proxy,
user_agent=USER_AGENT,
read_timeout=READ_TIMEOUT,
retries={"max_attempts": MAX_RETRIES, "mode": "standard"},
),
)
Utilisation d'un client S3 pour télécharger des fichiers
s3_client.upload_file(file_path, bucket_name, s3_key)
Applicable uniquement pour les rôles IAM Anywhere
Création d'un client IAM
iam_client = boto3.client(
"iam",
aws_access_key_id=self.aws_public_key,
aws_secret_access_key=self.aws_private_key,
aws_session_token=self.aws_session_token,
region_name=self.configuration.get("region_name").strip(),
config=Config(
proxies=self.proxy,
user_agent=USER_AGENT,
read_timeout=READ_TIMEOUT,
retries={"max_attempts": MAX_RETRIES, "mode": "standard"},
),
)
Mise à jour de la politique de confiance du rôle de fournisseur
role = iam_client.get_role(RoleName=role_name) iam_client.update_assume_role_policy(RoleName=role_name, PolicyDocument=json.dumps(trust_policy))
Agent utilisateur
APN/1.1 (ahq9d89xj9gspapczzdb59goq)
Workflow
- Configuration sur AWS.
- Configurez le plugin CLS Amazon Security Lake.
- Configurez une règle métier pour AWS Security Lake.
- Ajoutez une configuration de livraison de logs pour AWS Security Lake.
- Validez le plugin AWS Security Lake.
Regardez une vidéo
Cliquer sur « play » pour regarder une vidéo.
Configurer AWS
Utiliser la méthode d'authentification du plugin AWS
Créer une politique
- Allez à IAM > Policies et cliquez sur Create policy.
- Ajoutez ces autorisations au format JSON.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "SecurityLakePerms", "Effect": "Allow", "Action": [ "securitylake:CreateCustomLogSource", "securitylake:ListLogSources", "securitylake:GetDataLakeSources", "securitylake:ListDataLakes" ], "Resource": "*" }, { "Sid": "LakeFormationPerms", "Effect": "Allow", "Action": [ "lakeformation:RegisterResource", "lakeformation:GrantPermissions", "lakeformation:GetDataLakeSettings" ], "Resource": "*" }, { "Sid": "GluePerms", "Effect": "Allow", "Action": [ "glue:CreateTable", "glue:CreateDatabase", "glue:CreateCrawler", "glue:UpdateCrawler", "glue:UpdateDatabase", "glue:UpdateTable", "glue:StartCrawlerSchedule", "glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables", "glue:GetTableVersion", "glue:GetTableVersions", "glue:GetPartition", "glue:GetPartitions" ], "Resource": "*" }, { "Sid": "AllowAssumeSecurityLakeProviderRole", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession" ], "Resource": [ "arn:aws:iam::[aws-account-id]:role/AmazonSecurityLake-Provider-*" ] }, { "Sid": "AllowPassAndReadRoleForCrawler", "Effect": "Allow", "Action": [ "iam:PassRole", "iam:GetRole", "iam:CreateRole", "iam:PutRolePolicy", "iam:ListRolePolicies", "iam:DeleteRole", "iam:DeleteRolePolicy" ], "Resource": "*" }, { "Sid": "S3Perms", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:PutObject", "s3:CreateBucket", "s3:ListAllMyBuckets", "s3:GetBucketLocation", "s3:GetBucketPolicy" ], "Resource": "*" } ] }Note
Veillez à remplacer l'identifiant du compte AWS dans la politique ci-dessus avant de l'utiliser.
- Saisissez un nom de politique.
- Cliquez sur Create Policy.
Créer un rôle
- Allez à IAM > Roles et cliquez sur Create role.
- Select le AWS Service.
- Sous Cas d'utilisation, sélectionnez EC2.
- Cliquez sur Next.
- Select la politique d'autorisation créée dans Créer une politique.
- Cliquez sur Next.
- Saisissez un nom de rôle et une description, comme Netskope-ce-instance-role.
- Cliquez sur Create Role.
Attribuer un rôle à l'instance EC2
- Ouvrez la console de votre instance EC2.
- Cliquez sur Instances sous Instances.
- Pour votre instance EC2 (où Cloud Exchange est déployé), accédez à Action > Security > Modify IAM Role.
- Select le rôle que vous avez créé ci-dessus dans Créer un rôle (Netskope-ce-instance-role).
- Cliquez Add IAM role > Modify IAM Role et cliquez Update IAM Role.
Créer l'ARN du rôle de crawler
- Rendez-vous sur IAM > Policies et créez une stratégie en utilisant les autorisations suivantes :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "GlueCrawlerListBucket", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:ListBucketVersions", "s3:ListBucketMultipartUploads", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::aws-security-data-lake-us-east-1-*" }, { "Sid": "GlueCrawlerReadObjects", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectVersion", "s3:GetObjectTagging", "s3:ListMultipartUploadParts" ], "Resource": "arn:aws:s3:::aws-security-data-lake-us-east-1-*/*" } ] }
- Saisissez un nom de politique et cliquez sur Create.
- Allez dans Role et cliquez sur Create a Role. Va sur Trusted Entity Type > Select AWS Service
Service > Select Glue.
- Attachez AWSGlueServiceRole et créez la politique pour ce rôle.
- Saisissez un nom de poste et cliquez sur Create role.
- Copiez l'ARN du rôle ; il sera utilisé comme ARN du rôle du Crawler.
Fournir des autorisations dans la formation des lacs
- Allez sur AWS Lake formation> Administration > Administrative roles and tasks.
- Définissez le type d'accès comme Data lake administrator, sélectionnez les rôles créés et cliquez sur Confirm. Assurez-vous qu'il inclut le rôle Crawler ainsi que le rôle instance.
- Allez à Permissions > Data permissions et cliquez sur Grant.
- Définissez le type de principe comme Principals, puis sélectionnez les rôles. Assurez-vous qu'ils incluent le rôle Crawler ainsi que le rôle Instance.
Note
Si vous souhaitez interroger des données sur Athena, ajoutez également le rôle de l'utilisateur sous IAM users and roles avec le Crawler Role et le Instance role.
- Select les ressources du catalogue Named données et entrez les catalogues et les bases de données dans lesquels les données seront stockées.
- Fournissez toutes les autorisations de base de données et cliquez sur Grant.
Utiliser la méthode d'authentification AWS IAM Roles Anywhere
Conditions préalables
Le service AWS Certificate Manager doit être activé pour authentifier le plugin à l'aide de la méthode d'authentification AWS IAM Roles Anywhere.
Remarque : veillez à créer l'autorité de certification privée, l'ancre de confiance et le profil dans la même région que celle où se trouve votre AWS S3 Source Bucket.
Créer une politique pour un certificat privé
Cette politique contient les autorisations requises pour créer un certificat d'autorité de certification privé (y compris les autorisations pour créer l'ancre de confiance et le profil) et pour utiliser les rôles IAM Anywhere.
- Accédez au générateur de stratégies et Select Stratégie IAM comme type de stratégie, puis générez la stratégie.
- Select Type de politique : Politique IAM
- Effet : Autoriser
- Service AWS : Autorité de certification privée AWS
- Actions :
- Créer une autorité de certification
- DescribeCertificateAuthority
- Obtenir un certificat
- Obtenir un certificat d'autorité
- Obtenir l'autorité de certification (GetCertificateAuthorityCsr)
- ImportCertificateAuthorityCertificate
- Délivrer un certificat
- Liste des autorités de certification
- ARN : *
- Cliquez sur Add Statement.
- Select Type de politique : Politique IAM
- Select Type de politique : Politique IAM
- Effet : Autoriser
- Service AWS : Gestion des identités et des accès (IAM) d'AWS
- Actions :
- Politique de rattachement des rôles
- Créer une clé d'accès
- Créer un rôle
- Supprimer un rôle
- PassRole
- ARN : *
- Cliquez sur Add Statement.
- Select Type de politique : Politique IAM
- Select Type de politique : Politique IAM
- Effet : Autoriser
- Service AWS : Gestionnaire de certificats AWS
- Actions :
- Décrire le certificat
- Certificat d'exportation
- Obtenir un certificat
- Liste des certificats
- ListTagsForCertificate
- Demande de certificat
- ARN : *
- Cliquez sur Add Statement.
- Select Type de politique : Politique IAM
- Select Type de politique : Politique IAM
- Effet : Autoriser
- Service AWS : Gestion des identités et des accès AWS Rôles en tout lieu
- Actions :
- Créer un profil
- CreateTrustAnchor
- Obtenir un profil
- GetTrustAnchor
- Liste des profils
- ListTrustAnchors
- ARN : *
- Cliquez sur Add Statement.
- Cliquez sur Generate Policy.
- Copiez la politique car elle sera utilisée dans l'étape suivante pour créer la politique nécessaire à la création des certificats de l'AC privée.
- Allez sur AWS Console et sélectionnez IAM depuis All Services. Cliquez sur Policies dans le panneau de gauche puis cliquez sur Create Policy.
- Copiez la politique dans l'onglet JSON. et cliquez sur Next:Tags, cliquez sur Next:Review..
- Saisissez Nom et cliquez sur Save Changes, comme Netskope-ce-rolesAnywhere-policy.
Créer une autorité de certification privée
- Connectez-vous à la console AWS
- Cherche Certificate Manager.
- Cliquez sur AWS Private CA.
- Cliquez sur Create a private CA.
- Select General-purpose for Mode options.
- Select Root for CA type options.
- Saisissez une organisation (O).
- Select RSA 2048 for Key algorithm options.
- Add tags if any (optional).
- Click the checkbox in the CA permissions options section.
- Click the checkbox in the Pricing section
- Cliquez sur Create pour créer le certificat CA.
- From Actions select Install CA Certificate.
- Cliquez sur Confirm and Install.
Créer une ancre de confiance pour le certificat privé
- Recherchez le service IAM et allez dans Roles dans la section Gestion d’accès. Faites défiler vers Rôles n’importe où et sélectionnez Manage.
- Cliquez sur Create a Trust anchor.
- Enter a Trust anchor name, like netskope-ce-trust-anchor.
- Select votre AWS Certificate Manager Private CA (créé dans les étapes précédentes) comme source d'autorité de certification (CA).
- Ajoutez des étiquettes si nécessaire.
- Cliquez sur Create a trust anchor.
- Cliquez sur l'Ancre de confiance créée et copiez l'ARN de l'Ancre de confiance.
Créer une politique de configuration des plugins
- Allez à IAM > Policies et cliquez sur Create Policy.
- Select Json, collez cette politique, puis faites défiler vers le bas et cliquez sur Next.
Politique :
{ "Version": "2012-10-17", "Statement": [ { "Sid": "SecurityLakePerms", "Effect": "Allow", "Action": [ "securitylake:CreateCustomLogSource", "securitylake:ListLogSources", "securitylake:GetDataLakeSources", "securitylake:ListDataLakes" ], "Resource": "*" }, { "Sid": "LakeFormationPerms", "Effect": "Allow", "Action": [ "lakeformation:RegisterResource", "lakeformation:GrantPermissions", "lakeformation:GetDataLakeSettings" ], "Resource": "*" }, { "Sid": "GluePerms", "Effect": "Allow", "Action": [ "glue:CreateTable", "glue:CreateDatabase", "glue:CreateCrawler", "glue:UpdateCrawler", "glue:UpdateDatabase", "glue:UpdateTable", "glue:StartCrawlerSchedule", "glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables", "glue:GetTableVersion", "glue:GetTableVersions", "glue:GetPartition", "glue:GetPartitions" ], "Resource": "*" }, { "Sid": "AllowAssumeSecurityLakeProviderRole", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession" ], "Resource": [ "arn:aws:iam::[aws-account-id]:role/AmazonSecurityLake-Provider-*" ] }, { "Sid": "AllowPassAndReadRoleForCrawler", "Effect": "Allow", "Action": [ "iam:PassRole", "iam:GetRole", "iam:CreateRole", "iam:PutRolePolicy", "iam:ListRolePolicies", "iam:DeleteRole", "iam:DeleteRolePolicy" ], "Resource": "*" }, { "Sid": "AllowUpdateProviderRoleTrustPolicy", "Effect": "Allow", "Action": [ "iam:UpdateAssumeRolePolicy", "iam:GetRole" ], "Resource": "arn:aws:iam:::role/AmazonSecurityLake-Provider-*" }, { "Sid": "S3Perms", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:PutObject", "s3:CreateBucket", "s3:ListAllMyBuckets", "s3:GetBucketLocation", "s3:GetBucketPolicy" ], "Resource": "*" } ] } Note
Veillez à remplacer l'ID du compte AWS dans la politique.
- Saisissez un nom et une description de stratégie, par exemple IAM-policy-security-lake.
- Cliquez sur Create Policy.
Créer un rôle pour la configuration du plugin
- Allez dans IAM > Roles et cliquez sur Create Role.
- Select Custom trust policy comme type d'entité de confiance, collez la politique de confiance personnalisée illustrée ci-dessous, puis cliquez sur Next.
Politique de confiance personnalisée :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession", "sts:SetSourceIdentity" ] } ] } - Attachez la politique précédemment créée à ce poste et cliquez sur Next.
- Saisissez un nom de rôle, faites défiler vers le bas et cliquez sur Create role.
- Une fois le rôle créé, ouvrez-le et copiez son ARN, car il sera utilisé comme ARN de rôle lors de la configuration du plugin Amazon Security Lake.
Créer un profil
- Allez sur Roles Anywhere > Create a Profile.
- Saisissez un nom de profil et ajoutez le rôle que vous venez de créer dans la section Créer un rôle.
- Scroll Down, click the check box in the Custom role session name section, and then click Create a Profile.
- Ouvrez le profil créé et copiez l'ARN du profil. Il sera utilisé lors de la configuration du plugin Amazon Security Lake.
Demander un certificat privé
- Allez sur AWS Certificate Manager > Request certificate.
- Select Request a private certificate.
- Cliquez sur Next.
- Select l'autorité de certification créée dans les étapes précédentes.
- Provide a domain name in the Fully qualified domain name field (like netskope-ce.com).
- Select RSA 2048 as the Key algorithm.
- Ajoutez des étiquettes si nécessaire.
- Confirmez les autorisations de renouvellement du certificat.
- Cliquez sur Request.
- Allez sur List certificates dans le panneau de navigation de AWS Certificate Manager.
- Select le certificat créé précédemment.
- Cliquez sur Export.
- Saisissez la phrase d'authentification. Notez la phrase d'authentification car elle sera nécessaire pour configurer le plugin AWS Security Lake en utilisant la méthode d'authentification AWS IAM Roles Anywhere.
- Cliquez sur Generate PEM Encoding.
- Téléchargez tous les sites Certificates car ils ne seront plus visibles. Pour les certificats New, vous devrez l'exporter à nouveau.
Pour plus d’informations, rendez-vous sur AWS IAM Role Anywhere
Créer un ARN pour le rôle de crawler
- Créez une politique à l'adresse IAM > Policies en utilisant les autorisations ci-dessous.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "GlueCrawlerListBucket", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:ListBucketVersions", "s3:ListBucketMultipartUploads", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::aws-security-data-lake-us-east-1-*" }, { "Sid": "GlueCrawlerReadObjects", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectVersion", "s3:GetObjectTagging", "s3:ListMultipartUploadParts" ], "Resource": "arn:aws:s3:::aws-security-data-lake-us-east-1-*/*" } ] }
- Saisissez un nom de politique et cliquez sur Create.
- Allez à Roles et cliquez sur Create a Role. Cliquez sur Trusted Entity Type > Select AWS Service
Service > Select Glue.
- Attachez AWSGlueServiceRole à la politique créée précédemment pour ce rôle.
- Saisissez un nom de poste et cliquez sur Create role.
- Copiez l'ARN du rôle ; il sera utilisé comme ARN du rôle du Crawler.
Fournir des autorisations dans la formation des lacs
- Définissez le type d'accès comme Data lake administrator, sélectionnez les rôles créés et cliquez sur Confirm. Assurez-vous qu'il inclut le rôle Crawler ainsi que le rôle Instance.
- Allez à Permissions > Data permissions et cliquez sur Grant.
- Select Principals comme type de principe, et sélectionnez les rôles. Veillez à inclure le rôle Crawler ainsi que le rôle Instance.
Note
Si vous souhaitez interroger des données sur Athena, ajoutez également le rôle de l'utilisateur sous IAM users and roles avec le Crawler Role et le Instance role.
- Select les ressources Named Data Catalog et entrez les catalogues et les bases de données où les données seront stockées.
- Fournissez toutes les permissions nécessaires à la base de données et cliquez sur Grant.
Etapes à suivre après que le plugin ait été configuré avec la politique de confiance du rôle du fournisseur de mise à jour automatique comme Non
- Créez manuellement la source de données personnalisée pour chaque type d'alertes, d'événements et de WebTx sur votre instance AWS. Utilisez le fichier OCSF Class Mappings for Default Mapping pour associer les alertes/événements à la classe OCSF.
- Une fois les sources de données personnalisées créées, vous devrez mettre à jour manuellement la politique de confiance pour chaque rôle de fournisseur. Voici l'exemple pour le type d'événement " clientstatus".
Politique de confiance :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::[aws-account-id]:root" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession" ] } ] } - Configurez le plugin en utilisant les sources de données créées manuellement.
Configurer le plugin Amazon Security Lake
1. Dans Cloud Exchange, accédez à Settings > Plugin Store.
2. Recherchez et sélectionnez le plugin Amazon Security Lake v2.0.0 (CLS).
3. Saisissez le nom de la configuration (comme Amazon Security Lake), sélectionnez le fichier de mappage en fonction de vos besoins.
Note
Avec les mappages par défaut, le champ raw_data sera considéré comme nul sur AWS (Athena). Pour envoyer des données brutes, les utilisateurs doivent mettre à jour le mappage et définir la valeur par défaut du champ raw_data comme raw_data pour chaque alerte/événement/webtx. Par exemple :
Ce plugin ne prend en charge que le format OCSF.
4. Cliquez sur Next et entrez les paramètres de configuration en conséquence :
Méthode d'authentification
Déployer avec AWS
Entrez ces paramètres :
- AWS S3 Bucket Region Name: AWS S3 Bucket Region Nom de la région à partir de laquelle vous pouvez obtenir le AWS S3 Bucket. Assurez-vous que le nom de la région correspond à celui de l'ARN du profil et de l'ARN de l'ancre de confiance.
- AWS Account ID: Identifiant du compte AWS dans lequel est créé le réservoir de sources personnalisé du lac de sécurité AWS.
- Parquet File Name Prefix: Préfixe du nom du fichier Parquet pour le Custom Source Bucket d'AWS Security Lake. Ce champ est facultatif.
- AWS Crawler Role ARN: Le nom de ressource Amazon (ARN) du rôle IAM que le crawler AWS Glue utilisera pour accéder à vos données. Ce rôle doit disposer d'autorisations pour accéder au Security Lake, aux buckets S3, au Glue données Catalog et au Lake Formation. Veuillez vous référer au guide pour les étapes détaillées de la configuration du rôle Glue Crawler.
- Provider External ID: Un identifiant externe utilisé pour établir une relation de confiance avec le fournisseur de logs (pour les meilleures pratiques de sécurité contre les attaques de type "confused deputy").
- Provider Principal: Le principal AWS (généralement un ARN de rôle IAM ou un ID de compte) de l'entité qui écrira les journaux dans le seau S3.
- Name of Custom Data Source for alert/event/webtx: Le Custom Source Bucket de ce nom sera créé dans AWS Security Lake pour le type d'alerte/événement ou Webtx en question. De même, le nom du dossier dans le seau S3 sera basé sur ces valeurs.
Déployez avec les rôles IAM d'AWS n'importe où
Faites défiler vers le haut et cliquez sur Save.
Configurer une règle de gestion de l'expéditeur de journaux pour Amazon Security Lake
- Dans Log Shipper, cliquez sur Business Rules.
- Cliquez sur Create New Rule.
- Saisissez un nom de règle et configurez le filtre en fonction de vos besoins. Saisissez un nom de dossier, le cas échéant.
- Cliquez sur Save.
Configurer la livraison de logs par Log Shipper pour Amazon Security Lake
- Allez à Log Shipper > Log Delivery et cliquez sur Add Log Delivery Configuration.
- Select une configuration de la source, une configuration de la destination et une règle de gestion.
- Cliquez sur Save.
Note/p>
Pour Amazon Security Lake, le nombre total de logs/Webtx envoyés à un récepteur externe ne représente pas le nombre de données ingérées. Ce nombre représente le nombre de Logs/Alerts/Events/Webtx extraits et stockés dans le fichier sur Cloud Exchange et plus tard ils seront téléchargés vers le Security Lake S3 bucket sur AWS. Les données ne seront pas ingérées dans la destination si l'alerte/événement/webtx tiré(e) est d'une taille inférieure à 265 Mo, et si aucun autre alerte/événement du même type n'est tiré(e) au bout de 5 minutes.
Valider le plugin Amazon Security Lake
Afin de valider le plugin workflow, vous pouvez vérifier à partir de Netskope Cloud Exchange et de AWS.
Valider le retrait
Allez sur Settings > Logging. Appliquez le filtre en fonction de vos besoins. Voici quelques exemples de journaux d'événements, d'alertes et de journaux Webtx.
Pour valider l'ingestion de Cloud Exchange
- Allez sur Settings > Logging. Appliquez le filtre en fonction de vos besoins. Exemple : message comme "[CLS Amazon Security Lake]" pour vérifier les journaux liés au plugin.
- Vous pouvez consulter les journaux pour vérifier la réussite de l'ingestion :
CLS Amazon Security Lake [CLS Amazon Security Lake] : [<alert/event name>] Téléchargé avec succès sur S3. >Notez que pour le WebTx, utilisez le nom de l'alerte/événement< comme v2.
Note
- Les données ne seront pas ingérées dans la destination si l'alerte/événement/webtx tiré(e) est d'une taille inférieure à 265 Mo et qu'aucune alerte/événement du même type n'est tiré(e) à nouveau après 5 minutes.
- Des logs similaires aux exemples ci-dessous ne signifient pas que les données sont ingérées dans le seau S3 du lac de sécurité :
| CLS Amazon Security Lake [CLS ASL] [alertes] [ctep] : Ajouté avec succès 1 journal(s) au fichier de téléchargement AWS Security Lake. Le fichier sera téléchargé dans le seau AWS Security Lake une fois que la condition relative à la taille du fichier (256 Mo) ou à la durée du téléchargement (5 minutes) aura été remplie. |
| 1 [alerts][ctep] log(s) a été inséré avec succès dans la configuration CLS ASL. Temps nécessaire : 2 secondes. |
Valider dans AWS
Allez sur S3 Bucket ➔ < security lake bucket name > ➔ ext ➔ Custom données Source for alert/event/webtx.
Il s'agit d'un exemple d'emplacement de destination pour la source de données personnalisée "ns_incident" :
Note
- Il comportera différents dossiers en fonction des dates (c'est-à-dire eventDay) dans chaque dossier de type alerte/événement/webtx.
- Si vous avez configuré le plugin avec "Parquet File Name Prefix", ce préfixe sera ajouté à chaque fichier.
- Les données ne seront pas ingérées dans la destination si l'alerte/événement/webtx tiré(e) est d'une taille inférieure à 265 Mo et qu'aucune alerte/événement du même type n'est tiré(e) à nouveau après 5 minutes.
Pour valider les données sur Athena
Note
Assurez-vous que l'utilisateur dispose des autorisations nécessaires pour interroger les données sur Athena. Les autorisations peuvent être fournies au rôle de l'utilisateur depuis AWS Lake Formation > données Permissions > Grant. Pour plus d'informations sur les autorisations de consultation des données sur Athena, vous pouvez contacter l'équipe d'assistance AWS.
- Avant de rechercher les données sur Athena, assurez-vous que tous les crawlers ont été exécutés avec succès. Les utilisateurs peuvent exécuter n'importe quel crawler à partir de la page AWS Glue > Crawlers sur AWS. Select les crawlers nécessaires et cliquez sur le bouton Exécuter. Une fois qu'il est exécuté correctement, l'utilisateur peut rechercher les données ingérées sur Athena. Les utilisateurs peuvent également définir un calendrier automatique pour l'exécution de ces Crawlers en modifiant manuellement le Crawler pour chaque alerte/événement/webtx.
- Pour rechercher les données ingérées, rendez-vous dans le Amazon Athena > Query editor.
- Cliquez sur les 3 points > Preview Table pour obtenir le tableau spécifique à l'alerte, l'événement ou le webtx. Vous pouvez ici définir la requête en fonction de vos besoins.
- Il s'agit d'un exemple d'événement de l'application d'ingestion :
Faites défiler l'écran pour afficher tous les champs pris en charge.
Voici quelques exemples de données ingérées :
For Events 
For Alerts
Note
Le tableau des alertes CTEP contient les alertes CTEP, C2 et IPS.
For WebTx
Dépannage du plugin AWS Security Lake
Si vous rencontrez une erreur lors de la configuration du plugin. Cela peut être dû aux raisons suivantes :
- Informations d'identification invalides
- Security Lake n'est pas activé sur le compte AWS fourni.
What to do:
- Vérifier si les informations d'identification fournies sont valides ou non. Reportez-vous aux étapes mentionnées dans la section Configuration sur AWS.
- Assurez-vous que l'option Security Lake est activée sur le compte AWS fourni.
Si vous ne voyez pas de fichiers Parquet dans le panier de destination dans les 10-15 minutes suivant la configuration. Cela peut être dû aux raisons suivantes :
- Les données ne sont pas extraites du plugin source.
- Les données extraites sont inférieures à 256 Mo et aucun New même type de données n'est extrait à nouveau.
What to do:
- Vérifiez si les logs sont tirés ou non, vérifiez les logs à partir de la page Logging pour le Source Plugin.
- Notez que les données ne seront pas ingérées dans la destination si l'alerte/événement/webtx tiré(e) est d'une taille inférieure à 265 Mo et qu'aucune alerte/événement du même type n'est tiré(e) à nouveau après 5 minutes.
Impossible d'ingérer des données sur AWS (Security Lake S3 bucket). Cela peut être dû à l'une des raisons mentionnées ci-dessous :
- Permissions insuffisantes
- Pour l'authentification AWS IAM Roles Anywhere, l'option Auto-update Provider Role Trust Policy est définie sur No et l'utilisateur n'a pas mis à jour les règles de confiance du rôle Provider.
What to do:
- Assurez-vous d'avoir suivi les étapes appropriées mentionnées dans la section Configuration sur AWS.
- Utilisez la section "Etapes après la configuration du plugin avec la mise à jour automatique de la politique de confiance des rôles du fournisseur comme Non" pour mettre à jour les rôles requis.
Impossible de valider les fichiers ingérés dans le bac S3 pour le nom de bac donné
Ce problème peut survenir parce que les anciennes versions du plugin utilisaient le nom du seau S3 comme nom de configuration du plugin et que tous les types de données étaient ingérés à un seul endroit.
What to do:
Configurez un nouveau CLS Amazon Security Lake v2.0.0 au lieu de mettre à jour le plugin à partir d'un plugin plus ancien. version
Vous n'arrivez pas à interroger les données sur Athena, cela peut être dû aux raisons suivantes :
- Aucune donnée n'est ingérée dans le seau S3 de Security Lake.
- L'utilisateur n'a pas l'autorisation d'interroger les données de la base de données du lac de sécurité.
What to do:
- Assurez-vous que les données sont ingérées dans le seau S3 du Security Lake. Reportez-vous à la section Valider à partir de l'AWS.
- Assurez-vous que l'utilisateur dispose des autorisations nécessaires pour accéder à la base de données des lacs de sécurité. Les autorisations peuvent être attribuées au rôle de l'utilisateur à partir de la page AWS Lake Formation > Data Permissions . Pour plus d'informations sur les permissions d'interrogation des données sur Athena, vous pouvez vous connecter à l'équipe de support AWS.
Le fichier Parquet est téléchargé dans le bucket S3 mais les données ne sont pas visibles sur Athena ou seulement certaines colonnes sont visibles. Cela peut être dû aux raisons suivantes :
- Le crawler pour cette alerte/événement/webtx n'est pas exécuté.
- Permissions insuffisantes
What to do:
- Soit l'utilisateur doit lancer manuellement le Crawler à partir de la page AWS Glue > Crawlers, soit il doit définir la sortie et la planification du Crawler en fonction de ses besoins.
Note
Chaque type d'alerte/événement et Webtx aura un Crawler distinct.
- Vérifiez les autorisations pour les informations d'identification générées pour configurer le plugin ou contactez l'équipe d'assistance AWS.
Comportements connus
- Les données ne seront pas ingérées dans la destination si l'alerte/événement/webtx tiré(e) est d'une taille inférieure à 265 Mo et qu'aucune alerte/événement du même type n'est tiré(e) à nouveau après 5 minutes.
- Les fichiers des données extraites ne seront pas supprimés s'ils ne sont pas ingérés dans la destination. Exemple : Si l'utilisateur a configuré le plugin CLS Amazon Security Lake v2.0.0 et a extrait 1 Mo de chaque type d'alertes/événements et Webtx lors de l'extraction initiale, puis qu'aucune New données n'est extraite ou que la configuration du plugin est supprimée, les fichiers créés lors de l'extraction initiale ne seront jamais supprimés.
- Les dossiers pour chaque type d'alerte/événement/webtx seront créés lors du téléchargement du premier fichier de ce type d'alerte/événement/webtx sur le seau S3 du lac de sécurité.
- Toutes les ressources créées par le plugin (i.e. Les données personnalisées Sources, Crawlers, Tables sous données Lake formation) sur AWS ne seront pas supprimées par la suppression de la configuration du plugin.
- Même si la source Custom données pour une alerte/un événement/un webtx particulier est supprimée, le plugin continuera à télécharger les données dans le dossier de destination jusqu'à ce que le dossier soit présent dans le seau S3 du lac de sécurité et si le dossier de destination est également supprimé, l'utilisateur rencontrera une erreur. Exemple de journal des erreurs :
CLS Amazon Security Lake [CLS ASL19thJana] [Malware]: S3 upload failed with unexpected error: Failed to upload /opt/netskope/plugins/security_lake_staging/temp_15497_1768910939013.parquet to aws-security-data-lake-us-east-1-drr9keiinq7es73ywbjszqfsmbchwc/ext/a_delete/region=us-east-1/accountId=472514710809/eventDay=20260120/cd51579e-f5f8-11f0-ad9f-de8f29b50429--20260120120859.parquet: An error occurred (InvalidAccessKeyId) when calling the PutObject operation: The AWS Access Key Id you provided does not exist in our records.. Not retrying.
- Dans les correspondances par défaut, certains champs sont associés à des valeurs par défaut.
- Le nombre total de logs/Webtx envoyés à un récepteur externe sur la page Log Delivery ne représente pas le nombre de données ingérées. Ce nombre représente le nombre de Logs/Alerts/Events/Webtx tirés et stockés dans le fichier sur Cloud Exchange et plus tard il sera téléchargé vers le Security Lake S3 bucket sur AWS.
- Le nombre d'alertes/événements/webtx ignorés peut être vérifié à partir des journaux. Exemple de protocole :
CLS Amazon Security Lake [CLS ASL]: [alerts][Compromised Credential] Processed 2 records: 1 succeeded, 0 failed, 1 empty records skipped.
- Le schéma OCSF définit certains champs par paires de frères, par exemple activity_name (String) et activity_id (Integer from a predefined enum), status et status_id, etc. Dans les correspondances par défaut, pour tous ces champs, les valeurs de l'énumération Integer sont mises en correspondance avec 99 . Cela permet à la moitié "chaîne" de la paire de contenir n'importe quel champ reçu de Netskope.
Par exemple : Dans Compromised Credential Alert, severity_id est associé à la valeur par défaut 99. Il est recommandé de se référer à son frère String severity et non à severity_id pour obtenir la valeur réelle reçue de Netskope. - Des logs similaires aux exemples ci-dessous ne signifient pas que les données sont ingérées dans le seau S3 du lac de sécurité :
| CLS Amazon Security Lake [CLS ASL] [alertes] [ctep] : Ajouté avec succès 1 journal(s) au fichier de téléchargement AWS Security Lake. Le fichier sera téléchargé dans le seau AWS Security Lake une fois que la condition relative à la taille du fichier (256 Mo) ou à la durée du téléchargement (5 minutes) aura été remplie. |
| 1 [alerts][ctep] log(s) a été inséré avec succès dans la configuration CLS ASL. Temps nécessaire : 2 secondes. |
Pour vérifier l'ingestion des données dans le seau S3 de Security Lake, reportez-vous aux sections "Pour valider l'ingestion à partir de Netskope Cloud Exchange" et "Pour valider à partir d'AWS".
- Les utilisateurs peuvent observer quelques erreurs ou avertissements lors de la validation des fichiers parquet téléchargés à l'aide du point de terminaison officiel du validateur OCSF, mais ceux-ci ne devraient pas affecter l'interrogation des données sur Athena. Voici quelques exemples :
{
"error": "attribute_enum_value_unknown",
"message": "Unknown enum value at \"proxy_http_request.http_method\"; value \"\" is not defined for enum \"http_method\".",
"value": "",
"attribute": "http_method",
"attribute_path": "proxy_http_request.http_method"
}
{
"message": "Attribute \"evidences[0].device.os_machine_uuid\" value does not match regex of type \"uuid_t\".",
"type": "uuid_t",
"value": "f5d060933f64c16cc6661ad5",
"warning": "attribute_value_regex_not_matched",
"attribute": "os_machine_uuid",
"regex": "[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}",
"attribute_path": "evidences[0].device.os_machine_uuid"
},
{
"message": "Attribute \"device.mac\" value does not match regex of type \"mac_t\".",
"type": "mac_t",
"value": "",
"warning": "attribute_value_regex_not_matched",
"attribute": "mac",
"regex": "^([0-9A-Fa-f]{2}[:-]){5}([0-9A-Fa-f]{2})$",
"attribute_path": "device.mac"
}
{
"message": "Attribute \"evidences[2].email.to[0]\" value does not match regex of type \"email_t\".",
"type": "email_t",
"value": "[\"amark@default.com\", \"johnak@default.com\", \"test_user@netstate.com\"]",
"warning": "attribute_value_regex_not_matched",
"attribute": "to",
"regex": "^[a-zA-Z0-9!#$%&'*+-/=?^_`{|}~.]+@[a-zA-Z0-9-]+\\.[a-zA-Z0-9-.]+$",
"attribute_path": "evidences[2].email.to[0]"
}
- Les alertes de type C2 et IPS seront intégrées dans le tableau des alertes CTEP sur la plateforme AWS.
- Seule une partie des colonnes sera visible dans le tableau Athena si le crawler pour un tableau particulier n'est pas exécuté. Vous pouvez soit lancer manuellement le crawler pour une table particulière, soit programmer l'exécution automatique d'un crawler particulier à un moment précis.
