Catégorie : Azure (Page 52 of 112)

Azure Security Center | Alerts Suppression Rules

[English below]

Bonjour!

Aujourd’hui, je vais vous présenter une nouvelle fonctionnalité disponible en public preview vous permettant de créer des règles afin de supprimer des alertes détectées par Azure Security Center Threat Protection.

Pour cela, je vous donne rendez-vous dans votre console Azure Security Center et je vous invite à cliquer sur « Suppression rules ».

Nous allons ajouter une nouvelle règle en cliquant sur : « Create new suppression rule »

Nous sélectionnons notre souscription Azure – dans cet exemple : Visual Studio Enterprise. Je vous invite ensuite à sélectionner l’alerte dont vous souhaitez rejeter les résultats. Dans cet exemple, il s’agit de l’alerte : « Role binding to the cluster-admin role detected ».

Nous donnons un nom à cette règle, son statut sera activé et nous pouvons choisir la raison de la création de cette alerte.

Enfin, nous pouvons définir une date de fin d’application de cette règle, et nous pouvons cliquer sur simuler afin de tester notre nouvelle règle. Pour finir, je vous invite à appliquer les modifications en cliquant sur : « Apply »

Nous pouvons constater que notre règle de suppression est désormais activée.

Cette fonctionnalité de suppression d’alertes Azure Security Center peut être vraiment intéressante dans des scénarios où vous avez des alertes qui sont un peu trop verbeuses à votre goût ou encore des faux positifs! Mais attention, ceci peut-être également dangereux : si vous masquez des alertes, vous perdez ainsi la visibilité sur de potentiels incidents de sécurité.

Maxime.


Hello,

In this article, I would like to share with you a new feature of Azure Security Center Threat Protection: Suppression rule

The goal of this new preview feature, released during Microsoft Build 2020 is to suppress false positives or other unwanted security alerts in Azure Security Center.

From the Azure Security Center Console, please click on « Security Alerts » and then click on « Suppression rules ».

In this second step, we will add a new rule. Please click on « Create new suppression rule »

Select your Azure Subscription – in this example: « Visual Studio Enterprise ». And then, select the security alert to hide – in this example: « Role binding to the cluster-admin role detected ».

Define a rule name, select enable for the state of this rule and select a reason.

In this last step, define a rule expiration date and click on the simulate button. To enable this new rule, please click on « Apply ».

As you can see here, our suppression rule is enabled.

When a single alert isn’t interesting or relevant, you can manually dismiss it. Alternatively, use the suppression rules feature to automatically dismiss similar alerts in the future. Typically, you’d use a suppression rule to:

  • suppress alerts that you’ve identified as false positives
  • suppress alerts that are being triggered too often to be useful

Be careful when you create a suppression rule, you loose visibility on potential security incident.

Maxime.

ACR | Chiffrement avec une Customer Managed Key (CMK)!

[English version below]

Bonjour!

Dans cet article, j’ai le plaisir de vous présenter une nouvelle fonctionnalité portant sur le chiffrement de votre Azure Container Registry. Par défaut, lorsque que vous stockez des images dans votre registry de containers Azure, Microsoft chiffre automatiquement le contenu de la registry avec des clés générées par le service lui meme.

Il est désormais possible (en preview à l’heure où j’écris cet article) de rajouter une couche de chiffrement en utilisant une clé que vous générez et stockez dans Azure Key Vault. On parle alors de Customer Managed Key (CMK) – je ne connais pas de traduction française pour ce terme, si vous en avez une, n’hésitez pas à m’en faire part.

Dans un premier temps, nous allons créer ensemble un ressource group:

az group create --name acrcmk --location canadacentral

Puis créez une identité managée de type: user-assigned

az identity create --resource-group acrcmk --name acrcmk-msi

identityID=$(az identity show --resource-group acrcmk --name acrcmk-msi --query 'id' --output tsv)

identityPrincipalID=$(az identity show --resource-group acrcmk --name acrcmk-msi --query 'principalId' --output tsv)

Nous créons notre Azure Key Vault avec la politique d’accès:

az keyvault create --name keyvaultmaxime --resource-group acrcmk --enable-soft-delete --enable-purge-protection

az keyvault set-policy --resource-group acrcmk --name keyvaultmaxime --object-id $identityPrincipalID --key-permissions get unwrapKey wrapKey

Nous générons notre clé depuis cet Azure Key Vault:

az keyvault key create --name keyacr --vault-name keyvaultmaxime
keyID=$(az keyvault key show --name keyacr --vault-name keyvaultmaxime --query 'key.kid' --output tsv)

Enfin, nous créons notre Azure Container Registry avec cette customer-managed key.

az acr create --resource-group acrcmk --name acrcmkmax --identity $identityID --key-encryption-key $keyID --sku Premium

Nous pouvons constater que le chiffrement est désormais activé sur notre registry de containers:

az acr encryption show --name acrcmkmax

Créer des clés et appliquer du chiffrement est une bonne chose, mais réaliser des rotations de ses clés est encore mieux! Je vous recommande donc d’automatiser cette action, tous les 90 jours.

az keyvault key create --name keyacr2 --vault-name keyvaultmaxime

keyID=$(az keyvault key show --name keyacr2 --vault-name keyvaultmaxime --query 'key.kid' --output tsv)

az acr encryption rotate-key --name acrcmkmax --key-encryption-key $keyID --identity acrcmk-msi

Enfin, si vous souhaitez révoquer l’accès d’une clé existante

az keyvault delete-policy --resource-group acrcmk --name keyvaultmaxime --object-id $identityPrincipalID

Pour conclure, cette fonctionnalité nous permet de rajouter une couche de chiffrement pour notre registry de containers (ACR).

Maxime.


Hello,

In this article, I would like to share with you a new security feature of Azure Container Registry : ACR CMK

By default, when you store a container image in ACR, Microsoft applies this own encryption with encrypted generated by the Azure Platform and managed by Microsoft. The goal of this new feature is to allow the use of your own key for the ACR encryption : Customer Managed Key (or CMK).

Please create a ressource group:

az group create --name acrcmk --location canadacentral

Create then a user-assigned managed identity

az identity create --resource-group acrcmk --name acrcmk-msi

identityID=$(az identity show --resource-group acrcmk --name acrcmk-msi --query 'id' --output tsv)

identityPrincipalID=$(az identity show --resource-group acrcmk --name acrcmk-msi --query 'principalId' --output tsv)

Next, create a KeyVault with an access policy

az keyvault create --name keyvaultmaxime --resource-group acrcmk --enable-soft-delete --enable-purge-protection

az keyvault set-policy --resource-group acrcmk --name keyvaultmaxime --object-id $identityPrincipalID --key-permissions get unwrapKey wrapKey

Subsequently, generate a key from our Key Vault

az keyvault key create --name keyacr --vault-name keyvaultmaxime
keyID=$(az keyvault key show --name --vault-name --query 'key.kid' --output tsv)

Finally, create a new Azure Container Registry with CMK feature

az acr create --resource-group acrcmk --name acrcmkmax --identity $identityID --key-encryption-key $keyID --sku Premium

Now, we can check if the encryption is enabled

az acr encryption show --name acrcmkmax

A security best practice is to rotate security key every 90 days. To do so, I recommend you to automate this process.

az keyvault key create --name keyacr2 --vault-name keyvaultmaxime

keyID=$(az keyvault key show --name keyacr2 --vault-name keyvaultmaxime --query 'key.kid' --output tsv)

az acr encryption rotate-key --name acrcmkmax --key-encryption-key $keyID --identity acrcmk-msi

And if you want to revoke the access of an existing key, please use this command

az keyvault delete-policy --resource-group acrcmk --name keyvaultmaxime --object-id $identityPrincipalID

In conclusion, this new security feature adds a new security layer on the top of AKS, and allows you to manage your own key for the encryption of your container images.

Maxime.

AKS | Attack matrix for Kubernetes

[English below]

Bonjour,

Dans cet article, je souhaite vous partager la matrice d’attaque d’une plateforme Kubernetes comme AKS basée sur le framework MITRE.

Dans un premier temps, permettez moi de redéfinir le framework MITRE. Ce framework est une base de connaissances incluant des tactiques et techniques connues et impliquées dans des cyberattaques. Ces matrices aident les organisations à comprendre la surface d’attaque de leur environnement et à s’assurer qu’elles disposent des contrôles de sécurité détectifs et préventifs adéquats à leurs différents risques. Le framework s’appuie sur les catégories suivantes:

  • Accès initial (Initial access)
  • Exécution (Execution)
  • Persistance (Persistence)
  • Escalade de privilèges (Privilege Escalation)
  • Évasion de la défense (Defense evasion)
  • Accès aux informations d’identification (Credential access)
  • Découverte (Discovery)
  • Mouvement latéral (Lateral movement)
  • Impact (Impact)

Vous pouvez retrouver l’article original crée par Yossi Weizman à l’adresse ci-dessous: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/

Maxime.


Hello,

In this article, I would like to share with you the attack matrix for Kubernetes based on MITRE framework.

The MITRE ATT&CK™ framework is a comprehensive matrix of tactics and techniques used by threat hunters, red teamers, and defenders to better classify attacks and assess an organization’s risk.

The aim of the framework is to improve post-compromise detection of adversaries in enterprises by illustrating the actions an attacker may have taken. How did the attacker get in? How are they moving around? The knowledge base is designed to help answer those questions that while contributing to the awareness of an organization’s security posture at the perimeter and beyond. Organizations can use the framework to identify holes in defenses, and prioritize them based on risk.

This framework uses the following categories:

  • Initial access
  • Execution
  • Persistence
  • Privilege Escalation
  • Defense evasion
  • Credential access
  • Discovery
  • Lateral movement
  • Impact
L’attribut alt de cette image est vide, son nom de fichier est k8s-matrix-1024x545.png.

Please find the following article created by Yossi Weizman: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/

Maxime.

« Older posts Newer posts »

© 2025 ZiGMaX IT Blog

Theme by Anders NorenUp ↑