Pourquoi chaque agence fédérale a besoin d'une stratégie d'application d'entreprise et comment en créer une

Les responsables informatiques des agences fédérales américaines doivent trouver le juste équilibre entre offrir davantage de valeur tout en réduisant le gaspillage et en minimisant les pertes dues aux cyberattaques. D’un côté, les responsables informatiques doivent adopter les dernières technologies pour accroître l’efficacité, offrir davantage de valeur et économiser l’argent des contribuables. D’autre part, ils sont confrontés à un paysage de menaces en constante évolution et en expansion, qui nécessite des ressources importantes pour les atténuer. Bref, à chaque initiative et à chaque décision, ils doivent à la fois innover et protéger. Pour atteindre ces objectifs apparemment opposés, les responsables informatiques fédéraux doivent élaborer une stratégie d’application d’entreprise adaptée à leur mission organisationnelle.

65 % des personnes interrogées dans le rapport F5 2019 sur l’état des services d’application ont déclaré que leurs organisations sont en pleine transformation numérique. La transformation numérique est une nouvelle façon pour les organisations d’utiliser la technologie pour permettre des améliorations profondes des performances et de la productivité des utilisateurs.

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

Pour tirer parti de ce changement radical, les organisations procèdent à des changements radicaux en quête de nouveaux modèles opérationnels commerciaux et informatiques, tels que :

• S'appuyer sur des services SaaS tels que la messagerie électronique et les outils de productivité basés sur le cloud
• Conteneurisation d'applications personnalisées pour simplifier la gestion et réduire les coûts
• Utiliser les services de sécurité cloud pour déterminer rapidement les attaques et appliquer la politique en fonction des règles organisationnelles.

Les applications sont livrées sur différents types d’appareils. Les utilisateurs qui accèdent aux applications ne résident pas dans des environnements d’entreprise traditionnels : ils sont mobiles ou travaillent à domicile. La fourniture de fonctions critiques pour l’entreprise telles que le CRM, l’ERP et tout ce qui se trouve entre les deux doit permettre l’accès en dehors du réseau d’entreprise traditionnel.

Le rapport 2018 de F5 Labs sur la protection des applications a révélé que l'organisation moyenne du secteur public utilise 680 applications, dont 32 % sont considérées comme critiques pour la mission.

En plus de cette croissance considérable des applications, les organisations déploient ces applications dans de nouvelles architectures et de nouveaux services. L'étude State of Application Services 2019 indique que 14 % des organisations interrogées ont fait des conteneurs l'approche par défaut d'isolation de la charge de travail des applications et que 87 % des répondants adoptent une architecture multicloud. Le Bureau de la gestion et du budget (OMB) lui-même prône une « stratégie intelligente du cloud »¹ pour migrer vers un réseau cloud sûr et sécurisé.

Les organisations gouvernementales et commerciales ne sont pas les seules à utiliser la technologie pour réduire les frictions, fournir de nouveaux services et améliorer la valeur. Les cybercriminels, les groupes militants et les acteurs de la menace étatique innovent également à une vitesse vertigineuse dans leurs capacités de cyberattaque. À mesure que nous améliorons la protection de nos réseaux et de nos infrastructures, les cyberattaquants se tournent désormais vers des cibles plus vulnérables.

Les cibles faciles sont utilisées pour infiltrer des actifs de grande valeur qui peuvent stocker du personnel ou des informations classifiées. Les recherches de F5 Labs montrent que 86 % des cyberattaquants ciblent directement les applications ou volent l'identité des utilisateurs, généralement par phishing.²

Les attaquants apprennent qu’il est parfois plus facile d’attaquer indirectement. Une façon d’y parvenir est de cibler des applications moins importantes, comme les appareils IoT, et d’améliorer leur accès. Ce fut le cas lorsque des criminels ont piraté un casino américain grâce à un thermomètre d'aquarium dans le hall et l'ont utilisé comme point d'accès à la base de données des gros joueurs.³ De même, la violation dévastatrice de Target en 2013 a commencé comme une exploitation du fournisseur de systèmes de chauffage, de ventilation et de climatisation de Target et s’est terminée par une violation du système de point de vente et une perte 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 introduire des risques. L'état de la chaîne d'approvisionnement logicielle 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 révision. Ces composants font partie du portefeuille d’applications et doivent être traités avec la même attention que le code personnalisé. Cela inclut les composants côté serveur (par exemple, les packages NPM, les bibliothèques) ainsi que côté client.

Les applications jouant désormais un rôle plus crucial dans la réalisation des objectifs d’une organisation, la croissance de ces applications dépasse la capacité de la plupart des organisations à faire évoluer leurs opérations. Le modèle traditionnel de sécurité au niveau du périmètre n’est pas évolutif et son efficacité pour prévenir les menaces est limitée. Une fois qu’une cible facile est compromise, des actifs de grande valeur sont en danger. Les nouvelles architectures et les nouveaux modèles de déploiement remettent encore plus en question les mesures de sécurité traditionnelles. Les applications sont mises en scène dans des emplacements dispersés et utilisent des services d’application multicloud pour améliorer les performances. Dans le même temps, la surface de menace associée aux applications s’étend de manière exponentielle.

Une surveillance continue à proximité des applications et des cibles vulnérables est importante pour assurer la sécurité tout en maintenant les performances. L’intégration d’une sécurité cloud intelligente peut fonctionner avec l’application pour atténuer rapidement les menaces et protéger les données sensibles. De petits types de données peuvent être envoyés vers le cloud pour identifier les menaces potentielles en comparant les données avec des millions d'artefacts stockés dans le cloud. Cela peut être utilisé pour déterminer si un client est un robot ou un utilisateur réel.

Un service de réduction de la fraude peut fonctionner avec une application pour interagir avec des acteurs malveillants, obtenir davantage de types de données et prévenir la fraude à grande échelle. Le profil de fraude complet peut être transmis au système de surveillance continue de l'organisation pour prendre des mesures, empêcher la propagation de l'attaque, déterminer l'emplacement des systèmes compromis et fournir des mesures pour supprimer la menace des machines infectées. Les analystes peuvent fournir les informations aux opérations pour une analyse plus approfondie.

Comme si les choses n’étaient pas assez complexes, les agences fédérales se tournent vers des déploiements multicloud et SaaS pour bénéficier d’une plus grande flexibilité, d’une plus grande disponibilité, de réduire la dépendance vis-à-vis des fournisseurs et, dans certains cas, de coûts inférieurs. Le dilemme est le suivant : comment peuvent-ils offrir une expérience applicative standardisée, sécurisée et transparente sur des architectures hybrides, multicloud et SaaS sans dépasser leur allocation budgétaire ?

Les agences peuvent utiliser leur solution de périmètre sur des points de connexion Internet fiables pour sécuriser la connectivité aux environnements SaaS et multi-cloud. Cela peut entraîner des problèmes de performances puisque les agences disposent de points de connexion limités. Les applications publiques doivent passer par ces points pour des raisons de sécurité, ce qui entraîne une latence. Les avantages d'avoir des applications évolutives et à hautes performances sont éliminés puisque le trafic doit « trombonner » pour des raisons de sécurité.

Les solutions de périmètre s’appuient également sur des signatures statiques. Si une nouvelle menace est développée et a été profilée au sein d’un fournisseur de cloud de sécurité, les informations ne seront pas relayées au système de périmètre pour empêcher l’attaque. Les mises à jour de signature peuvent se produire dans un délai d'un jour ou d'une semaine. Les actifs de grande valeur peuvent être compromis lorsque la signature est finalement développée et mise à jour au sein du système de sécurité du périmètre.

La standardisation des services d’application multicloud et SaaS (les solutions mises en place pour sécuriser, gérer et optimiser vos applications) réduit la complexité opérationnelle qui accompagne une architecture multicloud.

Par exemple, il est plus facile de gérer (et plus puissant) un service qui fonctionne au niveau d'une application d'entreprise, comme l'invocation basée sur le code d'API et les systèmes pilotés par événements, qu'un service spécifique à une plateforme, comme l'utilisation d'un service de mise en file d'attente de messages spécifique à un fournisseur. L’activation d’un ensemble de fonctionnalités sur toutes les applications réduit les frais opérationnels. En adoptant une plateforme standard pour autant de services d’application que possible, les organisations peuvent tirer parti d’une plus grande automatisation et réutiliser davantage de code pour réaliser des processus opérationnels cohérents, prévisibles et répétables.

À une époque où de nombreuses organisations nées dans le cloud n’ont même pas de service informatique, les architectures informatiques et les processus opérationnels traditionnels sont nettement en deçà des attentes des développeurs d’applications et des équipes DevOps. Le désir de déployer les applications plus rapidement conduit souvent à contourner les équipes traditionnelles de réseau et de sécurité ainsi que les processus de sécurité et d'exploitation associés. En effet, la protection du portefeuille d’applications d’entreprise est autant liée aux personnes et aux processus qu’à la technologie.

Pour gérer les performances et, plus important encore, les risques dans cette prolifération multicloud, les organisations ont désespérément besoin de solutions. Où que se trouvent les applications, les solutions doivent prendre en charge le déploiement de politiques cohérentes, gérer les menaces, fournir une visibilité et permettre la surveillance de l'état et des performances des applications. Une solution mal adaptée pourrait facilement réduire les avantages d’une transformation numérique si l’innovation et l’agilité des équipes de développement d’applications et DevOps sont entravées.

Compte tenu de la valeur croissante des applications et du profil de risque qu’elles représentent, chaque agence fédérale doit développer une stratégie d’application d’entreprise qui aborde la manière dont les applications du portefeuille de l’entreprise sont créées/acquises, déployées, gérées et sécurisées.

Résumé: Profitez de cette opportunité pour créer une stratégie d’application d’entreprise qui s’aligne sur la mission et les objectifs de votre agence fédérale.

L’objectif de la transformation numérique est de remplacer les processus lourds et manuels par des applications efficaces et riches en données. Par conséquent, l’objectif principal d’une stratégie d’application d’entreprise doit être d’améliorer, d’accélérer et de protéger directement les capacités numériques de l’organisation en ce qui concerne la réalisation de la mission. Toutes les applications ou services d’application associés qui ne sont pas conformes à cet objectif doivent être dépriorisés. Les applications hautement prioritaires doivent bénéficier de ressources et d’une sécurité supplémentaires, tandis que les ressources non prioritaires peuvent utiliser des ressources partagées.

Cet alignement implique également de prendre en compte le statu quo, ce qui implique d’examiner attentivement la stratégie actuelle en matière de données 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 l’impact sur l’agilité des équipes de développement d’applications ne sont probablement pas bien compris. Votre stratégie d’application d’entreprise doit clarifier l’équilibre que votre agence est prête à trouver entre les forces souvent concurrentes de l’innovation, de l’agilité et du risque.

Résumé: Avant de commencer la modernisation, vous devez créer un inventaire complet des applications.

Lorsqu’il s’agit d’une stratégie d’application d’entreprise, la plupart des équipes n’ont pas la chance de repartir à zéro. Presque tous les acteurs du secteur informatique héritent d’une architecture technologique qui est le résultat de décennies de systèmes disparates écrasés sur des systèmes hérités contraints de continuer à fonctionner. Ce problème peut être particulièrement grave au sein du gouvernement fédéral américain, par rapport au secteur commercial. Il est rarement facile de migrer proprement ces éléments technologiques incongrus vers l’état cible souhaité. Il est donc nécessaire de procéder à davantage de découvertes et d’analyses.

Même si cela peut paraître simple, pour protéger adéquatement quelque chose, il faut d’abord savoir qu’il existe, puis être capable de surveiller avec précision son état de santé. Et pourtant, à quelques exceptions près, la plupart des organisations ne sont pas en mesure de communiquer avec certitude le nombre d’applications qu’elles possèdent dans leur portefeuille, et encore moins de savoir si ces applications sont saines et sécurisées. Le rapport 2018 sur la protection des applications de F5 Labs a révélé que 62 % des responsables de la sécurité informatique ont peu ou pas confiance dans la connaissance de toutes les applications de leur organisation.

Un inventaire d’applications est l’élément le plus fondamental de toute stratégie d’application. Il s’agit d’un catalogue de toutes les applications, qu’elles soient fournies en interne, latéralement (par exemple, à d’autres entités gouvernementales) ou en externe (par exemple, au public), qui comprend :

• Une description de la fonction exécutée par l'application ou le service numérique
• L'origine de l'application (par exemple, un logiciel développé sur mesure, un logiciel packagé ou un service tiers)
• Les éléments de données clés auxquels l'application doit accéder ou qu'elle manipule
• Autres services avec lesquels l'application communique
• Composants open source et autres composants tiers faisant partie de l'application
• La ou les personnes ou le ou les groupes responsables de la demande

Créer l’inventaire des applications pour la première fois est souvent un travail fastidieux et chronophage. Une approche permettant d’éliminer facilement les applications malveillantes consiste à faire de l’inventaire des applications une liste blanche ; les applications qui ne figurent pas sur la liste blanche n’ont tout simplement pas accès aux ressources de l’entreprise (par exemple, le réseau). Pour traquer les applications en dehors de votre organisation, un outil comme un courtier en sécurité d'accès au cloud (CASB) peut être très utile. Les CASB se situent entre vos utilisateurs et Internet, surveillant et signalant toutes les activités des applications. Ils peuvent non seulement vous indiquer quelles applications vos employés utilisent le plus (et comment ils y accèdent), mais également vous donner un aperçu de l'utilisation des applications informatiques fantômes.

En utilisant un modèle d’architecture DevOps et en y intégrant vos applications, vous pouvez simplifier le processus d’inventaire à l’avenir. Lorsque la priorité d’une application est déterminée et qu’elle est placée dans votre environnement multicloud ou SaaS, les développeurs peuvent empaqueter le déploiement à l’aide d’outils open source (par exemple, Ansible, GitHub). Le déploiement est ensuite géré par ces outils qui incluent les services de sécurité, la gestion des correctifs et le code. Les informations d’inventaire sont centralisées et peuvent être fournies rapidement. Par conséquent, l’application peut exister dans un environnement cloud ou SaaS tout en étant identifiée par l’organisation.

Chaque moment passé à garantir l’exactitude de votre inventaire d’applications a un impact positif direct sur votre capacité à définir rapidement les limites du système FedRAMP. Cela vous permet également de disposer d’un moyen beaucoup plus précis pour trouver rapidement et précisément la partie responsable de l’infrastructure d’une application, ou même d’un composant individuel d’une application, lorsque l’organisme de certification vous le demande.

Enfin, vos efforts FedRAMP nécessitent qu’il s’agisse d’un exercice continu, éventuellement plus d’une fois par an. Il s’agit d’un processus constant qui consiste à garder un œil sur les applications et les référentiels de données en jeu, à surveiller ce que les utilisateurs doivent faire et à évaluer l’évolution de vos environnements de développement.

Résumé: Examinez le niveau de risque individuel de chaque application et combinez-le avec toutes les considérations de conformité applicables lors de la détermination des mesures de sécurité.

Le cyber-risque est une préoccupation importante et croissante pour les responsables informatiques du gouvernement américain. Pour le combattre, vous devez commencer par évaluer le cyber-risque pour chacune de vos applications.

Chaque application de votre inventaire doit être examinée pour quatre principaux types de cyber-risques :

1. Fuite d’informations internes sensibles (par exemple, des secrets militaires)
2. Fuite d'informations sensibles sur les clients/utilisateurs (par exemple, dossiers personnels, antécédents fiscaux)
3. Falsification de données ou d'applications
4. Déni de service des données ou des applications

En matière de cyber-risque, l’importance d’un service numérique doit être mesurée en prenant en compte l’impact financier ou sur la réputation de ce service en raison de la cyberattaque, selon les catégories ci-dessus. Différentes organisations définiront des niveaux de perte potentielle différents pour certains services par rapport à d’autres, chaque organisation doit donc faire ses propres estimations en fonction de sa mission définie. La FISMA, par exemple, vous demande de déterminer le risque au niveau de l’agence pour la mission ou l’analyse de rentabilisation. Mais il est souvent pratique d’examiner également les risques au niveau de l’application pour se préparer au moment où les normes de conformité de votre mission se durciront inévitablement.

Les calculs de risques organisationnels incluent parfois les risques de non-conformité aux règles, directives et contrats applicables. Les entités fédérales sont imprégnées de réglementations et de normes, et celles-ci doivent toutes être prises en compte lors de l’évaluation des applications et des services numériques. L’établissement d’un modèle lié à l’application pour évaluer le risque cybernétique permet de faciliter le processus de satisfaction des exigences CDM/ConMon en matière de conformité FedRAMP en vous permettant de réduire les limites à des groupes de services gérables et suffisamment granulaires.

L’utilisation de services SaaS peut aider à réduire les problèmes de conformité organisationnelle. Les risques liés aux applications et les problèmes de conformité relèvent de la responsabilité du fournisseur SaaS. Cela aide une organisation à se concentrer sur des applications personnalisées.

Envisagez d’intégrer des services de sécurité cloud au sein de l’application pour 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 qui peuvent être utilisés par l'application pour déterminer si un client est malveillant ou s'il s'agit d'un utilisateur réel. Étant donné que les points de données sont continuellement mis à jour, de nouvelles menaces peuvent être identifiées. Les règles peuvent être appliquées à l'application en temps réel et peuvent fonctionner avec une stratégie de sécurité d'entreprise existante.

Résumé: Faites l’inventaire des services applicatifs (les solutions qui exécutent vos applications en arrière-plan) nécessaires à votre organisation.

Les applications sont rarement autonomes. Par conséquent, parallèlement à l'inventaire des applications, les services d'application exécutant vos applications doivent être gérés et suivis. Les services d’application sont des solutions packagées destinées aux créateurs d’applications qui améliorent la vitesse, la mobilité, la sécurité et l’opérabilité d’une application. Les services d’application confèrent plusieurs avantages importants à la charge de travail des applications :

• Vitesse: Les performances d’une charge de travail applicative et la capacité à livrer rapidement.
• Mobilité : Le déplacement facile d’une charge de travail d’application d’un site d’hébergement physique ou logique vers un autre.
• Sécurité: La protection de la charge de travail de l'application et des données qui lui sont associées.
• Opérabilité : L'assurance qu'une charge de travail d'application est facile à déployer, facile à maintenir en cours d'exécution et facile à dépanner en cas de défaillance.

Une bonne façon de localiser les services d’application dépendants est d’examiner la section Contrôles du plan de sécurité système FISMA ou FedRAMP pour votre environnement. Cela indiquera souvent la présence de services d’application axés sur la sécurité et d’autres services qui en dépendent. 

Bien que chaque application puisse bénéficier des services d’application, toutes les applications ne nécessitent pas les mêmes services d’application.

Les services d’application courants incluent :

• Équilibrage de charge
• Livraison DNS
• Équilibrage global de la charge du serveur
• Pare-feu d'application Web
• Prévention/protection DDoS
• Surveillance et analyse des applications
• Gestion des identités et des accès
• Authentification des applications
• Passerelles API
• Contrôle d'entrée et de sortie des conteneurs
• Cryptage SSL

Tous les services applicatifs impliquent un certain niveau de coût, à la fois direct (en termes de service lui-même) et indirect (en termes de maintenance opérationnelle). Les applications à faible priorité peuvent utiliser des fonctionnalités partagées pour aider à réduire les coûts. Les capacités partagées assurent la sécurité et maintiennent les performances. Les actifs de grande valeur nécessitent davantage de ressources car ils sont très importants pour la productivité de l’organisation.

Il convient de noter que de nombreux services d’applications sont spécifiquement conçus pour prendre en charge des catégories restreintes d’applications. Par exemple, seules les applications conçues pour servir des applications IoT ont besoin d’une passerelle IoT. Les applications livrées dans une architecture traditionnelle ne nécessitent pas de services d’application ciblant les environnements conteneurisés. Par conséquent, les services d’application de contrôle d’entrée et de maillage de services peuvent ne pas être applicables.

Dans certains cas, de nouveaux services d’application peuvent devoir être acquis pour garantir la conformité ou réduire les risques. Même si cela peut techniquement répondre aux normes de conformité, vous devez toujours résister à la tentation de sélectionner les contrôles de base minimaux et insister pour sélectionner des services d'application qui améliorent votre capacité à gérer les cyber-risques.

Résumé: Regroupez logiquement les applications 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 en fonction des caractéristiques qui nécessitent différentes approches de gestion et de services d’application (par exemple, accès à des données sensibles, exposition à davantage de menaces).

Une fois catégorisée, la politique d’application d’entreprise doit spécifier les profils de performances, de sécurité et de conformité qui doivent être appliqués à différents types d’applications, en fonction de la criticité et de la classification d’entreprise de l’application elle-même.

Nous vous recommandons de commencer avec quatre niveaux de base.

Étant donné que les menaces auxquelles sont confrontées les applications varient en fonction de l’environnement dans lequel elles sont hébergées, cette catégorisation peut être encore élargie pour différencier en fonction de l’environnement de déploiement (par exemple, sur site, cloud public).

Prioriser vos objectifs de cette manière vous aide également à pré-classer facilement les applications que vous déployez dans les niveaux FISMA/FedRAMP appropriés. Passer un peu de temps ici à développer une structure pour vos objectifs de mission vous permet de passer beaucoup moins de temps à parler à un auditeur plus tard.

Aucune organisation ne dispose de suffisamment de ressources pour faire tout ce qu’elle veut dans un délai acceptable. En hiérarchisant vos applications, vous pouvez adopter une approche de triage pour déterminer quelles applications doivent être renforcées avec des services d’application, quelles applications doivent être modernisées ou remplacées et quelles applications ne valent pas la peine. Pour les applications de cette dernière catégorie, assurez-vous qu’elles sont segmentées dans votre réseau et évitez le scénario dans lequel un thermostat IoT inoffensif entraîne une violation totale du réseau. Ce processus comprend également l’examen de nouvelles applications susceptibles de générer de nouveaux flux de valeur et qui devraient donc être développées en interne ou fournies par un tiers.

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

Le déploiement et la gestion opérationnelle ont toujours été un élément fondamental de toute stratégie informatique, et une stratégie d’application d’entreprise moderne ajoute quelques nouveautés (par exemple, l’importance de l’expérience de l’utilisateur final). Cela comprend l'examen de :

• Quelles architectures de déploiement sont prises en charge (par exemple, cloud hybride, multicloud)
• Options de modèle de déploiement pour chacune des catégories 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 par rapport aux services tiers

Différentes applications ont des besoins différents en termes de modèles de déploiement et de consommation. Au cours de cette phase de développement de votre stratégie d’application, vous devez vous efforcer d’acquérir une compréhension claire des différentes options de déploiement, chacune pouvant avoir des modèles de consommation, des impacts sur les coûts et des profils de conformité/certification différents.

Lors de la sélection des modèles de déploiement, il est également prudent de faire l’inventaire des compétences et des talents disponibles à prendre en compte dans la décision. Par exemple, choisir de déployer sur AWS lorsque vous ne disposez pas de suffisamment de talents internes pour le gérer et que vous n'avez pas accès aux compétences contractuelles peut vous ralentir et introduire des risques.

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

Résumé: Établissez des lignes de responsabilité claires pour chaque élément de votre stratégie d’application d’entreprise.

En plus d’articuler vos objectifs et vos priorités, la stratégie d’application d’entreprise doit également inclure des éléments autour des rôles et des responsabilités.

Vous devez savoir :

• Qui dispose des droits de décision concernant l’optimisation et la sécurisation du portefeuille d’applications (par exemple, le choix de la technologie, la disposition des applications, la gestion de l’accès des 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 d’application de l’entreprise ?
• Qui va surveiller la conformité aux objectifs de la stratégie des applications de l’entreprise ? Et à qui communiqueront-ils les résultats ?
• Qui va contrôler la conformité des fournisseurs, y compris les fournisseurs de composants/services open source et tiers ?
• Qui va s’assurer que toutes les applications et tous les services d’application sont pris en compte (alors que les applications et les services continuent de changer et d’être ajoutés/supprimés) ?

Ces responsabilités pourraient incomber à un individu, à des comités multidépartementaux, voire à des départements entiers. Quoi qu’il en soit, ils doivent être clairement énoncés. En fait, il se peut qu’ils nécessitent une définition encore plus poussée que celle requise par votre régime de conformité.

Les organisations plus avancées adopteront des processus opérationnels et une automatisation pour attribuer ces responsabilités au début du processus de développement, au moment du lancement de l’application. Dans un monde multi-cloud comptant des centaines, voire des milliers d’applications prenant en charge des fonctions critiques, la stratégie d’application et les politiques correspondantes doivent établir des lignes de responsabilité claires.

Une fois la stratégie d’application d’entreprise élaborée, pour atteindre son objectif, elle doit être appliquée. Les mécanismes d’application devraient inclure des garde-fous « durs » intégrés à l’automatisation des processus (par exemple, le contrôle d’accès des utilisateurs, les analyses de vulnérabilité des codes lors de l’enregistrement) ainsi que des mesures « douces » telles que la formation des employés et le renforcement des capacités ou de la sensibilisation.

Votre politique de contrôle d'accès doit prendre en charge les rôles et responsabilités opérationnels définis dans la stratégie d'application de l'entreprise et s'étendre à toutes les applications sur site et dans le cloud. Une attention particulière doit être accordée à l'accès des utilisateurs privilégiés en raison du risque qu'ils représentent pour l'application, notamment celui d'être ciblés par des APT sophistiqués en raison de leur autorisation administrative ou root sur l'application.

Les mesures spéciales recommandées pour les utilisateurs privilégiés incluent :

• Les utilisateurs privilégiés doivent toujours être dans des groupes séparés. Ils doivent être définis comme « à haut risque » dans votre solution de contrôle d'accès et nécessitent des contrôles de sécurité que vous pourriez choisir de ne pas mettre en œuvre pour tous les utilisateurs ou tous les niveaux de classification des applications. 
• Plusieurs facteurs d’authentification à distance devraient être exigés. Si des tentatives d'accès sont effectuées avec des informations d'identification valides qui échouent à la deuxième exigence d'authentification (dans le cas où des attaquants ont collecté des informations d'identification valides à partir d'une violation où des informations d'identification ont été partagées), ou à partir d'un emplacement physiquement impossible sur la base de la dernière connexion valide (comme une connexion réussie aux États-Unis deux heures avant que le même utilisateur ne tente de se connecter en Europe de l'Est), le compte doit être verrouillé jusqu'à ce qu'un nouvel examen de sécurité soit terminé.
• L'accès administratif ne doit être autorisé qu'au personnel approprié et formé qui a besoin de ce niveau d'accès régulièrement pour effectuer son travail. Tout accès temporaire accordé pour des urgences ou des projets spéciaux doit être dans un groupe d'utilisateurs différent configuré avec une surveillance d'utilisation automatisée qui rappellera aux administrateurs système s'ils oublient de supprimer l'accès. L’examen de la pertinence de l’accès doit être effectué régulièrement et réalisé indépendamment de l’équipe responsable de la demande ou de l’octroi de l’accès à la demande, 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 faut se demander s’il a réellement besoin de cet accès.
• Une comptabilité appropriée de tous les accès des utilisateurs privilégiés aux applications doit être enregistrée. Cela inclut toutes les modifications apportées par le compte utilisateur.   

Obtenir ce niveau de visibilité et d’automatisation autour du contrôle d’accès dans le cloud peut être difficile et coûteux, car ces fonctionnalités ne sont généralement pas disponibles en mode natif. C'est toutefois possible avec des licences tierces et, compte tenu de son importance, c'est un investissement qui en vaut la peine.

Avec la croissance constante des applications et l’abondance des données disponibles dans les médias que les attaquants utilisent 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 spear phishing étant le modus operandi des adversaires, la formation au phishing doit faire l’objet d’une attention particulière. 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 réduire le taux de réussite du phishing de 33 % à 13 %. Pourtant, les formations de sensibilisation à la sécurité sont rarement dispensées en nombre suffisant et avec le matériel adéquat. Les services de formation de sensibilisation en conserve conçus pour cocher les cases de conformité risquent de faire en sorte que les employés ne comprennent pas leur rôle dans la sécurité de l'information et n'aient pas le sens du devoir personnel à cet égard. Si l’objectif est de réduire le risque de violation, une formation fréquente, personnalisée en fonction de votre organisation, est la solution.

Il n’y a aucun temps d’arrêt pour les attaquants, et les employés doivent donc toujours rester vigilants. Une culture continue de curiosité devrait être la norme pour toutes les organisations, en particulier dans l’espace fédéral ou dans toute entreprise fournissant des produits et des services au gouvernement fédéral. Les employés doivent être conscients qu’ils sont une cible en raison de leur accès aux applications et aux données. Ils doivent également être conscients de la manière dont cet accès ou ces données sont utilisés par des États-nations adverses ou vendus par des cybercriminels à but lucratif (qui sont ensuite achetés par des adversaires).

Pour garantir le succès de leur transformation numérique, toutes les organisations doivent adopter une stratégie d’application d’entreprise et une politique correspondante, et former leurs employés à leur sujet. Dans l’espace fédéral, avec son large mélange d’applications héritées, hybrides et modernes, cela est particulièrement critique. Votre réussite dans la fourniture d’un service numérique fiable, sécurisé et autorisé l’exige.

Les applications sont au cœur de la transformation numérique de toute organisation et, avec l’évolution rapide de la manière dont les logiciels sont développés et déployés, elles constituent à la fois la plus grande source de valeur et la plus grande source de vulnérabilité d’une organisation. La stratégie d’application et les composants politiques décrits ici fournissent les bases essentielles pour sécuriser les aspirations 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.

¹ Le Bureau de la gestion et du budget Cloud Smart Strategy

² Laboratoires F5 : Les leçons tirées d’une décennie de violations de données

³ Des criminels piratent un aquarium pour voler des données dans un casino , selon Forbes

⁴ La violation de la cible s'est produite à cause d'une erreur de segmentation de réseau de base , ComputerWorld

⁵ État de la chaîne d'approvisionnement des logiciels 2018 , Sonatype