This article is part of day 6 of KINTO Technologies Advent Calendar 2024. 🎅🎄

Introduction

Hello, I'm Tada from the SCoE Group at KINTO Technologies (from now on referred to as, KTC). SCoE is an abbreviation for Security Center of Excellence, and some of you may not be very familiar with the term yet. At KTC, we restructured our CCoE team into the SCoE Group this past April. The story behind the reorganization is summarized in this blog article, so please do check it out. Also, I've written this blog article about the Osaka Tech Lab (our company's Osaka office), so feel free to check it out as well.
KTC operates many production environments on Amazon Web Services (hereafter referred to as AWS), and with the leveraging of OpenAI, the use of Microsoft Azure (hereafter referred to as Azure) has been on the increase as well lately.
One of the tasks of the SCoE is to provide an environment with preconfigured security settings based on group policies. In this blog, I would like to introduce some of the security settings we implement when providing an Azure subscription.
Since Azure-specific terms will be used, please refer to the official website and other resources for more details.

Designing the Azure Landing Zone and Management Groups

When considering security settings, it is important to first understand landing zones and management groups. KTC’s subscription environment has been designed and constructed based on Azure landing zone design principles. However, rather than use Microsoft’s official landing zone as is, we have designed a lighter one of our own to go with KTC’s environment, referring to best practices as we did so.
Within the landing zone, we have designed several management groups to organize subscriptions logically and manage them efficiently. The following figure gives an overview of this. By using these management groups, we apply appropriate policies to each subscription.

Management group	Overview
KTC	The root of the management groups, used to apply the policies that will be common to all of them
Management	For managing subscriptions used for security, such as ones used for consolidating the Activity Logs of all subscriptions
Workload	For managing subscriptions used for workloads
Sandbox	For managing subscriptions used for sandboxes
PolicyStaging	For managing subscriptions and management groups used for testing Azure policies

The key point is that we have one, unified management group for workloads. This management group contains subscriptions used for products, and within a single subscription, has separate production, development, and staging environments on a per-resource-group basis.
There are various approaches to environment separation, but at KTC, we started with this approach because the number of workloads is not large, it is limited to specific Azure services, and cost management at the subscription level is easier. We are also thinking of reviewing it if use of Azure increases in the future.

Role of the “Management” Management Group

The Management management group is a management group used to consolidate subscriptions for operational management and the deployment of security tools common to all subscriptions. Only members responsible for operations and monitoring have access, and for example, we manage a subscription here that aggregates and monitors the Activity Log for all subscriptions.

Configuring Security Settings Using Azure Policies

By using Azure policies , it is possible to create resources in accordance with security and governance requirements, and violations can be detected and remediated. We use Azure policies to automatically apply security settings when creating subscriptions here at KTC, too. We are only using built-in policies at the moment, and not yet gone as far as creating custom ones. I would like to consider doing that in the future if the environment changes (due to an increase in workloads, for example).
The following is an example of a typical setup that utilizes Azure policies.

• Monitoring and storing Activity Logs
• Configuring and using Defender for CSPM
  At KTC, we do not adopt an approach of overly applying Azure policies as preventive guardrails. This decision is based on factors such as the relatively small number of workloads at KTC, the skill level of engineers, and operational costs. Rather than increasing the constraints with strict preventive guardrails, our approach is all about leaving the engineers a certain degree of freedom, and conducting kaizen (continuous improvement) to address issues detected through heuristic guardrails. The intention behind this is to enable our engineers to hone their skills through problem solving, get increasingly interested in the work, and grow.

Monitoring and storing Activity Logs

The Activity Logs from all the subscriptions are consolidated in the Log Analytics workspace of the Management subscription. We have set things up so that the Audit Logs get automatically consolidated by means of an Azure policy when new subscriptions are added, too.
The Azure policy we are using is shown below.

• Configure the Azure Activity Logs to stream to the specified Log Analytics workspace
  Since Log Analytics has a default retention period of 90 days, we keep backups in a storage account. However, there is no setting for this in the Azure policy, so we are doing it manually. We have confirmed that it can be configured to happen automatically by creating a custom policy, but have not gone as far as doing it yet.

Configuring and using Defender for CSPM

These are called heuristic guardrails. If any risky configurations or actions are performed in the Azure environment, we use Cloud Security Posture Management (CSPM) solutions to detect these risks. In the case of Azure, Microsoft Defender for Cloud can be used for CSPM. Microsoft Defender for Cloud is a solution for Cloud Native Application Protection Platform (CNAPP), covering security solutions such as CSPM (Cloud Security Posture Management) and CWPP (Cloud Workload Protection Platform).
Microsoft Defender for Cloud’s CSPM features include Foundational CSPM, which is free, and Defender CSPM, with which resources like servers, databases, and storage give rise to costs. In KTC’s case, we use Defender CSPM, because it enable you to do more detailed CSPM checking.
Using the following Azure policy, we configure Defender CSPM automatically upon issuing subscriptions.

• Configure things so that Microsoft Defender CSPM will be enabled
  Once we have configured the settings, we periodically monitor the alert situation via Microsoft Defender for Cloud, and if there are any risky configurations, we work with the product-side staff using the subscription to do kaizen to address the risks.
  We are not implementing cloud workload protection at the moment, but would like to consider it in the future (as resources increase, for example).

Threat Detection

In order to discover security incidents and unauthorized access in the Azure environment at an early stage, we have introduced a threat detection mechanism. I think many companies that have introduced AWS are using Amazon GuardDuty to achieve this, and that is also what KTC is doing. For Azure, using Microsoft Sentinel is apparently the surefire approach, but given KTC’s environment, in view of the cost and effort involved in introducing that, we are achieving it through the CDR (cloud detection response) features of the third-party product sysdig instead.
The CDR is actually handled by the OSS Falco. Falco detects and notifies you of abnormal behavior, potential security threats, and other violations regarding your hosts, containers, Kubernetes, and cloud environment as a whole. General threat detection rules are provided, and these can also be customized and tuned. This makes it very easy to use.
KTC was already using sysdig for CSPM and threat detection for its Google Cloud environments, so we are applying the know-how from that to Azure as well.

Summary

In this article, I talked about some of the security settings we employ at KTC when we provide Azure subscriptions. To enhance security, we utilize Azure Policy, Microsoft Defender for Cloud, and Sysdig's CDR functionality.
As I said in “Configuring Security Settings Using Azure Policies,” I think how strict you should make preventive guardrails will depend largely on your own company’s situation, so you should design and operate things in the best ways to suit that.
I hope this content serves as a helpful reference for security settings when using Azure. Thank you for reading all the way to the end.

Conclusion

The SCoE Group is looking for new team members to work with us. We welcome those with practical experience in cloud security as well as those who are interested but have no prior experience. Please feel free to contact us.
For additional details, please check here.