L’année dernière, j’ai eu la chance de travailler avec différentes organisations dans leur transformation du Cloud, et chacune d’elles a fourni à notre équipe de consultants Wavestone des idées et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.

Au cours de cette année, j’ai eu la chance de travailler avec différentes organisations dans leur transformation Cloud, et chacune d’entre elles a fourni à notre équipe de consultants Wavestone des retours d’expériences et des leçons clés sur ce que les systèmes de détection basés sur le Cloud peuvent et ne peuvent pas apporter à une organisation.

Pour cet article, gardez à l’esprit que nous considérerons tout changement de configuration conduisant à une dégradation du niveau de sécurité comme un incident. Bien qu’il ne corresponde peut-être pas à la définition exacte et habituelle d’un incident de sécurité, la mauvaise configuration d’un service public cloud (où les ressources et les données peuvent être directement accessibles par Internet) est un problème trop grave pour ne pas donner lieu à une alerte immédiate sur la sécurité du système d’information.

Embrassez les victoires rapides

Lorsque vous utilisez le Public Cloud des principaux fournisseurs (Amazon Web Services, Microsoft Azure et Google Cloud Platform), il est assez facile d’activer les fonctionnalités de détection natives et de d’obtenir une capacité de détection basique mais efficace. La plupart des éditeurs fournissent une plateforme de sécurité centrale qui vous permettra de détecter les erreurs de configuration  sur l’infrastructure que vous avez déployée, d’évaluer votre niveau de conformité par rapport à une norme donnée et de lever certaines alertes lorsque les incidents les plus typiques se produiront (voir plus loin). Il n’y a pratiquement aucune raison de passer sur ces fonctionnalités, qui sont parfois gratuites à activer (que ce soit pour un essai ou de manière permanente).

En outre, la journalisation est quasiment un non-problème dans votre feuille de route de sécurité. Les fournisseurs de cloud vous permettent généralement de diffuser les journaux de vos machines virtuelles (par l’intermédiaire d’agents), de vos composants PaaS (via une poignée de clics, ou de quelques paramètres dans vos modèles d’Infrastructure as Code) et du plan de gestion (management plane) de votre abonnement (souvent activé par défaut). Cela permet à votre équipe de sécurité de comprendre rapidement l’activité en cours sur la plate-forme et de commencer à construire sur la base des journaux pour obtenir quelques alertes. En outre, certains fournisseurs de cloud possèdent des systèmes SIEM (tels que Azure Sentinel) prêts à être branchés via des connecteurs pour les appliances et les sources de données externes. Ces systèmes SIEM analysent les journaux et retire  une partie du travail lourd nécessaire lors de la mise en place de la journalisation.

Saisissez l’occasion d’améliorer la sécurité dès maintenant

Une fois que vous avez appris les bases des outils natifs de détection Cloud, il est temps de construire votre propre expertise pour pouvoir compter sur vos propres outils ! Vous pouvez également vous appuyer sur des solutions tierces telles que les solutions de gestion de la posture de sécurité dans les Cloud (CSPM) et les configurer de manière à couvrir vos besoins.

Comme indiqué ci-dessus, les fonctionnalités natives des fournisseurs de services Cloud offrent quelques alertes de base qui peuvent aller loin. Avec AWS Guard Duty, vous pouvez détecter la compromission des jetons d’accès AWS EC2 ou un accès anormal aux seaux S3. Azure Security Center vous avertira lorsqu’une activité potentiellement malveillante est détectée sur une machine virtuelle, ou lorsque les comptes Azure AD sont susceptibles d’être pris en charge… Si vous devez être capable de détecter rapidement des attaques, il existe un moyen d’exploiter les alertes natives et prêtes à l’emploi disponibles (bien que certaines d’entre elles puissent nécessiter la licence premium après un essai gratuit).

L’un des principaux avantages de la détection du Cloud est que vous pouvez agir immédiatement en y remédiant automatiquement ! Par exemple, les erreurs de configuration sont une réelle source de préoccupation pour les équipes de sécurité, comme en témoignent les téraoctets de données qui ont fui par des seaux S3 accidentellement exposés. Alors pourquoi ne pas reconfigurer tout seau exposé, à moins qu’il n’ait été spécifiquement défini dans une « liste d’autorisation » ? L’automatisation vous permettra de détecter le modèle d’exposition, de lancer une fonction sans serveur qui corrigera la mauvaise configuration et pourrait même avertir le propriétaire de la ressource ou l’équipe de sécurité.

Cela peut être fait pour une mauvaise configuration, mais aussi pour une activité malveillante : si vous détectez qu’un jeton EC2 est volé dans les métadonnées d’une instance, vous pouvez temporairement lui retirer ses droits d’accès. Si vous constatez que la journalisation est désactivée, réactivez-la et verrouillez les comptes d’utilisateurs responsables. Cela vous permettra de réagir plus rapidement aux incidents de sécurité.

Bien entendu, vous devez encore travailler sur le processus global de gestion des incidents : à la fois sur la manière d’éviter la mauvaise configuration des services (par la formation des développeurs et les contrôles dans les canaux CICD s’ils existent) et sur la manière de les gérer une fois qu’ils se produisent (le modèle de fonctionnement est abordé plus loin).

Se rapprocher de l’entreprise et de l’amélioration continue

Le passage au Cloud est généralement un moment où les applications et les charges de travail devront à nouveau passer par un examen de sécurité pour s’assurer que l’architecture et la conception sont solides et sûres. Mais c’est aussi l’occasion de rendre la détection de sécurité plus pertinente pour l’application.

Pour que cela compte, mon conseil serait le suivant:

• Passer par le processus de « Service Enablement » pour les nouveaux services : comme le passage au cloud permet aux équipes commerciales et informatiques d’utiliser des centaines de nouvelles fonctionnalités et de nouveaux composants, il est important de réunir les architectes et les équipes de sécurité pour évaluer les principaux risques pour chaque nouvelle technologie, trouver des contre-mesures pour limiter ces risques et commencer à réfléchir aux alertes qui devront être mises en œuvre dans le SIEM ;
• Construire un catalogue d’alerte pour chaque scénario et composant de risque typique, la logique de l’alerte étant déjà prédéfinie et seules les spécificités de l’entreprise devant être personnalisées. Le « time to market » de la supervision devrait également diminuer, car une bonne partie des composants utilisés pour les opérations dans le Cloud est commune à la plupart des applications (machines virtuelles, bases de données, applications et fonctions sans serveur, systèmes de découplage) ;
• Tenez-vous au courant des attaques liées au Cloud afin de comprendre les dernières vulnérabilités et les chemins empruntés par les attaquants, et intégrez-les dans vos systèmes de détection.

Toutes ces spécificités applicatives doivent s’ajouter aux alertes transversales couvrant les fonctions essentielles de votre Cloud (IAM, mise en réseau, zones d’atterrissage, etc.). Pour vous aider à mettre en place cette capacité de détection du noyau, vous pouvez évidemment compter sur notre équipe, mais je vous recommande également de vous renseigner sur la communauté CloudSec, qui ne cesse de s’agrandir et qui partage son expertise en permanence grâce à des outils open-source (comme cette vue consolidée ) ou sur des plateformes en direct et en ligne (comme le Forum sur la sécurité dans le Cloud et son premier Fwd:CloudSec conférence cette année).

Mais tout n’est pas facile !

D’après tout ce qui précède, il peut sembler facile d’obtenir une compétence de détection et de réaction d’un Cloud solide. Cependant, certains défis restent à relever.

Le premier qui vient à l’esprit est la tarification. Souvent proposé comme argument de vente pour les programmes Move to Cloud, il n’est pas aussi facile qu’il y paraît d’estimer avec précision le prix que votre fournisseur vous fera payer pour les détections Cloud. Au fil des ans, de nombreuses solutions de sécurité des CSP sont passées à une tarification basée sur les composants pour les IaaS et à une tarification basée sur les transactions pour les composants PaaS. Le stockage des journaux et les alertes sont parfois encore plus complexes, car certaines solutions vous factureront en fonction du transit et de l’agrégation des journaux, tandis que d’autres vous factureront le nombre d’évaluations par rapport aux alertes que vous avez lancées. Un travail important est nécessaire pour déterminer un budget réel et ne pas faire faillite.

Le deuxième point essentiel est de comprendre ce que votre fournisseur offre et ce qu’il n’offre pas en termes de détection. Si la plupart des solutions prétendront résoudre tous vos problèmes d’un seul coup, c’est malheureusement loin d’être le cas. Et pour chaque cas d’utilisation de la sécurité, il faut savoir si l’option gratuite, si elle existe, vous convient, si l’option premium est nécessaire ou si vos équipes de sécurité peuvent se débrouiller seules. De manière réaliste, vous devrez commencer par l’option native, jusqu’à ce que votre équipe de sécurité soit suffisamment mature, en termes de Cloud, pour passer à un processus fait maison.

En outre, et c’est peut-être l’aspect le plus important, vous devez concevoir un modèle d’exploitation qui vous permettra de travailler avec plusieurs abonnements, plusieurs équipes/entreprises et éventuellement plusieurs fournisseurs de Cloud. De plus en plus d’organisations parallélisent leurs opérations en choisissant différents CSP pour différents cas d’utilisation, ce qui entraîne une complexité accrue pour les équipes de sécurité – car elles doivent gérer des incidents sur différentes plateformes, les responsabilités étant réparties entre les DevOps, les SecOps et les équipes sur site. Cela sera d’autant plus difficile qu’une mauvaise configuration entraînera des risques de sécurité immédiats et qu’il faudra choisir entre les opérations et la sécurité. En l’absence d’une division solide des tâches entre tous les fournisseurs et toutes les équipes, il y a de fortes chances qu’une petite erreur de configuration se transforme en une fuite de données importante.

Enfin, n’oubliez pas que la surveillance de vos applications dans le Cloud peut également créer des risques. Outre le verrouillage des fournisseurs, vous pouvez perdre toutes les fonctions de sécurité ainsi que vos applications si tout se trouve sous le même plan de gestion. Si les droits d’administration globale du locataire SIEM sont repris par un attaquant, il aura toute liberté d’affecter les ressources sous-jacentes (c’est-à-dire d’effacer les journaux, de désactiver les alertes ou de supprimer les capacités de correction). Il vaut la peine d’y réfléchir avant d’empiler votre SIEM et vos applications critiques sous le même toit.

Pour résumer, en fin de compte :

• Attrapez les fruits qui pendent : votre fournisseur de Cloud vous aidera à collecter et à consolider les bûches facilement. Il n’y a pratiquement plus d’obstacles techniques pour ne plus utiliser les bûches. En outre, activez les fonctions de sécurité de base fournies par votre fournisseur de services dans le Cloud pour détecter les attaques les plus évidentes.
• Développez votre maturité en matière de Cloud avec des équipes de Cloud : Le mouvement Cloud a poussé les équipes commerciales et informatiques (SecDevOps) à travailler plus étroitement que jamais. Adoptez cette philosophie en comprenant mieux les besoins des entreprises en termes de sécurité, en personnalisant les alertes et en automatisant votre réponse pour permettre à votre capacité d’évoluer.

• Optimiser les coûts et les modèles de fonctionnement pour exceller : La virtualisation a facilité de nombreux aspects techniques pour les équipes, mais les processus peuvent être difficiles à adapter. Veillez à concevoir avec soin votre modèle d’exploitation de détection/réponse aux incidents pour vous assurer que toutes vos applications et tous vos fournisseurs de services dans le Cloud sont couverts. Enfin, pensez à l’optimisation des coûts lorsqu’il s’agit de la gestion des logs !

Cet article Comment améliorer votre detection cyber en migrant dans le Cloud est apparu en premier sur RiskInsight.

Guy Bellot : Au cours des dernières années, dans une volonté d’industrialisation et de réduction des coûts, nos structures ont évolué vers des « centres de services » ayant recours à de l’externalisation. Les actions de massification ont mécaniquement entraîné une concentration de l’activité sur quelques grands fournisseurs qui représentent aujourd’hui une part significative de la dépense IT.
Au vu de l’importance de ces fournisseurs dans nos activités IT, il est devenu essentiel de pouvoir à la fois :

• Accroître notre écoute respective, augmenter la visibilité donnée sur les attentes du business et aider à anticiper les variations de charge ;
• Objectiver la qualité de service fournie, par une mesure régulière et partagée d’indicateurs, en intégrant la vision d’un service « de bout en bout » délivrés aux utilisateurs finaux ;
• Garantir indépendance et souplesse pour Carrefour en favorisant la comparaison avec le marché tout en challengeant réversibilité et flexibilité des modèles déployés.

En étroite collaboration avec la Direction des Achats IT, le VMO doit animer et renforcer la relation de Carrefour avec ses fournisseurs stratégiques (au nombre de 6).

Quels en sont les premiers résultats ?

GB : Initié au cours du deuxième semestre 2012, le VMO a tout d’abord conduit une phase pilote qui nous a permis d’étoffer notre connaissance de nos fournisseurs et de tester la mise en oeuvre d’indicateurs suivant le principe des Balanced Score Card (BSC).
À ce jour, 3 outils correspondant à 3 niveaux d’information distincts sont utilisés ou en cours de déploiement :

• l’enquête de satisfaction semestrielle, qui nous permet de capter la perception des équipes IT quant à nos fournisseurs ;
• la BSC, qui complète la perception d’indicateurs de mesures sur les aspects performance financière, satisfaction client, performance des processus, ainsi qu’innovation et amélioration continue ;
• et enfin le dossier de suivi fournisseur qui enrichit les informations précédentes par d’un côté les informations externes (analyses financières, informations de tendances communiquées par les cabinets, retours d’autres grands groupes) et de l’autre les informations communiquées par le fournisseur (sa perception de son positionnement, de ses forces et ses faiblesses, ses retours sur l’enquête de satisfaction et les plans d’actions qu’il propose de mettre en oeuvre).

Ces dossiers sont construits et partagés avec les fournisseurs et avec les directeurs IT des entités et pays Carrefour. Ils permettent d’initier puis de suivre des plans d’actions, induisant ainsi une dynamique plus forte dans la relation.

Quels enseignements, quelles recommandations pour d’autres DSI ?

GB : L’animation du VMO demande un changement d’état d’esprit dans la relation. Il faut privilégier la transparence, la recherche de synergies, la collaboration avec nos partenaires et entre les partenaires. En même temps, il faut rester vigilant aux attitudes opportunistes, aux visions trop court terme, et aux situations de concurrence entre ces partenaires. Les modèles de sourcing doivent permettre de maintenir l’équilibre (dual sourcing). Il faut aussi adresser les bons niveaux hiérarchiques pour partager l’ambition et leur permettre de s’inscrire dans une démarche qui va demander du temps et de la maturité. Une phase pilote avec peu de fournisseurs (2 ou 3) sur un périmètre restreint permet assez vite d’identifier les limites et de régler les ambitions réciproques, pour ainsi sortir du diktat du « Quarter ».

Cet article 3 questions à Guy BELLOT (Carrefour) est apparu en premier sur RiskInsight.

« Trop nombreux, trop coûteux à suivre, manquant de pertinence » : telles sont les perceptions des DSI sur l’usage des indicateurs pour mesurer la performance d’une prestation d’infogérance.

On note en effet une certaine dérive dans la prolifération des indicateurs mis au contrat pour pouvoir mesurer dans le moindre détail la performance des fournisseurs en oubliant le sens même des indicateurs. Que met-on derrière les indicateurs et en fait-on bon usage ?

1- Les indicateurs visent à aligner la performance des fournisseurs avec les enjeux de la DSI et s’appuient sur 3 principes : A chaque engagement du fournisseur doit correspondre un indicateur d’engagement ;

2- Chaque indicateur est associé à un seuil d’engagement minimum qui répond à un enjeu opérationnel ;

3- Certains indicateurs doivent être associés à un système incitatif d’amélioration continue à travers le calcul de bonus/malus.

Des indicateurs pas toujours pertinents

Le volume d’indicateurs doit être limité : « On ne peut pas tout mesurer ». La multiplication des indicateurs génère une surcharge liée au calcul et au suivi des indicateurs. Somme toute, il ne faut pas définir plus de 10 indicateurs par domaine ou ligne de service.

Par ailleurs, un indicateur doit être vertueux et être en ligne avec une attente de qualité de service. Il doit en outre inciter à une amélioration continue et doit se traduire par une contrainte raisonnable sur le prestataire (pour éviter des comportements non-productifs du prestataire). La « mesure du délai moyen de résolution d’un incident » en est ici un parfait exemple : l’attente opérationnelle est le respect des délais de résolution dans 95% des cas. La mesure du délai moyen de résolution ne met pas en lumière les cas où les délais de résolution sont dépassés et ne permet pas de mesurer la réponse à l’attente. Dans ce cas, mieux vaut préférer la « Mesure de la proportion des incidents où le délai de résolution est respecté ».

Mais tout ne peut pas être mesuré à partir d’indicateurs calculés. La perception globale de la prestation est également à prendre en compte et son appréciation par le pilote de la prestation est nécessaire. La mise en place d’indicateurs globaux qualitatifs permet de mesurer, par exemple, le niveau de réactivité/flexibilité du fournisseur, le niveau d’industrialisation et d’efficacité, le niveau de pilotage de la prestation et le niveau de conseil apporté. Chaque indicateur est une note attribuée selon un barème de notation précis et partagé avec le fournisseur.

Savoir être exigeant vis-à-vis des fournisseurs

Le respect des engagements fournisseurs (des indicateurs fournisseurs au « vert ») ne reflète pas toujours la satisfaction des clients des services délivrés. C’est ce qu’on appelle l’effet « pastèque ». Cette situation se rencontre si les indicateurs définis ne sont pas les bons ou si les niveaux d’engagement ne sont pas suffisants. Au cours de la prestation, il est donc nécessaire de rehausser régulièrement les niveaux d’engagement pour tenir compte de l’évolution des besoins client, des gains d’efficacité du fournisseur et également de l’état de l’art du marché. Cette pratique permettra de maintenir le fournisseur dans une démarche d’amélioration continue.

Appliquer les pénalités ne doit pas être vécu comme une dégradation de la relation

Le pilotage des engagements permet de mesurer l’alignement de la performance du fournisseur avec les enjeux de la DSI. Un autre levier d’amélioration de la performance est la mise en œuvre de système type bonus/malus. Des malus sanctionnent une performance en deçà des engagements et peuvent donner lieu à l’application de pénalités. Des bonus peuvent récompenser des réalisations « hors fourniture de qualité de service » et traduisant une performance au-delà des attentes (amélioration significative de la qualité du code confié, niveau de conseil élevé, etc.). Un bonus peut donner lieu à un avantage pour le fournisseur (exemple : facturation en partie à livraison). Attention cependant : la sur-qualité ne doit pas donner lieu à bonus.

L’une des solutions est de définir un nombre limité d’indicateurs qui seront soumis à pénalités (5 à 6) : seuls les manquements sur les engagements les plus critiques devront être sanctionnés.

Or, très souvent, on constate que les pénalités ne sont pas appliquées et sont négociées à l’amiable entre les opérationnels et les fournisseurs par crainte de dégrader la relation. Les fournisseurs étant très attachés au pilotage de la rentabilité et du chiffre d’affaires de leur contrat, l’application des pénalités est un moyen efficace de mettre en visibilité les difficultés rencontrées et de garantir un traitement au bon niveau.

Finalement, c’est le pilotage et l’ajustement régulier des indicateurs, des niveaux d’engagement et des dispositifs de pénalités qui permettra de trouver un équilibre dans la relation fournisseurs permettant de répondre aux enjeux de la DSI et garantissant une amélioration continue du fournisseur.

Cet article Fait-on bon usage des indicateurs pour piloter la performance des fournisseurs ? est apparu en premier sur RiskInsight.