Source: Blog officiel de la société Salesforce. Contexte: article didactique d’Eoghan Casey présentant une méthodologie pour enquêter sur des incidents de sécurité dans des environnements Salesforce.

L’article détaille trois piliers pour l’investigation: logs d’activité, permissions utilisateurs et données de sauvegarde. Les logs répondent au qui/quoi/où/quand/comment, les permissions déterminent l’étendue d’accès et d’export, et les sauvegardes permettent d’évaluer l’impact sur les données et de restaurer l’intégrité. Des exemples incluent la Login History, le Setup Audit Trail, et pour une visibilité avancée, Shield Event Monitoring (API, exports de rapports, téléchargements de fichiers), ainsi que des journaux additionnels pour B2C Commerce Cloud.

Sur l’évaluation initiale de l’impact, l’article insiste sur la complexité de Profiles, Permission Sets/Groups, Sharing Rules et Role Hierarchies. L’outil Who Sees What (WsW) Explorer dans Security Center offre une vue unifiée des accès par objet et champs (avec marquage des champs sensibles), facilitant l’application du principe du moindre privilège et la décision d’une analyse approfondie si des droits étendus sont détectés.

L’analyse des logs s’appuie sur les trois sources d’Event Monitoring: Real Time Event Monitoring (RTEM) avec Threat Detection (anomalies basées sur statistiques/ML, stockables jusqu’à 6 mois et consultables/streamables), Event Log Objects (ELO) (latence faible, interrogeables via APIs), et Event Log Files (ELF) (CSV pour observabilité, non temps réel). L’article montre l’usage de Security Center et Analytics Studio pour créer des dashboards menant à des pivots vers les données ELO, notamment pour répondre à la question « que fait un utilisateur sur une période donnée » et investiguer des hausse anormale d’appels API, exports de rapports ou téléchargements de fichiers. Il souligne que certaines activités utilisateur normales génèrent aussi des API calls.

Pour la reconstitution détaillée, l’article précise que RTEM ApiEventStream peut inclure les enregistrements et champs effectivement consultés lors d’exfiltration via API (niveau de détail non présent dans ELF/ELO). Il met en avant Field History Tracking, la comparaison de sauvegardes avant/après (via Backup & Recover), et le Setup Audit Trail et Security Center pour repérer des changements de configuration pouvant maintenir un accès non autorisé. Côté réponse automatisée, Enhanced Transaction Security et les Transaction Security Policies (TSP) permettent de bloquer le téléchargement de rapports contenant des champs sensibles, alerter, imposer MFA, créer des cases et envoyer des notifications Slack. Un cas illustratif concerne une Guest User Anomaly via Digital Experience Sites, traçable par des événements AuraRequest, et dont l’exposition dépend des permissions de l’utilisateur invité et des org wide defaults.

En conclusion, l’article met l’accent sur les bénéfices de la préparation forensique pour détecter, enquêter et neutraliser plus rapidement les incidents affectant des données critiques Salesforce. Il mentionne aussi la possibilité d’utiliser Agentforce for Security pour requêter les événements et obtenir des recommandations. Il s’agit d’un guide technique visant à fournir une démarche et des outils concrets d’investigation et de réponse dans Salesforce.

🔗 Source originale : https://www.salesforce.com/blog/a-primer-on-forensic-investigation-of-salesforce-security-incidents/