Il est de plus en plus courant d'utiliser des solutions SaaS (software as a service), principalement parce qu'elles sont rentables, faciles à utiliser, l'exploitation et la maintenance étant assurées par le fournisseur, et qu'elles offrent une grande sécurité, car les choses peuvent mal tourner si l'on n'est pas prudent et si l'on ne s'assure pas de la sécurité avant l'achat. Trop de gens achètent une solution SaaS avec la même attitude que lorsqu'ils achètent une voiture, ils s'attendent à ce que la personne qui a construit la voiture se soit assurée qu'elle est sûre et solide.
Commencez par déterminer qui est responsable et pour quoi afin d'avoir une bonne vue d'ensemble de la solution. L'informatique sur le cloud comporte de nombreux modèles différents : l'informatique en nuage privée, dans laquelle vous mettez en place votre propre environnement, exécutez et gérez vos propres machines. L'infrastructure en tant que service, où le client est responsable de certaines parties et le fournisseur de certaines parties. Ensuite, il y a la plateforme en tant que service, où le fournisseur s'occupe de la plupart des aspects, et le logiciel en tant que service, dont nous parlons dans cet article.
Il est de votre responsabilité de vous assurer que vous achetez un produit capable de gérer la classification de sécurité des données que la solution traitera. Comme pour l'achat d'une voiture, Volvo est responsable de s'assurer que vous pouvez conduire la voiture en toute sécurité et qu'elle n'a pas d'accident, mais si vous avez un accident et que vous vous blessez, c'est votre problème.
Lors de l'évaluation des fournisseurs et de l'achat, il est important que les exigences en matière de sécurité soient claires afin que vous puissiez vous assurer que vos données sont totalement sécurisées avec le fournisseur que vous choisissez.
Le contenu d'un cahier des charges est propre à chacun, mais il faut toujours partir du type de données que vous avez dans la solution lorsque vous définissez votre cahier des charges. Par exemple, si vous avez des informations de carte de crédit, la solution doit être capable de gérer PCI DSS, et si vous avez des données personnelles, la solution doit suivre la loi RGPD.
Même si les exigences sont différentes, la grande majorité d'entre elles garantissent généralement la réalisation de tests de pénétration. C'est généralement le fournisseur qui s'en charge. Un conseil : veillez à ce que le fournisseur fasse appel à un testeur indépendant. Pour plus de sécurité, vous devriez également être tenu d'utiliser vos propres testeurs indépendants lorsque vous achetez une solution, ce qui est presque toujours le cas. À la fin de cet article, vous trouverez une liste des éléments généraux les plus importants à inclure dans une déclaration de sécurité.
Les fournisseurs sont généralement très favorables à l'idée de faire appel à une partie externe et de payer les tests de sécurité, mais je pense que vous devriez vous assurer que le fournisseur couvre ce coût. Après tout, c'est vous qui êtes le client et qui allez payer pour le produit. C'est comme si vous achetiez une voiture et que vous l'ameniez ensuite chez un garagiste pour vérifier si elle est sûre, vous ne le faites pas.
En fonction de la solution SaaS, vous pouvez effectuer des configurations et des intégrations personnalisées. Dans ce cas, vous effectuez les tests à vos propres frais.
La plupart du temps, il est bon de s'assurer de ses besoins auprès du fournisseur lors de l'évaluation/avant l'achat, mais malheureusement, beaucoup s'en rendent compte trop tard. Vous vous retrouvez alors dans une situation où les exigences en matière de données ne sont pas personnalisées, ce qui rend l'ensemble plus complexe. La première chose à faire est d'examiner la solution, d'évaluer à quel point elle est critique pour vos informations et de voir s'il y a quelque chose que vous devez/pouvez changer. La deuxième étape consiste à déterminer si le fournisseur est disposé à effectuer ces changements, ce qui est généralement le cas. À partir de là, vous développez un ensemble d'exigences que vous examinez ensemble, en regardant ce qui existe aujourd'hui et ce qui doit être corrigé
Les fournisseurs de SaaS sont presque toujours favorables au changement, mais vous devez comprendre que cela ne se fera pas du jour au lendemain, mais que cela prendra du temps. Si vous recevez un refus, il vous suffit de décider s'il est possible de vivre avec le risque ou de commencer à chercher une nouvelle plateforme.
Avant de procéder à un achat, il est également important de savoir à quoi ressemble le processus de test du fournisseur et comment il travaille avec la sécurité. Vous ne voulez pas d'un propriétaire de produit qui donne la priorité à d'autres choses qu'à la sécurité et à ses mesures.
Vérifiez s'ils effectuent des tests de sécurité et, le cas échéant, quels sont ces tests. Renseignez-vous sur la manière dont les tests sont effectués, sur les personnes qui les réalisent, sur leur fréquence et sur le processus de résolution des failles en cas d'apparition de celles-ci. N'hésitez pas à demander des preuves afin d'examiner à quoi ressemblent les rapports et comment l'entreprise a résolu les vulnérabilités antérieures (le cas éché
Il doit y avoir une continuité dans leur travail de sécurité, les tests ne doivent pas être effectués uniquement lorsque quelqu'un le demande ou tous les trois ans.
Alors que de plus en plus d'entreprises s'orientent vers différentes solutions SaaS, le nombre de fournisseurs a complètement explosé. Que vous choisissiez d'exploiter votre propre système ou d'utiliser des solutions SaaS, il est extrêmement important de veiller à ce que l'application, l'infrastructure et les données soient protégées de manière adéquate. Le problème est que nous nous attendons souvent à ce que la sécurité soit en place sans vérifier ou poser des exigences lors de l'achat, ce qui peut avoir des conséquences fatales en cas d'attaque.
C'est pourquoi nous avons établi une liste de contrôle des éléments à inclure dans vos exigences lors de la phase d'achat d'une solution SaaS. Vous trouverez la liste ici.