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.

To meet this challenge, Microsoft has defined the Enterprise Access Model, offering a new approach to identity and access management adapted to the reality of the cloud. This model promises to redefine how companies manage access to digital resources, whether within cloud solutions like Azure, Office 365 applications, or other strategic services.  

This article proposes a methodology and examples for implementing the Enterprise Access Model and defining criteria for assigning roles to the management plane or control plane. The article also aims to highlight the risks associated with poor implementation of the model, with concrete examples. Finally, it lists several best practices for configuring and managing the access model to help mitigate these risks.    

Is the tiered model unsuitable for access management in the cloud?

(For more information on this subject, please consult wavestone’s white paper available here) 

The tiering security model, applied to Active Directory, is based on the fundamental principle of segmenting privileged accounts into 3 different layers, known as tiers. The aim is to ensure that, if a resource or account in a tier is compromised, the higher-trusted tiers remain preserved, thus avoiding any potential propagation of the compromise to the entire system. 

• Tier 0 is the most critical tier, covering all the infrastructure components managing the company’s AD Domain Controllers.   
• Tier 1 typically comprises the company’s applications and the servers that host them.   
• Tier 2 covers everything that revolves around the user environment.   

While the tiering model can be used to secure the Active Directory infrastructure, it encounters significant challenges when applied in a cloud context. One of the major challenges lies in the very nature of the cloud, where access and administration are generally carried out via consoles exposed on the Internet, unlike in on-premises environments.  

Microsoft has therefore defined a new model, the “Enterpise Access Model”, to take account of these new challenges. This article will look at how this model can be effectively implemented in a Microsoft cloud environment. 

The Enterprise Access Model: a new model adapted to the needs of the cloud 

One of the key features of the Enterprise Access Model is the implementation of a privileged access mode for certain critical tasks and the management of a multitude of critical resources, either on-premises or in the Cloud.  

Source  : https://learn.microsoft.com/en-us/security/privileged-access-workstations/privilegedaccess-access-model

Evolution of purpose and scope  

Tier 0 -> control plane   

• Control plane: includes management of all aspects of access control, identity management, and all elements that could jeopardize the tenant.  

Tier 1 divided into 2 parts   

• Management plane: management of the application infrastructure base, such as servers or configuration of PaaS (Platform as a Service) services.  
• Data/Workload Plane: management and configuration of applications, resources, and APIs.  

Tier 2 divided into 2 parts   

• User access: includes B2B, B2C, and public access scenarios.  
• App access: takes into account the attack surface of application-to-application exchanges via APIs. 

Which accounts should be included in the control plane?  

To define the accounts in the control plane, this article proposes an approach based on the criticality of the roles and the impact they can have on the cloud environment. If the role could have a systemic impact on the enterprise (destruction of a large part of the cloud and backups, for example), it should be managed in the control plane.  

Make sure to carry out a complete analysis, as some common roles, such as helpdesk administrator, with no critical privileges on direct resources, can take control of accounts that do!   

Strategy based on criticality 

Optimizing security: applying the Enterprise Access Model to the Microsoft cloud   

At the heart of Microsoft’s cloud ecosystem are roles, an essential component that governs how users and services interact with cloud resources.    

This section takes a deep dive into this crucial aspect of identity and access management in the cloud. The section will explain what Azure roles are, how they work, and why good management is crucial to the security and performance of a company’s cloud infrastructure.    

Organization of roles in Microsoft clouds:  

Roles are a set of permissions that control who can access Azure resources and what actions they can perform.  

Roles in Microsoft Cloud  

It’s important to differentiate between three types of roles:  

• Azure roles are dedicated to accessing and managing Azure resources.  
• Microsoft Entra roles are used to manage resources in the Microsoft Entra ID directory.   
• Microsoft Entra roles used to manage associated Office 365 resources.  

It’s important to note that these roles can be interconnected.  

Azure roles 

Azure roles are organized according to the principle of Role-Based Access Control (RBAC), which is an integrated feature of Microsoft’s Azure cloud platform.   

They are dedicated to the management and access of Azure resources, and encompass elements such as Azure virtual machines, SQL databases, services, as well as application services such as web apps. 

Azure role assignment is a key step in implementing access management in a cloud environment. It determines who has access to which resources, and what privileges are granted.   

‘Security Principals’, on Azure, refers to the entities, including users, groups, or services, to which permissions are assigned. There are several types of security principals on Azure, which may or may not be human. 

Security Principal 

Scope, when assigning roles in Azure, is crucial in determining where permissions apply. It can be specified at different levels, as shown in the diagram below:   

The scope of RBAC 

To better understand role assignment as well as the strategy based on the criticality of roles, and their impact on the cloud in terms of their placement in the control plane, this article proposes two concrete examples: 

Strategy application example 

In example 1, a user is assigned the owner role (allowing him to read, write, and assign roles to other users throughout the scope to which the role is assigned), on the scope of a management group. In this example, the owner role is critical because the scope is very high-level: it will therefore have full authority over all subscriptions, resource groups, and resources in its management group. This is why the owner role is in the control plane.  

In example 2, a group is assigned the contributor role (allowing it to read and write to the entire scope to which the role is assigned), on the scope of a subscription. In this example, the impact is limited to one subscription, and therefore probably not systemic for the enterprise. This is why, in this case, the contributor role is in the management plane.  

The key takeaway from these examples is that the criticality of a role is not only related to its permissions but also to the scope over which it is assigned.     

Segmentation between Microsoft Entra ID and Azure? The case of global admin  

Microsoft Entra ID and Azure roles are defined independently: in Microsoft Entra ID and Azure RBAC respectively. This means that authorizations assigned to Microsoft Entra ID roles do not provide access to Azure resources, and vice versa. However, as global admin within Microsoft Entra ID, they can grant themselves access to all associated Azure subscriptions and management groups.   

When the global admin grants themselves access to Azure, they are assigned the role of user access administrator in the Azure management group root scope. This enables them to view all resources and grant themselves access to any subscription or management group in the directory.  

It is therefore important to control who and how many people are assigned the global admin role, and to manage it in the Control Plane.  

Global Admin Azure 

Privilege escalation through password reset and MFA  

This method relies on exploiting privileges that allow passwords to be reset for user accounts or systems. Attackers often target specific roles that have this privilege because, once compromised, they can reset the passwords of more sensitive accounts and thus gain access to take control of critical systems.   

The table below highlights the Microsoft Entra ID roles that can reset the password of any subscription owner.   

Note that security measures such as MFA (Multi-Factor Authentication) can reduce this risk, as detailed in the rest of this article. 

Can a user with a role in column 1 reset the password of the user in row 1?   

Attack scenario 1: Escalation of privilege to an Azure role from a Microsoft Entra ID role:  

A helpdesk administrator, which is a very common role in the enterprise, can reset the password of a subscription owner and thus access Azure from within Microsoft Entra ID. As a result, segmentation between the two worlds is no longer guaranteed.  

Attack scenario 2: Escalation of privilege to a Microsoft Entra ID role from a Microsoft Entra ID role:  

Within Microsoft Entra ID, privilege escalation from a helpdesk administrator to an Authentication Administrator is possible.   

These two scenarios are no longer possible if MFA is set up, as the password alone cannot be used to authenticate to the account. In most cases, this security measure covers this type of privilege escalation. However, certain roles have the upper hand on both parameters, i.e. password reset and MFA setting, and it is not uncommon for user support to have this ability. 

Does a user with a role in column 1 have rights on the MFA? 

Attack scenario 3: Privilege escalation from an authentication administrator to Azure or Microsoft Entra ID :  

Here the authentication administrator is a role that can manage and reset the authentication methods of users who do not have an administrator role. In addition to being able to control the MFA, this role can also modify or reset the passwords of a large proportion of users. The tables above show that it can take on the role of a helpdesk administrator or a subscription owner.   

These roles need to be managed in the control plane to avoid privilege escalation scenarios and maintain the watertight seal between Microsoft Entra ID and Azure. 

Reinforce your security, some examples of additional security measures

Grant privileges to a managed identity rather than to a user  

To limit the risks associated with assigning control plane roles, it is recommended to use Managed Identities as alternatives to user authorizations, or Privileged Identity Management (PIM) to better manage high-privileged users. This approach limits the risk of privilege escalation.  

Managed Identities are authentication entities managed by Azure for applications and services. Rather than granting privileges to individual users, you can assign authorizations to the Managed Identities associated with these applications or services. This approach offers the following advantages:  

1. Reduced credential exposure: using Managed Identities reduces the potential attack surface, as credentials are not exposed or shared.  
2. Secure automation: applications and services using Managed Identities can automate tasks without the need for high-privileged user accounts.  
3. Centralized control: authorizations are managed centrally, facilitating privilege management across the entire cloud environment. 

Limiting risks with Privileged Identity Management (PIM)   

When assigning high-privilege roles or control plane roles, especially to users, it is very important to control and monitor the assignment of these roles. The use of PIM, a feature that enables precise management of administrative privileges, may prove useful. PIM is based on:  

1. Temporary elevation of privileges: users can be granted administrative privileges on a temporary basis to perform specific tasks, thus reducing the risks associated with permanent authorizations and errors.  
2. Mandatory justification for elevated privileges.  
3. Implementation of control and monitoring.  
4. Creation of a workflow to validate privilege elevations: /!\ requires a high level of maturity to manage reactivity and HNO (non-working hours) requirements. 

Securing a cloud environment is an essential concern. Attacks using the concepts and intricacies of cloud management will increase in the near future, therefore; it would be a loss to wait until attackers start dealing with this subject before companies start dealing with it properly.  

This article has explored various aspects of privilege management and security in the cloud, highlighting fundamental strategies and practices for effectively protecting the control plane, which brings together data and resources that are highly sensitive to the integrity of a company’s infrastructure.   

The article explored Microsoft’s enterprise access model, based on the “Zero Trust” principle. This model offers a flexible and secure approach to access management in a cloud environment. 

It was then presented that Microsoft Azure roles and some of the risks of privilege escalation, highlighting the importance of accurate authorization assignment and continuous monitoring to prevent abuse and potential threats. 

Securing the control plane in a cloud environment is of paramount importance in protecting a company’s sensitive data and resources. Exploring the strategies and best practices discussed in this article, it’s clear that every organization needs to carefully define its role model, ensuring that accounts and permissions are appropriately assigned in the control plane or management plane. It is imperative that measures are put in place to ensure the isolation of each plane, while paying particular attention to precise authorization management and continuous monitoring to prevent abuse and potential threats (including privilege escalation).   

Security in the cloud is no longer an option, but an absolute necessity! 

Cet article Protecting the Control Plane: Critical Stakes in Cloud Security  est apparu en premier sur RiskInsight.

Simultaneously, we are moving towards Information Systems that are built on an ever-increasing diversity of environments, thanks in particular to the Cloud, which is now an integral part within corporate Information Systems. This enables corporations ) to expand their capabilities, however it is also the surface area  for risk of attacks.   

Conventional intrusion detection and protection techniques already exist and are developing exponentially. These are effective against the most common attacks, however are not always adapted to the specificities of the Cloud.   

This raises questions about the use of proactive strategies, such as Deceptive Security, to stay one step ahead of attackers. Particularly in the context of Cyber-Resilience; how can this kind of technology be used in both a traditional and a cloud environment?   

When should Deceptive Security techniques be used? Are Deceptive Security solutions in the Cloud being developed today? Are there any specific strategies to consider in a Cloud environment as opposed to a traditional one?  

We will answer these questions in a mini-series of 2 articles. In the first article, we showed how to develop and evaluate your decoy strategy. In the second article, we’ll present a practical example of deceptive security in AWS.  

Initial assumptions and choice of scenario     

Thanks to Wavestone’s expertise and the resources shared by our CyberLab, we have designed a simple scenario to illustrate the use of decoys in an AWS Cloud environment. The example detailed below is inspired by a CTF (Capture The Flag) scenario designed by the CyberLab team to illustrate the lateral propagation of an attacker.  

As in the previous scenarios, where we used Deceptive Security for the detection of attackers already introduced into the IS, the aim is once again to avoid attracting opportunistic attackers to our network with a “search” Deceptive Security approach. We therefore assume an initial infection of some kind, which is highly probable (all the more so in poorly controlled Cloud environments), and concentrate on detecting the intruder as it is being deployed into the network. 

Applying this approach to an AWS environment is no innocent matter. One of the benefits of the Cloud lies in its simplified identity management and easy delegation of access, but this asset can turn to the advantage of attackers in the event of unintentional exposure of resources, or the creation of dangerous links between zones of different security levels. There is no shortage of hardening and prevention measures, generously promoted by Cloud providers themselves, but these vulnerabilities remain in poorly hardened accounts and subscriptions, whose administration too often obeys rules that are still informal.   

The attack scenario and associated luring will therefore be based on the principle of linking two AWS accounts, here conceived as a production environment and a less critical development environment. We’ll place ourselves in a scenario where an approval relationship is used to propagate from the development account to the production account, via the endorsement of a cross-account role. 

Luring scenario  

Description of the scenario   

Let’s assume that an unauthorized user has gained access to an EC2 machine (domainIntegrated-EC2) within the test account (initial infection). After an initial successful connection,  they attempt to access commonly used resources such as Amazon Simple Storage Service (Amazon S3), or tries to elevate their privileges by assuming other roles (role chaining) related to the role to which they have access.  

This lateral propagation scenario is a common attack technique in cloud environments due to the nature of their architecture and the cloud computing responsibility model, where the customer is responsible for securing their applications, data and access control (while the provider ensures the security of the underlying infrastructure). 

As illustrated below, lateral propagation attacks take advantage of weaknesses in the customer’s security controls, such as misconfigured authorizations or the application of too-weak authentication mechanisms, to gain unauthorized access to other resources in the environment. 

Scenario from the attacker’s point of view 

0. After compromising a “domainIntegrated” EC2 machine, the attacker discovers that it has a role associated with it (“Semi-Admin-role”):  

 
Enumeration of EC2 machine domainIntegrated 

It then lists the rights of the “Semi-Admin-Role”: 

 
Enumeration of Semi-Admin-Role rights 

First, this role has modification privileges on a resource in the “AWS – SHARED” account: it can assume (sts:assumeRole) and modify (iam:UpdateRole) a role called “LambdaAuto”. He can then assume (by “role chaining”, step 5 in the diagram above) another role called “SecurityAudit” in a different account, called AWS MASTER.  

The attacker also realizes that they can directly assume another role (“IAM-RO-Role”) in the AWS – MASTER account. This latter role attracts particular attention, as the MASTER account’s name suggests a much greater scope of action than the simple SHARED account, and the IAM-RO-Role role suggests an extended scope of vision over the account’s resources. 

1. The attacker assumes the “SemiAdmin-role”, which then allows them to assume the “IAM-RO” role and attempt other actions that will enable them to analyze their field of vision. 
2. Indeed, after assuming the “IAM-RO” role, he proceeds to an IAM enumeration where they becomes aware of the roles and users in their field of vision: 

List of roles in the field of view of the IAM-RO role  

List of users in the field of view of the IAM-RO role  

The “SecurityAudit” role in particular attracts their attention thanks to the privileges that this name suggests and the role description, which provides information on these privileges:  

SecurityAudit role description 

However, the attacker only has read access to the resources listed. They will therefore look to see if any of these resources can be written to from the SHARED account, where they have high privileges. For example, if certain MASTER account roles can be endorsed by SHARED account roles:   

List of roles that can be assumed from an external account (here the SHARED account) 

The attacker investigates the approval relationship of the “SecurityAudit” role, which authorizes an endorsement by the “LambdaAuto” role of the SHARED account. 

0. Back on the SHARED account, all the attacker has to do is check that the other counterpart of this approval relationship, i.e. that the “LambdaAuto” role does indeed authorize the “SecurityAudit” role’s endorsement in its approval policy. This is not the case, but the “SemiAdminRole” role allows it to configure this authorization. 

1.Once the “LambdaAuto” role approval policy has been modified, it can now assume the “LambdaAuto” role. 

2. Then they take on (by role-chaining) the role of “SecurityAudit”, the real decoy. 

Role chaining of the attacker 

After attempting to take on the “SecurityAudit” role, from which they hope to gain the privileges of a security auditor (announced in step 1), the attacker in reality finds themself without any real powers, for example : 

Example of denied access from the SecurityAudit  

Creating lures 

The diagram below shows how decoys are added at different stages of the attack and how they are configured by the defender: 

Scenario from the defender’s point of view  

0.The “Semi-Admin-Role” is the entry point into the decoy scenario. It can therefore be associated with any resource likely to be compromised (here the EC2 “domainIntegrated”) to redirect the attacker to the decoys. 

No alerts are configured at this level, as the Semi-Admin role’s connection to all SHARED account resources makes it likely that unintentional endorsements will be triggered, resulting in false-positive alerts. 

1. Once the IAM-RO role has been assumed, the attacker is then invited into an account entirely dedicated to luring and familiarising themselves with the surrounding resources, gaining a complete overview of all the account’s roles and users.   
2. By populating the attacker’s field of vision not only with the main “SecurityAudit” decoy, but also with other dummy roles and users, we ensure that the account’s appearance appears credible and that our key decoy, the SecurityAudit role, is not isolated.   

We thus add to the account :   

• Users : different user names attracting the attacker.  
• The “LambdaFunction” role: this role is created to simulate a Lambda function that calls on AWS services.  
• The “LogsAndS3Bucket” role: a role created to facilitate access to logging services and S3 storage resources within the account.  
• The “taskExecutionRole”: the task execution role that can be used for different purposes and services associated with the account.  

3.  The “SemiAdminRole” role has deliberately been configured with permission (iam:UpdateRole) on the “LambdaAuto” role, enabling it to modify this role and thus add the approval relationship to the “SemiAdminRole” role. For monitoring purposes, an initial alert can be triggered at this level when the “LambdaAuto” approval relationship is updated, enabling the “SemiAdminRole” to assume it.   

4. The “LambdaAuto” role is deliberately created as the gateway to the “SecurityAudit” role, once its approval relationship has been modified using the privileges of the “SeminAdminRole” role. 

5. The “SecurityAudit” role is deliberately configured with an approval relationship authorizing the “LambdaAuto” role of the SHARED account to assume it. 

6. At this stage, the attacker had assumed that they would be granted security auditor rights. However, a very restrictive Security Control Policy (SCP) was applied, granting them no privileges on the account. 

The policy prohibiting all actions from the Security-Audit-Role 

Alerting chain 

An alerting chain in the AWS cloud refers to a means of communicating notifications or alerts generated by AWS services to users or teams responsible for managing these services, enabling them to take rapid action to resolve problems and minimize service interruptions.   

To set up an alerting chain, you first need to configure AWS services to generate alerts when certain events occur, such as, a server down or an application exceeding a specific CPU usage threshold. Once these alerts have been generated, they can be sent to the appropriate alerting chain according to the notification preferences configured by the user or the team responsible for managing the service.   

In order to detect the attacker, we use the following AWS services to create the alerting chain: 

• CloudTrail l to track actions performed on the compromised AWS account; 
• EventBridge to detect any “AssumeRole” event of the “SecurityAudit” role and trigger an alert ; 
• Simple Notification Service (SNS) to send the alert by e-mail with the information gathered during the attack.  

Illustration of the alerting chain 

Alerting chain creation steps :  

Cloudtrail configuration  

The first step in creating an alerting chain on AWS is to enable CloudTrail (if not already activated) in your AWS account. CloudTrail logs all activity and API calls in your account, which can be useful for security, compliance and troubleshooting purposes.   

Based on the logs generated in CloudTrail, we’ve created an EventBridge rule that sends notifications to the SNS service whenever the “SecurityAudit” role is assumed (event type: AssumeRole). 

Creation of an EventBridge rule 

A rule monitors specific types of events, and when a corresponding event occurs, it is routed to the service associated with the rule and handling the event (in this case, the SNS service).  

The event model detects all events of the “AssumeRole” type occurring in the account used and triggers the alert. In order to avoid false positives when triggering alerts, we have refined the event model to be as accurate as possible for the events we are interested in.   

This means including relevant fields, such as event source, detail type or specific values, to refine the matching criteria. This reduces the risk of unrelated events triggering the rule. 

The event model detecting all “AssumeRole” events on the “SecurityAudit” role 

The Eventbridge service must therefore first be linked to the SNS target.   

The target related to the EventBridge rule 

SNS rubric configuration  

At this stage, an SNS topic is created and linked to a subscription of an e-mail endpoint authenticated later. The SNS topic will be the target of the EventBridge rule. Once the topic has been created, the e-mail subscription is carried out by selecting the e-mail address as the protocol (endpoint) where the alerts are to be received. 

Other targets than e-mail could be considered for receiving alerts (ServiceNow, SIEM, etc.). 

Details of the SNS rubric 

Alert customization  

EventBridge’s Input Transformer function was used to customize the content of the alert, so that only the most important elements were displayed.   

It allows you to customize the text of an event before it is transmitted to the target.  This is achieved by defining JSON variables to reference values in the original event source. 

Input transformer configuration  

In our case, the variables listed below will constitute the alert message: 

Input transformer creation 

Input model 

The input model will use the variables defined previously within the final alert message:    

Input model creation 

Once the “SecurityAudit” role has been endorsed, an alert is sent to the endpoint created: 

Example of e-mail alert content 

Cost of the AWS services used  

AWS offers a pay-per-use approach to pricing its cloud services. With AWS, you only pay for the services you need, as long as you continue to use them, without a long-term contract. You only pay for the services you use, and if you stop using them, you won’t be charged any additional costs or termination fees.  

The services deployed in this scenario are not intended to be used except in the event of an intrusion or security incident. The associated costs are therefore negligible.   

Decoy evaluation with the PARCS matrix 

Several criteria can be used to evaluate a lure, and here are the results of our analysis based on the PARCS matrix:   

• Pertinence (efficiency) : 4/4 

«  Various approaches can be adopted to effectively spot the initial compromise of an EC2 instance and the lateral propagation of an attacker. In our context, depending on the resources at our disposal, one possible strategy is to monitor operations by analyzing logs, which will enable malicious actions to be detected. These observations could then be used to generate alerts for administrators. For example, an alert could be triggered in the event of an intrusion attempt via a brute force attack on the RDP service of EC2 instances within our AWS environment, thanks to GuardDuty.  

In addition, it would be possible to use a combination of AWS services such as CloudTrail and EventBridge to establish detection rules and automate interventions in response to specific activities, including those related to cross-account access, and create detection rules that monitor all endorsement events to trigger actions in the event of corresponding events. » 

• Attractivité (attractiveness): 4/4 

« The decoy is distinguished by a dedicated account, significantly increasing its power of attraction. By having access to the metadata of all the resources within their reach, the attacker can also verify various levels of privilege, which substantially enhances credibility. Thanks to the ability to visualize the dates and times of the last uses of resources in their field of vision, they can deduce that these resources are rarely used. With this in mind, a lambda function is implemented to automate the execution of various resources or their authentication, thus guaranteeing proof of recent use.  » 

• Risque (risk): 4/4 

« The authorization granted to the IAM-RO role only confers IAM privileges to the attacker in the context of a purely fictitious account. Thanks to appropriate configuration of the upstream SCP, any attempted actions by the Security-Audit role will also be thwarted. The only elements deliberately introduced in a real environment are the Semi-Admin and Lambda-Auto roles, which are subject to stringent policies preventing any assignment of rights or privileges in the event of attempted malicious use. These policies include read-only access (IAMReadOnlyAccess) and a restriction preventing any modification of account role authorizations, as defined by the SCP. » 

• Crédibilité  (credibility): 3/4 

« The credibility of the decoy may be called into question by the resources available to it and potential limitations, such as an Inline Policy that restricts permissions and possible actions. It’s important to take these factors into account, as they can create doubts in attackers and compromise the decoy’s effectiveness. It is therefore crucial to put in place measures that make the decoy as realistic and convincing as possible, ensuring that it has access to the relevant resources and authorizations to create a credible scenario. » 

• Scalabilité (scalability) : 3/4 

« Depending on the size of an infrastructure, it may be possible to implement fluid deployment and maintenance of components, thanks to the use of automated scripts empowered to perform operations on resources. However, careful monitoring of all resources is essential to consolidate security in the face of possible attacks, and to ensure rapid reaction to defend an extended perimeter.»  

In conclusion, implementing such a Deceptive Security scenario in the Cloud, offers an approach to improving its overall security. It helps restrict an attacker’s ability to explore and propagate across the network, by presenting deceptive paths, delaying their progress and enabling faster detection and response. Decoys, which resemble attractive targets, divert attackers’ attention and resources away from real assets, increasing the chances of early detection.  

In addition, alert mechanisms play a crucial role in providing rapid information on potential intrusions to security teams, enabling rapid incident response and limiting the impact of attacks.  

Combining these defence strategies strengthens the overall security posture of Cloud environments, improves their resilience in the face of constantly evolving cyber threats, and guarantees the integrity and confidentiality of sensitive data.   

By using these deceptive security measures, companies can strengthen their defence against cyberattacks. However, it is important to note that Deceptive Security does not replace existing standard cybersecurity solutions, and that protection against cyberattacks requires the use of complementary security techniques for optimal defense. 

ANNEX – AWS Services  

Definitions from source : AWS documentation → docs.aws.amazon.com. 

SCP – Service control policies : Service control policies are a type of policy that enable central control of authorizations. This ensures that broad guidelines are followed for all AWS accounts in the organization.  

EC2 – Elastic Compute Cloud : AWS EC2 allows you to rent servers (EC2 instances) to best meet your workload needs.  

STS – Security Token Service : AWS STS enables you to request temporary security credentials for AWS resources. This makes it possible to grant temporary access to resources via API calls, the AWS console or the AWS CLI (Console Line Interface).  

Please note: Each STS token has a lifecycle, defined when it is created, of between 15 minutes and 36 hours.  

CloudTrail : AWS CloudTrail is a service that records the actions performed by an AWS user, role or service. 

Fonction Lambda : The Lambda function is a service for executing code. 

SNS – Simple Notification Service : Amazon SNS is a web service for managing the sending of messages (SMS, e-mail, HTTP.S, etc.). 

Thanks to Charles BULABULA  for his contribution to this article. 

Cet article Deceptive Security: the solution for effective detection in the cloud? – Deceptive use example in AWS cloud  est apparu en premier sur RiskInsight.

Today, cyber-attacks are part of our daily lives, and are becoming increasingly numerous and sophisticated.  

Simultaneously, we are moving towards Information Systems built on an ever-increasing diversity of environments, thanks in particular to the Cloud, which is now an integral part within corporate Information Systems. This enables corporation to expand their capabilities, however it also the surface area and risks of attack.  

Conventional intrusion detection and protection techniques already exist and are developing exponentially. These are effective against the most common attacks, however are not always adapted to the specificities of the Cloud.  

This raises questions about the use of proactive strategies, such as Deceptive Security, to stay one step ahead of attackers. Particularly in the context of Cyber-Resilience: how can this kind of technology be used in both a traditional and a cloud environment?  

When should Deceptive Security techniques be used? Are Deceptive Security solutions in the Cloud being developed today? Are there any specific strategies to consider in a Cloud environment as opposed to a traditional one? 

We will answer these questions in a mini-series of 2 articles. In the first article, we will show you how to develop and evaluate your decoy strategy. In the second article, we’ll present a practical example of deceptive security in AWS. 

Develop and evaluate your deceptive strategy  

Ambitions of Deceptive Security 

Deceptive Security in a nutshell 

“Deceptive Security” (referred to as “Deceptive” in the rest of this article), or “digital decoying“, is a cyber-defense technique that deals with the intrusion of attackers into an IS (Information System). It works by setting up traps and/or decoys in an IS. These are designed to imitate legitimate technology, so as not to be identified as security systems/measures.  

This method makes it possible to detect intrusions by generating alerts, to prevent damage to the actual infrastructure and to observe the practices used by the attacker.  

Before delving into the details of this subject, we recommend reading the article “Deceptive Security : comment arroser l’arroseur ? “, which describes the main concepts of “Deceptive Security“.  

The main objectives of Deceptive 

The use of Deceptive on an IS can have several objectives:  

•  Detect an intrusion  
•  Distract the attacker  
•  Analyze the techniques used in the attack 

This technology can be used at different levels of maturity, depending on the needs identified.   

The technology can be used to meet many of the needs mentioned above, but the key is to determine our requirements for this technology in advance. If we restrict the needs for detection, it should be noted that the configuration, deployment and maintenance of Deceptive will be far less complex than if we push the possibilities of this technology to the maximum (e.g. setting up complex scenarios to lure the attacker and strategic analysis of his actions).

The benefits of Deceptive 

Why Deceptive ? 

As discussed in the introduction, today’s cybersecurity challenges are fueled by the need to detect and react to growing attacks.  

Deceptive does not replace existing standard cybersecurity solutions. Being a more complex tool, it acts as a complement to cover all types of attack, including the most sophisticated.  

This technology is not designed to prevent an attack, but to alert security teams, minimize the effects of the attack and observe the intruder’s modus operandi (“Detect, Distract & Analyze”). 

Honeypot VS Honeytoken 

Presentation of concepts 

Depending on the needs and how they are to be used, different types of decoys exist. Whatever the case, they take on the appearance of attributes that make up our Information System.  

The best-known decoys are “honeypots”. These are servers or workstations that imitate real machines on the network. There’s also what’s known as a “honeynet”: a network of servers.   

Another type of decoy is of growing in popularity. This is a decoy that hides directly on a system. These are generally represented by documents or other files whose role is to trigger an alert when someone comes to interact with them. Finally, we have “honeytokens”, which are data, information, often secrets or keys used to access a dummy resource on the IS (a honeypot, for example). 

A fundamental difference 

Traditionally, honeypots enable the observation and understanding of an attacker’s actions, as well as detecting an intrusion. The difficulty in this case is to configure a decoy that is attractive and credible enough for the attacker to fall into the trap, without delivering information that could compromise a component of our real infrastructure.  

However, honeytokens can be more complex and enable the creation of a finer and more credible decoy. Without honeytokens, the probability of trapping an attacker is lower, and analysis results are not always reliable. The honeytoken’s dependence on its environment makes it more attractive in comparison to a honeypot, which represents no more than a trap with no possibility of subsequent escalation. For honeypots to be effective, we recommend deploying one or more complete honeynets, however it is important to consider the cost of such an infrastructure.  

Cloud technology development 

Today, the challenge for the most mature Deceptive solution vendors is to develop specific services in the Cloud.  

Indeed, companies are increasingly using the Cloud to extend their storage, deploy virtual machines, containers and so on. This provision of services is very popular and effective, but at the same time, the interest of cyber-attackers is growing. Templates, or default configurations, make life easier for businesses, but can increase cybersecurity risks. Even though many Cloud providers are making great strides in this area, default configurations don’t always comply with IT security guidelines.  

The Cloud is therefore a new playground for cyber-attackers. That’s why we’re focusing today on adapting our knowledge of Deceptive to protect Cloud environments and services too.  

Overview of the main publishers on the market 

It’s important to note that Deceptive is not reserved for overly complex applications. There are all kinds of offers on the market. Some companies offer services that enable you to obtain a complete off-the-shelf tool, while others focus on customization, lure quality and therefore the possibility of using their tool to create your own lures (configuration and maintenance not managed by the solution itself).  

Here’s an overview of the main publishers and their solutions:   

For some, the current trend is to join forces with other tools or integrate their solution with an EDR (Endpoint Detection and Response) to increase the effectiveness of the technology and meet market needs.  

As mentioned above, the challenge that some have chosen to tackle is to adapt to a Cloud environment. For example, solutions such as “Attivo Networks”, acquired by SentinelOne, are developing Cloud AWS offers that propose the creation of decoys linked to the service (e.g.: EC2, S3, AWS access keys, etc.).  

How to build and place decoys? 

Deceptive strategies 

Once you’ve familiarized yourself with this technology and all the possibilities it offers, it is worth asking yourself the question, what strategy or strategies you should adopt with regard to the number of traps and/or decoys to be implemented, and where they should be placed in the IS.  

To adapt to different use cases, 3 strategies stand out, responding to distinct needs: 

Indeed, the Deceptive strategy to be adopted is often tailor-made according to the IS infrastructure and, above all, according to the priorities and objectives defined beforehand.  

By way of example: if you need to enrich your detection technologies within your IS, it may be worthwhile to study the strategy of “mass deployment” of decoys. The aim is to create a phantom IS, thereby increasing the likelihood of the cybercriminal falling into a trap that will trigger an alert to the security teams.  

PARCS matrix 

The challenge when talking about Deceptive, and more specifically about lures, is to answer the questions: What is a good lure? How do you create a good lure? Where to place it? How many to place? etc.  

The article “ HoneyWISE : stratégie d’exploitation d’honeytokens en environnement Active Directory ”, written by Augustin TOURNYOL-DU-CLOS and Nathan FAEDDA, proposes a decoy strategy against certain attacks in a specific context: AD (Active Directory). We’ll also look at honeytokens in comparison with honeypots in the rest of this article.  

The objective of this study was to simply test the implementation of decoys within the AD and to measure their effectiveness using the “PARCS” matrix.  

PARCS was born on the basis of 5 criteria, originally conceived in the context of an AD environment but applicable to all environments:  

When designing a decoy, it’s a good idea to prepare a PARCS to check your thinking and ensure that it matches your expectations. It is also important to take into consideration minimum requirements illustrated by these 5 criteria: Relevance, Risk, Credibility, Attractiveness and Scalability.  

The objective of this matrix is to determine a balance between importance and priority based on these criteria’s (Is the lure’s attractiveness important in my use case? Do I need a scalable solution? How scalable? etc.).  

Example of PARCS use: Kerberoasting scenario “Stealing or falsifying Kerberos tickets” 

Perhaps the best way to illustrate the PARCS matrix presentation is with an example from the “ HoneyWISE ” article.  

The AD attack called Kerberoasting is, “[…] in synthesis, the offline brute force (no logon failure) of a Kerberos ticket receiving the secret of a service account, without having to send a single packet to this service or even being the local administrator of the compromised workstation”.  

“Kerberoasting […] hijacks the native operation of Kerberos in order to carry out an attack. This hijacking takes place on steps 3 and 4 of the Kerberos authentication process, as shown in the following diagram”: 

For this attack case, Augustin TOURNYOL-DU-CLOS and Nathan FAEDDA propose in their article to deploy a honeytoken against Kerberoasting (see part 2.3 “Description of detection scenarios” – scenario 2).  

Here is the result, through PARCS, of the study of this type of honeytoken in the context of a Kerberoasting scenario (16/20): 

• Pertinence (efficiency): 4/4 
  • «  The alerts generated by this honeytoken are reliable. In fact, as soon as a TGS ticket is requested to access an unused and non-existent service, it becomes clear that a malicious action is underway. » 
• Attractivité (attractiveness): 3/4 
  • «  The attractiveness of this token lies in the fact that carrying out the attack does not require any privileges, and can potentially gain privileges while being silent (generation of traffic deemed legitimate). Provided that the account chosen to lure the attacker appears privileged and managed by a user (so that the password is likely to be simple), this honeytoken is highly attractive. » 
• Risque (risk): 4/4 
  • « In our example, a 64-character password has been defined, which cannot be broken in a reasonable time. » 
• Crédibilité (credibility): 3/4 
  • «  Subject to the choice of account name and attributes according to the production context in which it is deployed, since the attack is based on normal Kerberos operation, it should come as no surprise that it can be carried out. Credibility is therefore high. » 
• Scalabilité (scalability): 2/4 
  • «  The decoy account can be deployed automatically on several domains using scripts. However, for an effective lure, contextualization remains essential and will be the major obstacle to effective mass deployment. The cost of providing this contextualization and keeping it up to date must therefore be taken into account.  » 

To conclude, Deceptive Security solutions must be considered on a case-by-case basis. It is imperative to determine in advance the objectives to be prioritized, the strategy to be adopted, the scope to be covered, and so on.  

In certain situations, especially for companies with mature IT security systems, it may be appropriate to implement Deceptive Security solutions. This is to be applied in addition to standard minimum security tools such as firewalls, antivirus, intrusion detection and/or prevention systems, etc. The aim is to cover all types of cyberattack (“0-day” type, with no known pattern).   

This technology can be difficult to implement for smaller companies, as they may not have the essential security tools in place by default, nor the resources to configure (e.g., design decoys, create strategies and scenarios) and maintain such a solution (e.g., dedicated maintenance teams).  

Today, the market is expanding, mainly around detection thanks to Deceptive, but not exclusively. For the time being, however, vendors’ interest in building deceptive solutions is focused on traditional environments. Solutions for Cloud AWS, Azure, etc., are still underdeveloped. 

Thanks to Augustin TOURNYOL DU CLOS for his contribution to this article.

Cet article Deceptive Security: the solution for effective detection in the cloud? – your luring strategy.  est apparu en premier sur RiskInsight.

I had the opportunity to organize a round table on confidential computing for the Assises de la Sécurité de 2022, moderated by Thierry AUGER, CISO & Corporate CIO of Lagardère, and including Mathieu Jeandron of AWS, Thiébaut Meyer of Google Cloud, Arnaud Jumelet of Microsoft France and Julien Levrard of OVHCloud. This article intends to summarize the exchanged elements by discussing use cases, the technology, and the initial steps to be taken.

Purposes of Confidential Computing

The principle of confidential computing is to create an enclave that ensures that only the processes running within the enclave has access to clear text data. Before going into more detail about how the technology works, we’ll look at how it can be used to improve cybersecurity.

Multi-party Confidential Data Analytics

Several parties want to share data in such a way that none of the external parties will be able to access thier data. This requirement will be met by putting in place a confidential computing enclave. Only the cellar will be able to see the information of what each party shares.

Example: Several banks wish to collaborate on the development of a fraud detection algorithm. However, none of the banks wants their customer information to be used for this analysis in the fear of data getting exposed to other parties.

Federated AI Learning

Several parties want to pool their data to train an artificial intelligence algorithm. The data must not be disclosed to or known by another actor. The confidential computing enclave will guarantee that only the artificial intelligence algorithm has access to the data.

For example, several hospitals want to train an AI model to upgrade their medical diagnosis on a larger scale. Medical secrecy also requires, under no circumstances another actor will have access to their patient’s data.

Protection of Calculations in Edge Computing

Edge computing cannot guarantee the same level of physical security for processing as the data center. However, it is desired that the embedded code and processed data remain inaccessible and unmodifiable. The confidential computing enclave will be able to provide the aforementioned guarantee.

Example: An IoT solution provider wants to ensure that the code embedded in its objects cannot be accessed, guaranteeing its intellectual property.

Finally, the most frequently cited use case is the protection from its infrastructure provider.

Here, it’s important to make sure that the administrators of the infrastructure on which I’m going to carry out my processing cannot access my data. Satya Nadella, CEO of Microsoft, stated at the Microsoft Build in May 2022 that he considers confidential computing to be a game-changer.

For example, a cloud service provider should not have access to the data processed on its infrastructure. Today, confidential computing provides a hardware-based guarantee in addition to the existing logical isolation mechanisms and implemented security measures. This can restrict the administrators’ actions. In the event of a vulnerability on the latter, the enclave also provides enhanced security against malicious access by a different virtual machine running on the same hypervisor.

The promises seem interesting, but how does confidential computing work?

Confidential computing aims to perform the processing in an enclave accessible only to the processor; this property is materially guaranteed by the processor and its firmware (*). A secure channel is established between the enclave and the processor, preventing any intermediate components (Hypervisor, OS, etc.) from accessing the data.

^{(*) The technical implementation of the enclave differs based on the processor founders (Intel, AMD, ARM, IBM, etc.). Let’s not elaborate on it in this article.}

There are two primary forms of an enclave:

• Enclave at the machine or container level: all processing performed within the virtual machine or container is protected.
• Application-level enclave: the enclave will protect only a portion of the application (for example, the code performing sensitive processing: raw data is never accessible, only the results are)

During the round table, Arnaud Jumelet presented an analogy with a building:

An enclave at the level of a VM or container can be compared to the protection that an apartment would provide in relation to the rest of the entire building: only those with the keys can enter.

In the case of an enclave at the application or code level, it can be compared to a safe within the apartment that protects the processing.

In the first case, the building manager (i.e., the IS infrastructure management) has no view of what is going on in the flat, whereas in the latter case, not even those with access to the apartment (i.e., the VM administrator) can see what is happening in the safe.

It all sounds magical; does it cover all my risks?

Confidential computing is a new toolbox for reducing risks. Mathieu Jeandron warns that it should not be used in opposition to existing measures; it is a matter of adding a hardware-based guarantee to the logical isolation offered by virtualization.

Like any tool, it can have its own security flaws, such as side-channel attacks (like the SQUIP vulnerability) or attacks affecting other functions of the processors (such as attack on the server). However, these attacks require a high level of expertise. During the round table, Thiébaut Meyer stated that disabling hyperthreading can reduce the risks associated with these vulnerabilities. It is also crucial that the enclave, upon startup, verifies that it is running in a trusted space like process challenge, processor firmware version verification, etc.

Mathieu Jeandron mentioned that completely understanding confidential computing will not address all his risks, with respect to the following:

• In the context of a VM-level enclave, the VM administrator will always have access
• Vulnerability in the code running in an enclave could still be exploited by an attacker to access the data
• Compromise of the supply chain producing the processors is always a possibility…

Implementing an enclave can blind certain external cybersecurity detection mechanisms; beware that what is on one side could be lost on the other!

To make a well-thought-out plan for using the technology, it is important to understand both the technology and the associated risks.

Data protection is a matter of key management

Encryption is never far away when it comes to data protection. Moreover, encryption requires key generation and storage tools. Julien Levrard reminded us that the protection provided by the enclave is only one part of the problem, whereas it must be seen holistically! 

Specifically, both the data to be processed and the code running in the enclave originate from outside the enclave. The data must therefore be encrypted, and only the enclave must have access to decrypt the data. Therefore, the keys must be sequestered in an HSM or KMS, which must verify that the correct enclave is requesting access prior to releasing the keys. The customer will have the option of utilizing the services of the supplier or implementing BYOK or HYOK.

I see an opportunity, but isn’t it too complicated to go there?

The Confidential Computing Consortium, which aims to promote the technology, provides accelerators to facilitate this adoption. For example, Arnaud Jumelet mentioning about the open-source project OpenEnclave or Enarx. There are also services that offer player-building solutions, such as Securitee, Cosmian or Decentriq. Furthermore, many software players have also incorporated the integration of confidential computing functionalities to their roadmaps; in the future, this may be the default operation!

The majority of confidential computing initiatives in France are currently in the Proof of Concept (POC) stage. However, some use cases are already in production; the SIGNAL messaging system uses confidential computing to protect messages, for instance. Thiébaut Meyer even indicated that the first ransomware used this technology to evade detection!

Julien Levrard explained that the technical requirements for testing are straightforward: simply order a server of the latest generation and activate the function in the firmware or subscribe to cloud resources that are compatible. In an enclave, one can then easily deploy an OS or container with the appropriate drivers. For the business use cases described at the beginning of this article, however, the application code must be redesigned.

Confidential Computing- A Maturing Technology

Confidential computing has matured to the point where an expert assembler is no longer required to use it. This is probably the right time for companies with use cases to test this technology to better understand it before deciding on its use in the production.  Moreover, it makes sense to incorporate this into a security roadmap.

Cet article <strong>Confidential Computing: Revolution or New Mirage?</strong> est apparu en premier sur RiskInsight.

Figure 1 : The three fundamental principles of the Zero Trust model

Despise these principles being well-known now, their practical implementation still represents a challenge for many organisations.

Currently, there is not and will not be a specific product that can be used to implement a Zero Trust model, instead, there are many distinctive implementation architectures. For user access, Zero Trust can be applied using two main architectural models (which are not in conflict and can be complementary):

• A model using a cut-off infrastructure element, e.g., a Secure Access Service Edge (SASE) approach. It dynamically controls network access to IS resources (where the user’s identity and posture are being used to make the decision).
• An approach where only identity is used to make the cut: access to IS resources is conditional, requiring proof of authentication and authorisation. In this approach, access control is carried out by an identity provider (identity manager or IdP) and by the targeted resources themselves.

The second type of architecture will be the topic of this article. We will focus on the implementation process which uses Azure Active Directory (AAD) as the Identity Provider.

Before understanding how the Identity Provider can be used to implement Zero Trust, here is a small description of the theory on the token-based access management mechanism.

AAD-based access management: a token story

AAD-based access management follows the principles of the access scheme involving an Identity Provider, i.e. a service to which the target resource delegates the management of the life cycle of user identities and their authentication.

In this scheme, a user’s access to a resource requires the presentation of a valid pass, issued by the Identity Provider after the user’s authentication process and (potentially) verification of his entitlement to access the target resource. These passes are called tokens and are cryptographically signed to protect against the use of fake tokens.

What is a token? A token is a string of characters containing various information called clauses, transmitted, for example, by HTTP (HyperText Transfer Protocol) requests.

AAD, as an identity provider, can issue three types of tokens, known as Security Tokens:

ID Token: Evidence of user authentication. It contains information about the user’s identity and the authentication context. It is not associated with any specific resource nor involved in access control.

Access Token: A pass authorising access to a particular resource. It may contain attributes or claims that allows the targeted resource to refine access control, such as the permissions delegated to the client application (scopes) on the resource. However, in case of Azure AD (a self-supporting token (*) (JWT)): it cannot be revoked after it has been issued. Its lifetime has an average of one hour. In other words, an Access Token remains valid until its lifetime ends.
^(*)Another implementation of OAuth could have been with opaque tokens which requires querying the Authorization server in order to find the details. This type of implementation would allow for easier revocation. This is not the choice made by Microsoft.

Refresh Token: is provided at the same time as the Access Token; it allows obtaining a new Access Token/Refresh Token pair after the expiration of the previous Access Token, without explicit user re-authentication. It also allows to retrieve Access Tokens for other resources without explicit user authentication. In the context of Azure AD, its lifetime is 90 days or 24 hours for Single Page Applications, and unlike Access Token, it can be revoked before its expiration.

It should be noted that Microsoft has defined a fourth type of token, the Primary Refresh Token, which allows single sign-in between applications on a given device. This token will not be mentioned in the rest of the document for the sake of simplicity.

Now we need to understand how these different tokens circulate from actor to actor!

Initial access to the target resource

At the time of the initial access, we assume that there are no valid tokens: no Access Tokens for the target resource nor Refresh Tokens. When the user wants to access the target resource, he will be redirected to AAD to be authenticated (and eventually authorised).

Figure 2: Dynamic process of obtaining an Access Token/Refresh Token pair during the initial access to the resource

The resulting Access Token will be included in each request to the target resource. The target resource will process them as long as the access token has not expired.

Renewal of access rights to the resource

After the expiration of the initial Access Token, the Refresh Token will be used to silently retrieve, without user intervention, a new Access Token/Refresh Token pair.

Figure 3: Access session dynamic maintenance via the renewal of the Access Token/Refresh Token pair

In an access management model, which involves an Identity Provider such as AAD, it can be noticed that the tokens are the keys to the castle and the Identity Provider is the gatekeeper. Let’s now look at how well this access management model implements the principles of Zero Trust for applications that rely on AAD to manage their login sessions.

Tokens: vulnerable vehicles of implicit trust

Looking at how Azure AD-based access management works, we see that:

• Access to any resource delegating access management requires proof of authentication and authorisation, through the presentation of a valid Access Token, regardless of the network origin of the access.
• An Access Token only gives access to one resource. Access to a different resource requires a dedicated Access Token from the Identity Provide.
• The Refresh Token allows to obtain Access Tokens for all resources to which the user is authorised

The application of Zero Trust principles is partial and perfectible at this stage:

• By default, the delivery of the Access Token is done against a basic authentication (login and password)
• The validity of the Access Token is decorrelated from the context. It can be used during its validity period, independent of the potential compromised signals that could have been detected
• The Access Token can be renewed without verification, if the authentication context did not changed

Conditional Access (CA) reinforces the conditions for issuing tokens and securing of the sessions

Conditional Access (CA) is an AAD function requiring an AAD Premium P1 or M365 Business Premium licence that allows context to be considered in access management.

Thanks to CA, it is possible to integrate a set of signals related to the user’s identity, the terminal used, the target resource, the access context and/or the risk level into the access authorisation decision.

The CA also allows non-binary authorisation decisions to be applied. Thus, an access carried out in a certain context can be authorised under specific conditions, which aim to compensate and reduce the level of risk associated with the access context. 

Figure 4: The principal of Conditional Access

The distribution of an Access Token can be conditioned by implementing a two-factor authentication, which helps to protect against unauthorised access (as a result of stolen credentials).

In addition, the CA offers other mechanisms for conditioning the use of tokens. Here we will focus on two mechanisms in particular: Sign-In Frequency (SIF) and Continuous Access Evaluation (CAE).

The Sign-In Frequency: influences the frequency of explicit user authentication

The Sign-In Frequency is used to define a maximum duration during which the user must re-authenticate after having been initially authorised access to the target resource.

Beyond the given timeframe, the Refresh Token cannot be anymore used to implicitly renew the Access Token/Refresh Token pair.

The SIF is thus a means of limiting the implicit trust given to Refresh Tokens over time.

The operation of the mechanism is illustrated below, for a SIF set at 90 minutes.

Figure 5: Illustration of the operation of the Sign-in Frequency

Note that the SIF has no effect on the validity of Access Tokens already issued. An Access Token that has not yet expired can still be used to access the associated resource, even after the maximum duration defined by the SIF has expired. The SIF only intervenes to prevent an implicit renewal of Access Tokens already issued or the implicit obtaining of new Access Tokens. In order to act on the Access Tokens already issued, it is necessary to turn to the Continuous Access Evaluation (CAE).

Continuous Access Evaluation (CAE) represents the way of linking the validity of Access Tokens to the context

CAE is a CA feature, available since January 2022, that allows context to be considered throughout the access session and not only at the time of the initial authorisation, so that it can force a renewal of the Access Token already issued in response to certain signals, including signals that suggests a compromise.

Figure 6: Types of signals that can force the renewal of the Access Token

CAE requires a communication link between AAD and the target resource to notify the latter of signals requiring re-authentication and to retrieve the conditional access policies defined for it. When the target resource receives an access request, it checks if it has not previously received a notification about the concerned user and whether the access context is different from the one allowed by the conditional access policies or not. If so, it rejects the access request and sends the user back to AAD with a request (challenge) for explicit re-authentication and a re-evaluation of the applicable access policies.

It should be noted that CAE is not a transparent mechanism for the target resources and its implementation requires changes in their operating logic. The implementation of CAE requires a CAE-capable client application capable of interpreting the request (challenge) returned by the target resource while redirecting the user to AAD. Microsoft has started to implement AAD for its M365 collaboration suite applications.

Summary

Nowadays, it is possible to implement a Zero Trust access philosophy based on identity, however, to avoid falling into the shortcomings of historical security models, the conditions for issuing and using these tokens must be tightened up, otherwise they will become carriers of implicit and excessive trust.

The use of mechanisms allows us to integrate signals that authorises the evaluation of context and allows a continuous control on the issued tokens when necessary.

However, it must be kept in mind that, in the face of a token theft scenario, these mechanisms play a reactive role depending on detection capabilities, and not a preventive role capable of preventing the use of stolen tokens. We will have the opportunity return with more details in a future article, discussing the problems of a token theft and the various existing and emerging solutions for dealing with them. 

Cet article Zero trust and identity as the new perimeter : what about tokens ? est apparu en premier sur RiskInsight.

Misconfigurations in cloud environments are still a source of major incidents and will keep on reoccurring endlessly. With the news continuously providing new examples:  leakage of 1 billion citizens’ data linked to a key leak, phishing campaign using a Kaspersky AWS key, misconfiguration of a NoSQL database, 3TB of sensitive airport data…

The objective of this article is to illustrate how to anticipate a scenario by implementing a Control Tower, or a tool for continuous supervision of the configuration of Cloud resources.

To begin with, a little theory about logs

Cloud logs can be divided into 3 categories:

• System logs: They are generated by the OS and applications hosted in IaaS/CaaS mode. The stakes are not different from a classic on premise IS, but only the architecture of logs collection can be adapted.

• Security infrastructure admin logs: Includes the logs of the security appliances, but also of the PaaS security services used by the customer and the logs of the network flows. For the appliances, there are no new changes here either, it is the same component already in use and well known. However, for security PaaS services and network logs, it is necessary to implement a specific integration and adapt the detection scenarios.
• Cloud Infra API logs: During each API call to create, modify or delete a resource, the Cloud Service Provider will generate a log.

These logs are accessible in dedicated managed services such as AWS CloudTrail, AWS config or Azure activity log:

The time taken to make the logs available will depend on the SLA of the CSP, but they are generally available within 15 minutes after the operation has been carried out.

Exploiting these logs will enable you to move from a manual and static compliance to an automatic and continuous compliance:

What are the technical options for building a Control Tower?

There are three main options for a customer to implement a control tower:

• Native (built-in)
• Custom native
• Cloud Security Posture Management (CSPM)

Native (built-in)

In the first case, the tools activated by the Cloud Service Provider are default, sometimes free of charge, using predefined alerts to assess the compliance of your environments and deliver using a security score.

For example, Trusted Advisor on AWS or Microsoft Defender for Cloud on Azure.           

These native and non-customized solutions make it possible to initiate a control tower, but they are limited as they are a generic response to specific problems.

Custom native

Cloud providers provide many services that allow customers to build a compliance tool for their infrastructure. The CSP tools available are customised to create specific compliance alerts and custom dashboards/KPIs.

In this option, it is necessary to allocate 10-to-40-man days to the project, in order to implement the monitoring infrastructure, define the first alerts and build the dashboards.

The use of several tenants, organizations or Clouds will require a specific architecture to be defined as there is no turnkey solution.

CSPM : Cloud Security Posture Management

Wavestone sees a booming market within CSPM where, Marketsandmarkets estimates that the CSPM market will more than double between 2022 and 2027 from $4.2 billion to $8.6 billion.

CSPMs natively support numerous Cloud providers and provide their customers with numerous dashboards based on the major market repositories. Customers can also easily define their own standards, policies and alerts.

The deployment of this type of tool is very simple, within few days it can be accessible to the customer.

The recurring costs may however be significant: typically 3 – 5% of the Cloud bill in addition to the Cloud services to be activated (similar to the native and custom services option).

Detection speed will also be slightly slower as the CSPM SLA adds to the CSP log generation SLA, typically 20 minutes – 1 hour detection time.

What should my Control Tower monitor?

The major problem customers face when implementing a CSPM with proposed alert activation, is the generation of tens or even hundreds of thousands of high criticality alerts to process. Teams don’t know where to start and are often feel discouraged. Care must be taken not to overload the security teams!

For the implementation of a control tower on a production Cloud IS, we recommend deploying security controls in waves of 10 – 15 at a time. To do this, you need to prioritise the most important topics. Below is an example of prioritisation:

Unfortunately, every rule has its exceptions! Mainly linked to the existing Cloud, specific architectures or technical constraints, it is therefore essential to foresee this situation and the associated governance at the design stage:

• Validation: by the local CISO and/or the global CISO
• Expiration
• Review: decentralised (locally or during annual global audits) or centralised (through continuous global monitoring)

Using tags for cloud resources is currently, the easiest way to do this, however, be aware that some resources may not be compatible such as IAM services.

No matter which model is chosen, the issues to be addressed remain mainly the same:

• Ensuring the legitimate use and application of exceptions
• Define specific indicators on exceptions for subjects at risk from Top Management
• Set up regular exception monitoring campaigns
• Alerting and dealing with when an exception expires

How to implement an effective remediation process?

The implementation of a control tower will generate numerous alerts, which will have to be corrected. The three options possible are listed below: 

Deny

Why remediate when you can simply block non-compliant resources preventively?

With Azure Policy or AWS SCP, it is natively possible to block certain configurations and thus avoid generating new alerts.

For use cases that are not covered, it is possible to set up checks on deployment templates in the CI/CD chains (this nevertheless requires a high level of maturity).

Deploying a deny mechanism on existing environments is rarely implemented as the risk of generating dissatisfaction among development teams is too high:

• Existing non-compliant resources can no longer be modified
• It will generate an additional burden on the development teams because habits must be changed
• …

Automatic remediation

Here, the aim is to correct deviant configurations directly and automatically but beware of side effects!

To do this, it is possible to use the cloud provider’s native services (Azure policy or AWS SSM Manager) or to develop functions for unsupported cases (AWS Lambda, Azure Function or Azure LogicApps).

Manual

Unfortunately, this is the most common solution, but also the most expensive in terms of human resources. Deviating configurations are remediated manually by the teams.

To guarantee the success of a manual remediation, it is necessary to have strong support from top management to ensure the adhesion and motivation of the teams.

The implementation of a Cloud OWSAP type dashboard highlighting the priorities of the moment is a good solution, allowing each person to take responsibility for their area. Each of the subjects mentioned opposite can have one or more indicators.

However, having the support of management is not sufficient, it is necessary to know the person responsible for the resource in order to ask  them to make the changes. In a large international group this is not easy. Our recommendation is to appoint at least one security officer per account/subscription who should have detailed knowledge of the applications and the people responsible for the resources.

In parallel, it is necessary to implement an effective training and awareness programme. In order to minimise the number of alerts and avoid filling the bathtub faster than it empties, the development teams must be fully aware of the security requirements in the cloud.

To begin the remediation process, our advice is to start centrally with an ample sized team in charge of implementing the control tower, but also in charge of mobilising and training local relays, enabling local teams to monitor and manage compliance on their own.

Compliance alert or security alert?

Most companies consider that monitoring the compliance of their cloud resources is not a responsibility of the SOC teams. But the boundary is not so easy to define, especially given the number of security incidents in the cloud that stem from configuration errors: public exposure of a storage resource containing critical data, unconfigured MFA on an admin account, or RDP or SSH exposed on the internet.

Generating a security alert to the SOC will leverage existing processes and tools for 24/7 handling even if the SOC resources are not cloud experts.

And finally, this will be a good opportunity to bring Cloud security and SOC teams together to improve security supervision by adapting it to the reality of the cloud.

Cet article Compliance in the Cloud, a new Paradigm est apparu en premier sur RiskInsight.

Due to a lack of internal resources or expertise, it is still common to see configuration errors, such as a publicly deployed Storage Account or S3 bucket, allowing attackers to access and exfiltrate the data, or Network Security Groups that have not been properly configured to restrict flows, allowing attackers to compromise the cloud account through the exploitation of uncontrolled flows.

These misconfigurations create new surfaces of exposure and provide attackers with new ways to compromise IS.

Ensuring secure and controlled use of cloud services is a major challenge, which requires specific skills and appropriate governance.

What is cloud security posture management?

Cloud security posture management is a set of strategies and tools to reduce the security risks associated with cloud usage. This is achieved by implementing controls on the configuration of resources as well as mechanisms to react in case of detection of a deviation from good practices.

There are 4 main pillars in the management of the cloud security posture:

One of the first steps in managing the cloud security posture is to understand the entire environment; inventory and classification of resources, compliance indicators, risk visualization dashboards, etc. This overview makes it possible to identify the exposed surface of the environment and to prioritize the work to be done.

Effective cloud security posture management relies on several tools that automatically detect resource configurations that do not comply with good security practices. Most of the tools allow companies to assess themselves against standards and norms (CIS, GDPR, HIPAA, …) and thus identify gaps between the current environment and the target to be reached. In addition to the generic security rules proposed by the tools, companies can also integrate rules specific to their context in order to refine the controls carried out and thus build their own security framework.

Cloud environments offer advanced industrialization and automation capabilities that enable the rapid deployment of new solutions to reduce time to market, the time it takes to bring an idea to fruition and deliver a finished product to consumers. In this context of rapid evolution, it is necessary to ensure continuous monitoring of the environment in order to be able to react as quickly as possible when a non-compliant resource is deployed: quarantine of the resource, automatic remediation, etc.

One of the challenges of security is to succeed in integrating it as early as possible in the project cycle, in order to limit the impact of misconfiguration of a resource. To give an example, as part of the management of the security posture, it is possible to integrate compliance controls from the development phase with the integration of Terraform or CloudFormation template analysis in the CI/CD chains. Note that this step requires advanced maturity and mastery of the other three pillars mentioned above.

Focus on CSPM tools: which type of tool for which use case?

CSPM (Cloud Security Posture Management) tools are a range of software that can assist companies in managing their cloud security posture. There are many of them on the market, which we will distinguish into 3 main categories:

• Tools from market publishers (e.g., Prisma Cloud, Cloud Conformity, Cloud Health, CloudGuard, Zscaler, Aquasec…)
• Native tools from cloud providers (e.g., Microsoft Defender for Cloud & Azure policy, AWS config…)
• Open-source tools (e.g., Cloud Custodian, ScoutSuite…).

Although these tools have a common objective, there are many differences, and it is important to study the impacts in order to determine the most appropriate solution for the local context. Some examples of points of attention when selecting a CSPM tool:

Governance and administration of the tool:

What resources are available to facilitate the management of the tool (e.g., available roles and RBAC model, implemented processes, management interface, possible interconnections, etc.)?

Tool coverage:

Is the tool single or multi-cloud? What services are supported? What security rules are implemented in the tool?

Tool features:

What are the dashboard capabilities? Is it possible to set up alerts? Some CSPM tools specialize in one or more of the security posture management pillars mentioned above or are more mature for one cloud provider than for others. It is important to study the features offered by each tool to ensure that it covers all the desired use cases.

Ease of deployment:

How is the tool deployed? How long does it take? Is the tool available in SaaS mode or does it require the implementation of a specific architecture?

Ease of use:

How is the user interface? This criterion is particularly important because some tools, although very flexible, require specific skills (e.g., scripting) and may require detailed knowledge of the subject.

Available support:

Are security standards updated automatically? How long do new cloud services take to implement after they are released? The cloud is a very evolving environment, new services are regularly made available, implying new security risks. The ability of a CSPM vendor to adapt to its customers’ evolutions by proposing new rules and supported services is therefore a major asset.

Pricing:

What is the pricing model? Do we have to pay per resource? How many people are needed to administer the tool? Depending on the tool chosen, prices can vary widely. Particular attention must be paid to the choice of a solution that is well sized in relation to the expectations expressed. 

Based on these criteria, it is possible to observe major trends shared by tools in the same category.

To summarize: CSPM tools from market vendors offer a lot of functionality that is easily deployable but not very customizable.

Native CSPM tools from cloud providers are easily integrated into the existing ecosystem and have cloud provider-specific functionality, which does not always cover all needs.

As for open-source tools, they have the advantage of being very flexible and giving the user a great deal of leeway, but these tools are complex to maintain over time and require specific skills to be deployed and used.

Choosing the most appropriate type of tool therefore requires identifying the challenges specific to one’s context and studying how each type of solution responds according to its characteristics.

Here are some examples of questions an enterprise might ask when selecting a CSPM tool: Is the enterprise’s security posture management maturity appropriate for its current use of the cloud? If not, is the delay in tooling or in the definition of security best practices in a Group framework? Does the company have the internal skills to ensure that the management of the security posture evolves at the same speed as the business needs of cloud usage?

Indeed, the choice of a CSPM tool must be part of a more global process of managing the security posture, in other words, by relying on the company’s local governance and expertise capacities.

CSPM industrialization: the key steps

Implementing an effective security posture management is a long process with several steps. Any company wishing to gain in maturity on the subject must define an industrialization strategy allowing to progressively reach the target. The following chart is an example of an industrialization strategy:

This consists firstly of the initial compliance of the cloud environments to secure them. This phase can be carried out using cloud native CSPM tools or using a tool from the market. The advantage of these tools is that they provide a framework and generic security rules on which a company with little experience in this area can rely. In order to capitalize on the tool’s feedback, a governance and action plan must be put in place to:

• Prioritize the identified projects
• Define indicators for monitoring compliance (e.g., percentage of resource compliance by service and/or by criticality)
• Support projects in bringing their environment into compliance by providing them with the necessary elements to remediate non-conformities

Once the desired minimum level of security has been reached (or in parallel with the initial compliance), one of the next challenges is to ensure that new cloud projects do not create new vulnerabilities. It is therefore necessary to set up a structure to support development teams in their cloud projects. This structure should allow the following:

• Maintain a group cloud security repository that is adapted to the company’s context and evolves with the demands of new business use cases
• The implementation of security validation processes (automated or not) in order to validate the various project stages (cloud eligibility, transition from development environment to production, etc.)
• Security monitoring of cloud services used within the company

The first two steps allow to secure the existing and future evolutions.

The next two steps aim to add a layer of additional validations and controls to perpetuate the use of best practices throughout the organization. In order to implement a generalized continuous monitoring, it is preferable to initially focus on a test perimeter; this test phase allows to:

• Test a new approach in terms of monitoring infrastructure. Technically, this means setting up the CSPM tool(s) needed to ensure both spot audits on a specific perimeter and continuous monitoring of the entire test perimeter. From an organizational point of view, this translates into the implementation of validation processes and specialized teams.
• Define organization-wide control points and mechanisms to ensure their durability: management of the life cycle of security rules, definition of remediation actions per rule, etc.
• Prepare the scaling of continuous monitoring.

Based on the feedback from the previous test phase, the scope of continuous monitoring can then be extended to industrialize the management of cloud security posture within the organization.

The last step corresponds to the last pillar of cloud security posture management, anticipation, and therefore the implementation of advanced features to improve existing practices. Security is integrated upstream of the production launch, i.e., on the left side of this cycle, which is called the “shift-left”.

Synthesis

Managing the cloud security posture within an organization is a major challenge with strong impacts requiring a progressive and incremental implementation.

By relying on the four pillars of security posture management – Visualize, Control, Monitor, Shift-Left; companies are able to ensure the compliance of their cloud environment while following the needs and changes of the business. This objective requires dedicated governance and tools adapted to the local context, all of which evolve with the company’s cloud security maturity.

There are many CSPM solutions available and each one has its own benefits and disadvantages. Particular attention should be paid to the study of the solution that is best suited to the needs expressed and to the future developments envisaged.

Cet article Cloud security posture management: towards an industrialization of the control of its cloud environment est apparu en premier sur RiskInsight.

The bill, originally created to amend a 1986 bill, The Stored Communication Act, allows the United States to force US-based service providers to transfer their customers’ data hosted overseas much more rapidly. It currently takes an average of ten months to obtain the data, rendering investigations conducted from within the US highly unproductive. The bill aims to allow US authorities (from sheriffs to the CIA) to access the data hosted by US companies, without the authorization of a judge. Large technology companies, who have supported the bill in the Senate, will be able to oppose a request if:

• The customer or subscriber is not a U.S. citizen or resident (section 3.2.b.h.2.i), and
• The transfer would require the provider to contravene the regulations of the country hosting the data (section 3.2.b.h.2.ii)

Such a request would then be brought before a US court which would be able to quash (or uphold) the request for the data transfer. Its decision will be based, among other things, on the validity of the information provided, the US’s interest in the request, the scope of the violation, and the chances of it being deemed to contravene the law in the foreign country. The public nature of the appeal is not specified, especially regarding the capacity of companies to communicate about contested requests. Today, it seems likely that the major US players are using such appeals to maintain the trust of their customers.

In order to avoid contravening the regulations of the countries concerned, the US can enter into bilateral agreements with them, which, in return for their goodwill, will be able to access data from the United States.

In the US, the CLOUD Act remains contested due to the risks introduced by the potential agreements with foreign countries. The fact that an executive power can put in place mutual agreements worries the American people, who fear that foreign powers are using the CLOUD Act to access their data without any safeguards.

What are the consequences for customers in Europe?

While tech giants (like Facebook, Google, Microsoft, and Apple) have supported the bill (with the US authorities refraining from approaching them for back-door access and providing a clear framework for data transfer), these regulations raise concerns about customer privacy for the targeted businesses. The act could leave customers without a right to consult, or any information about access to their data by US authorities.

However, European customers whose data is processed in Europe are now protected by the General Data Protection Regulation (GDPR). Articles 45 and 48 of the regulation, which is now in force, lay down a clear set of rules for allowing data to be transferred to third-party countries. According to Frank Jennings (a renowned lawyer on cloud matters), the European Data Protection Board, which oversees the implementation of the GDPR, will be responsible for deciding whether data appropriation under the CLOUD Act constitutes a necessary measure for the safeguarding of US national security, or whether a request does not comply with the new regulation. This could force the United States to negotiate with the EU or its Member States on the conditions for such data transmission, thus protecting their citizens against illegitimate transfers. US customers, however, would remain within the scope of the CLOUD Act.

Negotiations are due to begin between the European Commission and the US. EU leaders have already criticized the US bill as being hastily adopted, something that may complicate negotiations. In the meantime, some 100 civil society organizations have urged transparency from the European Council about the negotiations of the CLOUD Act as set out by the “Convention on Cybercrime” (or “Budapest Convention”).

Privacy laws: an asset for companies?

While the GDPR has preoccupied a good number of companies with respect to the changes it involves for their information systems, and that the ePrivacy Directive is in preparation, it is instructive to consider the connections between regulatory developments and the world of business. Data privacy laws could, whether in the near or distant future, be considered as an aid to protecting business’ data and to maintaining customers’ trust.

In a world where data-privacy issues are becoming increasingly important (think of Cambridge Analytica and Google Home Mini ), protection of customer data can be a decisive factor when choosing between competing offers. The position US providers will take on privacy and data protection issues is therefore eagerly awaited.

What can you do today?

To conclude, the new regulations on privacy remain somewhat ambiguous and may even clash in certain areas. The main conclusion remains that, as a result of the GDPR, Europeans should be better protected against the CLOUD Act, provided US suppliers reject inappropriate requests, and the courts with responsibility for arbitrating them play their roles correctly. Meanwhile, non-European customers will not gain greater protection by choosing to host their data in Europe.

While awaiting the implementation of new laws dealing with confidentiality and possible data appropriation, there are steps you can take to protect your personal and business data against it being inappropriately accessed while overseas, and other potential threats:

1. Clarify with your provider under what conditions it may be required to give access to your data, without forgetting to consider any mutual legal assistance treaties.
2. Define or review your hosting strategy according to the type of data held, your provider’s nationality, and the hosting site’s location.
3. Favor data hosting in European data centers, or in countries with well-established data privacy frameworks.
4. Choosing a French or European supplier enables you to avoid the risks associated with the CLOUD Act. You must, however, stipulate contractually that it does not use US subcontractors (either directly or indirectly)!

Cet article The Cloud Act: does it mean your data is better protected? est apparu en premier sur RiskInsight.

SAAS COMPUTER BACKUP: THE SERVICE PROVIDER’S RESPONSIBILITY TO PUT IN PLACE

SaaS (Software as a Service) is software that is made available on, and consumed directly from, the internet. It is managed by one or more providers.  The customer does not have the wherewithal to carry out the backup activities is case of disaster (no access to raw data, source codes, applications that could duplicate the infrastructure, etc.), so it has to rely on the provider’s goodwill.

Levels of disaster recovery are variable for SaaS, depending on the provider’s degree of maturity

Three major trends are emerging:

• Providers who offer an inclusive disaster recovery plan. As part of their standard offering, the provider offers recovery at a remote data center, usually augmented with outsourced backup. However, they rarely offer commitments on recovery times.
  Examples are the big SaaS players (such as: Office 365, SalesForce, and SAP), as well as some intermediate players (such as Evernote, and Xero);

• Suppliers who offer outsourced backup only. In their case, there is no clearly established disaster recovery plan, as such. The customer then has to question the ability of the provider to restore backup files in the event of a disaster at the main site.
  Examples are intermediate suppliers (such as Zervant and Sellsy);

• Suppliers who don’t mention the issue or do not have anything in place. The subject of backup doesn’t even get raised, so it’s better to assume that nothing is being done.
  Small players are usually in this situation.

Getting contracts right is key

In the vast majority of cases, SaaS providers have no provisions in their contracts on how they will manage disaster recovery, even though they might stress their ability to handle that risk. In fact, contracts usually include default Act of God clauses stipulating that the supplier is not liable for a breach of contractual obligations if this is caused by an event beyond their reasonable control. The legal risks must therefore be addressed when framing the agreement, and these types of clauses should be removed to ensure an appropriate level of cover.

Just as they do when framing conventional contracts, customers must ensure that clear service level agreements are in place, in particular for disaster recovery. These need to cover:

• Recovery times (Recovery Time Objective – RTO) and data loss (Recovery Point – RPO) in the event of a disaster;

• The provider’s disaster recovery plan, including crisis management procedures, as well as the obligation to carry out conclusive tests every year with real-world scenarios, as part of the plan, with the customer having the option to review the test report;

• Financial penalties and the right to terminate the contract (in particular, with a provision to recover usable data) if commitments are breached.

IAAS/PAAS disaster recovery: THE CUSTOMER’S RESPONSIBILITY TO PUT IN PLACE

Infrastructure as a Service (IaaS) is a standardized, automated offering of computing, storage, and network resources owned and hosted by a provider, and made available to the customer on demand. A Platform as a Service (PaaS) offering is similar to an IaaS offer, but it is different in that it only applies to software development stack (database, EDI, business process management…) according to Gartner’s definition. Unlike SaaS, disaster recovery remains the customer’s responsibility in both cases: IaaS/PaaS providers make services available in various data centers, and the customer is responsible for their use and configuration. Two solutions are available to customers using these services: to entrust things to a provider, or manage it themselves.

The market for cloud disaster recovery is not a mature one

Cloud disaster recovery providers are referred to by the acronym DRaaS: Disaster Recovery as a Service. Initially, DRaaS providers offered cloud-based IS disaster recovery of an “on premise” datacenter. But, today, they also offer to provide recovery for infrastructure already in the cloud, such as AWS or Azure. Levels of maturity remain very variable, depending on the provider and which cloud is used. Some DRaaS providers require that their own cloud is used for recovery, which means they cannot offer a PaaS recovery service.

As with SaaS, there are no default contractual provisions. Therefore, any guarantees required for data loss or recovery time will need to be negotiated. Suppliers generally promise to be able to tailor their offer to the customer’s requirements! To ensure that the recovery performs correctly, the customer must plan for disaster recovery tests to be carried out regularly (we recommend once a year).

Operating your own disaster recovery plan, using tools offered by the supplier

For “on-premise” infrastructure, you will need to think about, and define, your DRP strategy right from the design phase. This strategy must include the option of performing tests to ensure a sufficient level of confidence in your plan.

Implementation can be simplified by the tools offered by cloud providers, and the high levels of standardization in cloud environments. The major players have set out, in white papers, the key guidelines to follow in pursuing such a project (for example, AWS and Azure).

Conceptually, these DRP strategies remain close to those used in “on-premise” data centers.

There are four main ones:

• backup and restore: simple backups of data and images of machines on a remote site, which are restored if an incident occurs;
• pilot light: replication of databases and the provision of machines, in the form of images, ready to be used if an incident occurs;
• warm standby: full replication of the main site (data and machines); the recovery site is undersized in performance terms but ready to scale up if an incident occurs;
• multi-site (or active-active): the two sites are identical and share the load from users. If an incident occurs, the remaining site can scale up to cover all users.

Hybrid solutions that are better designed to take account of recovery time requirements, and cost and complexity considerations, can also be considered.

The real contribution that the cloud can make to DRP is the numerous tools that it can offer to simplify its implementation and activation.

As a result, data replication can be simplified for asynchronous geo-replication options (where multiple copies are replicated to other regions). The RPO varies, depending on the types of data and tools involved. Aside from this option, local data redundancy is almost always included.

The high degree of standardization also makes it possible to automate the recovery: the scripts or APIs made available by providers make it possible to automate deployment of infrastructures, resize instances (according to previously defined configuration), distribute loads and traffic, carry out IP addressing, etc., in order to considerably speed up a backup site’s activation time.

The monitoring and alert tools, which are also on offer, are intended to facilitate in-service support and can be used to detect an incident in the shortest possible time, or in some cases, partially automate the activation of a backup site.

Lastly, this ability to provision new resources within a few minutes enables the associated OPEX to be minimized. By using such a strategy, it’s possible to make gains of 40 to 70% on the cost of DRP infrastructure.

Toward greater support by providers?

During 2017, Azure is planning to offer an option to provide recovery for virtual machines hosted on its platform by enhancing its “Site Recovery” service. In fact, “Site Recovery”, in its current form, offers to support traditional site backup, by using the Azure cloud to host the secondary site, but Microsoft wants to extend this service to provide a Recovery as a Service option. This tool would allow the automatic deployment of the secondary site (of the active-passive type), automatic data replication, and easier testing.

This option was available as a “public preview” at the end of May 2017. There is no equivalent project in train from the other main IaaS/PaaS providers.

THE CLOUD AND PROVIDER SYSTEMIC RISK

Backup of cloud-based services is dealt with differently, depending on the type of service used. SaaS recovery must be managed through contracts and are the responsibility of the provider, while IaaS/PaaS recovery, simplified by the tools available, remains the responsibility of the customer.

There is a risk of the widespread failure of a provider’s hosting region as recent incidents have shown. Even though these incidents have been short-lived, or have had minor impacts, the possibility of widespread failure cannot be ignored. The issue of cyber-resilience, then, must still be dealt with. Using a second cloud provider can cover the risk of destruction, or a major outage of a first provider’s infrastructure. This solution is very complex because portability between providers is a difficult issue. For now, there are few companies that have risked it, although  Snapchat is an example: it uses Google’s cloud for its production, and plans to use Amazon’s for its DRP within five years.

Cet article The Cloud: The end of IT backup – or a new way of doing it? est apparu en premier sur RiskInsight.

Le secours informatique SaaS, une responsabilité du fournisseur à formaliser

Un service SaaS (Software as a Service) est un logiciel mis à disposition et directement consommable depuis Internet. Il est géré et administré par un ou plusieurs fournisseurs.  Le client n’a donc pas la latitude nécessaire pour opérer le secours (pas d’accès aux données brutes, pas d’accès aux codes sources, ni aux applicatifs pour dupliquer l’infrastructure…), il doit donc s’en remettre au bon vouloir de son fournisseur.

Un niveau de couverture du secours informatique pour SaaS variable suivant la maturité du fournisseur

Trois grandes tendances se dessinent :

• Les fournisseurs qui disposent d’un plan de secours informatique inclus
  Dans le cadre de l’offre standard, le fournisseur assure un secours sur un datacenter distant, complété généralement par des sauvegardes externalisées. Il ne s’engage néanmoins que rarement sur les délais de reprise.
  Ex : les grands acteurs du SaaS (ex : Office 365, SalesForce, SAP…) , ainsi que certains acteurs de taille intermédiaire (ex : Evernote, Xero…) ;

• Les fournisseurs qui disposent simplement d’une sauvegarde externalisée
  En tant que tel, aucun plan de secours informatique n’est clairement établi. Le client doit alors s’interroger sur la capacité du fournisseur à restaurer les sauvegardes en cas de sinistre global sur le site principal.
  Ex : Des fournisseurs de taille intermédiaire (ex : Zervant, Sellsy…) ;

• Les fournisseurs qui ne communiquent pas ou n’en disposent pas
  Le sujet du secours informatique n’est pas abordé, il est donc préférable de considérer que rien n’est fait.
  Ex : Les acteurs de petite taille sont généralement dans ce cas.

L’importance de l’aspect contractuel

Dans la très grande majorité des cas, les fournisseurs SaaS ne s’engagent pas dans leur contrat sur leur façon de gérer le secours ; même lorsque ceux-ci mettent en avant leur capacité à traiter cette problématique. En effet, les contrats comportent généralement par défaut des clauses de Force Majeure stipulant que le fournisseur n’est pas responsable de manquement aux obligations du contrat dans la mesure où ce manquement est causé par un évènement en dehors de leur contrôle raisonnable. Le risque juridique doit donc être traité lors de la souscription et ces clauses supprimées pour s’assurer un bon niveau de couverture.

Lors de la souscription, comme pour des contrats classiques, les clients doivent s’assurer que figure bien des engagements de service, en particulier pour les secours informatiques :

• Le délai de reprise (Durée Maximale d’Interruption Acceptable ou DMIA) et les pertes de données (Perte de Données Maximale Acceptable ou PDMA) en cas de sinistre;
• Le plan de secours informatique du fournisseur incluant les modalités de gestion de crise ainsi que l’obligation de conduire plusieurs tests probants par an de ce plan avec la possibilité pour le client d’accès au rapport des tests ;
• Les pénalités financières et le droit de résilier le contrat (avec en particulier la récupération des données exploitables) en cas de manquement aux engagements.

Le secours informatique du IaaS/PaaS, une mise en oeuvre et une responsabilité du client

Le IaaS (Infrastructure as a Service) est une offre standardisée et automatisée de ressources de calcul, de moyens de stockage et de ressources réseau détenus et hébergés par un fournisseur et mis à disposition au client à la demande. L’offre PaaS (Platform as a Service) est similaire à celle du IaaS, à la différence près qu’elle ne concerne que les infrastructures applicative (définitions Gartner) Contrairement au cas du SaaS, le secours reste sous la responsabilité du client dans les deux cas : les fournisseurs IaaS/PaaS mettent à disposition des ressources dans différents datacenters et le client est responsable de l’usage et de la configuration qu’il en fait. Deux solutions s’offrent aux clients utilisant ces services : confier à un prestataire son secours ou bien le gérer lui-même.

Avoir recours à un prestataire de secours, un marché peu mature

Les prestataires de secours dans le Cloud sont désignés par l’acronyme « DRaaS » pour Disaster Recovery as a Service. Initialement, les fournisseurs DRaaS proposaient d’assurer dans le Cloud le secours de votre SI « on-premise ». Mais ils proposent également aujourd’hui d’assurer le secours de vos infrastructures déjà dans le Cloud, AWS ou Azure par exemple. La maturité reste très variable selon les fournisseurs et le cloud utilisé. Certains fournisseurs DRaaS imposent que le Cloud de destination du secours soit le leur, ne permettant pas ainsi de couvrir le secours de service PaaS.

Comme avec le SaaS, pas de garanties incluses par défaut quant aux pertes de données ou au délai de reprise, il faut les négocier. Les fournisseurs promettent de pouvoir s’adapter aux exigences du client ! Pour s’assurer que le secours fonctionne, le client doit prévoir la réalisation régulière de tests probants du secours (recommandation d’une fois par an).

Réaliser soi-même son secours en utilisant les outils proposés par le fournisseur

Comme sur une infrastructure « on-premise », il est nécessaire de réfléchir et définir sa stratégie de secours dès la conception. Cette stratégie doit intégrer la capacité de réaliser des tests probants permettant d’assurer un niveau de confiance suffisant dans son plan.

La mise en place est simplifiée par les outils mis à disposition par les fournisseurs Cloud et la forte standardisation des environnements Cloud. Les grands acteurs publient dans des livres blancs les grandes lignes directrices pour mettre en place un tel projet (par exemple AWS ou Azure).

Les concepts des stratégies du secours informatique restent proches de celles pour les datacenters on-premise.

On peut en dénombrer quatre principales :

• la sauvegarde et restauration: simple sauvegarde des données et images des machines sur un site distant, restaurées en cas de sinistre ;
• la veilleuse: réplication des bases de données et mise à disposition des machines sous forme d’images prêtes à être démarrées en cas de sinistre ;
• le secours à chaud: réplication complète du site primaire (données et machines), le site de secours est sous-dimensionné en termes de performances et est prêt à monter en charge en cas sinistre ;
• le multi site (ou actif-actif): les deux sites sont identiques et se partagent la charge des utilisateurs. En cas de sinistre, le site restant peut monter en charge pour accueillir la totalité des utilisateurs.

Des solutions hybrides pouvant mieux s’adapter aux exigences de délai de reprise, coût et complexité de la solution peuvent être envisagées.

Le véritable apport du Cloud pour le secours concerne les nombreux outils mis à disposition simplifiant la mise en œuvre et le déclenchement.

La réplication des données est ainsi simplifiée pour les options de géo-réplication asynchrones (plusieurs copies répliquées dans d’autres régions). La PDMA est variable en fonction des types de données et des outils proposés. Au-delà de cette option, une redondance locale des données est presque systématiquement incluse.

La forte standardisation permet également d’automatiser la reprise : les scripts ou API mis à disposition par les fournisseurs permettent d’automatiser le déploiement des infrastructures, le redimensionnement des instances en fonction de métriques précédemment définies, la répartition des charges et du trafic ou, l’adressage IP etc… afin d’accélérer de façon significative l’activation d’un site de secours.

Les outils de surveillance et alerte qui sont également proposés visent à faciliter le Maintien en Conditions Opérationnelles (MCO) du secours et peuvent être utilisés pour détecter au plus tôt un incident voire, dans certains cas, automatiser partiellement le déclenchement du secours.

Enfin la capacité à provisionner des nouvelles ressources en quelques minutes permet de limiter l’OPEX. A stratégie équivalente, il est ainsi possible d’avoir des gains de 40 à 70% sur le coût du secours !

Vers une plus grande prise en charge par le fournisseur ?

Azure prévoit une option, courant 2017, pour assurer le secours des machines virtuelles hébergées au sein de leur plateforme via la complétion de leur service « Site Recovery ». En effet, « Site Recovery » propose à l’heure actuelle de prendre en charge le secours de site traditionnel en utilisant le cloud Azure pour accueillir le site secondaire, mais Microsoft souhaite étendre ce service au secours de leurs propres infrastructures. Cet outil permettrait un déploiement automatique du site secondaire (de type actif-passif), une réplication automatique des données et une mise en place de tests facilitée.

Cette option est passée en « public preview » fin mai 2017. Un projet équivalent n’est pas d’actualité chez les autres principaux fournisseurs IaaS/PaaS.

Le cloud face au risque systémique des fournisseurs

Le secours informatique des services hébergés dans le cloud s’aborde différemment selon le type de service utilisé. Le secours du SaaS doit être géré contractuellement et est sous la responsabilité du fournisseur tandis que le secours du IaaS/PaaS, simplifié par les outils, reste sous la responsabilité du client.

Le risque de défaillance généralisé d’une région d’hébergement d’un fournisseur existe comme le montre les derniers incidents. Même si aujourd’hui, les incidents ont été de courte durée ou avec des impacts fiables, une défaillance généralisée ne peut pas être ignorée. Reste donc à traiter la problématique de cyber-résilience. L’utilisation d’un 2^ème fournisseur cloud permet de couvrir le risque de destruction ou d’indisponibilité majeure des infrastructures du premier. Cette solution reste très complexe car la portabilité d’un fournisseur à un autre est délicate. Pour l’instant, peu d’entreprises s’y sont risquées, même si l’on peut citer l’exemple de Snapchat qui utilise le cloud Google pour sa production et prévoit d’utiliser celui d’Amazon pour son secours d’ici à 5 ans.

Cet article Le Cloud, la fin ou renouveau du secours informatique ? est apparu en premier sur RiskInsight.