Dashboards and KPIs that convey concrete messages and calls for action are often what drives the success of operational resilience initiatives.

Operational resilience brings together and harmonises multiple disciplines that were previously managed in silos: business continuity, IT and disaster recovery, incident and crisis management (IT, business and cyber), cyber defence, third party management, and operational risk management.

In order to coordinate and orchestrate these disciplines effectively to establish an accurate picture of the overall resilience, companies need to analyse their data in relation to these topics. This requires a complete mapping of critical services (Important Business Services), their dependencies (business processes, applications, suppliers, teams, buildings, etc.) and testing.

To make this possible, there is a real need for tools and automation. This is also why we are seeing more end-to-end solutions for operational resilience management emerging in the market, from specialist vendors such as Fusion Risk Management, Castellan to non-specialist ones, such as ServiceNow.

What are the challenges in the field?

Depending on the company’s maturity, each stage of the process may pose challenges or difficulties.

Challenge 1: Data Model

The operational resilience data model must be created in consideration of Important Business Services and their respective dependencies. Preferably, an organisation would reuse existing inventories (e.g. CMDB, supplier inventories, BIAs, HR systems, etc.) and run workshops to leverage on the knowledge of their business representatives and IT experts, suppliers, etc. The challenge stems from the need to rationalise all the elements into a format that enables data analysis. This means that even if one starts with Excel, it is important to firstly define the precise rules (common referencing system, one piece of information per line, etc.).

Challenge 2: Identifying gaps

Once this mapping is carried out, companies need to identify threats linked to the end-to-end service and existing resilience capabilities to mitigate them. These capabilities can be specific to a dependency or broader. This allows the creation of indicators that show resilience gaps. Overall, there can be two types of gaps:

1. A dependency with insufficient contingency plans

This can be identified in the initial analysis, through existing controls, or through testing.

Example: A person wants to withdraw cash. Normally, this service is available through an ATM. Several elements are necessary for ‘normal’ service to function properly:

• Physical ATM itself
• Customer authentication system via their bank card
• Customer account management software provided by a third party to check the balance

The following threats may affect this service:

• Major IT loss (whether or not caused by a cyberattack)
• Loss of the software provider
• Physical incident affecting the ATM

We shall assume that 4 hours is the period before the inability to withdraw cash becomes an intolerable source of harm to the customer – which is also known as the impact tolerance). With this context in mind, the bank needs to consider the following questions to identify resilience gaps:

• Recovery Time Objective (RTO): In the event of a computer loss, can the ATM and authentication system be brought back online within 4 hours according to their RTO? Has it been tested?
• Exit plan: In the event of a major breakdown or bankruptcy of the account management software provider, is there an alternate provider the bank can turn to for delivering the service without intolerable delay? Alternatively, is there a way to bring the activities in-house?
• Contingencies: Is there a degraded process for dispensing cash, for example, by replacing a faulty ATM? What are the dependencies for this process? Can it be done without an IT system?

Once these gaps have been identified, you can then calculate resilience scores for individual components.

2. Absence of a core resilience capability

A range of operational resilience capabilities is needed in every organisation, which includes business and IT continuity, third party management, cyber defence, disaster recovery and crisis management. We have identified a list of 50 generic core capabilities, linked to the most common threats, and are deploying this framework with our clients to measure the overall operational resilience maturity level.

Examples of key capabilities include:

• Crisis management: alternative communication channel
• Disaster recovery: Cyber vault
• Third party management: Crisis SLAs with third parties
• Business and IT continuity: degraded processes without IT
• Cyber defence: emergency authentication procedure

Challenge 3: Governance

Finally, governance is required to ensure that operational resilience data is maintained up to date, such that accurate reporting can be delivered to aid decision-making in the right forums. For instance, any initiatives to remediate identified resilience gaps requires management buy-in and funding, and management can only make the right decision and prioritise initiatives based on what is being reported on official reports.

Finally, what should be measured? 

The underlying question in MI is: how well is your organisation prepared to withstand a major incident?

• Are the dependencies identified?
• Are the necessary documentations in place?
• Are the threats known?
• Are controls in place to indicate a gap?
• Are the company’s employees prepared to respond and minimise the operational impact of a major incident?

What are customers’ expectations?

As of today, through supporting our clients in their Operational Resilience program, we have identified three common themes with regards to our clients’ expectations around operational resilience projects:         

1. Clients need help with creating an inventory and rationalising multiple sources with various data formats to be incorporated into the data model.
2. Clients regularly require support with creating reporting. This can be in the form of designing useful KPIs that can be translated into actionable items and a driver for decision-making process, or creating dashboards in data visualisation tools such as PowerBI.
3. There is an increasing demand for sourcing and deployment of operational resilience tools. Wavestone can help companies find the right tool that suits their needs via:
   • Performing a benchmark
   • Gathering requirements and specifications through workshops with future users
   • Creating an RFP and a suitable scoring mechanism to evaluate vendors

In fact – a great example showcasing our expertise around this particular area around helping our clients with sourcing and the deployment of operational resilience tools would be Wavestone’s second edition of the Operational Resilience Tooling Panorama – it captures the main market players across a range of topics such as emergency notifications, resilience management (mapping, testing, dashboards), crisis management and business or cyber incident simulation (cyber range). The radar is also built to encompass a wide spectrum of players – from disruptive innovators to traditional players, and from start-ups to large organisations.  

Any final advice for readers?

For French clients who have not yet launched an operational resilience program, there are two pieces of advice:

• As soon as the mapping is done, you need to think about how to store the data (i.e. the data model). Excel may not be sufficient as a tool to ensure the sustainability of the model
• Do not hesitate to re-use what your company already has in terms of business and IT continuity, third party management, cyber defence, IT reconstruction and crisis management.

Cet article MI and tooling at the heart of operational resilience management, Roxane Bohin interview est apparu en premier sur RiskInsight.

Let’s continue here with a few additional questions – and answers – to explore the subject in greater depth.

How many roles do I need to create? How many roles should each user have?

It may be tempting to design a model that can handle every use case identified during a requirements collection phase. However, we should bear in mind that the model will have to live and evolve with new applications, new organizational units, etc.

There is no general rule on the number of roles to assign to each user. It is perfectly possible to build your model so that only one role is assigned per user, just as it is possible to assign several.

However, a compromise must be found between creating overly specific roles, which quickly fall into the “1 role for each user” pitfall, and creating overly general roles that do not bring much benefit and lead to over-allocation of rights.

Aiming for 80% of rights allocated via the role model and 20% of discretionary rights should already prove to be a good goal.

Bottom Up or Top Down, which method should I use?

There are two main methods that can be considered when creating an authorization model.

The “Bottom Up” approach starts from the existing rights and analyzes them to derive a model. For example, if all employees in the Accounting department have the same rights, then a role dedicated to this department can be created, which will contain the corresponding permissions. In this approach, data quality is a prerequisite for successful modeling, as wrongfully assigned rights would add noise to the model and reduce its relevance.

The “Top Down” approach starts by defining the theoretical authorization model, on which the necessary authorizations are then projected. For example, a role for the Accounting department can be created and include the permissions that business representatives deem necessary to accomplish their mission.

In practice, it is common to adopt an intermediate approach.

It is also recommended to work iteratively and to validate the approach on a pilot scope before generalizing it. The involvement of business representatives in the definition and validation of the roles plays a key role here.

What tools do I need?

The high volume of rights to be processed and the multiple iterations required imply the use of a tool that can either be sourced from the market or developed internally (Excel tables, database, scripts…). A prior analysis of the needs will ensure the adequacy of this tool.

In addition to the ability to create roles or rules for assigning rights, which is increasingly facilitated using algorithms that take advantage of machine learning, the chosen tool must facilitate the data quality cleaning phase before the actual modeling phase. It is also useful to have a simulation function that highlight the over- or under-allocations generated by the new model compared to current assignments.

In nominal mode, the IAM solutions on the market offer various possibilities that can used advantageously: role hierarchy, automatic ABAC-style allocations, suggested allocations, multiple role dimensions, etc. However, care must be taken not to fall for a model too complicated to use and administer.

If the choice of the IAM solution that will handle the model has already been made, it is necessary to ensure that this solution can handle all the desired complexity, even if it means making some simplifications or adjustments to the model.

Should I build my authorization model before, during, or after the implementation of my new IAM solution?

Generally speaking, it is preferable to design your authorization model before the implementation of a new IAM solution as the model can strongly influence the choice of the tool, depending on the adequacy of the technical possibilities and the functional expectations.

If data quality is satisfactory, the implementation of the model itself can then take place at the same time as the implementation of the IAM solution. If necessary, it is possible to plan a transition phase where the old tool can coexist with the new one. The perimeters ready for the transition to the new model can thus processed in the new tool, which gives more time for the migration of perimeters that require more work and time, although a migration schedule should be defined and closely monitored to avoid any drift that would prolong this situation for too long.

How much time should I plan?

The implementation of an authorization model is usually substantial project that requires the consideration of many factors and has a significant impact on all the stakeholders involved in the authorization environment (application managers, user support, business lines, etc.).

It is essential to take your time during the framing and design phase in order to ensure the success of your project.

The modeling phase can be long and tedious, especially if the volume is high in terms of the number of roles or the number of entities to be covered, or if the data quality is unsatisfactory and requires remediation.

Change management should not be neglected, given the impacts that are clearly visible to users. Training and a strong support phase are most of the time necessary once the model has been implemented.

What governance should I establish to bring my authorization model to life?

An authorization model is never static. The authorization catalog is updated as new applications are developed or decommissioned, the information system and business undergo evolutions, and reorganizations are carried out. Right from the design phase, it is necessary to reflect on the principles of current governance to avoid building a model that is too complex and impossible to maintain over time.

While the management of the model is often handled by a team dedicated to authorizations, the involvement of other stakeholders is essential, particularly on the part of the business, which must communicate any changes in its needs. The appointment of authorization correspondents within the business departments can be a way of encouraging this involvement.

Final words

The perfect implementation of an authorization model probably does not exist. Even if there is no major interdiction, finding a compromise between expectations and possibilities remains a delicate exercise that requires careful planning, preparation and monitoring.

In a nutshell, here are five good practices for the success of an authorization model redesign project:

1. Allocate sufficient time for the project.
2. Frame and steer the project with the greatest care to avoid deviations in terms of ambition, priorities, workloads or deadlines.
3. Communicate with and involve the right IT and business contributors.
4. Know when to say “no” if covering a need would risk deteriorating the ease of use or the maintainability too much.
5. Do not neglect the change management with the end-users.

It is worth note that these good practices remain perfectly applicable to any IAM project in general!

Cet article Redesigning your authorization model: the key issues (2 /2) est apparu en premier sur RiskInsight.

We have cited five key success factors needed to deliver an ERP permissions risk-remediation project:

The key success factors for an ERP permissions risk-remediation project

The first two key success factors were discussed in the previous article; and the other three are covered in this one.

3. Preparing for large-scale deployment

Services, business lines, geographical or legal entities… the remediation of permission-related risks means reviewing user accounts across varied—and often numerous—functional areas. To be able to keep to schedules, limit workloads, and reassure those involved in the project locally, it’s best to deploy things at as larger scale as possible. Doing this means:

• Defining and communicating the risk analysis and remediation methodology;
• Putting in place a steering plan;
• Introducing analytical tools, automated as far as possible, to cope with volumes;
• Formally preparing materials for workshops and consolidation sessions;
• The documentation for the methodology and the tool in order to be able to train users.

These documents will form the deployment kit to be used in the different areas of work of the project phase; this can also continue to be used when the project phase is complete.

The deployment kit for an ERP permissions risk-remediation project

The deployment methodology will need to cover the following activities, and will need to be recreated for each area of work:

• Risk assessments and the definition of KPIs.
• Remediation workshops for user-related risks.
• Validation and execution of remediation plans.
• Training and support for upskilling.

Obviously, the methodology must be adapted to the company’s organizational structure and the resources available to it: the workforce, local variations in business processes, the degree of maturity in risk and permissions management, etc.

In particular, this will involve engaging local experts both on the technical aspects of permissions (access rights officers, application owners, security officers), and on the business-function aspects of processes (business-function representatives, process owners, internal controllers, team managers, etc.). The contribution that will be expected from them, and the effort they will need to put in, should be clear from the start and must remain “reasonable”. Local managers should therefore be involved, to ensure that those who need to take part do so, and to help in decision-making.

During remediation workshops, participants will, in particular, analyze user-related risks, but they will also have to consider various remediation strategies, such as the ones described below:

Strategies to consider in an ERP permissions risk-remediation project

It’s always preferable to validate the methodology using a pilot project that is small enough to limit work volumes, but large enough to be representative of the company. In some cases, a better strategic choice may be to select a work area that’s likely to be more fruitful for the project; or, conversely, one that’s expected to require more support. The lessons learned at the pilot stage will allow the methodology and tools to be adjusted before they are deployed more widely.

4. Selecting the right tools

The tools put in place must aid success during the project phase, but also—and more importantly—provide long-term support for the chosen approach; both these phases must be complementary.

Being well equipped is about being clear on the initial controls to be applied (at the point when new permissions are requested) as well as on the ongoing controls (those applied once permissions have been granted). Having more initial controls will help reduce risks, but operational efficiency may also suffer (delays, difficulties in processing requests, etc.); a balance needs to be found.

From a functional point of view, it’s a question of putting in place the families of controls typically found in such projects, namely:

• Data quality controls: completeness and coherence of data; respect for nomenclature, etc.
• IT security-rule controls: orphan, dormant, and administrator accounts; temporary and residual permissions; IT accounts with business-function permissions and vice versa, etc.
• Business-functions rules/compliance controls: discrepancies between jobs and the associated permissions; discrepancies in permissions between members of the same team; breaches of rules on the segregation of duties; users having access to areas that are beyond the scope of their responsibility, etc.
• Usages and behavior control: excessive or unusual uses, suspicious behavior, typical fraud scenarios, etc.

Families of typical controls for an ERP permissions risk-remediation project

Being well equipped is also about prioritizing and automating the controls that are worth putting in place. The return on investment must be assessed in terms of each control’s relevance to the company’s situation (does the control cost more than dealing with the consequences of the risk it’s designed to cover?), and the potential benefits of automation (how much will be saved compared with a manual process?).

The volumes and complexities associated with ERP authorization models means turning to tools specifically designed for the task: for example, it’s not unusual to see SAP systems with several thousand roles and over a hundred thousand fine-grained permissions (transactions and authorization objects).

These needs fall at the intersection of several different segments of the software market; these are currently highly dynamic and far from mutually exclusive: “Identity and Access Management”, “Continuous Control”, “Specialized Governance-Risk-Compliance tools on a given ERP”, and so on. Given this, the approach taken, degree of maturity, functional coverage, and mode of delivery (on site or cloud/SaaS), can vary substantially from one product to another.

When selecting a tool, it’s a question of considering the following elements carefully:

• Ergonomics and ease of use: once the project is finished, the tool’s users will be mostly from business functions—not from IT.
• Customization options: such that the tool really can be used to support the methodology taken (vocabulary and screens, rules and controls, dashboards and reports customized to company needs, etc.).
• A package of preconfigured controls: usually based on good practice, for the company ERP.
• The ability to put in place controls on other applications, and between applications: over the medium-term.
• Analysis and decision support functionality: to highlight anomalies, simulate changes in permissions, conduct in-depth analyses, suggest remediation measures, etc.

Although the tools are generally not intrusive, in terms of their effect on applications, there’s still a need to automate the transfer of data, in a reliable way—from the ERP and other potential repositories. Involvement of the relevant IT teams will thus be needed too.

5. Getting things right for the long term

Projects of this type only make good sense if permission-related risks can be controlled effectively over the long-term. Doing so avoids the problem of risks that have been brought under control during the project appearing again—some time later.

To encourage long-term buy-in to the approach and tools put in place, it’s essential to invest in change management from the start—and throughout the project—by means of meetings and regular newsletters, training and coaching sessions, documentation and tutorials, etc. It’s best to use a diversity of channels and communication supports to reach the maximum number of people without giving the impression of over-marketing.

It’s also important to help those responsible for permission-related risks to apply new controls to their recurring activities. In fact, the frequencies of advanced controls, the objectives to be achieved, and the levels of risk that must not be exceeded, can be explicitly defined. These objectives must be realistic and progressive: “What’s needed is to envision a long road—but with short milestones.”

There must be an emphasis on community too: it’s important to encourage interactions between managers from different functions, which will enable them to share experiences and good practice. There may even be a value in introducing a degree of healthy competition between different business functions; perhaps even organizing some low-key challenges. However, you should ensure that the fact of making progress is valued more highly than achieving any specific numerical objective, because the various work areas will have to progress from very different starting points.

Finally, an “ongoing” mode needs to be implemented—to ensure that permission-related risks remain under control once the project is completed. This should include:

• Choosing a designated contact for the methodology and tools put in place;
• Upskilling the technical teams to ensure in-service support for tools, and that reports and controls can be developed when necessary;
• Documenting and capitalizing on the knowledge acquired during the project phase.

This must give consideration to developing a roadmap for other future activities that will address new processes, risks, applications, or populations.

Long-term control of the risks related to ERP permissions

In conclusion: it can be done!

As we’ve seen in the two articles on this topic, controlling the risks related to ERP permissions means pursuing a number of key workstreams—from putting in place the right tools, through holding workshops for the business functions, to training and change management.

But with a good methodology and committed participants from IT and the business functions on board, anything is possible! Tangible results can be achieved—and corporate momentum built—within a reasonable timeframe, to regain control of permissions across the IS. And, lastly, the key success factors presented here are broadly applicable to applications other than ERPs.

Cet article ERPs: How to control permission-related risks (PART 2) est apparu en premier sur RiskInsight.

Qu’est-ce que l’informatique quantique et pourquoi s’y intéresser ?

La manière dont les ordinateurs sont encore très majoritairement conçus aujourd’hui repose sur une architecture principalement séquentielle : les opérations sont effectuées par l’ordinateur les unes après les autres, selon un programme d’instructions écrit par l’homme. Le micro-processeur exécute alors les opérations de façon quasi séquentielle, et c’est ici l’une des principales faiblesses de cette architecture et de ses variantes.

L’informatique quantique viendrait alors combler cette faiblesse en proposant des machines dotées d’une faculté de parallélisme, permettant d’augmenter considérablement la puissance de calculs complexes, la rapidité de traitement et la capacité (théorique) de stockage. Cette technologie s’appuie sur le phénomène de superposition d’états quantiques pour développer des capacités de calcul beaucoup plus importantes que l’informatique classique. En effet, l’information est représentée par des « quantum bits » (qubit) similaires aux bits binaires utilisés dans l’informatique numérique. Pour rappel, le bit peut prendre deux valeurs, 0 ou 1 selon l’état du transistor. Le qubit, peut avoir trois états, le 1, le 0 mais aussi les deux à la fois : c’est ce qu’on appelle la superposition.

Cette capacité de superposition multiplierait le nombre d’opérations complexes réalisables dans un temps limité. Ainsi, là où le traitement d’informations volumineuses peut parfois prendre plusieurs jours, semaines, mois à être traitées par des ordinateurs classiques, les systèmes de l’informatique quantique le traiteraient en quelques secondes.

Malheureusement, cette technologie impose de maintenir l’état quantique pour atteindre de telles capacités de calcul, le problème étant que cet état ne peut être atteint qu’en plaçant l’ordinateur proche du zéro absolu, soit -273 °C, seules températures pour lesquelles le qubit est réellement stable. De manière évidente, il est extrêmement complexe de maintenir de telles températures avec un système simple, peu onéreux et peu encombrant pour une longue période de temps.

L’informatique quantique comme outil de sécurité

Les apports de l’informatique quantique en matière de capacité de résolution et de traitements rapides d’opérations complexes sont très convoités, et principalement dans le domaine de la sécurité informatique, où les mesures de protection et de détection nécessitent de plus en plus de rapidité d’exécution.

Par exemple, la lutte contre la fraude est aujourd’hui l’une des principales problématiques de sécurité du secteur bancaire et a pour enjeu d’exploiter des techniques poussées de détection de fraude, basées sur la collecte, le traitement et l’analyse, en temps réel, de données volumineuses. Ces techniques sont très gourmandes en puissance de calcul et, bien qu’aujourd’hui réalisables par nos ordinateurs les plus performants, elles pourraient être encore plus efficientes avec plus de puissance. Les ordinateurs quantiques, s’ils voient le jour, pourraient ainsi constituer un pilier de la lutte contre la fraude, à travers leur forte capacité (théorique) de stockage et leur rapidité de traitement.

De même, les systèmes quantiques pourraient notamment permettre de détecter et de corriger les erreurs. En effet, le qubit, sur lequel repose tout le fonctionnement de cette nouvelle génération informatique, est en effet très sensible aux perturbations de son environnement (interception, changement de configuration, variations de température, champs magnétiques…). Le qubit peut constituer ainsi, dans ces conditions, un moyen fiable pour garantir l’intégrité des données stockées.

L’informatique quantique comme source de menace

Les communications sécurisées, les systèmes sécurisés de paiements, les transactions financières, les monnaies virtuelles telles que le bitcoin, reposent tous sur des mécanismes cryptographiques, et en particulier sur les protocoles de chiffrement asymétriques. La sécurité de ces protocoles dépend principalement du fait qu’il faudrait plusieurs fois l’âge de la Terre à des ordinateurs classiques pour casser une code par la « force brute ». Pour un ordinateur quantique, ce décryptage est théoriquement réalisable et en très peu de temps. D’où le risque non négligeable pour les systèmes de chiffrement actuels si ces ordinateurs quantiques venaient à être démocratisés.

De plus, plusieurs attaques informatiques telles que les attaques par déni de service (DOS ou DDOS) nécessitent d’exploiter de fortes ressources en termes de traitement informatique qui, à l’aide des futurs ordinateurs quantiques, pourraient devenir facilement exécutables.

C’est précisément pour ces raisons que les instigateurs de l’informatique quantique se focalisent notamment sur le domaine de la sécurité afin de combler les failles qui pourraient potentiellement être occasionnées par l’apparition des ordinateurs quantiques, et espérant ainsi offrir des communications totalement sécurisées aux utilisateurs, en misant sur la cryptographie quantique. En effet, un réseau de communication quantique serait théoriquement inviolable. Toute tentative visant à intercepter la « clé de chiffrement quantique » modifierait l’intégrité physique des données quantiques, changerait alors leurs états (passage au 0 ou au 1 par exemple), et pourraient ainsi déclencher une alerte qui avertirait les personnes concernées. Actuellement, plusieurs laboratoires dans différents pays tentent de tirer le meilleur parti de cette technologie.

Par ailleurs, l’histoire nous a montré que lorsqu’un protocole de chiffrement était devenu « cassable », des solutions de chiffrement plus sécurisées voyaient le jour au même moment. On peut donc imaginer que si un jour un ordinateur quantique permet de casser un chiffrement « classique », une solution de chiffrement plus robuste, potentiellement basée sur la cryptographie quantique, sera disponible.

L’informatique quantique, concrètement…

Dans l’état actuel des recherches, tous ces concepts restent théoriques et seuls quelques embryons d’ordinateurs quantiques existent dans le monde, confinés encore à des laboratoires académiques, au sein des institutions les plus prestigieuses. Une quête dans laquelle IBM et Google se sont déjà lancés depuis plusieurs années. Intel a également rejoint la course à l’informatique quantique en annonçant investir 50 millions de dollars sur le sujet. La France n’est pas en reste, avec notamment le Laboratoire Kastler Brossel qui a reçu récemment un troisième Prix Nobel pour des travaux allant dans ce sens.

Du reste, les avis divergent sur cette nouvelle génération de l’informatique : Le National Institute of Standards and Technology (ou NIST) américain a prévenu que les différentes agences gouvernementales devront être prêtes à adopter de tels systèmes en 2025.  La NSA, l’agence nationale de la sécurité, conseille de mettre en place des processus de sécurité quantique aussi rapidement que possible. A l’opposé, certains cryptographes ne partagent pas cet avis, et ont déclaré lors de la dernière Conférence RSA qu’ils doutent que les progrès dans le calcul quantique et l’intelligence artificielle transformera réellement la sécurité informatique. Aussi, Eleni Diamanti, chercheuse au CNRS et membre de Paris Center for Quantum Computing, affirme pareillement que « même si un qubit est plus puissant qu’un bit, il en faut au moins un millier pour concurrencer les machines actuelles », ce qui est loin d’être concrétisé aujourd’hui, au vu de la complexité de création d’un qubit et de maintien dans des conditions stables.

Cet article Informatique quantique et sécurité : menace ou opportunité ? est apparu en premier sur RiskInsight.

Les 4 clés de l’intégration des services Cloud

1 – Une intégration des données sans couture

Avec l’utilisation de services Cloud, on exacerbe le besoin de mettre en place des plateformes transverses d’échanges entre les différentes ressources, qu’elles soient Cloud ou internes. Cette problématique est essentiellement présente lorsque l’on s’appuie sur des services SaaS.

Il s’agit ainsi soit d’étendre les plateformes d’échanges traditionnelles aux services Cloud si elles offrent des connecteurs vers les interfaces (API) des applications Cloud, soit de s’appuyer sur des services d’échanges relais (Cloud ou internalisés), qui masqueront la complexité des interfaces et de leur évolution.

2 – Une gestion centralisée des identités

Celle-ci est essentielle pour fournir aux utilisateurs un accès sans couture à l’ensemble du SI, qu’il soit en mode Cloud ou non. Elle doit notamment permettre de gérer le cycle de vie des comptes utilisateurs (décommissionnement, gestion du mot de passe…).

Cet aspect est trop souvent négligé. Il arrive par exemple de laisser des accès ouverts à des employés ayant quitté la société, l’exposant à de la surfacturation et à d’importantes brèches de sécurité. La DSI doit donc mettre en œuvre une gouvernance des identités globale ainsi que l’outillage adéquat.

3 – Des référentiels communs de service management

Pour que la DSI puisse garantir les niveaux de services de l’outil informatique (disponibilité, impact des changements, capacité d’évolution…), il est nécessaire qu’elle puisse intégrer les services Cloud à ses référentiels de service management. Ils auront notamment un rôle primordial pour gérer les changements. En effet, les services Cloud évoluent constamment, en cycle rapide, sans que les clients puissent s’y opposer. Les analyses d’impacts doivent donc être précises et le plus automatisées possible. Pour s’adapter au Cloud, les référentiels devront intégrer des ressources fournies en mode as-a-Service, pour lesquels les aspects de localisation ou de dépendance à des ressources physiques ne sont pas connus.

4 – Des portails de services par usage

L’une des composantes essentielles du Cloud est l’aspect self-service. Pour optimiser l’apport des services Cloud, il est primordial de limiter le nombre de points d’entrées pour les demandes de ressources, les déclarations d’incidents et le suivi des consommations, et ce quel que soit le nombre de fournisseurs.

En revanche, il n’est pas nécessaire de se limiter à une seule interface globale pour l’ensemble des services de la DSI. Il s’agit ici de fédérer les différents portails de services qui seront instanciés par typologie d’usage et de population. Pour ce faire, il faut anticiper au plus tôt une cible globale d’intégration puis s’appuyer sur un outillage adapté aux services souscrits et à l’existant. Cet outillage est à déployer progressivement à l’occasion de chaque projet Cloud jusqu’à atteindre la cible.

Une stratégie d’outillage à définir en fonction de la stratégie Cloud

La cible d’outillage sera à définir en fonction de la stratégie Cloud. Dans une stratégie à dominante SaaS, le challenge majeur sera d’intégrer sans couture les nouvelles applications au SI. Il faudra donc en priorité traiter les problématiques d’intégration de données, la gestion unifiée des identités et le portail de services. Si la stratégie Cloud est essentiellement IaaS, les enjeux seront plutôt liés à la gestion de ce nouveau parc de ressources. Il faudra alors se doter rapidement d’un outillage permettant d’adresser la problématique de service management.

Deux types d’acteurs constituent actuellement le marché de l’outillage Cloud, qui est en phase d’évolution rapide. D’un côté, des startups aux offres fonctionnellement riches mais dont la pérennité n’est pas toujours assurée. De l’autre, des fournisseurs traditionnels avec des offres qui sont soit balbutiantes, soit issues de rachats récents, donc peu intégrées au reste de leur gamme et en passe de subir des évolutions majeures.

Ces solutions n’étant pas pleinement satisfaisantes, deux stratégies de déploiement s’offrent aux entreprises.

Si l’on est dans un rythme d’adoption du Cloud plutôt lent, mieux vaut temporiser en s’appuyant sur l’outillage existant et en l’adaptant au cas par cas. Par exemple, des transferts de fichiers non automatisés peuvent suffire dans un 1er temps pour assurer le provisioning des identités. Cette stratégie évite d’investir dans des solutions peut-être non pérennes, au prix d’un surcoût modéré en opérations.

En revanche, si l’on souhaite adopter une démarche volontariste et cadencée vers le Cloud, il n’est plus possible de temporiser au risque de voir exploser ses coûts d’opérations. Il faut donc expérimenter ce que le marché sait fournir ! L’outillage Cloud-ready, qu’il permette l’intégration de données, la gestion des identités et le service management ou offre un portail de service, embarque de toute façon un ensemble de connecteurs vers  les fournisseurs du marché. Charge ensuite à l’éditeur de la solution de les maintenir à jour en fonction des évolutions apportées par les fournisseurs Cloud.

Dans tous les cas, un impératif : rester en veille permanente pour adapter sa stratégie aux évolutions des standards, à leur niveau d’adoption par le marché et aux mouvements de consolidation.

Cet article Sans maîtrise, le Cloud n’est rien… est apparu en premier sur RiskInsight.

Microsoft, géant de l’industrie logicielle, a lancé début 2010 l’outil Service Manager SCSM en s’appuyant sur sa suite System Center. Après une nouvelle version sortie début 2012 (SCSM 2012) et un Service Pack 1 disponible depuis janvier 2013, Microsoft confirme sa volonté de consolider sa position sur toute la chaîne de gestion des services IT. Pour autant, il n’apparaît pas encore dans le radar Gartner. Quel est donc le potentiel de cette solution ?

Quel sont les enjeux des outils ITSM ?

Les outils ITSM permettent à la DSI de se professionnaliser et d’améliorer sa qualité  de service, sa réactivité vis-à-vis des utilisateurs et de mieux piloter la production informatique.

Le choix et le déploiement d’un outil ITSM est impactant en termes de délai, les décisions doivent être prises avec un horizon à moyen terme (5 ans). De plus, c’est un outil visible, utilisé par de nombreux acteurs de la DSI et servant l’ensemble des utilisateurs. Dans un environnement d’entreprise de plus en plus changeant, l’enjeu d’adaptabilité de l’outil est donc primordial. Il doit apporter la souplesse permettant d’intégrer et de se séparer facilement de nouveaux périmètres, groupes supports et prendre en compte de nouveaux paramètres.

Le besoin de plus en plus prégnant de maîtriser les coûts informatiques et l’utilisation de plus en plus  large de services externalisés imposent également aux outils de répondre aux besoins de reporting et de mesure des SLA et OLA souvent complexes.

Le cloud en tant que tendance de fond se décline également sur les outils ITSM. Les solutions SaaS peuvent séduire des clients adeptes de solutions « clé en main ».

Enfin, les utilisateurs sont de plus en plus habitués à des interfaces user friendly pour leurs usages personnels. Ils deviennent de plus en plus exigeants sur l’ergonomie des outils professionnels. Les interfaces doivent donc être simples, intuitives et proposer des temps de réponse courts.

Le choix d’un outil sera donc guidé par les spécificités de chaque DSI, comme sa taille, son mode d’organisation (dispersion géographique, périmètres externalisés), ses engagements contractuels (catalogue et niveaux de service, impacts financiers liés à la mesure des engagements de services). L’enjeu pour les éditeurs sera de répondre à ces attentes diverses.

Qu’apporte la solution Microsoft ?

Tout comme ses principaux concurrents, System Center Service Manager 2012 permet d’outiller de façon intégrée les principaux processus :

• Front-office : gestion des incidents et gestion des demandes basée sur un module de gestion du catalogue de services.
• Back-office : gestion des problèmes, des changements, des mises en production et des configurations.

Du point de vue définition et design, les processus pris en charge sont basés sur MOF (Microsoft Operations Framework), largement appuyé sur le référentiel internationalement reconnu ITIL V3.

La spécificité de l’outil tient principalement à son appartenance à la famille Microsoft :

• Il est accessible à travers deux canaux dont l’interface est facilement prise en main car conçue dans « l’esprit » Microsoft : un client riche, ou console, à destination des équipes IT, et un portail web aux fonctionnalités plus limitées à l’usage des utilisateurs finaux.
• Il permet des interconnections natives avec les autres produits de la firme : l’Active Directory pour le peuplement de la solution, SCCM pour la gestion de configuration ou encore le portail Sharepoint pour le partage de la base de connaissance et la publication des reporting.
• La solution de reporting embarquée est l’un des atouts de cet outil. Basée sur les services de business intelligence issus de la technologie Microsoft SQL et elle permet d’automatiser la production des tableaux de bord publiables directement sur SharePoint.

Quelles entreprises peuvent en tirer le meilleur bénéfice ?

Le déploiement de cet outil met en avant la question du subtil équilibre à trouver entre l’adaptation de l’outil aux processus et l’adaptation des modes de fonctionnement de l’entreprise aux contraintes des éditeurs.

• Les possibilités d’adaptation de l’outil aux processus de l’entreprise éloignés des standards ITIL ou dotée d’une organisation avec de nombreux sites ou périmètres infogérés restent plus compliquées. Une personnalisation à l’aide du module « Authoring Tool » et de programmation XML devient nécessaire mais n’est supportée que lorsqu’elle est réalisée par Microsoft.
• L’ergonomie du portail web reste un point à améliorer au regard des capacités de Microsoft : le nombre de clic gagnerait à être réduit et une fois encore la personnalisation est difficile du fait d’une structure en Silverlight totalement verrouillée.
• D’un point de vue technique, l’interface web pour les utilisateurs n’est prise en charge que sur les plate-formes Windows Vista et ultérieures.

Compte tenu de ces caractéristiques, Microsoft répond plus particulièrement aux besoins d’entreprises souhaitant s’appuyer avant tout sur la console back-office ou aux entreprises de taille moyenne qui n’auront besoin que d’un faible niveau de personnalisation et qui pourront s’appuyer sur une solution clé en main et un cadre de référence standard.

Cet article Microsoft, challenger sur le marché des outils IT Service Management (ITSM) ? est apparu en premier sur RiskInsight.

« Allo Bernard ? C’est Jacques ! Ton pro est sur répondeur, heureusement Philippe avait ton perso.

Désolé de te réveiller, mais  notre SI est tombé. Apparemment, une mise en production s’est mal passée. Quelle application ? Aucune idée.

Philippe m’a chargé de mobiliser la cellule de crise. Du coup, tu peux regarder la procédure et appeler Simone avant de venir s’il te plait ? Rappelle-moi si tu ne retrouves pas le numéro. J’espère qu’elle sera là, c’est vraiment la galère on est en pleine clôture.

Envoie-moi un SMS pour me dire quand  tu arrives. Au fait, tu sais où on se retrouve ? Non ? À l’Atlantis, salle du conseil. On verra en arrivant comment on prévient les collaborateurs.»

Bien que fictives, ces quelques lignes – qui évoqueront peut-être à certains des souvenirs – mettent en évidence les points clés d’un début efficace de gestion crise et les difficultés afférentes.

En effet, les différents acteurs doivent réussir à se contacter, relayer une information exacte, obtenir de la visibilité sur les disponibilités et, éventuellement, alerter massivement les collaborateurs ; alors même qu’ils sont en situation de stress, pas ou peu préparés, que les procédures et annuaires sont oubliés voire non mis à jour et que les moyens de communication habituels ne sont pas forcément disponibles.

Impossible dès lors de s’assurer que l’alerte a été correctement transmise jusqu’aux derniers maillons et que la mobilisation suffit à adresser la crise rencontrée. Sans parler de la probable difficulté à informer l’ensemble des collaborateurs de l’organisation.

Au vu de ces difficultés, le recours à un outillage spécifique à ces premières phases de crise peut se révéler pertinent.

Industrialiser l’alerte : des outils offrant de nombreuses fonctionnalités couvrant différents aspects de la gestion de crise

On distingue classiquement deux besoins d’alerte distincts lorsqu’une organisation doit faire face à une crise. Le premier est de monter le plus rapidement possible la cellule de crise appropriée à la nature du sinistre. Le second est d’alerter largement ses collaborateurs –  éventuellement organisés en différentes populations – de façon pro active, tout en s’enquérant de leur condition (ce que ne permet pas l’usage d’un numéro vert).

Pour ce faire, il est possible de recourir à ce que les américains appellent un EMNS : Emergency Mass Notification System, ou outil d’alerte et de communication d’urgence, qui vise à éviter les écueils décrits plus haut grâce à différentes fonctionnalités.

En amont, un tel outil permet de définir des schémas d’alerte, listant les personnes à prévenir (sans limitation de nombre), l’éventuelle escalade, les moyens de communication à utiliser (mail, téléphone, serveur vocal interactif, sms voire fax, en distinguant les canaux principaux de ceux à activer en cas d’échec), et enfin la teneur du message, qui peut bien sûr être adaptée le jour J.

En cas d’alerte à déclencher, la personne d’astreinte dispose de différents moyens d’activation. Le principal est un portail internet, mais il est aussi possible de lancer une activation par d’autres médias (téléphone, sms, etc.).

Une fois l’alerte lancée, l’outil permet de suivre la progression du processus : échec ou succès des appels, retours des personnes contactées, etc.

Cette richesse fonctionnelle a pour contrepartie l’exploitabilité de la solution. Les interfaces sont riches et leur maitrise n’est pas immédiate, du moins en ce qui concerne le paramétrage.

La mise en place d’un tel outil peut aussi demander un investissement non négligeable, voire un développement spécifique pour assurer l’interface avec des éléments du SI de l’organisation comme l’annuaire des contacts. Les coûts d’entrée peuvent donc être élevés.

Au quotidien le coût est principalement constitué de l’abonnement, ces outils étant le plus souvent proposés en mode SaaS, notamment pour ne pas les exposer aux mêmes risques que ceux des clients. Les communications sont facturées à l’usage.

Un marché des EMNS loin d’être uniforme à travers le monde

Ces outils se sont principalement développés aux Etats-Unis, sous l’impulsion de réglementations fédérales (NFPA 72 2012 et DoD UFC 04-021-01). En mars dernier, le Gartner a mené une revue des EMNS présents sur le marché américain, qui a recensé plus de 50 fournisseurs ; 13 ont fait l’objet d’une étude détaillée, et 4 ont été positionnés dans le quadrant des leaders : Everbridge, MIR3, SendWordNow et AtHoc .

Pour autant, aucun de ces acteurs majeurs n’est présent en Europe, où l’on trouve généralement un acteur prépondérant par pays : Fact24 en Allemagne, AlarmTilt au Luxembourg, DolphinSystemsSikado en Suisse, etc.

Certains, comme Fact24 et AlarmTilt sont néanmoins présents sur le marché français, mais celui-ci reste atypique. Peu développé, il est en effet essentiellement adressé par des acteurs du telemarketing ou de la relation client qui ont su adapter leurs plates-formes à la transmission d’alertes (par exemple la solution GALA, qui équipe la majorité des préfectures, basée sur l’offre ContactEveryOne d’Orange ou la solution push SMS de Jet Multimedia).

Se positionnent également des acteurs issus de la surveillance et de l’alerte industrielle, avec des outils en mesure de s’interfacer avec différents canaux de communication pour proposer un service équivalent à un EMNS.

Consulter le marché pour trouver l’outil qui saura accompagner une organisation de crise définie au préalable

Avant d’envisager le recours à un EMNS, il est nécessaire d’être au clair sur sa gestion de crise et sur les modalités d’alerte et d’information de ses collaborateurs : acteurs mobilisés, messages délivrés, information avec acquittement de collaborateurs, etc. Comme à chaque fois, l’outil doit venir accompagner un processus en place, et non pas permettre de le définir.

Une fois ce pré-requis atteint,  le recours à EMNS est de nature à accélérer les phases d’alerte et accompagner le dispositif de crise. Ceci est d’autant plus vrai pour les organisations de grande taille, géographiquement réparties ou ayant des modalités d’astreinte complexes.

Reste dès lors à trouver le bon outil, qui saura répondre au besoin, être disponible le jour J, et dont on est sûr que les communications seront transmises, le tout à un coût raisonnable. Pour y parvenir, il faudra se demander quelles sont les fonctionnalités qui serviront à accompagner la gestion de crise, et être en mesure de les distinguer de celles qui constitueront un plus. Puis consulter le marché sur cette base pour trouver l’outil adéquat.

Cet article Alerter en cas de crise : faut-il passer par un EMNS (Emergency Mass Notification System)? est apparu en premier sur RiskInsight.

Qu’en est-il des aspects sécurité de la dernière mouture de l’OS ?

Les deux versions précédentes (Vista et Windows 7) avaient fait l’objet d’une communication sécurité appuyée.

Windows 8 ne déroge pas à la règle, et de nombreux détails sont d’ores et déjà connus : Microsoft annonce plusieurs évolutions substantielles des outils de protection, mais ce n’est pas là que se trouve la vraie révolution qui se prépare.

Des évolutions et de nouvelles fonctions de sécurité

Tout d’abord, les mécanismes existants sont presque tous améliorés (chiffrement BitLocker, contrôle des logiciels AppLocker, ainsi que l’ASLR qui charge le système dans des zones mémoire aléatoires pour éviter les attaques). L’antimalware Windows Defender sera capable de détecter de nouveaux types de logiciels malveillants, et le navigateur Internet Explorer 10 gagnera en robustesse.

Ces annonces ne changeront pas à elles seules le paysage sécuritaire de Windows. Une fonction faisant son apparition méritera tout de même une attention particulière : Windows-to-Go.

Elle permettra d’utiliser une version portative du poste de travail Windows 8 de l’entreprise, sur clé USB. Les opportunités d’usage sont multiples : fourniture d’un « poste virtuel » entreprise aux prestataires à moindre coût, tests applicatifs, clés prêtes à l’usage en cas de déclenchement d’un plan de continuité informatique… Il s’agit même d’une réponse possible aux problématiques de BYOD.

Malgré ces évolutions, les cellules de veille et de gestion de la sécurité, ainsi que les éditeurs de solutions ont encore de beaux jours devant eux : les failles de sécurité ne disparaîtront pas par magie à court terme !

Un renouveau par les fondamentaux

La base de l’OS a cependant pris un tournant significatif vers une sécurité plus moderne.

Si l’on peut se féliciter des améliorations apportées aux fonctions de sécurité, il faut reconnaître que d’autres changements touchant au fonctionnement-même de Windows, vont être les porteurs d’une sécurité « by design », moins monolithique, et intégrée au cœur du système.

Windows 8 adopte en effet une approche qui rappelle celles des principales plates-formes mobiles du moment :

• L’utilisation d’un « magasin » d’applications vérifiées, qui va tendre à assainir l’écosystème Windows, en tentant de trouver un équilibre entre contrôle des applications et liberté d’installation.
• Une  isolation inter-applicative permettant d’éviter qu’un programme malveillant en contamine un autre.
• Le Secure Boot, mécanisme n’autorisant Windows à se lancer que si la séquence de démarrage est vérifiée comme étant  intègre, offre une piste de réponse aux rootkits (ces virus furtifs qui s’installent dans les couches basses du système, et qui ont causé des dégâts dans plusieurs grandes sociétés ces dernières années). Windows 8 abandonne par ailleurs l’utilisation du BIOS historique, pour son successeur, l’UEFI.

C’est ici que se joue le futur de la sécurité de l’OS. Microsoft tente ainsi de se mettre à la page, y compris dans le monde de la mobilité après le démarrage poussif de Windows Phone 7.

La disponibilité de Windows 8 sur les PC et tablettes (peut-être les smartphones ?) sera donc un argument de poids, en particulier pour les entreprises souhaitant éviter une trop grande fragmentation de leur parc, et donc de leur sécurité.

Reste un obstacle de taille : la rétrocompatibilité. Même si Microsoft fait des efforts importants dans ce domaine, il faudra a minima des années pour que le parc, matériel mais surtout applicatif (en particulier les applications métier) s’adapte à ce modèle de sécurité, qui est donc plutôt une cible à long terme.

En attendant la sortie du système à l’automne, il est déjà possible de le tester facilement, par exemple sur une machine virtuelle, et se faire son avis sur les avancées et les opportunités à venir !

Cet article Windows 8 : des évolutions sécurité à court terme, une révolution à long terme ? est apparu en premier sur RiskInsight.