The importance of the M365 suite in business

The Microsoft 365 software suite offers a critical set of collaborative services for businesses (Figure 1). These collaborative services handling a large volume of potentially sensitive data need to be secured, thanks to tools. Microsoft has therefore made available a range of security products, to reduce these risks.

Figure 1 – The features of the M365 suite.

Internal threats are often forgotten but increasingly present

The M365 tenants, like any computer system, obviously represent a potential target for external attackers. However, the internal threat should not be underestimated, especially since the proportion and impact of the latter is not negligible.  Indeed, in 2020 in North America, nearly 19%[1] of threat actors come from inside the company. Different categories of insider threats can be distinguished:

• Sabotage designates an internal employee using legitimate access to damage or destroy company systems or data in order to harm the company;
• Fraud, represented by the modification or destruction of data by an insider for personal gain;
• Data theft where the insider steals the company’s intellectual property in order to resell it or keep it for himself or for an upcoming job. The insider may also steal information for another organization (competitors or governments for example), for the purpose of carrying out industrial or government espionage;
• Clumsiness that comes from mistakes or unintentional actions performed by a negligent employee.

These threats are also associated with potential actors:

• Malicious employees with the aim of carrying out acts of sabotage (e.g. modification or deletion of data).
• Employees leaving a company, especially if they leave it forcibly. In this case, the biggest associated threat is data theft. According to a study^[2], 70% of employees say they take with them the work they have produced for the company, even though it does not belong to them.
• The internal agent who is a person working for an external group to allow them to access company resources. These people may have been subjected to methods of corruption or even blackmail.
• Disobedient people who circumvent company’s security policies, for example by using personal online data storage solutions, creating a risk of data leakage.
• External workers who are not employees but who have access to the company’s information system (service providers, suppliers, partners, etc.).
• Careless workers, who are not aware that their actions lead to vulnerabilities for the company. Indeed, in most cases, security breaches involving an employee are not intentional, but come from negligent workers (in 56% of cases in 2021^[3]). For example, an employee may lose or have an unencrypted device with sensitive data stolen that could put the business at risk. Or just share files to the wrong people or delete important items without realizing it.

Microsoft’s response to these insider threats

One of Microsoft’s challenges today is to help its customers protect themselves against internal risks. Currently, Microsoft offers a group of solutions to combat insider threats called:  “Microsoft Purview“, formerly known as “compliance center” (see Figure 2[4]).

This group includes

• “Communication compliance“: minimizing communication risks by making it possible to detect, capture and act on risky messages within an organization;
• “Information barriers“: restrict communication and collaboration between 2 groups to avoid internal conflicts of interest;
• “Privileged access management“: control access to administrator tasks in Exchange Online to avoid access rights that are too high.

Finally, Microsoft Purview is also newly composed of the   “Insider Risk Management” (IRM) module. This module helps minimize internal risks by detecting, investigating and acting on malicious or unintentional activities within an organization.

Figure 2 – Microsoft’s insider threat management modules.

Insider Risk Management, the Microsoft solution that helps organizations address some of these insider threats.

As explained earlier, IRM helps minimize internal risks. Concretely, the tool works in different phases (which will be detailed later) and is based on proven data from Microsoft workflows. It has pre-established data leakage scenarios such as an employee’s resignation or dissatisfaction. These scenarios facilitate the analysis of risky activities by providing context. The tool will be able to use metadata related to the targeted scenario, such as the dates of departure or annual maintenance of an employee for example. Thus, it will be able to assess the level of risk of users and generate alerts at the appropriate time.

For this, Insider Risk Management uses different modules of M365. IRM is an advanced solution and therefore requires specific licenses. To be able to use this module, there are several licensing possibilities:

Figure 3 – Three ways to get Insider Risk Management with Microsoft licenses.

A tool that works in 6 phases

The first is the strategy creation phase, which defines the triggering events and risk indicators leading to the generation of alerts.

The second is detection, when a user’s activities begin to be analyzed by IRM as a result of suspicious activity (triggering event).

The third is a phase of generation of alerts, they are automatically generated by the risk indicators defined in the strategies.

Once an alert is lifted, IRM provides a triage step that allows administrators to classify alerts based on severity and other parameters.

Then comes the inspection phase which allows to analyze in depth all the activities related to a user and an alert thanks to the creation of a deep analysis file (“case”).

Once the alert has been processed, the action phase intervenes. It consists of resolving the analysis case, either by alerting the user to unusual behavior, or by alerting the organization’s stakeholders (legal, IS, human resources, etc.) who can take appropriate action.

Figure 4 – The 6 phases of IRM operation.

To work, Insider Risk Management fully integrates with the M365 components of the tenant on which it is deployed (see diagram in Figure 5).  Indeed, the data received from other modules allows the analysis of workflows and different activities.

Figure 5 – Overall IRM architecture diagram

To begin, define detection strategies

As presented above, the first step is the definition of strategies, which are based on one of the 5 scenarios established by Microsoft: 

• Data theft: Combating the theft of company data for the purpose of profiting or personal interest. This scenario applies to users leaving the company (voluntarily or not).
• Data leakage: Fight against the intentional or unintentional sharing of sensitive information.
• Misuse of health data: Combatting the illegal exploitation of health information by employees.
• Violation of security policies: Combating the installation of malware and the uninstallation or disabling of certain services.
• Dangerous use of browsers: Detects browsing behavior that may not be acceptable by the company’s charter (visiting sites that incite hatred, with adult content) or present a threat (phishing sites).

These scenarios are available as templates to feed strategies and can include any type of user in an organization, but IRM allows for more precision and more meaning and context by targeting specific categories of users. Here are the 3 types of actors offered by Microsoft:

• Disgruntled users: Employee’s behavior can be influenced by many events such as performance evaluation or organizational changes (including “demotion” in the organization). To do this, IRM allows you to import data related to performance and organization.
• Employees leaving the company: An employee can change companies or be fired and therefore become a threat to the organization they worked for.
• Priority users: Users with privileged access or with high-risk responsibilities.

To detect these cases, IRM allows you to import data from HR tools (evaluation, organization, resignations, dismissal), and data related to user authorizations.

Figure 6 – Components of an Internal Risk Management Strategy

The definition of detection strategies (scenarios and actors) allows you to configure the associated list of triggering.

If we take as an example, the “data leak” scenario, it includes a set of indicators and triggering events to prevent accidental and intentional data leaks. But depending on the users targeted by this strategy, the indicators and triggering events will be different (see table below). In this example, the policy can apply to all users, to priority users (for example, a group of users working on sensitive data), or to disgruntled users (for example, a focus on users who have been denied their promotion).  The detection mechanism and the importance of indicators and triggering events specific to the selected user profiles are detailed in the rest of this article.

Next, detect suspicious activities

Once the policy creation phase is complete, the detection phase (Figure 7) is used to generate alerts.  This step is the most important for detecting malicious behavior. It should be noted that without a triggering event present in an internal risk management strategy, user activities are not analyzed by IRM.  The triggering events are related to the chosen detection scenario. As said before, this can be a resignation date or massive exfiltration activities (printing, downloading, copying to USB, sending email, etc.) or deletion.  Triggering events can also be a sequence of actions, such as when a file is downloaded, then exfiltrated and finally deleted.

Figure 7 – Focus on the detection process.

After a user performs a triggering event, he become the target of the associated detection policy. From then on, the activities of the users defined in this strategy by the risk indicators are analyzed. Risk indicators can be indicators related to Office activities (manipulating files on SharePoint, OneDrive, Teams …), activities on devices (printing, renaming, creating hidden files, using USB keys, installing software…), browsing activities (accessing malicious sites, dangerous content…) and activities of other cloud applications (thanks to Microsoft Defender for Cloud Apps).  If one of these indicators exceeds a certain threshold (defined via the policy), then an alert is generated and if the alert is confirmed by an IRM administrator as not a false positive, a case is opened to be able to analyze in detail the activities of the targeted user.

Finally, process the generated alerts

When a threat is confirmed and an in-depth scan file has been opened, IRM and global admins can then observe the content that has been downloaded, shared, printed, viewed, etc. This then allows stake holders to decide on the action to be taken in the face of the threat. We can either send a notification to the user concerned or escalate the case for investigation. However, it is important to remember that Insider Risk Management, does not allow to restrict the actions of a malicious user, it remains a tool of alert and inspection facilitating decision-making.  

IRM is a powerful and promising solution but is not yet sufficiently mature

While Insider Risk Management requires a good understanding of all M365 services and Azure AD, it leverages the capabilities of security services to provide a better protection against insider threats.  As described earlier, Insider Risk Management is a very effective tool, which analyzes all workflows and easily adapts to the activities of companies and users.

However, some points remain to be clarified and improved.  Indeed, the effectiveness of IRM is contrasted by its rather high reaction time (about 12 hours to detect activities) and its interface which is not intuitive enough. Also, Microsoft documentation can be complicated to understand or even false in some cases (wrong date format for HR data for example). In addition, in the current situation, the scenarios presented could be monitored by a company’s SOC teams (via specific scripts, or alerts for example). Therefore, the tool is still less used by companies.  Nevertheless, the evolution of the maturity of this tool needs to be carefully monitored, as regular changes are made (such as the addition of new detection scenarios).

In conclusion, what questions should be asked at the outset?

Define the concrete use cases to be covered and evaluate the added value compared to existing alerting (within the SOC).

Evaluate the impact of this tool on personal data, given its operating power.

Think about the organization to implement (responsibilities, alert handling process, strategy evolution process).

[1] Source: Verizon’s 2021 Data Breach Investigations Report (link).

[2] Source: Article “What happens to your data when a departing employee leaves? » on S2|DATA (link).

[3] Source: 2022 Cost of Insider Threats Global Report from Ponemon Institute (link).

[4] Based on Microsoft documentation for the Insider Risk Management product.

Cet article IRM, a tool to better manage internal risks in the M365 ecosystem 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.

In particular, with the explosion of the IoT and regulations such as DSP2, the need to trigger uncorrelated authentications from the  user’s medium access become more pressing: indeed, the later may not have the necessary interfaces, or may not be recognized as a sufficiently secured support.

The additional cinematic CIBA, Client Initiated Backchannel Authentication Flow aims to define the exchanges and calls allowing to trigger such authentications. This first article aims to briefly describe the high-level operation of this cinematic, and to present the contributions and additional use cases that it can cover.

What is CIBA?

CIBA is a new authentication flow and authorization of the OpenID Connect standard, defined by the Open ID foundation.

The CIBA flow is the first OpenID flow qualified as ‘’decoupled’’, because it introduces the notions of Consumption Device (CD) and Authentication Device (AD). The CD is the device on which the access to a service (Relying Party, RP) is requested, whereas the AD is the device on which the user authenticates  themselves  with the OpenID Provider (OP) and authorizes the CD-requested access, by giving its consent.

Contrary to the other flows of the OIDC standard, CIBA considers that the user can authenticate on a device different from the one on which he wants to access the service. For example, a user is looking to access his bank account from his computer and authenticate themselves to authorize the access from his smartphone.

What contributions?

The CIBA flow presents several significant interests for users’ authentication.

Today’s OIDC authentications flows are relying on web redirection between the accessed service (Relying Party) and the identity provider. These redirections are not very user-friendly and might be disturbing for the users, who see their browser, or their application go from a page to another without really understanding this behaviour. With CIBA, the device that the user employs to access the service stays on said service’s page, waiting for user authentications to be executed on the AD. The redirections’ disappearance also improves the Relying Party’s acceptance, which does not lose control and visibility of the user’s action when the latter must authenticate themself to the OP anymore.

Gains by population

The multi-factor authentication (MFA) is more and more common and recommended to access internet services. Texts, soft-tokens or Out-Of-Band push notifications are several examples of additional authentication factors, used today in addition to a password. With CIBA, this factor’s presence is a natural part of the authentication, since it is carried out on a registered device like AD. Asking the users to authenticate themself on the AD with a password, a PIN, a biometric factor, etc… allows a centralization of the authentication actions on a single device, while allowing to do some  MFA.

Use case examples

The call centre

Nowadays, when a client rings a call centre, the operator often verifies the client’s identity with several personal inquiries (date and place of birth, social security number) or with security inquiries. This authentication method is particularly vulnerable to attacks, such as social engineering.

Thanks to CIBA, it is possible for the operator to trigger an authentication request for callers on their Authentication Device, and thus ascertain the client’s identity in a more secure fashion.

Virtual assistants

DSP2 imposes banking organisations to ascertain the identity of the person carrying out an operation over a certain threshold, which mandatorily passes through an authentication phase (2 factors) during a transfer, for example. However, IoT such as the voice assistants do not have an interface allowing the user to input their identifiers, and force the customer to validate a transfer request on a web portal via his smartphone or his PC, which is not the ideal user experience. CIBA is used to free oneself from this constraint, because the customer’s bank is then able to send an authentication request on the adequate terminal (AD), limiting the impression of a break in course for the customer.

Conclusion

The authentications cinematic CIBA fills real weaknesses of the OpenID Connect protocol, both in terms of functional coverage and customer experience. It’s implementation in the real world should happen quickly, and numerous market players are already looking to implement it.

Cet article FAPI-CIBA: How to authenticate my user without an interface? est apparu en premier sur RiskInsight.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How do I protect my data?

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

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

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

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

How to remain compliant with the regulations?

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

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

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

The thorny issue of stock management

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

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

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

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

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

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

A model of administration

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

A semi-architectural / semi-security community

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

The life cycle of shared identities and spaces

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This reflection should cover the main risks of data leakage and access to data by administrators, Microsoft and third parties or applications.

A new governance model imposed by Microsoft

Office 365 is a SaaS communication and collaboration solution. As such, the platform is constantly evolving, unlike the historical “on-premise” solutions: new features or settings appear and are modified, while others disappear (e.g. retirement of Skype for Business planned for 2021, July 31^st and the end of legacy authentication support for Exchange Online planned for 2020). This continuous delivery pace is imposed by Microsoft, without control. Hence, a completely new governance model is required.

Changes integration can no longer be done in project mode. It must follow an established process. In this model, the workplace and security teams must work hand in hand and must be represented in all project and architecture committees, starting from the very beginning of the platform use cases design. These teams will also have a common responsibility to ensure the platform efficiency and regulatory compliance.

The security team sees its perimeter evolving: it no longer has control over security tools and can, or even must, play a business enabler role to support the migration to the cloud by proposing new uses (e.g. opening a controlled external file exchange service). An appropriate organization must be put in place. We could even consider having a Security Officer dedicated to the platform very close to the business, with the role of advising projects, ensuring the platform configuration and monitoring security alerts.

Another topic to be addressed is the delegated administration.  Even though it is not a rare situation, it is not possible to have nearly 20 General Administrators for an O365 tenant. Indeed, a Global Admin has control over Office 365 services, but also Intune, Azure, AAD, etc. A delegated administration solution must be considered for user accounts and objects, through the implementation of an interface or a connector based on PowerShell or Graph API. This process should allow the company to manage all objects while considering business logic. To define this new governance model, the following security pillars must be articulated:

• Identity management ;
• Mastery of services and uses ;
• Control of compliance to company policies.

Identity management at the core of the model

In a solution designed to enable internal or external collaboration, with an ATAWAD use (Any Time, Any Where, Any Device), identity management (and therefore authentication) is the core of platform management.  As with any project, the definition phase of who can access what, when and where is fundamental.

On Office 365, there are three types of users, each with different privilege levels: administrators, internal users and guests (external users invited to collaborate on a file or within an O365 Group or SharePoint site).

For each of these account types, implementing the defined security measures will be challenging. In addition to the unavoidable multi-factor authentication (highlighted by the data leak that affected Deloitte in 2017), there are also other essential issues, such as administrator access control (personalized or predefined roles, permanent or occasional access, etc.) and guest users lifecycle management (nothing being clearly defined by default). The cost of Azure AD Premium licenses or a third-party tool will be a major element of the discussion.

Also note that Office 365 allows external applications to communicate with its APIs. The external application can then act on behalf of a user with its own rights or of an administrator with higher privileges. These applications can come from different application stores (such as AppSource or AAD) or be developed locally. The management of permissions granted to these applications must be highly considered by companies. Indeed, through APIs, it is very easy to imagine a massive data leak in case of a user dupe (e.g. an application requiring unnecessary permissions, such as email access).

An essential but neglected control of services and uses

Once access to Office 365 is under control, the next topic is to manage its use. It is not uncommon to observe that some services, not prioritized during migration to the Cloud (Power BI, Teams, Flow, API access, etc.) are left accessible with their default configuration. The two reasons are generally a focus on adoption and a lack of time devoted to these non-priority services. In addition to setting up the service, it is also essential to define precise rules around uses to clarify who can do what and when (e.g. managing SharePoint authorizations, creating Groups). The best solution consists in implementing technical measures (general settings or configuration via PowerShell) congruent with the defined policy.

However, the lack of security of these services leaves the door open to potential data leaks: automatic transfer to the outside, exposure on the Internet or loss of the data control. As written above, governance must take security into account when designing future uses. Services must be analyzed and tested on small populations. Indeed, it will always be easier to open a feature than to restrict an already widespread use. In that case, it will be necessary to carry out an impact analysis, to tinker with a workaround solution and to raise users’ awareness widely. However, these actions may require significant investment and could be avoided.

The management of the service should not end with user adoption. Security and Workplace teams will be responsible for following Office 365 evolution (Evergreen program, setting up a watch, monitoring Microsoft blogs, etc.) in order to assess new opportunities and threats.

The control of the compliance with company policies

The implementation of the company security policies is the last pillar and includes the implementation of security tools: information protection, anti-malware, supervision and alerting.

Concerning Office 365 security, we can differentiate 3 levels of maturity. The resources put in place will depend on the expertise available (resources being limited on the market) and the budget (depending in particular on the strategy of the Microsoft licensing management company):

• Level 1 – Control of identities, services and use of the Security and Compliance Center: the company implements native Security Center and Compliance Center security solutions (including Office DLP, Exchange Online Protection, eDiscovery) accessible with basic licenses;
• Level 2 – Development of “in-house tools”: the company creates a set of simple scripts or dashboards, using Graph API, Security Graph API and PowerShell, to implement controls and security measures adapted to its context (e.g. life cycle management of guest users);
• Level 3 – Use of advanced security tools: the company implements additional solutions to strengthen the level of security: tools to fight data leaks, analyze malware on emails, review rights, detect abnormal behavior or even harden the use of the platform according to the context.

Mastering Office 365 services, their uses and native security features is essential, and must precede any consideration of adding an additional security tool, which would not cover existing vulnerabilities and would only add complexity.

Sample of controls included in the Wavestone Office 365 Audit Methodology

Conclusion

Office 365 is an interesting case of opening business applications on the Internet through the Cloud. This evolution requires adapting the company historical security model, towards the airport model following the Cloud adoption.

However, Office 365 security must not omit the security of the on-premise bricks necessary for the platform operation, as it is generally the case for the authentication that is carried out by ADFS.

Cet article A secure Office 365, a rare gem? est apparu en premier sur RiskInsight.

What are the risks in the iot world?

The IoT advent has enabled millions of new potential technological advantages for consumers and companies. However, with these new advantages, certain risks are higher in the field of connected devices.

Figure 1 – Most significant risks in the IoT world

These business and technological risks which could cause significant potential impacts for consumers and companies, should be identified from the upstream phases of an IoT project.

Which project methodology to choose in order to ensure security of connected devices?

Even though security issues to address in IoT project are common for all project, we think necessary to structure reflections regarding the life cycle of the connected device.

The diagram below highlights all the stages of their life cycle.

Figure 2- A life cycle enabling to address all the security issues

Let us review  some important issues raised by this approach:

1. Design, manufacturing, and distribution phases

This first phase addresses issues related to the design of the object, regarding business stakes, targeted users (B2B, B2C, B2E), deployment environment (controlled or not) and criticality of the use:

• What are the regulatory constraints related to the use of the object?
• What identity should be labeled and how is this identity created?
• How is the security related to object’s hardware and software secrets and data stored in the object?
• How is the state of a device on the management platform initialized, ensuring it has no right on the IS before the initialization step?

The determined choices during the manufacturing phases are crucial because they determine characteristics and capacities of the device. Some of them will therefore be immutable throughout the life of the device and will impose strong constraints in the following steps.

Furthermore, although the end of the manufacturing phase marks the beginning of the existence of the device on the device management platform, there is still no reason to consider an interaction with the IS.

Any interaction before the device’s association to a user (physical or moral) would mean that it has been diverted in the distribution phase. Any access to the IS before the initialization phase must be strictly limited to the firmware update (version N installed at the factory and version N+1 available when unpacking) or to the pre-customization of the object (operating settings or injection of secrets not related to the user). Beyond IS security, an object that is unused before any pairing phase will reduce the risk of theft of that object in the factory or during distribution.

2. Initialization phase

Initialization phase materializes the association phase (also named pairing) between a device and its owner. Any data generated by the device (or realized action) is then declared as belonging or attributed to its owner..

Therefore, the main challenge is to ensure a reliable level of user / object association corresponding to the following business stakes:

• Low level of association required (low-risk situation): An employee declares the usage of an attendance identification system in the meeting room;
• Strong level of association required (high-risk situation): when purchasing a connected lock, a consumer provides a serial number and a one-time secret code to allow his mobile application to unlock the door of his home.

It is very important to find a balance between the user experience and security.

The robustness of the expected association will vary according to the nature of the services to which the customer has subscribed.

3. Use phase

The definition of the use cases of connected devices is the most anticipated step by companies, however many aspects of security remain neglected.

Besides business use cases, additional questions must be raised:

• How can regular updates of the connected device be implemented?
• What are the different actors of the company roles regarding the maintenance of the device operating system layer: the application layer, and the network module?
• What is the detection and response requirements for a compromised device?
• How to take advantage of the company SIEM (Security Information and Event Management) and SOC (Security Operation Center) for technical security incidents (software compromise of the device) and for business security incidents (misuse or theft of a device)?
• How can backward compatibility of protocols and APIs used by different versions of the same type of device be maintained?
• What are the models of roles and interactions between different populations acting on the object?

Concerning this last question, and as an example, the scheme below illustrates the potential complexity stemming from the interactions and roles model such as a connected vehicle.

Figure 3- Example of a roles and interactions model with a connected vehicle (research carried out with IMT Atlantique)

4. Resale phase

Today, the resale is the most neglected phase during the device design. This event essentially concerns devices for B2C markets and raises very specific issues:

• How to detect and handle the resale of a device between individuals?
• What privacy-by-design principles should be implemented to protect secrets and data from the former owner while resetting a device?
• How can access rights of the former owner of the device be removed?
• What are the ways to reset a device in a stable and clean state before re-pairing?

The major difficulty involves the detection of the resale event which triggers the device/user unpairing processes, reset the state of the object, etc.

Our experience allows us to identify some circumstances that could indicate a change of ownership.

Figure 4 – Examples of events that could indicate the change of ownership

Despite such examples, we witness that resale remains a complex event to identify. Thus, some companies choose not to authorize the device resale via a lease contract. The device must therefore be returned when the service is terminated; otherwise it must be made unusable. This model is comparable to renting an Internet box with an ISP (Internet Service Provider).

5. End-of-life and recycling

Although essential, we currently have little perspective on this step, however there are multiple stakes:

• Revoke access rights on the Information System of an end-of-life device;
• Renew the identity of a recycled device;
• Ensure the replacement of a defective object by re-associating a new one with the same owner and the same data;
• Detect the inactivity of a device to trigger a replacement.

The main risks are the loss of access control over the company IS via identifiers associated with recycled devices, the disclosure of personal data of the former owner or the additional cost of license for data generated by devices considered out of the scope.

A variable capacity of action in response to the risks according to the nature of the project

At this stage of your reading, you probably think that this article is not your concern because you purchase pre-conceived connected modules or devices.

Unfortunately this mindset is wrong –  you are still exposed to the same risks! Even though you only purchase or welcome connected devices in your IS, by addressing all the issues above you will be able to feed the contents of requirement specifications to suppliers.

To conclude, whatever the nature of your IoT project, it is essential to design your object by structuring the reflections around its life cycle: from its manufacturing to its disposal. It is therefore necessary, at each stage, to address all the relevant security themes: Network / application / hardware security, standards, detection and reaction, governance, maintenance in security condition…

Figure 5 – Main security themes for an IoT project

Cet article A life cycle approach for IoT security est apparu en premier sur RiskInsight.

Pourtant, le volet IAM « Identity and Access Management » est souvent relégué au second plan dans les Programmes de mise en conformité LPM/NIS mis en œuvre par les Opérateurs d’Importance Vitale (OIV) / Opérateurs de Service Essentiel (OSE).

Comment comprendre cette situation et quelles leçons en tirer pour construire sa feuille de route IAM pour ses infrastructures critiques ?

L’IAM est un des piliers du volet cybersécurité de la LPM/NIS

Les mesures IAM à mettre en place sur les infrastructures critiques sont décrites dans les quatre règles suivantes :

Auxquelles il convient d’ajouter la règle portant sur les indicateurs (règle 20 pour la LPM et règle 4 pour NIS).

Les bonnes pratiques IAM habituelles à appliquer à tous les accès

Les exigences des trois premières règles reprennent les bonnes pratiques habituelles à appliquer à la gestion des comptes et des droits, tant pour les utilisateurs physiques que pour les processus automatiques accédant aux infrastructures critiques :

• Gérer le cycle de vie des utilisateurs, notamment les mutations et départs
• Affecter les droits selon le principe du moindre privilège
• Revoir (ou recertifier) régulièrement les droits affectés, a minima annuellement
• Contrôler et auditer les droits
• Attribuer des comptes et des moyens d’authentification strictement nominatifs

Le cadre ci-dessous résume les règles concernées :

Ces règles fixent un cadre mais laissent une grande liberté aux Opérateurs pour les décliner dans leur contexte.

Des comptes d’administration dédiés et soumis aux mêmes exigences

La quatrième règle (n°14 LPM et n°11 NIS) traite spécifiquement des comptes d’administration, destinés aux seuls personnels en charge de l’administration des infrastructures critiques : installation, configuration, maintenance, supervision, etc. L’exigence forte est la mise en place de comptes d’administration dédiés à la réalisation des opérations d’administration.

Au-delà du principe de moindre privilège explicitement mentionné, les comptes d’administration doivent respecter les mêmes exigences que les autres comptes telles que décrites précédemment.

Des indicateurs à produire pour surveiller les comptes à risque élevé

Enfin, la règle sur les indicateurs prévoit la définition de plusieurs indicateurs concernant la gestion des comptes présentant un niveau de risque élevé :

• Pourcentage de comptes partagés
• Pourcentage de comptes privilégiés
• Pourcentage de ressources dont les éléments secrets ne peuvent pas être modifiés

Au vu de ces exigences, l’intégration des infrastructures critiques dans les outils IAM (ci-après appelés « l’IAM ») de l’Opérateur apparaît comme la réponse nécessaire ; à compléter par l’application de mesures de durcissement (suppression, désactivation ou changement de mot de passe des comptes par défaut).

NB : les exigences LPM et NIS étant très similaires, nous emploierons par la suite le terme « OIV » pour désigner aussi bien les Opérateurs d’Importante Vitale et les Opérateurs de Service Essentiel, et le terme « SIIV » pour désigner les Systèmes d’Informations d’Importance Vitale et les Systèmes d’Informations Essentiels.

Pourtant, les Opérateurs hésitent encore à raccorder leurs infrastructures critiques à l’IAM

Les règlementations LPM et NIS ont accéléré la mise en place et le déploiement de solutions de bastion d’administration afin de sécuriser les accès d’administration. Cependant, bien que ces projets soient nécessaires, ils ne permettent de répondre que très partiellement aux exigences évoquées précédemment.

Ces règlementations devraient pourtant être un bon driver pour les projets IAM, mais les Opérateurs sont confrontés à deux principaux problèmes :

• La complexité d’intégration des systèmes industriels avec l’IAM – pour les Opérateurs industriels.
• Le risque induit par le raccordement des infrastructures critiques à l’IAM.

Des systèmes industriels complexes à intégrer

Les systèmes industriels présentent en effet des spécificités qui, d’une part complexifient le raccordement à un outil IAM, et d’autre part le rendent moins indispensable. Car, de façon générale :

• le nombre d’utilisateurs est limité ;
• ces systèmes sont cloisonnés, voire isolés du réseau d’entreprise ;
• la maturité sécurité des éditeurs et constructeurs est en retrait, les capacités d’interfaçage sont réduites, tant pour la gestion des comptes que pour la délégation d’authentification ;
• la granularité des droits d’accès est faible, se limitant souvent à autoriser l’accès ou non à l’ensemble du système, et non fonctionnalité par fonctionnalité.

Une intégration potentiellement génératrice de risques

Mais, au-delà de ces considérations propres aux systèmes industriels, les Opérateurs sont parfois réticents à mettre en place cette intégration, car elle est perçue comme génératrice de risques. En effet, si l’outil IAM ne présente pas un niveau de sécurité à la hauteur des règlementations, il pourrait paradoxalement constituer un point d’entrée sur les SIIV et ainsi amener de nouvelles vulnérabilités : création de compte ou attribution de droit illégitime, suppression malveillante de tous les comptes, etc.

Quant à mettre en place un IAM entièrement dédié au périmètre SIIV, cela représente un investissement très conséquent, parfois disproportionné, et qui ne permet pas de tirer tous les avantages d’un IAM mutualisé, par exemples les liens avec les sources autoritaires comme le SI RH.

Différentes approches d’intégration IAM permettent de répondre aux exigences règlementaires en maintenant un niveau de cloisonnement élevé

Dès lors, comment répondre efficacement aux exigences de la LPM et de la directive NIS ? Comment tirer parti des services proposés par les outils IAM sans ouvrir de nouvelle porte sur les infrastructures critiques ?

Nous distinguons différentes approches pour intégrer un système avec les outils IAM.

L’approche « délégation », à l’état de l’art mais fortement couplée

La première approche consiste à déléguer l’authentification et l’autorisation à l’IAM, en l’occurrence au service d’authentification et de contrôle d’accès, via un protocole de Fédération d’Identités (SAML2, OpenID Connect / OAuth2) ou via un raccordement Active Directory / LDAP.

Cette solution permet une gestion des comptes et des accès à l’état de l’art, mais rend le SIIV totalement dépendant de ce service et l’expose aux risques évoqués précédemment. Même en situation de crise, une isolation du SIIV serait difficilement envisageable.

Cette approche est donc plutôt à réserver aux applications qui fonctionnent déjà sur ce principe, typiquement les applications du SI de gestion avec un grand nombre d’utilisateurs. Pour les systèmes industriels, la solution à privilégier est de conserver le service d’authentification au sein du SIIV et d’opter pour une autre approche.

L’approche « provisioning », avec un niveau de couplage à ajuster au contexte

Cette approche consiste à conserver un système d’authentification et de contrôle d’accès propre au SIIV mais provisionné – c’est-à-dire alimenté – par l’IAM : les comptes et droits des utilisateurs sont stockés dans un référentiel interne au SIIV, et la solution IAM les gère au travers d’un connecteur. En fonction du niveau d’isolation souhaité, ce connecteur peut prendre différentes formes :

• Un connecteur automatique, permettant à l’IAM d’écrire directement les informations sur les comptes et accès dans le SIIV. Une isolation temporaire devient possible, en situation de crise ou en cas de détection d’activité anormale (par exemple : suppression massive de tous les comptes). Mais rien n’empêche un utilisateur malveillant ayant la main sur l’IAM de se donner accès au SIIV.
• Des ordres transmis aux administrateurs du SIIV (par ticket ITSM ou par mail) qui réalisent les actions manuellement. Un « sas » d’isolation est ainsi maintenu entre l’IAM et le SIIV, avec une étape de contrôle par les administrateurs.

Cette approche permet de bénéficier des processus de gestion des identités et des accès : validation et traçabilité des demandes d’accès, retrait des comptes et droits en cas de mutation ou de départ, etc. tout en préservant un degré de cloisonnement du SIIV.

L’approche « revue », orientée contrôle a posteriori

L’approche « revue » (également appelée « recertification ») se distingue des autres par le fait qu’elle repose sur une logique de contrôle a posteriori plutôt que de gestion a priori. Il s’agit cette fois d’analyser périodiquement les accès déclarés dans le SIIV afin de vérifier s’ils sont toujours légitimes. Cette vérification peut reposer sur un rapprochement des comptes avec un référentiel de collaborateurs (fichier RH, solution IAM, etc.), ou sur une validation explicite de la part des responsables des utilisateurs.

Ce peut être l’occasion de réaliser des contrôles approfondis (par exemple détection de combinaisons toxiques), de produire des indicateurs et des rapports d’audit.

Adapter son projet IAM – Infrastructures critiques à son niveau de maturité et à la typologie du SIIV

Sur la base de ces différentes options, nous proposons ci-dessous des pistes pour construire la feuille de route de mise en conformité LPM/NIS en fonction du niveau de maturité IAM et de la typologie des SIIV concernés.

Conserver la brique d’authentification et autorisation localement dans chaque SIIV

Il est préférable de conserver un référentiel de comptes et de droits d’accès localement dans chaque SIIV. Cependant, pour les systèmes déjà raccordés à un service mutualisé d’authentification et d’autorisation, le système mutualisé peut être conservé mais l’Opérateur doit lui appliquer les mesures prévues par la LPM et NIS : a minima le cloisonnement réseau, le durcissement, le maintien en conditions de sécurité, l’administration depuis un SI d’administration dédié, l’envoi des logs au SIEM, etc.

Dans un environnement de gestion des identités et des accès non mature, commencer par la revue des comptes et des droits

En l’absence d’outillage de gestion IAM mature, le moyen le plus rapide d’atteindre un premier niveau de maîtrise des risques et de conformité est de définir et mettre en œuvre un processus de revue régulière, sur une base a minima annuelle.

Sur un SIIV au nombre d’utilisateurs limité, le processus peut être déroulé manuellement, avec un niveau de qualité acceptable et une charge de travail raisonnable. Mais pour gérer des volumétries plus importantes, un outillage adéquat est à envisager : il facilite le pilotage des campagnes de revue et garantit la traçabilité des décisions. Il constitue en outre une opportunité pour envisager ensuite la mise en place d’un outil de gestion IAM.

Lorsqu’un outil de gestion IAM est en place, le sécuriser pour y raccorder les SIIV

Lorsque l’Opérateur dispose d’un outillage IAM mature, le provisioning des SIIV par l’IAM est recommandé : l’automatisation, la fiabilisation et la maîtrise que permettent les outils doivent compenser les risques induits par le couplage. A condition toutefois de garantir la sécurité de l’IAM : en complément des mesures techniques précédemment évoquées, l’Opérateur doit configurer l’IAM de sorte à ce que seuls les utilisateurs susceptibles d’accéder au SIIV peuvent demander l’accès, que le propriétaire du SIIV valide les demandes d’accès et puisse consulter facilement la liste des utilisateurs autorisés, et enfin que des contrôles permettent de détecter des anomalies sur les comptes et accès.

Le rehaussement de la sécurité profitera d’ailleurs à l’ensemble du Système d’Informations.

Trouver le bon équilibre risques / bénéfices pour construire son projet IAM – Infrastructures critiques

Ces propositions doivent permettre à tout Opérateur de construire sa feuille de route IAM pour ses infrastructures critiques en trouvant le bon équilibre entre les bénéfices apportés, les risques induits et le coût de mise en conformité.

Cet article Quelle approche pour gérer les identités et les accès sur les infrastructures critiques ? est apparu en premier sur RiskInsight.

Connected objects bring a whole range of new perspectives for the evolution of processes and working methods for businesses and users. Indeed, they are now able to interact with their environment to exchange information or perform actions. These interactions are characterized by relationships between corporate information systems, employees, end users and even other objects. To ensure the security of such exchanges, it is absolutely necessary to implement access control mechanisms which implies knowing and managing the identities of all connected objects of a fleet as well as their users.

This identity management discipline is well known within companies and linked to the IAM field (Identity & Access Management), that means the lifecycle management of the identities of employees and partners (traditional IAM) or end clients (Customer IAM). It must now be applied to the fleets of connected objects: it is the IAM of Things (IAMoT).

Figure 1 – Traditional IAM, Customer IAM and IAMoT: three strongly related fields

A connected object, yes… but to WHAT?

The interactions between a connected object and its environment can be grouped into 3 main categories.

1 – An object connected to the company’s IS

This is the first use case that comes to mind. Each object communicates with the IS via a unique identity that represents it and is associated to its access rights. This implies the implementation of principles for the creation, referencing, management, control and piloting of theses identities. We must know the condition of an object or the identity of its owner at any time.

In a standard technological chain such as “objects – relays – IoT platform – applications”, the IoT platform offers a central point for managing all objects identities.

In this context, it is also essential to manage the authentication of objects to applications, and therefore to define the principles of creating the secrets that will be used.

Figure 2 – Standard technological chain

2 – An object used by customers

For this type of object, appears a strong relationship with the Customer IAM field. Indeed, the object must be able to verify the user’s identity against the CIAM and determine the services to which the customer has subscribed.

In case of shared usage of the same object, a role and data model involving different types of end-users must also be considered.

Let’s take the example of a connected vehicle:

• The vehicle driver wants to use the GPS service. Before granting access to the service, the vehicle must answer many questions. What is the identity of the driver and what personal profile should I use (in order to load his previous rides for instance)? Is he the owner of the vehicle, the driver of a rental car, or has he borrowed it for a one-time use? Has the driver subscribed to the GPS services from the manufacturer and what is his level of service (routes calculation only, or also alerts for danger zones)?

3 – An object in interaction with the company’s employees and partners

Last use case, each object can interact with the company’s employees, service providers or partners. The relationship with the traditional IAM domain managing the authorizations and roles of the company’s partners and employees is therefore essential.

The use cases of an object require the creation of a role model to answer the question: which rights for which populations of users on which functionalities of the object?

Let’s take again the example of a connected vehicle:

• If repairs are needed, the mechanic must be able to view the latest vehicle’s operating indicators before the breakdown for diagnostic purposes. Is this garage part of the manufacturer’s network or independent? Is the mechanic allowed to access all GPS information or only the technical indicators of the engine? Can the customer consent or at least be informed of such access to his vehicle’s data?

This example also highlights that access rights may be closely linked to a time frame (only for the duration of the repair) or to the nature of the data (privacy protection of GPS data).

IAM of Things also means processes!

All IAM experts will agree: there is no IAM without a thorough study of the lifecycle of the identities involved. Our conviction is that IAMoT must study all the processes involving the object over its entire life cycle. Indeed, throughout the life of an object, the nature of interactions with its environment is likely to evolve according to its condition. For example, a brand-new object should be associated with its main user via a pairing process that ensures a level of trust consistent with the issues at stake…

Let’s use for the last time the example of the connected vehicle:

• A person has just acquired a second-hand connected vehicle from a private owner. In the context of this resale, it is necessary for the new purchaser to ensure that all accesses to services will be properly revoked for the previous owner. The detection of the resale event must therefore trigger a process of un-pairing the former owner.

Figure 3 – Ingredients for the IAM of Things recipe

The IAM of Things, a new discipline based on mastered concepts

This article highlights the identity management issue for the IoT and underlines the existing links with other fields of the IAM. It is important to keep in mind that even if the fundamental principles of the IAM also apply to the identity of connected objects, responses adapted to each project’s context must be carefully studied.

Cet article What is IAM of Things? est apparu en premier sur RiskInsight.

To avoid these costly consequences, companies are clearly concentrating on securing their critical IT infrastructures, but cyber-attacks are not only targeted at network vulnerabilities, datacentres and workstations. Users, whether internal or external to the organisation, are a prime target. Attackers usurp the identity of the targeted organisation to trick users in order to carry out their misdeeds.

The Company’s Digital Presence: A New Risk Factor

In recent years, companies’ digital transformation has been characterised mainly by exponential development of external communication via digital channels; means of communication have multiplied and become the privileged vectors of exchange and interaction, revolutionising the customer relationship and exchanges with partners. To remain closer to clients and partners companies promote the use of digital communication via:

• Emails
• Instant Messaging
• Institutional websites and Web applications
• Mobile applications
• Social networks

These media are the company’s showcase allowing it to portray itself, to expose and to radiate its brand image, via its own graphic impact, elements of language and messages. They personify the company and therefore refer directly to its perceived value. In addition, digitalisation has made it possible to largely substitute the physical relationship by digital services, accessible at any time and anywhere in the world, via which the company gives access to its community as well as its products and services, boosting ever faster, simpler and customised interactions with the users.

This heightened digital presence has enabled companies to develop their communication and the accessibility of their services, using digital channels to represent the company directly and fly its brand image flag. But there is a flip side to the coin: this digital ubiquity increases the possibility for attackers to usurp the company identity for malicious purposes.

Damaged Brand Image: the cyber-attack’s collateral damage

During a cyber-attack using spoofing of the company’s identity as a vector, the attackers’ intentions can be varied:

Some attacks aim directly to undermine the company’s credibility, to make the company appear incompetent, or to show the malicious group’s superiority imposing its antagonistic ideology:

Over the last few years, there have been cases of website defacing where the content of the pages has been changed to transmit false information and mock businesses in order to harm their image. In 2015, Lenovo paid the price when “hacktivist” group Lizard Squad attacked its website, redirecting visitors to photos of the attack’s protagonists. Attackers can also publish false information on a social network after stealing the Community Manager’s credentials. One defining moment of 2017 in France was the hijacking of the Ministry of Culture’s Twitter account by a joker distilling various abusive tweets. For the companies affected by these attacks, the financial consequences are as expected: following these events and announcements, the repercussions on sales and stock market value are always accompanied by a heavy impact on brand image.

In other cases, the attackers divert the company’s identity, this time seeking to steal money. In this case, the attackers pass themselves off as the company in order to commit frauds aimed directly at tricking the users:

• The “President scams” are steadily increasing and allow attackers to divert large sums of money by misleading employees in finance to believe they have to execute an urgent transfer for a company director. In France, the total damage caused by this fraud is estimated at more than 400 million euros per annum.
• Corporate employees are also the target of phishing campaigns, which can trigger a viral load contained in an attachment or a link from a seemingly familiar email. The goal may be to deploy a Cryptolocker to demand a ransom, or to gain a gateway into the organisation’s information system.
• Companies are also affected indirectly when phishing campaigns use their domain name to send fake emails to customers asking them to update their bank information or other personal data that may have value.
• The great novelty for collecting client data is via fake mobile apps imitating a legitimate application by their logo and interface but acting as a spyware when installed on the user’s smartphone. For example, a false WhatsApp application integrating malware was downloaded more than 1 million times on the Google Play store in October 2017.

In a digital world where customer confidence, increasingly sensitive to cyber subjects, is easily lost, protecting brand image has become a major issue for businesses, alongside protecting their IT infrastructure and data. But what are the best practices to put into place to limit these risks of usurpation?

Dedicated Solutions and Organised Monitoring for better protection

A company’s brand image protection of necessarily passes through the protection of digital communication channels. Depending on the type of channel, different action can be taken:

• Names of websites, email addresses and social network accounts similar to those of the company need to be monitored. This practice is recommended by the ANSSI (French Information Security Agency) to combat the brand usurpation, as well as the monitoring of the “Dark App Store” offering users pirated and potentially malicious versions of enterprise mobile applications.
• Carrying out regular audits and vulnerability scans on institutional sites and mobile applications allows the identification of vulnerabilities that could provide entry points during a cyber-attack. The necessary corrective measures can then be implemented to secure these media especially against defacing.
• Implementing multi-factor authentication for email and social network administrator accounts reduces the risk of spoofing by simply stealing credentials. This greatly limits the risk of malicious content being published or shared, or theft of sensitive data accessible via mailboxes, as was the case in 2017 for the firm Deloitte. In this theft, more than 5 million e‑mails containing sensitive exchanges with their customers were stolen, following the theft of one of the administrator’s credentials
• Activating protection such as SPF, DKIM or DMARC protocols can prevent the spoofing of company email addresses. In fact, these protocols protect the company’s domain names by declaring the IP addresses legitimate for sending emails and implementing signature mechanisms for emails to certify them. These protocols ensure that the company’s domain name cannot be used from an undeclared server.

Since digitalisation has favoured exposure of enterprise identities, cyber-attackers and hacktivists therefore take advantage to attack the companies and their ecosystem by posing as the company. In all these attacks and frauds, the attacker uses more or less complex means to usurp the company’s identity to attack and to weaken it. A damaged company brand image, for its customers but also for the general public, can cause financial losses of millions of euros, added to which are the huge losses that an attack crippling the company’s information system generates.

The subject of protecting companies’ digital identity, in whatever form, needs addressed so that they can protect themselves against the frequent and costly usurpation of which they are victims.

Cet article Protecting Company Identity: Digitalisation’s New Challenge est apparu en premier sur RiskInsight.

In recent years, companies have faced an expansion in the scope of Identity and Access Management (IAM) activities. They no longer concentrate solely on user provisioning and authentication; focus has shifted toward both account review and certification and the use of identity federation mechanisms (for example, SAML). The changes affect both SaaS and those that remain in-house. These two developments mean that ISs have an ever-broader scope—and it’s vital that they are implemented properly to minimize security vulnerabilities.

These developments in IAM are running in parallel with more widespread use of cloud services, which are continually being used in new ways to increase the scope and flexibility of IS access and use. Internal users accessing an IS are increasingly doing so from outside the corporate network—and from an increasingly diverse range of devices.

In addition, new Agile and DevOps technologies are forcing ISs to evolve in a different direction: integrating new technologies (IoT, etc.) and new uses, much more rapidly.

Today, all these developments make an IS one “bubble” among others, interacting with its environment and remotely controlling interactions between decentralized components.

…MAKING APIs ESSENTIAL

This new, decentralized IS model raises the problem of the interconnection of services and applications: How can you ensure a controlled access to data at all times—and in all places?

Today, APIs are already a predominant and essential communication mechanism for any company embracing digital transformation. They are used to process not only public data (branch addresses, transport timetables, etc.) but also personal data (for example, fitness tracker, health insurance, and government benefits apps) and sensitive data (online payments, e-commerce, mobile industrial information, etc.).

And, given their importance to ISs, the challenge of securing APIs becomes more important than ever.

WHAT’S THE RIGHT RECIPE TO SECURE YOUR APIs?

Securing APIs requires a recipe based on four ingredients, all of which must be carefully measured out.

THE SECURITY AS USUAL BASELINE

In a Wavestone benchmarking exercise on web application security, of the 128 applications we audited, serious flaws were observed in 60%. In this respect, and since APIs are just a kind of web applications, the standard web-security recommendations – for example those for OWASP – Open Web Application Security Project, must be taken into account in just the same way.

Essentially, this ensures that a web application’s main areas of risk are covered, and the appropriate security measures determined.

A pinch of OAuth

OAuth is an authorization delegation framework that allows an application to obtain permission to access a resource on behalf of a user.

OAuth2 is designed to cover a wide range of use cases (web applications, mobile, access [or not] via a browser, server-to-server access, etc.), and, to this end, it offers four main process flows to obtain a token (RFC 6749). Together combined with a specification detailing the use of this token (RFC 6750), a document detailing the threat model (RFC 6819), and a dedicated authentication overlay (OpenID Connect), results in a body of documents that runs to some 250 pages, leaving room for a broad range of implementation options and choices.

What’s more, it’s this abundance of options—and lack of constraints—that lead to the security flaws regularly observed in the implementation of OAuth2.0: the misuse of an application, access to personal data of a third-party user, the theft of Facebook/Google cookies when logging in using social media, or the compromise of a user’s account.

The following six recommendations are essential in ensuring the framework is securely implemented:

• Local storage of secret information: The client application is provided with identifiers enabling it to authenticate itself with the OAuth server; so, don’t put this secret information (the service identifier) in the mobile application; and, if you do, consider it compromised
• Redirected URLs: Validate redirected URLs strictly with the application, without the use of wildcards
• Implicit: Avoid implicit grant as far as possible (and strictly reserve it to client-side javascript applications)
• Authorization codes: Validate authorization codes strictly, as well as the associated clients
• State and PKCE: Use these to ensure the integrity of the entire series of process steps
• Authorization ≠ Authentication: Use OpenID Connect to authenticate, but OAuth to delegate access

LIMIT THE ADDITIVES

As soon as this first pinch of OAuth has been swallowed, you need to start thinking about the security measures to meet the most frequent needs.

The Single Sign-On mobile… or, how to enable mobile employees or clients to easily access multiple applications without reauthenticating?

It might be a field agent in a customer-facing role, or making a series of interventions at different sites, all while using a good dozen of applications every day; or it might be a client who’s installed several applications on the public app store and needs to access them all, without having to reauthenticate on each… Today, these are all very common scenarios. Although, since 2008, the techniques that make it possible have varied depending on the possibilities offered by the mobile OS (iOS’s KeyChain, URL parameters, Mobile Device Management, etc.), Apple and Google converged toward a common solution in 2015: the use of the browser system as an anchor point for an SSO session. This is now officially good practice, formalized in “Best Current Practice – OAuth2 for native applications.”

Contextual authentication… or, how to match the access level to the data, according to its criticality

One of the many issues concerning authentication is to simplify, as much as possible, user access to data, while still guaranteeing satisfactory levels of security. Contextual authentication provides an answer to this issue, adapting the level of access to the nature of the transaction: its characteristics, user habits, context, and so on. This is termed LOA (Level of Assurance). A mobile banking application, for example, allows the user to access their bank account, and see account balances, without having to reauthenticate each time these are accessed. However, the application will require authentication when performing a sensitive operation (transferring money between their own accounts, for example), and strong authentication when performing a very sensitive operation (adding an external recipient for a transfer, for example).

The market now offers solutions designed according to a logic where the application client is responsible for initiating the LOA request that corresponds to the data or service it requires. But the real need is to define and apply these data access policies at a single point within the authorization server. This is essential when there’s a need to apply an authentication proportionate to the level of risk (geolocation, is it a known terminal or not, transaction habits, etc.).

Identity propagation… or, how to pass an access token between two (or more) applications.

It is increasingly common that a call to an API triggers a cascade of calls to other APIs, in particular within a micro-service-type architecture setting. The transmission of the identity of the user must then be assured while still maintaining security. And the first three solutions that come to mind have limitations:

• The transmission of the initial token is obviously to be avoided, in view of the very high risk of internal fraud involved.
• Caller authentication alone is not enough either, because a compromised link in the chain can result in the theft of any user’s identity, thus compromising the rest of the chain.
• The generation of a caller token, transmitted along with the initial user’s token, does not assure the integrity of the user/API combination, and does not validate the chain.

However, an advanced initial solution does currently exist, in the form of a new grant type: Token Exchange. This mechanism allows the caller to request an intermediate token, which includes the identity of the user, the caller, and the call chain already made. This new series of process steps makes it possible to centralize the calls policy between micro-services, as well as its application, thereby ensuring the traceability of calls.

Protecting against token theft… or, how to guard against the theft of a token base?

As a rule, the token contains a good deal of information about its holder, entailing significant risks if stolen. More striking still is the fact that, in some contexts (for example, new standards on electronic payments such as those in the modified European Payment Services Directive [PSD2]), a third party (aggregator) may be in possession of many tokens, and the owner of the API is then effectively at the mercy of this third party and its level of security. Because theft is very difficult to detect, there was a need to find other solutions such as Token Binding: a negotiation mechanism using two or three components to link a token to a pair of cryptographic keys, and where the client must prove that it owns the private key that makes up part of this pair by establishing a mutual TLS connection with the API.

WRITING THE RECIPE DOWN

What’s the last ingredient of the recipe? The need to set out a reference architecture for OAuth in order to adapt it to the context of the company’s IS. To do this, the API framework must be defined, by:

• Defining and sharing the security rules: The authorized process steps and the application framework, the security checklists, and the reference architecture must all be formalized.
• Training and equipping developers: There will be a need to organize training sessions, and presentations on the principles to adopt. Project teams can be made autonomous in terms of their integration with the rest of the IS.
• Integrating security resources into Agile sprints: The resources that act as a “security coach” must be identified in order to support the application design, provide ready-to-use solutions, and serve as an accelerator.

IN SUMMARY

In summary, rather like the recipe for a good soup, securing APIs requires a list of ingredients, ranging from the most basic to the most sophisticated, while keeping the needs and context firmly in mind.

Cet article What’s the right recipe to secure your APIs? est apparu en premier sur RiskInsight.

In the context of IAM, organisations have traditionally focused on managing identities and controlling who accesses what (and how).

In terms of identity management, organisations first focused on automation of provisioning tasks and other low value tasks. The focus then gradually turned to access rights request and approval processes. More recently, organisations have turned their attention to accounts and access rights review and recertification.

In terms of access control, organisations have migrated from centralised authentication (e.g. in a shared directory) to delegated authentication (e.g. to a Web Single Sign-On (SSO) solution). We are now at a stage where authentication is standardised with identity federation protocols (e.g. SAML) equally applicable to SaaS applications as internally hosted applications.

In recent years, information systems have opened up to the Internet while at the same time their authentication has become more standardised: organisations must now contend with SaaS, IaaS, external Information Systems (IS) access by partners and clients, a mobile workforce and mobile applications. And IAM professionals have devised solutions for these new use cases without necessarily challenging the fundamental principles of the existing paradigm. In effect, the market has witnessed a gradual evolution. And whilst we are currently experiencing a relatively calm state of affairs, major change is brewing.

Figure 1: 2005-2015 – an opening of the Information System under control

The evolving ‘IS’ landscape influencing IAM

The IS landscape is undergoing a new wave of transformation;

Driven by Cloud adoption, we are heading towards further adoption of SaaS, majority use of IaaS relative to historic datacentres, real adoption of PaaS (in the form of containerised applications and server-less apps), and ever increasing remote access by employees. There is also a surge in the number of end-points accessing information systems (more customers whose interactions are digitalised, Internet of Things, OpenData, etc.).

And driven by new agile methodologies and DevOps, information systems no longer evolve in the same way. Development and deployment cycles have been considerably shortened and interactions between business lines and IT are less confrontational than they used to be. These new methods are increasingly the norm and it is difficult to resist them.

Although IAM’s primary goal has not changed much, namely controlling who accesses what in the IS, there will be many more variants of “who” and “what” in the future. Core IS will be merely one “bubble” among others (refer to diagram below) interacting with its wider environment and remotely controlling interactions between decentralised components.

Figure 2: A decentralised Information System

7 factors shaping the future of IAM

IAM must find its sweet spot in a new environment where the requirements of business lines drive technology innovation. The business lines might even impose technology solutions onto IAM teams.

In predominantly cloud-based architecture, IAM must demonstrate control over this dynamic and bring added-value to this new world.

There are seven key factors that will shape the future of IAM; three of which relate to the needs of the business lines and four of which are new IAM challenges.

Agility

Business lines now expect to offer new products and services in ever-shorter timeframes. This poses two parallel challenges for IS:

1. Maintaining quality of service for existing business line products, and
2. Adapting to meet the need of new business line products.

This is an opportunity for IS to move away from a monolithic IAM framework that is often complex to implement and very difficult to handle by embracing a lighter architecture to support the new business demands (e.g. micro-services).

Client Identity Management (Customer IAM or CIAM)

Digital transformation is driving the business lines to interact with their customers in many new ways and through ever more channels.

A flawless user experience and the simplification of the customer journey are required. Optimisation of customer acquisition and churn rates become key indicators for CIAM to address.

Internet of Things (IoT)

Whether an organisation is building connected objects or offering services on top of them, a number of questions will become unavoidable:

• How to ensure that the object I am communicating with is the one it purports to be? Is it important to be absolutely certain?
• How to scale the IS to manage the growing volume of deployed objects?
• How to ensure end-to-end security?
• What object lifecycle should we anticipate?

These are fascinating questions which force us back to the drawing board to consider different hypothesis beyond the usual IAM framework.

Identity as a Service (IDaaS)

As we predicted a few years ago, the criteria for exporting IAM to the cloud is no longer restricted to security considerations. Equally important questions are: do I really need to do it? how will I benefit?

Although the IDaaS market is still in its infancy, with current offerings only partially covering the IAM spectrum, all indicators suggest the IAM offering of the near future will plug the gaps in the form of on-premises provisioning, rights requests and approval, identities governance, and more. What remains to be seen is whether identity management and access control will be packaged together or offered by separate providers and which provider(s) will be the most reliable.

Application Programming Interface (APIs)

APIs already represent a vitally important communication medium for any company committed to the digital transformation journey: exchange with partners, mobile applications, client-side applications, OpenData, etc.

Despite perceived gaps compared to web-service standards from previous years (in particular in the eyes of WS-* suite nostalgics), it is necessary to embrace the REST/JSON wave, to dive into Oauth2 and to bring up the API first topic in all your projects.

Standards

The fight between standards is eternal. Any standard used today is destined to be challenged and replaced later by another. However, this does not prevent good standards from emerging which, if adopted, can enable a correct response to IAM issues.

On the topic of access control, several standards and protocols for authentication, as well as propagation of authentication, are mature and already adopted by a large share of the market.

FIDO (Fast ID Online), U2F (Universal 2^nd Factor) and OpenID Connect are amongst the most promising standards in terms of their adoption rate, the maturity of the underlying technologies and the players who have collectively created them.

Identity & Access Intelligence

This is probably the most exciting and fast moving IAM area. Machine learning algorithms, detection of weak signals, neural networks and other emerging technologies can lead to new use cases linked to user (or object) identity and behaviour. Examples include pre-emptive fraud detection and risk anticipation, even “closing the door” before someone attempts to enter. Whilst there is an element of science-fiction to some of the scenarios presented by vendors, this is nonetheless a vibrant and highly promising market.

Figure 3: 7 factors shaping the future of IAM

Conclusion

Identity and Access Management (IAM) is developing at a fast pace as a result of new technology developments, digital transformation and the evolving cyber threats. Large organisations need to review their IAM strategy to take into account the current and future requirements of a digitally enabled business. Instead of focusing on “point” solutions to address these challenges one at a time, organisations need to take a more considered and holistic view of developments. An effective strategy can transform your IAM platform into an asset that enables mobility and productivity whilst also helping to overcome security challenges and integrate future IAM demands.

Cet article 7 drivers transforming Identity & Access Management (IAM) est apparu en premier sur RiskInsight.

Dans ce contexte, la grande majorité des entreprises a mené des projets d’IAM : les accès aux applications sensibles sont étroitement contrôlés et les niveaux d’accès sont restreints selon les profils des utilisateurs et les actions à réaliser.

Or, trop souvent, ces démarches IAM « oublient » les populations IT qui ont pourtant des accès privilégiés sur l’infrastructure de l’entreprise. Et pour ces derniers, plusieurs spécificités sont à prendre en compte.

Les utilisateurs IT ont des besoins d’accès différents

Les utilisateurs « non-IT » représentent les utilisateurs « standards » du SI : utilisateurs des directions métier ou des fonctions support comme RH, paie, ou comptabilité… Ils accèdent classiquement :

• Aux applications en environnement de production,
• Et via les IHM standard de celles-ci.

Les populations « IT » (service informatique interne, télémaintenance, support…) ont quant à elles des accès très différents :

• Elles opèrent les infrastructures (serveurs, bases de données), et le code applicatif, sur lesquels reposent les applications ;
• Elles accèdent à tous les environnements et en particulier production et hors-production (ces derniers contenant souvent des données de production ou à caractère sensible ou personnel) ;
• Très souvent, elles opèrent avec des niveaux de droits (des « privilèges ») très élevés, présentant donc un niveau de risque non négligeable.

Ainsi, la terminologie « accès à privilèges » désigne tout accès technique, sur une infrastructure ou une brique logicielle, dans des environnements de production ou hors-production.

Ces accès sont parfois créés pour des individus, ou pour les applications elles-mêmes (une application a besoin de plusieurs comptes techniques, comme pour écrire dans une base de données).

On distingue différents niveaux d’accès « à privilèges ». Les plus critiques, de niveau « administrateur », offrent un contrôle total d’un ou plusieurs serveurs, et donc potentiellement plusieurs applications. Les accès IT de niveau « standard » sont moins sensibles mais restent à surveiller. Ces derniers pourraient permettre, par exemple, de consulter des informations sensibles dans une base de données.

Accès IT, risques métier

Par définition, la maitrise des accès privilégiés des populations IT doit être au cœur des préoccupations des entreprises.

Parmi les risques les plus importants, nous retrouvons :

• Les risques opérationnels, sans impact sur la production

Exemple : des traces d’exploitation sont supprimées par erreur ou un serveur non critique est éteint.

• Les risques sur l’activité de l’entreprise

Exemple : indisponibilité de la plateforme de flux des paiements / transaction suite à un redémarrage des serveurs par erreur.

• Les risques de non-conformité aux régulations

Exemple : mise en évidence d’un accès non-justifié sur un périmètre régulé suite à un audit interne.

• Des actions frauduleuses

Exemple : délit d’initié commis grâce à une information sensible consultée directement depuis une base de données.

Sans compter les risques plus larges autour du système d’information : vol de données, ransomwares et autres actions malveillantes. Parce qu’ils sont puissants (et permettent notamment de désactiver les mesures de sécurité), les accès à privilèges sont des cibles de choix en cas de cyber-attaque.

Aujourd’hui, la plupart des responsables d’application sensibles sont en mesure de rendre des comptes quant à l’usage des accès métier dans leur application. De la même manière, les responsables d’application et les responsables d’infrastructure doivent pouvoir répondre à des questions simples telles que :

• Qui utilise réellement des accès à privilèges sur mon périmètre ?
• Combien de comptes à privilèges existent sur mon périmètre ?
• Les mots de passe de ces comptes sont-ils changés régulièrement ?
• Quels sont les niveaux d’accès nécessaires pour mon application ou mes services, et qui ne peuvent pas être retirés sans conséquence pour la production ?

Plusieurs particularités à prendre en compte

Avant de se lancer dans un projet de mise sous contrôle des accès à privilèges, il est bon d’avoir conscience de certaines spécificités qui ne s’appliquent pas pour les accès métier.

À commencer par le cycle de vie de certains accès à privilèges. Dans le monde des accès métier, le cycle de vie est lié au statut RH de leur unique propriétaire. Mais dans le monde IT, il existe des accès partagés entre plusieurs personnes (pour des besoins opérationnels spécifiques), ou bien qui sont utilisés par l’application elle-même pour fonctionner. La durée de vie de ces accès-là est plutôt liée à la durée de vie de l’application concernée, ou bien parfois à la durée d’un projet.

Certaines contraintes opérationnelles sont aussi à prendre en compte. Notamment en ce qui concerne :

• La gestion de la production, qui ne souffre aucun délai. Dans le monde des accès métier, les niveaux d’accès sont généralement liés à la fiche de poste des utilisateurs, et c’est aussi le cas pour les populations IT. Mais dans certaines circonstances, les utilisateurs IT doivent pouvoir obtenir de nouveaux accès sans délai. Par exemple, en cas de panne d’une application critique, les équipes IT doivent pouvoir intervenir au plus vite avec toute la latitude nécessaire. Ce qui peut nécessiter des élévations de privilèges. Dans ce contexte, des processus de validation seraient trop longs (avec validation du responsable hiérarchique, puis éventuellement un autre niveau de validation…). Une autre approche peut consister à autoriser ce type de demande sans validation préalable, mais tracer et contrôler à posteriori l’usage qui a été fait de cet accès.

• Le grand nombre de ressources cibles. Certaines applications reposent sur un grand nombre de serveurs de production, et au moins autant de serveurs hors-production. Des applications peuvent aujourd’hui créer ou supprimer des serveurs virtuels à la volée, en fonction de la charge. Dans ce cas, il serait vite ingérable d’imposer aux utilisateurs des demandes d’accès pour chaque ressource cible. Une solution peut consister à gérer des demandes d’accès à des groupes de ressources (par exemple un groupe Active Directory qui représente tous les serveurs de production d’une application, lequel groupe pourrait même être déployé automatiquement sur les nouveaux serveurs par un orchestrateur).

Surtout, l’hétérogénéité de l’environnement peut rendre le modèle d’accès complexe. En effet, articuler la gestion des accès à privilèges autour d’un modèle cohérent, implique de composer avec :

• Des serveurs qui hébergent parfois plusieurs applications. Dans ce cas, un besoin d’accès à une seule application se traduit, en pratique, par des accès indus à plusieurs applications. Dans le cas d’applications critiques, il vaut donc mieux investir dans des serveurs dédiés (virtuels ou non, face aux risques portés par les administrateurs des plateformes de virtualisation).

• Des ressources hétérogènes avec leurs propres particularités. Serveur Windows, Unix, base de données Oracle, middleware Tomcat, des équipements réseau, voire des conteneurs comme Docker… La liste des technologies à prendre en compte est longue.

• Pour une même ressource, différents comptes à créer. Un utilisateur peut souvent intervenir sur une même ressource via différents moyens. Pour un même serveur, on pourra offrir la possibilité de s’y connecter directement (protocoles SSH, RDP…), via l’intermédiaire d’un serveur de rebond (et dans ce cas, c’est sur ce serveur qu’il faut créer un accès utilisateur), ou encore via une interface logicielle d’administration (c’est d’ailleurs la voie du DevOps).

• Des populations hétérogènes et des besoins qui évoluent rapidement. Le modèle d’accès est difficile à uniformiser, notamment parce que différents types de population, comme des administrateurs d’infrastructures ou des développeurs, ont des besoins différents. Par exemple, un administrateur Windows opère tous les serveurs Windows, quelle que soit l’application, alors qu’un développeur intervient sur plusieurs technologies dans la limite d’une application. Mais il est aussi difficile d’uniformiser le modèle d’accès pour une même population, car les développeurs de 2 applications différentes peuvent avoir des besoins différents.

Les accès à privilèges : un challenge pour la sécurité ?

Accès standards métier et accès à privilèges sont les 2 faces de la même pièce. Et les accès à privilèges en sont la face sombre, car ils sont à la fois plus sensibles et techniquement plus complexes à gérer.

Face à cet état des lieux, la prise de conscience des entreprises est inégale. Les mieux informées sont les équipes techniques IT qui utilisent les comptes à privilèges, et qui sont souvent favorables au statuquo.

Au-delà de la Direction des systèmes d’information, ce sont les Directions en charge des processus internes, de la qualité ou encore le contrôle interne, qui ont un rôle clé de sponsoring à jouer.

Le législateur, lui, commence aussi à s’y intéresser. Ainsi la Loi de programmation militaire, qui concerne les opérateurs d’importance vitale, impose une mise sous contrôle des accès à privilèges les plus critiques.

Mais alors comment s’y prendre, pour mettre les accès à privilèges sous contrôle ? Nous y reviendrons dans un prochain article.

Cet article Accès à privilèges : la face sombre de l’IAM est apparu en premier sur RiskInsight.

VERS UN CADRE COMMUN

Bien qu’aujourd’hui le règlement reprenne la majeure partie des dispositions de la directive qu’il abroge, il y apporte cependant quelques modifications, et de nouvelles dispositions, renforçant ainsi cette reconnaissance européenne des services de confiance. Le règlement détermine notamment :

• Les conditions dans lesquelles un État membre reconnaît les moyens d’identification électronique des personnes physiques et morales qui relèvent d’un schéma d’identification électronique notifié d’un autre État membre ;
• Les règles applicables aux services de confiance, en particulier pour les transactions électroniques ;
• Le cadre juridique pour les services de signatures électroniques, de cachets électroniques, d’horodatages électroniques, de documents électroniques, d’envoi recommandé électronique et les services de certificats pour l’authentification de site internet.

Contrairement à la directive 1999/93/CE, eIDAS est un règlement, il n’y a donc pas de transposition nationale, le texte est applicable pour l’ensemble des États membres.

VERS UNE HARMONISATION EUROPÉENNE : LES POINTS CLÉS

Le règlement introduit un certain nombre de nouvelles notions, parmi lesquelles on peut noter :

• L’acceptation du document électronique en tant que preuve devant la justice;
• La création d’un label de confiance pour un marché plus transparent ;
• L’encadrement des méthodes de validation de signatures qualifiées par le biais de prestataires de services de confiance ;
• Le service de conservation qualifié des signatures électroniques qualifiées pour garantir la fiabilité des signatures et donc leur valeur dans le temps ;
• L’horodatage au niveau européen permettant une reconnaissance de la datation et de l’intégrité de données numérique et donc de la validité juridique du document dans toute l’UE ;
• L’obligation pour les États membres de maintenir des listes de confiance des services et prestataires qualifiés et labélisés à disposition du grand public ;
• L’assouplissement de la signature sécurisée : reconnaissance de la signature créée à distance par un tiers de confiance au nom du signataire pour faciliter les usages en mobilité.

Parmi les autres points remarquables, nous pouvons citer l’apparition d’un nouveau principe juridique : la signature électronique de personne morale. Le cachet électronique permettra donc aux entreprises et administrations de signer électroniquement en leur nom des documents afin de certifier leur provenance. Concrètement, un juge français ne pourra pas refuser un cachet ou une signature électronique apposé par un italien avec une solution allemande. Enfin, nous pouvons également souligner l’introduction de la notion de signature qualifiée côté serveur, ce qui permettra otamment le développement de nouvelles offres (en SaaS), objectif clairement affiché de ce nouveau règlement.

eIDAS définit ainsi une graduation en 3 niveaux de signature de personne physique, synthétisé dans le tableau ci-dessous, contre 2 niveaux anciennement pour la directive.

3 niveaux de signature physique

L’Europe s’intéresse à l’adoption de ces technologies dans les pays membres

Les autorités européennes, en particulier la direction générale de l’informatique (DG DIGIT) en charge des 4 piliers fondamentaux que sont l’eInvoicing, l’eDelivery, l’eSignature et l’eID, ont souhaité évaluer concrètement les forces en présence dans chaque pays. À ce titre, ils ont fait réaliser par Wavestone Luxembourg un sondage et organisé des groupes de travail à l’échelle européenne pour identifier les acteurs présents sur le marché et leurs besoins. Les différentes solutions pour stimuler l’adoption de chacun de ces piliers fondamentaux ont été analysées et discutées avec l’ensemble des acteurs. Résultats à venir !

Cet article Nouveau règlement eIDAS : en route vers une Europe de la confiance numérique est apparu en premier sur RiskInsight.

Touch ID, un lecteur d’empreintes simple et plus sûr

Selon Apple, Touch ID est plus sécurisé qu’un code à quatre chiffres : la probabilité que le capteur confonde deux empreintes digitales est de 1 sur 50 000 et elle augmente à « 1 sur 10 000 lorsqu’un utilisateur non autorisé devine un code d’accès à 4 chiffres ». Il faut néanmoins préciser que ces deux chiffres ne sont pas réellement de même nature car le premier représente une probabilité de fausse détection tandis que le second correspond à la probabilité de trouver le bon code de déverrouillage, et donc de pouvoir se ré-authentifier par la suite.

Utiliser Touch ID est également relativement simple. Lorsque le doigt est apposé sur le bouton d’activation de l’écran d’accueil, une photographie haute résolution de l’empreinte digitale est prise, puis comparée à un gabarit référence généré au moment de l’enregistrement de l’utilisateur. Concernant la confidentialité de ces données, la documentation technique précise que lors du processus d’enregistrement, c’est la modélisation mathématique de l’empreinte digitale qui est hébergée dans l’enclave sécurisée du processeur, au plus proche du capteur, et non les empreintes digitales des utilisateurs.

Un capteur biométrique aux usages multiples

Avec le lancement de l’iPhone 6 et d’iOS 8, les usages évoluent. Jusqu’à présent, le capteur permettait uniquement de s’authentifier et de payer ses achats sur l’Apple store, l’iTunes Store et l’iBooks Store. Désormais, l’arrivée d’Apple Pay permet de réaliser tous types d’achats en validant ses paiements via Touch ID, notamment grâce à l’intégration d’une puce NFC (pour le moment, Apple Pay n’est disponible qu’aux États-Unis). Il devient également possible de sécuriser l’accès à des applications tierces.

Les nouvelles fonctionnalités que pourraient offrir ces capteurs biométriques sont nombreuses, telles que déverrouiller une voiture ou effectuer un virement bancaire. La question de la sécurité devient donc cruciale.

Performances et limites de Touch ID

En dépit des tests et des études montrant que cette technologie est robuste et que les taux de faux positif et de faux négatif restent bas, Touch ID possède quelques limites.

L’authentification peut être avortée si le lecteur biométrique porte des traces de poussières, de graisse…Le capteur est également insensible à la chaleur corporelle et ne fait donc pas la différence entre la peau et les corps inertes. Enfin, comme pratiquement tous les lecteurs d’empreintes digitales, il est possible de le piéger. De nombreux experts en sécurité ont posté des vidéos montrant leurs tentatives réussies de piratages à partir de fausses empreintes digitales. Le « Chaos Computer Club » a ainsi réussi à tromper Touch ID en photographiant en haute résolution une empreinte digitale et en moulant cette dernière.

Nous avons, nous aussi, voulu tester la fiabilité de cette technologie avec de fausses empreintes digitales réalisées en gélatine alimentaire et en colle à bois. Le processus est fastidieux et les résultats varient en fonction de la qualité des copies et de leur fidélité par rapport à l’originale, mais nous sommes bien parvenus à déjouer le capteur biométrique.

Ainsi, une personne mal intentionnée pourrait parvenir, moyennant de nombreux efforts, à s’authentifier sur les appareils utilisant la biométrie par Touch ID. Cela implique cependant de pouvoir récolter une empreinte digitale nette, claire et épaisse qui puisse être facilement dupliquée, ce qui est au quotidien difficile à trouver.

Des évolutions dans le futur ?

Simple d’usage et efficace, la technologie Touch ID est une belle avancée pour la sécurité des terminaux mobiles. Malgré ses limites, les usages cités précédemment (accès aux données personnelles sur les terminaux, paiements mobiles…) ne devraient théoriquement pas souffrir de problèmes majeurs de sécurité pour le grand public.

Cependant, pour des populations sensibles ou dans des contextes à risques, il faut avoir conscience des limites concrètement démontrées. Il aurait été souhaitable que la sortie de l’iPhone 6 améliore de façon notable la sécurité et les performances du capteur biométrique. Malheureusement, à part une plus grande sensibilité impliquant une diminution du taux de faux négatifs (la résolution du capteur étant plus grande), il n’y a pas eu de modifications substantielles. Dans le futur, une approche combinant l’empreinte et un code pourrait être une évolution intéressante et simple à mettre en œuvre.

Enfin, si l’on souhaitait renforcer la sécurité de manière significative, on aurait pu s’orienter vers des technologies biométriques « sans traces » (réseau veineux, reconnaissance d’iris…etc). Mise à part l’usabilité de la plupart de ces technologies qui ne permet pas à l’heure actuelle de les intégrer sur un smartphone, la question essentielle est de savoir si le grand public est prêt à les accepter et à les utiliser. Affaire à suivre…

Cet article Touch ID marque-t-il la sécurité de son empreinte ? est apparu en premier sur RiskInsight.

Des tentatives infructueuses

La carte d’identité nationale électronique sécurisée est un projet d’identité numérique français datant de 2003. Cette carte d’identité devait contenir des informations biométriques. Ces données devaient également être conservées dans un fichier centralisé, solution perçue comme une atteinte aux libertés individuelles par nombre d’associations. Le projet a été arrêté puis relancé à de nombreuses reprises jusqu’en 2012. Le Conseil constitutionnel donna alors un coup d’arrêt définitif au projet en le censurant.

En parallèle, certains citoyens français ont pu expérimenter l’utilisation d’un certificat électronique « pour un usage unique » dans le cadre de leur déclaration d’impôts en ligne. L’expérimentation a finalement été abandonnée en raison de processus jugés trop complexes pour les utilisateurs (notamment lors d’un changement d’ordinateur) et trop coûteux pour le fournisseur (notamment en matière de support aux utilisateurs).

En 2010, un nouveau projet d’identité numérique, baptisé IDéNum est lancé. Deux ans plus tard, peu d’avancées concrètes à constater, sans qu’aucune raison officielle ne soit donnée.

L’échec des précédents projets gouvernementaux n’a cependant pas découragé les initiatives privées. Ainsi, La Poste propose un service de courrier recommandé en ligne, via une identité numérique baptisée « IDN ». Les informations personnelles sont vérifiées via plusieurs mécanismes, notamment la présentation d’une pièce d’identité à domicile à un facteur. Son utilisation reste cependant limitée à cet usage très ciblé.

2013 : un nouvel envol ?

Le gouvernement tente de relancer le projet IDéNum depuis début 2013. Le projet, financé par un partenariat public-privé, doit permettre de « préserver notre souveraineté nationale face aux alternatives étrangères et non sécurisées ».

Le projet adopte une approche innovante : garantir la fiabilité des Identités émises sans imposer l’État comme autorité de confiance. Ainsi, IDéNum devrait proposer un ou plusieurs « labels » reprenant des critères de qualité, de confidentialité, d’interopérabilité ou encore de contrôle fixés par l’État. Charge aux fournisseurs d’Identités privés de répondre à ces critères pour être labélisés et ainsi pouvoir émettre des Identités numériques fiables et reconnues.

Cette identité numérique devrait permettre d’accéder aux services administratifs de l’État, et plus largement à n’importe quel service privé qui y aura souscrit. C’est donc bien le « label » qui porte le niveau de fiabilité associé à l’identité numérique. D’où, peut-être, la possibilité de promouvoir plusieurs labels, correspondant à des critères de qualité différents, et adaptés à différents usages. Le « label » devrait aussi définir les « droits et devoirs » des fournisseurs de services souhaitant utiliser IDéNum. Ainsi, il permettrait d’encadrer l’usage et la diffusion des données recueillies.

Caractère universel, maîtrise de ses informations personnelles et fiabilité : 3 conditions de succès

Quels que soient les choix retenus, trois points cristallisent la relation à l’objet « identité numérique », et donc son futur niveau d’adoption : le caractère universel de son usage, la confiance de l’utilisateur dans le système – matérialisée par la maîtrise de ses informations personnelles -, et la confiance des fournisseurs de services utilisant ce même système, matérialisée par la fiabilité des informations.

Le caractère quasi universel d’une identité numérique – c’est-à-dire la possibilité de l’utiliser pour tout, tout le temps sans limite ni contrainte – est une condition sine qua non à une adoption de masse. Aussi, la question de l’interopérabilité, avec fournisseurs de services et entre pays, est primordiale. Le projet se doit donc d’emporter l’adhésion de nombreux acteurs publics comme privés. Pour cela il doit notamment offrir une prise en main et une utilisation des plus simples, pour les utilisateurs et également pour les fournisseurs de services. Par ailleurs, les initiatives de chaque pays européen doivent être compatibles et offrir un unique standard d’interopérabilité. En 2012, la Commission européenne a d’ailleurs publié un projet de règlement visant à définir un cadre européen pour l’identité numérique.

De plus, les utilisateurs doivent avoir confiance dans la maîtrise de leurs informations personnelles. La multiplication des comptes en ligne a conduit les internautes à diffuser massivement des informations personnelles, qui sont parfois monnayées à des tiers. L’identité numérique, qui fournit des informations qualifiées, ne doit pas devenir une source d’information à tout-va. L’utilisateur devra pouvoir choisir quelles informations il souhaite communiquer en fonction du service accédé et donc contrôler la diffusion de ses informations personnelles.

Aujourd’hui, un site de poker en ligne qui souhaite vérifier que vous êtes majeur vous demande de fournir une photocopie de votre carte d’identité. Cette dernière contient bien plus d’informations que la simple réponse à la question « Êtes-vous majeur ? ». Une identité numérique pourrait autoriser une granularité bien plus fine dans la diffusion des informations personnelles. De la même manière, un site de vente en ligne a besoin de connaître votre adresse postale, mais non votre date de naissance ou votre statut marital. Autre point d’attention : les adhérences entre les sphères privées, publiques ou professionnelles. Un fournisseur de services (par exemple de la sphère professionnelle) ne devrait a priori pas avoir connaissance des autres usages associés à une identité. L’identité numérique doit donc garantir souplesse, transparence et confidentialité sur les informations diffusées.

Enfin, l’adoption par les fournisseurs de services passe par un niveau de confiance élevé dans la fiabilité des informations recueillies. Par exemple, pour les services les plus critiques, permettre d’interroger le fournisseur d’Identités numériques pour garantir la validité de l’information fournie. À l’instar des cartes d’Identité physique, le vol ou la falsification seront autant de menaces pesant sur l’identité numérique. D’où la nécessité de définir un cadre légal, autant pour protéger les utilisateurs que les fournisseurs de services.

Alors, l’identité numérique, un levier pour de nouveaux usages ?

IDéNum doit permettre de dématérialiser encore plus de procédures, avec un niveau de confiance adapté, et accélérer ainsi l’émergence de nouveaux services sur internet (B2C notamment). Les entreprises vont en particulier y trouver un levier pour faciliter la relation client. L’identité numérique devrait simplifier des processus de souscription, et améliorer la confiance mutuelle : l’utilisateur dans l’usage de ses données personnelles et les fournisseurs de services dans la qualité des informations recueillies.

Mais soyons pragmatiques et n’attendons pas IDéNum pour avancer. Les Identités numériques existent déjà, même si elles ne sont pas qualifiées ou réputées fiables. Et pour certains usages, c’est déjà bien suffisant. Quels risques à permettre à un prospect de sauvegarder un devis et de s’authentifier avec son compte Google ? Si vous employez des étudiants saisonniers durant les congés estivaux, est-ce plus risqué d’utiliser des comptes génériques avec un mot de passe trivial, ou de leur permettre de s’authentifier avec leur compte Facebook ou LinkedIn ? Cette tendance est d’ailleurs déjà associée à un acronyme : « BYOID » pour Bring Your Own IDentity.

Au-delà des concepts, les fondamentaux « traditionnels » de l’identité doivent rester au cœur des réflexions : comment proposer une Identité unique et pérenne ? Comment garantir le lien avec le cycle de vie des utilisateurs dans l’entreprise ? Ou encore comment garantir un niveau d’authentification en cohérence avec les services offerts et les risques associés ? Autant de questions qui devront servir de guide à la définition de l’identité numérique de demain.

Cet article Identité numérique : quel état des lieux aujourd’hui en France ? est apparu en premier sur RiskInsight.

Des principes de bases partagés mais des divergences dans leur application

De nombreux pays tentent, à leur échelle, de répondre aux enjeux de l’identité numérique. Ces initiatives partagent les mêmes principes de base, calqués sur ceux de l’identité réelle. En revanche, elles divergent sur la mise en application de ces principes : acteurs autorisés à émettre des identités numériques, stockage des données personnelles, caractère universel ou non, etc. Ces spécificités ont pour objectif de façonner une identité numérique au plus près de la culture de chaque pays.

L’émission des identités numériques : par l’État, mais pas uniquement

Contrairement au monde réel, ce sont les acteurs privés qui ont été force d’initiative sur Internet. Par exemple Yahoo, Facebook, Google ou d’autres sites proposent d’ores et déjà de vous authentifier sur des sites tiers. Mais attention, si ce mode de fonctionnement apporte un réel confort aux utilisateurs, ces identités restent déclaratives, sans réellement améliorer le niveau de confiance associé. En effet, personne n’a vérifié que vous êtes bien la personne que vous prétendez être.

Comment alors vérifier les informations fournies et améliorer la fiabilité des identités ?

C’est souvent l’État qui se charge de vérifier et délivrer les Identités numériques de confiance. Toutefois, et principalement pour des raisons culturelles, cette responsabilité peut être déléguée à des entreprises privées, parfois sous contrôle de l’État. C’est notamment le cas au Royaume-Uni, où il n’existe pas de carte d’identité. La dernière tentative du gouvernement pour introduire une carte d’identité en 2010 n’a pas survécu à son impopularité. Le gouvernement s’est alors tourné vers les modèles américains et canadiens, en choisissant de confier la délivrance d’Identités numériques à des acteurs privés. Ainsi, il est possible de se connecter certains sites administratifs de l’État avec une Identité numérique fournie par Paypal ou The Post Office.

Des données personnelles stockées de manière centralisée ou portées par chacun

Autre point structurant de divergence entre les initiatives : le stockage des données d’identité.

Le plus souvent, les informations d’Identité numérique se présentent sous la forme d’une carte à puce. Celle-ci contient peu ou prou les mêmes informations qu’une carte d’identité traditionnelle, ainsi que des certificats électroniques protégés par un code PIN. Elle peut être intégrée à la carte d’identité physique, ou être contenue dans un support dédié (carte à puce, clé USB, carte SIM du téléphone portable…).

À contrario, l’Inde a pris le parti de centraliser les données biométriques de ses citoyens dans une base de données unique. D’ici 2015, le gouvernement espère enregistrer dans un fichier centralisé les empreintes digitales et rétiniennes de la moitié de la population. Avec un terminal biométrique, toute administration ou commerçant affilié peut alors identifier une personne. Notons que, en l’état actuel, un tel dispositif ne pourrait être transposable en France, la CNIL interdisant l’utilisation d’une base de données biométrique centralisée, sauf pour « fort impératif de sécurité »¹.

Déployer l’identité numérique : l’exemple Estonien 

L’initiative de l’Estonie se démarque cependant par son niveau d’adoption et le caractère universel de l’usage de l’identité numérique, tant dans le monde numérique que dans le monde réel. Grâce à un badge remis à tout citoyen (ou à la carte SIM de leur mobile), les estoniens sont en mesure depuis 2002 de certifier dans le monde numérique leur identité, et toute information personnelle qui s’y rattache (âge, sexe, domicile, etc.). Plus qu’une carte d’identité dématérialisée, cette identité numérique est pleinement intégrée à leur quotidien. Moyens de transport, transactions bancaires, déclarations fiscales, inscriptions à l’université, créations d’entreprise, etc. Elle permet même de voter aux élections nationales.

L’Estonie fait figure d’exception,  les niveaux d’adoption restant généralement faibles et les déploiements limités à des usages ciblés. L’Identité numérique existe malgré tout aujourd’hui dans plusieurs pays, et notamment en Europe. Qu’en est-il de la France ? Des initiatives sont-elles à y souligner ? La réponse est oui.

À suivre au 3^ème épisode…

Cet article Identité numérique : de nombreuses initiatives à travers le monde est apparu en premier sur RiskInsight.

La sécurité de l’information, un pré-requis sur les canaux numériques

La protection des données est aujourd’hui une préoccupation évidente des clients et usagers. C’est ce que révèle un sondage de l’Economist Intelligence Unit en 2013, dans lequel 90% des sondés affirment penser que leurs données utilisées en ligne peuvent être volées, notamment pour détourner de l’argent. C’est également une préoccupation des pouvoirs publics qui renforcent les obligations en termes de sécurité. Attirer les clients sur les canaux digitaux est  une nécessité pour beaucoup d’entreprises. La sécurité est un prérequis indispensable à cette transition.

D’une part, Il faut rassurer les clients, et pour cela démontrer de manière visible que des mesures de sécurité existent pour protéger les données critiques et éviter notamment les fraudes financières. Une création de compte, une transaction, un changement de RIB… une bonne sécurisation, organisationnelle ou technique, peut conforter les clients dans leur confiance dans le canal numérique.

D’autre part, en cas d’incident, la capacité à bien réagir,  tant  pour résoudre l’incident le plus rapidement possible, que pour communiquer clairement et rassurer les clients concernés est un élément clé. L’évolution de la réglementation autour de la notification des incidents poussera d’ailleurs les organisations à développer ce point.

Enfin, il est important de relayer cette position au travers des acteurs de la relation client sur le terrain (vendeurs, conseillers…) en les sensibilisant pour qu’ils portent également ces messages en magasins, agences, etc.

La sécurité de l’information, un facteur de différenciation et de compétitivité

Démontrer un réel engagement dans la sécurité de l’information peut être un élément différenciant sur le marché. Pour ce faire, des solutions de sécurité avancées peuvent être proposées. Des banques comme Société Générale ou HSBC, proposent ainsi un logiciel à installer gratuitement pour renforcer la sécurité du terminal de l’utilisateur lorsqu’il utilise leur site. D’autres, comme Natwest et Barclays mettent à disposition de leurs clients des moyens d’authentification renforcés.  Au-delà des solutions techniques, certains acteurs vont jusqu’à sensibiliser leurs clients et usagers sur l’importance du respect de bonnes pratiques de sécurité. AXA a ainsi publié le « Le guide du bon sens numérique » et encore Le Groupe La Poste a communiqué sur des bonnes pratiques à adopter sur les réseaux sociaux.

Les services marketing doivent donc travailler en collaboration avec les équipes de sécurité à la fois pour innover et proposer des solutions de sécurité, mais aussi pour écouter et savoir tenir compte des attentes des consommateurs.

La sécurité de l’information, une offre à part entière ?

Et si de centre de coûts, la sécurité devenait une source de gains ? En étant attentifs aux attentes des clients, différentes entreprises se sont posées cette question et lancent aujourd’hui des offres de sécurité en tant que telles..

Plusieurs secteurs se sont d’ores et déjà  lancés : celui de l’assurance par exemple. Cyber-assurance ou encore protection de l’identité numérique, des assurances comme AIG, AXA ou Swiss Life, ont entendu l’intérêt que portent leurs clients à la sécurité de l’information, B2B comme B2C. Autre exemple, les opérateurs télécoms qui proposent un anti-virus avec les abonnements d’accès à Internet. Ou encore, d’autres opérateurs, d’un tout autre secteur, celui des jeux en ligne, mettent à disposition de l’authentification renforcée pour leurs clients.

Ainsi, au-delà d’être un pré-requis  la sécurité de l’information peut devenir un avantage concurrentiel, voire représenter une offre à part entière. C’est à chaque organisation de choisir la posture qu’elle souhaite adopter !

Cet article La sécurité de l’information, au service de la relation client est apparu en premier sur RiskInsight.

Le certificat au coeur de la confiance numérique

Au centre de la confiance numérique repose le fameux « certificat ». Cette carte d’identité numérique, délivrée par les infrastructures de gestions de clés (IGC ou encore PKI),  permet de garantir qu’une personne, un équipement ou un service est bien celui qu’il prétend être dans le monde numérique.  Ce certificat est stocké sur des supports variés, pouvant être physiques (carte à puce, clé USB, badge) ou logiques (fichier). Il a le rôle d’une carte d’identité présentée lors de l’accès à des services ou à des informations pour prouver son identité.

Structurer une offre de services sous 3 axes

Pour tirer le meilleur parti des investissements réalisés, nos retours d’expérience montrent que l’entreprise doit s’attacher à construire son catalogue de service de confiance numérique en trois volets.  Premier volet, la fourniture simple de certificats. Les utilisateurs finaux pourront alors utiliser ces certificats dans leurs propres systèmes ou pour leurs projets techniques. C’est par exemple le cas de projets d’applications web métiers, d’authentification réseaux (802.1x)… Deuxième volet, la fourniture de services de confiance destinés à l’utilisateur et intégrant des certificats. Il s’agit par exemple de projets badges uniques (bâtiment, restauration, système d’information…), de chiffrement de messagerie ou de poste de travail. Le certificat est alors intégré de manière transparente dans les services fournis. Troisième et dernier volet, la fourniture de services « métiers » intégrant la confiance numérique. La dématérialisation des processus (bulletins de paye, facturation), les coffres forts numériques ou le stockage à valeur probante sont des exemples parlants.

Les 3 règles d’or de la construction

Mais au-delà de cette catégorisation, quels sont les éléments clés de la constitution de ces services ?

Règle n°1 : identifier les premiers « quick wins »

Le premier défi rencontré est celui de l’identification initiale et de l’extension du périmètre des services. L’implication des acteurs sécurité permet de recenser les besoins et préciser les volumétries, selon différentes typologies d’utilisateurs. L’identification de « quick wins » permet de cibler les premiers investissements à travers la valeur ajoutée des services qu’ils offriront. A cet égard, on peut envisager de ne retenir d’abord qu’un nombre limité de fonctionnalités de sécurité, au profit de fonctionnalités dites « de confort ». On pourra ainsi, dans un premier temps, coupler accès distant au SI (VPN) et messagerie sécurisée (signature et chiffrement de mails) et dans un second temps, une fois les identités numériques largement déployées, s’atteler à la greffe de services de sécurité éventuellement plus poussés : chiffrement de données, signature de documents, signature de code.

Règle n°2 : privilégier l’ergonomie et la facilité d’usage

En outre, l’ergonomie des outils doit rester au cœur des préoccupations : simplicité d’emploi, transparence de l’intégration au poste de travail, mais également gestion des accès de secours. Car si l’implémentation de ces derniers constitue souvent une atteinte au niveau de sécurité des outils, force est d’avouer qu’une offre rendant l’oubli du support cryptographique (carte à puce, clé USB.) bloquant pour l’utilisateur, compromettra l’acceptabilité de la solution toute entière, notamment auprès des utilisateurs les plus exigeants. lesquels sont aussi souvent les plus influents. C’est pourquoi  une étude précise des besoins des métiers permettra d’identifier le meilleur compromis entre niveau de sécurité et types d’accès de secours exigés par les utilisateurs. Notons également l’importance du dispositif utilisé, clé du succès de l’offre : un projet de badge unique, offrant par exemple, l’accès aux bâtiments, le paiement à la cantine et la sécurisation de la messagerie, comprend de vraies complexités organisationnelles mais apporte une valeur ajoutée considérable

Règle n°3 : le RSSI, sponsor de choix

Last but not least, notons que le RSSI doit, autant que possible, servir d’appui moteur au déploiement des services, que ce soit de façon directe, par exemple par le biais d’une participation au financement du projet abaissant ainsi le coût utilisateur, ou de façon indirecte, via la promulgation de règles de sécurité imposant in fine l’utilisation des services de confiance. Ce sponsoring est d’autant plus crucial que la plupart du temps, l’appétence des utilisateurs finaux pour les services de confiance numérique est relativement modeste et ne suffit pas à donner un élan au projet

La confiance a de l’avenir

Le monde a commencé sans l’homme et s’achèvera sans lui”, nota le crépusculaire Levi-Strauss. “L’homme a commencé sans l’informatique et s’achèvera sans elle”, pourrons-nous dire de façon analogue. Nous avons montré plus haut que, si la confiance est d’ores et déjà au coeœur de beaucoup de services offerts par les DSI, cela n’occulte en rien le fait que cette notion dépasse largement l’IT. Les technologies changent mais les principes et processus perdurent, aussi le périmètre des services de confiance s’étend-il inéluctablement aux usages métiers les plus divers, à travers la dématérialisation notamment. Le chemin est, nous l’avons vu, semé d’embûches, mais pour l’offreur avisé, c’est donc un succès assuré. Ad augusta per angusta ! (*)”

(*) “Vers la gloire, par des chemins étroits” (Victor Hugo, Hernani)

Cet article Services de confiance numérique : pour que le contrat de confiance règne ! est apparu en premier sur RiskInsight.

Forts de premiers projets réussis, les années 2010 marquent une rupture en la matière, puisque l’on voit alors se développer rapidement l’utilisation conjuguée de la dématérialisation et de la signature électronique à destination du grand public. Cela s’explique par  trois facteurs.

Un cadre réglementaire aujourd’hui maîtrisé

En 2001, la législation française institutionnalisait la signature électronique  par les articles 1316-1 et 1316-4 du code civil et le décret n°2001-272 du 30 mars 2001. Elle rendait alors la signature électronique équivalente à la signature papier, sous condition du respect des principes d’identification fiable du signataire et d’intégrité des données. Pourtant, la frilosité l’emportait, faute de retours d’expérience suffisants dans l’application de ce cadre juridique.

Il faudra attendre 10 ans pour voir se déployer plus largement la signature électronique. Quelques jurisprudences, bien qu’encore peu nombreuses, confortent les entreprises : celle de décembre 2010, par exemple, concernant  la reconnaissance juridique de la notification électronique d’une demande de résiliation (exemple d’un abonnement téléphonique) portant une signature électronique (http://www.resilier.com).

Des premiers succès rassurants dans le B2B et les administrations

Ces dernières années, des projets plutôt B2B ont vu le jour. Les grandes entreprises ont mis en œuvre des solutions de dématérialisation et de signature électronique pour des usages professionnels (ex : signature de remises réglementaires pour les établissements financiers, signature d’ordres de paiement pour les trésoriers d’entreprise, signature de contrats entre professionnels). Ces solutions s’appuient sur l’utilisation de certificats électroniques, preuve de l’identité numérique personnelle de son porteur, indispensable à la signature électronique.

Déjà éprouvées par les entreprises, ces solutions sont désormais matures et peuvent être réutilisées pour de nouveaux usages destinés au grand public.Le grand public est prêt et demandeur !

Le grand public est aujourd’hui habitué et enclin à l’achat de biens et de services sur internet, ainsi qu’à l’utilisation de processus administratifs dématérialisés en ligne (Mon Service Public, déclaration des impôts, consultation de données personnelles de santé, facturation électronique des fournisseurs d’énergie et d’internet…).

De plus, conscients des risques de fraude et d’usurpation d’identité, le grand public est dès lors sensibilisé à l’utilisation de moyens de sécurité lors de transactions en ligne, tels que l’envoi de code par SMS, l’utilisation de carte bancaire virtuelle, de clavier numérique, de certificat électronique, etc.

Enfin, le grand public montre une appétence de plus en plus forte pour l’obtention de biens et de services rapidement, voire même de façon immédiate.

Les banques françaises (BNP Paribas, LCL…) participent fortement à cet essor ; elles offrent, depuis plusieurs années déjà, la gestion en ligne des comptes bancaires (suivi de comptes, opérations de virement…) ; et plus récemment, elles proposent la souscription en ligne à des services bancaires (ex : livret d’épargne, prêt à la consommation, assurance) à leurs clients particuliers, grâce à la signature électronique mise en œuvre par l’utilisation de certificats électroniques personnels. Cette  offre répond pleinement aux attentes du grand public.

Comment lever les derniers freins ?

Il reste aujourd’hui un frein majeur au développement de la signature électronique en France : la distribution et la gestion des  parcs de certificats pour le grand public.

Des opérateurs de téléphonie mobile (SFR en France, Turkcell en Turquie) ont ainsi créé des partenariats avec des fournisseurs de puces SIM cryptographiques (Oberthur, Gemalto), afin de fournir à leurs abonnés des mobiles embarquant une solution de signature.

Ces offres, reposant sur une collaboration entre opérateurs mobiles et banques, permettent aux abonnés d’accéder à des services sécurisés en ligne grâce à leur mobile, tel que l’achat en ligne et la banque en ligne, sans aucune transmission d’informations bancaires.

Par ailleurs, le gouvernement français renouvelle sa volonté de développer l’usage du numérique avec la préparation d’un nouveau plan France Numérique 2020, qui sera dévoilé d’ici 2012, avec la perspective d’y voir s’inscrire des projets concrets de confiance numérique.

Ces innovations et projets dans la confiance numérique permettront certainement de lever les derniers freins quant à la distribution et la reconnaissance des certificats électroniques.  En effet, c’est grâce à la demande du grand public et l’implication des grands acteurs du B2C et de l’administration (G2C) que la signature électronique pourra décoller !

Cet article Dématérialisation et signature électronique : vers l’explosion des usages grand public ? est apparu en premier sur RiskInsight.

La difficulté de la prédictibilité des coûts dans le cloud

Le modèle du cloud nécessite une attention forte pour ne pas perdre au bout de quelques temps les gains économiques escomptés, voire éviter une réelle dérive des coûts. Dans le cloud, comme au sein du SI historique, une gestion fiable des identités est ainsi essentielle pour garantir durablement la maîtrise du nombre d’accédants à ces services.

Bien évidemment, elle vise également à renforcer la protection de l’accès aux informations qui y sont stockées. Elle y est même encore plus indispensable, vu l’absence de garde-fous traditionnellement rencontrés, comme par exemple la « porte d’entrée » Active Directory ou le contrôle d’accès physique.

Gérer les identités dans le cloud : quelles stratégies gagnantes ?

Comment le faire concrètement ? Plusieurs solutions sont envisageables :

–       Gestion manuelle sur le site du service cloud par les équipes de l’entreprise. C’est certes efficace pour lancer rapidement des initiatives cloud, mais il faut prévoir de rencontrer, tout aussi rapidement, toutes les limites bien connues de la gestion manuelle : écart, difficultés de maintien, complexité des revues…

–       Gestion automatisée via un service de provisioning/deprovisioning avec des contrôles a priori (validations) et/ou a posteriori (contrôles et recertifications) : l’accès aux services cloud piloté par les processus et les outils IAM de l’entreprise. Mêmes solutions que dans le SI historique… et mêmes vigilances et bonnes pratiques pour éviter toute désillusion !

–       Gestion automatisée via un service de fédération d’identités : certainement aujourd’hui la solution à privilégier quand cela est possible, puisqu’elle apporte des réponses satisfaisantes aussi bien sur les problématiques de gestion au quotidien qu’en termes d’expérience utilisateur. Après des années de balbutiements où les entreprises n’allaient quasiment jamais plus loin qu’un prototype, les derniers dix-huit mois marquent le réel envol de la fédération avec des réalisations significatives.

–       Gestion automatisée et fédérée par un tiers de confiance, jouant le rôle d’intermédiaire entre l’entreprise et les différents offreurs de services cloud. Des acteurs commencent à se positionner sur ce sujet, mais la classique question de la confiance se pose !

Le cloud : un booster pour les projets IAM

Sujets à traiter, bon sens et bonnes pratiques, priorisation et angles d’attaque, risques et écueils à éviter : la gestion des identités dans le cloud doit relever les mêmes challenges que dans le SI historique.

Et si le cloud était un levier formidable pour d’une part simplifier et fiabiliser les processus et outillages IAM actuels, et d’autre part faire décoller l’usage de nouveaux services IAM de type reporting et recertification ?

Cet article Cloud computing : maîtriser ses coûts grâce à une bonne gestion des identités est apparu en premier sur RiskInsight.