Az Update: Azure Cloud Shell enhancements, Azure DB security enhancements and more

by Scott Muniz | Aug 14, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

Lots of news surrounding Azure security and hybrid offerings this week. Here are a couple of the news items we are covering this week: Azure Database for PostgreSQL Data encryption enhancements announced, New Microsoft Learn Modules for Azure and Windows Server IT Pros, Exchange Server 2016 End of Mainstream Support and Azure Cloud Shell running in an isolated virtual network and tools image open sourced.

Azure Database for PostgreSQL Data encryption enhancements announced

Azure Database for PostgreSQL Infrastructure double encryption (preview)

The preview of infrastructure double encryption for Azure Database for PostgreSQL-single server is now available. Infrastructure double encryption adds a second layer of encryption using a FIPS 140-2 validated cryptographic module and a different encryption algorithm which gives an additional layer of protection for your data at rest. The key used in Infrastructure Double encryption is also managed by this service. This feature is not turned on by default as it will have performance impact due to the additional layer of encryption.

Data encryption with customer managed keys for Azure DB for PostgreSQL-single server

Data encryption with customer-managed keys for Azure Database for PostgreSQL-single server enables you to bring your own key (BYOK) for data protection at rest. It also allows organizations to implement separation of duties in the management of keys and data. With customer-managed encryption, you are responsible for, and in a full control of, a key’s lifecycle, key usage permissions, and auditing of operations on keys.

New Microsoft Learn Modules for Azure and Windows Server IT Pros

Whether you’re just starting or an experienced professional, the hands-on approach helps you arrive at your goals faster, with more confidence and at your own pace. In the last couple of days, the team at Microsoft published a couple of new Microsoft Learn modules around Azure, Hybrid Cloud, and Windows Server for IT Pros. These modules help you to learn how you can leverage Microsoft Azure in a hybrid cloud environment to manage Windows Server.

Exchange Server 2016 and the End of Mainstream Support

Microsoft has announced that Exchange Server 2016 enters the Extended Support phase of its product lifecycle on October 14th, 2020.  During Extended Support, products receive only updates defined as Critical consistent with the Security Update Guide. For Exchange Server 2016, critical updates will also include any required product updates due to time zone definition changes. With the transition of Exchange Server 2016 to Extended Support, the quarterly release schedule of cumulative updates (CU) will end. The last planned CU for Exchange Server 2016, CU19, will be released in December 2020.

Azure Cloud Shell enhancements announced

Azure Cloud Shell can now run in an isolated virtual network (public preview)

Microsoft announced the public preview of Azure Cloud Shell running inside a private virtual network. This widely requested and optional feature allows you deploy a Cloud Shell container into an Azure virtual network that you control. Once you connect to Cloud Shell, you can interact with resources within the virtual network you selected. This allows you to connect to virtual machines that only have a private IP, use kubectl to connect to a Kubernetes cluster which has locked down access, or connect to other resources that are secured inside a virtual network.

The Azure Cloud Shell tools image is now open sourced

The Cloud Shell experience contains common command line tools to manage resources across both Azure and M365 and can now be found on GitHub. You can now file issues or pull requests directly to the tools image, and any changes that occur there will be reflected in the next release of Cloud Shell. You can use this container image in other management scenarios, with many tools already installed and updated regularly, removing the concern about updating your cloud management tools.

MS Learn Module of the Week

Implement hybrid identity with Windows Server

These hands-on-labs share details on how to configure an Azure environment so that Windows IaaS workloads requiring Active Directory are supported. You’ll also learn to integrate on-premises Active Directory Domain Services (AD DS) environment into Azure.

Let us know in the comments below if there are any news items you would like to see covered in next week show.  Az Update streams live every Friday so be sure to catch the next episode and join us in the live chat.

Azure API Management limitation workaround: Return 404 instead of 405 when the HTTP method not match

by Scott Muniz | Aug 14, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

This article provides a workaround for the limitation on API Management for returning 404 Operation Not Found instead of 405 Method Not Allowed. There is a Azure feedback and the Stack overflow about this limitation.

Current Status for API Management

Defining API in APIM including creating the resources and allowed methods for each resource.

1. Define a POST API:

2. Test the API with POST method via Postman:

3. Change the HTTP Method to GET or other methods, it returns with 404 operation not found:

The error returned by APIM in this scenario does not follow the definition of HTTP status code strictly. There was feedback that this is still a limitation for APIM and product team updated that there is still no plan on it.

Workaround:

1. Handle the error

When APIM failed to identify an API or operation for the request, it will raise a configuration error which Responses the caller with 404 Resource Not Found. We need to handle this kind of configuration error by referring the Error Handling for APIM, this kind of error can be specified with configuration Error source and OperationNotFound Error reason.  We can define a policy to single API or all of our APIs to capture the error, and set the status code to HTTP 405.

2. Define the policy to all APIs:

Policy Code:

      <choose>
            <when condition="@(context.LastError.Source == "configuration" && context.LastError.Reason == "OperationNotFound")">
                <return-response>
                    <set-status code="405" reason="Method not allowed" />
                    <set-body>@{
                    return new JObject(
                        new JProperty("status", "HTTP 405"),
                        new JProperty("message", "Method not allowed"),
                        new JProperty("text", context.Response.StatusCode.ToString()),
                        new JProperty("errorReason", context.LastError.Message.ToString())
                    ).ToString();
                }</set-body>
                </return-response>
            </when>
            <otherwise />
        </choose>

You may wonder how the condition context.LastError.Source == “configuration” && context.LastError.Reason == “OperationNotFound” will specify this type of error, from the error OCP trace, we can see the an error is thrown with message in Configuration section “OperationNotFound”:

when this type error occurred during the evaluation, the error source will be captured as configuration. It will not forward request further. To exclude other configuration error, we need specify the error reason as “OperationNotFound”.

3. Test the API with wrong HTTP method:

Tested on all APIs and with all wrong methods, it will get 405 Method Not Allowed.

Related links:

Error Handling for APIM

Hope this can be useful!

Monitoring Azure Kubernetes Service (AKS) with Azure Sentinel

by Scott Muniz | Aug 13, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

In 2020 Kubernetes only marked its sixth birthday, but in that time its usage has grown exponentially and it is now considered a core part of many organization’s application platforms. The flexibility and scalability of containerized environments makes deploying applications as microservices in containers very attractive and Kubernetes has emerged as the orchestrator of choice for many. Azure offers Azure Kubernetes Service (AKS) where your Kubernetes cluster is managed and integrated into the platform. In this blog we are going to look at how you can use Azure Sentinel to monitor your AKS clusters for security incidents.

Overview

There are several sources that you can use to help monitor your AKS cluster, of which you can deploy one or several in tandem depending on your environment and the security posture of your organization. We will be looking at the following detection sources that you can integrate into Sentinel:

• Azure Security Center (ASC) AKS threat protection
• Azure Diagnostics logs
• Third party tool alert integration

Below is a diagram illustrating how these different sources integrate into Azure Sentinel:

Before we dive into each of these sources, I want to mention an excellent piece of work created by my colleague Yossi Weizman where he created a threat matrix for Kubernetes clusters, aligned to the MITRE ATT&CK framework. You can read his full article here but we will refer to this threat matrix when assessing whether you have considered if this scenario is applicable to your AKS implementation, and if it is, how you can get visibility of this happening in your environment.

Azure Security Center (ASC) AKS threat protection

Azure Security Center Standard has threat protection built-in for the resources that it monitors. ASC has an optional Kubernetes bundle that you can enable, and ASC threat protection will look at your AKS cluster for signs of suspicious activity. To enable the AKS bundle in ASC, go to “Pricing & settings”, select the subscription and make sure the “Kubernetes” resource type is enabled, as per the below:

(The ASC Kubernetes bundle also provides security configuration and hardening recommendations for your AKS cluster, but that is outside the scope of this blog post. You can read more about this here.)

If you have already connected ASC threat alerts to your Azure Sentinel workspace via the native ASC connector these AKS threat alerts will also be sent directly into Azure Sentinel. Some of the threats that ASC can detect in your AKS cluster are below:

• Container with a sensitive volume mount detected
• Digital currency mining container detected
• Exposed Kubernetes dashboard detected

For an up-to-date list of ASC AKS-specific detections, please go here.

To turn on Kubernetes in Azure Security Center, go to ASC Pricing & Settings, in the Select pricing tier by resource type, you need to Enable Kubernetes and Container Registries.

Azure Diagnostics logs

If you have use cases not covered by ASC threat detections, you can also turn on AKS diagnostic logs and send to a Log Analytics workspace (you may notice that some documents referenced here refer to Azure Monitor. Note that Log Analytics is part of the larger Azure Monitor platform.) Follow the steps found here to enable resource logging. The logs that can be retrieved from AKS in this manner include:

• kube-apiserver
• kube-controller-manager
• kube-scheduler
• kube-audit
• cluster-autoscaler

After you have enabled the logging to be sent your Log Analytics workspace, you can start to run detections on these logs. These logs will be sent to the AzureDiagnostics table.

Let’s look at a basic query you can on these logs in Sentinel to look at (in this case) an NGINX pod:

AzureDiagnostics
| where Category == "kube-apiserver"
| where log_s contains "pods/nginx"
| project log_s

Now let’s look at some more security-focused queries that you can run on AKS logs. Note that we are using the threat matrix mentioned earlier in this blog as a guide for the manner of detections one may require on an AKS cluster:

# query for cluster-admin clusterrolebinding + extend columns
# detects: kubectl create clusterrolebinding my-svc-acct-admin --clusterrole=cluster-admin --serviceaccount=brianredmond 

AzureDiagnostics
| where Category == "kube-audit"
| where parse_json(log_s).verb == "create"
| where parse_json(tostring(parse_json(tostring(parse_json(log_s).requestObject)).roleRef)).name == "cluster-admin"
| where parse_json(tostring(parse_json(log_s).requestObject)).kind == "ClusterRoleBinding"
| extend k8skind = parse_json(tostring(parse_json(log_s).requestObject)).kind
| extend k8sroleref = parse_json(tostring(parse_json(tostring(parse_json(log_s).requestObject)).roleRef)).name
| extend k8suser = parse_json(tostring(parse_json(log_s).user)).username
| extend k8sipaddress = parse_json(tostring(parse_json(log_s).sourceIPs))[0]

# query for CronJob creation

AzureDiagnostics
| where Category == "kube-audit"
| where parse_json(log_s).verb == "create"
| where parse_json(tostring(parse_json(log_s).requestObject)).kind == "CronJob"

# query for actions from standard user account (az aks get-credentials)

AzureDiagnostics
| where Category == "kube-audit"
| project log_s
| where parse_json(tostring(parse_json(log_s).user)).username == "masterclient"

# query for specific source IP

AzureDiagnostics
| where Category == "kube-audit"
| project log_s
| where parse_json(tostring(parse_json(log_s).sourceIPs))[0] == "192.168.1.1"

# query for RBAC result (allow, deny, etc.)

AzureDiagnostics
| where Category == "kube-audit"
| project log_s
| where parse_json(log_s).verb == "create"
| where parse_json(tostring(parse_json(log_s).annotations)).["authorization.k8s.io/decision"] == "allow"

# query for Azure RBAC AKS role assignment

AzureActivity
| where OperationName == "Create role assignment"
| extend RoleDef = tostring(parse_json(tostring(parse_json(tostring(parse_json(Properties).requestbody)).Properties)).RoleDefinitionId)
| extend  Caller = tostring(parse_json(tostring(parse_json(tostring(parse_json(Properties).requestbody)).Properties)).Caller)
| where RoleDef contains "8e3af657-a8ff-443c-a75c-2fe8c4bcb635" or RoleDef contains "b24988ac-6180-42a0-ab88-20f7382dd24c"
| extend AccountCustomEntity = Caller
| extend IPCustomEntity = CallerIpAddress
| extend URLCustomEntity = HTTPRequest
| extend HostCustomEntity = ResourceId

Of course, this is just a start – there are many more AKS detections you could create with these logs that will be specific to your organization’s use cases and environment.

Third party tools

If you are using a third-party Kubernetes monitoring tool, this can also be integrated into Sentinel. At the time of writing, we already have a native connector for Alcide kAudit, but look for more native integrations to come in the future!

Remember, if you are using a third party tool that does not yet have a native connector in Sentinel, you can still integrate the logs using a custom connector. For example, Twistlock offers a number of ways to pull the audit events from the product itself.

Summary

Sentinel offers many options for monitoring AKS clusters, so we recommend that you look at your organization’s environment and the tools you have available to decide on a strategy that works best for you. Do you have some AKS-specific detections, Workbooks or something else to share? Please contribute to our GitHub repo here and share with the community!

With thanks to @GeorgeWilburn for his AKS queries and @Nicholas DiCola (SECURITY JEDI) and @Chi Nguyen for their comments and feedback on this article.

Assigning groups to Azure AD roles is now in public preview!

by Scott Muniz | Aug 13, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

Howdy folks,

Today, we’re excited to share that you can assign groups to Azure Active Directory (Azure AD) roles, now in public preview. Role delegation to groups is one of the most requested features in our feedback forum. Currently this is available for Azure AD groups and Azure AD built-in roles, and we’ll be extending this in the future to on-premises groups as well as Azure AD custom roles.

To use this feature, you’ll need to create an Azure AD group and enable it to have roles assigned. This can be done by anyone who is either a Privileged Role Administrator or a Global Administrator.

After that, any of the Azure AD built-in roles, such as Teams Administrator or SharePoint Administrator, can have groups assigned to them.

The owner of the group can then manage group memberships and control who can get the role, allowing you to effectively delegate the administration of Azure AD roles and reduce the dependency on Privileged Role Administrator or Global Administrator. 

You can also use this along with Privileged Identity Management (PIM) to enable just-in-time role assignment for the group. With this integration, each member of the group activates their role separately when needed and their access is revoked when the role assignment expires.  

We’ve also added a new preview capability in PIM called Privileged Access Groups. Turning on this capability will allow you to enhance the security of group management, such as just-in-time group ownership and requiring an approval workflow for adding members to the group.

Assigning groups to Azure AD roles requires an Azure AD Premium P1 license. Privileged Identity Management requires Azure AD Premium P2 license. To learn more about these changes, check out our documentation on this topic:

• Use groups to manage role assignments
• Manage Privileged access groups

As always, we’d love to hear any feedback or suggestions you may have. Please let us know what you think in the comments below or on the Azure AD feedback forum.

Best regards,

Alex Simons (@Alex_A_Simons)

Corporate VP of Program Management

Microsoft Identity Division