Créez des règles personnalisées sous Policies > Security Posture > Profiles & Rules en utilisant un langage spécifique au domaine (DSL) pour l'évaluation de la sécurité des ressources AWS, Azure et Google Cloud.
The following syntax diagram represents the general rule to write a DSL statement.
Format de la règle : <entity> [where <condition>] should [not] have <condition>
Par exemple,
S3Bucket should not have any ACL in (10.0.0.0)
IAMUser where Name eq “root” should have Password.Enabled eq true and MFAActive eq true
Entity
An entity defines what the rule is checking against. It can be used alone or with a condition to further specify the entity.
Voici quelques exemples d'utilisation d'une entité.
| <entity> <entité> devrait avoir <condition> | S3Bucket devrait avoir LoggingEnabled AADuser ne devrait pas avoir d’égalisation Type « Invité » |
| <entity> <entité> où <condition> La condition "où" définit davantage l'entité afin de réduire le résultat. | IAMUser où l’égalisation Name « racine » et l’égalisation MFAActive true AWS où CloudTrails avec [ MultiRegionTrailEnabled eq true ] |
Pour une liste complète des entités et attributs pris en charge, voir
Condition
Une condition est une norme que la règle utilise pour vérifier une entité afin de réduire le résultat.
The following table provides examples of using a condition. The formats in this table are applicable to all properties.
| <property>< propriété > | L'AWS doit avoir CloudTrails |
| <property> <propriété> [func()] <opérateur><operator> <value> | IAMUser doit avoir Name eq “root” IAMUser doit avoir Policies.Managed len() eq 0 |
| <property> <propriété> avec/contenant <condition> | L'AWS doit avoir IAMUsers with [ Name eq “root” ] |
| <property> <value1><value2><value3><propriété> in/notin (,,) | IAMUser doit avoir Name in ( “root”, “name2” ) |
| utiliser des quantificateurs pour les propriétés des listes et des séquences | IAMUser doit avoir atleast one Password eq “1234” |
| utiliser et, ou, pas, ( ) pour les conditions complexes | IAMUser doit avoir (Name eq “root”) and (MFAActive eq true) |
Function
Utilisez des fonctions dans les règles pour trouver des informations spécifiques sur les entités. Les fonctions utilisent la syntaxe suivante,
<entity> <function>(<argument>)
Par exemple,
S3Bucket should have Tags len ( ) gt 0
Protocol in ("-1", "tcp")
Le tableau suivant fournit une liste complète des fonctions disponibles pour les règles.
| Function | Property Types | Arguments | Renvoie le type de propriété | Description |
|---|---|---|---|---|
| len | list, string | none | number | Renvoie la longueur d'une chaîne ou d'une liste. |
| numhosts | ip | none | number | Number of hosts in subnet. |
| isPrivate | ip | none | boolean | Si l'IP est privée (IPy). |
| isPublic | ip | none | boolean | Whether IP is public (IPy). |
| divisibleby | number | number | boolean | Si le nombre LHS est divisible par l'argument. |
| en, pas en | chaîne, booléen, ip, nombre | list | boolean | Si la valeur LHS est dans la liste (raccourci pour OR long). |
| has | list | list | boolean | Whether LHS list contains any one of the lists passed in as argument. |
| isLaterThan | numéro (date) | nombre, unités | boolean | Indique si le nombre LHS (date) est postérieur à l'heure actuelle +/- le nombre d'unités (arguments). Par exemple, isLaterThan ( -1, "days") signifie que LHS est postérieur à un jour (à partir de l'heure de balayage). Les unités doivent être l'une des suivantes : secondes|minutes|heures|jours|semaines. Le terme "jours" est le plus courant. |
| isEarlierThan | numéro (date) | nombre, unités | boolean | Indique si le nombre LHS (date) est antérieur à l'heure actuelle +/- le nombre d'unités (arguments). Par exemple, Password.LastUsedTime isEarlierThan ( -90, "days")). Les unités doivent être l'une des suivantes : secondes|minutes|heures|jours|semaines. Le terme "jours" est le plus courant. |
Property
La propriété est utilisée pour définir la condition que la règle vérifie ainsi que pour restreindre l'entité contre laquelle la règle est vérifiée. Les propriétés peuvent être imbriquées à l'aide de ".", par exemple MFADevices.Virtual où la règle vérifie tous les périphériques virtuels.
The following is the syntax format.
<entity> should [not] have <property>...
<entity> where <property>...
Le tableau suivant fournit la liste des types de propriétés et des fonctions qu'ils prennent en charge.
| Type de propriété | Operators and Functions | Exemple |
|---|---|---|
| list | in, notin, contain, with, len() | IAMUsers with [ Name eq “root” ] |
| sequence | en, pas en | MFADevices in ("ID1", "ID2" ) |
| string | eq, neq, like, not like, len() | Name eq “root” |
| number | eq (=), neq (!=), gt (>), gte (>=), lt (<), lte (<=) | Topic.Subscriptions len() > 0 |
| boolean | eq, neq | Password.Enabled eq true |
| ip | eq, neq | IPRanges avec [ ip eq 0.0.0.0/0 ] |
Règles de conformité
Netskope provides a list of predefined rules to check your IaaS and SaaS environment for security posture compliance. For a complete list of predefined rules, see:
Common elements used to write a DSL rule
The following elements are commonly used in a DSL rule.
with- Pour accéder aux éléments d'une liste.- “.“
where– To restrict evaluated assets.- Opérateurs - Par exemple, eq, gte, gt, lt, lte, neq.
- Functions – Such as, like, has, in, len, isEarlierThan, isLaterThan, len.
- Numeric range syntax – For example, to check for port 137 and port 138, include the following in the syntax.
FromPort lte 138 and ToPort gte 13
Note
Will match any security group or firewall ruleset that has a port range including 137, 138 or both.
Meilleures pratiques en matière de rédaction de règles DSL personnalisées
Les meilleures pratiques suivantes sont recommandées lors de la rédaction de règles DSL personnalisées.
- Commencez par examiner les règles prédéfinies existantes. Si une règle prédéfinie peut effectuer les contrôles requis sur vos ressources IaaS, ajoutez-la à votre profil personnalisé.
- Si une règle existante répond partiellement à votre besoin, copiez-la et modifiez-la.
- Vérifiez les types de propriétés et les valeurs attendues du côté du fournisseur de services en nuage (CSP) et des entités prises en charge par Netskope. Les types et la hiérarchie peuvent être différents. Pour vérifier les types et les valeurs des propriétés :
- on the CSP side use the CSP test environment through CLI.
- du côté de Netskope, utilisez l'API Inventaire. Par exemple, obtenez des détails sur les ressources S3 Bucket dans AWS run,
curl --request GET "https://&lt;tenant_url&gt;/api/v1/public_cloud/inventory?token=NS_API_TOKEN&amp;limit=10&amp;skip=0&amp;resource_name=&lt;name_of_asset&gt;&amp;resource_type=S3Bucket" | python -mjson.tool
- Testez la règle personnalisée New en exécutant une commande comme la suivante :
curl --location --request POST "https://<tenant_url>/api/v1/public_cloud/rule_evaluate?token=NS_API_TOKEN" --header 'Content-Type: application/json' --data-raw '{ "cloud_provider": "aws", "rule_code": "S3Bucket should not have Access eq "Public"", "instance": "NS_UI_CONNECTION_INSTANCE", "resource_ids": [ ] }'Assurez-vous que le nom de l'instance correspond au nom configuré dans votre pile de locataires AWS.
- Déboguer la règle en fonction des résultats du test. Netskope recommande de tester la règle en utilisant au moins deux valeurs de propriété dont l'une correspond à la règle et l'autre non. Par exemple, testez en utilisant différents utilisateurs tels que root, admin, non-admin. Lorsque vous testez des politiques, faites-le en utilisant à la fois des politiques en ligne et des politiques gérées.
- Consider false positives and false negatives in the rule output and refine the rule.
- Incluez une clause "où" dans votre règle. Par exemple, pour signaler tout utilisateur non root qui ne s'est pas connecté au cours des 90 derniers jours, écrivez une règle du type,
IAMUser where RootUser eq False and LastUsedTime isEarlierThan ( -90, "days" )
- Assurez-vous de connaître les entités CSP et leur configuration. Il est important de connaître toutes les valeurs autorisées pour le bien afin de s'assurer qu'il n'y a pas de valeurs manquantes. Par exemple, pour vérifier un protocole TCP, vous devez savoir qu'en plus de tcp-only ("tcp"), il existe un joker "All Protocols" qui est enregistré sous la forme -1.
Reportez-vous à la documentation de Netskope ainsi qu'à celle de CSP pour connaître toutes les valeurs prises en charge pour un champ d'attribut.
- Incluez une clause "où" dans votre règle. Par exemple, pour signaler tout utilisateur non root qui ne s'est pas connecté au cours des 90 derniers jours, écrivez une règle du type,