Uncover the latest cloud data security capabilities from Microsoft Defender for Cloud
Learn about the latest multicloud data security capabilities from Microsoft Defender for Cloud to strengthen your data security posture and protect your cloud data estate against data breaches and malware distribution.App Assure’s promise: Migrate to Sentinel with confidence
In today's evolving cyber-threat landscape, enterprises need the most up-to-date tools for detection, investigation, and response. Cloud-native, AI-driven solutions like Microsoft's Sentinel provide businesses with faster implementation, greater integration and automation capabilities, and intelligent event correlation. But when moving from on-prem to the cloud, or from one SIEM to another, migrating can seem risky and complex for Security Operations Centers (SOCs) that have spent years investing in customized solutions. One challenge businesses face is how to port over third-party connectors, especially ones processing large data volumes, which can reach terabytes per day. For customers with such needs, Microsoft has built the Codeless Connector Framework (CCF) in Microsoft Sentinel. Microsoft Sentinel’s Codeless Connector Framework reduces friction for enterprises migrating to the cloud For enterprises ready to modernize their security operations, Microsoft recommends leveraging integrations built on CCF. These integrations are built to handle large data workloads and provide a number of powerful benefits: CCF connectors are a scalable and reliable SaaS offering, capable of handling high-volume data ingestion effortlessly. Its Data Collection Rules (DCRs) enable log filtering and transformation at ingestion, reducing data volume and lowering costs. CCF also streamlines installation and deployment. What formerly took hundreds of lines of code to configure, now takes a few simple mouse clicks. CCF communication is conducted privately between Microsoft services without being exposed to the public internet, thus aligning with Microsoft's security best practices to provide a secure and robust integration environment. What makes CCF an even more compelling and powerful tool is that our App Assure team stands behind the platform to uphold Microsoft’s Sentinel compatibility promise. Microsoft’s Sentinel promise How App Assure delivers on this promise Backed by Microsoft engineering, App Assure is here to help. If a Microsoft Sentinel ISV solution is not yet available or you have an issue with a solution already published by an ISV, App Assure may be able to assist with the following customer scenarios: Working with ISVs to develop new CCF solutions. Working with ISVs to add new features to existing CCF solutions. For supported scenarios, an App Assure Manager will be assigned to guide you through the process, ensuring you can leverage the full power of Sentinel. For customer scenarios that are not supported, App Assure will help you identify available resources. To engage App Assure and learn more about what we support, submit a request for assistance. Partner Testimonials App Assure has already been working with many ISVs on behalf of our customers to fulfil Microsoft’s Sentinel promise. Two recent engagements where we facilitated the integration of tools that our customers rely on include: 1Password NetskopeAnnouncing the enhanced Microsoft Sentinel AWS CloudTrail solution, powered by new MITRE-Based Rules
Use the updated Microsoft Sentinel AWS CloudTrail solution to better protect your AWS environment. The updated solution includes over 70 MITRE-based rules, and monitoring and alerting capabilities to detect suspicious activity in your environment.
The Risk of Default Configuration: How Out-of-the-Box Helm Charts Can Breach Your Cluster
Authors: Michael Katchinskiy, Security Researcher, Microsoft Defender for Cloud Research Yossi Weizman, Principal Security Research Manager, Microsoft Defender for Cloud Research Have you ever used pre-made deployment templates to quickly spin up applications in Kubernetes environments? While these “plug-and-play” options greatly simplify the setup process, they often prioritize ease of use over security. As a result, a large number of applications end up being deployed in a misconfigured state by default, exposing sensitive data, cloud resources, or even the entire environment to attackers. Cloud-native applications are software systems designed to fully leverage the flexibility and scalability of the cloud. These applications are broken into small services called microservices. Usually, each service is packaged in a container with all its dependences, making it easy to deploy across different environments. Kubernetes then orchestrates these services, automatically handling their deployment, scaling, and health checks. Out-of-the-Box Helm Charts Open-source projects usually contain a section explaining how to deploy their apps “out of the box” on their code repository. These documents often include default manifests or pre-defined Helm charts that are intended for ease of use rather than hardened security. Among other issues, two significant security concerns arise: (1) exposing services externally without proper network restrictions and (2) lack of adequate built-in authentication or authorization by default. Internet exposure in Kubernetes usually originates in a LoadBalancer service, which exposes K8s workloads via an external IP for direct access, or in Ingress objects, which manage HTTP and HTTPS traffic to internal services. If authentication is not properly configured, both can allow insecure access to the applications, leading to unauthorized access, data exposure, and potential service abuse. Consequently, default configurations that lack proper security controls create a severe security threat. Without carefully reviewing the YAML manifests and Helm charts, organizations may unknowingly deploy services lacking any form of protection, leaving them fully exposed to attackers. This is particularly concerning when the deployed application can query sensitive APIs or allow administrative actions, which is exactly what we will shortly see. Apache Pinot default configuration Apache Pinot is a real-time, distributed OLAP datastore designed for high-speed querying of large-scale datasets with low latency. For Kubernetes installations, Apache Pinot’s official documentation refers users to a Helm chart stored in their official Github repository for a quick installation: While Apache Pinot's documentation states that the provided configuration is a reference setup that users may want to modify, they don’t mention that this configuration is severely insecure, leaving the users prone to data theft attacks: The default installation exposes Apache Pinot’s main components to the internet by Kubernetes LoadBalancer services without providing any authentication mechanism by default. Specifically, the pinot-broker and pinot-controller services allow unauthenticated access to query the stored data and manage the workload. Below is a screenshot of Pinot’s dashboard, exposed by the pinot-controller service in port 9000, allowing full management of the Apache Pinot and access to the stored information. Recently, Microsoft Defender for Cloud identified several incidents in which attackers exploited misconfigured Apache Pinot workloads, allowing them to access the data of Apache Pinot users. Not Just Apache Pinot To determine how widespread this issue is, we conducted a thorough investigation by searching using GitHub Code Search repositories for YAML files containing strings that may indicate on misconfigured workload, such as “type: LoadBalancer”. We then sorted the results by their popularity and deployed the applications in controlled test environments to assess their default security posture. Our goal was to find out which applications are exposed to the internet by default, more critically, whether they incorporate any authentication or authorization mechanisms. Here's what we found: The majority of applications we evaluated had at least some form of basic password protection, though the strength and reliability of these measures varied significantly. A small but critical group of applications either provided no authentication at all or used a predefined user and password for logging in, making them prime targets for attackers. Sign me up Several applications appeared secure at first glance, but they allowed anyone to create a new account and access the system. This clearly does not provide effective protection when exposed to the internet. This highlights how a “default by convenience” approach can invite risk when security settings are not thoroughly reviewed or properly configured. Meshery is an engineering platform for collaborative design and operation of cloud native infrastructure. By default, when installing Meshery on your Kuberentes cluster via the official Helm installation, the app’s interface is exposed via an external IP address. We discovered that anyone who can access the external IP address can sign up with a new user and access the interface which provides extensive visibility into cluster activities and even enable the deployment of new pods. These capabilities grant attackers a direct path to execute arbitrary code and gain control of underlying resources if Meshery is not secured or restricted to internal networks only. Selenium Grid Selenium is a popular tool for automating web browser testing, with millions of downloads of its container image. In the last few months, we’ve observed multiple attack campaigns specifically targeting Selenium Grid instances that lack authentication. In addition several security vendors, including Wiz and Cado Security, have reported these attacks. While the official Helm chart for Selenium Grid doesn’t expose it to the internet, there are several widely referenced GitHub projects that do - using a LoadBalancer or a NodePort. In one Selenium deployment example from the official Kubernetes repository, Selenium is set up to use a NodePort. This configuration exposes the service on a specific port across all nodes in your cluster, meaning that the firewall rules set up in your network security group become your primary and often only line of defense. If you'd like to see additional examples, try using GitHub Code Search with this query. Awareness of the risks associated with exposing services has grown over the years, and many developers today understand the dangers of leaving applications wide open. Even so, some applications simply weren’t built for external access and don’t provide any built-in authentication. Their own documentation often warns users not to expose these services publicly. Yet, it still happens, usually for convenience, leaving entire clusters at risk. If you still remain unconvinced, look to the countless unsecured Redis, Elasticsearch, Prometheus, and other instances that are regularly surfaced in Shodan scans and security blog posts. Despite years of warnings, these applications are still being exposed. Conclusion Many in-the-wild exploitations of containerized applications originate in misconfigured workloads, often when using default settings. Relying on “default by convenience” setups pose a significant security risk. To mitigate these risks, it is crucial to: Review before you deploy: Don’t rely on default configurations. Review the configuration files and modify them according to security best practices. This includes enforcing strong authentication mechanism and network isolation. Regularly scan your organization to exposed services: Scan the publicly facing interfaces of your workloads. While some workloads should allow access from external endpoints, in many cases this exposure should be reconsidered. Monitor your containerized applications: Monitor the running containers in your environment for malicious and suspicious activities. This includes monitoring of the running processes, network traffic, and other activities performed by the workload. Also, many container-based attacks involve deployment of backdoor containers in the cluster. Monitor the Kubernetes cluster for unknown workloads and the nodes for unknown pulled images. Strengthening Cluster Security with Microsoft Defender for Cloud Microsoft Defender for Cloud (MDC) helps protect your environment from misconfigurations, including risky service exposure. For example, MDC alerts on the exposure of Kubernetes services which are associated with sensitive interfaces, including Apache Pinot. With Microsoft Defender CSPM, you can get an overview of the exposure of your organization’s cloud environment, including the containerized applications. Using the Cloud Security Explorer, you can get full visibility of the internet exposed workloads in your Kubernetes clusters, enabling you to mitigate potential risks and easily identify misconfiguration. Read more about Containers security with Microsoft Defender for containers here.Microsoft Defender for Cloud - Elevating Runtime Protection
In today's rapidly evolving digital landscape, runtime security is crucial for maintaining the integrity of applications in containerized environments. As threats become increasingly sophisticated, the demand for more adaptive protection continues to rise. Attackers are no longer relying on generic exploits — they are actively targeting vulnerabilities in container configurations, runtime processes, and shared resources. From injecting malicious code to escalating privileges and exploiting kernel vulnerabilities, their tactics are constantly evolving. Overcoming these challenges requires continuous monitoring, validating container immutability, and detecting anomalies to prevent and respond to threats in real time, ensuring container security throughout their lifecycle. Building on these best practices, Microsoft Defender for Cloud delivers advanced and innovative runtime threat protection for containerized environments, providing real-time defense and adaptive security to address evolving threats head-on. Empowering SOC with real-time threat detection At the heart of our enhanced runtime protection lies our advanced detection capabilities. To stay ahead of evolving threats and offer near real-time threat detection, Microsoft Defender for Cloud is proud to announce significant advancements in its unique eBPF sensor. This sensor now provides Kubernetes alerts, powered by Microsoft Defender for Endpoint (MDE) detection engine in the backend. Leveraging Microsoft’s industry-leading security expertise, we've tailored MDE's robust security capabilities to specifically address the unique challenges of containerized environments. By carefully validating detections against container-specific threat landscapes, adding relevant context, and adjusting alerts as needed, we've optimized the solution for maximum accuracy and effectiveness that is needed for cloud-native environments. By utilizing the MDE detection engine, we offer the following enhancements: Near real-time detection: Our solution provides timely alerts, enabling you to respond quickly to threats and minimize their impact. Expanded threat coverage: We've expanded our detection capabilities to cover a broader range of threats such as binary drift and additional threat matrix coverage. Enhanced visibility: Gain deeper insights into your container environment with detailed threat information and context that is sent to Defender XDR for further investigation. Switching between multiple portals leaves customers with a fragmented view of their security landscape, hindering their ability to investigate and respond to security incidents efficiently. To combat this, Defender for Cloud alerts are integrated with Defender XDR. By centralizing alerts from both solutions within Defender XDR, customers can gain comprehensive visibility of their security landscape and simplify incident detection, investigation, and response effectively. Introducing binary drift detection to maintain optimal security and performance, containerized applications should strictly adhere to their defined boundaries. With binary drift detection in place, unauthorized code injections can be swiftly identified. By comparing the modified container image against the original, the system detects any discrepancies, enabling timely response to potential threats. By combining binary drift detection with other security measures, organizations can reduce the risk of exploitation and protect their containerized applications from malicious attacks. An example of binary drift detection Key takeaways from above illustration: Common Vulnerability and Exposures (CVE) pose significant risks to containerized environments. Binary drift detection can help identify unauthorized changes to container images, even if they result from CVE exploitation. Regular patching and updating of container images are crucial to prevent vulnerabilities. In some customer environments, it's common to deviate from best practices. For example, tasks like debugging and monitoring often require running processes that aren’t part of the original container image. To handle this, we offer binary drift detection along with a flexible policy system. This lets you choose when to receive alerts or ignore them. You can customize these settings based on your cloud environment or by filtering specific Kubernetes resources. Learn more about binary drift detection For a deep dive into binary drift detection and how it can enhance your container security posture, please see Container, Security, Kubernetes. Presenting new scenario-driven alert simulation Simulate real-world attack scenarios within your containerized environments with this innovative simulator, enabling you to test your detection capabilities and response procedures. You can enhance your security posture and protect your containerized environments from emerging threats by leveraging this powerful tool. Examples of some of the attack scenarios that can be simulated using this tool are: Reconnaissance activity: Mimic the actions of attackers as they gather information about your cluster. Cluster-to-cloud: Simulate lateral movement as attackers attempt to spread across your environment. Secret gathering: Test your ability to detect attempts to steal sensitive information. Crypto-mining activity: Simulate the impact of resource-intensive crypto-mining operations. Webshell invocation: Test your detection capabilities for malicious web shells. You can gain valuable insights into your security controls and identify areas for improvement. This tool provides a safe and controlled environment to practice incident response, ensuring that your team is well-prepared to handle real-world threats. Key benefits of scenario-driven alert simulation: Test detection capabilities: Validate your ability to identify and respond to various attack types. Validate response procedures: Ensure your incident response teams are prepared to handle real-world threats. Identify gaps in security: Discover weaknesses in your security posture and address them proactively. Improve incident response time: Practice handling simulated incidents to reduce response times in real-world situations. Alert simulation tool Enhancing Cloud Detection and Response (CDR) From detection to resolution, we've streamlined every step of the process to ensure robust and efficient threat management. By enabling better visibility, faster investigation, and precise response capabilities, SOC teams can confidently address container threats, reducing risks and operational disruptions across multi-cloud environments. Cloud-native response actions for containers Swift and precise containment is critical in dynamic, containerized environments. To address this, we’ve introduced cloud-native response actions in Defender XDR, enabling SOC teams to: Cut off unauthorized pod access and prevent lateral movement by instantly isolating compromised pods. Stop ongoing malicious pod activity and minimize impact by terminating compromised pods with a single click. These capabilities are specifically designed to meet the unique challenges of multi-cloud ecosystems, empowering security teams to reduce Mean Time to Resolve (MTTR) and ensure operational continuity. Response actions Action center view Log collection in advanced hunting Limited visibility in Kubernetes activities, cloud infrastructure changes, and runtime processes weakens effective threat detection and investigation in containerized environments. To bridge this gap, we’ve enhanced Defender XDR’s advanced hunting experience by collecting: KubeAudit logs: Delivering detailed insights into Kubernetes events and activities. Azure Control Plane logs: Providing a comprehensive view of cloud infrastructure activities. Process events: Capturing detailed runtime activity. This enriched data enables SOC teams to do deeper investigations, hunt for advanced threats, and create custom detection rules. With full visibility across AKS, EKS, and GKE, these capabilities strengthen defenses and support proactive security strategies. Advance hunting view Accelerating investigations with built-in queries Lengthy investigation processes can delay incident resolution and can potentially lead to a successful attack attempt. To address this, we’ve equipped go hunt with pre-built queries specifically tailored for cloud and containerized threats. These built-in queries allow SOC teams to: Focus their time in quickly identifying attacker activity and not write custom queries. Gain insights in minutes vs. hours, reducing the investigation time enormously. This streamlined approach enhances SOC efficiency, ensuring that teams spend more time on remediation and less on query development. Go hunt view Bridging knowledge gaps with guided response using Microsoft Security Copilot Many security teams, especially those working in complex environments like containers, may not have deep expertise in every aspect of container threat response. Additionally, security teams might encounter threats or vulnerabilities they haven’t seen before. We are excited to integrate with Security Copilot to bridge this gap. Security Copilot serves as a valuable tool that offers: Step-by-step, context-rich guidance for each incident. Tailored recommendations for effective threat containment and remediation. By leveraging AI-driven insights, Security Copilot empowers SOC teams of varying expertise levels to navigate incidents with precision, ensuring consistent and effective responses across the board. Security copilot recommendations Summary Microsoft Defender for Cloud has introduced significant advancements in runtime protection for containerized environments. By leveraging the Microsoft Defender for Endpoint (MDE) detection engine, this solution now offers near real-time threat detection, enhancing threat visibility and response capabilities. A key feature, binary drift detection, monitors changes in container images to identify unauthorized modifications and prevent security breaches. Additionally, the integration with Defender XDR centralizes alerts, providing comprehensive visibility and simplifying incident detection, investigation, and response. With enhanced cloud-native response actions and advanced hunting capabilities, SOC teams can confidently address container threats, reducing risks and operational disruptions across multi-cloud environments. Learn more Ready to elevate your container security? Experience the power of our new features firsthand with our cutting-edge simulator—test them in your containerized environments and see the difference! Alerts for Kubernetes Clusters - Microsoft Defender for Cloud | Microsoft LearnAZ-500: Microsoft Azure Security Technologies Study Guide
The AZ-500 certification provides professionals with the skills and knowledge needed to secure Azure infrastructure, services, and data. The exam covers identity and access management, data protection, platform security, and governance in Azure. Learners can prepare for the exam with Microsoft's self-paced curriculum, instructor-led course, and documentation. The certification measures the learner’s knowledge of managing, monitoring, and implementing security for resources in Azure, multi-cloud, and hybrid environments. Azure Firewall, Key Vault, and Azure Active Directory are some of the topics covered in the exam.
