Is the tiering principle promoted for on-premise infrastructure applicable to the cloud?

Evolution of the Security Model

In on-premises Active Directory environments, infrastructure security generally relies on strict segmentation into three tiers (T0, T1, and T2). This allows for the isolation of critical administration systems (T0), servers (T1), and user workstations (T2) in order to limit propagation risks.

This hierarchical and perimeter-based organization is inherent to the AD world and cannot be directly applied to the cloud for the following two main reasons:

• Portals are centralized: A wide variety of administrators with different rights.
• The boundary between administration levels is more complex: The principle of granular permissions, whether Role-Based (RBAC), Attribute-Based (ABAC), or conditional (location, risk, compliance, authentication methods, etc.) allows for very precise access configuration, but it complicates and obscures the global view of permissions.

To address this new paradigm, Microsoft published its Enterprise Access Model (described here), highlighting three main planes: the Control Plane, Management Plane, and Data Plane.

This model retains “cascading” criticality but simplifies it with:

• the 3 tiers into 2 access types: administrator vs. user;
• the administration flows into portal access;
• the server’s criticality is centralized within the Data plane.

Below is a comparative illustration between the old and the new model:

This new model particularly highlights 3 elements:

• User identity: privileged access vs. user access;
• Data and services: at the expense of servers;
• The method of access to web administration portals.

The inversion of importance between “servers” and “web portals” abstracting Active Directory is a radical change.

However, very few (if any) large organizations are at this stage of abandoning their “legacy” IS; a large part will be in a transitional state where the information system has been virtualized on a cloud in order to move away from its datacenters, but whose administration methods have remained the same.

These companies must deal with an obsolete tiering model and an Enterprise Access Model disconnected from current security risks and needs.

For the remainder of this article, we will take as an example the Tartampion company, which has just completed a 3-year Move-to-Cloud program on AWS. The outcome is as follows:

• A Landing Zone was created, applications already on AWS were integrated into it
• Given the lack of time and resources, a major part of the IS was incorporated via lift and shift, including business, network, bastion, and AD solutions.
• The Data Centers were closed

A problematic hybrid and virtualized IS

According to the EAM, Azure and AWS portals are displayed at the same level (the management plane) at the T1 tier, without any other form of distinction. However, these 2 cloud environments are in themselves the support for numerous IS, used by multiple collaborators with very varied levels of rights and impacts.

To illustrate the previous points, let us set aside the Digital Workplace aspect (O365 suite) and take 3 AWS accounts from a Tartampion Landing Zone, supporting different infrastructure services:

Based on the framework proposed by Microsoft, these three AWS accounts should belong to the Management plane with a T1 security level. However, in the event of a compromise of one of the 3 accounts by an attacker, the impacts would be very different.

If the Landing Zone is correctly implemented, the compromise of a Sandbox account would have very little impact, whereas that of the Master Account would lead to the compromise of all underlying accounts and resources.

A more adequate example of segmentation would be the following:

Microsoft’s Enterprise Access Model is a macroscopic framework that allows for initiating a baseline for cloud service segmentation, but which remains to be adapted according to the criticality of the concerned IS.

How can it be made relevant? To answer this, it is necessary to understand the attack scenarios exploiting cloud services.

The cloud from an attacker’s perspective

5 cloud principles facilitating attacks

Firstly, public cloud administration panels are exposed to the Internet by default, unlike sensitive IS resources. Thus, successful phishing very likely leads to access to the cloud.

Secondly, companies today have hybrid organizations (on-premise and cloud):

• Cloud infrastructures are connected to the rest of the on-premises IS;
• Workstations can also be hybrid and managed by a cloud service like Intune. Permissions to use this service are managed in Entra ID;
• Identities are often synchronized accounts, this also applies to administration accounts.

Hybrid organizations can facilitate lateral movement between the cloud and on-premise environments.

Thirdly, identity management is very complex with different scopes. For example, Entra ID allows managing access to Azure and M365 for users, as well as for applications and service accounts.

In addition, cybersecurity concepts related to the cloud are still relatively new and unfamiliar to certain “legacy” teams, such as the SOC/CERT, network, etc. The most sensitive cloud resources are not systematically identified, protected, and monitored.

Finally, even if native detection mechanisms are present, they are not always interconnected with SIEM/SOAR, which slows down response capabilities. Moreover, a recent Purple Team operation conducted on Azure and AWS infrastructure confirmed that native detection tools have limited detection capacity. This is an observation also found in Red Teams since, with an “OpSec” approach, cloud detection tools are rarely able to identify an ongoing attack.

Feedback from our penetration tests & Red Team

Derived from recent Red Team operations, these cloud-specific attack paths demonstrate the impact and the ease with which it is possible to escalate privileges to obtain highly permissive access:

The first scenario, carried out on AWS, is described below; the other two were analyzed in a series of Risk Insight articles available here.

Reconnaissance and Initial Access

Categories of employees are generally targeted in order to compromise a person with interesting rights in the IS (Developer, Support, OPS…). A frequently used method is phishing. Current phishing mechanisms can bypass the use of complex passwords and most MFA (Multi-Factor Authentication) methods.

Privilege Escalation and Lateral Movements

In the first scenario, a compromised developer possessed access to a Citrix farm. Citrix environments are not simple to completely harden, and a few breakout vulnerabilities allowed the Red Team to gain access to the underlying server.

Information gathered on the machine indicated that the server could be hosted on AWS. This was verified by trying to access the server’s AWS metadata: the instance had rights on the client’s AWS account. The Citrix virtual machine possessed the “AmazonEC2FullAccess” role allowing it management actions on EC2s in the same AWS account.

Using the AWS CLI, the other EC2s were listed. A Domain Controller was present in this AWS account. It is a common practice to regroup services intended to be used by several projects into a single account, generally called “Shared Services”. It is nevertheless recommended to verify that the criticality of shared services is homogeneous to be able to apply adequate hardening on the account or separate them into several environments.

Actions on trophies

From the Citrix server AWS role, a snapshot of the domain controller was taken and then downloaded. Domain controller backups contain all the machine’s files, including the most sensitive files like the ntds.dit database, which contains the information and secrets of all domain users. The exfiltration of this database translates to the total compromise of the concerned AD domain.

This scenario illustrates one of the attack paths that were exploited during Red Team operations, facilitated by the lack of visibility regarding the impacts that a compromised resource hosted on the cloud can have.

Faster and stronger impacts

Attacks already possible on an on-premises IS can be reproduced and even accelerated thanks to cloud features. For example, the encryption of S3 buckets (file storage service) using a KMS (encryption) key from another AWS account mimics massive data encryption, or the use of the “lifecycle” feature allows for the deletion of all objects in less than 24 hours, regardless of the amount of data.

New attacks have also appeared, such as “Subscription Hijacking” which allows transferring an Azure organization’s subscription to another and thus stealing all the data it contains while preventing remediation actions. This attack is achievable in a few clicks from the Azure web interface.

Identification and protection of the cloud trust core

Identification

The trust core adopts an approach focused on asset prioritization, which differs from the tiering model or Microsoft’s Enterprise Access Model. Unlike these models which offer a predefined segmentation, there is no universal grid: each organization must identify for itself which resources deserve the highest level of protection. The idea is to establish a restricted circle of critical resources (whether cloud or on premises) and then deploy decreasing levels of protection as one moves away from this core.

The identification of the trust core relies on two main criteria:

• Business Criticality: these are the resources that concentrate the value and business continuity of the company. If they were to be lost or compromised, the consequences would be immediate for daily operations and financially. A SharePoint environment containing intellectual property / patents is a common example;
• IS Criticality: these are the resources that ensure the administration of the information system and which possess a high level of access. Their compromise would have a major impact on the entire IS and would allow for the business impact previously mentioned. Here we find domain controllers or cloud IAM services like Entra ID and AWS Identity Center.

This mapping is never totally clear-cut. For certain elements, the posture to adopt remains vague; two examples illustrate this well:

• EDR: an obvious security element of an IS, systematically deployed on both workstations and cloud and on-premises servers, its administration console is increasingly exposed to the internet, and allows executing arbitrary commands on the devices equipped with it.
• CI/CD pipelines: a clever but complex agglomeration of applications calling each other, whose access (the code repository: GitLab, GitHub…) is accessible by all collaborators and the runner permissions are very often administrator over the entire cloud infrastructure. Out of all Red Teams conducted in 2024 & 2025, 80% exploited vulnerabilities associated with these solutions to progress in their operation or even obtain compromise trophies through these means.

In order to identify the center of the trust core, which we will call the security foundation, we can revisit the precepts of the old T0: the compromise of one of its elements would probably lead to that of the others, and by cascade, of the major part of the IS.

Assuming that your applications apply correct inter-user segregation (all of your SharePoint sites are not accessible by everyone, are they?), references to the next applications should be understood as administrator / super-user access to them, and not simple user.

Here is one possible representation of a hybrid trust core:

In this representation, on the on-premise side, we can observe:

• The T0, with its domain controllers, ADCS, and potentially the PKI, the bastion, the EDR console…
• The T1, integrating additionally high-impact business applications.

And on the cloud side, we find:

• At the core, the Control Plane (AWS Orga & Identity Center, Entra ID) as well as the Landing Zone modules supporting T0 (if part of T0 is hosted in the cloud);
• Moving outward, the various administration consoles for productivity suites, and for infrastructure or application management.

When establishing this diagram, it is important to keep in mind that:

• IT serves the business, and even though the central zone of the trust core is mainly occupied by technical components, critical solutions should be included;
• Dependency/compromise chains have a significant impact on architectural choices: positioning an AD on AWS, or deploying an EDR on an AD can suddenly create numerous paths for compromise and pivoting between the 2 worlds.

Finally, building a trust core cannot be limited to a static classification logic. It must rely on an approach that evaluates the criticality of each asset and the risk it introduces (a software development company will surely not position its Git at the same level as a civil engineering company).

Protection of the cloud trust core

The security of the trust core will rely on the two traditional risk factors:

• Reduce impact: How to prevent a compromised or malicious user from connecting to cloud portals via a browser and performing sensitive actions in a few clicks, such as backing up a domain controller hosted on a VM or deleting production data backups?
• Reduce probability: How to reduce the risks of illegitimate access from a session cookie stolen via phishing, workstation compromising, or user password reuse?

Protection of the cloud security foundation

Regarding the cloud “security foundation,” it is possible to prioritize environments by criticality according to this macroscopic scale:

Depending on the teams involved and the complexity of including them in a particularly high protection level, some organizations choose to exclude environments whose compromise would not allow for dangerous lateral movement, such as those for FinOps, detection, the Digital Workplace…

Securing the cloud security foundation relies on 2 main points:

• Impeccable hygiene: streamlined IAM configuration, least privilege strategy, deployment procedures, limitation of resources to the strict minimum…
• A passive / active security layer: deployment of policies (SCP on AWS, Policy on Azure) explicitly forbidding certain actions, or the manipulation of certain resources, and detection rules to trigger an alert in the event of a policy modification or the occurrence of one of its protected events.

These policies can be effectively associated with a tagging strategy to apply, in addition to the RBAC (Role Based Access Control) model, an ABAC (Attribute Based Access Control) model.

For example, it is possible to tag different resources with a “tiering” key and a value between “T0”, “T1”, “T2” and then deploy this set of strategies:

• Prohibit any action targeting a resource tagged “tiering” by an identity whose own tiering tag value is not equivalent;
• Prohibit the manipulation of tiering tags, except for a specific role.

And that is how, with a few tags and 2 SCPs, it is possible to replicate the Microsoft tiering model (some exceptions may occur).

Protection of identities and access

To protect users, 3 hardening themes can be implemented:

• Identity: With which account does the user connect to cloud administration interfaces? How are rights obtained?
• MFA: Is the identity protected with multi-factor authentication resistant to phishing attacks?
• Origin: From which platform does the user connect to cloud administration interfaces? Is the platform managed, and healthy?

Several levels of protection are conceivable in order to protect cloud administrators:

To protect the restricted trust core, represented by the triple padlocks, it is recommended to implement the most robust authentication factors. This includes the use of a dedicated account for cloud administration, the activation of physical multi-factor authentication (example: FIDO2 security key), and the use of a workstation specifically reserved for operations on this trust core (this last one is not often implemented).

For resources further from the center of the core of trust, symbolized by the double padlocks, a hardened but proportionate security level can be applied, in order to strengthen protection to control costs and reduce excessive constraints on the users concerned.

Ultimately, the most secure methods are also those that imply the most constraints for the people concerned, usage must be controlled (limiting day-to-day operations) and emergency situations considered.

Repeat Operations

At the end of the identification and protection phases, resources will be distributed across the different layers of the core of trust.

To verify the proper implementation of the core of trust, an audit can be conducted to verify the proper protection of the critical resources that compose it.

An information system is always evolving, but the first two phases will have been performed at a given moment. New critical resources may be added, others modified or even deleted. It is essential to regularly re-evaluate the IS and update the distribution of resources within the core of trust.

In conclusion, information system security now operates within a context of increasing complexity and strong diversification of infrastructure components and services.

In this context, it appears increasingly complex to define a universal security model. Certain frameworks retain all their relevance within well-identified perimeters: tiering remains a reference for securing Active Directory, just like the EAM for cloud environments strongly centered on the Microsoft ecosystem. Nevertheless, these models quickly reach their limits as soon as one moves away from these specific use cases.

For the majority of information systems, an approach based on risk analysis therefore stands out as the most relevant. Identifying a core of trust, clearly defining critical assets – the crown jewels – and deriving security measures from these elements allow for building a more pragmatic security posture, adapted to the reality of the IS and capable of evolving with it. This logic, less normative but more contextualized, undoubtedly constitutes one of the major levers for reconciling security, agility, and sustainability of information systems.

Cet article Cloud Security: Adapting to a new reality est apparu en premier sur RiskInsight.

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

IT support compromise 

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

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

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

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

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

Control Plane Admin’s Laptop compromise 

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

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

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

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

CI/CD compromise 

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

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

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

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

Synthesis 

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

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

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

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

Thank you to Louis CLAVERO for contributing to this article.

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

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

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

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

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

Understanding Entra ID, Active Directory, and Azure Permissions 

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

Figure 1: Active Directory and Entra ID key differences

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

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

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

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

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

The most privileged roles in both systems are: 

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

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

A real-life global Entra ID compromise 

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

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

1 Compromising a helpdesk account 

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

2 Initial Attempt to Reset Global Administrator Account

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

3 Targeting a High-Value Standard User Account

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

4 Searching the available subscription 

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

5 Utilizing Intune Administrator Privileges 

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

6 Compromising the Global Administrator Account

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

Figure 2: A global Cloud compromise path 

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

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

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

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

Figure 4: The Enterprise Access Model 

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

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

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

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

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

Synthesis 

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

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

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

 Thank you to Louis CLAVERO for contributing to this article.

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

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.

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.

First of all, it is important to know that cloud security is particularly different depending on the type of cloud and the way cloud services are consumed. Among these services, there are three main categories: SaaS (Software as a Service), PaaS (Platform as a Service) and IaaS (Infrastructure as a Service).

Overall, cloud security is quite distinct between the PaaS / IaaS part and the SaaS part. This is materialized by the principle of the shared responsibility model. When consuming a cloud service, the customer will have access to a certain perimeter with a certain number of data layers or infrastructure depending on the category of cloud service.

This model makes it possible to determine on which perimeter of the service the responsibility of the cloud provider or that of the customer is engaged. The security part will also be shared on the layers of data on which the customer will have the responsibility, it thus requires the customer to ensure the security of its perimeter.

In the context of SaaS, to give an example, Microsoft Office 365 is a service where the customer integrates his data and does not have access to all the lower layers of the service. The customer has little access to the configuration of the service and therefore on the security, they can contractually require a level of security from the provider who will have control over the configuration of the service.

On the contrary, on PaaS or IaaS solutions, the customer will have access to the lower layers and will therefore be responsible for configuring them to ensure their security if they are not managed by the service provider. The customer can still require certain elements but the customer will be responsible for a significant part of the configuration and secure use of the cloud service.

The security of the cloud raises a particularly contractual issue since it is not the customer’s service itself but that of a third party. This raises security issues, and in particular the question of what the customer can demand of its supplier in terms of data security. These requirements are likely to change depending on the nationality of the supplier.

This security issue also leads to organizational changes. The consumption of cloud services must involve rethinking the organization of the IT department and the way it operates in the broadest sense, with security included in the new processes. In this agile approach, security must also be included with DevSecOps-type practices.

What are the market trends?

Just a few years ago, customers were reluctant to move towards cloud solutions, but today, the subject has gained consensus and is becoming more and more important. One of the major factors in its development is the Office 365 solution from Microsoft Azure.

The market trend on the customer side is to launch large cloud migration programs in order to be supported in this process, especially if they have to use single or multiple providers. The topic of multi-sourcing is particularly important at the moment. Customers are also asking how to organize their IT departments to adopt agile and DevOps principles to achieve their transformation in an intelligent way. The goal, is not to “lift and shift” an existing on-premise application without making any changes or redesigns by integrating it directly into the cloud.

Customers are realizing that managing their information systems involves very high costs and that this does not correspond to their core business. The cloud offer allows companies with this expertise, the service providers, to carry out the migration of these cloud platforms. This allows the customer to focus on their business processes and reduce the time to market, the time it takes to realize an initial idea and deliver a finished product to consumers.

In terms of security, a trend for large programs is to accompany cloud migrations in a secure manner. This involves several elements:

• Support in contracting with the cloud provider regarding the shared responsibility model and what the customer can or cannot migrate;
• On the organization of the IT department to become DevSecOps, an approach that allows the integration of security in the entire life cycle of projects, from development to implementation, using flexible methods and the DevOps approach ;
• For more advanced customers who have already started a migration and who already have a multicloud, the objective is to accompany them in the harmonization of these different cloud platforms, in particular security.

The trend among cloud security vendors is to offer multi-cloud solutions, but at the same time to compartmentalize the different types of cloud (IaaS, PaaS, SaaS) in order to offer specialized tools. The latest trend in the market is the so-called CSPM (Cloud Security Posture Management) tools, which enable compliance checks to be carried out on multi-cloud platforms. In terms of encryption, which is a sensitive issue for our customers, the dynamics of multicloud support are based on service offers such as HSMaaS or KMSaaS. These enable the provisioning of keys belonging to the customer – of the BYOK type – that can be used from one cloud to another.

From a technological point of view, the underlying trend remains serverless. This is a cloud development model that allows developers to create and run applications without having to manage servers. Containerization and Dockers or Kubernetes technologies are currently being deployed on a large scale by our customers, leading to major security issues.

What are the difficulties our clients encounter on the topics covered? How is this a real challenge?

Customers with low maturity on the subject who are reluctant to migrate to the cloud are generally entities that handle data with a very high level of confidentiality (e.g. healthcare providers, military, etc.). They wonder how they can trust an American company. Currently, when we talk about the cloud, we are mainly talking about American players: Microsoft, Amazon and Google, which own almost the entire public cloud market.

To answer this question, we emphasize that when you use a cloud provider, you must have total confidence in it. The objective is to define the contractual part upstream of the customer’s migration to ensure total confidence in the supplier. This can be regarding access to the data that will be transmitted. This can be done through a contractual guarantee, security controls, etc.  Note that encryption will never prevent the provider from accessing the data, so it is important to ensure that the cloud is secured against real threats.

Of course, there is a very small risk that the provider can access your data, since it is transmitted to them, but the risk is negligible compared to the risk as a customer of misconfiguring the cloud service. Thus, the main security incidents in the Cloud concern the theft of data exposed publicly through storage services (S3 bucket, Azure storage, etc.). The provider’s responsibility is not engaged in these cases since it is up to the customer to guarantee the correct configuration of the PaaS services he uses so that they are used in private and not exposed mode.

This obviously requires an effort on skills to consume cloud services in an intelligent way while securing it.

For more advanced customers, vendor locking is a dominant issue. If the cloud provider with which the customer is collaborating goes out of business or is unavailable for a certain period of time, the customer loses access to its IS. This is why customers are turning to multi-cloud strategies.

How can we address these issues and how can Wavestone help?

At Wavestone, we believe that the cloud can be a facilitator for IS security. A gateway to build an IS on a sound foundation and rely on technologies that work. You can take advantage of this to put security in the right place from the start, and one of the keys to achieving this is automation.

Automation must be implemented in deployment, infrastructure and security to achieve true value. If the customer sets the right security rules and these technical rules are translated into the integration and deployment chains (CI/CD), the customer will have the guarantee that the deployment of its resources and infrastructures will be secure as soon as they are deployed.

Wavestone also assists clients in contracting with cloud providers. We help our clients build landings zones, i.e. the basis of the security architects that will be deployed in the cloud. Our teams are embedded in cloud centers of excellence at our customers’ sites and work every day to secure cloud infrastructures. We also have the capacity to help our customers in their agile transformation, particularly on DevSecOps issues, in order to bring security closer to their projects.

The future of cloud security

The emerging trend of the moment is Zero Trust. This is a new security model that responds to the current challenges of cloud and mobility of people and data. The Zero Trust model aims at granting access on a need-to-know basis and thus putting security closer to the resources.

The objective is to put the user back at the center with the guarantee of the least privilege and to control access to a resource each time someone expresses the need for it. This verification will be done regardless of its origin even if it is an internal collaborator. Identity and authentication are at the center, as are the means of detection and control.

The definition of least privilege allocation algorithms and the systematic verification of each new entry request are vast topics around identity governance for our customers. Their technological translation, as with Azure AD to quote Microsoft’s technology, requires solid technical knowledge and change management support to be able to identify and configure the right authentication means (MFA, temporary rights allocation, etc.) and controls (Conditional Access Policy, sign-logs, etc.) available.

This model is particularly well suited for cloud use since most public cloud providers allow the use of more reliable and configurable technologies than on-premise to manage identities, authentication and detection.

Cet article Cloud security challenges and trends, interview with Vincent Ferrie 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.

Microsoft fait partie de ces acteurs de l’IAM pour le cloud. En raison de son rôle déterminant dans le SI « On-Premises » des entreprises, nous allons nous pencher de plus près sur sa solution : Windows Azure Active Directory (WAAD).

WAAD : une solution IAM-as-a-Service pour le cloud

Contrairement à ce que pourrait indiquer son nom, la solution Windows Azure Active Directory n’est pas un Active Directory hébergé dans Azure, la plate-forme cloud de Microsoft.

Officiellement lancée le 8 avril 2013, WAAD est décrit par Microsoft comme « une solution complète et sécurisée pour la gestion des identités et des accès dans le cloud. Elle combine des services d’annuaires principaux, une gouvernance des identités avancée, une gestion et une sécurisation des accès aux applications ».

Microsoft propose donc WAAD comme solution d’IAM-as-a-Service permettant, entre autres, de couvrir les applications hébergées dans le cloud. Contrairement à son approche « brique à brique » traditionnelle pour les services IAM On-Premises, dans laquelle chaque service est fourni par un produit spécifique, Microsoft adopte là une approche plus globale comme le démontre le tableau suivant :

Windows Azure Active Directory permet ainsi aux entreprises de :

• Étendre au cloud les identités gérées localement au sein d’un Active Directory On-Premises ;
• Gérer les identités et accès depuis le cloud, à la fois pour les applications cloud de Microsoft (Office 365, Dynamics CRM Online, Windows Intune), pour un nombre important d’applications SaaS du marché, mais également pour toute application que l’entreprise raccorde à WAAD ;
• Apporter une connexion unique (SSO) aux applications hébergées dans le cloud, voire aussi, dans certains cas, aux applications On-Premises ;
• Protéger les applications les plus critiques avec une solution d’authentification forte.

Notons que certains services proposés sont antérieurs à la date de lancement officielle puisqu’ils ont été introduits dès 2010 pour offrir les fonctionnalités de gestions des identités et des accès à Office 365. C’est ainsi que Microsoft a pu afficher les chiffres de 265 milliards d’authentifications réalisées et de 2,9 millions d’organisations clientes à la date de lancement de la solution.

Comment mettre en œuvre WAAD ?

Deux modes d’implémentation sont envisageables en fonction des usages que l’entreprise souhaite couvrir.

La première possibilité est une implémentation en stand alone, sans aucun lien avec les annuaires ou briques d’identités présentes dans le SI de l’entreprise. Cette absence de lien avec les infrastructures de l’entreprise permet de bénéficier rapidement d’une solution IAM pour le cloud. Néanmoins, cela impose de gérer spécifiquement le cycle de vie des identités (créations, modifications, suppressions), des mots de passe (initialisations, réinitialisations) et des habilitations (affectations de groupes).

La seconde possibilité consiste à « étendre les identités locales vers le cloud ». Ce type d’implémentation permet de déployer simplement des applications cloud et ce de façon transparente pour les utilisateurs. Pour cela, une synchronisation unidirectionnelle entre un Active Directory géré localement et WAAD est mise en place (via l’outil DirSync). Dès lors, les processus de gestion du cycle de vie des identités déjà en place au sein de l’entreprise se retrouvent étendus au cloud.

Et afin de permettre un accès sans couture aux utilisateurs à la fois aux applications cloud et aux applications hébergées dans le SI de l’entreprise, il est nécessaire de disposer d’une infrastructure de fédération des identités On-Premises.

Par ailleurs, il est possible d’utiliser un module d’authentification forte. Un téléphone est alors indispensable quel que soit le mode d’authentification choisi : One-Time Password par SMS, OTP par appel téléphonique ou encore notifications sur smartphone. Notons que ces fonctionnalités reposent sur la solution de l’éditeur PhoneFactor, racheté par Microsoft en octobre 2012.

Rappelons que Windows Azure Active Directory reste une solution d’IAM pour le cloud parmi d’autres. Dans un marché où des mouvements sont à prévoir dans les mois qui viennent, on peut se demander quels sont les véritables bénéfices de ces solutions, et ce qui les distingue les unes des autres. Des questions qui seront abordées dans un prochain article…

Cet article Identité dans le cloud : le marché se structure, quid de l’approche de Microsoft ? est apparu en premier sur RiskInsight.

Des craintes à relativiser …

Disponibilité du Cloud

Chaque incident touchant l’un des grands acteurs du Cloud fait la « Une » de l’actualité, mettant sur le devant de la scène la question de sa disponibilité.

Il s’agit pourtant d’un faux problème : les taux de disponibilité des services Cloud sont souvent  supérieurs à ceux des systèmes internes des entreprises. La situation, d’un point de vue médiatique, est comparable à celle des accidents aériens : bien que rares, ils choquent l’opinion et intéressent les journalistes beaucoup plus que les accidents de voiture, qui font pourtant annuellement plus de victimes. La disponibilité n’est donc pas un risque inhérent au Cloud. Il reste néanmoins une spécificité à laquelle il faut prêter attention : la connectivité avec le fournisseur Cloud. Si celui-ci utilise internet comme unique moyen d’accès à ses datacenters, le risque d’indisponibilité de cet accès et d’internet en tant que tel doit être pris en compte.

 Confidentialité des données

Mes données sont-elles isolées de celles des autres clients ? Les administrateurs peuvent-ils y accéder ? Il est important de remettre ces craintes en perspective. D’une part, toutes les données de l’entreprise ne sont pas critiques en termes de confidentialité. D’autre part, si ces questions se justifient dans certains cas, elles ne sont pas nouvelles et ont trouvé leurs réponses il y a déjà plusieurs années, à l’heure des premiers contrats d’externalisation IT ou de l’emploi d’administrateurs prestataires. Les principales différences résident dans l’éloignement potentiel et le degré de contrôle possible du fournisseur.

La confidentialité des données vis-à-vis des Etats reste un sujet plus complexe à adresser. Ces derniers disposent en effet de textes leur permettant d’accéder aux données présentes dans les systèmes hébergés sur leur sol. Les USA font souvent figure d’épouvantail, leurs textes ayant en plus une portée extraterritoriale (Patriot Act, FISAA). Ces textes permettent à la justice et aux forces de l’ordre américaines d’accéder aux données manipulées par des sociétés de droit américain quel que soit le client et la localisation des données. Le risque est donc que des Etats aient accès aux données dans un objectif d’espionnage économique. Ce risque est réel comme l’illustrent les révélations sur les moyens dont dispose la NSA. Mais là encore, la portée du risque est à mesurer. Seules quelques données ont un niveau de sensibilité élevé : étatiques (administrations, défense, etc.), stratégiques pour l’entreprise dans un environnement à forts enjeux concurrentiels, géopolitiques, etc.

 Conformité réglementaire

La conformité réglementaire (PCI-DSS, LIL…) des offres Cloud, notamment en matière de protection des données à caractère personnel est également un sujet d’inquiétude. La situation reste très variable en fonction des acteurs, même si des réponses techniques (localisation des données, chiffrement…) ou juridiques (Safe Harbour, contrat type de la commission européenne…) existent aujourd’hui chez la plupart d’entre eux.

… car la sécurité est au cœur de la préoccupation des fournisseurs

Très visibles et régulièrement attaqués, les fournisseurs majeurs de Cloud mettent souvent en place des équipes dédiées pour assurer la sécurité de leurs services. La sécurité est même devenue pour certains d’entre eux l’un  des principaux arguments de vente.

Attention cependant : tous n’assurent pas le même niveau de sécurité. Il reste donc important de préciser avec le fournisseur les mesures incluses dès la signature du contrat, d’autant qu’il est difficile de faire évoluer les mécanismes de sécurité d’un fournisseur quand ceux-ci ne sont pas prévus initialement. Certains fournisseurs de solutions « SaaS métier » de taille petite et intermédiaire négligent parfois la sécurité : les audits et tests d’intrusion ont pour ce type d’offres une importance accrue.

Vers une coresponsabilité fournisseur / entreprise

Analyse de risque : passer de l’intention à l’action

Suivre une démarche d’analyse de risque est impératif pour lever les freins relatifs à l’adoption du Cloud. La finalité de l’analyse n’est pas d’interdire le Cloud par défaut mais plutôt d’identifier les données sensibles afin d’accompagner les projets de la manière la plus sûre et la plus pertinente. L’implication des responsables sécurité dès le démarrage des projets est donc essentielle. Ils doivent identifier les risques que l’on peut réduire par des moyens techniques et organisationnels, et ceux résiduels impossibles à couvrir. Aux Métiers et à la Direction de décider ensuite si ceux-ci sont acceptables ou non pour l’entreprise. Et de revoir si besoin le périmètre de la démarche Cloud.

Des contrôles à ne pas négliger…

Durant le projet ou en amont lors de la phase de choix des fournisseurs, il est recommandé de poser des questions précises sur les mesures de sécurité pour ne pas laisser place à des réponses ambiguës. Par exemple, beaucoup de fournisseurs mettent en avant leurs certifications.

Il convient de vérifier le type de certification et le périmètre concerné. Un certain nombre d’acteurs du Cloud acceptent d’ailleurs de fournir des détails sur l’architecture de leur solution, après signature d’un accord de non-divulgation. La capacité à répondre rapidement et de manière détaillée aux questions permet de se forger un avis sur la maturité de l’offre proposée.

En outre, la possibilité d’auditer le prestataire Cloud est un bonus à ne pas négliger. Accepter un audit est une preuve de transparence du fournisseur et de confiance en son niveau de sécurité. Même si les plus grands acteurs anglo-saxons s’y refusent, il est toujours utile de poser la question, notamment pour des acteurs de taille intermédiaire.

Des référentiels émergents

Un outillage commence à voir le jour pour aider les entreprises à évaluer les risques et le niveau de sécurité inhérent. En France, l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) a publié un guide pour accompagner les démarches de type Cloud computing. Au niveau européen, l’ENISA (European Network and Information Security Agency) fournit une analyse générique mais complète des risques liés au Cloud. Enfin, outre- Atlantique, l’association Cloud Security Alliance, qui regroupe les acteurs majeurs, a mis au point la Cloud Controls Matrix. Cette matrice permet de comparer de nombreux fournisseurs sur des critères de sécurité précis. Bien que fondée sur les seules déclarations desdits fournisseurs, elle peut s’avérer utile pour comparer les offres.

Le chiffrement : graal de la sécurité Cloud ?

Parmi les solutions techniques permettant de réduire les risques du Cloud, le chiffrement se positionne en tête. Et si aujourd’hui son utilisation nécessite souvent de donner les clés de déchiffrement au fournisseur, des innovations technologiques se profilent. Elles permettront de transférer et de traiter des données à distance sans jamais donner au fournisseur d’accès direct. Bien qu’encore expérimentales, ces techniques, rassemblées sous la bannière du chiffrement homomorphique, méritent qu’on les suive avec attention.

Ne pas mettre ses responsabilités dans les nuages

Contrairement à ce que trop d’entreprises pensent, leur responsabilité ne s’arrête pas une fois la solution Cloud mise en production. Si le fournisseur est tenu de respecter un certain nombre

de règles de sécurité, le maintien du niveau de protection dans le temps relève aussi de la  responsabilité de l’entreprise. Pour cela, les bonnes pratiques appliquées au SI d’entreprise doivent être transposées au Cloud : gouvernance de la sécurité (processus, sensibilisation des utilisateurs), administration fonctionnelle de la sécurité, configuration des options de sécurité avancées, restriction des droits requis par les utilisateurs, formation des administrateurs, revue régulière des paramètres de configuration… Ceci est particulièrement vrai pour la gestion des identités et des accès, élément clé pour garantir la confidentialité des données dans le Cloud.

Cet article Sécurité et Cloud, un mariage de raison est apparu en premier sur RiskInsight.

Pour autant, même une fois cette démarche menée à bout, plusieurs doutes persistent.

Si l’actualité récente a fait éclater l’affaire PRISM , la réalité des accès aux données est pourtant connue depuis de nombreuses années.

 Les risques d’accès aux données sont réels, depuis longtemps

Les quelques années de recul et d’expérience sur le Cloud montrent que les craintes quant à l’accès aux données hébergées à l’étranger sont justifiées.

L’exemple le plus souvent cité est celui du USA PATRIOT Act : sur requête du gouvernement américain et après contrôle par un juge, toute entreprise américaine, ou située sur le sol américain, ainsi que tout citoyen américain (où qu’il soit), se doivent de fournir aux autorités un accès aux données auxquelles ils ont accès. Dans le cas d’une entreprise de droit américain, l’obligation s’étend en dehors du territoire national : si ses infrastructures sont situées en Union Européenne, la loi s’applique.

Le Syntec Numérique a publié un éclairage intéressant sur le sujet en avril 2013. On y précise notamment  qu’un contrôle par un juge peut être réalisé avant la divulgation des données… Ou après, donc trop tard pour l’empêcher.

Cette loi pose donc  en théorie le problème de la confidentialité des données. Dans la réalité, ces craintes se justifient principalement si les données manipulées ont un niveau de sensibilité très élevé : étatiques (administrations, défense, etc.), stratégiques pour l’entreprise dans un environnement à forts enjeux concurrentiels, géopolitiques, etc.

Pour autant, et c’est un aspect moins connu, la majorité des gouvernements mondiaux disposent de prérogatives équivalentes. Le grand cabinet d’avocats Hogan Lovells a publié une étude à ce sujet en 2012, incluant notamment un comparatif des législations de 10 grands pays sur l’accès aux données Cloud : beaucoup (dont la France) disposent de prérogatives similaires, parfois plus larges et moins contrôlées.
Pourquoi alors se focalise-t-on généralement sur le USA Patriot Act ? Principalement car les acteurs majeurs du Cloud sont aujourd’hui américains,  donc soumis à la législation américaine.

Cependant, ne considérer que l’aspect strictement légal est encore trop réducteur : l’entreprise doit également se demander si le pays sur le sol duquel ses  données critiques sont hébergées a des intérêts allant dans le même sens que les siens.

Dans tous les cas, les conseils de juristes spécialisés sont indispensables pour avoir une position précise et adaptée.

 Les fournisseurs français de Cloud computing, solution du problème ?

Sur le papier, stocker ou traiter ses données chez un prestataire de droit français sur le sol français semble la solution idéale…  en théorie seulement.

En effet, de nombreuses fournisseurs français ont des centres de traitement et de stockage dans le monde entier… Même si vos données n’y sont ni stockées ni traitées, ceux-ci pourraient être connectés aux centres situés sur le sol français (et donc permettre d’y donner accès à distance).

Au-delà des données, se pose la question des équipes décentralisées : un Cloud hébergé en France, mais dont les équipes d’administration sont situées aux quatre coins du monde (par exemple pour fournir un support 24/7) doit également faire l’objet d’attentions.

Une fois encore, tous ces risques sont à relativiser : ils ne concernent que les données réellement sensibles.

Entre protections juridiques et solutions techniques, la bonne parade reste encore à trouver

Un moyen de se protéger des divulgations indésirables pourrait consister en l’ajout de clauses contractuelles interdisant à son fournisseur de le faire. Malheureusement, ce dernier risque de ne tenir aucun compte desdites clauses lorsqu’une demande officielle de son gouvernement lui parviendra. Pire, dans le cas des lois américaines, il peut lui être interdit d’avertir le propriétaire des données que celles-ci ont été transmises (il s’agit du principe de gag order).

Dans certains cas, il est possible de prendre certaines précautions très spécifiques. Nous conseillons parfois à nos clients de demander l’isolation de leurs données  dans le datacenter du fournisseur, dans une salle sous alarme dont seule l’entreprise détient la clé. Là encore, cela n’empêchera pas un accès aux données, mais permettra au moins à l’entreprise d’en avoir connaissance.

Une véritable solution pourrait provenir de la technologie : un chiffrement adéquat des données permettrait de s’assurer que même en cas d’accès aux données, celles-ci sont correctement protégées. Cela nécessite des technologies de chiffrement de confiance (par exemple en France, qualifiées par l’ANSSI), afin que les données soient sécurisées sur tout leur parcours : pendant leur transmission sur le réseau, au moment de leur utilisation, et lorsqu’elles sont stockées dans le Cloud.

À ce titre, le chiffrement dit « homomorphique » constitue une perspective d’avenir intéressante…

Cet article Cloud et sécurité : mythes et réalité (partie 2) est apparu en premier sur RiskInsight.

En particulier, la question de la protection des données transmises, traitées et sauvegardées apparaît comme cruciale. Ces points préoccupent aujourd’hui les experts techniques, les managers d’information, et parfois même les directions des entreprises.

Le Cloud est-il sûr ? Que risque-t-on en l’adoptant ? Comment y assurer la sécurité de ses données ?

Un service moins cher n’est pas forcément moins sécurisé

Il faut voir les risques liés au Cloud comme proches de ceux existants sur l’externalisation et la virtualisation avec en particulier la perte de contrôle de ses données et les risques liés aux technologies utilisées (virtualisation des systèmes et des réseaux, automatisation d’un certain nombre de tâches, etc.).

Pourtant, de manière générale, nous constatons en France que le niveau moyen de sécurité des services Cloud est au-dessus du niveau moyen de sécurité des entreprises. Plusieurs facteurs expliquent cela.

Le fait de fournir un service informatique à l’état de l’art (et donc sécurisé) est le métier des acteurs du Cloud. Chez la plupart d’entre eux, la mise en place et le respect des procédures de sécurité fait l’objet d’une attention particulière. Par ailleurs, ils proposent un service industrialisé à de nombreux clients : les bonnes pratiques exigées par l’un peuvent souvent être appliquées à tous.

Ces fournisseurs sont, enfin, plus exposés que la moyenne des entreprises, et ont de vrais enjeux en termes d’image : la découverte de faiblesses de sécurité amène en général à une correction rapide.

Inversement, si un mécanisme de sécurité n’est pas offert par un fournisseur (de base ou en option), il sera malheureusement difficile de l’obtenir : en sécurité comme pour les autres fonctionnalités, les offres Cloud manquent souvent de souplesse.

Attention cependant, contrairement à une idée répandue, toutes les offres Cloud ne se valent pas : de véritables différences peuvent exister d’un fournisseur à un autre.

Des outils dédiés existent pour évaluer ses risques de sécurité

D’un point de vue sécurité, la démarche est celle – classique – de l’analyse de risque. Le but est ici d’accompagner les projets de mise en œuvre ou de migration vers le Cloud, et pas de les interdire.

Dans le cas du Cloud, un outillage spécifique commence à apparaître pour réaliser cette analyse. En France, l’ANSSI (Agence Nationale de  la Sécurité des Systèmes d’Information) a publié  un guide¹ pour accompagner les démarches de type Cloud computing. Au niveau européen, l’ENISA (European Network and Information Security Agency) fournit une analyse² générique mais complète des risques liés au Cloud.

Outre-Atlantique, l’association Cloud Security Alliance regroupant les acteurs majeurs du Cloud a mis au point son outil Cloud Controls Matrix³, qui permet de comparer de nombreux fournisseurs sur des critères de sécurité très précis. Si elle est basée sur les seules déclarations desdits fournisseurs, cette matrice peut néanmoins s’avérer utile.

Les comparaisons théoriques  ne suffisent pas

Il est parfois difficile de distinguer ce qui est présenté de ce qui est fait en réalité en termes de sécurité. Plusieurs critères permettent d’évaluer les fournisseurs.

Ils peuvent tout d’abord se prévaloir de différentes certifications : ISO 27001 (très adoptée et quasiment obligatoire aujourd’hui) et ISAE 3402/SAE 16 (très adoptées également, requises pour les groupes cotés aux États-Unis, dans la ligne de SOX). Des démarches spécifiques existent aussi dans certains domaines, comme pour les données de santé en France, ou PCI-DSS pour les données de cartes bancaires.

Pour autant, ces certifications ne sont pas toujours une assurance d’un niveau de sécurité adapté. Lors de la phase de choix des fournisseurs ou durant le projet, il apparaît nécessaire de poser des questions très précises, sans laisser de place à des réponses trop larges ou ambiguës.

Un certain nombre d’acteurs du Cloud accepteront d’ailleurs de fournir des détails sur le fonctionnement de leur solution, après signature d’un accord de non-divulgation. Des visites de datacenters sont aussi toujours très instructives, et permettent parfois de se forger un avis sur la maturité du niveau de sécurité de l’offre proposée.

Certains fournisseurs sont réticents à fournir des informations très précises préalablement à la signature du contrat, ils peuvent alors proposer l’ajout d’une clause permettant de dénoncer le contrat ultérieurement. Mais attention à ce mécanisme, une fois la mise en œuvre démarrée, faire marche arrière est presque impossible…

Enfin, la possibilité de contrôler le prestataire Cloud est un critère intéressant. Sa capacité à accepter un audit diligenté par ses clients est en effet une preuve de transparence, voire de confiance en son propre niveau de sécurité.

¹ : ANSSI – Externalisation, Cloud Computing : maîtriser les risques pour les systèmes d’information (http://www.ssi.gouv.fr/externalisation/)  

² : ENISA  – Cloud Computing Security Risk Assessment (http://www.enisa.europa.eu/activities/risk-management/)

³ : Cloud Security Alliance – Cloud Controls Matrix (https://cloudsecurityalliance.org/research/ccm/)

Cet article Cloud et sécurité : mythes et réalités (partie 1) est apparu en premier sur RiskInsight.

Le chiffrement « classique » : une réponse partielle aux inquiétudes

Dans ce cadre, l’envie de conserver une mainmise sur les données de l’entreprise émerge rapidement, et les technologies de chiffrement font leur retour sur le devant de la scène. L’idée serait de traiter au niveau du cloud des données chiffrées afin de limiter les risques d’écoute. Ceci est possible par exemple pour un service de stockage en ligne. Les données sont chiffrées dans l’entreprise puis envoyées sur le serveur, lors de l’accès elles sont déchiffrées localement par l’utilisateur. Cependant se pose rapidement la question de la capacité à traiter les données, en effet les attentes métiers vis-à-vis du cloud vont bien au-delà d’un simple espace de stockage !

Il est alors possible d’envisager un chiffrement uniquement au moment du stockage chez le fournisseur. Lors d’un traitement interne au service cloud (recherche de données, édition de bulletin de paye, calcul scientifique…) le fournisseur pourrait déchiffrer les données, réaliser le traitement puis chiffrer à nouveau. Cette méthode fonctionne techniquement mais elle ne répond pas aux multiples interrogations. En effet, pour que ce mécanisme fonctionne, le fournisseur doit disposer des clés de chiffrement. Mais qui nous assure alors qu’elles ne sont pas utilisées à mauvais escient ? Et ceci aussi bien par des employés du fournisseur, que des tiers (autorités ou pirates par exemple) qui auraient accès aux systèmes de gestion de clés.

Une solution à suivre : le chiffrement homomorphique

Depuis des années, une solution à ce problème mûrit dans la tête des chercheurs : le chiffrement homomorphique. Derrière ce terme complexe se cache une idée simple : pouvoir réaliser des traitements directement sur des données chiffrées, sans avoir besoin de les déchiffrer ! Depuis 2009, de nombreuses avancées ont été réalisées dans ce domaine en particulier au MIT. Récemment, une équipe d’IBM a même mis à disposition une implémentation concrète (code source à l’appui) de cette méthode. Aujourd’hui, il existe encore un grand nombre de limitations, en particulier par rapport à la vitesse de traitement ou les opérations réalisables. Il faudra également que cette méthode et son implémentation soient analysées par des experts en chiffrement pour en garantir la robustesse.  D’autre part, il faudra toujours que l’entreprise fasse l’effort de gérer correctement ses clés de chiffrement. Le quotidien nous montre qu’aujourd’hui c’est encore rarement le cas !

Une avancée à suivre de près !

Le chiffrement homomorphique représente une avancée importante dans l’industrialisation de l’informatique. Les annonces récentes ont été largement saluées dans les différentes communautés sécurité. Sa mise en œuvre pourrait lever les nombreux freins qui existent encore aujourd’hui par rapport à la localisation des données ou encore aux fournisseurs. Même s’il faudra encore attendre quelques années avant une possible démocratisation, il s’agit clairement d’un sujet à garder dans le radar de la veille !

Cet article Chiffrement : la clé d’un cloud computing sécurisé ? est apparu en premier sur RiskInsight.

La sécurité, une question négligée après la phase de contractualisation

Les limites posées par le SaaS sont aujourd’hui bien connues : difficultés d’adaptation du service aux besoins de l’entreprise, absence de possibilités d’audit, questions réglementaires, etc.

Pourtant, de plus en plus de services cloud sont adoptés, sans que la sécurité ne soit nécessairement un frein. Pour cela, une démarche classique d’analyse de risque est menée en évaluant les contraintes légales / réglementaires,  les mécanismes de protection des données, la gestion de la sécurité par le fournisseur, ou encore les conditions de réversibilité de la donnée.

Cette démarche est de plus en plus maîtrisée : de nombreux retours d’expérience et un outillage qui se professionnalise* amènent à faire des choix éclairés, en toute connaissance de cause des risques encourus, et donc parfois acceptés.

Malheureusement, la démarche sécurité s’arrête souvent là : à partir du moment où le sujet a été traité lors de la contractualisation, on considère qu’un bon niveau est assuré, puisque l’on a exigé du prestataire de s’en occuper !

Le maintien de la sécurité dans le temps est un enjeu régulièrement oublié, alors même qu’il est en partie du ressort de l’entreprise, et pas seulement à la charge du fournisseur.

Des sujets à inscrire dans la durée

Pour s’assurer que la solution cloud est déployée avec le bon niveau de sécurité, et maintenir celui-ci dans le temps, quatre grands thèmes sont à aborder en priorité. S’il s’agit de bonnes pratiques habituelles sur un SI d’entreprise, il faut aujourd’hui les adapter, voire les renforcer pour le SaaS.

•  La gouvernance : les services SaaS doivent être intégrés aux procédures de sécurité et des processus liés au service fourni. Il peut par ailleurs être utile de mener des actions de sensibilisation dans certaines situations.

• L’administration fonctionnelle du service est bien du ressort de l’entreprise : le fournisseur n’est pas en mesure de faire les choix fonctionnels à votre place (et ce n’est souvent pas ce qu’on lui demande) ! Pour l’aspect sécurité plus encore, c’est à l’entreprise de définir  et mettre en œuvre les fonctionnalités avancées disponibles, de restreindre les services au minimum requis par l’utilisateur, de former ses administrateurs… Ces aspects sont souvent les plus négligés, comme nous le constatons lors des audits que nous réalisons.
• Des contrôles réguliers peuvent et doivent aussi être mis en œuvre sur les parties auditables des services. Il s’agit en particulier de vérifier que les paramètres de sécurité sont inchangés, d’exploiter les logs sécurité, et de revoir les habilitations. S’il le permet, enfin, ne pas hésiter à auditer son fournisseur (visites de site, voire tests d’intrusion).
• Il reste enfin à traiter le sujet de l’IAM, enjeu transverse du Cloud, souvent peu ou mal maîtrisé de par sa complexité. Même si cette voie est souvent suivie, il faut pourtant éviter de recréer un compte dans le Cloud pour chaque utilisateur. Pour « synchroniser » les identités de l’entreprise dans le Cloud, il faut également éviter la multiplication des connecteurs  (et notamment ne pas en redévelopper un par fournisseur), sous peine de créer une situation ingérable. Deux approches sont aujourd’hui à prioriser : soit l’utilisation d’un outil de fédération d’identités interne (qui réalise la connexion avec la majorité des fournisseurs de SaaS), soit l’externalisation de l’IAM… dans le Cloud (!) en « Identity as a Service »

Le RSSI, garant de la cohérence des projets

Dans le cas du SaaS, le rôle des responsables sécurité de l’information est double.

D’une part, il s’agit d’accompagner les projets, en leur apportant des solutions transverses : un certain nombre de points peuvent être mutualisés en amont. C’est tout particulièrement le cas des sujets tels que l’IAM, qui doivent faire l’objet d’une approche unifiée et cohérente –  et surtout pas projet par projet.  C’est également le cas des questions légales qui doivent faire l’objet d’une réflexion globale amont.

D’autre part, la SSI demeure la garante du niveau de sécurité dans le temps : la Gestion Opérationnelle de la sécurité devra faire l’effort de partir à la conquête des nuages !

* On peut citer notamment le guide publié par l’ANSSI et la « Cloud Control Matrix » maintenue par la Cloud Security Alliance

Cet article SaaS et sécurité : entreprises, ne mettez pas vos responsabilités dans les nuages ! est apparu en premier sur RiskInsight.

Des sinistres de cette ampleur ont permis d’alerter les DSI sur leur exposition face aux risques naturels. La régularité et la violence de ces évènements climatiques ont poussé les entreprises à prendre des mesures pour faire face à de futures tempêtes de la dimension de «Sandy». Les leçons du passé ont-elles pour autant été retenues ? Ont-elles toutes réussi ce test grandeur nature ? si oui, comment y sont- elles parvenues ?

Les conséquences de l’ouragan « Sandy »

Annoncé comme une catastrophe majeure dans l’histoire des États-Unis, l’ouragan « Sandy » a capté l’attention de la plupart des DSI des acteurs économiques de la côte Est qui ont mobilisé leurs efforts pour déclencher leurs plans de continuité informatique. Ces PCI, mis à niveau depuis les attentats du 11 Septembre 2001, sont fondés notamment sur des procédés de géo-réplication.

Les acteurs du web et plus largement du marché du cloud sont plus enclins à communiquer sur leur capacité de reprise et à faire des retours sur les incidents subis que les entreprises traditionnelles. Les informations disponibles proviennent donc essentiellement de ces acteurs.

De nombreuses pannes d’électricité causées par la tempête, ont entraîné une indisponibilité partielle ou totale de services (Huffington Post, Gawker, Cafemon, Gizmodo, Buzzfeed, etc.) dans bon nombre de datacenters. Les hébergeurs et fournisseurs de services cloud Datagram et 75 Broad ont été indisponibles à causes d’inondations ou réserves insuffisantes de carburant pour le fonctionnement des groupes électrogènes.

« Sandy » a ainsi rendu apparente la vulnérabilité des nombreux datacenters présents dans cette zone (New York, New Jersey, et Virginie) des États-Unis. En effet, plusieurs centres de données géo-répliqués n’étaient distants que d’une centaine de kilomètres (150 datacenters) et donc dans le rayon d’impact de Sandy.

Ces dysfonctionnements mettent en exergue la nécessité, même pour des PCI bien pensés comme ceux de Wall Street, d’être mis à l’épreuve dans des conditions proches de la réalité, avant d’être jugés comme fiables.

 Des PCI à l’épreuve des ouragans

Certains opérateurs de datacenter, comme Telx, ont résisté à Sandy car ils avaient appliqué précédemment des tests simulant jusqu’au bout un sinistre. Par cette initiative, Telx a pu identifier certaines insuffisances dans son PCI comme la surchauffe de ses générateurs en mode dégradé et a donc pu limiter l’impact de Sandy.

Un cas d’école est celui de Buzzfeed qui, malgré le crash de Datagram qui hébergeait ses serveurs primaires, a réussi à réduire considérablement le temps d’indisponibilité de ses services. Cette réussite s’explique par :

• la mise en cache de la plupart de ses pages chez Akamai, le gestionnaire et diffuseur de contenu
• l’hébergement dans un second datacenter des données répliquées en temps réel.

La réplication de ces données a permis le rétablissement des services de Buzzfeed chez Amazon Web services (AWS). Quelques heures ont suffi pour assurer la migration complète des données vers AWS et ainsi basculer leur service sur les infrastructures d’Amazon. Cet exploit est à relativiser car il a nécessité la configuration manuelle d’une bonne partie du socle technique de Buzzfeed et reste donc peu applicable en l’état à un SI complexe.

Les leçons de « Sandy »

Chaque incident majeur est une façon pour les Grands Comptes d’apprendre par le réel et d’anticiper les futures catastrophes. Au-delà d’une stratégie multi-datacenters, Sandy a  mis en exergue la nécessité d’anticiper, de tester et d’adapter le PCI.

Elle a aussi révélé le cloud comme une alternative envisageable pour réaliser un PCI. Alternative que les offreurs cloud commencent à mettre en avant par le biais de leurs offres packagées de Disaster Recovery As A Service.

Les entreprises européennes et notamment françaises, qui ont moins l’occasion de mettre à l’épreuve de la réalité leur PCI, devraient néanmoins s’inspirer des retours d’expériences plus nombreux acquis par les américains. D’autant plus que les hébergeurs de cloud ne rechignent pas à communiquer sur leur stratégie PCI gagnante afin d’en faire un argument marketing. En effet, même si moins fréquentes, l’Europe n’est pas à l’abri de catastrophes équivalentes en termes d’impact à « Sandy ».

Cet article Les plans de continuité informatique des cloud à l’épreuve de l’ouragan Sandy est apparu en premier sur RiskInsight.

Le RaaS : fer de lance des « Cloud Recovery Services »

Comme pour beaucoup de ce qui tourne autour du cloud, il est parfois difficile de donner une définition précise de ce dont on parle, tant une même appellation peut cacher des offres différentes. Nous utiliserons la définition suivante : « Cloud Recovery Service => secours d’un système d’information sur une infrastructure virtualisée, hébergée par un tiers, disponible à la demande et facturée à l’utilisation. »

L’éventail des possibilités est très large :

•  d’une sauvegarde externalisée des données critiques en mode cloud (« Backup-as-a-Service ») …
•  …en passant par la construction par le client lui-même de son secours sur la base d’une prestation de type « IaaS » [2] …
•   …jusqu’à une offre complètement managée intégrant le suivi du SI nominal et des mécanismes de bascule planifiés. C’est ce type de prestations que l’on retrouve sous l’appellation « Recovery-as-a-Service ».

 Quel est l’intérêt de passer au RaaS ?

L’utilisation du RaaS résulte avant tout d’un choix économique. Sur le papier du moins, le secours paraît adapté au modèle de facturation du cloud (pas de sinistre > allocation limitée de ressources > coût d’utilisation réduit), alors qu’un secours traditionnel implique de stocker, héberger et faire évoluer des infrastructures, des serveurs et des applications sur un site de secours.

Mais à y regarder de plus près, les économies ne sont pas toujours au rendez-vous et varient grandement en fonction des applications. Si certaines d’entre elles, peu consommatrices de données, sont les candidates idéales pour le RaaS (des études indépendantes font état d’environ 80% d’économies [3] pour leur secours par rapport à l’approche traditionnelle), le ROI pour les applications plus lourdes et/ou pour lesquels les exigences de continuité sont plus fortes s’avère discutable. En effet, plus les RTO et RPO seront exigeants, plus le niveau de service devra être élevé (allocation renforcée de ressources, mécanismes de réplication des données site-à-site, liens sécurisés, supervision 24/7, etc.) entraînant une envolée des coûts à la clef.

Le RaaS s’assimile, à ce stade de sa maturité, au mieux à du « warm recovery ». En effet, il est aujourd’hui illusoire de penser que les solutions proposées permettront de la haute-disponibilité : délais d’activation, délais relatifs aux opérations de bascule notamment au niveau du réseau, délais de restauration en cas de corruption des données, etc.

En outre, le RaaS repose essentiellement sur des mécanismes de virtualisation de serveurs (le plus souvent restreints aux architectures Intel x86, à l’exception de quelques fournisseurs), que ne supportent pas tous les progiciels du marché, a fortiori les applications propriétaires des clients.

Ainsi, le fait de vouloir tirer pleinement parti de la compétitivité économique du RaaS tout en répondant aux besoins Métiers réduit son utilisation à une certaine catégorie d’applications. Ce faisant, il cantonne le RaaS en tant que solution complémentaire à un secours traditionnel, ce qui peut paradoxalement devenir une source de complexité, du fait de la cohabitation de deux SI de secours. Néanmoins, deux cas d’usage du RaaS émergent pour les organisations concernées :

•  La couverture des applications virtualisées ou éligibles à la virtualisation à coût optimisé
•  L’extension du secours à des périmètres qui n’auraient pas pu être intégrés au Plan de Continuité Informatique de l’organisation, pour une meilleure couverture au meilleur coût.

A qui s’adressent les offres RaaS ?

Étant donné son modèle économique et sa structure technique, le RaaS semble plus adapté aux moyennes structures (qui n’ont pas souvent la surface financière pour mettre en œuvre et gérer en propre un site de secours) et notamment à celles qui ont opéré la virtualisation de leur SI. Les études prospectives [4] le montrent : ce sont elles qui tireront la croissance de ce marché dans les prochaines années.

Les grandes organisations déjà dotées de Plans de Continuité Informatique seront probablement moins intéressées mais pourront néanmoins trouver dans le RaaS des réponses ciblées à certains de leurs besoins.

Le RaaS : une offre mature ?

Comme pour nombre de cloud services, le RaaS n’a pas encore atteint sa pleine maturité : en témoigne le foisonnement des offres et des prestataires notamment aux États-Unis et au Royaume-Uni. Au-delà des acteurs historiques de la continuité informatique se positionnent des pure-players des cloud recovery services et de plus en plus des hébergeurs informatiques, convertis au cloud.

Le marché se structure, les offres évoluent en recherchant notamment de la complémentarité avec les cloud services : des initiatives d’interopérabilité entre services IaaS et RaaS se font jour pour assurer du secours « cloud-to-cloud » par exemple.

A ce stade et en terme de couverture de risques, le RaaS doit faire ses preuves. Concrètement les infrastructures dévolues au RaaS reposent sur encore peu de datacenters. Le client qui souhaitera se prémunir de sinistres affectant des zones géographiques particulières (ou étendues) devra se rapprocher du fournisseur de service RaaS qui l’intéresse pour vérifier que son ou ses sites ne sont pas exposés aux mêmes risques.

En France, le marché reste jeune et sans retour d’expérience significatif de déploiement. Les grands offreurs français s’appuient, aujourd’hui, sur les infrastructures anglo-saxonnes ou nord-américaines de leur maison-mère (ce qui potentiellement impacte la qualité de service, le niveau de sécurité, les engagements contractuels, etc.). Reste donc aux acteurs, anciens comme nouveaux, à démontrer toute la pertinence de leurs offres, en particulier sur la gamme des services managés, probablement les plus recherchés par les DSI.

[1] On rencontre également l’acronyme DRaaS (Disaster Recovery-as-a-Service)

[2] IaaS : Infrastructure-as-a-Service

[3] « Disaster Recovery as a Cloud Service : Economic Benefits & Deployment Challenges »

[4] « Gartner Says 30 Percent of Midsize Companies Will Use Recovery-as-a-Service by 2014 »

Cet article Recovery-as-a-Service (RaaS) : une révolution pour le secours informatique ? est apparu en premier sur RiskInsight.

Certifier le management de la sécurité, pas un niveau de sécurité

Tout d’abord, bref retour sur un point majeur trop souvent oublié : la norme ISO 27001 ne certifie pas un niveau de sécurité, mais son management. Cette norme, qui énonce les exigences à mettre en œuvre pour l’implémentation d’un Système de Management de la Sécurité de l’Information (SMSI), vise à mettre en place le management de la sécurité et à s’assurer de son amélioration continue sur le périmètre de la certification.

Le choix des mesures et du niveau de sécurité en place est donc fait en réponse aux risques et exigences identifiés par les parties prenantes : un choix nécessairement validé par le management ! Contrairement à un standard « catalogue » comme PCI-DSS où toutes les mesures doivent être implémentées pour arriver à la certification, l’audit ISO 27001 ne vérifiera que les mesures sélectionnées comme apportant une réponse aux risques. Une différence de taille, qui pousse vers une sécurité pragmatique mais en contrepartie nécessite une analyse des risques de sécurité de qualité et une attention particulière de l’auditeur externe.

Un périmètre solide

De nombreuses entreprises affichent des certifications, mais il est souvent nécessaire pour les clients de s’attarder sur la lecture du périmètre pour en connaître la valeur : un périmètre très limité par rapport à l’utilisation de leurs données peut être trompeur !

Ce n’est pas le cas ici, puisque Google présente une certification ISO 27001 qui couvre l’ensemble des systèmes, collaborateurs, processus et datacenters qui permettent de délivrer le service Google Apps. Cela inclut les services  GMail, Google Talk, Google Calendar, Google Docs (documents, spreadsheets, presentations), Google Sites, Control Panel (CPanel), Google Contacts, Google Video, Google Groups, mais aussi les briques support (Directory Sync, Provisioning API, SAML-Based SSO API, Reporting API, Audit API). C’est un périmètre impressionnant au vu de la couverture des services, tant sur le plan fonctionnel que géographique !

Développer la confiance et diminuer le nombre d’audits

A l’heure où de plus en plus d’entreprises se posent la question de l’opportunité d’externaliser les services de bureautiques comme la messagerie, l’édition de documents, etc., rassurer les responsables de la sécurité en garantissant les meilleures pratiques de management de la sécurité ne peut qu’être positif en termes marketing. Au-delà de l’apport de confiance, c’est également pour Google la garantie d’une reconnaissance externe, sanctionnée par un organisme de certification indépendant, qui pourra diminuer le nombre ou la charge d’audits des clients. Un bénéfice opérationnel non négligeable – même si Google n’était pas très enclin à se faire auditer !

Si Google a largement communiqué sur l’obtention de la certification, la firme de Mountain View n’a pas été la première à se lancer dans l’aventure : Amazon web services et Microsoft Office 365 ont déjà fait l’objet de la mise en place de SMSI certifiés. Après les infogérants, l’ISO 27001 serait donc en passe de devenir le standard de référence pour la sécurité des services dans le Cloud : on ne peut que se réjouir de ce mouvement qui rassurera les entreprises clientes de ces services. Celles-ci ne doivent cependant pas considérer la certification comme un niveau de sécurité « garantie » et rester attentive aux périmètres et aux mesures mises en place concrètement.

Cet article ISO 27001, un passage obligé pour les fournisseurs de services dans le cloud ? est apparu en premier sur RiskInsight.

En matière de disponibilité, les promesses du cloud n’engagent que ceux qui y croient !

L’Hyper Cycle 2011 du Gartner a positionné en août dernier le cloud dans sa phase de « désillusion ». Force est de constater que les incidents à répétition que rencontrent les grands noms du cloud depuis l’année passée ne font que confirmer cette état de « disgrâce ».  Petit rappel des deux faits marquants de ce début d’année.

Le 29 février à 1h45 (GMT), la plate-forme de cloud services Windows Azure tombe sur 4 de ses 6 plaques mondiales pendant une durée oscillant entre 12h et 48h. Cette interruption de services a son origine dans un bogue logiciel générant une erreur de calcul de dates sur les années bissextiles ; à la décharge de Microsoft,  il est vrai qu’Azure ouvert en 2010 n’a pas connu d’autre année bissextile que 2012. Cette panne a laissé sur le carreau plusieurs sites clés, dont la fameuse place de marché du gouvernement britannique, le « CloudStore ».

Ce 7 mars vers 5h (GMT), le service Facebook tombe en panne plus de 3 heures sur les plaques  Europe, Afrique et Moyen-Orient. Principale cause avancée, celle de la défaillance des serveurs DNS européens de Facebook entraînant l’inaccessibilité du site. Pointés du doigt, les Anonymous ont démenti être mêlés à cet incident. En tout état de cause, le communiqué officiel de Facebook ne laisse filtrer aucune explication. Rappelons-nous que Facebook avait déjà rencontré un problème de configuration BGP en août 2010.

Ces deux incidents majeurs font écho aux non moins médiatiques pannes rencontrées par les promoteurs du cloud computing ; remémorons-nous les incidents de Google (trois en 2009, celle de 05/2010, puis de 02/2011 et 09/2011), d’Amazon et de son service EC2 (12/2010, 04/2011, 08/2011), du précurseur Salesforce.com (02/2008, 01/2009, 01/2010) et du plus récent VMware Cloud Foundry (05/2011).

S’agissant de « résilience », les atouts du cloud ont maintes fois été présentés, on citera en substance :

• Taux de disponibilité avantageux (Salesforce.com affiche 99,9%)
• Répartition et duplication des ressources sur des lieux géographiques différents
• Accessibilité permanente, en tout point du globe
• Standardisation de l’offre technique, facilitant sa reproductibilité sur les datacenters

Pour autant, le cloud n’en reste pas moins une machinerie complexe par construction ; du fait de l’empilement des services qui le composent, du volume des ressources qui le constitue et, paradoxalement, de leur répartition sur le globe.

Au-delà de cette complexité qui impacte les gestes d’exploitation et de maintenance au quotidien s’ajoutent également les risques posés par le modèle de standardisation retenu. Les effets d’une erreur de manipulation, d’un bogue ou d’une vulnérabilité se font ressentir rapidement sur tout ou partie des infrastructures sous-jacentes.

Difficile dans ces conditions, face à des offres « boîtes noires » peu dissertes sur leur fonctionnement interne, d’accorder un crédit sans limite aux niveaux de disponibilité avancés. Du reste, le cloud public, universel dans son usage et par sa fréquentation, ne permet pas de préjuger de la manière et avec quelle priorité seront traitées, en cas de sinistre, les entreprises (grandes ou petites) en regard des individuels que nous sommes.

Des axes de progrès pour une meilleure résilience du cloud

Ces incidents à répétition témoignent d’une maturité encore insuffisante du marché et des fournisseurs, qui fonctionnent encore pour certains « au coup par coup ». Pour autant, le tableau n’est pas si noir, le modèle vertueux d’amélioration continue se met en place, sous l’impulsion notamment de l’alliance CSA (cloud security alliance)  qui promeut de bonnes pratiques en matière de sécurité et de résilience du cloud, des exigences d’acteurs clefs et /ou de gouvernements (PCI DSS, FISMA, HIPAA, etc.) et, il faut bien le dire, au gré des incidents vécus.

D’autant que la problématique de continuité tout comme de sécurité est au cœur des préoccupations des fournisseurs de service ; en affectant la confiance de leurs clients, présents et futurs, elle touche directement leur business model. Rappelons-nous enfin que l’une des promesses essentielles du cloud computing est d’améliorer la résilience du service rendu, parce qu’il est précisément « partout dans le nuage ».

A y regarder de plus près, le nombre d’incidents rencontrés par les acteurs du cloud est équivalent sinon inférieur à ce que rencontrent les entreprises. Le principal facteur aggravant tient au fait que la surface d’impact est sans commune mesure avec celles des SI des entreprises (ce sont des dizaines de milliers voire de millions d’usagers qui sont touchés).

Les fournisseurs de service entrent doucement dans la phase de maturation de leurs offres ; ils renforcent progressivement leurs dispositifs de continuité, prennent davantage en compte le facteur humain (source indéfectible d’erreur !) et apprennent aussi à mieux communiquer auprès de leurs clients.

Mais il ne faut pas croire au cloud « infaillible ». Aussi, les entreprises consommatrices de services cloud doivent-elles prévoir des processus de continuité de leurs métiers les plus sensibles et de préservation de leurs données les plus critiques.

C’est enfin le prochain challenge des fournisseurs que de prouver et démontrer les performances de leurs services cloud face à ceux des SI des grandes organisations !

Cet article Panne Facebook : symptomatique de la résilience du cloud computing ? est apparu en premier sur RiskInsight.

Une fois de plus les Assises sont un succès, un succès à la fois grâce à une organisation de grande qualité mais aussi du fait de la présence de l’ensemble de la communauté française. RSSI, responsables des risques, DSI, éditeurs, constructeurs et cabinets de conseil, tous étaient là dans une optique de partage et d’échange toujours aussi fructueuse.

Quels sont les sujets d’actualités et les nouveautés rencontrées ?

Les sujets ont tellement été diversifiés qu’il est quasiment impossible de tous les citer. Si je devais le résumer les 3 mots clés les plus rencontrés, je dirais : cloud, consumersation et cybercriminalité. Ils ont été largement débattus et ont fait l’objet de nombreuses annonces innovantes. A l’inverse, je noterais une  plus faible représentation des sujets attenant à la sécurité applicative, pourtant au cœur de la protection aujourd’hui. Enfin, des sujets plus atypiques et prospectifs comme l’IPv6, ont fait leur apparition.

Finalement la gestion de risques et l’évolution du rôle du RSSI ont, une fois de plus, été l’objet de nombreuses discussions dans plusieurs ateliers, dont celui animé par Solucom. Le débat s’est élargi, touchant alors à des problématiques hors « sécurité », avec notamment une intervention de premier plan de Luc Ferry sur la multiplication des peurs dans notre société. J’en retiendrai que la peur ne doit pas être le premier élément de nos réflexions et que la gestion du risque ne doit pas être un frein au développement ou à l’innovation !

L’ANSSI a animé une plénière pour alerter la communauté et lui demander de revenir aux fondamentaux de la sécurité, quelle est votre analyse ?

Je pense qu’aujourd’hui la communauté sécurité connaît bien ces fondamentaux (gestion d’identité, correctifs, antivirus, durcissement…), mais elle est confrontée depuis plus d’une dizaine d’année à la difficulté de les faire appliquer. Les équipes techniques et les métiers rechignent, les directions ne comprennent pas.

Cet état de fait a amené la communauté à s’orienter d’une part autour de la gestion des risques, afin de  concrétiser et d’expliciter en termes « métier » les impacts potentiels, mais aussi d’autre part dans la publication de nombreuses normes ou réglementations pour aider ou « forcer » l’application de ces mesures. Pourtant, cela n’a marché qu’un temps et la plupart de ces initiatives se sont transformées en sécurité « cache sexe » comme le disait Patrick Pailloux. Cela est un vrai drame car ces démarches pourtant de qualité sont trop souvent dévoyées !

A mon sens, aujourd’hui, la communauté sécurité manque de leviers pour convaincre les directions et les métiers. Elle manque également de support managérial pour réellement sanctionner et faire évoluer des pratiques déviantes souvent rencontrées. Les récents incidents médiatiques sont une aide mais la logique du « cela n’arrive qu’aux autres » est encore trop répandue

L’ANSSI, grâce à son message « back to basics », joue un rôle de premier plan. Mais elle pourrait aller plus loin en faisant part régulièrement de leur « thermomètre » du risque tel qu’évoqué durant la plénière afin de faciliter la sensibilisation des donneurs d’ordre.

Il faut arrêter de minimiser l’exposition de la France aux menaces cybercriminelles. L’illusion de sécurité est bien trop répandue aujourd’hui et j’espère que  les messages forts de la plénière aideront à changer cette situation.

Cet article Trois questions à Gérôme Billois sur les Assises 2011 est apparu en premier sur RiskInsight.

Une nouvelle bataille juridique s’ouvre entre les États-Unis et l’Europe. En jeu cette fois-ci, le Cloud Computing. L’’affiche ? USA Patriot Act Vs. Directive Européenne de protection des données à caractère personnel.

D’un côté, l’USA Patriot Act. Véritable épouvantail de l’externalisation et fer de lance de la lutte antiterroriste US, il autorise les écoutes et la capture de données par les autorités américaines, avec un encadrement judiciaire permettant de le faire à l’insu de leur propriétaire… Il constitue l’argument le plus précieux des opposants de l’hébergement de données aux Etats-Unis.

De l’autre, la Directive européenne pour la protection des données à caractère personnel. Mère européenne de la Loi Informatique et Libertés française, elle encadre fortement le traitement de données en dehors de frontières de l’Union et, plus généralement, leur accès non légitime et non autorisé par le responsable de traitement. Bien plus, elle le rend pénalement responsable de tout accès tiers non signalé aux propriétaires des données.

Au centre, Microsoft. Le géant de Redmond consent des efforts importants pour être en conformité avec les réglementations sur les données à caractère personnel. En particulier, leur adhésion aux principes du Safe Harbor , qui, en dépit de certaines limites, constitue une garantie jugée suffisante par l’Europe pour que soit autorisé le transfert de données à caractère personnel vers une entreprise américaine. D’autre part la mise en place d’un Cloud européen, aux serveurs dédiés et localisés strictement au sein des frontières de l’Union ensuite, offre une solution simple pour la conformité.

A l’origine de la bataille, une conférence dédiée au lancement d’Office 365. Le directeur Royaume-Uni de Microsoft a alors reconnu tout haut ce que bon nombre de spécialistes du secteur murmuraient déjà : son siège social étant domicilié aux Etats-Unis, Microsoft est soumis au droit national… et doit donc appliquer l’USA Patriot Act y compris sur le sol européen.

Et ceci est vrai pour l’ensemble des fournisseurs américains de services de Cloud computing ! Ils pourraient ainsi être amenés à communiquer aux autorités américaines des données de leurs clients européens, en dehors de tout cadre légal national ou communautaire.

Cette transparence soudaine signe-t-elle le début de la fin du Cloud computing made in USA ? ou s’agit-il d’une opportunité de croissance inespérée pour les fournisseurs européens ? Doit-on s’attendre à une migration massive des premiers vers les seconds ?

Ce qui est vécu comme une ingérence américaine sur le terrain législatif communautaire est aujourd’hui examiné par la Commission Européenne, qui s’est saisie du sujet.

Sans préjuger en rien des conclusions des débats d’ores et déjà très animés sur le sujet, cette bataille mérite d’être suivie avec attention.  Et permet de rappeler l’importance d’une analyse de risques, y compris juridiques, avant tout recours à un fournisseur externe…

Cet article La guerre des réglementations aura-t-elle raison du cloud computing? est apparu en premier sur RiskInsight.

De nombreux incidents ont rythmé l’année. Deux cas ressortent particulièrement : Stuxnet, premier virus ciblant spécifiquement des équipements industriels, Wikileaks et la fuite de données gigantesque qui a touché les Etats-Unis. 2010 a également été une année où de nouveaux usages se sont développés! La virtualisation, qui est maintenant définitivement entrée dans les datacenters, le cloud computing, qui fait ses premières preuves ou encore les smartphones et autres tablettes avec des premiers déploiements métiers mais également des premiers usages innovants d’utilisation d’équipements personnels.

Une nouvelle approche pour de nouveaux enjeux

L’ensemble de ces évènements a aussi montré la limite des approches sécurité classiques. Celles-ci sont basées avant tout sur une protection de l’infrastructure du SI. Nous ajoutons des mécanismes de sécurité sur les différentes briques que sont le poste de travail, le réseau d’entreprise, l’accès Internet, voir le datacenter. Mais cette approche ne permet plus de répondre aux nouveaux enjeux ! En effet l’information est de moins en moins traitée sur les infrastructures de l’organisation. Elle est de plus en plus partagée, avec des partenaires et des clients, accédées depuis des équipements mobiles voir personnels, parfois encore traitées sur des systèmes aux contours plus ou moins connus comme dans le cadre du cloud computing.
Une nouvelle stratégie de réponse doit être envisagée face à ces évolutions, une stratégie qui devra être basé sur un principe simple : protéger au plus près les informations les plus sensibles. En effet pour être efficace et pérenne la sécurité doit se rapprocher de l’information, voir être portée par l’information elle-même, pour pouvoir être mieux partagée tout en étant toujours sécurisée.

Quelles en sont les conséquences ?

Ceci nécessite de planifier des chantiers ambitieux, lié par exemple à la classification des informations les plus sensibles, à la mise en place de mécanismes de protections des données (chiffrement, DRM, DLP…) ou encore à l’inclusion des mesures de sécurité dans les applications (chiffrement, scellement, authentification, processus projet…). Bien entendu les fondamentaux de la gestion des identités jouent un rôle essentiel et devront être encore renforcés pour y ajouter la gestion des partenaires et des clients. Mais il faudra aussi faire évoluer les habitudes, en ayant un focus particulier sur les équipes en charge des applications au cœur de cette nouvelle problématique de protection.L’objectif de 2011 est de faire évoluer nos principes pour aller de la protection de l’infrastructure à une vraie protection des données. Voici une année qui s’annonce donc riche en projets et en challenge !

Cet article 2010 – 2011 : protéger les infrastructures ou protéger les données ? est apparu en premier sur RiskInsight.