How to ensure the security of your applications despite outsourcing their development?

Integrating security into projects is an important process for companies to define and integrate security aspects into products as early as possible. This avoids increasing the cost of remediation if it has not been planned and is implemented at the end of the project.

In the context of developments, Agile Security and DevSecOps define the processes and tools to be put in place to integrate security as early as possible, as presented in our previous article giving examples.

These methods are often defined on internal developments. However, it is often the case that companies call on external service providers to develop a particular application or functionality. In this case, it is important to ensure that these providers follow rigorous security practices and that they integrate security into their development processes to the same standards as the requester. This leads to the following question:

External developments: how to maintain confidence in externally developed code?  

In the remainder of this article, external code is defined as all code elements that have not been developed through an internalised CI/CD chain. For example, a freelance developer using the internal CI/CD chain or an enterprise workstation is not considered external code.

In addition, we will consider two models of application delivery depending on the development model used by the provider:

• delivery of the source code itself
• delivery of the executable, i.e. the already precompiled code

It is important to note that these two application delivery models have different implications in terms of cyber security and DevSecOps.

Code delivery

In the case of code delivery, external providers hand over the code they have written, usually in the form of source files (e.g. .java files for Java code), to the company. The company can then audit, compile and deploy the code on its own servers.

Code delivery has several advantages. The first advantage is flexibility: by delivering the source code, the company can easily make changes and customisations to the code. It can also integrate the code into its existing development and deployment environment (CI/CD) containing all the pre-configured security tools.

The company then does not have to place its trust in the security of the provider’s CI chain over which it has no control. In addition, the company with access to the source code can also audit it and thus verify that it is secure. These audits tend to be more comprehensive as the auditor has access to much more detail about the operation of the code and can perform both static and dynamic analysis of the code.

On the other hand, code delivery has some disadvantages. The company must have the skills to adapt the build and deployment stages to the production context. If these skills are not available in-house, this can lead to additional costs.  

Here are some good practices to maximise confidence in the delivered code:

• Share as early as possible (contract, kick-off meeting) the expected requirements on security in development, software versions, internal tooling used for deployment, confidentiality of source code, etc. Some clients require external developers to have a certain level of certification or training (for example, a level of training on Secure Code Warrior, in a certain programming language).
• Define and contractualise commitments on the remediation processes for identified vulnerabilities after code delivery and the associated monitoring (monitoring tools, SLAs, etc.)
• Implement a hash or signature type control on the code sent to ensure its integrity and define the methods for secure transfer of the source code with the service provider
• Integrate the code received into the existing CI/CD chain, including the Infrastructure as Code (IaC) files
• Carry out the functional security tests initially defined during the threat modelling: Evil User Stories and Security Stories

Some organisations may be faced with a situation where the notion of external developers corresponds to developers from other entities within the same group. These entities may have their own CI chains but depend on the CD or CI/CD chain of the central production team.

In these cases, an interconnection of the different CI chains to the central CI/CD chain can be considered. This solution allows the different teams to develop with the tools that best suit them.

The level of security provided by the project CI/CD chain is ideally equivalent to that of production but this is not necessarily the case. The production CI/CD chain controls the code to be deployed.

However, security control is often carried out too late in the development process. To ensure effective security in developments, it is crucial to ensure that security is integrated from the beginning of the development cycle (shift-left). To address this, it is recommended to provide self-service security tools for project teams to identify vulnerabilities early in their development using the appropriate target tools.

Otherwise, the security tools in the production CI/CD chain will ensure compliance with the group’s rules without slowing down the production release if automated security controls have been put in place within the project chain.

This solution also allows production to ensure the use of images (systems, docker, etc.) or artefacts (libraries) validated by the company.

These interconnections between the different pipelines can, for example, clone the branch to be deployed by the product team in order to push them into the CD chain. However, the production teams must have the appropriate rights. Technically, the model for managing the rights granted (ideally temporarily) must meet both the need to facilitate execution and the need for rights provisioning (manual vs. automatic), while limiting access to all branches or projects in order to respect the principle of least privilege.

Most of the good practices mentioned above also apply to reduce the time to production.

Although the methods described above appear to be the most effective for gaining control over applications developed by third parties, companies sometimes find themselves receiving executables without access to the source code. This may be due to licensing restrictions, for example. In this case, some of the good practices outlined above do not apply, and it is necessary to rethink how to integrate changes into production so as not to neglect certain security aspects.

Executable delivery

In the case of executable delivery, external providers hand over an executable file (e.g., an .exe file for Windows servers) that can be directly executed by the company without compilation. This delivery method is often used for commercial software that still requires some configuration adjustments.

In this context, the integration in the deployment chain is much more limited and only a few classical CD steps can be performed without the security steps of the CI chain being verified:

• Performing an artefact scan
• Performing a DAST scan to detect the most common vulnerabilities
• Performing penetration tests

Reports from the security tools of the development provider’s chain can also be requested. This must be included in the service contract, along with the security requirements for the level of security of the code.

Finally, a signature of the code to ensure its integrity is necessary at the time of the exchange and the executable. For this purpose, it is better to use signatures via certificates rather than hash prints, since the latter make it possible to verify the origin (non-repudiation) in addition to the integrity of the executable.

In conclusion, it is important for companies to ensure the quality and security of the code delivered by external providers, especially when the latter are developing code on external CI chains. There are several ways to convince yourself of the security of the delivered code:

• Clear and precise contractual clauses can help define the expectations and responsibilities of each party with regard to the quality and security of the code.
• Sharing specifications and security expectations with external providers can also help ensure that the delivered code meets the company’s requirements.
• Integration with internal development chain tools can facilitate verification of code quality and security, as well as the implementation of automated testing. These integrations raise both technical and process challenges that must be anticipated to facilitate the deployment of external developments.

By implementing these different approaches, companies can increase their confidence in the code delivered by external providers and ensure the security of their application.

Cet article Stay in control of your external developments est apparu en premier sur RiskInsight.

Un projet de sourcing ne se résume pas à la signature d’un contrat avec un prestataire : certaines bonnes pratiques s’avèrent indispensables à  la réussite d’une externalisation. Découvrons en 10 points clés comment bien réussir une stratégie de sourcing.

1 – Définir des objectifs précis et alignés avec les orientations stratégiques de l’entreprise

La définition d’une stratégie de sourcing n’est pas une finalité en soi. En effet, elle doit répondre à des objectifs clairement définis et alignés sur les enjeux globaux de l’entreprise, comme par exemple : améliorer l’alignement et l’agilité face aux métiers, réduire les coûts, améliorer la qualité de service, exploiter des opportunités de mutualisation, massifier le nombre des fournisseurs et professionnaliser les achats de prestations, repositionner les internes sur des métiers à (plus) forte valeur ajoutée / sur les compétences cœur de métier…

2 – Prendre en compte les aspirations des collaborateurs

Aucune conduite du changement, aussi parfaite soit-elle, ne pourra modifier complètement les aspirations des collaborateurs. En effet, pour certains collaborateurs, le « faire » est garant de maîtrise et d’épanouissement professionnel à l’inverse des managers pour lesquels le « faire-faire » est un aboutissement.

Sans devenir un point bloquant lors de la définition d’une stratégie de sourcing, les aspirations des collaborateurs peuvent néanmoins devenir, en fonction des périmètres, un facteur limitant pour l’ajustement de la trajectoire.

3 – Être réaliste sur la capacité d’évolution des collaborateurs

La reconversion de certains collaborateurs peut s’avérer difficile, surtout lorsqu’il s’agit de profils faiblement qualifiés et positionnés sur un même poste durant de nombreuses années. En effet, les compétences qu’ils ont développé ont parfois un champ très restreint et/ou spécifique. Malgré des formations adéquates et ciblées, ils n’auront vraisemblablement qu’une faible capacité à développer de nouvelles compétences. Par ailleurs, la solution de contournement par une externalisation d’activité avec transfert de personnel, un temps pratiquée par certaines entreprises, n’est quasiment plus d’actualité, en particulier dans des structures où les IRP ont un poids important.

4 – Donner une place centrale à la conduite du changement

De manière très classique, de nombreux collaborateurs vont développer une certaine résistance aux changements liés à la mise en œuvre d’une nouvelle stratégie de sourcing. Des phrases comme « c’était mieux avant », « la qualité de services s’est dégradée » ou encore « les managers sont trop loin de la réalité terrain » deviennent monnaie courante. Pour réussir la mise en place d’une stratégie de sourcing, la conduite du changement doit occuper un volet central de la transformation : elle se prépare en phase de cadrage et doit se lancer en parallèle de la phase d’étude.

5 – Définir le bon rythme de transformation, tout en demarrant fort

Il n’y a pas de règle préétablie : le choix du rythme d’une transformation du sourcing doit être adapté au contexte. Le bon rythme doit être cohérent avec les objectifs de la stratégie de sourcing (cf. règle 1) et tenir notamment compte des paramètres liés au capital humain (cf. règles 2 à 4). En effet, l’analyse des aspirations, de la capacité à évoluer et à conduire le changement amène souvent les DSI à envisager une démarche progressive, en douceur. Pourtant, cette approche des petites victoires successives, qui peut être très pertinente dans certains contextes, n’est en effet pas à privilégier.

« Démarrer fort » est une approche très efficace pour lancer la dynamique de transformation. Pour autant, cela ne signifie pas tout transformer d’un seul coup. Il faut savoir choisir « ses combats » en commençant par des transformations à forte valeur ajoutée et en ligne avec les objectifs prédéfinis, surtout quand il s’agit d’une transformation profonde de l’existant.

6 – Piloter la trajectoire avec une structure dediée

Une fois le bon rythme de transformation identifié, la difficulté va être de réussir à le maintenir et à réaliser en permanence les ajustements adéquats durant le projet. C’est une des raisons qui pousse à mettre en place une structure de pilotage dédiée, objectivée sur la réussite du projet de transformation (échéance, gains…) et dont un des rôles majeurs sera justement d’être le garant du rythme. « L’événement » lié à la mise en place d’une telle structure matérialisera également cette volonté de « démarrer fort ».

Au-delà d’être garant du rythme de la transformation, le pilotage devra également veiller à la montée en puissance des nouveaux modes d’externalisation mais aussi à la baisse des anciens, afin de garantir une réelle transformation et non une génération de coûts supplémentaires liée au maintien des deux dispositifs…

7 – Mettre en place un véritable suivi des gains

Afin de sécuriser le ROI défini au travers des différents business cases, un suivi des gains devra être mis en place. Il ne devra pas se limiter à la traduction des objectifs de gains dans chacun des appels d’offres lancés durant la phase de consultation du marché. Il est également primordial de suivre régulièrement les gains escomptés, et ceci pendant toute la durée des contrats d’externalisation. Ce suivi est généralement confié à une cellule VMO (Vendor Management Office) chargée de piloter l’ensemble des contrats d’externalisation d’une manière transverse. À ce titre, des représentants de cette cellule participeront aux comités de pilotage avec les différents fournisseurs et seront partie prenante des discussions financières.

8 – Établir une stratégie de sourcing « dynamique »

L’obtention d’une cartographie fiable de l’existant et de la baseline financière associée constitue généralement déjà un challenge en soi. Une erreur classique est alors de construire la stratégie de sourcing uniquement sur cette base ! En effet, le SI va continuer à vivre et la photographie de l’existant ne va pas rester figée. L’enjeu va donc être de s’assurer que les opportunités de sourcing identifiées restent bien cohérentes au vu des évolutions majeures à venir sur le SI.

9 –  Externaliser des activités maîtrisées

Un des principes de base du sourcing est d’externaliser des activités maîtrisées en interne : « on n’externalise pas un problème ! ». Ce principe vise simplement à éviter toute dépendance envers un fournisseur et à maîtriser les risques liés à la défaillance de certains fournisseurs (un recours potentiel pouvant toujours être une reprise en interne de l’activité en question).

10 – Anticiper la montée en compétences des internes sur les aspects de pilotage de contrats

En complément de la mise en place d’une cellule VMO au sein des Achats pour renforcer le pilotage des fournisseurs, il est essentiel d’anticiper la montée en compétences des équipes opérationnelles sur le volet pilotage de contrats. Passer d’un pilotage de ressources avec engagement de moyens à un pilotage en mode engagements de résultat est loin d’être naturel. Il faut donc donner les clés aux opérationnels en terme de posture, niveau de suivi, outils de pilotage…

Certains penseront probablement que ces dix règles d’or frisent la trivialité. Et pourtant, le constat est que dans ce type de projets, il est facile d’oublier les bases clés. Bases clés sur lesquelles repose la réussite d’une externalisation dans les règles de l’art. « À force de sacrifier l’essentiel pour l’urgence, on finit par oublier l’urgence de l’essentiel » (Edgar Morin).

Cet article DSI : 10 règles d’or de votre stratégie de sourcing est apparu en premier sur RiskInsight.

La standardisation est l’une des caractéristiques du Cloud. Si l’entreprise veut en tirer tous les bénéfices, opérationnels comme économiques, elle doit accepter et faire accepter aux utilisateurs un degré de standardisation important. Le déploiement du Cloud en entreprise implique un changement de posture pour la DSI et une évolution radicale dans les mentalités, au sein des équipes informatiques comme du côté des Métiers.

Le challenge principal pour les équipes de maîtrise d’ouvrage et de conception du SI va avant tout être de trouver le bon point d’équilibre entre les besoins de personnalisation des services Cloud et le niveau de standardisation imposé par les fournisseurs.

En outre, les équipes informatiques vont devoir apporter toute leur expertise pour mettre en cohérence des Clouds multiples et ainsi former un SI homogène. Bien qu’habituées à des environnements complexes, elles devront également intégrer un cadre moins flexible qu’auparavant.

Faire évoluer les fonctions techniques

Avec le développement du Cloud, la spécialisation des compétences est de moins en moins d’actualité : la tendance est au profil multi-généraliste. On le voit par exemple avec la mise en place de services SaaS, comme la bureautique et la messagerie : le besoin d’experts techniques sur ces périmètres auparavant internalisés est de plus en plus faible.

Avec un SI hybride, intégrant des services Cloud et des composants hébergés en propre, la coordination technique devient un enjeu majeur. Ce sera tout particulièrement le cas sur des actions opérationnelles comme la mise en œuvre des changements ou la résolution des incidents. La présence de ces profils techniques, capables de comprendre ce SI multi-facettes et de coordonner les fournisseurs, constituera même très vite un impératif pour la DSI.

On assistera aussi à la montée en puissance de profils techniques très spécifiques, conséquence directe de l’évolution de l’architecture du SI dans le contexte Cloud. Les compétences d’intégration technique des SI (architecture, orchestration, intégration de données, etc.) vont ainsi être amenées à se développer, avec un objectif clé : garantir la cohérence du SI. Des compétences sécurité (fédération d’identité, gestion des habilitations) vont également se développer.

Renforcer les fonctions de management des services

Le phénomène d’externalisation, croissant ces dernières années, a poussé au développement de compétences de pilotage des activités externalisées, mais aussi à une réduction de la prise en charge en interne des activités opérationnelles de la DSI (production, développement…).

Cette transition du « faire » au « faire faire » est encore plus marquée dans un contexte Cloud, où le niveau de standardisation requis va imposer à la DSI d’industrialiser encore plus ses activités. Les démarches de définition et de mise en place de services et de lignes de services ont conduit à l’apparition de fonctions de type « Service Manager » ou « Service Delivery Manager », dont le rôle est de coordonner la production du service et sa bonne fourniture au client.

Ces rôles doivent fortement se renforcer sur le pilotage des volumes consommés afin d’accompagner avec proactivité les clients dans la gestion de leur demande. De cette manière, les service managers peuvent être responsabilisés sur l’équilibre économique de leur service et plus seulement sur les engagements de qualité de service et de performance opérationnelle.

Anticiper dès aujourd’hui les impacts RH du Cloud

Il est crucial de bien accompagner la transition des compétences associées aux externalisations croissantes induites par le Cloud. Une méthode classique consiste à mettre en place une démarche de Gestion Prévisionnelle des Emplois et Compétences (GPEC), aussi connue sous le nom de Talent Management.

Pour analyser l’impact RH lié au Cloud, les DSI doivent justement se doter d’une véritable cartographie de ces emplois et compétences. Les déformations RH provoquées à court terme par les décisions connues en matière de Cloud peuvent ainsi être évaluées et faire l’objet de plans d’actions de redéploiements optimaux.

Par ailleurs, une identification des impacts potentiels à moyen / long terme doit être réalisée. Elle permet d’évaluer les plans d’actions RH et management à dérouler en matière de mobilité, formation, gestion de carrière et objectifs. Autant de transformations à prendre en compte.

Cet article Cloud : une nécessaire transformation des compétences et des pratiques est apparu en premier sur RiskInsight.

L’offshore implique un engagement pluriannuel qui refroidit les DSI en temps de crise

Un tout premier élément de réponse réside simplement dans le fait que, contrairement à une idée reçue, les DSI ont plutôt tendance à ralentir ou retarder leurs opérations d’outsourcing en période de crise. La taille et le nombre d’opérations a ainsi significativement baissé sur l’année 2012 par rapport à 2011 (la baisse serait de l’ordre de 19 % au niveau mondial selon le cabinet Everest Group). Et ce ralentissement est d’autant plus significatif que le marché avait déjà marqué un sérieux coup de frein en 2011.

La raison de cette tension sur le marché de l’externalisation est assez simple : en période de crise, les entreprises sont beaucoup plus frileuses à signer des contrats pluriannuels. En effet, la mise en œuvre de ces contrats nécessite généralement des investissements importants. Investissements que les DSI ne sont pas en mesure de prendre (ou de justifier) en période de crise, et qui vont venir « dégrader » le ROI de l’opération, les gains économiques n’intervenant qu’à moyen terme, et donc pas sur le budget de l’année suivante. Il est clair que ce ralentissement a un impact sur la progression de l’offshore. Les grandes SSII « indiennes » tablent ainsi sur une croissance beaucoup plus faible de leur chiffre d’affaires en 2012 par rapport aux exercices précédents.

On peut pourtant se demander si ce ralentissement global du marché de l’outsourcing ne porte pas en lui le germe d’une augmentation de la part d’offshore dans les services IT. Ne serait-ce que sous l’impulsion des grandes SSII américaines et européennes qui, déjà très largement implantées dans les destinations offshores, pourraient accélérer le mouvement pour préserver leurs marges.

Des chiffres qui sous-estiment la réalité du marché

Il est cependant extrêmement difficile de savoir précisément quelle est la part de l’offshore dans les services IT. Le SYNTEC n’a d’ailleurs publié aucun chiffre sur le sujet depuis 2008 ! Selon les cabinets d’étude, cette part varie de 5 à 10% sur le marché français en 2012, et certains annoncent que l’offshore représentera 15% des services IT en 2014. Il semble assez clair que cette part est aujourd’hui sous-estimée. Un grand nombre d’études ne prend en compte que les prestations externalisées directement en offshore, faisant ainsi abstraction de la réalité opérationnelle. Les grands prestataires de services IT ont ainsi tous mis en place des modèles de production mondialisés dans lesquelles des « usines » onshore, nearshore et offshore interagissent entre-elles pour délivrer les services. Nombreuses sont également les SSII occidentales qui sous-traitent certaines activités auprès d’acteurs offshores locaux. Par ailleurs, les effectifs offshores des plus grandes SSII occidentales représentent déjà souvent plus de 30% de leurs effectifs totaux. Enfin, l’apparition de toutes les offres de type cloud, où par essence, les services sont délivrés par une main d’œuvre dont la localisation est complètement transparente pour les clients vient encore perturber la donne.

L’offshore : une solution à anticiper !

Finalement, en cette période de crise, le véritable frein à la progression de l’offshore dans la part des services IT se situe chez les donneurs d’ordre. D’abord parce que les impacts sociaux et la montée des tendances protectionnistes (on l’a vu récemment aux États-Unis) peuvent ralentir (voire ajourner) la mise en œuvre de ce qui est vécu comme une délocalisation dans l’opinion publique. Mais surtout parce que faire le choix de l’offshore ne peut pas être un choix purement opportuniste. Ce choix nécessite en effet de faire évoluer l’organisation de la DSI ainsi que sa stratégie de sourcing pour s’adapter aux spécificités de ce marché (différences culturelles, services standardisés, gouvernance et pilotage renforcé…). La courbe d’apprentissage n’est pas simple et les échecs restent assez nombreux tant d’un point de vue opérationnel, que d’un point de vue économique (notamment si on n’a pas anticipé sur le coût complet des services).

L’offshore ne peut donc être un choix de crise que si la DSI si est préparée en amont.

Cet article La crise profite-t-elle à l’offshore ? est apparu en premier sur RiskInsight.

1 – Comprendre le cloud et démystifier ses complexités

L’actuel CloudWashing ne facilite pas la compréhension des différents modèles de services et des bénéfices réels que les grands comptes peuvent en tirer. C’est pourquoi, il est nécessaire de commencer par mener un état de l’art pour comprendre les principes de consommation de ressources banalisées prêtes à l’usage et de segmentation des ressources, les différences avec les précédentes approches (ASP pour le SaaS, outsourcing pour le IaaS) mais aussi les spécificités, niveaux de maturité, bénéfices et complexités propres à chaque modèle.

Contrairement à ce que l’on pourrait penser, les complexités à adresser dans le cadre du cloud public ne se limitent pas à la dimension technologique et doivent être adressées en continu  :

• Complexités organisationnelles : le rôle de la DSI passe du pilotage de ressources à celui de pilotage de fournisseurs (c’est là la fin du mythe du super administrateur !) ;
•  Complexités réglementaires : réversibilité contractuelle, confidentialité, contraintes sectorielles ou légales sur le stockage des données ;
• Complexités technologiques : services d’intégration au SI, forte dépendance au réseau, etc.

2 –  Identifier  les opportunités d’externalisation de services

L’état de l’art permet d’identifier les cas d’usages aujourd’hui possibles dans l’entreprise :

• Le SaaS de par les fonctions génériques qu’il propose est envisagé pour des besoins non spécifiques au cœur de métier avec une faible intégration au SI ;
• Le PaaS public de par l’hétérogénéité des services offerts et le manque de standards est considéré pour les besoins « jetables »  surtout pour des organisations qui ont déjà investi sur leurs filières de développement basées sur des technologies traditionnelles ;
• Le IaaS privé s’inscrit en continuité de l’industrialisation des infrastructures en permettant plus d’agilité via le self-service ;
• Le IaaS public  ou hybride permet quant à lui d’adopter une position de « broker » d’infrastructure modulant le coût et la QoS en fonction des besoins métiers tout en étant capable de fournir une réponse agile à un besoin ponctuel de débordement de capacité.

Il est alors possible de s’appuyer sur un modèle comme SOI (méthodologie de catalogue de services) pour décliner les opportunités d’externalisation de services dans le cloud.

3 –  Affiner le périmètre éligible et définir la cible

Cette troisième étape commence par l’inventaire des critères d’éligibilité techniques et métiers (criticité des applications, environnements de développement, DMZ, étude des coûts …). Le business case est une étape clé et peut notamment révéler des coûts d’exploitation plus importants (par exemple dans le cadre du IaaS dès lors que l’utilisation des serveurs est intensive). L’application de ces critères permet alors de construire et de prioriser un portefeuille de projets. Une démarche usuelle mais avec des spécificités  propres au cloud s’impose :

• Commencer les déploiements par un périmètre pilote afin d’instruire plus facilement et à plus petite échelles les changements organisationnels ;
• Identifier des quick wins opportunistes et les adresser à l’issue du pilote sur des applications avec peu de contraintes technologiques ;
• Puis généraliser les déploiements et mener une politique du changement.

4 – Transformer le SI pour le cloud

Dès lors que les déploiements en mode cloud vont se généraliser, des applications de plus en plus en lien avec le cœur du SI vont partir vers le cloud. Se pose alors la problématique d’intégration aux services du SI. Les transformations à opérer sur le SI seront alors la prochaine étape dans l’odyssée vers le cloud …

Cet article 2012, l’odyssée du cloud : comment bien préparer votre voyage ? est apparu en premier sur RiskInsight.

Force est de constater que la sécurité n’est plus un frein à sa propre externalisation. Les principaux risques que craignaient les RSSI il y a encore quelques années peuvent désormais être maîtrisés.  À condition bien entendu de respecter quelques règles d’or acceptées par la plupart des fournisseurs : engagement de réversibilité, clauses d’audit, mécanismes de suivi des SLA et certifications des fournisseurs …

Le RSSI n’a que l’embarras du choix : il est aujourd’hui possible d’externaliser quasiment tous les services imaginables en termes de sécurité opérationnelle. Mais alors que doit-on externaliser, et pourquoi ?

Externaliser pour rationaliser

Depuis des années, les entreprises font appel aux MSSP (Managed Security Service Providers) pour gérer leurs infrastructures sécurité : management du parc de firewalls, surveillance des consoles anti-virus et des IDS…

Ces fournisseurs, tirant partie de leurs nombreux retours d’expérience, proposent aujourd’hui des offres totalement packagées et industrialisées. La mutualisation de leurs ressources et processus permet d’optimiser les coûts, à tel point qu’aujourd’hui les business case penchent quasi-systématiquement en faveur de l’externalisation !

Et l’industrialisation pourrait encore aller plus loin… avec le marché des SecAAS (Security-as-a-Service). Ces « nouveaux entrants » ne se limitent pas à la gestion des infrastructures, mais fournissent directement des mesures de protection dans le Cloud (filtrage web, messagerie sécurisée, authentification forte…). Leurs clients peuvent ainsi bénéficier de tous les avantages hérités du Cloud (mutualisation, optimisation, flexibilité…) tout en réduisant le coût de l’exploitation de leur infrastructure.

Externaliser pour mieux se protéger

Paradoxalement, l’externalisation peut même avoir comme objectif premier d’augmenter le niveau de sécurité… en tirant partie de la vision globale, inter-clients, des MSSP.

Il s’agit de confier à un MSSP la surveillance de l’infrastructure sécurité, qui lui-même dispose d’une vue sans pareille sur l’actualité du monde de la cybercriminalité. En effet, les grandes entreprises doivent désormais connaître les nouvelles menaces en temps réel et être en capacité de réagir en cas d’attaque. Une conséquence évidente de l’évolution des attaques constatée ces dernières années.

Les MSSP leaders du marché ont compris l’importance de ce changement et ont structuré leurs offres autour de leurs connaissances du monde de la cybercriminalité (affiliation aux réseaux de CERT, présence sur les forums underground, déploiement de réseaux de sondes dans le monde…).

La surveillance des infrastructures de leurs clients ne se limite plus à l’administration d’outils SIEM (Security Information and Events Management) : les filtres de surveillance sont mis à jour au fil de l’actualité, sans se limiter aux comportements définis préalablement avec leur client. De même, les activités historiques de veille et de tests de vulnérabilités sont largement complétées : les vulnérabilités des clients sont désormais analysées en connaissance des menaces réelles et la surveillance peut être adaptée tant que la vulnérabilité n’est pas corrigée.

La valeur ajoutée sécurité est évidente : les clients bénéficient d’une mise à jour constante de leur niveau de sécurité. Bien entendu, plus le nombre de clients du MSSP est élevé, plus le service devient pertinent. Il n’est donc pas surprenant que le marché soit aujourd’hui dominé par les grands fournisseurs anglo-saxons. Mais peut-être pas pour longtemps, ces derniers étant bousculés depuis quelques temps par les groupes Indiens qui tendent aujourd’hui vers des services performants avec des prix plus compétitifs.

Externaliser pour encore plus de valeur ajoutée

Les services proposés par les MSSP tendent à s’homogénéiser… voire même à se standardiser. Il est de plus en plus complexe de négocier des SLA particuliers, ou d’exiger des ressources spécifiques ou dédiées.

Cette approche mutualisée est très efficace tant que les services portent sur la sécurité des infrastructures, cependant elle est fortement limitée lorsqu’il s’agit de protéger les besoins métiers spécifiques. Le « sur-mesure » est indispensable pour lutter contre les menaces les plus avancées et pour protéger de manière fine les applications critiques de l’entreprise.

Aujourd’hui il n’existe pas d’acteurs majeurs capables de surveiller les applications ou de détecter les fuites d’information avec une vision métier. Peut-être ce marché est-il à la portée des MSSP français qui restent assez proches de leurs clients, avec des offres encore adaptables ?

Il est donc à la fois possible d’optimiser ses coûts et d’augmenter son niveau de sécurité en externalisant la sécurité des infrastructures. En revanche, sur le terrain de la sécurité applicative… les clients devront encore attendre ! Les fournisseurs externes sont en effet encore trop loin des enjeux métiers de leurs clients.

Cet article Externaliser la sécurité, oui mais dans quel objectif ? est apparu en premier sur RiskInsight.

Pourquoi les opérations d‘offshore IT sont-elles si complexes ?

Plus que des opérations d’externalisation classiques, les opérations d’externalisation offshore embarquent un degré de complexité supplémentaire.

Au-delà des objectifs strictement liés à la réduction des coûts, la stratégie de sourcing doit clairement identifier les besoins IT pour lesquels l’offshore constitue une réponse pérenne. Pour cela, il est nécessaire de clarifier les critères d’éligibilité à l’offshore, de sélectionner les destinations potentiellement éligibles et d’identifier le modèle de delivery des services adapté au contexte de l’entreprise et du système d’information. Tous les projets et / ou services IT ne sont pas, aujourd’hui, éligibles à l’offshore.

Le choix de la destination s’avère également déterminant :  l’enjeu consiste à trouver le meilleur compromis entre réduction des coûts et niveau de compétence / expertise tout en prenant en compte les différences culturelles et linguistiques, les contraintes locales du marché de l’IT, les contraintes légales.

En volume, l’Inde domine encore le marché de l’offshore mondial. Pour la France, les pays d’Europe de l’Est et le Maghreb constituent des alternatives à l’Inde et se développent rapidement pour des raisons de proximité culturelle et une politique active des gouvernements.

Quels changements l’offshore impose-t-il en termes d’organisation ?

Plusieurs business models sont envisageables, selon le contexte et l’implantation de l’entreprise  :

•  création d’une filiale locale en propre (captive),
•  externalisation auprès d’un prestataire 100 % offshore,
•  externalisation auprès d’un prestataire global s’appuyant sur son tissu d’usines locales et offshores.

Quel que soit le modèle retenu, il faut apporter une attention particulière au modèle de production des services et en particulier à l’articulation des relations
entre équipes locales et équipes offshore (front-office vs. back-office) pour garantir une adhérence maximale et un contrôle permanent des prestations offshorisées.

Au delà du modèle, il est par ailleurs indispensable de muscler sa gouvernance, tant contractuelle qu’opérationnelle, et de mettre en place des dispositifs de pilotage spécifiques des prestations. En effet, dans de trop nombreux contrats de service offshore, le management opérationnel des usines offshore reste « invisible » ou « intouchable » pour le client qui n’a accès qu’aux équipes de gouvernance française.

Il faut veiller à ce que cette « strate locale » de management soit directement intégrée aux processus de gouvernance avec le client.

Tous ces sujets impliquent une conduite du changement, tant pour lever les craintes et résistances potentielles des équipes internes qui vont subir une transformation en profondeur de leurs méthodes de travail que pour s’adapter au fonctionnement de ces usines IT.

Quels gains peut-on espérer ?

Une erreur encore trop largement commise consiste à comparer les seuls prix unitaires « français » au prix unitaires « offshore ». On constate pourtant que, bien que les tarifs journaliers soient en moyenne de 40 à 45% moins élevés qu’en France, les gains finaux pour l’entreprise sont moins importants. Les business cases doivent donc évaluer les gains en calculant le coût complet des services, incluant tous les coûts spécifiques liés à l’offshore :

•  coûts récurrents : surcoûts induits par une gouvernance renforcée des prestations offshorisées, surcoûts potentiels liés à l’industrialisation et à la standardisation des processus d’interaction avec le prestataire (gestion des incidents, gestion des demandes, gestion des projets…), pertes de productivité des équipes en offshore par rapport à la productivité des équipes locales…
•  coûts projets : coûts de mise en place du projet, coûts induits par le(s) transfert(s)  de connaissances…

Malgré ces surcoûts potentiels, et si la DSI s’est bien préparée, on observe une courbe d’apprentissage de l’offshore permettant
d’obtenir les gains escomptés après plusieurs années d’expérience, dans les meilleurs cas : 10% lors du premier projet offshore, 20 à 25% après 2 ou 3 projets.

Cet article Offshore IT : comment réussir son externalisation ? est apparu en premier sur RiskInsight.

Les cartes de paiement ont envahi notre quotidien, que ce soit pour les achats en magasin comme pour la vente à distance en particulier via internet Pour autant, cette généralisation de l’utilisation de la carte de paiement a entrainé une augmentation du montant total de la fraude de 9,8% par an en moyenne, pour atteindre 342,3M€ en 2009*. Les grands émetteurs de cartes comme Visa et Mastercard  se devaient de réagir et de proposer de nouvelles mesures de sécurité.

PCI DSS, un standard de sécurité exigeant…

Pour contrer cette augmentation des fraudes, les acteurs majeurs des cartes de paiement ont défini le standard de sécurisation PCI DSS, dont les objectifs sont les suivants :

• Réduire les risques de fuite de données bancaires en renforçant et uniformisant à l’échelle mondiale leur sécurisation
• En cas de fraude, déplacer les responsabilités des sociétés de cartes de paiement vers les garants de la certification PCI DSS (banques et sociétés d’audit)

Le standard adresse 12 thèmes classiques de la sécurité. Mais il est particulièrement exigeant ! Toutes les règles doivent être appliquées et elles sont précises. Durcissement des serveurs, revue quotidienne des logs, détection des points d’accès wifi pirates, sont autant de chantiers complexes à adresser dans le cadre d’une mise en conformité. D’autant plus que leur application est contrôlée à travers des audits annuels pour les sociétés réalisant plusieurs millions de transactions par an.

Quelle stratégie de mise en conformité ?

Au vu de cette complexité, notre recommandation est d’initier tout projet de mise en conformité PCI DSS par la réduction du périmètre d’application du standard. Pour cela, plusieurs méthodes se détachent :

• Aligner le périmètre applicatif avec les besoins métiers réels. Cet exercice  consiste à supprimer les données de cartes bancaires partout où leur présence n’est pas justifiée par un besoin métier réel.
• Désensibiliser les données de cartes bancaires. Il est possible de remplacer les données bancaires par une donnée non exploitable en cas de fraude –  troncature, hash, ou identifiant unique (token) – différente de la donnée bancaire. Des éditeurs se positionnent sur la fourniture de solutions de désensibilisation.

Cette étape effectuée, le périmètre d’application du standard PCI DSS se résume alors aux applications restantes et aux services d’infrastructures sous-jacents (réseau, postes de travail concernés, sauvegardes, base d’identifiants uniques…). C’est a priori sur ce périmètre que s’appliqueront donc les exigences de PCI DSS.

Sauf si…  la réduction de périmètre se poursuit à travers l’externalisation de ces ressources applicatives. Et cette externalisation pourrait même servir à améliorer les services offerts…

L’externalisation : une solution à PCI DSS ?

Historiquement implantés dans beaucoup d’entreprises pour assurer un rôle d’intermédiaire avec les banques, les PSP (Payement Service Providers) peuvent jouer un rôle majeur dans une stratégie de mise en conformité, dans la mesure où toutes leurs offres sont proposées en standard sur des environnements entièrement certifiés PCI DSS.

En particulier, les PSP sont aujourd’hui en mesure de proposer l’externalisation de tous les composants de la chaîne de liaison paiement par internet ou par téléphone : collecte des données, demandes d’autorisation et de paiement, contrôles anti-fraude avancés…

Et l’externalisation peut aller encore plus loin ! Les PSP proposent dorénavant des tables de correspondance « tokenizer » facilitant la désensibilisation des données carte de paiement. Lors de la collecte de données, un identifiant unique, personnalisable, est renvoyé à l’entreprise et peut donc circuler dans le SI sans aucune contrainte vis-à-vis de la norme PCI DSS.

L’externalisation permet ainsi de réduire de manière conséquente le périmètre applicatif, mais attention… ce n’est pas la solution ultime pour être conforme à PCI DSS.  Certaines populations conservent souvent le besoin d’accéder au numéro de carte depuis leur poste de travail, pour des raisons réglementaires, entre autres. Nous pouvons par exemple citer les services de lutte anti-fraude ou les téléconseillers, dont les terminaux devront sans doute rester dans le périmètre PCI DSS. Il est donc difficile de penser qu’aucun composant du SI ne manipulera de données cartes surtout dans une grande entreprise.

Mais bien plus qu’un simple levier de mise en conformité PCI DSS, un projet d’externalisation peut devenir stratégique pour l’entreprise en lui permettant de développer de nouveaux moyens de paiements (ex : cartes cadeaux), de nouveaux marchés internationaux (facilités de connexions aux acquéreurs étrangers) ou de nouvelles fonctionnalités (ex : paiement one-click sans renseignement des données CB). Le recours à ces acteurs peut aider à la conformité mais aussi faciliter de nouveaux usages.

*Ces statistiques sont issues du rapport d’activité annuel 2009 de l’Observatoire de la sécurité des cartes de paiement publié en Juillet 2010

Cet article PCI DSS : l’externalisation est-elle une solution ? est apparu en premier sur RiskInsight.

L’annonce faite le mois dernier par Thierry Breton n’aura échappé à personne : « objectif zéro mail en interne d’ici 3 ans ».

Selon de récents sondages, l’e-mail serait le 1^er outil informatique utilisé en entreprise. L’annonce du PDG d’Atos Origin a donc de quoi susciter l’étonnement.

Est il vraiment envisageable de parler de disparition de l’e-mail en entreprise  ?

Un constat évident : l’e-mail n’est plus adapté à l’usage qui en est fait

Aujourd’hui, l’e-mail est utilisé à des fins très variées : partage de documents, gestion de projets, échanges temps réel. L’utilisation de la messagerie électronique est devenue un réflexe, parfois inopportun, dont la conséquence est sans appel : boîtes de réception débordantes, beaucoup de temps passé à prioriser, classer, archiver… en un mot : inefficacité.

Par ailleurs, les tendances 2.0, poussées par les utilisateurs, privilégient d’autres modes de communication (chat, micro-blogging), et de collaboration (« coauthoring », sondage), jugés plus efficaces dans bien des situations.

Mais il reste le meilleur outil d’échange asynchrone

Principal moyen de communication au sein de l’entreprise, mais également avec les clients et partenaires, la messagerie est aujourd’hui une application critique et le demeurera.

Utilisé à bon escient, il est d’une efficacité imparable : simple, adapté aux situations de mobilité et maîtrisé par une très grande majorité d’utilisateurs. Autant d’atouts qu’il paraît nécessaire de remettre en valeur.

Une évolution en conséquence indispensable

Trois enjeux majeurs la justifient :

Rendre l’e-mail efficace

La place donnée au service de messagerie par rapport aux autres services collaboratifs doit lui permettre de retrouver son objectif premier : l’échange simple de messages asynchrones.

Répondre aux attentes 2.0 des collaborateurs

La pénétration d’offres web grand public dans le marché de l’entreprise accentue la pression des utilisateurs, souvent plus satisfaits de leurs outils privés que professionnels.

Tentées par l’émergence de ces solutions « clé en main », il n’est d’ailleurs plus rare de voir les directions métier être à l’initiative de projets liés aux outils collaboratifs qui « échappent » à la DSI.

L’enjeu pour la DSI sera alors d’entendre ces besoins, mais aussi d’en maîtriser les ardeurs.

Saisir les opportunités marché

L’émergence du Cloud Computing et des offres associées (SaaS, PaaS, IaaS) ouvre de nouvelles opportunités aux DSI désireuses d’optimiser leurs investissements.

Si l’attractivité de ces offres paraît indéniable (facturation à l’usage, gestion du service simplifiée), il est important de bien différencier les solutions d’externalisation (cloud public, cloud privé, infogérance classique) ainsi que d’en mesurer les bénéfices réels et les risques.

Externaliser ou non soulève de fait des enjeux d’une autre nature, que nous traiterons dans un prochain article.

Cet article Messagerie d’entreprise : quel avenir pour l’email en entreprise ? est apparu en premier sur RiskInsight.