Heading

¿Busca el Plan de Respuesta a Incidentes del Campus? Vaya a Documentos de Seguridad de la Información en su lugar. La siguiente Guía de Planificación de Respuesta a Incidentes se refiere a los sistemas y aplicaciones que necesitan adherirse a la política MSSEI del Campus.

La política de seguridad de la Universidad de Berkeley exige el cumplimiento de la Norma de Seguridad Mínima para la Información Electrónica para los dispositivos que manejan datos cubiertos. Las recomendaciones siguientes se proporcionan como orientación opcional para los requisitos de respuesta a incidentes.

Requisito

Cada custodio del sistema debe desarrollar y revisar al menos anualmente un plan de respuesta a incidentes a nivel de sistema que contenga:

• Nombres e información de contacto para el equipo local de respuesta a incidentes, incluyendo:
  • Contacto de seguridad y contacto(s) alternativo(s) que tenga(n) credenciales de administrador del sistema, conocimiento técnico del sistema y conocimiento de la ubicación del plan de respuesta a incidentes.
  • Una autoridad local/tomador de decisiones para el sistema que comprenda el impacto empresarial del sistema y su indisponibilidad.
  • Detalles del sistema, o referencia a la ubicación de dicha información, incluyendo:
    • Diagramas de flujo de datos
    • Diagramas de red
    • Inventario de hardware del sistema (según lo requerido por el control de Registro Anual)
    • Información de registro (según lo requerido por el control de Registro de Auditoría)
  • Procedimientos para notificar y manejar un incidente sospechoso, definidos por rol: Sys Admin, Bulk Access User, End User, por ejemplo,
    • Con quién ponerse en contacto
    • Cómo NO manipular las posibles pruebas (es decir, no intentar realizar análisis forenses cuando no se está autorizado)

  Descripción del riesgo

  Si los usuarios y los administradores de sistemas no conocen los procedimientos de respuesta a incidentes, la respuesta se retrasará y las pruebas pueden corromperse o perderse, lo que aumenta en gran medida el impacto potencial de un incidente.

  Recomendaciones

  Para garantizar que los eventos de seguridad de la información y los puntos débiles asociados a los sistemas centrales cubiertos se comunican de manera que se puedan tomar medidas correctivas a tiempo, los procedimientos de notificación y escalado de eventos deben documentarse en un Plan de Respuesta a Incidentes formal. Los procedimientos de respuesta a incidentes suelen dividirse en las siguientes fases:

  • Detección – Evaluación inicial y clasificación de los incidentes de seguridad en los sistemas centrales cubiertos, incluyendo la escalada a la Oficina de Seguridad de la Información (ISO) y la asignación del nivel de prioridad del incidente.

  • Análisis – Realizar un análisis detallado del impacto para priorizar adecuadamente las actividades de respuesta adicionales necesarias para las violaciones de alto impacto. Comenzar las actividades de preservación y contención de pruebas, así como la recuperación inicial.

  • Recuperación – De acuerdo con la gravedad del incidente, mitigar el impacto del mismo terminando las actividades de contención y erradicación, y finalmente recuperándose del mismo. Durante esta fase, la actividad suele volver a la detección y el análisis; por ejemplo, para ver si hay más hosts infectados por el malware mientras se erradica un incidente de malware.

  • Post-incidente – Una vez que el incidente se haya gestionado adecuadamente, emita un informe que detalle la causa raíz y el coste total del incidente, junto con los pasos que la organización debería dar para prevenir futuros incidentes.

  Todo el personal del campus, los contratistas y los usuarios de terceros deben conocer los procedimientos para informar de los diferentes tipos de eventos que puedan tener un impacto en la seguridad de los dispositivos cubiertos. Se les debe exigir que informen de cualquier incidente de seguridad de la información lo antes posible al punto de contacto designado.

  ¿Qué es un incidente de seguridad?

  Un incidente de seguridad en el contexto de este requisito MSSEI es un evento que compromete o tiene el potencial de comprometer:

  • el funcionamiento de los sistemas centrales cubiertos o
  • la confidencialidad o la integridad de los activos de datos cubiertos

  Un incidente de seguridad puede implicar uno o todos los siguientes:

  • una violación de las políticas y normas de seguridad informática del campus
  • un acceso no autorizado al ordenador o a los datos
  • presencia de una aplicación maliciosa, como un virus
  • presencia de programas inesperados/inusuales
  • una condición de denegación de servicio contra los datos, la red o el ordenador
  • un mal uso del servicio sistemas o información
  • daño físico o lógico a los sistemas
  • robo de ordenadores

  Componentes de un Plan de Respuesta a Incidentes para Sistemas y Servicios Individuales

  Los propietarios y custodios de los recursos deben asegurarse de que su Plan de Respuesta a Incidentes contiene los siguientes componentes. Proporcionamos este PLANTILLA para planes de respuesta a incidentes para sistemas y servicios individuales.

  • Nombres, información de contacto y responsabilidades del equipo local de respuesta a incidentes, incluyendo:
    • Manipulador de incidentes: Contacto de seguridad y contacto(s) alternativo(s) que tenga(n) credenciales de administrador del sistema, conocimiento técnico del sistema y conocimiento de la ubicación del plan de respuesta a incidentes.
    • Administrador de recursos: Una autoridad local/tomador de decisiones para el sistema que comprenda el impacto empresarial del sistema y su indisponibilidad. El propietario del recurso debe asumir las responsabilidades del gestor de recursos o designar a un miembro del personal del campus para esta función.
  • Detalles del sistema, o referencia a la ubicación de dicha información, incluyendo:
    • Diagramas de flujo de datos
    • Diagramas de red
    • Inventario de hardware del sistema (según lo exigido por el control de Registro anual)
    • Información de registro (según lo exigido por el control de Registro de auditoría)
    • Procedimientos para notificar y gestionar un presunto incidente, incluyendo:
      • Completar un informe de admisión de incidentes, que debe incluir la siguiente información:
        • Nombre y número de teléfono de la persona de contacto
        • Dirección IP, nombre de host y ubicación física del sistema vulnerado
        • Nombre del sistema cubierto (tal como aparece en NetReg)
        • ¿Qué tipos de datos cubiertos estaban disponibles en/desde el host vulnerado?
          • Nombre completo
          • Número de la Seguridad Social
          • Número del carné de conducir o de la tarjeta de identificación de California
          • Número de la tarjeta de crédito o de la cuenta financiera (incluyendo el PIN o la fecha de caducidad)
          • Número de la cuenta bancaria (incluyendo la fecha de caducidad)
          • Número de cuenta bancaria (incluido el PIN u otra información de acceso)
          • Información médica o del seguro médico
          • Otros
        • Para cada fichero que contenga información personal especifique:
          • Nombre del fichero
          • Tamaño del fichero
          • Localización del fichero (ruta completa)
        • ¿Se encriptaron los datos y, en caso afirmativo, cómo?
        • Describa el impacto del incidente (por ejemplo, el número de registros de datos comprometidos o el número de usuarios que se ven afectados por el sistema no disponible)
        • Describa el incidente de seguridad, incluyendo la línea de tiempo de las actividades, cómo se detectó el incidente, el impacto (empresarial y técnico) del incidente, los detalles de los controles de mitigación en el lugar, tales como qué mecanismo de cifrado de datos se utilizó.
        • Documentar las acciones que se están llevando a cabo en el sistema vulnerado (cuál es el estado del sistema ahora, etc)

      • Informar del incidente de seguridad a ISO (correo electrónico [email protected]*) e incluir el informe de entrada. Asignaremos un analista de seguridad para coordinar cualquier actividad de seguimiento de la respuesta al incidente.

        • Después de notificar un incidente de seguridad a ISO, no desconecte ni inicie sesión en el sistema vulnerado hasta que se lo indique el analista de seguridad de ISO.
        • La interrupción del servicio que no sea resultado de actividades maliciosas debe notificarse al personal de soporte de TI adecuado. Se puede encontrar información adicional sobre la notificación de diferentes tipos de incidentes en el sitio web de seguridad. Por ejemplo, para la mayoría de las aplicaciones empresariales de todo el campus, la interrupción del servicio debe notificarse a los servicios compartidos de TI del campus.

      • Responda al incidente de seguridad de forma oportuna basándose en la directriz de priorización de incidentes.

      *Nótese que la dirección de correo electrónico [email protected] debe utilizarse únicamente para informar de incidentes de seguridad cubiertos por MSSEI. Los incidentes de seguridad no cubiertos por el MSSEI deben notificarse a [email protected].

      Priorización de incidentes de seguridad

      Para ayudar a priorizar el tiempo y los recursos necesarios para desplegar la acción correctiva, los propietarios y custodios de los recursos deben evaluar el impacto de un incidente de seguridad basándose en los siguientes factores:

      • Cómo afectará el incidente a la funcionalidad existente de los sistemas afectados
      • Si el incidente vulnera la confidencialidad o la integridad de los datos cubiertos UC P4 (antes UCB PL2) o de los datos no cubiertos
      • Cuánta población de usuarios se ve afectada por el incidente de seguridad
      • Cuál es el impacto reputacional/financiero para el campus

      Utilizando los factores enumerados anteriormente como punto de partida, los incidentes de seguridad deben ser evaluados y se les debe asignar un nivel de prioridad alto o bajo por el gestor de incidentes y el administrador de recursos designados. Los factores a considerar incluyen no sólo el impacto actual del incidente sino también el probable impacto futuro del mismo si no se corrige inmediatamente. Cualquier incidente de alta prioridad debe ser notificado inmediatamente a ISO siguiendo los procedimientos de gestión de incidentes. Una vez que se notifique un incidente de seguridad al analista de ISO, la calificación de prioridad se confirmará o revisará tras un análisis adicional del evento.

      Ejemplos de incidente de seguridad de alta prioridad incluyen un evento que conduzca a la pérdida de una función crítica para la población de usuarios de todo el campus o departamento. Del mismo modo, la violación de la confidencialidad de los datos cubiertos que afecte a más de 500 usuarios también debe recibir una calificación de alta prioridad. El nivel de prioridad del incidente puede ser revisado en fases posteriores del proceso de respuesta al incidente después de que el análisis de pruebas adicionales proporcione una comprensión más precisa del impacto del incidente. Cualquier actualización del nivel de prioridad debe ser revisada por los miembros del equipo local de respuesta a incidentes, y por un analista de ISO.

      La siguiente tabla proporciona orientación adicional sobre el compromiso de tiempo para los miembros del equipo de respuesta a incidentes en caso de un incidente de seguridad (Analista de ISO, Gestor de Incidentes, Gestor de Recursos):

      Fases de respuesta a incidentes	Incidente de alta prioridad	Incidente de baja prioridad
      Detección	Inmediata	8 horas
      Análisis	Administrador de recursos y gestor de incidentes asignados para trabajar con el Analista ISO* de forma dedicada, de forma continua.	Trabajador de incidentes asignado y dedicado a trabajar con el Analista de ISO en el caso durante el horario normal de trabajo.
      Recuperación	Gestor de recursos y gestor de incidentes asignados para trabajar con el analista de ISO* de forma dedicada y continua.	Gestor de incidentes asignado para trabajar con el analista de ISO en el caso según el tiempo/los recursos disponibles.
      Posteriores al incidente	El gestor de incidentes asignado a trabajar con el analista de ISO en el caso según el tiempo/los recursos disponibles.	El gestor de incidentes asignado a trabajar con el analista de ISO en el caso según el tiempo/los recursos disponibles.

      * Los casos de alta prioridad pueden implicar a otras partes interesadas del campus, incluyendo la Política de TI, el Consejo del Campus y otros representantes de liderazgo del campus.

      Definiciones de la fase de respuesta a incidentes:

      • Detección – Especifica el tiempo máximo que debe transcurrir desde que se detecta el evento sospechoso hasta que se espera que se completen las siguientes acciones:
        • Evaluación inicial y triaje
        • Determinar el nivel de prioridad inicial basado en el informe de admisión
        • Informar del incidente a ISO
        • Se asigna un analista de ISO para que trabaje con el gestor de incidentes y el gestor de recursos
        • Ingresar el incidente en el sistema de tickets de ISO

      • Análisis -. El período de tiempo en el ciclo de vida del caso en el que se requiere una respuesta activa al incidente para garantizar la resolución exitosa del caso. Típicamente esto incluye interrupciones del sistema o del servicio, y/o la preservación urgente de pruebas. También se verifica la legitimidad del incidente, se confirma la priorización y se realiza la escalada adecuada en función del impacto del incidente. Las actividades típicas incluyen:

        • Evaluación, triaje, contención, preservación de pruebas, recuperación inicial

      • Recuperación: período de tiempo en el ciclo de vida del caso en el que no se requiere una respuesta activa al incidente para resolverlo con éxito. Las actividades típicas incluyen:

        • Recogida de evidencias, análisis e investigación, análisis forense, remediación, recuperación completa, post-mortem.

      • Post-incidente – Después de que el incidente se maneje adecuadamente, el equipo de respuesta a incidentes emite un informe que detalla la causa y el costo del incidente y los pasos que la organización debe tomar para prevenir futuros incidentes.

      Las definiciones se derivan de http://www.first.org/_assets/resources/guides/csirt_case_classification….

      Recursos adicionales

      • Guía de manejo de incidentes de seguridad informática del NIST, http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

      • Manual del Instituto de Ingeniería de Software para equipos de respuesta a incidentes de seguridad informática (CSIRT),http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm

      • Plan de Respuesta a Incidentes para sistemas y servicios individuales

      • Plan de Respuesta a Incidentes del Campus
      • Plan de Respuesta a Incidentes del Campus.