Taxonomía

Dependiendo del tipo de reporte recibido, éste se clasificará en una de las siguientes opciones:

  • Contenido abusivo: incidentes que muestren signos evidentes de spam, contengan comentarios ofensivos o inciten a la pederastia, violencia y/o delitos sexuales.
  • Contenido malicioso: problemas relacionados con virus, troyanos, gusanos, spyware, bots e inyección de código.
  • Obtención de información: los escaneos como reporte más común. También se consideran dentro de esta clasificación aquellos relacionados con los usos de sniffers, ingeniería social o ataques de fuerza bruta.
  • Acceso/Intrusión: incidentes en los que se manifieste el claro acceso a cuentas privilegiadas, no privilegiadas, compromiso de aplicaciones y ataques de 0-day.
  • Disponibilidad: ataques de denegación de servicio, tales como DoS, DDoS y sabotajes.
  • Seguridad/Confidencialidad de la información: problemas relacionados con el acceso a información y/o modificación no autorizada.
  • Fraude: reportes que tengan nexo con el uso no autorizado, derechos de autor, suplantación de identidad, phishing y robo de credenciales.
  • Helpdesk: aquellos incidentes que realicen consultas técnicas, mensajes informativos y peticiones judiciales.
  • Otros: reportes recibidos en el servicio gestionado por INCIBE-CERT, pero que no se debe tomar acciones puesto que no pertenece a su ámbito de actuación. También se incluirán en esta clasificación aquellas quejas sobre las que no se reporten evidencias o éstas no sean contrastadas.

Prioridades

  • Emergencia: incidentes cuya resolución no admite demora. Los incidentes de este tipo se procesarán en paralelo de haber varios y, en su resolución, se emplearán todos los recursos disponibles. Ejemplos: aquellos que supongan peligro para vidas humanas, para la seguridad nacional, para la infraestructura de Internet. Hasta ahora también se consideran emergencias todos aquellos incidentes que requieran acción inmediata debido a su rapidez y ámbito de difusión.
  • Alta: aquellos cuyas características requieren que sea atendido antes que otros, aunque sea detectado posteriormente. Se mantienen en una cola independiente de incidentes de alta prioridad, y no se procesarán los de prioridad inferior mientras que estos no estén atendidos. Los incidentes de alta prioridad se procesan en serie.
  • Normal: por defecto, los incidentes se atienden en serie por orden de llegada, mientras no requiera atención uno de prioridad superior. Un incidente de prioridad normal puede adquirir la categoría de alta prioridad si no recibe atención por un tiempo prolongado. Ejemplos: todos los incidentes no clasificados como alta prioridad o emergencia donde el atacante haya ganado acceso a un sistema informático ajeno. También se incluyen escaneos insistentes de redes.
  • Baja: los incidentes de baja prioridad se atienden en serie por orden de llegada, mientras no requiera atención uno de prioridad superior. Un incidente de baja prioridad será cerrado automáticamente si no recibe atención por un tiempo prolongado. Ejemplos: incidentes aislados en grado de tentativa, donde el atacante no ha conseguido su propósito y no es probable que lo consiga.

Relación de prioridades y taxonomías

La asignación de prioridad a un incidente podrá variar a lo largo del tiempo en función de la nueva información disponible sobre el mismo.

Por ello, esta relación pretende ser meramente orientativa pudiendo ser alterada en aquellos casos en los que el equipo de operación o de INCIBE-CERT lo estimen oportuno, atendiendo al alcance y gravedad del incidente.

Valores de cierre & KPIs institucionales

Todo ataque y su evolución de resolución quedan registrados en la herramienta de gestión de incidentes de INCIBE-CERT. Por ello, cabe destacar, que los valores de resolución computan para los KPIs institucionales.

Actualmente se indica, al origen del ataque, el valor de resolución del incidente para que puedan analizar y mejorar sus parámetros de calidad.

Los posibles valores de cierre son:

  • Solucionado satisfactoriamente (Se aportan soluciones): el problema ha sido solucionado. Se aportan las medidas adoptadas y se informa del origen y causas del ataque. Se deberán cumplir ambas condiciones para cerrarlo a tal valor.
  • Solucionado satisfactoriamente (No se aportan soluciones): el problema ha sido solucionado. No se informa de las medidas adoptadas o no se informa del origen y causas del ataque. Se considerarán dentro de esta categoría aquellos incidentes solucionados satisfactoriamente de los que no se ha abierto una investigación interna aclaratoria del ataque (i.e., medidas rápidas de actuación que impidan la investigación: formateos, eliminación de contenido malicioso sin conocer cómo han accedido a las máquinas, ...)
  • Parcialmente resuelto: se aportan medidas cautelares para remitir el ataque, pero no se solventa el problema de raíz (i.e., filtrado de IP, desconexión de la máquina).
  • Cierre ordenado por el cliente: No se aporta información adicional sobre las medidas adoptadas ni de las causas y el origen del ataque. De esta forma no se puede asegurar que la resolución haya sido satisfactoria.
  • Falso positivo: el cliente o el equipo de seguridad de RedIRIS determina que las conexiones son lícitas, pues pertenecen a proyectos de investigación u otras actividades controladas.
  • Problema no resuelto (Se obtiene respuesta): imposible alcanzar tecnológicamente la solución al problema o el cliente indica que no sabe solventarlo incluso con las indicaciones desde INCIBE-CERT. Se incluyen dentro de esta categoría aquellos incidentes que sean escalados a los técnicos de informática o administradores de sistemas institucionales y no proporcionen respuesta alguna. Por lo general, este tipo de actuaciones impiden seguir con el protocolo ordinario de actuación (i.e., mensajes de seguimiento).
  • Problema no resuelto (No se obtiene respuesta): el cliente no atiende al incidente remitido ni a los mensajes de seguimientos. También se considerarán dentro de este grupo aquellos incidentes no solucionados a pesar de obtener una auto respuesta.

Observación: En el caso de que el valor de resolución de su incidente no sea positivo, lo puede cambiar a "Resuelto satisfactoriamente (se aportan soluciones)" respondiendo al mensaje de cierre del ticket con las causas del ataque así como las soluciones aportadas.

¿Por qué estos valores de cierre?

Los valores de cierre están enfocados no sólo en la descripción de la solución aportada por la institución afectada, sino también tratan de mostrar el nivel de solución al que se ha podido llegar en cada uno de los incidentes.

El motivo fundamental se encuentra en que las labores de desinfección/reparación de máquinas afectadas por malware suelen ser una tarea interna de cada institución y trivial frente al conocimiento exhaustivo de sus causas.

Tener una información detallada sobre las causas que han originado cierta actividad maliciosa permite, entre otras cosas, ayudar a otras instituciones afiliadas a RedIRIS a resolver problemas similares, así como tener una fuente de conocimiento de la que toda la comunidad pueda sacar provecho.

Con el esfuerzo de todos, cuanto más detallada sea esta información, más ayuda personalizada le podremos ofrecer a su institución frente a cualquier anomalía.