Conformité Continue en Tant que Code P1 : Sigma

La conformité a toujours été une sorte de processus réactif puisque les normes sont longues, nécessitent des tonnes d’efforts et mettent du temps à être mises à jour, encore plus de temps à être mises en œuvre et le processus d’audit se déroule une fois par an. Venant du monde du SIEM, je traitais la conformité à travers un prisme de rapports préétablis qui renvoyaient généralement des résultats vides ou quelque chose de très éloigné de ce qui pourrait être expliqué à un auditeur externe. D’autre part, la logique sous-jacente des rapports et des requêtes est obscure et nécessite des tonnes d’efforts pour être maintenue, pour le moins. Pour que cela fonctionne, il faut maîtriser le moteur des règles de corrélation ou le langage de requête d’une technologie SIEM spécifique et le moteur de reporting qui l’accompagne, configurer des tonnes de listes et d’exceptions de manière statique, tandis que l’environnement réel est dynamique et que le simple fait de rassembler toutes les données en un seul endroit peut prendre de nombreux mois. Et au moment où nous avons terminé ces tâches, la technologie SIEM est changée ou je travaille avec un autre client qui utilise un système d’analyse de sécurité basé sur la recherche au lieu de l’ancienne « corrélation en temps réel ». Cela devient plus facile si nous disposons d’outils d’audit de sécurité comme des scanners VM qui disposent de fonctionnalités d’audit de conformité, par exemple Qualys Policy Compliance, Tripwire et similaires. Cependant, ces derniers outils ne construisent pas une image holistique ni en temps réel à moins d’être connectés à un SIEM ou une plate-forme d’analyse de sécurité d’une manière ou d’une autre. Ensuite, arrive le train GRC avec des produits massifs et des années d’effort en conseil. Ennuyeux. Non rentable. Garanties de lacunes en visibilité. Trop lent pour l’ère numérique dans laquelle nous vivons. Et quelle est l’efficacité de tout ce qui précède pour aborder le NIST CSF ou le RGPD ? IMHO, la conformité est un reflet de la sécurité, donc si vous faites bien la cybersécurité, la conformité suivra. Cela ne fonctionne pas dans l’autre sens, cependant. Temps pour un changement ? Oui. Et aujourd’hui, nous allons commencer une série d’articles pour rendre votre conformité un processus agile, transparent et rentable, adapté aux entreprises numériques modernes.

Évolution des règles Sigma et lien avec la conformité

Je considère l’adoption accélérée des règles Sigma pour les tâches de SIEM, SOC et de chasse aux menaces comme l’un des changements les plus positifs dans le domaine de la sécurité. Et bien que Sigma soit déjà un standard de facto pour les requêtes de chasse aux menaces, nous avons eu cette idée folle de l’appliquer pour établir des pratiques de conformité continue. Au cas où vous n’auriez pas entendu parler de Sigma auparavant, c’est une langue facile à comprendre, à courbe d’apprentissage rapide, agnostique à la plate-forme et open source. Exemples des règles et du code source https://github.com/Neo23x0/sigma et tutoriel pour commencer https://www.nextron-systems.com/2018/02/10/write-sigma-rules/Si vous avez Elastic Stack, Splunk, ArcSight, QRadar, Qualys, Microsoft Windows Defender ATP, Logpoint, Greylog : vous pouvez déjà tirer de la valeur des règles Sigma pour la sécurité et la chasse. Ces plateformes font probablement partie de votre infosec / SOC et elles contiennent des tonnes de données exploitables pour la conformité. Et il est encore plus probable que vous ayez un Elastic stack, version premium ou communautaire, utilisé dans diverses unités commerciales de votre organisation qui peut avoir des données pour des contrôles de conformité automatisés. L’une des raisons importantes de l’évolution de Sigma et de son adoption mondiale est son support natif de MITRE ATT&CK https://attack.mitre.org. Au cas où vous lisez cet article sans venir de l’infosec : MITRE ATT&CK est la blockchain de la cybersécurité ou le tableau périodique des éléments de la chimie. Donc, nous avons un standard open source, largement adopté qui est plus facile à apprendre que n’importe quel langage de requête de SIEM et prend en charge le balisage avec la méthodologie ATT&CK pour effectuer une attribution TTP à la volée. Que se passerait-il si nous ajoutions des balises pertinentes aux normes de conformité ? Avoir une requête pour un contrôle automatisé conformément à CSC 8.2 ou trouver des systèmes qui traitent des données personnelles pour le RGPD ? Pour Sigma, c’est juste une autre balise, donc techniquement c’est la prochaine étape logique de l’évolution.

Comment écrire des règles Sigma pour la conformité

Ce n’est pas un secret que bien que je sois personnellement un grand supporter de Sigma, je n’écris pas autant de règles moi-même à ce stade. Pour un guide détaillé du HOWTO, j’ai capturé Alex Yamposlkyi pour une courte discussion. Alex, étant l’un des développeurs de règles Sigma très actifs, en termes de quantité de règles développées, deuxième seulement après Florian Roth, a fourni quelques idées très pratiques.

AB : « Alex, avez-vous déjà développé des règles Sigma pour la conformité ? »
AY : « Oui, ces derniers mois ont été très chargés. Vous pouvez trouver quelques exemples dans le dépôt GitHub officiel de Sigma : https://github.com/Neo23x0/sigma/tree/master/rules/compliance et au SOC Prime Threat Detection Marketplace : https://tdm.socprime.com/?sigmaTypes[]=Compliance »

AB : « Génial. Y a-t-il un algorithme particulier que vous suivez lors de la création de règles Sigma de conformité ? »
AY : « Je suppose que je peux décrire cela comme un processus en 5 étapes :

1. Apprenez le contrôle CIS initial sur https://www.cisecurity.org/controls/cis-controls-list/
2. Comprenez quelle source de journal dans votre organisation peut être utilisée pour couvrir les exigences du contrôle particulier.
3. Recherchez dans votre plate-forme SIEM les événements nécessaires.
4. Une fois les événements appropriés découverts, décidez de la logique de la règle : un enregistrement de journal correspond-il à un événement qui est bon ou mauvais pour la conformité. Posez-vous la question : ce contrôle de journal passe-t-il ou échoue-t-il ?
5. Codez l’événement résultant dans la règle Sigma, en supprimant tous les paramètres de recherche spécifiques à la plate-forme pour la garder agnostique au SIEM. Ajoutez des balises de l’élément #1 et planifiez une recherche automatique. »

AB : « Cela ressemble à une victoire rapide. Pouvons-nous essayer d’étendre cela à une instruction étape par étape ? »
AY : « Oui. Voici une petite note.

1. Sélectionnez le domaine spécifique pour le contrôle que vous construisez, par exemple, « Défenses contre les malwares » qui correspond au domaine CSC #8.
2. Creusez plus profondément dans la description de ce contrôle, dans notre cas 8.2 se lit comme suit : « S’assurer que le logiciel anti-malware de l’organisation met à jour son moteur de balayage et sa base de données de signatures sur une base régulière. »
3. Pensez à ce qui doit se passer sur le système pour réussir ou échouer ce contrôle. Pour 8.2, cela signifie que si le service AV est arrêté ou s’il y a une erreur avec sa mise à jour, nous échouons au contrôle. Ainsi, nous devons suivre le journal des événements AV, spécifiquement pour les événements d’arrêt de service et d’erreur de mise à jour.
4. Il est assez facile de suivre ce contrôle particulier, nous devons installer un produit AV. Dans mon cas, c’était un produit Symantec intégré à Elastic stack via Logstash. Après avoir trié les journaux pendant un certain temps, j’ai trouvé l’événement que je cherchais responsable du téléchargement et du déploiement des mises à jour qui contient les chaînes suivantes « Nouveau contenu téléchargé », « Une mise à jour pour ».
5. En vérifiant quels champs contiennent ces mots-clés, je peux faire une simple requête Elastic : (event.name:(« Nouveau contenu téléchargé »)) OU (event.name:(« Une mise à jour pour »))
6. Maintenant nous prenons une décision sur la logique de la règle : avoir l’événement est-il bon ou mauvais. Dans notre cas, avoir l’enregistrement du journal est positif et signifie que le contrôle est passé. Pour automatiser le processus, nous coderons la règle Sigma et l’appliquerons au mécanisme de recherche enregistré spécifique à la plate-forme. Dans mon cas, je programme un Watcher à exécuter sur Elastic Stack avec un intervalle de temps spécifique à mon environnement.
7. Écrivons une règle Sigma
8. Dans cet exemple, je peux décider de programmer une alerte lorsque des événements sont manqués pendant une certaine période. Avec d’autres exemples, la situation peut être l’inverse et nous pourrions avoir besoin d’une alerte lorsque nous découvrons un événement.
9. Maintenant, notre règle a besoin de toutes les étiquettes pertinentes, donc je vais les ajouter dans ce formatÉtiquettes :
   – CSC8.2
   – attack.impact
   – attack.t1489

Nous pouvons en fait mélanger des balises pour ATT&CK et la conformité. Dans l’exemple ci-dessus, « CSC8.2 » est le numéro de contrôle correspondant au domaine CSC ; « attack.persistence » est une tactique MITRE ATT&CK et attack.t1053 » est une technique spécifique sur laquelle le contrôle est focalisé.

Un code Sigma mis à jour ressemblera à ceciUne fois que je publie des règles sur le Threat Detection Marketplace, j’obtiens également des métadonnées générées pour les règles en appuyant sur le bouton « Parse Sigma Content tags ».Dans la liste « Tags », je peux relier les règles à n’importe quelle norme de conformité telle que ISO, PCI, NIST CSF, etc.

Notre conversation s’est poursuivie pendant encore une heure avec suffisamment de matériel pour une interview sur le programme SOC Prime Threat Bounty. D’ici là, tout retour sur Sigma pour la conformité est très apprécié.
Et si vous souhaitez un aperçu de l’apparence du résultat final sur Elastic stack, regardez la vidéo sur https://my.socprime.com/en/continuous-compliance

/Restez en sécurité