Lorsque les entreprises déplacent des fichiers de travail vers le cloud pour prendre en charge les travailleurs distants, elles créent souvent des opportunités pour les attaquants. Ce sont les erreurs les plus courantes à éviter.
introduction
À la suite de la pandémie, de nombreuses entreprises sont passées par nécessité à davantage d'applications basées sur le cloud, car nous sommes plus nombreux à travailler à distance. Dans une enquête menée auprès de 200 responsables informatiques par Menlo Security, 40% des personnes interrogées ont déclaré être confrontées à des menaces croissantes provenant des applications cloud et des attaques Internet des objets (IoT) en raison de cette tendance.
Il existe de bonnes et de mauvaises façons de réaliser cette migration vers le cloud. De nombreux écueils ne sont pas nouveaux. Par exemple, lors d'une réunion Gartner 2019, deux responsables informatiques ont déclaré que leur déploiement d'Office 365 était suspendu en raison de la nécessité de mettre à jour le matériel hérité. Maintenant, la façon dont nous utilisons et partageons nos ordinateurs personnels a changé. Nos ordinateurs ne sont plus personnels. Ce même ordinateur peut prendre en charge l'école virtuelle de votre enfant et les applications de votre conjoint.
L'enquête d'été de CyberArk a révélé que plus de la moitié des répondants enregistrent leurs mots de passe sur les navigateurs de PC d'entreprise. Bien sûr, cela ne promet rien de bon pour une politique de sécurité.
Voici sept principales erreurs qui nuisent à la sécurité et quelques conseils pour les éviter.
1. Utilisation du VPN pour l'accès à distance
Avec tous les travailleurs distants, un VPN n'est peut-être pas la meilleure solution d'accès. Découvrez ce qui s'est passé en décembre 2020 avec le hack FireEye. Apparemment, le compte VPN piraté a été le point de départ du pirate informatique pour voler ses outils. Dans le passé, les VPN étaient le principal moyen de protéger les travailleurs distants.
Il est bien préférable de remplacer les VPN par des réseaux sans confiance, où l'identité est le plan de contrôle et fournit le contexte d'accès.
2. Construire le mauvais portefeuille cloud
J'entends par là considérer plusieurs facteurs. Vous avez besoin de clouds privés pour séparer vos données commerciales critiques du reste de l'univers? Vous disposez d'un système d'exploitation adapté.
Des versions sont-elles disponibles pour exécuter des applications spécifiques qui dépendent de configurations Windows et Linux spécifiques? Disposez-vous des bons connecteurs et protecteurs d'authentification pour travailler avec des applications et du matériel sur site que vous ne pouvez pas transporter? Si vous avez une ancienne application mainframe?
Vous voudrez probablement l'exécuter d'abord sur un cloud privé, puis essayez de trouver un environnement approprié le plus proche de votre configuration mainframe existante.
3. Votre politique de sécurité n'est pas adaptée au cloud
Les erreurs courantes de sécurité dans le cloud incluent des conteneurs de stockage non sécurisés, des droits d'accès et des paramètres d'authentification mal configurés et des ports ouverts. Vous souhaitez maintenir une sécurité constante, que vous soyez localement ou que vous vous connectiez depuis Timbuktu Pro. Vous voulez également être en sécurité dès le départ, avant de déplacer une application autonome vers le cloud.
Johnson & Johnson l'a fait il y a quelques années lorsqu'il a transféré la plupart de ses charges de travail vers le cloud et centralisé son modèle de sécurité. Aide: Netflix vient de publier un outil open source qu'ils appellent ConsoleMe. Il peut gérer plusieurs comptes Amazon Web Services (AWS) dans une seule session de navigateur.
4. Ne testez pas les plans de reprise après sinistre
À quand remonte la dernière fois que vous avez testé votre plan de reprise après sinistre (DR)? C'était peut-être il y a trop longtemps, surtout si vous étiez occupé par les problèmes quotidiens de soutien aux travailleurs domestiques.
Le fait que vos applications soient dans le cloud ne signifie pas qu'elles sont indépendantes de certains serveurs Web, serveurs de bases de données et autres éléments d'infrastructure. Une bonne reprise après sinistre consiste à documenter ces dépendances et à disposer d'un didacticiel couvrant les flux de travail les plus importants.
Un autre élément important de tout plan de reprise après sinistre est le test continu des pannes de cloud partielles. Vous rencontrerez probablement des interruptions dans votre travail. Même les clouds Amazon, Google et Microsoft en font l'expérience de temps en temps. Netflix a été l'un des premiers endroits où l'ingénierie générale du chaos avec un outil appelé Chaos Monkey est devenue populaire il y a quelques années. Il a été conçu pour tester l'infrastructure AWS de l'entreprise en arrêtant constamment et accidentellement divers serveurs de production.
Utilisez ces leçons et outils pour développer vos propres tests de défaillance, en particulier les tests liés à la sécurité qui identifient les faiblesses de votre configuration cloud. Un élément clé est de le faire automatiquement et en permanence pour identifier les goulots d'étranglement et les lacunes de l'infrastructure. En plus d'utiliser les outils open source de Netflix, il existe des produits commerciaux tels que la validation de sécurité de Verodin / Mandiant, la simulation de violation et d'attaque de SafeBreach, les outils de simulation Cymulate et la plate-forme d'optimisation de la sécurité d'AttackIQ.
5. L'authentification n'est pas optimisée pour un portefeuille avec un service cloud dominant
Vous pouvez avoir un compte et un contrôle d'accès, SIEM, CASB, ou un - un outil de connexion qui a été acquis à l'ère du LAN. Il ne répond désormais pas à vos besoins d'authentification, un monde principalement basé sur le cloud et un monde d'accès à distance.
Assurez-vous d'examiner de près ces outils pour vous assurer qu'ils peuvent couvrir l'environnement cloud et l'ensemble de votre portefeuille d'applications qui protègent vos systèmes. Par exemple, les CASB font un excellent travail de gestion de l'accès aux applications cloud, vous pourriez en vouloir une qui puisse fonctionner avec votre application personnalisée interne spécifique. Gestion des risques basée sur l'authentification ou protection contre les menaces plus complexes et mixtes.
6. Active Directory obsolète
"L'identité est désormais un nouveau périmètre et les données se répandent partout", ont déclaré David Mahdi et Steve Riley de Gartner dans leur présentation.
«Vous devez donner aux gens le bon accès aux bonnes ressources, au bon moment et pour la bonne raison.»
Bien sûr, il y a beaucoup à résoudre ici. Cela signifie que votre Active Directory (AD) peut ne pas refléter la réalité à la fois de la liste des utilisateurs actuels et autorisés et des applications et serveurs actuels et autorisés.
La transition vers le cloud sera plus fluide si vous transférez les informations les plus précises.
7. Refus de demander de l'aide
De nombreux fournisseurs de services de sécurité gérés (MSSP) se spécialisent dans ces types de migrations, et vous ne devriez pas hésiter à les contacter pour obtenir de l'aide.
Vous êtes peut-être trop occupé pour accorder toute votre attention à la migration et avez oublié par inadvertance certains aspects importants. Pressés, ils ont tout déplacé vers le cloud et laissé plusieurs portes dérobées ouvertes ou introduit des vulnérabilités.