Cuando se manejan múltiples incidentes simultáneamente, es necesaria la priorización. La razón para asignar prioridad es el nivel de importancia del error para la empresa y el usuario. A partir del diálogo con el usuario y de acuerdo con lo establecido en los Acuerdos de Nivel de Servicio (SLA), el Service Desk asigna prioridades que determinan el orden en el que se procesan las incidencias. Cuando los incidentes se derivan a una segunda, tercera o más líneas de soporte, se debe mantener la misma prioridad, pero a veces se puede ajustar consultando con el Service Desk.

impacto del incidente: el grado de desviación del nivel normal de prestación de servicios, expresado en el número de usuarios o procesos comerciales afectados por el incidente;

urgencia del incidente: Un retraso aceptable en la resolución de incidentes para un usuario o proceso comercial.

La prioridad se determina en función de la urgencia y el impacto. Para cada prioridad se determina el número de especialistas y la cantidad de recursos que se pueden destinar a resolver la incidencia. El orden en que se manejan los incidentes de la misma prioridad se puede determinar según el esfuerzo requerido para resolver el incidente. Por ejemplo, un incidente que se resuelve fácilmente puede gestionarse antes que otro que requiera más esfuerzo.

En la Gestión de Incidentes, existen formas de reducir el impacto y la urgencia, como cambiar el sistema a una configuración de respaldo, redirigir la cola de impresión, etc.

Arroz. 4.2. Determinar el impacto, la urgencia y la prioridad

El impacto y la urgencia también pueden cambiar con el tiempo, por ejemplo, a medida que aumenta el número de usuarios afectados por un incidente o en momentos críticos.

El impacto y la urgencia se pueden combinar en una matriz como se muestra en la Tabla 1. 4.1.

Tabla 4.1. Ejemplo de un sistema de codificación de prioridades

Escalada

Si el incidente no puede ser resuelto por la primera línea de soporte dentro del tiempo acordado, se debe incorporar experiencia o autoridad adicional. A esto se le llama escalada, que se produce de acuerdo con las prioridades comentadas anteriormente y, en consecuencia, el tiempo para resolver el incidente.

Existen escalamientos funcionales y jerárquicos:

Escalada funcional (horizontal)– significa involucrar a más especialistas o proporcionar derechos de acceso adicionales para resolver el incidente; al mismo tiempo, es posible que exista una extensión más allá de los límites de un departamento estructural de TI.

Escalada jerárquica (vertical)– significa una transición vertical (a un nivel superior) dentro de la organización, ya que no hay suficiente autoridad organizacional (nivel de autoridad) o recursos para resolver el incidente.

El trabajo del Gerente de Procesos de Gestión de Incidentes es reservar proactivamente oportunidades de escalamiento funcional dentro de las unidades de línea de la organización para que la resolución de incidentes no requiera un escalamiento jerárquico regular. En cualquier caso, las unidades de línea deberán dotar de recursos suficientes para este proceso.

Soporte de primera, segunda y n líneas

La ruta del incidente, o escalamiento funcional, se describió anteriormente. El enrutamiento está determinado por el nivel requerido de conocimiento, autoridad y urgencia. La primera línea de soporte (también llamada soporte de nivel 1) suele ser la mesa de servicio, la segunda línea es la gestión de la infraestructura de TI, la tercera es el desarrollo y la arquitectura de software y la cuarta son los proveedores. Cuanto más pequeña es la organización, menos niveles de escalada tiene. En organizaciones grandes, el Gerente del Proceso de Gestión de Incidentes puede nombrar Coordinadores de Incidentes en los departamentos apropiados para apoyar sus actividades. Por ejemplo, los coordinadores pueden desempeñar el papel de interfaz entre las actividades del proceso y las unidades organizativas de línea. Cada uno de ellos coordina las actividades de sus propios grupos de apoyo. El procedimiento de escalamiento se presenta gráficamente en la Fig. 4.3.

Arroz. 4.3. Escalada de incidentes (fuente: OGC)

El objetivo del Proceso de Gestión de Incidentes es restaurar el Nivel de Servicio normal tal como se define en el Acuerdo de Nivel de Servicio (SLA) lo más rápido posible, con la mínima pérdida posible para las actividades comerciales de la organización y los usuarios. Además, el Proceso de Gestión de Incidentes debe mantener un registro preciso de los incidentes para evaluar y mejorar el proceso y proporcionar la información necesaria a otros procesos.

4.2.1. Beneficios de utilizar el proceso

Para negocios en general:

Resolución oportuna de incidentes, que conduzcan a una reducción de las pérdidas comerciales;

Mayor productividad del usuario;

Monitoreo de incidentes independiente y centrado en el cliente;

Disponibilidad de información objetiva sobre el cumplimiento de los servicios prestados con los acuerdos acordados (SLA).

Para una organización de TI:

Monitoreo mejorado, que permite una comparación precisa de los niveles de desempeño del sistema de TI con los acuerdos (SLA);

Gestión y seguimiento efectivos de la implementación de acuerdos (SLA) basados ​​en información confiable;

Uso efectivo del personal;

Evitar que los incidentes y Solicitudes de Servicio se pierdan o se registren incorrectamente;

Incrementar la precisión de la información en la Base de Datos de Gestión de Configuración (CMDB) comprobándola al registrar incidentes en relación con los Elementos de Configuración (CI);

Incremento de la satisfacción de usuarios y clientes.

No utilizar el Proceso de Gestión de Incidentes puede tener como resultado las siguientes consecuencias negativas:

Los incidentes pueden perderse o, por el contrario, percibirse injustificadamente como extremadamente graves debido a la ausencia de los responsables del seguimiento y la escalada, lo que puede conducir a una disminución del nivel general del servicio;

Los usuarios pueden ser redirigidos a los mismos especialistas “en círculo” sin lograr resolver la incidencia;

Los profesionales pueden verse constantemente interrumpidos por llamadas telefónicas de los usuarios, lo que les dificulta realizar su trabajo de forma eficaz;

Pueden surgir situaciones en las que varias personas trabajen en el mismo incidente, perdiendo tiempo de forma improductiva y tomando decisiones contradictorias;

Puede haber una falta de información sobre los usuarios y los servicios prestados para apoyar las decisiones de gestión;

Debido a los posibles problemas mencionados anteriormente, el costo para la empresa y la organización de TI de respaldar los servicios será mayor de lo que realmente se requiere.

En la Fig. La Figura 4.4 muestra las entradas y salidas de un proceso, así como las actividades que implica el proceso.

Arroz. 4.4. Declaración del proceso de gestión de incidentes

4.3.1. Entradas de proceso

Los incidentes pueden ocurrir en cualquier parte de la infraestructura. A menudo son reportados por los usuarios, pero también pueden ser detectados por empleados de otros departamentos, así como por sistemas de gestión automática configurados para registrar eventos en aplicaciones e infraestructura técnica.

4.3.2. Gestión de configuración

La base de datos de gestión de configuración (CMDB) juega un papel importante en la gestión de incidentes, ya que define la relación entre recursos, servicios, usuarios y niveles de servicio. Por ejemplo, la Gestión de la configuración muestra quién es responsable de un componente de la infraestructura, lo que permite distribuir los incidentes de manera más efectiva entre los equipos. Además, esta base de datos ayuda a resolver problemas operativos como redirigir una cola de impresión o cambiar un usuario a otro servidor. Cuando se registra un incidente, se agrega un enlace al elemento de configuración (CI) correspondiente a los datos de registro, lo que permite proporcionar información más detallada sobre el origen del error. Si es necesario, se puede actualizar el estado del componente correspondiente en la CMDB.

4.3.3. Gestión de problemas

Una gestión eficaz de problemas requiere un registro de incidentes de alta calidad, lo que facilitará enormemente la búsqueda de las causas fundamentales. Por otro lado, la Gestión de Problemas ayuda al Proceso de Gestión de Incidentes proporcionando información sobre problemas, errores conocidos, soluciones alternativas y soluciones rápidas.

4.3.4. Gestión del cambio

Las incidencias se pueden solucionar realizando cambios, como por ejemplo sustituyendo el monitor. La Gestión de Cambios proporciona al Proceso de Gestión de Incidentes información sobre los cambios planificados y sus estados. Además, los cambios pueden provocar incidencias si los cambios se realizan de forma incorrecta o contienen errores. El Proceso de Gestión de Cambios recibe información sobre los mismos del Proceso de Gestión de Incidentes.

4.3.5. Gestión del nivel de servicio

La Gestión del Nivel de Servicio controla la implementación de acuerdos (SLA) con el cliente en relación con el soporte que se le brinda. El personal involucrado en la Gestión de Incidentes debe estar familiarizado con estos acuerdos para poder utilizar la información necesaria al contactar con los usuarios. Además, se requieren registros de incidentes con fines de presentación de informes para verificar que se esté cumpliendo el nivel de servicio acordado.

4.3.6. Gestión de accesibilidad

El Proceso de Gestión de Disponibilidad utiliza registros de incidentes y datos de monitoreo de estado proporcionados por el Proceso de Gestión de Configuración para determinar las métricas de disponibilidad del servicio. De manera similar a un elemento de configuración (CI) en una base de datos de configuración (CMDB), a un servicio también se le puede asignar el estado "fuera de servicio". Esto se puede utilizar para verificar la disponibilidad real del servicio y los tiempos de respuesta del proveedor. Al realizar dicha verificación, es necesario registrar el tiempo de las acciones que ocurrieron durante el proceso de procesamiento del incidente, desde el momento de su detección hasta su cierre.

4.3.7. Gestión de capacidad

El proceso de Gestión de Capacidad recibe información sobre incidentes relacionados con el funcionamiento de los propios sistemas de TI, por ejemplo, incidentes ocurridos por espacio insuficiente en disco o velocidad de respuesta lenta, etc. A su vez, la información sobre estos incidentes puede ingresar al Proceso de Gestión de Incidentes desde el administrador del sistema o desde el propio sistema en función del monitoreo de su condición.

Sin arroz. 4.5. Se muestran los pasos del proceso:

Arroz. 4.5. Proceso de gestión de incidentes

Aceptación y Registro– se recibe el mensaje y se crea un registro de incidencia.

Clasificación y soporte inicial– se asigna el tipo, estado, grado de impacto, urgencia, prioridad del incidente, SLA, etc. Se podrá ofrecer al usuario una posible solución, aunque sea temporal.

Si la llamada se refiere Petición de servicio, entonces se inicia el trámite correspondiente.

Encuadernación (o coincidencia)– comprueba si el incidente ya es un incidente conocido o un error conocido, si ya existe un problema abierto y si existe una solución o solución alternativa conocida.

Investigación y diagnóstico (Investigación y Diagnóstico)– a falta de una solución conocida, se lleva a cabo una investigación del incidente para restablecer el funcionamiento normal lo antes posible.

Resolución y recuperación– si se encuentra una solución, se podrá restablecer el trabajo.

Cierre– Se contacta con el usuario para confirmar la aceptación de la solución propuesta, tras lo cual se puede cerrar la incidencia.

Monitoreo y seguimiento del progreso– se monitorea todo el ciclo de procesamiento de incidentes, y si el incidente no se puede resolver a tiempo, se lleva a cabo una escalada.

4.4.1. Recepción y registro

En la mayoría de los casos, los incidentes son registrados por el Service Desk, donde se reportan los incidentes. Todos los incidentes deben registrarse inmediatamente después de su notificación por las siguientes razones:

Es difícil registrar con precisión información sobre un incidente si no se hace de inmediato;

Monitorear el progreso del trabajo para resolver un incidente solo es posible si el incidente está registrado;

Los incidentes registrados ayudan a diagnosticar nuevos incidentes;

La gestión de problemas puede utilizar incidentes registrados cuando trabaja para encontrar las causas fundamentales;

Es más fácil determinar el grado de impacto si se graban todos los mensajes (llamadas);

Sin registrar incidentes, es imposible monitorear la implementación de los acuerdos (SLA);

El registro inmediato de incidentes evita situaciones en las que varias personas trabajan en la misma llamada o nadie hace nada para resolver el incidente.

La ubicación del incidente está determinada por el origen del mensaje. Los incidentes se pueden detectar de la siguiente manera:

Descubierto por el usuario: Informa del incidente al Service Desk.

Detectado por el sistema: Cuando se detecta un evento en la aplicación o la infraestructura técnica, por ejemplo, cuando se excede un umbral crítico, el evento se registra como un incidente en el sistema de notificación de incidentes y, si es necesario, se escala al equipo de soporte.

Detectado por la mesa de servicio: El empleado registra el incidente.

Descubierto por alguien en otro departamento de TI: Este especialista registra el incidente en el sistema de notificación de incidentes o lo informa al Service Desk.

Debe evitarse la doble grabación del mismo incidente. Por lo tanto, a la hora de registrar una incidencia se debe comprobar si existen incidencias abiertas similares:

Si los hay (y se relacionan con el mismo incidente), se actualiza la información sobre el incidente o se registra el incidente por separado y se establece una conexión (enlace) con el incidente principal; si es necesario, se cambia el nivel de impacto y la prioridad, y se agrega información sobre el nuevo usuario.

Si no (diferente del incidente abierto), se registra una nueva incidencia.

En ambos casos la continuación del proceso es la misma, aunque en el primer caso los pasos posteriores son mucho más sencillos.

Cuando se registra una incidencia se realizan las siguientes acciones:

Asignar un número de incidente: En la mayoría de los casos, el sistema asigna automáticamente un nuevo número de incidente (único). Muchas veces este número se proporciona al usuario para que pueda consultarlo en futuros contactos.

Registro de información de diagnóstico básica: hora, signos (síntomas), usuario, empleado que aceptó el asunto a trámite, localización de la incidencia e información sobre el servicio y/o medio técnico afectado.

Grabar información adicional sobre el incidente.: La información se agrega, por ejemplo, desde un script o procedimiento de sondeo o desde una base de datos de configuración (CMDB) (normalmente basada en las relaciones de elementos de configuración definidas en la CMDB).

Anuncio de alarma: Si ocurre un incidente de alto impacto, como una falla crítica del servidor, se emite una alerta a otros usuarios y a la administración.

4.4.2. Clasificación

La clasificación de incidentes tiene como objetivo definir su categoría para facilitar el seguimiento y la notificación. Es deseable que las opciones de clasificación sean lo más amplias posible, pero esto requiere un mayor nivel de responsabilidad del personal. A veces intentan combinar varios aspectos de la clasificación en una lista, como tipo, grupo de apoyo y fuente. Esto muchas veces causa confusión. Es mejor utilizar varias listas cortas. Esta sección aborda cuestiones relacionadas con la clasificación.

sistema de procesamiento central– subsistema de acceso, servidor central, aplicación.

Neto– enrutadores, segmentos, concentradores, direcciones IP.

Estación de trabajo– monitor, tarjeta de red, unidad de disco, teclado.

Uso y funcionalidad– servicio (servicio), capacidades del sistema, disponibilidad, respaldo (back-up), documentación.

Organización y procedimientos– pedido, solicitud, soporte, notificación (comunicaciones).

Petición de servicio– una solicitud de usuario al Service Desk para soporte, información, documentación o consulta. Esto se puede separar en un procedimiento separado o manejarse de la misma manera que un incidente real.

Una prioridad

Luego se asigna una prioridad para garantizar que el equipo de soporte preste al incidente la atención que necesita. La prioridad es un número determinado por la urgencia (qué tan rápido debe solucionarse) y el impacto (cuánto daño se producirá si no se soluciona rápidamente).

Prioridad = Urgencia x Impacto.

Servicios (servicios)

Para identificar los servicios afectados por el incidente, se puede utilizar una lista de acuerdos de nivel de servicio (SLA) existentes. Esta lista también le permitirá establecer el tiempo de escalamiento para cada uno de los servicios definidos en el SLA.

Grupo de apoyo

Si la mesa de servicio no puede resolver el incidente de inmediato, se asigna un equipo de soporte para resolver el incidente. La base para la distribución de incidentes (enrutamiento) suele ser información de categorías. Al definir las categorías, es posible que sea necesario considerar la estructura de los grupos de apoyo. La distribución adecuada de los incidentes es esencial para la eficacia del Proceso de Gestión de Incidentes. Por lo tanto, uno de los indicadores clave de rendimiento (KPI) del proceso de gestión de incidentes puede ser la cantidad de tickets asignados incorrectamente.

Plazo para la decisión

Teniendo en cuenta la prioridad y acuerdo SLA, se informa al usuario del tiempo máximo estimado para resolver la incidencia. Estos plazos también quedan registrados en el sistema.

Número de identificación del incidente

Se informa al abonado sobre el número de incidencia para su correcta identificación en llamadas posteriores.

Estado

El estado de un incidente indica su posición en el proceso de manejo de incidentes. Ejemplos de estados podrían ser:

Planificado;

Fijado;

Activo;

Aplazado;

Permitido;

4.4.3. Encuadernación (mapeo)

Después de la clasificación, se comprueba si ha ocurrido un incidente similar antes y si existe una solución o solución alternativa ya preparada. Si un incidente tiene las mismas características que un problema abierto o un error conocido, se puede vincular a él.

4.4.4. Investigación y diagnóstico.

El Service Desk o el equipo de soporte escala los incidentes que no tienen solución o están más allá de las capacidades de la persona que trabaja con ellos al equipo de soporte del siguiente nivel con más experiencia y conocimiento. Este equipo investiga y resuelve el incidente o lo escala al siguiente nivel del equipo de soporte.

Durante el proceso de resolución de incidentes, diversos especialistas pueden actualizar el registro de incidentes cambiando el estado actual, información sobre acciones tomadas, revisando la clasificación y actualizando el tiempo y código del empleado.

4.4.5. Solución y recuperación

Tras completar con éxito el análisis y resolver la incidencia, el empleado registra la solución en el sistema. En algunos casos, es necesario enviar una Solicitud de Cambio (RFC) al Proceso de Gestión de Cambios. En el peor de los casos, si no se encuentra una solución, el incidente queda abierto.

4.4.6. Clausura

Una vez que se implementa una solución a satisfacción del usuario, el equipo de soporte remite el incidente a la mesa de servicio. Este servicio contacta al empleado que reportó el incidente para obtener confirmación de que el problema se ha resuelto exitosamente. Si confirma esto, entonces el incidente puede cerrarse; de lo contrario, el proceso se reanuda en el nivel apropiado. Cuando se cierra un incidente, es necesario actualizar la categoría final, la prioridad, los servicios afectados por el incidente y el elemento de configuración (CI) que causó la falla.

4.4.7. Monitoreo y seguimiento del progreso de la solución

En la mayoría de los casos, el Service Desk, como “dueño” de todas las incidencias, es el responsable de monitorear el progreso de la resolución. Este servicio también debe informar al usuario sobre el estado de la incidencia. Los comentarios de los usuarios pueden ser apropiados después de un cambio de estado, como escalar un incidente a la siguiente línea de soporte, cambiar el tiempo estimado de resolución, escalar, etc. Durante el monitoreo, es posible escalar funcionalmente a otros grupos de soporte o escalar jerárquicamente para tomar decisiones ejecutivas. .

La base para el control de procesos son los informes para distintos grupos destinatarios. El Gerente de Proceso de Gestión de Incidentes es responsable de estos informes, así como de la lista de correo y el cronograma de informes. Los informes podrán incluir información especializada para las siguientes unidades funcionales:

El Gerente del Proceso de Gestión de Incidentes necesita el informe para:

Identificación de eslabones faltantes en el proceso;

Identificación de violaciones de los Acuerdos de Nivel de Servicio (SLA);

Seguimiento del avance del proceso;

Determinación de tendencias de desarrollo.

Gestión de Departamentos TI Lineales– informe para la gestión del grupo de apoyo; También puede ser útil en la gestión del departamento de TI. El informe debe contener la siguiente información:

Avances en la resolución de incidencias;

Tiempo para resolver incidencias en diversos grupos de soporte.

Gestión del nivel de servicio– el informe debe contener, en primer lugar, información sobre la calidad de los servicios prestados. El Gerente de Proceso de Gestión de Nivel de Servicio debe recibir toda la información necesaria para preparar Informes de Nivel de Servicio para los clientes. Los informes a los clientes deben proporcionar información sobre si se están cumpliendo los acuerdos de Nivel de Servicio dentro del Proceso de Gestión de Incidentes.

Responsables de otros procesos de Gestión de Servicios TI– Los informes para los responsables de otros procesos deben, ante todo, ser informativos, es decir, contener toda la información que necesitan. Por ejemplo, un Proceso de Gestión de Incidentes basado en registros de incidentes podría proporcionar la siguiente información:

Número de incidentes detectados y registrados;

Número de incidentes resueltos, dividido por el tiempo de resolución;

Estado y número de incidentes no resueltos;

Incidencias por periodo de ocurrencia, grupos de clientes, grupos de soporte y tiempo de resolución de acuerdo al acuerdo (SLA);

4.5.1. Factores críticos del éxito

La gestión exitosa de incidentes requiere lo siguiente:

Una base de datos de configuración (CMDB) actualizada para ayudar a evaluar el impacto y la urgencia de los incidentes. Esta información también se puede obtener del usuario, pero en este caso puede ser menos completa y bastante subjetiva, lo que provocará un aumento del tiempo de resolución de incidencias.

Para evaluar el desempeño del proceso, es necesario definir claramente los parámetros de control y puntajes mensurables, a menudo llamados indicadores de desempeño. Estas métricas se informan periódicamente, por ejemplo una vez por semana, para proporcionar una imagen de los cambios a partir de la cual se pueden identificar tendencias. Ejemplos de tales parámetros son:

Número total de incidentes;

Tiempo medio de resolución de incidencias;

Tiempo medio de resolución de incidencias por prioridad;

Número promedio de incidentes resueltos dentro de los SLA;

Porcentaje de incidentes resueltos por la primera línea de soporte (sin derivación a otros grupos);

Costo promedio de soporte por incidente;

Número de incidentes resueltos por lugar de trabajo o por empleado de Service Desk;

Incidencias resueltas sin visitar al usuario (de forma remota);

Número (o porcentaje) de incidentes con clasificación inicialmente incorrecta;

Número (o porcentaje) de incidentes asignados incorrectamente a grupos de apoyo.

4.5.3. Funciones y roles

La implementación de procesos se realiza en un plano horizontal a través de la estructura jerárquica de la organización. Esto sólo es posible con una definición clara de las responsabilidades y autoridades asociadas a la implementación de los procesos. Para aumentar la flexibilidad, se puede utilizar un enfoque basado en roles (es decir, definir roles). En organizaciones pequeñas o para reducir costos generales, es posible combinar roles, por ejemplo, combinando los roles de Gestión de Cambios y Gerente de Procesos de Gestión de Configuración.

Responsable de Procesos de Gestión de Incidentes

En muchas organizaciones, la función de administrador de gestión de incidentes la desempeña el administrador de la mesa de servicio. Las responsabilidades del Gerente de Proceso de Gestión de Incidentes incluyen lo siguiente:

Seguimiento de la eficiencia y racionalidad del proceso;

Seguimiento del trabajo de los grupos de apoyo;

Desarrollo y mantenimiento del sistema de Gestión de Incidentes.

Personal del grupo de apoyo

La primera línea de soporte se encarga de registrar, clasificar, emparejar (vincular), asignar a grupos de apoyo, resolver y cerrar incidencias.

El resto de equipos de soporte se dedican principalmente a investigar, diagnosticar y resolver incidentes dentro de las prioridades establecidas.

4.6.1. Gastos

Los costos asociados con la Gestión de Incidentes incluyen costos de implementación inicial (por ejemplo, costos de desarrollo de procesos, capacitación y entrenamiento del personal), selección y adquisición de herramientas para respaldar el proceso. La selección de herramientas puede llevar una cantidad significativa de tiempo. Además, existen costos operativos asociados con el pago del personal y el uso de herramientas. Estos costos dependen en gran medida de la estructura de la Gestión de Incidentes, la gama de actividades incluidas en el proceso, las áreas de responsabilidad y el número de departamentos.

4.6.2. Problemas

Al implementar la Gestión de Incidentes, pueden surgir los siguientes problemas:

Usuarios y profesionales de TI trabajan en torno a los procedimientos de gestión de incidentes.– si los usuarios resuelven los errores ellos mismos o contactan directamente a los especialistas sin seguir los procedimientos establecidos, la organización de TI no recibirá información sobre el nivel de servicio real proporcionado, la cantidad de errores y mucho más. Los informes a la dirección tampoco reflejarán adecuadamente la situación.

Sobrecarga de incidentes y procrastinación “para más tarde”– si hay un aumento inesperado en el número de incidentes, es posible que no haya tiempo suficiente para un registro correcto, ya que antes de que termine de ingresar información sobre el incidente de un usuario, es necesario atender al siguiente. En este caso, la entrada de descripciones de incidentes puede no ser lo suficientemente precisa y los procedimientos para distribuir incidentes a los grupos de apoyo no se llevarán a cabo correctamente. Como resultado, las decisiones son de mala calidad y la carga de trabajo aumenta aún más. En los casos en que el número de incidentes abiertos comienza a aumentar rápidamente, un procedimiento para la asignación de emergencia de recursos adicionales dentro de la organización puede evitar la sobrecarga de personal.

Escalada– Como es sabido, la escalada de incidentes es posible dentro del Proceso de Gestión de Incidentes. Demasiadas escaladas pueden tener un impacto negativo en el trabajo de los especialistas, que por lo tanto se ven apartados de su trabajo planificado.

Falta de un catálogo de servicios y acuerdos de nivel de servicio (SLA)– Si los servicios y productos admitidos no están bien definidos, puede resultar difícil para quienes participan en la gestión de incidentes rechazar razonablemente la asistencia a los usuarios.

Falta de compromiso Enfoque de proceso por parte de la dirección y el personal.– la resolución de incidentes utilizando un enfoque de procesos generalmente requiere un cambio de cultura y un mayor nivel de responsabilidad por su trabajo por parte del personal. Esto puede causar una resistencia significativa dentro de la organización. La gestión eficaz de incidentes requiere que los empleados comprendan y se comprometan verdaderamente con un enfoque de proceso en lugar de simplemente participar.

Notas:

La “cadena” se refiere a la cadena de creación de plusvalía. – Aprox. ed.

En la literatura ITIL, el concepto de "función" está asociado con una división vertical (línea) de una organización que desempeña las responsabilidades funcionales correspondientes y, de hecho, es sinónimo de ella. – Aprox. ed.

Petición de servicio.

Solicitud de cambio (RFC).

Elemento de configuración (CI).

Indicadores clave de rendimiento: KPI.

Indicadores de desempeño.

Eficacia y eficiencia.

Aquellos. software. – Aprox. ed.

Garantizar la seguridad de la información empresarial Andrianov V.V.

4.1.4. Ejemplos de incidentes

4.1.4. Ejemplos de incidentes

información general

Esta sección describe los detalles publicados de algunos de los incidentes de alto perfil. Al mismo tiempo, la generalización de los incidentes proporciona una gran cantidad de circunstancias que caracterizan la variedad de amenazas a la seguridad de la información por parte del personal, tanto en términos de motivos y condiciones como en términos de los medios utilizados. Entre los incidentes más frecuentes destacamos los siguientes:

Fuga de información oficial;

Robo de clientes y negocios de la organización;

Sabotaje de infraestructura;

Fraude interno;

Falsificación de informes;

Negociar en mercados basados ​​en información privilegiada y patentada;

Abuso de autoridad.

anotación

En represalia por una bonificación demasiado pequeña, Roger Duronio, de 63 años (ex administrador de sistemas de la UBS Paine Webber), instaló una "bomba lógica" en los servidores de la empresa, que destruyó todos los datos y paralizó el trabajo de la empresa durante mucho tiempo.

Descripción del incidente

Duronio estaba insatisfecho con su salario de 125.000 dólares al año, lo que pudo haber sido el motivo de la introducción de la bomba lógica. Sin embargo, la gota que colmó el vaso para el administrador del sistema fue la bonificación que recibió de 32.000 dólares en lugar de los 50.000 dólares esperados. Cuando descubrió que su bonificación era mucho menor de lo que esperaba, Duronio exigió a su jefe que renegociara su contrato de trabajo por 175.000 dólares al año o dejaría la empresa. Le negaron un aumento de sueldo y también le pidieron que abandonara el edificio del banco. En represalia por tal trato, Duronio decidió utilizar su “invento”, introducido de antemano, anticipándose a tal giro de los acontecimientos.

Duronio implementó la “bomba lógica” desde la computadora de su casa varios meses antes de recibir lo que consideraba una bonificación demasiado pequeña. La bomba lógica se instaló en aproximadamente 1.500 computadoras en una red de sucursales en todo el país y se programó a una hora específica: las 9:30, justo a tiempo para el inicio del día bancario.

Duronio renunció a UBS Paine Webber el 22 de febrero de 2002 y el 4 de marzo de 2002, una bomba lógica eliminó secuencialmente todos los archivos en el servidor de base de datos central principal y 2.000 servidores en las 400 sucursales del banco, al tiempo que deshabilitaba el sistema de respaldo.

Durante el juicio, el abogado de Duronio señaló que el culpable del incidente no podía ser solo el acusado: dada la inseguridad de los sistemas informáticos de la UBS Paine Webber, cualquier otro empleado podría haber llegado allí con el login de Duronio. Los problemas con la seguridad informática en el banco se conocieron en enero de 2002: durante una auditoría se descubrió que 40 personas del servicio informático podían iniciar sesión en el sistema y obtener derechos de administrador utilizando la misma contraseña, y comprender quién lo hizo exactamente o quién otra acción no fue posible. El abogado también acusó a la UBS Paine Webber y a la empresa @Stake, contratada por el banco para investigar el incidente, de destruir pruebas del ataque. Sin embargo, la evidencia irrefutable de la culpabilidad de Duronio fueron los fragmentos de código malicioso encontrados en las computadoras de su casa y una copia impresa del código en su armario.

Oportunidades internas

Como uno de los administradores de sistemas de la empresa, a Duronio se le asignó la responsabilidad y el acceso a toda la red informática de UBS PaineWebber. También tenía acceso a la red desde la computadora de su casa a través de una conexión segura a Internet.

Causas

Como se dijo anteriormente, sus motivos eran el dinero y la venganza. Duronio recibió un salario anual de 125.000 dólares y un bono de 32.000 dólares, mientras esperaba 50.000 dólares, y así se vengó de su decepción.

Además, Duronio decidió ganar dinero con el ataque: previendo una caída de las acciones del banco debido a un desastre informático, hizo una orden de venta de futuros para recibir la diferencia cuando el tipo bajara. El acusado gastó 20.000 dólares en esto. Sin embargo, los títulos del banco no cayeron y las inversiones de Duronio no dieron sus frutos.

Consecuencias

La “bomba lógica” colocada por Duronio paró el funcionamiento de 2.000 servidores en 400 oficinas de la empresa. Según Elvira María Rodríguez, gerente de TI de la UBS Paine Webber, fue un desastre “más de 10 en una escala de 10”. El caos reinaba en la empresa, que tuvo que eliminar a 200 ingenieros de IBM durante casi un día. En total, unos 400 especialistas trabajaron para corregir la situación, incluido el servicio informático del propio banco. Los daños causados ​​por el incidente se estiman en 3,1 millones de dólares. Ocho mil corredores en todo el país se vieron obligados a dejar de trabajar. Algunos de ellos pudieron volver a sus operaciones normales después de unos días, otros después de algunas semanas, dependiendo de cuán gravemente se vieron afectadas sus bases de datos y si la sucursal bancaria tenía copias de seguridad. En general, las operaciones bancarias se reanudaron a los pocos días, pero algunos servidores nunca se restauraron por completo, en gran parte debido a que el 20% de los servidores no contaban con instalaciones de respaldo. Sólo un año después, todo el parque de servidores del banco fue completamente restaurado.

Durante el juicio de Duronio ante los tribunales, fue acusado de los siguientes cargos:

Fraude de valores: este cargo conlleva una pena máxima de 10 años en una prisión federal y una multa de 1 millón de dólares;

Fraude informático: este cargo conlleva una pena máxima de 10 años de prisión y una multa de 250.000 dólares.

Como resultado del juicio de finales de diciembre de 2006, Duronio fue condenado a 97 meses sin libertad condicional.

"Vimpelcom" y "Sherlock"

anotación

Con fines de lucro, ex empleados de la empresa VimpelCom (marca comercial Beeline) ofrecieron detalles de conversaciones telefónicas de operadores de telefonía móvil a través del sitio web.

Descripción del incidente

Los empleados de la empresa VimpelCom (antiguos y actuales) organizaron el sitio web www.sherlok.ru en Internet, del que la empresa VimpelCom tuvo conocimiento en junio de 2004. Los organizadores de este sitio ofrecieron un servicio: buscar personas por apellido, número de teléfono y otros datos. En julio, los organizadores del sitio ofrecieron un nuevo servicio: detallar las conversaciones telefónicas de los operadores de telefonía móvil. El detalle de llamadas es una copia impresa de los números de todas las llamadas entrantes y salientes, que indica la duración de las llamadas y su costo, que utilizan los operadores, por ejemplo, para facturar a los suscriptores. A partir de estos datos podemos sacar una conclusión sobre las actividades actuales del suscriptor, su área de interés y su círculo de conocidos. En el comunicado de prensa de la Dirección "K" del Ministerio del Interior (en adelante Ministerio del Interior) se aclara que dicha información le cuesta al cliente 500 dólares.

Los empleados de la empresa VimpelCom, al descubrir este sitio, recopilaron de forma independiente pruebas de las actividades delictivas del sitio y transfirieron el caso al Ministerio del Interior. Los empleados del Ministerio del Interior abrieron una causa penal y, junto con la empresa VimpelCom, establecieron la identidad de los organizadores de este negocio criminal. Y el 18 de octubre de 2004, el principal sospechoso 1 fue detenido con las manos en la masa.

Además, el 26 de noviembre de 2004 fueron detenidos los seis sospechosos restantes, entre ellos tres empleados del servicio de abonados de la propia empresa VimpelCom. Durante la investigación resultó que el sitio fue creado por un ex alumno de la Universidad Estatal de Moscú que no trabajaba para esta empresa.

Los trámites sobre este incidente fueron posibles gracias a la sentencia del Tribunal Constitucional de 2003, que reconoció que los datos de las llamadas contenían el secreto de las conversaciones telefónicas, protegido por la ley.

Oportunidades internas

Dos de los empleados de VimpelCom identificados entre los participantes en el incidente trabajaban como cajeros en la empresa, y el tercero era un ex empleado y trabajaba en el mercado Mitinsky en el momento del crimen.

Trabajar como cajeros en la propia empresa indica que estos empleados tenían acceso directo a la información puesta a la venta en el sitio web www.sherlok.ru. Además, dado que un ex empleado de la empresa ya trabajaba en el mercado Mitinsky, se puede suponer que con el tiempo este mercado también podría convertirse en uno de los canales de distribución de esta información o cualquier otra información de las bases de datos de la empresa VimpelCom.

Consecuencias

Las principales consecuencias de este incidente para VimpelCom podrían ser un duro golpe a la reputación de la propia empresa y la pérdida de clientes. Sin embargo, este incidente se hizo público directamente gracias a las acciones activas de la propia empresa.

Además, hacer pública esta información podría tener un impacto negativo en los clientes de VimpelCom, ya que el detalle de las conversaciones permite sacar una conclusión sobre las actividades actuales del suscriptor, su área de interés y círculo de conocidos.

En marzo de 2005, el Tribunal de Distrito de Ostankino de Moscú condenó a los sospechosos, entre ellos tres empleados de la empresa VimpelCom, a diversas multas. Así, el organizador del grupo fue multado con 93.000 rublos. Sin embargo, el funcionamiento del sitio web www.sherlok.ru no se suspendió indefinidamente hasta el 1 de enero de 2008.

La mayor filtración de datos personales en la historia de Japón

anotación

En el verano de 2006 se produjo la mayor filtración de datos personales en la historia de Japón: un empleado del gigante de la impresión y la electrónica Dai Nippon Printing robó un disco con información privada de casi nueve millones de ciudadanos.

Descripción del incidente

La empresa japonesa Dai Nippon Printing, especializada en la producción de productos impresos, permitió la mayor filtración en la historia de su país. Hirofumi Yokoyama, un ex empleado de uno de los contratistas de la empresa, copió datos personales de los clientes de la empresa en un disco duro móvil y los robó. Un total de 8,64 millones de personas estaban en riesgo porque la información robada incluía nombres, direcciones, números de teléfono y números de tarjetas de crédito. La información robada incluía información de clientes de 43 empresas diferentes, como 1.504.857 clientes de American Home Assurance, 581.293 clientes de Aeon Co y 439.222 clientes de NTT Finance.

Después del robo de esta información, Hirofumi abrió el comercio de información privada en porciones de 100.000 registros. Gracias a unos ingresos estables, el informante incluso dejó su trabajo permanente. En el momento de su arresto, Hirofumi había logrado vender los datos de 150.000 clientes de las mayores firmas de crédito a un grupo de estafadores especializados en compras en línea. Además, algunos de los datos ya se han utilizado para fraudes con tarjetas de crédito.

Más de la mitad de las organizaciones cuyos datos de clientes fueron robados ni siquiera fueron advertidas sobre la filtración de información.

Consecuencias

Como resultado de este incidente, las pérdidas de los ciudadanos que sufrieron debido al fraude con tarjetas de crédito, que sólo fue posible gracias a esta filtración, ascendieron a varios millones de dólares. En total, los clientes de 43 empresas diferentes se vieron afectados, incluidas Toyota Motor Corp., American Home Assurance, Aeon Co y NTT Finance. Sin embargo, más de la mitad de las organizaciones ni siquiera fueron advertidas sobre la filtración.

En 2003, Japón aprobó la Ley de Protección de Información Personal de 2003 (PIPA), pero los fiscales no pudieron aplicarla en el juicio real del caso a principios de 2007. La fiscalía no pudo acusar al informante de violar la PIPA. Sólo se le acusa de robar un disco duro valorado en 200 dólares.

No apreciado. Hacker de Zaporozhye contra un banco ucraniano

anotación

El ex administrador de sistemas de uno de los grandes bancos de Ucrania transfirió alrededor de 5 millones de grivnas a través del banco donde trabajaba anteriormente desde la cuenta de la aduana regional a la cuenta de una inexistente empresa en quiebra de Dnepropetrovsk.

Descripción del incidente

Su carrera como administrador de sistemas comenzó después de graduarse de la escuela técnica y fue contratado por uno de los grandes bancos de Ucrania en el departamento de software y hardware. Después de un tiempo, la dirección se dio cuenta de su talento y decidió que sería más útil para el banco como jefe de departamento. Sin embargo, la llegada de una nueva dirección al banco también supuso cambios de personal. Se le pidió que dejara temporalmente su puesto. Pronto, la nueva dirección comenzó a formar su equipo, pero su talento resultó no ser reclamado y le ofrecieron el inexistente puesto de subjefe, pero en otro departamento. Como resultado de tales cambios de personal, comenzó a hacer algo completamente diferente de lo que mejor conocía.

El administrador del sistema no pudo soportar esta actitud de gestión hacia sí mismo y renunció por su propia voluntad. Sin embargo, lo perseguía su propio orgullo y resentimiento hacia la gerencia, además, quería demostrar que era el mejor en su negocio y regresar al departamento donde comenzó su carrera.

Después de dimitir, el ex administrador del sistema decidió devolver el interés de la antigua dirección a su persona utilizando las imperfecciones del sistema "Banco-Cliente" utilizado en casi todos los bancos de Ucrania 2 . El plan del administrador del sistema era que decidió desarrollar su propio programa de seguridad y ofrecerlo al banco, regresando a su anterior lugar de trabajo. La implementación del plan consistió en penetrar el sistema Banco-Cliente y realizar cambios mínimos en él. Todo el cálculo se basó en el hecho de que el banco habría descubierto un hackeo del sistema.

Para penetrar en el sistema especificado, el ex administrador del sistema utilizó contraseñas y códigos que aprendió mientras trabajaba con este sistema. Toda la demás información necesaria para la piratería se obtuvo de varios sitios de piratas informáticos, donde se describieron en detalle varios casos de piratería de redes informáticas, técnicas de piratería y todo el software necesario para la piratería.

Habiendo creado una laguna en el sistema, el ex administrador del sistema penetraba periódicamente en el sistema informático del banco y dejaba varios carteles en él, tratando de llamar la atención sobre los hechos de la piratería. Los especialistas del banco debían detectar el hackeo y hacer sonar la alarma, pero, para su sorpresa, nadie se dio cuenta de la penetración en el sistema.

Entonces el administrador del sistema decidió cambiar su plan, haciéndole ajustes que no podían pasar desapercibidos. Decidió falsificar una orden de pago y utilizarla para transferir una gran cantidad a través del sistema informático del banco. Utilizando un ordenador portátil y un teléfono móvil con módem incorporado, el administrador del sistema penetró en el sistema informático del banco unas 30 veces: revisó documentos, cuentas de clientes, flujos de efectivo, en busca de clientes adecuados. Como tales clientes eligió las aduanas regionales y una empresa en quiebra de Dnepropetrovsk.

Una vez más tuvo acceso al sistema del banco, creó una orden de pago en la que retiró 5 millones de jrivnia de la cuenta personal de la aduana regional y los transfirió a través del banco a la cuenta de la empresa en quiebra. Además, cometió deliberadamente varios errores en el “pago”, lo que a su vez debería haber ayudado a atraer la atención de los especialistas bancarios. Sin embargo, ni siquiera estos hechos fueron notados por los especialistas bancarios que atienden el sistema Banco-Cliente y transfirieron tranquilamente 5 millones de jrivnia a la cuenta de una empresa desaparecida.

En realidad, el administrador del sistema esperaba que los fondos no fueran transferidos, que el hecho de la piratería se descubriera antes de que se transfirieran los fondos, pero en la práctica todo resultó diferente y se convirtió en un delincuente y su transferencia falsa se convirtió en robo.

El hecho de la piratería y el robo de fondos a una escala especialmente grande se descubrió sólo unas horas después de la transferencia, cuando los empleados del banco llamaron a la aduana para confirmar la transferencia. Pero informaron que nadie había transferido tal cantidad. El dinero fue devuelto urgentemente al banco y se abrió una causa penal en la fiscalía de la región de Zaporozhye.

Consecuencias

El banco no sufrió pérdidas, ya que el dinero fue devuelto al propietario y el sistema informático sufrió daños mínimos, por lo que la dirección del banco rechazó cualquier reclamación contra el ex administrador del sistema.

En 2004, por decreto del Presidente de Ucrania, se reforzó la responsabilidad penal por delitos informáticos: multas de 600 a 1.000 mínimos libres de impuestos y penas de prisión de 3 a 6 años. Sin embargo, el exadministrador del sistema cometió un delito antes de que entrara en vigor el decreto presidencial.

A principios de 2005 se llevó a cabo un juicio contra el administrador del sistema. Fue acusado de cometer un delito previsto en la parte 2 del artículo 361 del Código Penal de Ucrania (intervención ilegal en el funcionamiento de sistemas informáticos que causan daños) y en virtud de la parte 5 del artículo 185 (robo cometido a gran escala). Pero como la dirección del banco se negó a presentar reclamaciones contra él, se le retiró el cargo de robo y la parte 2 del artículo 361 se cambió a la parte 1: interferencia ilegal en el funcionamiento de los sistemas informáticos.

Comercio incontrolado en el banco Societe Generale

anotación

El 24 de enero de 2008, Société Générale anunció una pérdida de 4.900 millones de euros debido a las maquinaciones de su comerciante Jerome Kerviel. Como demostró una investigación interna, durante varios años el comerciante abrió posiciones por encima del límite en futuros sobre índices bursátiles europeos. El importe total de las posiciones abiertas ascendió a 50 mil millones de euros.

Descripción del incidente

Desde julio de 2006 hasta septiembre de 2007, el sistema informático de control interno advirtió sobre posibles violaciones 75 veces (es decir, cuántas veces Jerome Kerviel realizó transacciones no autorizadas o sus posiciones excedieron el límite permitido). Los empleados del departamento de seguimiento de riesgos del banco no realizaron controles detallados de estas advertencias.

Kerviel comenzó a experimentar con operaciones no autorizadas en 2005. Luego tomó una posición corta en acciones de Allianz, esperando que el mercado cayera. Pronto el mercado cayó realmente (después de los ataques terroristas en Londres), así se ganaron los primeros 500.000 euros. Más tarde, Kerviel contó a los investigadores sus sentimientos sobre su primer éxito: “Ya sabía cómo cerrar mi posición y estaba orgulloso del resultado, pero al mismo tiempo estaba sorprendido. El éxito me hizo continuar, fue como una bola de nieve... En julio de 2007, propuse tomar una posición corta en previsión de una caída del mercado, pero no recibí el apoyo de mi gerente. Mi pronóstico se cumplió y obtuvimos ganancias, esta vez fue completamente legal. Posteriormente, seguí realizando tales operaciones en el mercado, ya sea con el consentimiento de mis superiores o en ausencia de su objeción explícita... El 31 de diciembre de 2007, mi beneficio alcanzó los 1,4 mil millones de euros. En ese momento no sabía cómo declarar esto a mi banco, ya que era una cantidad muy grande que no estaba declarada en ningún lado. Estaba feliz y orgulloso, pero no sabía cómo explicarle a mi dirección la recepción de este dinero y no incurrir en sospechas de realizar transacciones no autorizadas. Por lo tanto, decidí ocultar mis ganancias y realizar la operación ficticia opuesta…”

De hecho, a principios de enero de ese año, Jerome Kerviel volvió a entrar en juego con contratos de futuros sobre los tres índices Euro Stoxx 50, DAX y FTSE, que le ayudaron a ganarle al mercado a finales de 2007 (aunque prefirió quedarse corto en el mercado). tiempo). Según los cálculos, en vísperas del 11 de enero, su cartera contenía 707,9 mil futuros (cada uno con un valor de 42,4 mil euros) sobre el Euro Stoxx 50, 93,3 mil futuros (192,8 mil euros por pieza) sobre el DAX y 24,2 mil futuros (82,7 mil euros). por 1 contrato) para el índice FTSE. En total, la posición especulativa de Kerviel equivalía a 50 mil millones de euros, es decir, superaba el valor del banco en el que trabajaba.

Conociendo el momento de los controles, abrió una posición de cobertura ficticia en el momento adecuado, que luego cerró. Como resultado, los revisores nunca vieron una sola posición que pudiera considerarse arriesgada. No deberían alarmarse por las grandes cantidades de transacciones, que son bastante comunes en el mercado de futuros sobre índices. Lo decepcionaron las transacciones ficticias realizadas desde las cuentas de los clientes del banco. El uso de cuentas de varios clientes bancarios no generó problemas visibles para los controladores. Sin embargo, con el tiempo, Kerviel comenzó a utilizar las cuentas de los mismos clientes, lo que provocó que se observara una actividad "anormal" en estas cuentas y, a su vez, atrajo la atención de los controladores. Este fue el final de la estafa. Resultó que el socio de Kerviel en el acuerdo multimillonario era un gran banco alemán, que supuestamente confirmó la astronómica transacción por correo electrónico. Sin embargo, la confirmación electrónica levantó sospechas entre los inspectores y se creó una comisión en Societe Generale para verificarlas. El 19 de enero, en respuesta a una solicitud, el banco alemán no reconoció esta transacción, tras lo cual el comerciante accedió a confesar.

Cuando fue posible conocer el tamaño astronómico de la posición especulativa, el director general y presidente del consejo de administración de Société Générale, Daniel Bouton, anunció su intención de cerrar la posición de riesgo abierta por Kerviel. Esto duró dos días y provocó pérdidas de 4.900 millones de euros.

Oportunidades internas

Jerome Kerviel trabajó durante cinco años en el llamado back office del banco, es decir, en un departamento que no realiza transacciones directamente. Se ocupa únicamente de la contabilidad, ejecución y registro de transacciones y monitorea a los comerciantes. Esta actividad nos permitió comprender las características de los sistemas de control del banco.

En 2005, Kerviel fue ascendido. Se convirtió en un verdadero comerciante. Las responsabilidades inmediatas del joven incluían operaciones básicas para minimizar riesgos. Jerome Kerviel, que trabajaba en el mercado de futuros sobre índices bursátiles europeos, tenía que controlar cómo cambiaba la cartera de inversiones del banco. Y su tarea principal, como explicó un representante de Societe Generale, era reducir los riesgos jugando en la dirección opuesta: "En términos generales, como el banco apostaba al rojo, tuvo que apostar al negro". Como todos los traders junior, Kerviel tenía un límite que no podía superar y que era supervisado por sus antiguos colegas en el back office. Societe Generale tenía varias capas de protección; por ejemplo, los operadores sólo podían abrir posiciones desde la computadora de su trabajo. Todos los datos sobre las posiciones abiertas se transmitieron automáticamente en tiempo real al back office. Pero, como suele decirse, el mejor cazador furtivo es un ex guardabosques. Y el banco cometió un error imperdonable al poner al ex guardabosques en la posición de cazador. A Jerome Kerviel, que tenía casi cinco años de experiencia en el seguimiento de comerciantes, no le resultó difícil eludir este sistema. Conocía las contraseñas de otras personas, sabía cuándo se realizaban los cheques en el banco y conocía bien la tecnología de la información.

Causas

Si Kerviel estuvo involucrado en fraude, no fue con el propósito de enriquecimiento personal. Así lo afirman sus abogados, y los representantes del banco también lo admiten, calificando de irracionales las acciones de Kerviel. El propio Kerviel dice que actuó únicamente en interés del banco y sólo quería demostrar su talento como comerciante.

Consecuencias

A finales de 2007, sus actividades aportaron al banco unos beneficios de unos 2.000 millones de euros. En cualquier caso, esto es lo que dice el propio Kerviel, afirmando que la dirección del banco probablemente sabía lo que estaba haciendo, pero prefirió hacer la vista gorda mientras fuera rentable.

El cierre de la posición de riesgo abierta por Kerviel supuso unas pérdidas de 4.900 millones de euros.

En mayo de 2008, Daniel Bouton dejó el cargo de director general de Société Générale y fue sustituido en este cargo por Frédéric Oudea. Un año después, se vio obligado a dimitir de su cargo de presidente del consejo de administración del banco. El motivo de su salida fueron duras críticas de la prensa: Bouton fue acusado de que los altos directivos del banco bajo su control fomentaban transacciones financieras riesgosas realizadas por los empleados del banco.

A pesar del apoyo de la junta directiva, la presión sobre Bouton aumentó. Los accionistas del banco y muchos políticos franceses exigieron su dimisión. El presidente francés, Nicolas Sarkozy, también pidió la dimisión de Daniel Bouton después de que se conociera que, en el año y medio anterior al escándalo, el sistema informático de control interno de Société Générale emitió una advertencia 75 veces, es decir, cada vez que Jerome Kerviel realizaba transacciones no autorizadas, posibles violaciones. .

Inmediatamente después de que se descubrieron las pérdidas, Societe Generale creó una comisión especial para investigar las acciones del comerciante, que incluía miembros independientes de la junta directiva del banco y auditores PricewaterhouseCoopers. La comisión concluyó que el sistema de control interno del banco no era lo suficientemente eficaz. Esto hizo que el banco no pudiera evitar un fraude a tan gran escala. El informe afirma que "el personal del banco no realizó controles sistemáticos" de las actividades del comerciante y que el propio banco no tenía "un sistema de control que pudiera prevenir el fraude".

El informe sobre los resultados de la auditoría del comerciante indica que, tras los resultados de la investigación, se tomó la decisión de "reforzar significativamente el procedimiento de supervisión interna de las actividades de los empleados de Societe Generale". Esto se hará mediante una organización más estricta del trabajo de las distintas divisiones del banco y la coordinación de su interacción. También se tomarán medidas para rastrear y personalizar las operaciones comerciales de los empleados bancarios "reforzando el sistema de seguridad informática y desarrollando soluciones de alta tecnología para la identificación personal (biometría)".

4.2.2. Tipología de incidentes La generalización de la práctica mundial nos permite identificar los siguientes tipos de incidentes de seguridad de la información que involucran al personal de la organización: - divulgación de información oficial; - falsificación de informes; - robo de activos financieros y materiales; - sabotaje