In this article, we will expose the cyber-resilience challenge of Entra ID, explain why native features are incomplete and present the result of a PoC conducted on an open-source tool, Microsoft 365 DSC, to backup and recover Entra ID’s data.

The challenge of cyber-resilience in managed Cloud services

With Entra ID, the directory management strategy is in line with the Cloud paradigm. It means that the various network, storage, computer, OS and application layers are handled by Microsoft, leaving the customer to focus solely on his identity data.

This fundamental difference has an impact on the resiliency of the service. Indeed, the creation of snapshots to back up the integrality of the system, which is a common practice on AD, is not native on a managed service such as Entra ID. Thus, in order to face a disaster recovery scenario linked to malicious activities, we can only rely on native Microsoft functionalities: the identity lifecycle model, RBAC administration model and import/export capabilities.

The incomplete soft delete model

To ensure resilience, Cloud services are widely using a soft delete mechanism. Its main purpose is to recover data in the event of an accidental deletion. For example, in Azure Recovery Service Vault, the soft delete is the last safeguard in the event of intentional or unintentional deletion of the vault. Combined with immutability parameters, the vault cannot be erased regardless of admin permissions.

In Entra ID, the concept of soft delete exists but is insufficient to ensure data resilience for two reasons. On the one hand, there is neither role distinction between soft-delete and hard-delete nor Recovery role, i.e. the permissions required to delete an object are sufficient to allow for permanent deletion. On the other hand, the life cycle of objects in Entra ID (create, manage, delete) is governed by the same role:

• The role User Administrator can both create and hard-delete a user
• The role Cloud Application Administrator can register an application, configure all aspects of the application and hard-delete the application
• The role Cloud Device Administrator can add a device, configure all aspects of the device and unregister a device

The impact of a deletion on Entra ID

This design makes the User Administrator, Privileged Authentication Administrator, Cloud Application Administrator, Application Administrator, Cloud Device Administrator, Intune Administrator and Windows 365 Administrator roles all the more critical, as their compromise can lead to the permanent loss of identity data. The impact of such a deletion can be a loss of access to applications and data, a loss of permissions, and an inability to administrate.

Although the deletion of hybrid users synchronized with an on-premise AD is reversible, information such as role assignment will be lost, threatening the rights and access model. This is not the case for Cloud identities, which are generally part of the Control Plane. As part of the Enterprise Access Model, the Control Plane includes the most sensitive access, leading to a global compromise of an Information System.

In a disaster recovery scenario, some assets are more critical than others and should be backed up as a priority. These include:

• Control Plane users, groups and roles assigned
• Enterprise Applications (service principals) with critical permissions over Azure or Microsoft 365
• Administrative workstations

Comparison of backup open-source methods

To reduce the likelihood of Entra ID malicious data loss risk, the implementation of a backup solution seems essential, at least for the Control Plane in order to maintain control over your Information System and rebuild. We have therefore analyzed 3 open-source methods for ensuring data backup:

• Microsoft Graph PowerShell: this is the PowerShell library for Microsoft Graph APIs. You can build your own script(s) to export and import Entra ID objects attributes that fit with organization needs
• Microsoft Entra Exporter: this is a PowerShell module that export a local copy of some Entra ID attributes (Users, Applications, Service Principals, Roles, etc.) into JSON file
• Microsoft 365 Desired State Configuration (DSC): this is a PowerShell module for declarative configuration, deployment and management of Microsoft 365 services

Backing up Entra ID objects with Microsoft 365 DSC

In this part, we will explain how we tested the open-source solution Microsoft 365 DSC and share the results and conclusions we got.

Our PoC

Microsoft 365 DSC enables the management of the configuration and state of Microsoft 365 services following a declarative approach. By defining the desired state rather than specific steps, it simplifies the management of complex cloud configurations and ensures consistency across the environment.

In the context of a PoC, the test population deployed in our test tenant is as follows:

• 30 Cloud Only Users (randomly generated by Microsoft as part of the test’s tenant creation process)
• 10 Security Groups (randomly assigned to Users)

The purpose of this PoC is to identify the benefits and limitations of the solution through a series of tested and documented uses cases:

The process required configuring a service account with the right permissions (User.ReadWrite.All, Group.ReadWrite.All) in Entra ID to interact with Microsoft Graph API for data export and import.

These permissions enabled the service account to retrieve the necessary configuration and data from Entra ID and later re-import it.

Result of the PoC Microsoft 365 DSC

As a result of these tests, we were able to gather conclusive information on the solution’s benefits and limitations. On the positive side:

• Granular Configuration Selection: The solution allows precise targeting of configurations for backup, enabling users to select specific settings.
• Recovery without deletion: During recovery, current users and groups are retained, preventing accidental deletion.
• Overwrite of Outdated Attributes: Backed-up attributes replace the old ones.
• Language of the Data Storage: Data is stored in JSON format, making it easy to manipulate and modify backup files.
• Automation Capabilities: Once the necessary tools are installed, the solution is easy to automate.
• Monitoring and Alerts: Microsoft 365 DSC can be used to monitor data consistency and receive alerts in the event of suspicious changes
• Snapshot Versions management: It enables easy maintenance and administration of multiple snapshot versions
• Detailed Logging Functionality: It offers the possibility to generate highly detailed logs, providing records of all operations for enhanced oversight.

Despite these advantages, the study revealed several limitations:

• Incomplete Data in Backup: The backup process does not capture all attributes, leading to potential loss of important information.
• Backup Size Limit: The backup size is capped at 11MB, which may be insufficient for larger configurations or datasets.
• Deactivation Status Not Captured: Snapshots do not store deactivation statuses for users, potentially re-enabling disabled users during recovery.
• Unencrypted Data and Credentials: Security concerns arise from data and credentials being stored unencrypted, posing risks to sensitive information.
• Object IDs’ Loss: During imports, object IDs are lost, causing recreated objects to have new IDs, which can lead to duplicate entries in subsequent imports.
• Privileged Service Principal: The service principal involved has elevated privileges, increasing the risk of security vulnerabilities if not properly managed.

It is important to note that this tool does not really support “restoration” as it is possible to re-create objects, but it does not ensure service restoration and continuity. The reason being that it currently cannot restore links between new ID objects and applications, which is an issue native to Entra ID.

Our opinion about Microsoft 365 DSC

Microsoft 365 DSC is a great tool when it comes to basic uses and documentation as it is simple to use and to deploy on test environments. It is also quite efficient as a monitoring tool thanks to its version control and detailed logs. However, it is not adapted to large environments because of the limited scalability, the poor user experience and security issues related to configurations and credentials. It can also lead to inconsistencies or duplication as object IDs that can be referenced elsewhere are unrecoverable.

Additional solutions may be required such as scripting for handling configuration files and ensuring the consistency of the modifications, as well as well-defined encryption and backup processes. Therefore, we recommend always carefully evaluating the specific needs, planning additional developments and mainly using the solution for supervision and testing purposes.

Given the limitations of Microsoft’s open-source tools, it could be worthwhile to explore what third-party vendors, such as Semperis or Quest who are pure players on the subject, have to offer. These alternatives might address some of the challenges related to scalability, reliability and security, providing options that better suit larger environments. It is important to remain open to these possibilities and evaluate them based on the specific requirements of your organization.

Cet article Resilience Entra ID est apparu en premier sur RiskInsight.

In this second article, we will analyze practical attack scenarios that threaten the Control Plane and provide actionable recommendations to mitigate these risks. Specifically, we will explore three common attack scenarios that pose significant threats to the control plane: IT Support compromise, Control Plane Administrator Laptop compromise and CI/CD compromise. By understanding these attack vectors and implementing robust security measures, you can significantly enhance your cloud environment’s resilience against potential compromises. 

IT support compromise 

Imagine a scenario where the account of a member of the IT support is compromised. This might occur through a phishing attack, social engineering, or even a credential stuffing attempt. Such accounts often can reset passwords, including those of very high-privilege users, like Application Administrator or an Azure’s Owner at root level, thereby gaining unauthorized access to critical resources from Entra ID to the Cloud to On-premises to SaaS. 

This type of attack illustrates a critical point we discussed in the first article: the need to scope and isolate the control plane effectively. The help desk, while essential for everyday operations, must be rigorously segregated from high-privilege administrative functions. The lack of such separation can allow an attacker to pivot from a compromised help desk account to a Global Admin role. 

To mitigate this risk, organizations must implement a series of strategic defenses: 

• First, isolating control plane accounts from those managed by IT support is essential. This ensures that even if a help desk account is compromised, it cannot be used to access or manipulate high-privilege accounts.  
• Second, using cloud-only accounts dedicated to control plane tasks reduces the likelihood of legacy systems being exploited as an entry point.  
• Third, coupling these accounts with phishing-resistant Multi-Factor Authentication (MFA), Just-In-Time admin (JIT), robust identity governance and conditional access policies, strict workstation conformity creates a multi-layered defense that significantly diminishes the risk of such an attack. 

This scenario underscores the importance of viewing every account as a potential threat vector. By enforcing strict segregation and controls, you can ensure that your control plane remains secure, even if a lower-tier account is compromised. 

Control Plane Admin’s Laptop compromise 

Now, consider a situation where the attacker successfully compromises Intune’s Mobile Device Manager (MDM) admin account. With this access, the attacker gains control over Intune admin portal, allowing him to manipulate the laptop of a control plane admin. He can deploy malicious configurations, install backdoors, or directly connect to the admin’s laptop (Remote Help). This access turns the admin’s laptop into a powerful tool for further exploitation, granting the attacker the ability to execute commands, exfiltrate sensitive data, and manipulate cloud resources without the need for additional sophisticated hacking. 

This scenario reminds us of a key principle from the first article: cloud security must be approached holistically. It is not just about securing identities but also ensuring that the devices used to access the Control Plane are secured. In this case, the Control Plane admin’s laptop becomes a critical asset that, if compromised, could undermine even the most sophisticated cloud defences. 

To prevent such an outcome, organizations need to integrate admin workstations in the Control Plane. At a minimum, devices used for administrative tasks must be tightly controlled through dedicated MDM policies, ensuring strict access controls, encryption, and continuous monitoring. However, for higher-risk scenarios, leveraging Privileged Access Workstations (PAWs) is essential. PAWs are isolated, hardened machines dedicated solely to administrative activities. They operate under a far stricter security regime than standard devices—limited internet access, dedicated management, and enhanced monitoring—ensuring that they cannot easily become a tool for attackers. 

This scenario demonstrates that endpoint security is inseparable from cloud security. By securing the very devices that control your cloud infrastructure, you reduce the chances of a breach originating from compromised endpoints, ensuring that your Control Plane remains protected against even the most sophisticated attacks. 

CI/CD compromise 

As cloud environments rely heavily on automation, CI/CD pipelines for managing infrastructure become prime targets for attackers. Imagine a scenario where an attacker gains access to a DevOps engineer’s account via phishing or credential theft. With this foothold, he pushes malicious Infrastructure as Code (IaC) change into a Git repository, knowing this will trigger an automated Azure pipeline. The pipeline validates, plans, and deploys the infrastructure on Azure, leading to the destruction or alteration of key Azure resources, i.e. the foundations of the Landing Zone. Alternatively, the attacker modifies the Azure Pipeline’s YAML configuration. By doing so, he causes the pipeline to leak a service principal secret in the logs or debug console, which is then used to make unauthorized Graph API calls. Abusing the overprivileged identity, the attacker can escalate its privilege, compromising Entra ID identities or Office 365 accounts. Runners also play a crucial role in the CICD pipeline. They are agents responsible for executing jobs in the pipeline. They can be hosted and maintained by the Cloud Provider or hosted on-premises. As with any server, their compromise can be used as a pivot point to bounce back to the Landing Zone (e.g., token stealing) or other associated services. 

This scenario illustrates interconnectedness of cloud security. The CI/CD pipeline, often seen as a back-office function, is, in reality, deeply integrated with the Control Plane. Its compromise can lead to widespread, devastating consequences to the very foundation of your cloud operations. 

To protect against such threat, it is crucial to isolate the Control Plane’s pipeline whose purpose is to build the Landing Zone from project pipelines. Then, one should apply the principle of least privilege, ensuring that accounts and runners within the pipeline have only the permissions they need to perform their tasks. For example, to limit runner permissions we can use federated identity and request OpenID Connect (OIDC) tokens, which provide scoped and temporary access to Cloud Services like Azure. Additionally, adopting automated security practices such as Configuration as Code (CaC) or Policy as Code (PaC), can help reduce human error and ensure consistent security across your deployments. 

In cloud security, every process and every tool must be viewed through the lens of potential risk. The CI/CD pipeline is no exception. By securing this critical component, you not only protect your control plane but also ensure the stability and security of your entire cloud infrastructure. This holistic approach to cloud security is what will ultimately keep your operations running smoothly, even in the face of sophisticated attacks. 

Synthesis 

In this article, we have examined three attack scenarios that threaten the security of the control plane in cloud environments: IT support compromise, Control Plane Admin’s laptop compromise, and CI/CD pipeline compromise.  

Each of these scenarios highlights the importance of a multi-layered security approach that includes both technical and organizational measures. We propose a four-step strategy designed to design your Control Plane and secure it against potential attacks: 

• Step 1: define what is systemic for your infrastructure: identify the critical components and accounts within your control plane that, if compromised, could lead to a global disruption.
• Step 2: assess your current risk with a security audit: conduct regular security audits to evaluate the current state of your control plane security. This will help you identify vulnerabilities and prioritize remediation efforts.
• Step 3: define a roadmap to isolate and secure the assets most at risk: based on your audit findings, develop a clear roadmap for securing the most critical assets. This should include timelines, resource allocation, and specific actions to mitigate identified risks. 
• Step 4: prepare for cloud eraser scenarios: consider worst-case scenarios where entire sections of your cloud infrastructure might be compromised or disabled. Develop contingency plans and ensure that backups and disaster recovery processes are in place. 

By following these recommendations, you can build a robust defense against potential threats to your control plane, ensuring that your cloud environment remains secure and resilient. 

Thank you to Louis CLAVERO for contributing to this article.

Cet article Enterprise Access Model (2/2): What are the solutions to secure the Control Plane  est apparu en premier sur RiskInsight.

This article is the first of a series of 2, tackling the implementation of the Enterprise Access Model, an administration model proposed by Microsoft to secure the administration of Cloud environments.  

Today, most companies use public cloud to host numerous workloads from business to functional services. Although this brings benefits, the Cloud also introduces new paradigms, which need to be understood clearly in order to be secured. 

Historically, enterprises have relied on a 3-tier model for securing Active Directory environments. This model segments the network into three distinct tiers: Tier 0 for highly sensitive systems and data, Tier 1 for server administration, and Tier 2 for end-user workstations and devices. While this model has proven effective in on-premises environments, the shift to cloud-based infrastructures requires a reevaluation of its applicability. 

This article delves into a recent, concerning trend: the global compromise of Entra ID, originating from the compromise of a helpdesk account. Such an attack can have severe repercussions, even more so than an AD Domain Administrator compromise. We will explore the mechanisms behind these attacks, their implications, and, most importantly, how we should protect against this kind of privilege escalation and implement an adapted and secured administration model. 

Understanding Entra ID, Active Directory, and Azure Permissions 

As shown in Figure 1, Active Directory and Entra ID (formerly Azure Active Directory) are two Identity services with different structural properties and IAM protocols. While Entra ID focuses on identity and access management across both cloud and on-premises environments, providing authentication and user management, Azure permissions extend to the broader management of cloud infrastructure and services. Understanding the distinctions and interconnections between these tools is essential for maintaining robust security and effective access control in modern enterprise environments. 

Figure 1: Active Directory and Entra ID key differences

Between Active Directory, Entra ID, and Azure- each manages its own permission model: 

• Active Directory uses a unified permission model for all its objects, from users to servers. 
• Entra ID uses Role-Based Access Control (RBAC) to manage its tenant’s objects (e.g., users, devices, applications). 
• Azure Resource Manager (RM) uses RBAC to manage Azure resources 

However, there is a bridge between Entra ID and Azure RM thanks to the single tenant’s relationship to an Azure organization: the Entra ID’s Global Admin role is assigned by default the User Access Administrator role in the Azure RM service. As a result, it can grant itself full permissions in Azure.  

Although there is a link between Azure and Entra ID, it’s important to remember that the roles in Entra ID and Azure RM can be assigned independently. For example, a standard Entra ID user with very limited permissions on Entra ID can hold the highest privileges in Azure RM, which is a critical point of vulnerability exploited in attacks. 

Privilege escalation in Entra ID can lead to an extensive compromise of Azure RM (including all resources and infrastructures), Microsoft 365, workstations, Windows servers, cloud networks, and more. 

The most privileged roles in both systems are: 

• Entra ID: Global Administrator 
• Azure RM: Owner (which can be scoped from Management Groups down to resources) 

These significant differences mean that the concepts from the traditional AD 3-tier model cannot be directly applied to cloud environments. We must rethink and adapt these concepts to ensure they are relevant and effective in cloud-based contexts, particularly by adequately addressing the specific requirements and risks associated with cloud environments. 

A real-life global Entra ID compromise 

To focus on Cloud Administration compromise and privilege escalation, a small number of hypotheses will be taken: 

• The victim has an Entra ID tenant as Identity Provider. 
• The victim uses Intune to manage its entire workstation fleet. 
• The victim has an Azure subscription for its Virtual Desktop Infrastructure activities. 
• A helpdesk account is compromised (the source of the attack is not relevant, but it is important to note that this is a likely scenario that could have been the result of several different compromise like phishing, credential theft, workstation compromise, social engineering, etc.). 

1 Compromising a helpdesk account 

• Following our last hypothesis, the attacker has gained control of a helpdesk account, that can reset passwords and MFA.  

2 Initial Attempt to Reset Global Administrator Account

• The attacker initially attempts to reset the Global Administrator account, seeking the quickest path to becoming the Global Administrator of Entra ID.
• This action is blocked by default by Microsoft. The Global Administrator role is a “privileged role”, and only specific privileged roles are authorized to reset its password or modify its attributes. Microsoft updates here its list of privileged built-in Entra ID roles. 

3 Targeting a High-Value Standard User Account

• Restricted to resetting standard Entra ID user passwords, the attacker identifies a user with the username “VDI Admin”, who is the Owner of an Azure RM subscription used for workstation administration services. 
• Despite MFA being enabled on the account, the attacker successfully resets both the password and MFA mechanisms, gaining access to the account. 

4 Searching the available subscription 

• With the VDI Admin password reset, the attacker logs in and accesses the subscription. Through reconnaissance, they discover access to a key vault containing credentials for a service account. 
• The service account is identified as having the “Intune Administrator” role in Entra ID. 

5 Utilizing Intune Administrator Privileges 

• The attacker logs in as the Intune Administrator, gaining permissions related to workstation administration, including the ability to run scripts on any workstation. 
• They deploy a script on the Global Administrator’s workstation to extract authentication cookies from the Global Administrator’s browser. 

6 Compromising the Global Administrator Account

• The attacker obtains the Global Administrator’s authentication cookies and uses them on their own workstation to impersonate the Global Administrator. 
• This grants the attacker control over the entire Microsoft Entra ID tenant, which includes compromising the Microsoft365 tenant, the Azure RM environments, and all other Microsoft cloud-based tools relying on Entra ID. 

Figure 2: A global Cloud compromise path 

By following these steps, the attacker, beyond being able to compromise the entire cloud infrastructure, can deeply affect a company’s business through unauthorized access to emails & documents, backups, endpoints and corporate network. This attack demonstrates the critical importance of securing high privilege accounts that have permissions that could lead to a global compromise.  

Figure 3: Impact of a compromise at the Control Plane level 

How to ensure this does not happen: Implement the Enterprise Access Model and scope your Control Plane 

As discussed in the first part, cloud directories, particularly Entra ID, exhibit key differences from Active Directory. Consequently, the traditional three-tier model requires adaptation to be fully effective in cloud environments. To address these challenges, Microsoft has introduced a new administration framework specifically designed for cloud environments: the Enterprise Access Model. 

Figure 4: The Enterprise Access Model 

While there are some modifications, the core concept remains the same: sensitive resources must be isolated to ensure that a compromise in one plane (formerly tier) does not lead to a compromise in another. This leads us to a crucial question: how should we scope our Control Plane within our Information System to effectively isolate it and mitigate the risks of a global compromise? 

The answer lies in identifying the systemic components within our Information System — those whose compromise could lead to a widespread breach. Losing one project is far less critical than a global compromise of the entire Information System. 

In our cloud environment, numerous components interact to support projects, from CI/CD infrastructure and deployment pipelines to various IAM tools (such as Identity Providers like AD, Entra ID or Okta, IGA, etc.), along with cross-functional security tools (like EDR, Bastion, and MDM for example). While these are generic components likely present in many systems, there are also numerous environment-specific ones to consider. 

We must assess the impact of compromising high-privilege accounts within these components. For instance, if an attacker gains control of a high-privilege account for the CI/CD infrastructure, they could potentially alter the CI/CD processes and/or run a specific pipeline to deploy unauthorized changes in the cloud, which would allow them to gain global access. Thus, these high-privilege CI/CD accounts should be part of the Control Plane. Similarly, consider the EDR solution: if a high-privilege administrator can execute scripts across all workstations, potentially stealing authentication cookies, accessing critical data, or rendering all workstations inoperable, then this high-privilege account must also be included in the Control Plane. 

By carefully scoping and securing our Control Plane, we can significantly reduce the risk of a global compromise within our Information System. 

Synthesis 

As we have seen, the risk of global compromise in a Cloud environment is significant. While cloud computing offers enhanced flexibility, resilience, and cost optimization, it also introduces new paradigms and operational methodologies that must be mastered to ensure security. 

The traditional 3-tier model from the on-premises world, particularly from Active Directory, is not suited for organizing administration in the cloud. To address this, Microsoft has introduced the Enterprise Access Model (EAM). This model expands the 3 tiers into five distinct planes, with the most critical being the Control Plane. However, just as with the 3-tier model, isolation measures are crucial in the EAM, requiring the identification of critical components and high-privilege accounts within your Information System as a top priority for cloud security. 

The next article in this series will provide concrete examples of attack scenarios that can lead to a global compromise of cloud environments. It will also include security recommendations to enhance cloud administration and prevent such risks from becoming security incidents. 

 Thank you to Louis CLAVERO for contributing to this article.

Cet article Enterprise Access Model (1/2): How to scope your Control Plane to secure your Cloud Administration and prevent a global Cloud compromise est apparu en premier sur RiskInsight.

Wavegame is a Wavestone inter-school challenge designed to promote cybersecurity expertise and the consulting profession created in 2019. In its 2023 edition, 33 teams competed in a hands-on exercise focused on securing an AWS Infrastructure.

The challenge was split into 2 tracks, the first being dedicated to Business majors and the later for Computer Science majors. The technical track consisted of 2 qualifying exercises and a final event. The second exercise is the topic of this article. 

As part of a futuristic scenario, the students, acting as consultants, are hired by France Fusion, a company operating the country’s first nuclear fusion plants. France Fusion is developing a Cloud-based monitoring platform to analyze data from its proprietary industrial equipment. For this purpose, it uses an ElasticSearch database. 

Initially started independently as a Proof of Concept (PoC), detached from the security department, a team of developers succeeded in deploying a functional architecture on AWS. The students are then tasked with strengthening the infrastructure’s security, in accordance with France Fusion’s Public Cloud policies. 

The technical challenge was significant: deploying a self-service, vulnerable infrastructure across 33 AWS accounts. This also meant granting students full admin access and necessary permissions to make direct modifications from the AWS console, all within limited budget considering the number of participants. In this article, we will share the recipe that made this challenge a reality. 

Step 1: draw up an architecture with an educational dimension 

Before delving into the development of the coding game, we had to keep in mind 4 constraints:  

• Target Audience: as our participants are students with heterogeneous backgrounds in the Cloud, it is important to take this diversity into account. Therefore, we focused on using essential AWS services only (e.g., S3, EC2, Lambda), because such resources are well-documented, and students may already have used them in class or as part of personal projects. 
• Theme: our objective was to create an architecture similar to a client environment. The immersion and realism of the interface was a key to student engagement. We therefore opted for an ELK stack on an EC2 instance as it seemed appropriate for a proof-of-concept with a monitoring dimension. 
• Costs: as the infrastructure would be available to students for two weeks and replicated across 33 AWS accounts, it was in our interest to optimize costs. To achieve this, we used AWS Pricing Calculator to estimate costs, and opted for a low-cost region and built the infrastrucure around pay-as-you-go services such as Lambda functions. 
• Deadlines: to cope with a tight schedule, we have defined objectives and deadlines with enough margin to overcome any technical constraints. The main stages of the project include development, testing, account creation and deployment. 

Considering the project constraints, we have sketched the “vulnerable” architecture schema outlined below (Figure 1). The industrial equipment is simulated by a Lambda (Datalake) which generates logs and sends them to an S3 bucket (Datalake). A second Lambda (ELK) is then triggered by an S3 notification. It will retrieve the log file and send it to the ElasticSearch database (Docker image within an EC2 instance). Finally, the Kibana interface is accessible from Internet for visualization and log analysis. 

Figure 1 : initial architecture diagram of the Wavegame 2023 

Step 2: picture a secure architecture based on Public Cloud policies 

Now that we have our initial infrastructure, the next step is to design Public Cloud policies that will define the security requirements and provide evaluation criteria. To achieve this, we have fine-tuned security best practices implemented by clients, here are some examples: 

• AWS-01: All AWS resources must use IAM roles that are specific to their needs and that respect the principle of least privilege. 
• AWS-02: All AWS resources must be connected and/or attached to a VPC. 
• AWS-03: EC2 instances must not be publicly accessible through Internet. 
• AWS-04: All infrastructure logs (AWS Lambda and EC2) generated by AWS services must be sent to CloudWatch. 
• AWS-05: Root EBS volume must be encrypted on all EC2 instances. 
• AWS-06: Data stored on S3 buckets must be encrypted. 

From the Public Cloud policies, we came up with the following secure architecture (Figure 2): 

Figure 2: target architecture diagram of the Wavegame 2023 

To summarize network design, all compute resources are placed in a private subnet, the S3 bucket is reachable through a VPC endpoint, the ELK monitoring platform is solely accessed through a jump host Virtual Machine (VM). CloudWatch and CloudTrail services are activated for monitoring and supervision purposes. Finally, some security groups are attached to resources to only allow incoming communications that are strictly necessary.  

Step 3: move from design to code in Terraform 

To build the coding game, we created and maintained 2 distinct architectures, represented by 2 distinct branches in Github. The first one being the vulnerable architecture which will be deployed initially, and the second being the solution that acts as a warranty of feasibility. This “warranty of feasibility” means that 3 mandatory points are met: 

• The IAM permissions set are enough to allow the system to work properly. 
• The final configuration of the infrastructure must consider objects lifecycles and their interactions. 
• The expertise required to complete the coding game must be adapted to students’ skills development over a 2-week challenge period. 

Regarding the development lifecycle, rather than following a linear development approach, where we would first create the code for the initial infrastructure, then for the target infrastructure, we opted for an agile approach with the definition of functional blocks. To illustrate this idea, the block “Lambda (ELK) -> S3” aims to design a Lambda that will request an S3 bucket as soon as an S3 PutObject notification is created, with or without a VPC endpoint. Although we must maintain 2 Terraform configurations simultaneously, this approach gives us greater agility in reassessing our technical choices. To further reduce redundancy and ensure maintainability, we focused on developing Terraform modules such as lambda and S3.   

To automate the deployment of resources within our sandbox and student accounts, we created a simple CI/CD in Github. It is constituted of 2 Github Actions: one workflow to terraform apply, the other to terraform destroy. In a YAML syntax, Github Actions allow you to execute AWS or Hashicorp built-in tasks.  

One advantage of such workflow is that you can store AWS access credentials in Github Secrets instead of source code or local file. Moreover, by storing Terraform states in a S3 bucket it facilitates collaboration. A Terraform state is a file that keeps track of the current configuration. Each developer sets up his S3 key in his Github branch that will become the reference of his state. 

As the development progressed, we realized how wide the gap was between the initial and the target architecture. The main reason is that IAM and network logics are very different. As a result, it has become essential to carry out tests under real conditions, i.e. from the AWS console, to identify breaking changes, blocking policies, and to assess complexity. As an example, one of the tests reminded us that the startup script of an EC2 called user-data is not persistent after a reboot. Therefore, this behavior prevented the implementation of the EBS root volume encryption security policy (AWS-05). 

Step 4: securely deploy the environments 

In the context of the challenge, we were about to grant students privileged access to an environment for two weeks where constant individual monitoring or assistance would not be feasible. While this approach represents a better learning opportunity, it raises specific security scenarios that we must anticipate and mitigate. Among these, budget overrun was a major concern, given the unrestricted access and resources at their disposal. Another significant threat is the potential for students to ascend within the organization, gaining access systems or messing with each other. Lastly, the risk of resource misappropriation for unauthorized or malicious purposes is not negligible. Each of these threats requires careful consideration to ensure a secure and responsible deployment. 

For this coding game, we opted for a multi-account AWS design to isolate each team environments. With AWS Organization, we achieved a simplified administration, improved cost control, and were able to enforce guardrails using Security Control Policies (SCP). In Figure 3, we present our AWS Organization, made of an admin account and an OU Wavegame that hosts the teams accounts where the infrastructure is deployed. We implemented 3 specific SCPs to: 

• Restrict access to AWS services outside the designated region, us-east-1, by defining a list of authorized operations. 
• Enforce the use of Amazon EC2 instance types t2.micro or t2.large, a constraint related to the ElasticSearch (ELK) environment. 
• Deny students accounts from deleting or modifying a resource that has “protected” tag. 

Additionally, to better manage costs, especially for a two-week duration, we set up a Lambda function to automatically shut down EC2 instances after two hours of activity. To prevent any unauthorized alterations by the students, this Lambda function was one of the resources secured with the “protected” tag. 

Figure 3: AWS Organization of the Wavegame 2023 

Finally, in addition to our IAM user being administrator of the OU Wavegame via an assumable IAM role, we created an IAM user with the AdministratorAccess role for each AWS account, to give students autonomy during the challenge. In particular so they have enough rights to create nominative accounts. 

Step 5: prepare for the Run and the correction 

Once the challenge kicked off, the students had two weeks to secure the resources in their AWS account following the guidelines. With such extensive permissions, major configuration errors can quickly arise. For instance, one group created a “Deny All” S3 policy, which resulted in them locking themselves out, as well as anyone else since none of us had root account privileges. 

To address such situations, we set up the following communication system: each team would be assigned a coach responsible for reporting technical issues to the organizing team, which then escalated the incidents to us. We were then able to investigate and fix the issue or be able to quickly communicate with them without receiving too many messages for simple questions that could be answered by the coaches. 

Besides incident management, our role also involved monitoring budget overruns. To achieve this, we set up cost alerts for each AWS account. We also developed a script to track the budget evolution of the teams in real-time. This tool proved to be very useful in providing an estimate of the time spent by the students on the challenge and respond in case or abnormal spending. For example, two days after the challenge began, an alert was triggered due to a failure in the Lambda function meant to shut down the VM. 

Once the challenge concluded with few incidents, and student access had been revoked, it was time to proceed with the assessment to declare the winners. As a reminder, the students were required to configure their AWS account in compliance with the Public Cloud policies. For their evaluation, we used two grading mechanisms: 

• An automatic assessment through the deployment of AWS Config Managed rules at the end of the challenge. Amazon provides a sufficient set of rules to cover a significant percentage of the requirements. For example, a rule checks whether the S3 bucket is encrypted (AWS-06). 
• A manual assessment based on clearly documented expected criteria and steps for verification.

To conclude, the organization of a coding game is an ambitious project, requiring strong Cloud and Terraform skills, solid management capabilities and the ability to react to unexpected events. Despite the challenges, this is an outstanding learning opportunity. Indeed, for the participants, the Wavegame provides an immersive entrance into Public Cloud Security. Meanwhile, for the organizers, the Wavegame offers a new practical experience in designing, building, and maintaining operational readiness for an infrastructure in the Public Cloud. 

Cet article    How to build a coding game around Public Cloud Security step by step?     est apparu en premier sur RiskInsight.