PageUp: les données de recrutement, un test de responsabilité SaaS

Résumé

• L'incident de 2018 de PageUp est important car une plateforme SaaS de recrutement se trouvait entre les employeurs qui achetaient le service et les candidats dont les données personnelles, professionnelles et de filtrage étaient traitées par son intermédiaire.
• La question de responsabilité est de savoir qui avait le contrôle pratique sur la garde des données des candidats, les limites de locataire des employeurs, la délimitation de la brèche, la notification aux clients, le repli du processus de recrutement et la preuve que les affirmations de réparation de la plateforme étaient plus que de simples paroles rassurantes.
• Les archives publiques incitent à la prudence: PageUp et les rapports publics ont décrit des activités non autorisées et un risque d'accès potentiel, tandis que des reportages ultérieurs ont souligné que les enquêteurs n'avaient pas trouvé de preuves spécifiques d'exfiltration. Ce sont des déclarations différentes qui ne doivent pas être confondues.
• L'incident a forcé les universités, les entreprises, les employeurs du secteur public, les candidats, les recruteurs et les régulateurs à dépendre de la délimitation médico-légale et de la chaîne de communication d'un seul fournisseur, même lorsqu'ils n'avaient pas d'accès direct aux journaux de la plateforme.
• Cet article considère les rapports de notification de violation de données du OAIC, les avis publics aux clients, les documents actuels de sécurité et de confidentialité de PageUp et les reportages contemporains comme des preuves publiques. Il ne prétend pas avoir accès aux journaux privés de PageUp, aux enregistrements des locataires clients, aux images médico-légales ou aux données d'exposition candidat par candidat.

Pourquoi ce cas figure dans un dossier de risque et de responsabilité

PageUp figure dans un dossier de risque et de responsabilité car un logiciel de recrutement n'est pas un simple outil de back-office. C'est un système de garde de données pour des personnes souvent en position de faiblesse. Une personne qui postule un emploi dans une université, un organisme public, un détaillant, une entreprise énergétique ou une grande entreprise peut ne pas connaître PageUp par son nom.

Le candidat voit la marque de l'employeur, télécharge un CV, rédige des lettres de motivation, saisit ses coordonnées, liste son historique professionnel, répond à des questions de filtrage et fournit parfois des informations d'identité, de référence, de visa ou de vérification des antécédents. L'employeur a choisi la plateforme. Le candidat a fourni les données parce que le processus de recrutement de l'employeur l'exigeait.

Cette structure modifie la question de responsabilité. Dans de nombreux incidents SaaS, le client payant dispose au moins d'une voie contractuelle pour demander des preuves au fournisseur. Les candidats, généralement, n'en ont pas. Leur premier avis peut provenir de l'employeur, d'une page web universitaire, d'un rapport public de violation ou d'un article de presse. Ils ne peuvent pas inspecter l'isolation des locataires du fournisseur, l'architecture de la base de données, la conservation des journaux, la chronologie de l'incident ou les conclusions médico-légales.

Ils ne peuvent pas choisir un autre processeur de recrutement pour une ancienne candidature. Ils ne peuvent pas savoir facilement si un ancien CV, une adresse, un numéro de téléphone, un historique professionnel ou une réponse de filtrage fait désormais partie d'une surface de phishing ou de risque d'identité.

Les preuves publiques commencent par le fait que PageUp a divulgué un incident de sécurité affectant sa plateforme de recrutement en 2018. Les reportages contemporains surhttps://www.securityweek.com/hr-software-firm-pageup-suffers-data-breach/décrivaient PageUp avertissant ses clients après avoir découvert une activité non autorisée. Les reportages publics australiens surhttps://www.abc.net.au/news/2018-06-06/australian-data-may-be-compromised-in-pageup-security-breach/9840048ethttps://www.theguardian.com/technology/2018/jun/07/thousands-of-job-seekers-details-potentially-exposed-in-hackmontraient pourquoi l'événement est rapidement devenu plus qu'un incident de fournisseur: de grands employeurs et universités ont dû expliquer le risque possible aux candidats et aux candidats au personnel.

Le rapport de 12 mois du Bureau du Commissaire australien à l'information sur les violations de données notifiables à l'adressehttps://www.oaic.gov.au/privacy/notifiable-data-breaches/notifiable-data-breaches-publications/notifiable-data-breaches-scheme-12-month-insights-reportest important car il a encadré la première année du régime de notification obligatoire de l'Australie et a discuté des conditions de violation multipartites. La version PDF à l'adressehttps://www.oaic.gov.au/__data/assets/pdf_file/0016/2356/ndb-scheme-12month-insights-report.pdfest utile comme enregistrement stable. PageUp était le type d'événement qui teste si un régime de violation peut gérer les fournisseurs cloud qui traitent des informations pour de nombreuses entités clientes à la fois. Un seul incident de plateforme peut produire de nombreuses notifications en aval, de nombreuses personnes affectées confuses et de nombreuses obligations qui se chevauchent.

La question centrale n'est donc pas « Est-ce que les données de chaque candidat ont été volées? » Les preuves publiques ne soutiennent pas cette affirmation brutale. La question plus forte est: qui contrôlait les preuves nécessaires pour décider qui était à risque? PageUp contrôlait la plateforme, l'engagement médico-légal, le canal de communication avec les clients, la capacité de dire quels systèmes étaient impliqués et la preuve technique de confinement. Les clients contrôlaient leurs propres relations avec les candidats, les avis publics et les décisions relatives au processus de recrutement.

Les candidats ne contrôlaient presque aucun des faits.

C'est pourquoi ce cas correspond aux sujets de dépendance aux services cloud, de souveraineté et localité des données, et d'automatisation des logiciels d'entreprise. La fonction de recrutement est devenue une dépendance cloud. Les données se trouvaient dans une relation de traitement avec des obligations juridictionnelles et de confidentialité. Le processus lui-même était suffisamment automatisé pour qu'une panne ou une suspension de la plateforme puisse interrompre le recrutement. Le problème de responsabilité émerge de cette combinaison.

Le déclencheur de l'incident était une activité non autorisée, mais le vrai problème était la garde des preuves

Le déclencheur a été la découverte par PageUp d'une activité non autorisée dans son environnement informatique et sa notification aux clients concernant une possible exposition de données. Les reportages contemporains décrivaient l'entreprise prenant des mesures pour enquêter et sécuriser ses systèmes. Des reportages ultérieurs surhttps://www.itnews.com.au/news/pageup-security-incident-shows-no-sign-of-exfiltration-494495ethttps://www.itnews.com.au/news/no-evidence-data-stolen-in-compromise-pageup-515978rapportaient que le travail médico-légal n'avait pas trouvé de preuves spécifiques que des informations personnelles avaient été emportées. Le rapport de BankInfoSecurity surhttps://www.bankinfosecurity.com/pageup-no-evidence-personal-data-was-exfiltrated-a-11724décrivait également la distinction entre un accès possible et l'absence de preuve d'exfiltration.

Cette distinction est importante. « Aucune preuve d'exfiltration » n'est pas la même chose que « aucun risque ». Cela peut signifier que les journaux, les indicateurs, les traces réseau, les preuves de point de terminaison et l'examen médico-légal n'ont pas montré de copie de données. C'est une conclusion importante. Elle peut réduire le préjudice attendu. Mais elle dépend toujours de l'exhaustivité des journaux, de la fenêtre temporelle, des systèmes examinés et du niveau de confiance du processus médico-légal. Les candidats ne peuvent pas vérifier indépendamment l'une de ces conditions.

Les clients peuvent recevoir plus de détails par contrat ou par le biais des canaux réglementaires, mais leurs avis publics doivent souvent traduire la conclusion en langage simple.

C'est la première voie de responsabilité: la garde des preuves. Une plateforme de recrutement peut détenir des données pour le compte de milliers d'employeurs et de millions de candidats au fil du temps. Le fournisseur contrôle l'environnement dans lequel la brèche est délimitée. Si le fournisseur dit qu'il n'y a aucune preuve spécifique de vol, les personnes affectées doivent savoir sur quoi repose cette déclaration. Le journal d'accès pertinent a-t-il été conservé? Les bases de données concernées étaient-elles instrumentées? Les journaux d'application pouvaient-ils distinguer un accès en lecture d'un accès en écriture?

Les exportations, téléchargements, appels API, rapports et actions administratives étaient-ils enregistrés séparément? Les fichiers, CV, pièces jointes et champs de base de données étaient-ils couverts par le même examen? Les anciens dossiers de candidats se trouvaient-ils dans le même environnement que les processus en cours?

Ces questions ne sont pas académiques. Les données des candidats sont inhabituellement réutilisables par les attaquants. Un CV peut inclure un nom complet, un numéro de téléphone, une adresse email, une ville, un historique professionnel, une formation, des licences professionnelles, des références et parfois des documents d'identité partiels. Une candidature peut révéler le salaire souhaité, la disponibilité, le statut d'immigration, les handicaps ou aménagements, les réponses aux vérifications de casier judiciaire, le statut de candidat interne et l'historique professionnel.

Même lorsque les documents les plus sensibles ne sont pas présents, un dossier de candidature détaillé peut soutenir un phishing ciblé contre les chercheurs d'emploi ou les employeurs.

Le suivi de SecurityWeek surhttps://www.securityweek.com/hr-software-firm-pageup-finds-no-evidence-data-theft/est utile car il a capturé la posture publique après une enquête plus approfondie: une déclaration probante plus étroite plutôt qu'un déni en bloc du risque d'incident. Cette posture est meilleure que de faire semblant qu'il n'y a eu aucun problème, mais elle laisse toujours la population affectée dépendante d'une chaîne de confiance. PageUp devait informer les clients. Les clients devaient informer les candidats lorsque cela était requis ou prudent. Les candidats devaient décider de surveiller ou non les fraudes, le phishing ou les utilisations abusives.

Le test de responsabilité est de savoir si cette chaîne a préservé l'incertitude honnêtement. Une plateforme ne devrait pas exagérer le préjudice pour créer la panique, mais elle ne devrait pas non plus transformer des preuves incomplètes en réassurance absolue. La formulation la plus forte sépare les faits confirmés, les faits probables, les faits possibles et les inconnues. Un candidat peut agir sur « il n'y a aucune preuve que vos données aient été prises, mais le système qui traitait les candidatures a été accédé et ces types de données peuvent avoir été présents ». Un candidat ne peut pas agir sur une confiance vague.

Les candidats étaient des personnes affectées, pas seulement des enregistrements clients

Le cas PageUp est facile à sous-estimer si le mot « client » ne désigne que l'employeur. Les clients de PageUp étaient des organisations utilisant la plateforme de recrutement. Les personnes affectées étaient les candidats, les employés potentiels, les candidats au personnel et parfois les employés existants utilisant des processus de recrutement interne ou d'intégration. Cette différence change l'éthique de l'avis.

Les avis aux clients montrent comment l'incident s'est propagé à travers les institutions. L'Université du Queensland a publié un avis sur le problème de sécurité PageUp à l'adressehttps://news.uq.edu.au/2018-06-08-pageup-security-issueet a dirigé les personnes affectées vers des informations sur le système de recrutement. L'Université Monash a publié une mise à jour à l'adressehttps://www.monash.edu/news/articles/update-on-recruitment-and-staff-onboarding-system. SA Power Networks a publié un avis d'incident de cybersécurité PageUp à l'adressehttps://www.sapowernetworks.com.au/data/24395/pageup-cyber-security-incident/. Ces avis sont importants car ils montrent la forme pratique de la responsabilité SaaS multipartite. Le fournisseur a enquêté sur la plateforme. Les employeurs avaient la relation avec le candidat. Le candidat avait besoin d'informations exploitables.

Certaines personnes affectées par une brèche de recrutement peuvent ne jamais devenir employées. Cela rend le redressement plus difficile. Elles peuvent ne pas avoir de contact interne, de portail du personnel ou de relation continue avec l'employeur. Elles peuvent avoir postulé des mois ou des années plus tôt et être passées à autre chose. Elles peuvent utiliser une adresse email qui a changé. Elles peuvent avoir soumis des données par l'intermédiaire de plusieurs employeurs utilisant la même plateforme, créant une exposition en double ou qui se chevauche.

Elles peuvent ne pas savoir quelle organisation est responsable de répondre aux questions.

L'incident public a également intersecté avec la confiance dans les universités et les organismes publics. Lorsqu'une université utilise une plateforme de recrutement tierce, le candidat peut supposer que l'université contrôle les données. En pratique, l'université contrôle le processus de recrutement et la sélection du fournisseur, mais le fournisseur SaaS contrôle l'environnement système. C'est le fossé de responsabilité. La personne qui subit un possible phishing ou de l'anxiété peut blâmer l'institution qu'elle reconnaît. L'institution peut dépendre des preuves médico-légales du fournisseur.

Le fournisseur peut ne pas avoir de relation directe avec le candidat. Chaque maillon peut être rationnel, et le système global peut encore laisser la personne avec des preuves faibles.

C'est pourquoi l'avis aux candidats devrait faire plus que répéter une déclaration du fournisseur. Il devrait dire quelles classes de données étaient probablement détenues, quelles périodes de candidature étaient incluses, si les candidatures internes étaient affectées, ce que le fournisseur a confirmé, ce qui reste inconnu, quelles actions l'institution a prises et ce que le candidat peut faire. Il devrait éviter de sous-entendre que le candidat a personnellement choisi le processeur.

Il devrait également expliquer comment les anciens dossiers de candidature sont conservés et quand ils sont supprimés, car la minimisation des données est un contrôle uniquement si la pratique de conservation est connue avant une brèche.

L'incident PageUp a exposé un schéma plus large dans l'automatisation des logiciels d'entreprise. Les organisations automatisent le recrutement pour réduire les coûts administratifs, améliorer le flux de travail, suivre la conformité et créer un traitement cohérent des candidats. Le système devient une couche d'enregistrement. Lorsqu'il échoue, l'impact ne se limite pas aux temps d'arrêt. Il devient une question de confidentialité, de preuve et de devoir de diligence pour les personnes dont la relation avec le système est temporaire et asymétrique.

Les limites de locataire devaient être prouvées, non supposées

La responsabilité SaaS multi-locataire dépend des limites de locataire. Dans une plateforme de recrutement, un employeur ne devrait pas exposer les candidats d'un autre employeur simplement parce que les deux utilisent le même fournisseur. La plateforme devrait être capable de prouver quels locataires, tables, compartiments de stockage, fichiers, intégrations, exportations et consoles d'administration étaient accessibles pendant l'incident. Sans cette preuve, le message public le plus sûr devient large et vague, ce qui augmente l'incertitude pour tout le monde.

Les archives publiques ne fournissent pas une carte complète de l'architecture de l'environnement 2018 de PageUp. Cette limitation a de l'importance. Une analyse responsable ne devrait pas inventer une cause technique racine. Les preuves disponibles soutiennent une conclusion plus modeste: les clients et les candidats ont dû se fier à la délimitation par PageUp des systèmes et types de données affectés. C'est suffisant pour rendre la preuve des limites de locataire centrale au dossier de responsabilité.

La preuve des limites de locataire comporte plusieurs parties. Premièrement, les journaux d'authentification et d'autorisation devraient montrer quels comptes, sessions, comptes de service ou composants d'infrastructure ont été utilisés. Deuxièmement, les journaux d'application devraient montrer si les dossiers des candidats, pièces jointes, rapports, exportations ou pages d'administration ont été consultés. Troisièmement, les contrôles de base de données et de stockage devraient séparer suffisamment les données des clients pour qu'un composant compromis n'implique pas un accès à l'échelle de la plateforme.

Quatrièmement, les systèmes de sauvegarde, d'analyse, de support et de rapport devraient être inclus dans la carte des preuves, car les données quittent souvent le chemin principal de l'application. Cinquièmement, les intégrations avec les fournisseurs d'identité, les fournisseurs de vérification des antécédents, les services de messagerie et les systèmes RH devraient être examinés pour détecter les chemins latéraux.

La leçon n'est pas que chaque avis public doive publier un diagramme de schéma. Il ne devrait pas. Publier des détails d'architecture sensibles pourrait créer un nouveau risque. La leçon est que le fournisseur et les clients ont besoin d'un dossier de preuves interne suffisamment solide pour justifier la portée publique. Si l'avis public dit que seuls certains types de données ou clients ont été affectés, les preuves privées devraient montrer pourquoi. Si l'avis public dit qu'il n'y a aucune preuve d'exfiltration, les preuves privées devraient montrer quels journaux soutiennent cette conclusion.

La page de sécurité actuelle de PageUp à l'adressehttps://www.pageuppeople.com/how-we-do-it/security/est pertinente en tant que vocabulaire de contrôle plutôt que comme preuve directe de l'état de l'incident de 2018. Elle présente les pratiques de sécurité actuelles et les thèmes d'assurance. La politique de confidentialité de PageUp à l'adressehttps://www.pageuppeople.com/privacy-policy/est pertinente car elle montre les types d'engagements de confidentialité et d'explications de traitement qu'un fournisseur de technologie RH moderne offre. La page de divulgation responsable à l'adressehttps://www.pageuppeople.com/responsible-disclosure/est pertinente car la prise en charge des vulnérabilités fait partie du maintien de la confiance dans un service cloud. Aucune de ces pages ne prouve ce qui s'est passé en 2018. Elles aident à définir la norme de contrôle qu'une plateforme de recrutement doit respecter après un tel événement.

La question pratique des limites de locataire est également économique. Les employeurs achètent un SaaS de recrutement parce qu'ils ne veulent pas exploiter la plateforme eux-mêmes. Ils s'attendent à ce que le fournisseur gère la sécurité, l'hébergement, les mises à jour du flux de travail, le suivi des candidats et le support. Cela signifie que le fournisseur contrôle les preuves les plus importantes. Le langage contractuel peut attribuer des devoirs, mais les preuves suivent le contrôle opérationnel.

Si le client ne peut pas inspecter l'environnement directement, le fournisseur doit produire des conclusions crédibles assez rapidement pour que le client puisse remplir ses obligations de confidentialité et maintenir la confiance des candidats.

Le calendrier de notification était un système partagé, pas un message unique

La notification dans une brèche SaaS est un système. Le fournisseur découvre et enquête. Le fournisseur notifie les clients. Les clients décident si et comment notifier les personnes affectées, les régulateurs, le personnel, les recruteurs, les responsables du recrutement et les tiers. Les régulateurs reçoivent les notifications en vertu de la loi locale. Les reportages médiatiques créent une sensibilisation du public. Les candidats peuvent contacter plusieurs employeurs. Une seule déclaration peu claire peut multiplier la confusion.

Le régime australien de notification des violations de données a rendu cette structure plus visible. Le rapport public de l'OAIC à l'adressehttps://www.oaic.gov.au/privacy/notifiable-data-breaches/notifiable-data-breaches-publications/notifiable-data-breaches-scheme-12-month-insights-reporta souligné comment les violations de données éligibles et les obligations de notification fonctionnaient au cours de la première année du régime. Un incident de fournisseur cloud peut créer à la fois un événement au niveau du processeur et de nombreuses décisions au niveau du client quant à savoir s'il existe un risque probable de préjudice grave. C'est un test de résistance de la gouvernance. Il demande si le fournisseur peut donner aux clients suffisamment d'informations assez rapidement pour prendre des décisions de notification défendables.

L'incident de PageUp s'est produit à une période où les organisations apprenaient encore le régime. Cela n'abaisse pas le devoir envers les personnes affectées. Cela soulève l'importance de rôles clairs. Un fournisseur devrait identifier les entités de contrôle ou les clients, décrire les catégories de données, définir les fenêtres temporelles affectées et tenir les clients informés à mesure que la confiance médico-légale évolue. Les clients ne devraient pas attendre une certitude parfaite si le seuil de risque est atteint, mais ils ne devraient pas non plus émettre des alarmes vagues non étayées par des faits.

Les régulateurs devraient pouvoir voir la distinction entre une prudence rapide et une enquête incomplète.

Les avis publics aux clients faisaient partie de la chaîne de preuves. Ils montraient quelles organisations ont suspendu ou modifié leurs processus de recrutement, quels conseils elles ont donnés et comment elles ont traduit les conclusions de PageUp en langage destiné aux candidats. Un bon avis devrait identifier le fournisseur, expliquer la nature de l'incident, décrire les classes de données en question, pointer vers des précautions contre la fraude et le phishing, et fournir une voie de contact. Un avis faible laisse le candidat avec seulement « un incident chez un tiers s'est produit », ce qui n'est pas suffisant.

L'incident met également en évidence le défi des mises à jour répétées. Les premiers avis viennent souvent avant que l'examen médico-légal ne soit terminé. Des mises à jour ultérieures peuvent réduire le risque. Cela peut créer un scepticisme public: les gens entendent d'abord « brèche possible » puis « aucune preuve de vol ». L'approche responsable n'est pas d'éviter les premiers avis. C'est d'étiqueter soigneusement les niveaux de confiance. « Enquête en cours » devrait signifier enquête en cours. « Aucune preuve » devrait identifier la base de preuves. « Aucun impact » devrait être réservé aux cas où le fournisseur peut le prouver.

C'est là que le prisme de contrôle de Daniel Kade a de l'importance. La responsabilité suit le contrôle pratique sur les preuves, pas seulement la visibilité de la marque. L'employeur peut être la partie visible. PageUp avait le contrôle pratique sur les preuves de la plateforme. Le candidat n'avait un contrôle pratique que sur les précautions en aval telles que les changements de mot de passe, la sensibilisation au phishing et la surveillance des utilisations abusives. Ce déséquilibre est la raison pour laquelle la notification doit être conçue pour la partie la moins puissante de la chaîne.

La souveraineté et la localité des données n'étaient pas des questions de politique abstraites

Les données de recrutement traversent les frontières plus facilement que les candidats ne peuvent s'y attendre. Une plateforme RH mondiale peut traiter des données pour des clients dans plusieurs juridictions, héberger l'infrastructure dans des régions particulières, utiliser des équipes de support dans plusieurs endroits et s'intégrer à des services qui créent des flux de données supplémentaires. L'incident PageUp a rendu la souveraineté et la localité des données concrètes. La question n'était pas seulement de savoir où l'entreprise avait son siège social.

Il s'agissait de savoir où les dossiers des candidats étaient stockés, qui pouvait y accéder, quelle loi s'appliquait et quel régulateur ou client disposait des preuves.

Les archives publiques n'exigent pas d'affirmer que toutes les données des candidats ont traversé une frontière d'une manière particulière. Le point de responsabilité est plus étroit: les plateformes de recrutement cloud devraient rendre la garde juridictionnelle compréhensible avant une brèche. Les politiques de confidentialité et les contrats devraient dire aux clients et aux candidats comment les informations personnelles sont traitées, où elles peuvent être hébergées ou accessibles, et quels sous-traitants ou voies de support sont importants.

Si une brèche se produit, la même carte devrait soutenir la notification réglementaire et la communication avec les personnes affectées.

Le rapport de l'OAIC est pertinent ici car le régime australien fonctionne à travers le prisme des entités couvertes par la loi australienne sur la confidentialité et du préjudice grave probable. Un incident de plateforme affectant des candidats australiens peut exiger une notification australienne même si des parties de la pile technique ou de la clientèle sont mondiales. D'autres juridictions peuvent avoir des seuils et des délais différents. Un fournisseur multi-locataire a besoin d'un ensemble de preuves de notification qui peut soutenir ces différences sans produire des faits incohérents.

La localité des données intersecte également avec la conservation. Les données des candidats peuvent rester longtemps après la fin d'un processus de recrutement. Les employeurs peuvent conserver les candidatures pour de futurs postes, la conformité, les rapports d'égalité des chances, l'audit, les viviers de talents ou les raisons contentieuses. Les fournisseurs peuvent conserver les journaux, les pièces jointes, les sauvegardes et les données de flux de travail dérivées. Plus la conservation est longue, plus la surface de brèche est large. La souveraineté des données sans discipline de conservation est incomplète.

Savoir que les données se trouvent dans un pays donné n'aide pas si les anciennes candidatures restent accessibles sans un besoin commercial clair.

C'est la question de gouvernance que les employeurs devraient se poser après PageUp: quels champs de candidature sont nécessaires, combien de temps sont-ils conservés, quels champs sont visibles pour les recruteurs, lesquels sont visibles pour le support du fournisseur, lesquels sont exportés, lesquels sont supprimés après une période, et comment la suppression est prouvée dans les sauvegardes et les systèmes d'analyse. Les logiciels de recrutement peuvent rendre la collecte de données bon marché. La responsabilité en cas de brèche montre que chaque champ supplémentaire a un coût de risque futur.

L'alerte client de Marsh à l'adressehttps://www.marsh.com/content/dam/marsh/Documents/PDF/en_au/Client%20Alert%20-%20PageUp%20data%20breach%20-%20June%202018.pdfet la discussion d'Aon à l'adressehttps://www.aon.com.au/australia/risk-solutions/cyber-risk/pageup-breach-largest-cyber-incident-in-australia.jspsont utiles car ils ont traité l'incident comme un événement de risque organisationnel, pas seulement une histoire technique. Le cyberrisque dans le recrutement comprend les obligations légales, les questions d'assurance, la gestion des fournisseurs, la continuité des activités et les communications. Ce cadre plus large est approprié. La garde des données des candidats est une fonction de gouvernance.

La continuité du processus de recrutement faisait partie du modèle de préjudice

L'incident PageUp a également créé une question de continuité. Les plateformes de recrutement sont des systèmes de flux de travail. Elles acheminent les candidatures, soutiennent les approbations, envoient des communications, suivent l'intégration et conservent l'historique des candidats. Si un client suspend l'utilisation de la plateforme pendant un incident, le recrutement peut ralentir. Si le client continue de l'utiliser, il doit faire confiance au confinement du fournisseur.

Si le client passe à un repli manuel, cela peut créer de nouveaux risques de confidentialité par le biais de feuilles de calcul, de pièces jointes email, d'enregistrements en double et de suppression incohérente.

Cette question de continuité est souvent sous-pondérée dans l'analyse des brèches. Ce n'est pas aussi dramatique que le vol de cartes de paiement ou les rançongiciels. Mais le recrutement est un processus métier critique. Les hôpitaux, universités, agences publiques, services publics, détaillants et entreprises technologiques ont besoin de pourvoir des postes. La perturbation du recrutement peut retarder le personnel, l'intégration, les vérifications de conformité et la mobilité interne.

Les personnes affectées peuvent être des chercheurs d'emploi attendant des décisions, des responsables de recrutement avec des postes ouverts et des équipes RH gérant des données sensibles sous pression.

Un fournisseur SaaS mature devrait donc avoir un manuel de continuité des incidents destiné aux clients. Il devrait dire aux clients quand suspendre les candidatures, comment préserver les enregistrements de candidats en attente, comment exporter ou réconcilier les données, comment éviter la collecte en double, comment communiquer avec les candidats et comment redémarrer les flux de travail après le confinement. Il devrait également dire aux clients quelles fonctions restent sûres, lesquelles sont désactivées et lesquelles nécessitent une prudence supplémentaire.

Une enquête de brèche qui se concentre uniquement sur la confidentialité manque l'impact opérationnel d'une plateforme que les clients peuvent hésiter à utiliser.

Cela a de l'importance pour l'automatisation des logiciels d'entreprise. L'automatisation concentre les flux de travail chez un seul fournisseur. Cette concentration peut améliorer la cohérence et la conformité lorsque le fournisseur est en bonne santé. Pendant un incident, elle peut créer une perturbation de mode commun. De nombreux employeurs peuvent avoir besoin de la même clarification en même temps. De nombreux candidats peuvent recevoir des avis similaires. Les files d'attente de support peuvent s'allonger. Les reportages publics peuvent devancer la communication directe.

La cellule de crise du fournisseur devient une ressource partagée de continuité des activités pour ses clients.

L'incident PageUp n'a pas été une panne prolongée connue dans la même classe qu'une défaillance destructrice d'infrastructure. La question de continuité est toujours pertinente car plusieurs clients ont publiquement discuté de changements ou de prudence dans leur système de recrutement. La bonne leçon n'est pas d'éviter le SaaS de recrutement. C'est d'exiger des preuves de repli avant un incident. Les clients devraient savoir comment recevoir les candidatures si la plateforme est suspendue, comment sécuriser les enregistrements temporaires, comment les fusionner et comment supprimer les doublons.

Les fournisseurs devraient rendre cela possible sans forcer les clients à improviser de manière risquée.

La continuité affecte également les candidats. Si une candidature est retardée ou soumise à nouveau, le candidat ne devrait pas avoir à deviner si l'enregistrement original est toujours actif, si des enregistrements en double ont été créés ou si les communications sont légitimes. Une brèche crée des opportunités de phishing car les candidats s'attendent à des messages concernant le recrutement. Une réponse solide devrait dire aux candidats à quoi ressembleront les communications officielles, quels domaines ou canaux seront utilisés et comment vérifier les demandes suspectes sans exposer plus d'informations.

Ce qu'une réparation vérifiable exigerait

Le test de réparation durable pour une plateforme de recrutement commence par la portée médico-légale. Le fournisseur devrait être capable de montrer aux clients et aux régulateurs les systèmes affectés, la fenêtre temporelle, les catégories de données, les limites de locataire, les méthodes d'enquête et le niveau de confiance. Les preuves n'ont pas besoin d'être publiques dans tous leurs détails, mais elles doivent être suffisamment spécifiques pour que les clients puissent prendre des décisions juridiques et éthiques. « Nous avons enquêté » ne suffit pas.

« Nous avons examiné ces systèmes, ces journaux, ces chemins de données et avons trouvé ces faits » est plus proche de la norme.

Deuxièmement, le fournisseur devrait prouver le confinement. Cela inclut la rotation des identifiants, la révision des accès administratifs, la suppression des codes malveillants, la réparation des vulnérabilités, le durcissement des points de terminaison et des serveurs, les changements de surveillance et la validation que les attaquants n'ont plus d'accès. Les sources publiques n'exposent pas le dossier de correction complet de PageUp. La norme de responsabilité est que les clients devraient pouvoir recevoir des preuves appropriées à leur risque.

Une université ou un employeur du secteur public traitant des dossiers sensibles de candidats ne devrait pas avoir à se fier uniquement à une déclaration générale.

Troisièmement, la plateforme devrait examiner la minimisation des données. Les systèmes de recrutement collectent souvent plus que nécessaire parce que chaque champ semble utile à quelqu'un. La réparation devrait demander si les CV, pièces jointes, réponses de filtrage, références et documents d'identité sont conservés seulement aussi longtemps que nécessaire. Elle devrait également demander si les paramètres par défaut des clients encouragent la surcollecte. Une brèche est un moment pour réduire les préjudices futurs, pas seulement pour fermer la voie d'entrée.

Quatrièmement, l'isolation des locataires devrait être testée en tant que propriété de contrôle des brèches. Cela signifie que le fournisseur devrait être capable de démontrer que les données d'un client ne peuvent pas être atteintes par le chemin administratif d'un autre client, par le chemin de support, par l'intégration, par un rapport ou par un rôle mal configuré. Cela signifie également que les journaux devraient être suffisamment conscients du locataire pour soutenir la délimitation. Si les journaux ne peuvent pas distinguer l'accès par locataire, l'avis public sera large par nécessité.

Cinquièmement, la notification aux clients devrait être répétée. Un fournisseur SaaS multipartite devrait savoir quels contacts clients reçoivent les avis d'incident, à quelle vitesse ils peuvent être joints, quels modèles sont disponibles, comment les mises à jour sont versionnées et comment les avis de sécurité urgents sont séparés des emails de compte normaux. Les contacts clients changent. Les boîtes aux lettres des achats se dégradent. L'avis d'incident devrait être testé comme la restauration de sauvegarde, car un avis qui atteint la mauvaise adresse n'est pas un contrôle efficace.

Sixièmement, l'aide destinée aux candidats devrait être conçue avant la panique. Les candidats ont besoin d'une explication simple, d'un canal de contact, de conseils sur le phishing, de conseils sur les mots de passe si applicable, et d'un moyen de comprendre s'ils ont soumis des données pendant une période pertinente. Ils ne devraient pas être ballottés entre le fournisseur et l'employeur sans prise en charge. Un fournisseur peut ne pas être en mesure de répondre directement à chaque candidat, mais il peut équiper les clients pour le faire.

Enfin, la réparation devrait survivre au temps. Les pages actuelles de sécurité et de confidentialité de PageUp peuvent refléter un programme plus mature que ce que le public pouvait voir en 2018, mais la question de responsabilité persiste pour chaque plateforme de recrutement. Les contrôles sont-ils testés? Les clients reçoivent-ils des preuves d'audit? Les rôles de support sont-ils limités? Les anciennes candidatures sont-elles supprimées? Les avis d'incident sont-ils acheminés vers les contacts actuels? Les chemins de traitement transfrontaliers sont-ils clairs?

Les candidats sont-ils traités comme des personnes affectées plutôt que comme de simples lignes dans un locataire client?

Ce que les clients devraient demander après PageUp

La leçon pour les clients est pratique. Les employeurs utilisant un SaaS de recrutement devraient demander au fournisseur une carte des données: champs des candidats, pièces jointes, enregistrements dérivés, sauvegardes, journaux, exportations, accès de support, sous-traitants, régions, périodes de conservation et preuve de suppression. Ils ne devraient pas attendre un incident pour apprendre si les CV sont stockés dans un système et les pièces jointes dans un autre, ou si le personnel de support peut voir les détails des candidats lors du dépannage.

Ils devraient demander des engagements de preuves en cas d'incident. Un contrat peut exiger un avis rapide, mais un avis rapide sans faits utiles peut encore laisser le client exposé. Le fournisseur devrait s'engager à donner les systèmes affectés, les classes de données, les fenêtres temporelles, les étapes de confinement et les niveaux de confiance à mesure qu'ils sont connus. Le client devrait identifier qui reçoit les avis et comment les avis sont escaladés en dehors des canaux habituels de gestion des fournisseurs.

Ils devraient demander une assurance d'isolation des locataires. Les certifications, les tests de pénétration et les rapports d'audit peuvent aider, mais la question devrait être liée au modèle de données de recrutement. Un attaquant qui atteint le flux de travail d'un client peut-il voir celui d'un autre? Le support du fournisseur peut-il usurper l'identité des utilisateurs? Les sessions de support sont-elles enregistrées et examinées? Les exportations en masse sont-elles contrôlées? Les jetons API sont-ils limités et rotés? Les intégrations de vérification des antécédents sont-elles segmentées?

Ils devraient demander des paramètres par défaut de conservation. La minimisation des données n'est pas seulement un slogan de confidentialité. C'est un contrôle du rayon d'explosion de la brèche. Si les anciens candidats restent dans des systèmes actifs et consultables pendant des années sans raison claire, le client a accepté un risque futur pour des personnes qui peuvent n'avoir aucune relation continue avec l'organisation. Les règles de conservation devraient être visibles pour les équipes RH, juridiques, de confidentialité et de sécurité, pas enterrées dans l'administration technique.

Ils devraient demander un repli de continuité. Si la plateforme de recrutement est suspendue, que se passe-t-il pour les postes ouverts, les candidatures en attente, les entretiens planifiés, les dossiers d'intégration et les communications avec les candidats? Comment les enregistrements temporaires seront-ils sécurisés? Comment les doublons seront-ils réconciliés? Comment les candidats vérifieront-ils les messages authentiques? Un incident chez un fournisseur ne devrait pas pousser les équipes RH vers des feuilles de calcul ad hoc qui créent un deuxième événement de confidentialité.

La dernière question est culturelle mais fondée sur les preuves: le fournisseur sépare-t-il la réassurance de la preuve? Le dossier public de l'incident de PageUp montre pourquoi cette distinction est importante. Une déclaration indiquant qu'il n'y a aucune preuve d'exfiltration peut être vraie et utile, mais seulement si la base de preuves est suffisamment solide pour que les clients et les personnes affectées comprennent le risque résiduel.

Une plateforme de recrutement gagne la confiance en prouvant la garde, la portée, le confinement et la réparation pour les personnes dont elle détient les données, y compris celles qui n'ont jamais signé le contrat du fournisseur.

La norme de responsabilité après la brèche

La norme durable est simple à énoncer et difficile à atteindre: la partie qui a le contrôle pratique de la plateforme doit produire des preuves pratiques pour les personnes qui supportent le risque. PageUp contrôlait l'environnement de recrutement, la délimitation médico-légale et les intrants de notification aux clients. Les employeurs contrôlaient les relations de recrutement et la communication avec les candidats. Les candidats supportaient le risque de confidentialité sans contrôler ni la sélection du fournisseur ni les preuves de la plateforme.

Cela ne signifie pas que chaque mauvais résultat appartient uniquement au fournisseur SaaS. Les clients choisissent les fournisseurs, configurent les flux de travail, décident des champs de données, fixent les attentes de conservation et communiquent avec les candidats. Les régulateurs définissent les seuils de notification et les attentes en matière d'application. Les candidats peuvent prendre certaines précautions en aval. Mais le fournisseur est la seule partie qui peut prouver ce qui s'est passé à l'intérieur de la plateforme.

Cette preuve devrait être structurée autour de six questions. Quels systèmes ont été consultés? Quelles données pouvaient être atteintes? Quelles données ont été réellement consultées ou exportées, si connues? Quels clients et candidats se trouvent dans la fenêtre? Quels contrôles ont échoué ou ont nécessité une amélioration? Qu'est-ce qui a changé de manière mesurable? Si le fournisseur ne peut pas répondre aux six immédiatement, il devrait dire ce qui est inconnu et quand la prochaine mise à jour est attendue.

Le cas PageUp reste pertinent car les données de recrutement sont désormais une partie normalisée de la dépendance cloud des entreprises. Les employeurs acheminent de plus en plus le recrutement, l'évaluation, l'intégration et l'analyse via des plateformes spécialisées. Cela peut être efficace, mais cela rend la vie privée des candidats dépendante des preuves du fournisseur. Le dossier de responsabilité devrait donc rester concentré sur les preuves: limites de locataire, exhaustivité des journaux, minimisation des données, clarté transfrontalière, flux de travail de repli et notification honnête.

L'incident ne devrait pas être retenu seulement comme un titre sur une brèche chez un éditeur de logiciels. Il devrait être retenu comme un test de savoir si le marché de la technologie de recrutement peut respecter les personnes dont les données remplissent le système. Ces personnes ne sont pas que des enregistrements. Ce sont des chercheurs d'emploi dont les CV, les histoires, les références et les espoirs ont été traités par une plateforme qu'ils n'ont généralement pas choisie. La responsabilité commence lorsque la plateforme peut montrer, avec des preuves, qu'elle a traité cette asymétrie comme une responsabilité de conception.

Cette norme aide également les clients à acheter de meilleurs systèmes avant le prochain incident. Une équipe d'achat ne devrait pas demander seulement si le fournisseur a des certifications de sécurité. Elle devrait demander quelles preuves seront disponibles lors d'une brèche, quels journaux soutiennent la délimitation au niveau du candidat, comment l'isolation des locataires est testée, comment les anciennes candidatures sont supprimées, comment les avis urgents atteignent les contacts actuels et comment les candidats reçoivent de l'aide lorsqu'ils ne sont plus des candidats actifs.

Le dossier de PageUp montre pourquoi ces questions appartiennent au contrat, à l'examen de sécurité, à l'évaluation d'impact sur la confidentialité et au manuel opérationnel. Les plateformes de recrutement détiennent des histoires personnelles fragiles. Le fournisseur responsable traite cette histoire comme une frontière de confiance, pas seulement comme des données de flux de travail.

La même norme devrait façonner la configuration du client. Les employeurs peuvent affaiblir une plateforme sécurisée en collectant des pièces jointes inutiles, en créant des rôles de recruteur larges, en laissant des campagnes de recrutement obsolètes ouvertes, en autorisant des exportations non gérées ou en acheminant les données des candidats vers des systèmes annexes non couverts par l'ensemble de preuves du fournisseur. La responsabilité du fournisseur reste centrale, mais les paramètres du client déterminent une partie du rayon d'explosion.

Un examen post-incident utile demande donc si le client a utilisé la plateforme d'une manière minimisant les données, si les exportations étaient enregistrées, si les responsables du recrutement n'avaient que l'accès nécessaire et si les solutions de contournement manuelles ont créé de nouveaux enregistrements qui nécessitaient également protection et suppression.