1) Définitions & périmètre
Incident de service : dégradation ou interruption d’un composant (WEB/API, SQL, intégrations SMTP/Graph, contrôle d’accès, iPad/écrans).
Incident de sécurité : atteinte potentielle/avérée à la confidentialité, intégrité ou disponibilité des données/systèmes.
Vulnérabilité : faiblesse technique ou de configuration (OS/IIS/SQL, dépendances, applicatif, périphériques).
2) Chaîne de gestion d’incident (SaaS)
Détection : supervision (sondes, métriques), anti‑DDoS, ou ticket Support.
Qualification : périmètre, impact, début, derniers changements ; priorisation selon gravité/étendue.
Containment : mesures de confinement, bascule PRA si nécessaire, règles temporaires (pare‑feu, throttling).
Remédiation & reprise : correctifs, redémarrages contrôlés, vérifications post‑reprise (auth, envois mails/SMS, Graph, contrôle d’accès).
Communication : messages de statut au Client (détection, progression, clôture).
RCA (post‑mortem) : causes racines, mesures préventives, mise à jour docs/runbooks.
Les modalités de support, escalade et fenêtres de maintenance sont détaillées dans Maintenance & Support (SaaS).
3) Notification sécurité & données personnelles
En cas d’incident affectant des données personnelles, Hamilton Apps informe le Client dans les meilleurs délais avec description, périmètre, mesures prises et points de contact.
Le Client, en tant que Responsable de traitement, évalue la notification à l’autorité compétente (≤ 72 h selon RGPD art. 33) et la communication aux personnes concernées.
4) Gestion des vulnérabilités (veille → patch)
Veille : éditeurs, CERT‑FR, CVE, bulletins sécurité OS/IIS/SQL, librairies.
Qualification : exposition (internet/interne), exploitabilité, impact fonctionnel.
Traitement :
SaaS : correctifs de sécurité testés, puis déployés en fenêtre de maintenance avec plan de rollback.
On‑prem : le Client applique les patchs OS/SQL/IIS/AV et recommandations de durcissement ; l’application Hamilton suit les procédures de mise à jour publiées.
Mesures compensatoires : configuration/durcissement en attendant un correctif (filtrage réseau, désactivation modules obsolètes, restriction d’accès).
Communication : bulletins d’information au besoin (impact, versions affectées, actions recommandées).
5) Politique de mises à jour & correctifs (rappels)
Prioriser les correctifs de sécurité et dépendances critiques.
Tester en environnement de recette avant production.
Planifier : fenêtre, sauvegarde/point de restauration, validation post‑MAJ.
Tracer : changements, versions, résultats de tests et vérifications.
6) Rôles & responsabilités
SaaS : Hamilton Apps opère la plateforme (supervision, sécurité, patching, PRA) et communique au Client.
Client On‑prem : patching système/SQL/IIS, sauvegardes, supervision locale, sécurité périmétrique, et application des bonnes pratiques de l’éditeur.
7) Spécificités On‑prem (client)
Intégrer l’application dans les outils SIEM/NMS ; définir des seuils d’alerte.
Mettre en place un plan de réponse à incident (contacts, escalade, checklists) et un PRA testé.
Durcir l’hôte : TLS/LDAPS, comptes de service à moindre privilège, segmentation réseau.
Checklist prête à l’emploi
Contacts d’escalade et canal Support à jour.
Sondes supervision HTTP/SQL/SMTP/Graph et journaux collectés.
Procédure incident sécurité (communication, preuves, forensics légers) publiée.
Calendrier patching et plan de rollback définis.
Exercice RCA réalisé après tout incident majeur.
Liens croisés
Conformité & sécurité → gouvernance SSI, sauvegardes, chiffrement.
Disponibilité & continuité → PRA/PCA, modes dégradés.
Sauvegardes & restauration → points de reprise & demandes.
RGPD / DPA → rôles, notification, sous‑traitants.
Politique de mises à jour & correctifs → méthodes & fenêtres (voir article dédié).