Malware Scanning for Defender for Storage

Hi,

The malware scanning feature in Microsoft Defender for Storage scans files stored in Azure Blob Storage and Azure Files to detect and remove malware. The scanning process is automatic and continuous, ensuring that your data is always protected. When malware is detected, Microsoft Defender for Storage takes action to remove the threat and prevent it from spreading to other files or systems.

Microsoft Defender for Storage supports both real-time and on-demand scanning. Real-time scanning is performed automatically when files are uploaded to Azure Blob Storage or Azure Files. On-demand scanning can be initiated manually through the Azure portal or using PowerShell scripts. On-demand scanning is useful for detecting and removing malware that may have evaded real-time scanning or for scanning files that have been in storage for some time.

Microsoft Defender for Storage provides detailed reporting and alerts when malware is detected. Reports are available through the Azure portal and provide detailed information on the type of malware detected, the location of the infected files, and the actions taken to remove the threat. Alerts can be configured to notify security teams when malware is detected, allowing them to take immediate action to protect your data.

Limitations:

  • Legacy v1 storage accounts aren’t supported
  • Azure Files isn’t supported for Malware Scanning
  • Client-side encrypted blobs aren’t supported (they can’t be decrypted before scan by the service). [data encrypted at rest by CMK is supported].
  • File size limit is 2 GB
  • The “capping” mechanism is currently not functional. You can set your limitations now, and they’ll set in when “capping” starts working.
  • Malware Scanning scan throughput rate limit per-storage-account – 2GB/min
  • Uploading in a higher rate results in a slow-down scan – files are scanned later
  • Index tag scan result isn’t supported in storage account with Hierarchical namespace enabled (Azure Data Lake Storage Gen2)
  • Append and Page blobs aren’t supported for Malware Scanning.

Source: https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-storage-malware-scan

Maxime.

New alert in Azure Defender for Key Vault

Hi!

Azure Defender for Key Vault has the following new alert:

Alert (alert type)DescriptionMITRE tacticsSeverity
Denied access from a suspicious IP to a key vault
(KV_SuspiciousIPAccessDenied)		An unsuccessful key vault access has been attempted by an IP that has been identified by Microsoft Threat Intelligence as a suspicious IP address. Though this attempt was unsuccessful, it indicates that your infrastructure might have been compromised. We recommend further investigations.Credential AccessLow

You can see a list of all of the alerts available for Key Vault.

Maxime.

AKS | Pod Sandboxing

Hi!

In a traditional Kubernetes cluster, pods share the same node and therefore have the same level of access to the host system. This can lead to potential security risks, particularly if a malicious actor gains access to a vulnerable pod. Pod sandboxing in AKS addresses this issue by creating a dedicated container for each pod, which is isolated from other pods and the host system.

AKS pod sandboxing achieves this isolation by running each pod in its own container, using the gVisor sandboxing technology. gVisor is an open-source sandboxing solution that provides a lightweight, container-based isolation mechanism for running untrusted workloads. This approach enables AKS to provide a secure runtime environment for each pod, without sacrificing performance or scalability.

AKS pod sandboxing also provides a number of other security features, including encryption at rest for pod volumes, network isolation through virtual networks, and integrated identity and access management through Azure Active Directory. These features help to protect sensitive data and prevent unauthorized access to Kubernetes resources.

To use AKS pod sandboxing, users can simply enable the feature when creating a new AKS cluster. Once enabled, all pods deployed to the cluster will be automatically sandboxed, providing an added layer of security and isolation.

In summary, pod sandboxing is an important technique for securing Kubernetes workloads, particularly in multi-tenant environments. AKS pod sandboxing provides a powerful and easy-to-use solution for isolating pods from one another and from the host system, using the lightweight gVisor sandboxing technology. By enabling AKS pod sandboxing, users can improve the security and reliability of their Kubernetes deployments, while maintaining performance and scalability.

How it works:

To achieve this functionality on AKS, Kata Containers running on Mariner AKS Container Host (MACH) stack delivers hardware-enforced isolation. Pod Sandboxing extends the benefits of hardware isolation such as a separate kernel for each Kata pod. Hardware isolation allocates resources for each pod and doesn’t share them with other Kata Containers or namespace containers running on the same host.

The solution architecture is based on the following components:

  • Mariner AKS Container Host
  • Microsoft Hyper-V Hypervisor
  • Azure-tuned Dom0 Linux Kernel
  • Open-source Cloud-Hypervisor Virtual Machine Monitor (VMM)
  • Integration with Kata Container framework

To use this feature with a pod, the only difference is to add runtimeClassName kata-mshv-vm-isolation to the pod spec.

Limitations:

Enable Pod Sandboxing to an existing AKS cluster:

az aks nodepool add --cluster-name myAKSCluster --resource-group myResourceGroup --name nodepool2 --os-sku mariner --workload-runtime KataMshvVmIsolation --node-vm-size Standard_D4s_v3

az aks update --name myAKSCluster --resource-group myResourceGroup

Documentation: https://learn.microsoft.com/en-gb/azure/aks/use-pod-sandboxing

Maxime.