Heading

Vous cherchez le plan de réponse aux incidents du campus ? Allez plutôt sur les documents de sécurité de l’information. La directive de planification de la réponse aux incidents ci-dessous concerne les systèmes et les applications qui doivent adhérer à la politique MSSEI du campus.

La politique de sécurité de l’UC Berkeley impose la conformité à la norme minimale de sécurité pour l’information électronique pour les appareils manipulant des données couvertes. Les recommandations ci-dessous sont fournies à titre d’orientation facultative pour les exigences en matière de réponse aux incidents.

Exigence

Chaque dépositaire de système doit développer et réviser au moins une fois par an un plan de réponse aux incidents au niveau du système qui contient :

• Noms et coordonnées de l’équipe locale de réponse aux incidents, y compris :
  • Contact de sécurité et contact(s) alternatif(s) qui ont des accréditations d’administrateur système, une connaissance technique du système et une connaissance de l’emplacement du plan de réponse aux incidents.
  • Une autorité locale/décideur pour le système qui comprend l’impact commercial du système et son indisponibilité.
• Détails du système, ou référence à l’emplacement de ces informations, notamment :
  • Data Flow Diagrams
  • Network Diagrams
  • System hardware inventory (as required by the Annual Registration control)
  • Logging information (as required by the Audit Logging control)
• Procedures for reporting and handling a suspected incident, defined per role : Admin Sys, Utilisateur d’accès en masse, Utilisateur final, par exemple,
  • Qui contacter
  • Comment NE PAS altérer les preuves potentielles (c’est-à-dire, ne pas tenter d’analyse médico-légale lorsqu’on n’y est pas autorisé)

Description du risque

Si les utilisateurs et les administrateurs système ne connaissent pas les procédures de réponse aux incidents, la réponse sera retardée et les preuves peuvent être corrompues ou perdues, ce qui augmente considérablement l’impact potentiel d’un incident.

Recommandations

Pour s’assurer que les événements et les faiblesses en matière de sécurité de l’information associés aux systèmes centraux couverts sont communiqués d’une manière permettant de prendre des mesures correctives en temps opportun, les procédures de signalement et d’escalade des événements doivent être documentées dans un plan officiel de réponse aux incidents. Les procédures de réponse aux incidents s’inscrivent généralement dans les phases suivantes :

• Détection – Évaluation initiale et triage des incidents de sécurité sur les systèmes centraux couverts, y compris l’escalade vers le bureau de la sécurité de l’information (BSI) et l’attribution d’un niveau de priorité à l’incident.

• Analyse – Effectuer une analyse d’impact détaillée afin de prioriser correctement les activités de réponse supplémentaires requises pour les brèches à fort impact. Commencer les activités de préservation et de confinement des preuves, ainsi que la récupération initiale.

• Récupération – En fonction de la gravité de l’incident, atténuez l’impact de l’incident en terminant les activités de confinement et d’éradication, et finalement en vous en remettant. Au cours de cette phase, l’activité revient souvent à la détection et à l’analyse – par exemple, pour voir si d’autres hôtes sont infectés par des logiciels malveillants tout en éradiquant un incident de logiciels malveillants.

• Post-Incident – Une fois l’incident traité de manière adéquate, publiez un rapport qui détaille la cause profonde et le coût total de l’incident, ainsi que les mesures que l’organisation doit prendre pour prévenir de futurs incidents.

Tous les membres du personnel du campus, les contractants et les utilisateurs tiers doivent être informés des procédures de signalement des différents types d’événements susceptibles d’avoir un impact sur la sécurité des dispositifs couverts. Ils devraient être tenus de signaler tout incident de sécurité de l’information aussi rapidement que possible au point de contact désigné.

Qu’est-ce qu’un incident de sécurité ?

Un incident de sécurité dans le contexte de cette exigence MSSEI est un événement qui compromet ou a le potentiel de compromettre :

• le fonctionnement des systèmes centraux couverts ou
• la confidentialité ou l’intégrité des actifs de données couverts

Un incident de sécurité peut impliquer l’un ou l’ensemble des éléments suivants :

• une violation des politiques et normes de sécurité informatique du campus
• un accès non autorisé à l’ordinateur ou aux données
• la présence d’une application malveillante, telle qu’un virus
• la présence de programmes inattendus/insolites
• une condition de déni de service contre les données, le réseau ou l’ordinateur
• un mauvais usage du service, systèmes ou informations
• dommages physiques ou logiques aux systèmes
• vol d’ordinateur

Composants d’un plan de réponse aux incidents pour les systèmes et services individuels

Les propriétaires et les gardiens de ressources doivent s’assurer que leur plan de réponse aux incidents contient les composants suivants. Nous fournissons ce TEMPLE pour les plans de réponse aux incidents pour les systèmes et services individuels.

• Noms, coordonnées et responsabilités de l’équipe locale de réponse aux incidents, notamment :
  • Gestionnaire d’incidents : Le contact de sécurité et le(s) contact(s) alternatif(s) qui ont des accréditations d’administrateur système, une connaissance technique du système et une connaissance de l’emplacement du plan de réponse aux incidents.
  • Resource Manager : Une autorité locale/décideur pour le système qui comprend l’impact commercial du système et son indisponibilité. Le propriétaire de la ressource doit assumer les responsabilités du gestionnaire de la ressource ou désigner un membre du personnel du campus pour ce rôle.

• Détails du système, ou référence à l’emplacement de ces informations, notamment :

  • Schémas de flux de données
  • Schémas de réseau
  • Inventaire du matériel du système (comme l’exige le contrôle de l’enregistrement annuel)
  • Informations de journalisation (comme l’exige le contrôle de la journalisation des audits)
• Procédures de signalement et de traitement d’un incident suspect, notamment :
  • Compléter un rapport de réception d’incident, qui doit inclure les informations suivantes :
    • Nom et numéro de téléphone de la personne à contacter
    • Adresse IP, nom d’hôte et emplacement physique du système violé
    • Nom du système couvert (tel qu’il apparaît dans NetReg)
    • Quels types de données couvertes étaient disponibles sur/depuis l’hôte violé ?
      • Nom complet
      • Numéro de sécurité sociale
      • Numéro de permis de conduire ou numéro de carte d’identité californienne
      • Numéro de carte de crédit ou de compte financier (y compris le code PIN ou la date d’expiration)

      .

      • Numéro de compte bancaire (y compris le NIP ou d’autres informations d’accès)
      • Informations médicales ou d’assurance maladie
      • Autres
    • Pour chaque fichier contenant des informations personnelles, précisez :
      • Nom du fichier
      • Taille du fichier
      • Localisation du fichier (chemin d’accès complet au fichier)
    • Les données ont-elles été cryptées, et si oui, comment ?
    • Décrire l’impact de l’incident (par exemple, le nombre d’enregistrements de données sont compromis ou le nombre d’utilisateurs qui sont affectés par le système indisponible)
    • Décrire l’incident de sécurité, y compris la chronologie des activités, comment l’incident a été détecté, l’impact (commercial et technique) de l’incident, les détails des contrôles d’atténuation en place, tels que le mécanisme de cryptage des données utilisé.
    • Documenter les mesures prises sur le système violé (quel est l’état du système maintenant, etc)

• Reporter l’incident de sécurité à l’ISO (courriel [email protected]*) et inclure le rapport d’admission. Nous affecterons un analyste de la sécurité pour coordonner toute activité de suivi de l’incident.

  • Après le signalement d’un incident de sécurité à l’ISO, ne vous déconnectez pas et ne vous connectez pas au système violé avant d’avoir reçu des instructions de l’analyste de sécurité de l’ISO.
  • L’interruption de service qui ne résulte pas d’activités malveillantes doit être signalée au personnel d’assistance informatique approprié. Des informations supplémentaires sur le signalement de différents types d’incidents peuvent être trouvées sur le site Web de la sécurité. Par exemple, pour la plupart des applications d’entreprise à l’échelle du campus, l’interruption de service doit être signalée aux services informatiques partagés du campus.

• Répondre à l’incident de sécurité en temps opportun en fonction de la directive de priorisation des incidents.

Notez que l’adresse électronique [email protected] doit être utilisée uniquement pour signaler les incidents de sécurité couverts par la MSSEI. Les incidents de sécurité non couverts par la MSSEI doivent être signalés à [email protected].

Priorisation des incidents de sécurité

Pour aider à prioriser le moment et les ressources nécessaires au déploiement des mesures correctives, les propriétaires et les gardiens de ressources doivent évaluer l’impact d’un incident de sécurité en fonction des facteurs suivants :

• Comment l’incident aura un impact sur la fonctionnalité existante des systèmes affectés
• Si l’incident viole la confidentialité ou l’intégrité des données couvertes UC P4 (anciennement UCB PL2) ou des données non couvertes
• Combien de la population d’utilisateurs est affectée par l’incident de sécurité
• Quel est l’impact réputationnel/financier pour le campus

En utilisant les facteurs énumérés ci-dessus comme point de départ, les incidents de sécurité doivent être évalués et se voir attribuer un niveau de priorité élevé ou faible par le gestionnaire des ressources et le gestionnaire des incidents désignés. Les facteurs à prendre en compte incluent non seulement l’impact actuel de l’incident, mais aussi son impact futur probable s’il n’est pas immédiatement corrigé. Tout incident de haute priorité doit être immédiatement signalé à l’ISO en suivant les procédures de traitement des incidents. Une fois qu’un incident de sécurité est signalé à l’analyste ISO, la cote de priorité sera confirmée ou révisée à la suite d’une analyse supplémentaire de l’événement.

Les exemples d’incident de sécurité de haute priorité comprennent un événement conduisant à la perte d’une fonction critique pour une population d’utilisateurs à l’échelle du campus ou du département. De même, une violation de la confidentialité des données couvertes affectant plus de 500 utilisateurs doit également se voir attribuer un niveau de priorité élevé. Le niveau de priorité de l’incident peut être révisé dans les phases ultérieures du processus de réponse à l’incident, après que l’analyse de preuves supplémentaires ait fourni une compréhension plus précise de l’impact de l’incident. Toute mise à jour du niveau de priorité doit être examinée par les membres de l’équipe locale de réponse aux incidents, et un analyste ISO.

Le tableau suivant fournit des indications supplémentaires sur l’engagement en temps des membres de l’équipe de réponse aux incidents en cas d’incident de sécurité (analyste ISO, gestionnaire d’incidents, gestionnaire de ressources) :

.

Phases de réponse aux incidents	Incident de haute priorité	Incident de faible priorité
Détection	Immédiate	8 heures
Analyse	Le gestionnaire de ressources et le gestionnaire d’incidents sont chargés de travailler avec l’analyste ISO* sur une base dédiée, de façon continue.	Un gestionnaire d’incidents affecté et dédié à travailler avec l’analyste ISO sur le cas pendant les heures de bureau normales.	Récupération	Le gestionnaire de ressources et le gestionnaire d’incidents sont assignés à travailler avec l’analyste ISO* sur une base dédiée et continue.	Le gestionnaire d’incidents est assigné à travailler avec l’analyste ISO sur le cas selon le temps/les ressources disponibles.	Post-Incident	Le gestionnaire de l’incident est assigné à travailler avec l’analyste ISO sur le cas selon le temps/les ressources disponibles.	Le gestionnaire de l’incident est assigné à travailler avec l’analyste ISO sur le cas selon le temps/les ressources disponibles.

* Les cas de haute priorité peuvent impliquer d’autres parties prenantes sur le campus, notamment la politique informatique, le conseil du campus et d’autres représentants de la direction du campus.

Définitions de la phase d’intervention en cas d’incident :

• Détection – Ceci spécifie la durée maximale qui doit s’écouler entre le moment où l’événement suspect est détecté et le moment où les actions suivantes sont censées être réalisées :

  • Évaluation et triage initiaux
  • Déterminer le niveau de priorité initial en fonction du rapport d’admission
  • Rapport de l’incident à l’ISO
  • Un analyste de l’ISO est affecté pour travailler avec le gestionnaire d’incidents et le gestionnaire de ressources
  • Entrer l’incident dans le système de billetterie de l’ISO
• Analyse -. La période de temps dans le cycle de vie du cas où une réponse active à l’incident est nécessaire afin d’assurer la bonne résolution du cas. Typiquement, cela inclut les pannes de système ou de service, et/ou la préservation urgente des preuves. L’incident est également vérifié pour être légitime, la priorisation est confirmée et l’escalade appropriée faite en fonction de l’impact de l’incident. Les activités typiques comprennent :

  • L’évaluation, le triage, le confinement, la préservation des preuves, la récupération initiale

• Récupération – La période de temps dans le cycle de vie du cas où la réponse active à l’incident n’est pas nécessaire pour résoudre avec succès le cas. Les activités typiques comprennent :

  • La collecte de preuves, l’analyse et l’investigation, la médecine légale, la remédiation, la récupération complète, le post-mortem.

• Post-Incident – Après que l’incident a été traité de manière adéquate, l’équipe de réponse à l’incident émet un rapport qui détaille la cause et le coût de l’incident et les mesures que l’organisation doit prendre pour prévenir de futurs incidents.

Les définitions sont tirées de http://www.first.org/_assets/resources/guides/csirt_case_classification….

Ressources supplémentaires

• Guide de traitement des incidents de sécurité informatique du NIST, http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

• Manuel de l’Institut de génie logiciel pour les équipes de réponse aux incidents de sécurité informatique (CSIRT),http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm

• Modèle de plan de réponse aux incidents pour les systèmes et services individuels

• Plan de réponse aux incidents sur le campus

.