Resumen STIC UD 8 PDF

RESUMEN STIC UD 8 SA ARAMYS GÁZQUEZ LÓPEZ Contenido 1. INCIDENTES........................................................................................................................... 2 2. GESTIÓN DE INCIDENTES........................................................................................

RESUMEN STIC UD 8 SA ARAMYS GÁZQUEZ LÓPEZ Contenido 1. INCIDENTES........................................................................................................................... 2 2. GESTIÓN DE INCIDENTES....................................................................................................... 2 3. 2.1 FASES............................................................................................................................. 2 2.2 HERRAMIENTAS............................................................................................................. 2 2.3 ETAPAS Y CICLO DE VIDA................................................................................................ 3 INCIDENTES DE SEGURIDAD.................................................................................................. 3 3.1 PREVENCIÓN Y PREPARACIÓN....................................................................................... 3 3.2 DETECCIÓN.................................................................................................................... 4 3.3 NOTIFICACIÓN............................................................................................................... 4 3.4 RESPUESTA (IDENTIFICACIÓN, CONTENCIÓN Y ERRADICACIÓN).................................. 4 3.4.1 IDENTIFICACIÓN.................................................................................................... 4 3.4.2 CONTENCIÓN......................................................................................................... 4 3.4.3 ERRADICACIÓN...................................................................................................... 5 3.4.4 RECUPERACIÓN..................................................................................................... 5 3.5 PERIODO POSTERIOR (AFTERMATH)............................................................................. 6 4. INFORMACIÓN CLASIFICADA................................................................................................. 6 5. ACTORES Y RESPONSABILIDADES.......................................................................................... 7 5.1 ACTORES INTERNOS...................................................................................................... 7 5.2 ACTORES EXTERNOS...................................................................................................... 7 1. INCIDENTES   Incidente: conjunto de uno o más eventos de seguridad no planificados y con una posibilidad significa va de comprometer las operaciones del negocio y amenazar la seguridad corpora va. o Es imposible predecir un incidente. o Es muy posible que el impacto asociado a un incidente sea alto. Ges ón de incidentes: capacidad de responder de forma adecuada a los incidentes de seguridad de manera correcta, ágil y proporcional. 2. GESTIÓN DE INCIDENTES  Proceso con nuo: o Antes o Durante (respuesta pura) o Después (lecciones aprendidas, revisión y mejora) 2.1 FASES    Planificación: Organizar las ac vidades de preparación ante la ocurrencia de incidentes. Respuesta pura: Iden ficar para poder abordar su resolución de forma sa sfactoria. Periodo posterior: rela vo a las lecciones aprendidas en la ges ón del incidente y a la mejora de la seguridad corpora va en su conjunto. Las organizaciones deben establecer una capacidad de respuesta para ges onar los incidentes de una forma acorde a sus polí cas y requisitos de seguridad, con un ámbito, estructura y composición del equipo de ges ón de incidentes adecuados. Las Administraciones Públicas españolas enen el CCN CERT que cons tuye la Capacidad de Respuesta a Incidentes de Seguridad de la información del Centro Criptológico Nacional dependiente del CNI, cuyo obje vo principal es contribuir a la mejora del nivel de seguridad de las tres administraciones públicas existentes (general, autonómica y local) aportando soporte y coordinación. 2.2 HERRAMIENTAS Capacidad de respuesta viene determinada no tan solo por el conocimiento de los miembros del ERI (equipo respuesta incidentes) sino también por la calidad de las herramientas en los siguientes ámbitos:       Análisis de tráfico Procesamiento de trazas de registro logs Análisis de código malicioso (ingeniería inversa) y forense Evaluación de la seguridad y análisis de vulnerabilidades Monitorización y alerta temprana Ges ón de incidentes Lucia 2.3 ETAPAS Y CICLO DE VIDA Un incidente de seguridad pasa por diversas etapas desde su no ficación e iden ficación hasta que se le da respuesta y solución. 3. INCIDENTES DE SEGURIDAD El proceso de ges ón de incidentes, debe estar documentado, debe definirse un procedimiento de ges ón de incidentes que marque la opera va de al menos los siguientes aspectos:      Responsabilidades y autorizaciones No ficación Clasificación Determinación cri cidad Respuesta Lecciones aprendidas Se debe asignar un responsable de la ges ón, máximo responsable de la respuesta proporcionada y actuará también como interlocutor entre la organización y terceros, centralizará toda la información y actuaciones rela vas al incidente, único punto de contacto y obtendrá una visión global para tomar las decisiones adecuadas. 3.1 PREVENCIÓN Y PREPARACIÓN La prevención es vital para intentar minimizar el número o impacto de los incidentes que finalmente llegan a manos del ERI, las tareas preven vas van ligadas al seguimiento tanto de las amenazas y vulnerabilidades fuera de la organización como aquellas iden ficadas en la Organización en incidentes previos, englobando las siguientes tareas:     No ficación de vulnerabilidades en los productos u lizados Difusión de avisos sobre la existencia de nuevas o inminentes amenazas Recomendaciones de la aplicación de medidas de protección o iden ficación Formación y concienciación del personal 3.2 DETECCIÓN El primer paso es monitorizar los posibles elementos que puedan generar situaciones que comprometan la seguridad. Debe considerarse obligatoria la monitorización del entorno tecnológico propio sobre los elementos necesarios para garan zar los servicios que la organización presta y en los términos y umbrales necesarios para garan zar la calidad del servicio ofrecido. La detección es un momento crí co, cuanto más tarde se produzca esta situación junto con su no ficación al personal de respuesta, el impacto puede ser mayor en los sistemas de información de la Organización, esto se conoce como detección temprana. Cualquier miembro de la Organización que detecte una circunstancia anómala, será responsable de informar de esa circunstancia bajo los procedimientos de comunicación que se hayan dispuesto, por ejemplo, llamada o correo electrónico al Servicio de Informá ca y Atención al Usuario (SAU o CAU). Todos los eventos de seguridad deben ser registrados en la Organización (registro de incidentes). La Organización debe implantar canales que permitan al personal de la Organización la no ficación de posibles incidentes de una forma adecuada. 3.3 NOTIFICACIÓN Los canales de no ficación deben ser ágiles ya que la detección y alerta temprana es vital para que el impacto sea el menor posible. La Organización debe ofrecer a su personal canales para no ficar una situación anómala. Además, estos canales deben estar publicitados en la Organización y ser conocidos por todo el personal relevante, para garan zar que su funcionamiento es correcto. 3.4 RESPUESTA (IDENTIFICACIÓN, CONTENCIÓN Y ERRADICACIÓN) 3.4.1 IDENTIFICACIÓN Compuesta por acciones encaminadas a iden ficar, contener y erradicar el incidente para recuperar después la opera va estándar del entorno afectado. Hay que obtener una primera impresión del origen del incidente, en lo que se denomina la etapa de iden ficación. La primera tarea de esta etapa debe ser determinar si realmente el equipo se enfrenta a un incidente, aunque se haya realizado un análisis inicial, el responsable debe confirmar que el evento detectado o la no ficación que se ha hecho al equipo cons tuyen realmente un incidente. 3.4.2 CONTENCIÓN Confirmada la materialización de un incidente comienza la etapa de contención, cuyo obje vo es evitar que el alcance de un incidente se incremente y por tanto lo haga el impacto. Habitualmente la fase de contención se divide en dos partes:  La contención a corto plazo, que pretende detener la propagación preservando evidencias.  La contención a largo plazo, etapa en la que ya se introducen cambios en los elementos afectados por el incidente y que debe ser abordada una vez se ha tomado la información necesaria para posibles análisis forenses posteriores. Se debe disponer de procedimientos de contención detallados para los diversos pos de incidente. Las medidas de contención deben ser lo más específicas y eficientes posible, de manera que su aplicación no afecte la operación del resto de sistemas. Conlleva la recogida y preservación de evidencias de los sistemas de información tales como copias del disco duro, recolección de trazas de registro, logs, etc. Se debe conservar una descripción detallada de cada evidencia recogida incluyendo:     Datos de iden ficación (número de serie del equipo, nombre modelo, dirección IP, MAC). Nombre, cargo y número de teléfono de la persona o personas que han recogido la prueba. Fecha y hora de aparición de la prueba. Lugar de almacenamiento de la evidencia. 3.4.3 ERRADICACIÓN Eliminación total de los elementos que han posibilitado o potenciado el incidente o pueden volver a generarlo. Destaca el contenido de los archivos de registro de eventos (local o bien remotos si existe un punto de recogida centralizado {syslog}. Necesaria la incorporación al equipo de trabajo del incidente de miembros de la Organización que puedan ofrecer un conocimiento de alto nivel asociado a su área de conocimiento TIC: Administradores de red, sistemas o seguridad de los sistemas implicados. En defini va, en esta fase el equipo de respuesta debe “limpiar” los entornos afectados antes de devolverlos a su opera va estándar, tarea para la cual será necesario reinstalar por completo sistemas y aplicaciones afectados y bas onarlos convenientemente antes de devolverlos al entorno de producción. Además, deberá realizarse una verificación funcional y otra verificación de seguridad para dar la fase de erradicación por concluida. 3.4.4 RECUPERACIÓN Devolver a los entornos afectados por el incidente a su opera va estándar. En esta etapa deberán aplicarse salvaguardas (temporales o permanentes) con el objeto de garan zar que el incidente no vuelve a producirse. Un incidente se considera resuelto cuando se ha restablecido toda la información y los recursos, el sistema opera normalmente y se ene un conocimiento razonable de:     Las pérdidas ocasionadas Se conoce qué o quiénes han sido los causantes ¿Qué ha pasado? ¿Por qué ha pasado? 3.5 PERIODO POSTERIOR (AFTERMATH) La única fase que obligatoriamente deberá ser abordada por la Organización durante la ges ón de un incidente, corresponde con lo que se denomina lecciones aprendidas. En esta etapa, el equipo de ges ón de incidentes debe generar un informe de actuación que recopile todos los datos rela vos a la ges ón, las acciones emprendidas en cada etapa de la respuesta, las conclusiones obtenidas y, en especial, las directrices de mejora a abordar para que incidentes similares no vuelvan a producirse o si se producen su impacto sea menor para la Organización:          Datos de registro inicial especificados Resumen ejecu vo Relación de eventos de seguridad Iden ficación del responsable de ges ón del incidente Datos generales del incidente Informe del ERI Resumen de la resolución del incidente Análisis posterior Opciones de mejora Es de especial importancia contar con una base de datos de conocimiento dentro de la Organización que contenga la información rela va a los incidentes, con el obje vo de agilizar la ges ón en caso de que se vuelva a producir ya que las lecciones aprendidas, tal y como se ha indicado previamente, realimentan a la fase inicial del ciclo de vida de la ges ón de incidentes, la correspondiente a la preparación. 4. INFORMACIÓN CLASIFICADA En la ges ón de incidentes en Sistemas que manejan información clasificada, se debe comunicar inmediatamente la aparición del mismo a la Autoridad Opera va del Sistema y éste, dependiendo del po de información involucrada, a la Autoridad responsable de la acreditación. El equipo involucrado en la resolución del incidente debe disponer de la habilitación de seguridad correspondiente. Se debe determinar si ha sido comprome da información clasificada y, en su caso, de qué información se trata, su clasificación, número, fecha, originador, objeto y alcance. Adicionalmente, se debe indicar el período durante el cual ha sido expuesta o comprome da. El originador de la información debe ser no ficado del incidente. Durante la ges ón del incidente, la Autoridad Opera va del Sistema debe ser informada periódicamente. Una vez resuelto o si han transcurrido noventa 90 días desde la aparición del mismo, se debe elaborar y entregar un informe a la Autoridad Opera va del Sistema. Toda la información rela va al incidente debe ser mantenida y almacenada de acuerdo con la clasificación de la información comprome da. 5. ACTORES Y RESPONSABILIDADES El equipo de ges ón de incidentes debe tener el apoyo de una serie de áreas o grupos de trabajo internos a la Organización, así como relaciones habituales o puntuales con actores ajenos a ésta, pero relevantes, por uno u otro mo vo, en la ges ón de incidentes de seguridad. 5.1 ACTORES INTERNOS       DIRECCIÓN CORPORATIVA: define aspectos como el presupuesto, composición o polí ca a alto nivel del equipo, habitual el repor ng periódico a la Dirección, que será quien deba asumir la responsabilidad en relación a inicia vas emprendidas. DEPARTAMENTO DE SEGURIDAD: El responsable de la ges ón de un incidente debe disponer de autoridad sobre otros grupos para, en caso de ser requerido, obtener de éstos apoyo inmediato en esta fase de respuesta: o Seguridad sica para acceso a ubicaciones protegidas. o Seguridad lógica para habilitación o deshabilitación temporal de controles. DEPARTAMENTO DE TI: Áreas como Sistemas, Comunicaciones, Desarrollo, etc poseen, además de unos conocimientos técnicos muy específicos un conocimiento también profundo de la tecnología en la Organización, de especial u lidad en la fase caliente de la respuesta en la que es posible que se interrumpan ciertos servicios o que haya que tomar decisiones en relación a cambios tecnológicos sobre ac vos relevantes. DEPARTAMENTO JURÍDICO: La ges ón de incidentes debe tener un soporte legal muy amplio en todas sus fases, para garan zar que respetan la legislación vigente en cada caso. RECURSOS HUMANOS: En ocasiones los incidentes vienen mo vados o potenciados por atacantes internos, por este mo vo, sin perjuicio de posibles actuaciones legales, la Organización puede decidir emprender procedimientos disciplinarios contra personal interno. COMUNICACIÓN: repercusión en medios de comunicación o en el público en general que escapa al ámbito técnico del equipo de ges ón de incidentes, los departamentos de Prensa o Comunicación pueden ser relevantes en estas situaciones. 5.2 ACTORES EXTERNOS    FUERZAS Y CUERPOS DE SEGURIDAD: se debe mantener una comunicación bidireccional con las Fuerzas y Cuerpos de Seguridad del Estado con competencias en el ámbito de la Organización. CERTs - CSIRTs (CCN CERT Gubernamental Nacional): En el ámbito de las Administraciones Públicas españolas, es especialmente relevante la relación de los equipos de ges ón de incidentes con el CCN CERT, el CERT gubernamental español (guía CCN STIC 403 Ges ón Incidentes de Seguridad). En este caso concreto, los equipos de ges ón de incidentes deben mantener un contacto formal y periódico con el CCN CERT. FABRICANTES / PROVEEDORES: Dentro de la fase de preparación de la ges ón de incidentes, los equipos de ges ón deben establecer contacto con proveedores o fabricantes de productos y sistemas de uso en la Organización, con el obje vo de tener acceso a información rela va a su seguridad (en especial a sus vulnerabilidades), soporte para bas onado, acceso a parches y actualizaciones, etc. Ya que es dicho proveedor el que habitualmente dispone de los mayores expertos en sus productos y por el que nos puede proporcionar un apoyo técnico muy especializado en caso de ser necesario.