Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 





















Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Information Services Group (ISG) : Connaissez-vous bien le SOC ?

octobre 2013 par Information Services Group (ISG)

Information Services Group (ISG), société dans le domaine des perspectives technologiques, l’analyse du marché et le conseil, divulgue sa stratégie pour une évaluation infaillible des services Cloud et dissipe la confusion autour du SOC.

Toute personne ayant un jour acheté une prestation d’hébergement ou des services logiciels auprès d’un fournisseur IT doit se demander si la « Certification SAS 70 » était incluse dans les critères d’évaluation du fournisseur. En tout cas, ce qui suit devrait l’alerter :

« Contrairement à ce qui est suggéré les documents commerciaux qui décrivent les modalités d’implémentation de SAS 70, les fournisseurs de services ne sont pas en mesure d’assurer le niveau d’assurance et de confiance promis », déplore Dan Schroeder, Partner de la société comptable Habif, Arogeti & Wynne et président du Comité Executive IT de l’AICPA. « C’est vraiment très choquant. »

Cette citation, publiée en 2010, est d’autant plus troublante trois ans plus tard, puisque l’on constate les mêmes difficultés sur SSAE 16 (Statement on Standards for Attestation Engagements), le successeur de SAS 70, comme outil de certification de sécurisation des systèmes.

Il règne une grande confusion sur le marché autour de ce sujet, dès lors que le Cloud est considéré comme un modèle de delivery. Une autre source d’inquiétude vient du fait que de nombreux acheteurs ne savent pas que SSAE 16 a très peu d’incidence sur la sécurité. Son seul but est de fournir une « attestation » sur la conception et l’efficacité des contrôles internes sur le reporting financier. Tel était déjà le cas pour SAS 70…

Pourquoi autant de confusion ? Selon Nazif Sharique de UHY Advisors, « Peu d’efforts ont été faits dans l’industrie afin d’apporter des réponses claires à cette question, et pour guider les fournisseurs de services vers les bonnes décisions concernant les certifications ». Si les fournisseurs ne sont pas clairs, les acheteurs ne peuvent pas l’être non plus.

Pour dissiper toute confusion, ISG recommande à ses clients de se concentrer sur les types de rapports spécifiques que le fournisseur peut produire pendant l’évaluation. Une fois cette information connue, il est possible de connaitre le type d’audit dont le fournisseur a fait réellement fait l’objet :

• Un rapport SOC1 (Service Organization Control) est produit à partir d’un audit SSAE 16. Ce dernier étant le successeur de SAS70, la meilleure façon d’analyser un rapport SOC 1 est comme un successeur au rapport SAS 70. Comme mentionné précédemment, la certification SSAE 16 est axée sur les contrôles internes relatifs au reporting financier, les systèmes ou solutions informatiques non spécifiques.

• Un rapport SOC2, contrairement à SOC1, est axé sur les attributs des systèmes - la sécurité, la disponibilité, l’intégrité de traitement et la confidentialité. Collectivement, ces attributs constituent le cadre « Trust Services Principles ». Essentiellement, avec un rapport SOC2, un prestataire de services doit cartographier ses processus par rapport à ce cadre. L’avantage : étant donné que les fournisseurs doivent correspondre à une norme, cela permet aux acheteurs de tout de suite comparer, ce qui est comparable, entre les fournisseurs. L’inconvénient : les fournisseurs peuvent choisir quels attributs ils souhaitent cartographier. Il est donc important d’examiner le rapport SOC 2 dans son intégralité.

• Un rapport SOC 3 est très similaire à un rapport SOC2. La différence principale est qu’il peut être utilisé comme un outil de marketing auprès du grand public, contrairement à un SOC2, qui a une diffusion beaucoup plus restreinte : management, auditeurs, clients et prospects (si accord de non divulgation). Voici une comparaison de haut niveau :

Il y a un dernier rebondissement à l’histoire du SOC. Pour chacun de ces trois rapports, il existe deux types. Un rapport de Type 1, qui comprend à la fois une description du système, écrit par le fournisseur et l’avis de l’auditeur quant à l’adéquation de la conception des contrôles sur ce système. Et un rapport de Type 2 qui comprend tout ce qui précède, avec en plus les contrôles menés par l’auditeur sur l’efficacité du fonctionnement des contrôles sur une période de temps.

Ce dernier point est essentiel.

Un rapport de Type 1, permet d’obtenir seulement une opinion tierce sur la conception des contrôles, sans confirmation que les contrôles fonctionnent réellement. Or, il ne faut pas oublier que pour quiconque cherchant des services de Cloud, et notamment des services multi-tenant, les fournisseurs peuvent refuser de se laisser auditer directement. Bref, pour éviter d’acheter des services Cloud qui : 1) n’ont pas été vérifiés par une entité tierce ; 2) que l’on ne peut pas vérifier soi-même, l’utilisateur devrait rafraîchir ses listes de contrôle de sécurité des fournisseurs et s’assurer qu’un rapport SOC 2 de type 2 figure dans le cadre des critères d’évaluation. C’est d’autant plus important s’il envisage des services de Cloud partagés et si le prestataire pose des limites à sa capacité de vérification. Il convient également d’insister pour voir les résultats détaillés.

Evidemment, cela ne signifie pas qu’un SOC 2 de Type 2 est tout ce dont l’utilisateur a besoin pour faire une évaluation correcte. Il faut aussi inclure d’autres activités qui relèvent de la Due Diligence, ainsi que des preuves d’autres certifications, attestations et normes qui sont importantes pour lui et son entreprise (par exemple, PCI, HIPAA, FedRAMP). Toutefois, le SOC 2 de Type 2 peut augmenter le degré de confiance sur le fait que le fournisseur met en pratique ce qu’il a promis pendant le processus de vente.

Julien Escribe, Partner chez ISG, résume la situation : « La sécurité des SI des grandes entreprises oscille entre la logique de l’aéroport (un système ouvert sur les échanges, avec des règles précises permettant à chacun de travailler en confiance) et celle du château-fort (tout est interdit a priori et tout se gère par exception). Les outils de certifications dans le Cloud n’ont pas encore permis de dupliquer ces 2 types de logiques. En revanche, les certifications de type SSAE 16 – même si elles restent très anglo-saxonnes – vont dans le bon sens pour augmenter le niveau de confiance de chacun dans ces solutions de Cloud, qu’elles soient privées ou hybrides. Beaucoup d’acteurs du Cloud ayant des origines américaines, il est important que les utilisateurs européens maîtrisent ces concepts importants ».


Voir les articles précédents

    

Voir les articles suivants