Cadre d'automatisation de la sécurité AWS sans serveur qui ingère des renseignements sur les menaces, applique une détection d'anomalies basée sur le ML (RCF, IP Insights) et enrichit la télémétrie de sécurité dans Kibana pour une prévention, détection et réponse automatisées aux menaces.
SyntheticSun est un cadre de sécurité automatisé et de surveillance en profondeur qui utilise le renseignement sur les menaces, l'apprentissage automatique, les services de sécurité AWS gérés et les technologies serverless pour prévenir, détecter et répondre en continu aux menaces.
Tu dors dans du verre brisé
Avec tes reflets,
Mais te sens-tu vivant ?
Oui, laisse-moi te demander,
Te sens-tu vivant ?
- Norma Jean, 2016
SyntheticSun est construit autour de l'utilisation de la plateforme de partage d'informations sur les malwares (MISP) et de LIMO d'Anomali, qui sont des plateformes de renseignement sur les menaces (TIP) communautaires fournissant divers types d'indicateurs de compromission (IoC). Les renseignements sur les menaces normalisés et dédupliqués sont consultés en quasi-temps réel pour identifier rapidement les menaces connues dans divers types de trafic réseau. Pour dynamiser l'identification des menaces potentielles, des modèles IP Insights sont déployés pour trouver des anomalies (et les menaces potentielles qui y sont liées) entre le couplage d'adresses IP et d'entités (telles que les identifiants principaux IAM, les user-agents, etc.). Des détecteurs RCF natifs sont également utilisés dans Elasticsearch pour trouver des anomalies dans la télémétrie de sécurité en quasi-temps réel lorsqu'elle est diffusée dans Kibana. Pour démocratiser l'utilisation et le réglage fin des modèles de ML au sein des équipes de sécurité, des utilitaires pour entraîner les modèles IP Insights sont fournis en complément de la solution de base.
Pour effectuer à la fois l'orchestration et l'automatisation ainsi que l'extraction, la transformation et le chargement (ETL) de la télémétrie de sécurité dans Kibana, diverses technologies serverless AWS telles qu'AWS Lambda, Amazon DynamoDB et AWS CodeBuild sont utilisées. Ces technologies serverless sont choisies pour leur scalabilité, leur facilité d'utilisation et leurs coûts relativement faibles par rapport aux solutions lourdes basées sur MapReduce ou Glue ETL. La majeure partie de la solution est déployée via CloudFormation avec des scripts d'aide en Python et en shell fournis dans les différentes étapes pour favoriser l'adoption et le déploiement potentiel dans des pipelines d'intégration continue.
Pour rendre les « entrailles » de la solution aussi légères que possible, des modules Python de base tels que boto3, requests, json, ipaddress, socket et re effectuent la majeure partie de l'extraction, de la transformation et du chargement (ETL) vers les services en aval. Étant donné que toutes les informations de géolocalisation sont fournies par ip-api.com, cela ne nécessite ni compte ni niveaux payants et dispose d'une excellente API qui inclut des informations de limitation dans les en-têtes de réponse. La plupart des dépendances Elasticsearch et Kibana sont également fournies dans le code (index, mappings, visualisations, etc.) pour éviter une configuration manuelle lourde.
SyntheticSun est réparti sur trois étapes en raison de la taille de la solution et des dépendances requises. Toutes les instructions d'architecture et d'installation (ainsi que les FAQ le cas échéant) se trouvent dans leur propre étape. Des modules complémentaires (appelés Annexe) sont également fournis pour étendre les fonctionnalités, avec leurs propres instructions d'architecture et d'installation localisées.
SyntheticSun, en tant que quelque chose que vous avez trouvé sur GitHub, est une preuve de concept et je n'ai donc pas fait tout le nécessaire pour la première version afin de durcir absolument tous les aspects. Si vous lisez ceci à un moment où je n'ai pas encore apporté les modifications nécessaires, tenez compte des points suivants avant de déployer cette solution dans un environnement de production (ou tout environnement avec des besoins de sécurité renforcés). Je placerai ces éléments sur une feuille de route et les mettrai à jour si nécessaire.
SyntheticSun est un moyen simple de commencer à utiliser le renseignement sur les cybermenaces et l'apprentissage automatique pour vos cas d'utilisation de sécurité périmétrique sur le cloud AWS sans avoir à investir dans un ou plusieurs outils commerciaux, ou à embaucher un data scientist pour votre équipe de sécurité (même si vous devriez idéalement faire ce dernier). Cette solution, après configuration initiale, est entièrement automatisée, ce qui vous permet d'identifier et de répondre aux menaces à la vitesse de la machine. Enfin, cette solution fournit des visualisations de base pour que votre équipe de réponse aux incidents les utilise pour la réponse aux menaces, comme les connexions entrantes ou sortantes autorisées ou les requêtes DNS vers et depuis des adresses IP ou des domaines jugés malveillants. Le cœur de la solution repose sur des pipelines d'automatisation et d'ingénierie des données très légers, qui, en théorie, peuvent être réutilisés à d'autres fins lorsque des besoins de normalisation et d'enrichissement en plusieurs étapes ou des traitements par lots planifiés et rapides sont nécessaires.
Tout d'abord, si vous utilisez Amazon GuardDuty et/ou AWS WAF, il peut être judicieux d'évaluer cette solution, mais c'est aussi une exigence. Les personas évidents qui peuvent en tirer parti sont les équipes produit responsables de la sécurisation de leur pile complète et qui manquent de capital ou d'expertise pour modéliser, entraîner et déployer des algorithmes d'apprentissage automatique ou pour opérationnaliser les flux de renseignements sur les cybermenaces de manière significative. Ces personas susmentionnés sont probablement des ingénieurs en sécurité, des analystes/ingénieurs SecOps/SOC ou un ingénieur DevSecOps ; cependant, cette liste n'est pas exhaustive et ils n'ont pas besoin d'être alignés sur un produit/une application car les équipes centrales peuvent également l'utiliser. Une autre utilisation est pour ces mêmes personas (SecOps, ingénierie sécurité) qui travaillent pour une équipe centralisée et souhaitent créer une liste de blocage dynamique pour les pare-feux et les systèmes de prévention d'intrusion ; les projets CodeBuild peuvent être réutilisés pour déposer des fichiers CSV ou plats dans presque n'importe quel emplacement (par exemple, pare-feux Palo Alto, filtres URL du proxy direct Squid, etc.).
SyntheticSun manque actuellement d'une couverture complète sur toutes les principales sources de journaux - à savoir, les S3 Access Logs et les CloudFront Access Logs, qui sont intégrales à la manière dont beaucoup de gens fournissent des services (en particulier pour les SPA sur les buckets S3). La détection d'anomalies ne s'étend pas au-delà de WAF, des API Gateway Access Logs ou de CloudTrail en raison de mon obsession pour IP Insights et de mon manque total de formation en data science (sérieusement, je ne sais même pas utiliser pandas ou numpy). Il n'y a pas d'analyse approfondie des IoC bruts de renseignements sur les menaces autre que la tentative de les faire correspondre dans les journaux.
La façon la plus simple de déployer cette solution pour une organisation est de la déployer dans un compte de services de sécurité centralisé. Pour la télémétrie de bas niveau telle que les VPC Flow Logs et les WAF Logs, vous devriez envisager de fournir des scripts d'aide ou des modèles CloudFormation via AWS Service Catalog pour promouvoir leur activation dans les environnements inférieurs. Vous devrez évaluer votre consommation de shards et la rotation des index d'Elasticsearch Service, ainsi que les autorisations, si vous avez des flux de livraison Kinesis Data Firehose multi-comptes publiant dans un emplacement centralisé. J'ai construit cette solution dans mon compte sandbox personnel, c'est pourquoi je n'ai pas intégré les considérations ci-dessus dans la solution ; je serai heureux de travailler sur une PR dans cet esprit et je pourrais le faire moi-même à l'avenir.
Depuis le 31 JUILLET 2020, les politiques AWS Firewall Manager prennent en charge l'agrégation multi-comptes de la journalisation WAF, ce qui vous rapproche d'une solution beaucoup moins pénible...
AVERTISSEMENT : Je ne suis pas data scientist et cette réponse sera longue. En résumé : c'est un détecteur d'anomalies et je pense que oui ?
Étant donné que je ne suis même pas proche d'un data scientist ou que je n'ai aucune formation, vous feriez mieux de lire la documentation à ce sujet. Cela dit, voici ma tentative de vulgarisation : IP Insights est un algorithme d'apprentissage automatique non supervisé qui apprend la relation entre une adresse IPv4 et une entité (par exemple, numéro de compte, nom d'utilisateur, user-agent). IP Insights tente ensuite de déterminer la probabilité que l'entité utilise cette adresse IPv4. Derrière le rideau d'IP Insights se trouve un réseau neuronal qui apprend la représentation vectorielle latente de ces entités et adresses IPv4. La distance entre ces représentations vectorielles est emblématique de la nature anormale (ou non) de l'association d'une entité avec une adresse IPv4 (par exemple, envoyer une requête depuis celle-ci).
Les réseaux neuronaux sont presque exactement comme ils sonnent ; ils forment un système d'apprentissage automatique conçu pour se comporter de manière similaire au cerveau humain, avec des neurones et des synapses informatisés. Dans l'apprentissage automatique non supervisé, l'algorithme peut discerner à quoi ressemble le « bon » (c'est-à-dire le vrai négatif) par rapport au « mauvais » (c'est-à-dire le vrai positif) en examinant l'association entre toutes les adresses IPv4 et leurs entités appariées. Cette association est évaluée afin d'identifier quels vecteurs sont similaires aux autres par leur « distance ». Dans le cas d'IP Insights, un encodeur pré-construit est fourni qui recherche les adresses IPv4 puis regroupe toutes les entités en clusters. Il les itère ensuite en utilisant la vectorisation. La vectorisation est une manière d'effectuer des calculs sous forme de matrice au lieu de les parcourir en boucle (pensez à une boucle « For » pour une liste contenant des dizaines de millions de valeurs).
Lorsque vous entraînez un modèle IP Insights, il va en fait se créer lui-même des faux positifs en appariant des adresses IPv4 avec des entités qui ont une grande distance (c'est-à-dire hautement anormales) et qui sont moins susceptibles de se produire dans la réalité ; le modèle peut maintenant faire la distinction entre les vrais positifs, les faux positifs et les vrais négatifs. Cela est fait pour éviter un autre terme complètement dingue appelé « entropie croisée » (AKA « log loss » comme si c'était mieux), et introduit un autre terme, la classification binaire. IP Insights se demande essentiellement : « Quelle est la probabilité que cette adresse IP appariée avec cette entité soit anormale ? » C'est ce qui le rend binaire, je pense, donc « oui c'est mauvais » ou « non ce n'est pas le cas ». La probabilité est représentée comme une valeur entre 0 et 1, le but de tous les modèles d'apprentissage automatique est de la rendre aussi proche de 0 que possible, donc prédire une valeur de 0,01 pour quelque chose qui est réellement 1 (vrai positif connu) entraînerait une perte de log très élevée. Donc, avec tout cela dit, en créant délibérément des données pourries, IP Insights aide à réduire cette perte de log (c'est-à-dire les mauvaises prédictions) pendant l'entraînement.
Cela nous amène à la sortie du point de terminaison. Lorsque vous l'interrogez (soit par lots, soit en quasi-temps réel en utilisant l'API InvokeEndpoint), la réponse est un float non borné qui peut être négatif ou positif. Plus il est élevé au-dessus de 0, plus il est susceptible d'être anormal, et c'est là que votre travail commence. Pour cette solution, j'ai choisi tout ce qui est au-dessus de 0,03, ce qui est largement notionnel ; pour vous rapprocher de la vérité, vous devriez fournir des vrais positifs au point de terminaison et voir quelle est votre réponse. Sur la base de ces résultats, vous pourriez configurer une approche hiérarchisée où votre application pourrait émettre un défi de second facteur, déclencher une alerte ou bloquer carrément selon le score. La réponse à la deuxième partie de la question est « Oui, je pense », entraîner le modèle avec des user-agents appariés à une IP est en fait assez risqué. Maintenant, pour d'autres entités moins volatiles (numéro de compte, nom d'utilisateur, utilisateur IAM), cela semble être l'utilisation prévue.
Dans la solution, je fournis quelques exemples de flux que vous devriez utiliser, certains sont assez évidents comme le flux de domaines de cybercriminalité, Emerging Threats et CI-badguys. Dans mon vrai travail, je travaille avec l'un des spécialistes du renseignement sur les cybermenaces les plus talentueux au monde (sans blague, elle est géniale !), qui a également influencé les choix. Comme pour les modèles d'apprentissage automatique et tout autre chose que vous construirez, vous devez adapter vos flux de renseignements sur les menaces et leur agrégation à votre environnement de menace actuel. Les doublons sont identifiés dans MISP et seule une clé de hachage est spécifiée dans les tables DynamoDB pour garantir l'unicité, donc même si 5 flux rapportent la même adresse IPv4, un seul arrivera dans la table.
Vous pouvez également apporter vos propres plateformes et flux de renseignements sur les menaces commerciaux tels que InfoBlox ou Recorded Future dans cette solution en les pointant vers les tables DynamoDB avec une syntaxe similaire.
La plupart des livraisons de journaux d'AWS sont « au mieux », il n'y a donc pas de SLA officiel publié ; cependant, je suppose qu'il se situe autour de 99,5 à 99,9 %, où tout ce qui se trouve dans les derniers 0,5 à 0,1 % ne sera pas livré. Le trafic « de production » est également de première classe chez AWS ; s'il y a des contraintes de bande passante réseau, il privilégiera par défaut la connectivité vers les clients plutôt que l'envoi de journaux. L'événement le plus probable est que le fichier journal brut était trop volumineux pour que Lambda puisse le traiter entièrement à temps ; vous voyez cela souvent lorsque vous êtes inondé par un DOS ou un crawler depuis la même IP cliente. WAF et ALB regroupent les fichiers journaux par appelant (d'après ce que je peux voir), donc si vous absorbez des centaines de requêtes, le fichier journal peut être très volumineux.
Oui, cependant vous devrez effectuer l'une des actions suivantes :
Il y a des coûts supplémentaires pour cela. Lambda dans un VPC, surtout pour des dizaines d'invocations concurrentes, entraînera probablement plus de problèmes avec les ENI qui persistent et consomment votre espace RFC1918. À moins que vous ne deviez absolument isoler tout le trafic dans votre VPC pour répondre aux exigences de conformité, je ne recommanderais pas cette voie.
Oui, cela est réalisable en modifiant la solution pour publier les journaux formatés finaux dans Kinesis Data Firehose et les pointer vers Splunk.
J'espère avoir un support pour les Route 53 DNS Logs, les S3 Access Logs, les CloudFront Access Logs et les API Gateway Access Logs et peut-être d'autres journaux basés sur l'hôte à l'avenir.
Honnêtement, j'aurais préféré utiliser l'agent Kinesis Data, mais j'ai rencontré beaucoup de problèmes avec lui : Il n'est pas inclus par défaut dans Amazon Linux 2 et maintenant que les AMI Ubuntu 18.04 LTS sont livrées avec Java 11 pré-installé, je rencontrais des problèmes de rétrocompatibilité avec l'agent car il échoue à la construction à moins que vous n'ayez OpenJDK 8 ou 9. Il était beaucoup plus facile d'installer l'agent CloudWatch car il est fréquemment mis à jour avec de nouvelles fonctionnalités et il y a un support de document Systems Manager pour la configuration ; il a même un assistant d'installation. Si AWS prend un jour le support de l'agent Kinesis Data aussi sérieusement que l'agent CloudWatch, je pourrais basculer vers lui car je préférerais de loin publier directement vers Kinesis Data Firehose pour certains journaux basés sur l'hôte (Suricata, Squid, Nginx, Apache) plutôt que d'utiliser CloudWatch Logs comme intermédiaire.
Je suis heureux d'accepter les PR pour les éléments étiquetés « Help Wanted » dans les Issues ou le Tableau de Projet. Je passerai également en revue toute autre PR proposée si elle correspond à l'esprit du projet.
Remerciements particuliers à David Dorsey et Ryan Nolette qui ont fourni des commentaires précieux, des tests et des contributions pour affiner SyntheticSun.
Cette bibliothèque est sous licence GNU General Public License v3.0 (GPL-3.0). Voir le fichier LICENSE.
