Pourquoi chaque agence fédérale a besoin d’une stratégie en matière d’applications d’entreprise et comment en élaborer une

Introduction

Les responsables informatiques des agences fédérales américaines doivent trouver un juste équilibre afin de créer davantage de valeur tout en réduisant le gaspillage et en limitant les pertes dues aux cyberattaques. D’un côté, ils doivent adopter les technologies les plus récentes pour gagner en efficacité, créer davantage de valeur et économiser l’argent des contribuables. De l’autre, ils sont confrontés à un paysage des menaces en constante évolution et expansion, dont l’atténuation exige des ressources considérables. En somme, dans chaque initiative et chaque décision, ils doivent à la fois innover et protéger. Pour concilier ces objectifs apparemment contradictoires, les responsables informatiques fédéraux devraient élaborer une stratégie en matière d’applications d’entreprise adaptée à la mission de leur organisation.

Entrer dans l’ère des applications

65 % des personnes interrogées dans le rapport État des services applicatifs de F5 en 2019 ont déclaré que leur organisation était en pleine transformation numérique. La transformation numérique est une nouvelle façon pour les organisations d’utiliser la technologie afin d’améliorer considérablement leurs performances et la productivité des utilisateurs.

En bref, les applications deviennent l’activité ou la mission elle-même.

Pour tirer parti de cette transformation radicale, les organisations opèrent des changements de grande ampleur afin d’adopter de nouveaux modèles opérationnels pour leurs activités et leur informatique, tels que :

• S’appuyer sur des services SaaS tels que la messagerie électronique et les outils de productivité dans le cloud
• Conteneuriser les applications personnalisées afin de simplifier leur gestion et de réduire les coûts
• Utiliser des services de sécurité cloud pour détecter rapidement les attaques et appliquer des politiques conformes aux règles de l’organisation.

Les applications sont mises à disposition sur différents types d’appareils. Les utilisateurs qui y accèdent ne se trouvent plus dans les environnements d’entreprise traditionnels : ils sont mobiles ou travaillent depuis leur domicile. Les fonctions essentielles à l’activité, telles que les solutions CRM et ERP, ainsi que toutes les autres, doivent être accessibles en dehors du réseau d’entreprise traditionnel.

Le rapport 2018 de F5 Labs sur la protection des applications a révélé qu’un organisme moyen du secteur public utilise 680 applications, dont 32 % sont considérées comme critiques pour ses missions.

Outre cette croissance considérable du nombre d’applications, les organisations déploient celles-ci dans de nouvelles architectures et de nouveaux services. L’étude 2019 sur l’état des services applicatifs indique que 14 % des organisations interrogées ont fait des conteneurs leur approche par défaut pour l’isolation des charges de travail applicatives, et que 87 % des répondants adoptent une architecture multicloud. L’Office of Management and Budget (OMB) préconise lui-même une « stratégie Cloud Smart »¹ afin de migrer vers un réseau cloud sûr et sécurisé.

Comprendre l’expansion rapide de la surface d’attaque

Les organismes publics et les entreprises ne sont pas les seuls à utiliser la technologie pour simplifier les processus, proposer de nouveaux services et créer davantage de valeur. Les cybercriminels, les groupes militants et les acteurs malveillants soutenus par des États développent eux aussi leurs capacités de cyberattaque à une vitesse fulgurante. À mesure que nous améliorons la protection de nos réseaux et de nos infrastructures, les cyberattaquants se tournent vers des cibles plus vulnérables.

Les cibles vulnérables servent à infiltrer des actifs de grande valeur susceptibles de contenir des informations sur le personnel ou des informations classifiées. Les recherches de F5 Labs montrent que 86 % des cyberattaquants ciblent directement les applications ou dérobent les identifiants des utilisateurs, généralement par hameçonnage.²

Les attaquants découvrent qu’il est parfois plus facile d’attaquer indirectement. L’une des méthodes consiste à cibler des applications moins importantes, telles que les appareils IoT, afin d’élever leur niveau d’accès. C’est ainsi que des cybercriminels ont piraté un casino américain par l’intermédiaire du thermomètre d’un aquarium situé dans le hall, puis s’en sont servis comme point d’appui pour accéder à la base de données des gros joueurs.³ De même, la cyberattaque dévastatrice subie par Target en 2013 a commencé par l’exploitation d’une faille chez son prestataire de systèmes CVC et s’est soldée par la compromission du système de point de vente et le vol des données de 40 millions de cartes de crédit.⁴

S’ils ne sont pas gérés, les composants et services open source et autres composants et services tiers peuvent également présenter des risques. Le rapport « State of the Software Supply Chain 2018 » de Sonatype indique qu’un téléchargement de composant open source sur huit contient une vulnérabilité de sécurité connue.⁵ Les organisations, y compris celles du secteur public, tirent parti de l’open source, car il accélère le développement et la livraison. Cependant, ces mêmes organisations omettent souvent d’inclure les composants open source dans les analyses de sécurité et les processus de vérification. Ces composants font partie du portefeuille d’applications et doivent être examinés avec la même rigueur que le code personnalisé. Cela concerne aussi bien les composants côté serveur (par exemple, les packages NPM et les bibliothèques) que ceux côté client.

Alors que les applications jouent désormais un rôle plus déterminant dans la réalisation des objectifs d’une organisation, leur croissance dépasse la capacité de la plupart des organisations à adapter leurs opérations. Le modèle traditionnel de sécurité périmétrique n’est pas évolutif et son efficacité en matière de prévention des menaces est limitée. Dès lors qu’une cible vulnérable est compromise, les actifs de grande valeur sont menacés. Les nouvelles architectures et les nouveaux modèles de déploiement mettent encore davantage à l’épreuve les mesures de sécurité traditionnelles. Les applications sont déployées sur des sites dispersés et utilisent des services applicatifs multicloud afin d’améliorer leurs performances. Parallèlement, la surface d’attaque associée aux applications connaît une croissance exponentielle.

Une surveillance continue au plus près des applications et des cibles vulnérables est essentielle pour garantir la sécurité tout en préservant les performances. L’intégration d’une solution intelligente de sécurité dans le cloud peut fonctionner de concert avec l’application afin d’atténuer rapidement les menaces et de protéger les données sensibles. De petits volumes de données peuvent être envoyés dans le cloud afin d’identifier les menaces potentielles en les comparant à des millions d’artefacts qui y sont stockés. Cela permet de déterminer si un client est un bot ou un utilisateur réel.

Un service de réduction de la fraude peut fonctionner avec une application afin d’interagir avec des acteurs malveillants, de recueillir davantage de types de données et de prévenir la fraude à grande échelle. Le profil de fraude complet peut être transmis au système de surveillance continue de l’organisation afin de prendre les mesures nécessaires, d’empêcher la propagation de l’attaque, de localiser les systèmes compromis et d’indiquer les étapes à suivre pour éliminer la menace des machines infectées. Les analystes peuvent transmettre ces informations aux équipes opérationnelles pour une analyse plus approfondie.

Tirez parti du multicloud et du SaaS

Comme si les choses n’étaient pas déjà assez complexes, les agences fédérales se tournent vers des déploiements multicloud et SaaS afin de bénéficier d’une plus grande flexibilité et d’une meilleure disponibilité, de réduire leur dépendance vis-à-vis des fournisseurs et, dans certains cas, de profiter de coûts moins élevés. Toute la difficulté consiste à offrir une expérience applicative standardisée, sécurisée et fluide dans des architectures hybrides, multicloud et SaaS, sans dépasser le budget alloué.

Les agences peuvent utiliser leur solution de sécurité périmétrique au niveau des points de connexion Internet de confiance afin de sécuriser la connectivité aux environnements SaaS et multicloud. Cela peut entraîner des problèmes de performances, car les agences disposent d’un nombre limité de points de connexion. Pour des raisons de sécurité, les applications accessibles au public doivent transiter par ces points, ce qui introduit de la latence. Les avantages d’applications évolutives et hautement performantes sont ainsi annulés, puisque le trafic doit effectuer un « détour en trombone » à des fins de sécurité.

Les solutions périmétriques reposent également sur des signatures statiques. Si une nouvelle menace apparaît et qu’elle a été analysée par un fournisseur de services de sécurité cloud, les informations ne seront pas transmises au système périmétrique afin de prévenir l’attaque. Les signatures peuvent être mises à jour dans un délai d’un jour à une semaine. Des actifs de grande valeur peuvent être compromis avant que la signature ne soit finalement créée et mise à jour dans le système de sécurité périmétrique.

Standardisation des services applicatifs

La standardisation des services applicatifs multicloud et SaaS — les solutions mises en place pour sécuriser, gérer et optimiser vos applications — réduit la complexité opérationnelle inhérente à une architecture multicloud.

Par exemple, il est plus facile de gérer — et plus avantageux de disposer de — un service qui fonctionne au niveau des applications d’entreprise, comme l’invocation d’API par le code et les systèmes pilotés par les événements, qu’un service propre à une plateforme, qui impose par exemple l’utilisation d’un service de mise en file d’attente des messages spécifique à un fournisseur. Le déploiement d’un même ensemble de fonctionnalités dans toutes les applications réduit la charge opérationnelle. En adoptant une plateforme standard pour autant de services applicatifs que possible, les entreprises peuvent davantage tirer parti de l’automatisation et réutiliser plus de code afin de mettre en œuvre des processus opérationnels cohérents, prévisibles et reproductibles.

Élaborer une stratégie d’applications d’entreprise

À une époque où de nombreuses organisations nées dans le cloud ne disposent même pas d’un service informatique, les architectures informatiques et les processus opérationnels traditionnels sont manifestement loin de répondre aux attentes des développeurs d’applications et des équipes DevOps. La volonté de déployer les applications plus rapidement conduit souvent à contourner les équipes réseau et sécurité traditionnelles, ainsi que les processus de sécurité et d’exploitation associés. En effet, la protection du portefeuille d’applications de l’entreprise dépend autant des personnes et des processus que de la technologie.

Pour gérer les performances et, plus important encore, les risques liés à cette prolifération multicloud, les entreprises recherchent désespérément des solutions. Quel que soit l’environnement dans lequel les applications sont hébergées, ces solutions doivent permettre de déployer des politiques cohérentes, de gérer les menaces, d’assurer une bonne visibilité et de surveiller l’état et les performances des applications. Une solution inadaptée pourrait facilement réduire à néant les bénéfices d’une transformation numérique si elle entrave l’innovation et l’agilité des équipes de développement d’applications et DevOps.

Compte tenu de la valeur croissante des applications — et des risques accrus qu’elles présentent —, chaque organisme fédéral doit élaborer une stratégie applicative à l’échelle de l’entreprise qui définit la manière dont les applications du portefeuille sont développées ou acquises, déployées, gérées et sécurisées.

Étape 0 : Aligner les objectifs de la stratégie applicative sur la mission de l’organisation

Résumé : Profitez de cette occasion pour élaborer une stratégie applicative à l’échelle de l’entreprise, en adéquation avec la mission et les objectifs de votre agence fédérale.

La transformation numérique vise avant tout à remplacer les processus lourds et manuels par des applications efficaces et riches en données. Par conséquent, l’objectif global d’une stratégie d’applications d’entreprise doit être d’améliorer, d’accélérer et de protéger directement les capacités numériques de l’organisation qui contribuent à l’accomplissement de sa mission. Les applications ou services applicatifs associés qui ne répondent pas à cet objectif doivent être considérés comme moins prioritaires. Les applications hautement prioritaires doivent bénéficier de ressources et de mesures de sécurité supplémentaires, tandis que les actifs moins prioritaires peuvent utiliser des ressources partagées.

Cet alignement implique également de tenir compte de la situation actuelle, notamment en examinant attentivement la stratégie de données actuelle de l’entreprise, les exigences de conformité et le profil de risque global de l’organisation.

Dans de nombreux cas, les contraintes imposées par ces différentes sources et leur incidence sur l’agilité des équipes de développement d’applications sont probablement mal comprises. Votre stratégie en matière d’applications d’entreprise doit préciser l’équilibre que votre organisme est prêt à trouver entre des impératifs souvent concurrents : l’innovation, l’agilité et la gestion des risques.

Étape 1 : Dressez un inventaire des applications

Résumé : avant de commencer la modernisation, vous devez dresser un inventaire complet des applications.

En matière de stratégie applicative d’entreprise, la plupart des équipes n’ont pas la chance de pouvoir repartir de zéro. Presque tous les acteurs du secteur informatique héritent d’une architecture technologique résultant de décennies d’empilement de systèmes disparates sur des systèmes existants que l’on s’est efforcé de maintenir en fonctionnement. Ce problème peut être particulièrement aigu au sein du gouvernement fédéral américain, par rapport au secteur privé. Il est rarement facile de migrer proprement ces composants technologiques hétérogènes vers un état cible souhaité. Il est donc nécessaire de mener un travail plus approfondi de recensement et d’analyse.

Aussi simpliste que cela puisse paraître, pour protéger correctement quelque chose, il faut d’abord savoir que cette chose existe, puis être en mesure de surveiller précisément son état. Pourtant, à quelques exceptions près, la plupart des organisations ne sont pas en mesure d’indiquer avec certitude le nombre d’applications que compte leur portefeuille, et encore moins si ces applications sont fiables et sécurisées. Le rapport « F5 Labs 2018 Application Protection Report » a révélé que 62 % des responsables de la sécurité informatique ont peu confiance, voire aucune, dans leur connaissance de l’ensemble des applications de leur organisation.

Éléments à inclure dans votre inventaire d’applications

Un inventaire des applications constitue l’élément le plus fondamental de toute stratégie applicative. Il s’agit d’un catalogue de toutes les applications, qu’elles soient fournies en interne, à des entités de même niveau (par exemple, à d’autres organismes publics) ou en externe (par exemple, au public), et qui comprend :

• Une description de la fonction assurée par l’application ou le service numérique
• L’origine de l’application (par exemple, développée sur mesure, progiciel ou service tiers)
• Les principaux éléments de données auxquels l’application doit accéder ou qu’elle doit manipuler
• Autres services avec lesquels l’application communique
• Composants open source et autres composants tiers intégrés à l’application
• La ou les personnes ou le ou les groupes responsables de l’application

Comment constituer l’inventaire

La création initiale de l’inventaire des applications est souvent un travail laborieux et chronophage. Pour repérer facilement les applications non autorisées, une approche consiste à utiliser l’inventaire des applications comme liste d’autorisation : les applications qui n’y figurent pas n’ont tout simplement pas accès aux ressources de l’entreprise (par exemple, au réseau). Pour identifier les applications utilisées en dehors de votre organisation, un outil tel qu’un courtier en sécurité d’accès au cloud (CASB) peut s’avérer très utile. Les CASB s’interposent entre vos utilisateurs et Internet afin de surveiller l’ensemble de l’activité des applications et de générer des rapports à ce sujet. Ils peuvent non seulement vous indiquer les applications que vos collaborateurs utilisent le plus souvent (et la manière dont ils y accèdent), mais aussi vous fournir des informations sur l’utilisation d’applications relevant du shadow IT.

En adoptant un modèle d’architecture DevOps et en y intégrant vos applications, vous pouvez simplifier le processus d’inventaire à l’avenir. Une fois la priorité d’une application définie et celle-ci intégrée à votre environnement multicloud ou SaaS, les développeurs peuvent préparer son déploiement à l’aide d’outils open source (par exemple, Ansible ou GitHub). Le déploiement est ensuite géré par ces outils, qui prennent notamment en charge les services de sécurité, la gestion des correctifs et le code. Les informations d’inventaire sont centralisées et peuvent être fournies rapidement. Ainsi, l’application peut être hébergée dans un environnement cloud ou SaaS tout en restant identifiable par l’organisation.

Considérations relatives à FedRAMP

Chaque instant consacré à garantir l’exactitude de votre inventaire d’applications améliore directement votre capacité à définir rapidement les limites du système FedRAMP. Cela vous permet également d’identifier beaucoup plus rapidement et précisément la partie responsable de l’infrastructure d’une application — voire d’un composant particulier de celle-ci — lorsque l’organisme de certification vous le demande.

Enfin, vos efforts en matière de FedRAMP exigent que cet exercice soit mené en continu, éventuellement plus d’une fois par an. Il s’agit d’un processus permanent qui consiste à surveiller les applications et les référentiels de données utilisés, à suivre les besoins des utilisateurs et à évaluer l’évolution de vos environnements de développement.

Étape 2 : évaluer le risque cyber pour chaque application

Résumé : examinez le niveau de risque propre à chaque application et tenez compte de toutes les exigences de conformité applicables pour déterminer les mesures de sécurité à mettre en place.

Le cyberrisque constitue une préoccupation majeure et croissante pour les responsables informatiques de l’administration américaine. Pour y faire face, commencez par évaluer le cyberrisque associé à chacune de vos applications.

Chaque application de votre inventaire doit être examinée au regard de quatre principaux types de cyberrisques :

1. Fuite d’informations internes sensibles (par exemple, des secrets militaires)
2. Fuite d’informations sensibles concernant les clients/utilisateurs (par exemple, dossiers du personnel, historique fiscal)
3. Altération de données ou d’applications
4. Déni de service visant les données ou les applications

En matière de cyberrisque, l’importance d’un service numérique doit être évaluée en tenant compte des conséquences financières ou réputationnelles qu’une cyberattaque pourrait avoir sur ce service, selon les catégories ci-dessus. Les pertes potentielles associées à certains services varieront d’une organisation à l’autre ; chaque organisation doit donc réaliser ses propres estimations en fonction de la mission qu’elle s’est fixée. La FISMA, par exemple, exige de déterminer, à l’échelle de l’agence, les risques pesant sur la mission ou l’activité. Toutefois, il est souvent judicieux d’examiner également les risques au niveau des applications afin d’anticiper le renforcement inévitable des normes de conformité applicables à votre mission.

Considérations relatives à la conformité

Les calculs des risques organisationnels incluent parfois les risques liés au non-respect des règles, directives et contrats applicables. Les entités fédérales sont soumises à de nombreuses réglementations et normes, qui doivent toutes être prises en compte lors de l’évaluation des applications et des services numériques. La mise en place d’un modèle d’évaluation des cyberrisques lié aux applications facilite le respect des exigences CDM/ConMon et la conformité à FedRAMP, en permettant de circonscrire le périmètre à des groupes de services gérables et présentant un niveau de granularité approprié.

Simplifier la conformité grâce au SaaS

Le recours à des services SaaS peut contribuer à réduire les préoccupations d’une organisation en matière de conformité. Les risques liés aux applications et les questions de conformité relèvent de la responsabilité du fournisseur SaaS. L’organisation peut ainsi se concentrer sur les applications personnalisées.

Envisagez d’intégrer des services de sécurité cloud à l’application afin de protéger les comptes utilisateurs, les données financières et les informations personnelles. Les services de sécurité cloud disposent de millions de points de données que l’application peut exploiter pour déterminer si un client est malveillant ou s’il s’agit d’un utilisateur légitime. Ces points de données étant continuellement mis à jour, de nouvelles menaces peuvent être détectées. Des règles peuvent être appliquées à l’application en temps réel et s’intégrer à une stratégie de sécurité d’entreprise existante.

Étape 3 : déterminer les services applicatifs nécessaires

Résumé : Faites le point sur les services applicatifs — les solutions qui assurent le fonctionnement de vos applications en arrière-plan — dont votre organisation a besoin.

Les applications fonctionnent rarement de manière isolée. Par conséquent, en plus de l’inventaire des applications, les services applicatifs qui assurent leur fonctionnement doivent être gérés et suivis. Les services applicatifs sont des solutions prêtes à l’emploi destinées aux développeurs d’applications, qui améliorent la rapidité, la mobilité, la sécurité et l’exploitabilité d’une application. Ils apportent plusieurs avantages importants à la charge de travail applicative :

• Rapidité : les performances d’une charge de travail applicative et la capacité à assurer une livraison rapide.
• Mobilité : Déplacement aisé de la charge de travail d’une application d’un site d’hébergement physique ou logique à un autre.
• Sécurité : La protection de la charge de travail applicative et des données qui lui sont associées.
• Exploitabilité : La garantie qu’une charge de travail applicative est facile à déployer, à maintenir en fonctionnement et à dépanner en cas de défaillance.

Un bon moyen d’identifier les services applicatifs dépendants consiste à examiner la section « Contrôles » du plan de sécurité du système FISMA ou FedRAMP de votre environnement. Celle-ci permet souvent de mettre en évidence la présence de services applicatifs axés sur la sécurité, ainsi que d’autres services qui en dépendent.

Bien que toutes les applications puissent bénéficier de services applicatifs, elles n’ont pas toutes besoin des mêmes services applicatifs.

Les services applicatifs courants comprennent :

• Répartition de charge
• Diffusion DNS
• Répartition globale de la charge des serveurs
• Pare-feu pour applications web
• Prévention/protection contre les attaques DDoS
• Surveillance et analyse des applications
• Gestion des identités et des accès
• Authentification des applications
• Passerelles API
• Contrôle des flux entrants et sortants des conteneurs
• Chiffrement SSL

Trouver le juste équilibre entre coût, sécurité et performances

Tous les services applicatifs engendrent un certain niveau de coût, à la fois directement (pour le service lui-même) et indirectement (pour sa maintenance opérationnelle). Les applications peu prioritaires peuvent utiliser des capacités partagées afin de réduire les coûts. Ces capacités partagées assurent la sécurité et le maintien des performances. Les actifs à forte valeur nécessitent davantage de ressources, car ils jouent un rôle essentiel dans la productivité de l’organisation.

Il convient de noter que de nombreux services applicatifs sont spécifiquement conçus pour prendre en charge des catégories restreintes d’applications. Par exemple, seules les applications conçues pour prendre en charge des applications IoT ont besoin d’une passerelle IoT. Les applications déployées selon une architecture traditionnelle ne nécessitent pas de services applicatifs destinés aux environnements conteneurisés ; les services applicatifs de contrôle des flux entrants et de maillage de services peuvent donc ne pas être pertinents.

Dans certains cas, il peut être nécessaire d’acquérir de nouveaux services applicatifs afin de garantir la conformité ou de réduire les risques. Même si les contrôles minimaux de référence peuvent techniquement satisfaire aux normes de conformité, vous devez toujours résister à la tentation de les choisir et privilégier des services applicatifs qui renforcent votre capacité à faire face aux cyberrisques.

Étape 4 : Définir les catégories d’applications

Résumé : regroupez les applications de manière logique en fonction de leur type, de leur priorité et de leurs exigences.

Une fois l’inventaire des applications terminé, l’étape suivante consiste à regrouper vos applications en catégories logiques selon les caractéristiques qui nécessitent des approches différentes en matière de gestion et de services applicatifs (par exemple, l’accès à des données sensibles ou l’exposition à davantage de menaces).

Une fois les applications catégorisées, la politique de l’entreprise en matière d’applications doit préciser les profils de performance, de sécurité et de conformité à appliquer aux différents types d’applications, en fonction du niveau de criticité et de la classification de chaque application au sein de l’entreprise.

Nous recommandons de commencer par quatre niveaux de base.

Niveau 1

Caractéristiques des applications
Applications que vous considérez comme des actifs de grande valeur et qui constituent également des services numériques essentiels à vos activités, collectant et transformant des données sensibles

Services applicatifs requis
Répartition de charge, répartition globale de la charge des serveurs, pare-feu d’applications web, protection/prévention contre les attaques DDoS, détection des bots, chiffrement et déchiffrement SSL, gestion des identités et des accès des utilisateurs, gestion des identités et authentification des applications/services, visibilité et surveillance des applications

Caractéristiques supplémentaires
Les services applicatifs sont placés au plus près de l’application et intégrés à son déploiement. Protégez les données sensibles à l’aide de services cloud intelligents afin de sécuriser les comptes utilisateurs, les informations de carte bancaire et les données personnelles.

Niveau 2

Caractéristiques de l’application
Services numériques critiques donnant accès à des données sensibles

Services applicatifs requis
Répartition de charge, répartition globale de la charge des serveurs, pare-feu applicatif web, protection/prévention contre les attaques DDoS, détection des bots, chiffrement et déchiffrement SSL, gestion des identités et des accès des utilisateurs, identité et authentification des applications/services, visibilité/surveillance des applications

Caractéristiques supplémentaires
Protégez les données sensibles grâce à des services cloud intelligents afin de sécuriser les comptes utilisateurs, les informations de carte bancaire et les données personnelles.

Niveau 3

Caractéristiques de l’application
Services numériques critiques qui ne collectent pas de données sensibles et n’y donnent pas accès

Services applicatifs requis
Répartition de charge, répartition globale de la charge des serveurs, protection/prévention contre les attaques DDoS, visibilité/surveillance des applications

Caractéristiques supplémentaires
Vous pouvez utiliser des services partagés pour réduire les coûts. Protégez les données sensibles à l’aide de services cloud intelligents afin de sécuriser les comptes utilisateurs, les informations de carte bancaire et les données personnelles.

Niveau 4

Caractéristiques de l’application
Autres services numériques

Services applicatifs requis
Répartition de charge, visibilité/supervision des applications

Caractéristiques supplémentaires
Vous pouvez utiliser des services partagés pour réduire les coûts.

La valeur de la catégorisation

Étant donné que les menaces auxquelles sont confrontées les applications varient selon l’environnement dans lequel elles sont hébergées, cette catégorisation peut être affinée afin d’établir une distinction en fonction de l’environnement de déploiement (par exemple, sur site ou dans un cloud public).

Hiérarchiser vos objectifs de cette manière vous aide également à préclasser facilement les applications que vous déployez selon les niveaux FISMA/FedRAMP appropriés. En consacrant un peu de temps à structurer vos objectifs de mission à ce stade, vous passerez beaucoup moins de temps à échanger avec un auditeur par la suite.

Aucune organisation ne dispose de suffisamment de ressources pour accomplir tout ce qu’elle souhaite dans un délai acceptable. En hiérarchisant vos applications, vous pouvez déterminer lesquelles doivent être renforcées par des services applicatifs, lesquelles doivent être modernisées ou remplacées, et lesquelles ne méritent pas que l’on y consacre des efforts. Pour les applications de cette dernière catégorie, veillez à les isoler sur votre réseau afin d’éviter qu’un thermostat IoT en apparence inoffensif n’entraîne une compromission de l’ensemble du réseau. Ce processus consiste également à étudier de nouvelles applications susceptibles de créer de nouvelles sources de valeur et qui devraient donc être développées en interne ou acquises auprès d’un fournisseur tiers.

Étape 5 : Définir les paramètres de déploiement et de gestion des applications

Résumé : Définir les paramètres de déploiement et de consommation.

Le déploiement et la gestion opérationnelle ont toujours constitué un pilier de toute stratégie informatique, et une stratégie moderne en matière d’applications d’entreprise y ajoute quelques nouvelles dimensions (par exemple, l’importance de l’expérience utilisateur). Il convient notamment d’examiner les éléments suivants :

• Quelles architectures de déploiement sont prises en charge (par exemple, cloud hybride, multicloud)
• Options de modèle de déploiement pour chaque catégorie d’applications
• Quels clouds publics peuvent servir de points d’accès aux applications
• Dans quelle mesure les services natifs du cloud public peuvent être exploités plutôt que des services tiers

Les besoins des applications varient en matière de modèles de déploiement et de consommation. Au cours de cette phase d’élaboration de votre stratégie applicative, vous devez vous efforcer de bien comprendre les différentes options de déploiement, chacune pouvant présenter des modèles de consommation, des incidences sur les coûts et des profils de conformité/certification différents.

Lors du choix des modèles de déploiement, il est également judicieux de recenser les compétences et les talents disponibles afin d’en tenir compte dans la décision. Par exemple, choisir d’effectuer un déploiement sur AWS alors que vous ne disposez pas de suffisamment de compétences en interne pour le gérer et que vous n’avez pas accès à des prestataires qualifiés peut vous ralentir et engendrer des risques.

N’oubliez jamais que vos mécanismes de déploiement et de gestion peuvent eux-mêmes être soumis à une autorisation, que ce soit dans le cadre de la FISMA ou d’une ATO/P-ATO FedRAMP, selon la norme utilisée par votre agence pour votre mission.

Étape 6 : clarifier les rôles et les responsabilités

Résumé : définissez clairement les responsabilités pour chaque composante de votre stratégie d’applications d’entreprise.

Outre la définition de vos objectifs et de vos priorités, la stratégie relative aux applications d’entreprise doit également préciser les rôles et les responsabilités.

À savoir :

• Qui dispose du pouvoir de décision en matière d’optimisation et de sécurisation du portefeuille d’applications (par exemple, choix des technologies, devenir des applications, gestion des accès utilisateurs) ?
• Qui dispose d’un accès utilisateur privilégié à chaque application ?
• Qui est responsable du déploiement, de l’exploitation et de la maintenance de chaque application dans les différents environnements ?
• Qui est responsable du respect de la politique relative aux applications d’entreprise ?
• Qui sera chargé de veiller au respect des objectifs de la stratégie relative aux applications d’entreprise ? Et à qui les indicateurs seront-ils communiqués ?
• Qui sera chargé de vérifier que les fournisseurs — y compris les prestataires de composants/services open source et tiers — respectent les exigences de conformité ?
• Qui veillera à ce que toutes les applications et tous les services applicatifs soient bien pris en compte (à mesure qu’ils évoluent et sont ajoutés ou supprimés) ?

Ces responsabilités peuvent incomber à une personne, à des comités interdépartementaux, voire à des services entiers. Dans tous les cas, elles doivent être clairement énoncées. Il peut même être nécessaire de les définir plus précisément que ne l’exige votre régime de conformité.

Les organisations les plus avancées adopteront des processus opérationnels et des mécanismes d’automatisation afin d’attribuer ces responsabilités dès les premières étapes du processus de développement, au moment de la création de l’application. Dans un environnement multicloud comptant des centaines, voire des milliers d’applications prenant en charge des fonctions critiques, la stratégie applicative et les politiques correspondantes doivent établir clairement les responsabilités de chacun.

Faire respecter la stratégie applicative de l’entreprise

Une fois la stratégie relative aux applications d’entreprise élaborée, elle doit être mise en œuvre pour remplir son objectif. Les mécanismes d’application doivent comprendre des garde-fous « stricts » intégrés à l’automatisation des processus (par exemple, le contrôle des accès utilisateurs et l’analyse des vulnérabilités du code lors de son archivage), ainsi que des mesures « souples », telles que la formation des collaborateurs et le développement des compétences ou la sensibilisation.

Mettre en œuvre des contrôles d’accès robustes

Votre politique de contrôle des accès doit prendre en charge les rôles et responsabilités opérationnels définis dans la stratégie applicative de l’entreprise et s’étendre à toutes les applications, qu’elles soient sur site ou dans le cloud. Une attention particulière doit être accordée aux accès des utilisateurs privilégiés en raison des risques qu’ils représentent pour l’application, notamment parce qu’ils peuvent être ciblés par des menaces persistantes avancées (APT) sophistiquées du fait de leurs droits d’administration ou d’accès root à l’application.

Les mesures spécifiques recommandées pour les utilisateurs disposant de privilèges comprennent :

• Les utilisateurs à privilèges doivent toujours être placés dans des groupes distincts. Ils doivent être définis comme « à haut risque » dans votre solution de contrôle d’accès, afin de leur appliquer des mesures de sécurité que vous ne souhaiteriez peut-être pas mettre en œuvre pour tous les utilisateurs ou pour tous les niveaux de classification des applications.
• Plusieurs facteurs d’authentification à distance doivent être exigés. Si des tentatives d’accès sont effectuées avec des identifiants valides, mais échouent à la seconde exigence d’authentification (dans le cas où des attaquants auraient récupéré des identifiants valides à la suite d’une violation de données impliquant des identifiants partagés), ou depuis un lieu physiquement incompatible avec la dernière connexion valide (par exemple, une connexion réussie aux États-Unis deux heures avant que le même utilisateur ne tente de se connecter depuis l’Europe de l’Est), le compte doit être verrouillé jusqu’à ce qu’un examen de sécurité approfondi soit terminé.
• L’accès administrateur ne doit être accordé qu’aux membres du personnel compétents et formés qui ont régulièrement besoin de ce niveau d’accès pour exercer leurs fonctions. Tout accès temporaire accordé en cas d’urgence ou pour des projets spéciaux doit relever d’un groupe d’utilisateurs distinct, doté d’un dispositif automatisé de suivi de l’utilisation qui rappellera aux administrateurs système de supprimer l’accès s’ils oublient de le faire. La pertinence des accès doit être examinée régulièrement et de manière indépendante par rapport à l’équipe responsable de l’application ou de l’octroi des accès à celle-ci, afin d’éviter tout conflit d’intérêts. Si un utilisateur privilégié n’accède pas à un compte pendant une période prolongée, il convient de se demander s’il a réellement besoin de cet accès.
• Tous les accès des utilisateurs privilégiés aux applications doivent être dûment consignés. Cela inclut toutes les modifications effectuées par le compte utilisateur.

Obtenir ce niveau de visibilité et d’automatisation de la gestion des accès dans le cloud peut s’avérer complexe et coûteux, car ces fonctionnalités ne sont généralement pas disponibles de manière native. Cela reste toutefois possible grâce à des licences tierces et, compte tenu de l’importance de cet enjeu, l’investissement en vaut largement la peine.

Former en continu les employés et les parties prenantes concernées

Avec l’augmentation constante du nombre d’applications et l’abondance des données disponibles dans les médias, que les attaquants exploitent pour déterminer quelles applications cibler et qui y a accès, la formation à la sensibilisation à la sécurité n’a jamais été aussi importante.

Le harponnage étant le mode opératoire privilégié des cybercriminels, la formation à la détection du phishing doit constituer une priorité majeure. Le Rapport 2018 de F5 Labs sur le phishing et la fraude a révélé que former les employés plus de 10 fois peut faire passer le taux de réussite du phishing de 33 % à 13 %. Pourtant, les formations de sensibilisation à la sécurité sont rarement dispensées assez souvent et avec des contenus adaptés. Les services de formation standardisés, conçus pour simplement satisfaire aux exigences de conformité, risquent d'empêcher les employés de comprendre leur rôle dans la sécurité de l'information et de développer un véritable sens des responsabilités à cet égard. Si l'objectif est de réduire le risque de violation de données, la meilleure approche consiste à proposer des formations fréquentes et personnalisées pour votre organisation.

Les attaquants ne connaissent aucun répit ; les employés doivent donc rester vigilants en permanence. Toutes les organisations devraient instaurer une culture durable de la curiosité, en particulier les organismes fédéraux et les entreprises qui fournissent des produits et des services au gouvernement fédéral. Les employés doivent avoir conscience qu’ils constituent une cible en raison de leur accès aux applications et aux données. Ils doivent également savoir comment cet accès ou ces données sont exploités par des États-nations hostiles ou vendus par des cybercriminels motivés par le profit (avant d’être achetés par des adversaires).

Conclusion

Pour garantir la réussite de leur transformation numérique, toutes les organisations doivent adopter une stratégie en matière d’applications d’entreprise ainsi qu’une politique correspondante, et former leurs collaborateurs à celles-ci. Dans le secteur fédéral, qui se caractérise par une grande diversité d’applications anciennes, hybrides et modernes, cette démarche est particulièrement cruciale. Elle est indispensable pour fournir un service numérique fiable, sécurisé et autorisé.

Les applications sont au cœur de la transformation numérique de toute organisation et, compte tenu de l’évolution rapide des méthodes de développement et de déploiement des logiciels, elles constituent à la fois sa principale source de valeur et sa plus grande source de vulnérabilité. Les composantes de la stratégie et de la politique applicatives présentées ici fournissent les fondements essentiels pour sécuriser les ambitions numériques de toute organisation. Le profil de risque de leur portefeuille d’applications augmentant chaque jour, les organisations doivent agir rapidement pour formaliser leur stratégie et leur politique.

_{¹ La stratégie Cloud Smart de l’Office of Management and Budget
² F5 Labs : les enseignements tirés d’une décennie de violations de données
³ Des criminels piratent un aquarium pour voler les données d’un casino, Forbes
⁴ La violation de données de Target est due à une erreur élémentaire de segmentation du réseau, ComputerWorld
⁵ État de la chaîne d’approvisionnement logicielle en 2018, Sonatype}

PUBLIÉ LE 11 JANVIER 2021