No edites los borradores de otros escritores sin su permiso.
Ítem #: sepa dios
Clasificación del objeto: Euclid
Procedimientos Especiales de Contención: Los dispositivos recuperados durante el incidente de descubrimiento1 se encuentran actualmente en el Sector de Anomalías Informáticas del Sitio-██, donde deben permanecer almacenados. En caso de realizarse pruebas sobre los objetos y las instancias de SCP-ES-XXX que los habitan, se deben depositar todos los aparatos informáticos2 externos en los puntos designados fuera de la cámara de contención. El uso de dispositivos análogos, debido a su incapacidad para hospedar instancias de SCP-ES-XXX, está permitido.
La cámara de contención de SCP-ES-XXX almacena los cinco objetos originalmente recuperados durante el incidente de descubrimiento, junto con los dispositivos de alimentación y periféricos con los que contaban al momento del involucramiento de la Fundación en el evento. La habitación posee energía para permitir el continuo funcionamiento de los electrónicos. No posee ni debe poseer en ningún caso acceso a redes de internet conectadas a cualquier dispositivo fuera de la cámara. Para este fin, las paredes están equipadas con capas de concreto alternadas con placas de aluminio con el propósito de evitar cualquier tipo de conexión accidental. Se permite, en caso de necesitarse, el establecimiento de una red local entre los dispositivos contenidos.
En caso de que se produzca el ingreso de un dispositivo informático externo, sea por motivo de una prueba o no, el dispositivo debe asumirse huésped de una incubación de SCP-ES-XXX, por lo que este no puede retirarse de la cámara de contención, debiéndose proceder a su eliminación dentro de un periodo máximo de un mes luego de la exposición.
Deben, al menos una vez cada dos semanas, realizarse tareas de mantenimiento con dos sujetos Clase-D para sustentar a las instancias de SCP-ES-XXX hospedadas en cada dispositivo de forma alternada. Durante estas pruebas, debe imitarse el uso cotidiano de los dispositivos, recomendándose la simulación de tareas de oficina regulares, aunque se permiten desviaciones de este modelo con previa aprobación a través de un Permiso de Experimento firmado por el Jefe de Investigación asignado al Sector de Anomalías Informáticas. Estas pruebas deben extenderse por al menos 2 horas. También se permite a los Clase-D el uso de programas recreativos instalados en los dispositivos. Durante tareas de mantenimiento programadas, se debe reportar cualquier desviación de comportamiento esperado de las entidades residentes en los dispositivos.
NOTA: ACTUALIZAR LUEGO CON LAS MEDIDAS DE CONTENCIÓN AGREGADAS LUEGO DEL INCIDENTE B!!!!!!!!! NO OLVIDARSE!!!!!!!! DESPUES BORRÁ ESTO!!!!!!!!!!!!!!!!!!
Descripción: SCP-ES-XXX es un grupo de entidades energéticas capaces de parasitar y afectar dispositivos informáticos y sus periféricos, pareciendo extraer sustento de las emociones negativas, principalmente frustración, causadas a través de la provocación de desperfectos en los sistemas digitales de los aparatos en los que se hospedan. Dichos desperfectos nunca han demostrado estar causados directamente por alguna manipulación de los componentes físicos de los aparatos, por lo que se presume que las instancias de SCP-ES-XXX tienen la capacidad de afectar de forma directa los flujos de datos de una computadora.
Las instancias de SCP-ES-XXX han demostrado seguir un patrón de incubación, crecimiento, reproducción y muerte semejantes a los de seres vivos no anómalos. Este ciclo consta de cuatro etapas, detalladas a continuación:
- Incubación: Producto de la reproducción de una instancia de SCP-ES-XXX. Durante este periodo, que dura alrededor de dos semanas, se registra, en los dispositivos huésped, un consumo de recursos de memoria excesivo aún cuando no existe una carga de procesos en ejecución que justifique dicho evento. Al terminar el periodo de incubación, el consumo de memoria vuelve a los niveles anteriores a este, variando adecuadamente según los procesos activos y el estado de los componentes.
- Crecimiento: Terminada la incubación, existe un periodo de latencia durante el cual no se experimentan anomalías en el comportamiento del equipo, el cual dura alrededor de cinco días. Pasado este tiempo, se comienzan a experimentar, nuevamente, anomalías en el funcionamiento de la computadora, generalmente siendo estos problemas que causan inconvenientes menores durante el uso cotidiano (se especifican algunos de estos problemas en el reporte de errores correspondiente al Registro de Experimento 11). DESARROLLAR EXPERIMENTO 11 EN UN ADDENDUM. Progresivamente, las instancias de SCP-ES-XXX parecen aumentar el alcance y gravedad que tienen sus alteraciones, enfocándolos al uso dado por el usuario al dispositivo, lo que demuestra una capacidad de adaptación a través del aprendizaje, sugiriendo un cierto nivel de inteligencia en las entidades.
- Reproducción: Pasado alrededor de un mes luego del nacimiento de una instancia de SCP-ES-XXX, esta adquiere la capacidad de multiplicarse, escogiendo invariablemente aquellos dispositivos que registren más uso en la proximidad inmediata. La reproducción de un SCP-ES-XXX parece estar limitada por la distancia y el acceso físico que la instancia tenga al dispositivo al cual pretende infectar, por lo que cualquier barrera sólida es suficiente para impedir una incubación, aunque es de notar que la existencia de huecos mayores a 1cm en el material utilizado como barrera parecen ser suficientes para inutilizar esta medida. La distancia máxima a la que se ha mostrado capacidad de generar nuevos nidos, hasta el momento, han sido 30 metros.
- Muerte: La muerte de una instancia de SCP-ES-XXX se da luego de un periodo prolongado sin utilizar dispositivo huésped. Este proceso se extiende normalmente a lo largo de un mes y puede por si mismo separarse en una etapa de hambruna y letargo. Durante el periodo de hambruna, que se da tras alrededor de dos semanas posteriores al cese del uso del dispositivo, el SCP-ES-XXX parece aumentar su actividad, incluso cuando no existe la posibilidad de afectar a un usuario. Esta actividad se caracteriza por llegar a ser excepcionalmente destructiva, pudiendo, en casos extremos, acabar con la inutilización del aparato. En caso de no ocurrir esto, pasada entre tres y cuatro semanas desde la última alimentación, comienza la etapa de letargo, donde, en contraste con la hambruna, la actividad de la instancia de SCP-ES-XXX disminuye exponencialmente, solamente pudiendo registrarse desperfectos mínimos, siendo generalmente menos intensos que una instancia juvenil. Luego de alrededor de un mes luego del último uso, todas las actividades de la instancia de SCP-ES-XXX cesan y no vuelven a retomarse, a menos que exista un dispositivo huésped cercano que permita una nueva incubación, lo cual da origen a una entidad presumiblemente distinta de la anterior. ESTARÍA BUENO ACOMPAÑAR ESTO CON UN REGISTRO DE EXPERIMENTO.
Cada instancia de SCP-ES-XXX parece tener la capacidad de afectar un único dispositivo a la vez, y parecen incapaces o, en su defecto, no tener deseos de abandonar el aparato huésped, incluso si esto termina en su muerte por inanición.
A pesar del profundo entendimiento que se tiene del ciclo de vida de una instancia de SCP-ES-XXX, se desconoce aún la causa del evento de anidación que provocó el Incidente SCP-ES-XXX-A, y se investiga activamente la posibilidad de que este haya sido creado por algún Grupo de Interés.
Reporte de Incidente de Descubrimiento
SCP-ES-XXX-A
Introducción
El descubrimiento de SCP-ES-XXX ocurrió durante el 15 de Junio del año 202█, luego de un Reporte de Urgencia generado por el SUMA (Sistema Unificado de Monitoreo Automatizado) utilizado por la unidad Kappa-10 "Skynet" de las Fuerzas de Tareas Móviles. El reporte indicaba un aumento generalizado de la creación de tickets de asistencia técnica en ███████ █████, un barrio suburbano ubicado en el condado de San Bernardino, California.
Es bajo este contexto que se lleva a cabo el ingreso de la unidad a ███████ █████, donde se inició una investigación preliminar del evento para determinar su naturaleza anómala y trazar un plan de contención adecuado.
Tras el análisis y tras concluir que el evento correspondía a un fenómeno anómalo, la unidad comienza, bajo el protocolo usual de contención anomalías informáticas, una cuarentena del barrio, impidiendo la salida de personas, conjuntamente con un bloqueo de servicio de internet a la zona, bajo la tapadera del choque de un camión de transporte de químicos nocivos en las inmediaciones.
Finalizada la clasificación y proceso de contención del SCP-ES-XXX se realiza, a través del análisis de tickets de soporte técnico y entrevistas con locales, el presente informe de incidente, designado SCP-ES-XXX.
Nota: Las entrevistas realizadas se hicieron bajo el nombre de tapadera de Secure Computation Providers LLC, un contratista de seguridad informática realizando una investigación de lo ocurrido por orden del gobierno de California.
Entrevistado: ██████ Patai
Entrevistador: Agente █████ Ross
Prefacio: Durante el 16 de Junio de 202█, la unidad Kappa-10 realiza entrevistas conjuntas a diversos afectados por el incidente, con el fin de esclarecer el orden de eventos previos al involucramiento de la Fundación. Para esto, se le pidió su presencia a ██████ Patai, quien ejercía el puesto de Jefe de Seguridad Informática en ██████████.
<Comienzo de Registro>Agente Ross: Bien, comenzamos a grabar. Para el registro, ¿podría por favor describir que actividades desarrolla en su puesto?
Ing. Patai: Por supuesto. Eh, como Jefe de Seguridad Informática, mis tareas actualmente están más centradas en gestión, administración y coordinación que tareas operativas. Generalmente estoy atento a logs de seguridad, coordinando parcheos de vulnerabilidades, preparando auditorías, hablando con mi equipo. Ya sabe, revisando que todo fluya según lo esperado.
Agente Ross: Supongo que también es responsable de la respuesta a incidentes, ¿correcto?
Ing. Patai: En principio, sí. Es lo que dice la descripción de mi puesto. [Patai ríe un momento] Pero, a día de hoy, la mayor parte de "incidentes" son detenidos antes de que ocurran. Los IPS, WAFs y IAs de comportamiento que integramos actualmente me dejan un poco obsoleto en ese sentido. Claro, cada tanto, algún ataque DDoS particularmente bien pensado supera las barreras de prevención, pero inmediatamente se activan los IDS y SIEM, se corta el acceso a los atacantes y, antes de que cerremos el día, ya sabemos de donde provino, se eleva el reporte pertinente, y ya no es mi problema. Bueno, si en algún momento lo fue.
Agente Ross: Y, sin embargo, en los últimos meses, su centro de datos pasó de ser perfectamente funcional, a tener que cesar sus operaciones completamente.
Ing. Patai: Temporalmente, no completamente. Pero sí, es cierto. Supongo que es por eso que vinieron ustedes, ¿no?
Agente Ross: Correcto. Y por eso necesito su ayuda para entender lo que ocurrió. Nos hicimos con varios reportes de errores que datan desde Marzo, pero me gustaría saber, directamente de usted, como se desarrollaron estos eventos.
Ing. Patai: Bueno, si la memoria no me falla, esto comenzó a mediados de Marzo. El 13, creo. Cinco servidores aumentaron su consumo de RAM de forma casi simultanea. El IDS no emitió reportes, así que comenzamos a revisar procesos activos, microservicios, lo usual. Pero nada saltó a la vista. Ningún proceso consumía más de lo indicado, ningún microservicio producía algún memory leak, nada evidente. Tampoco habían conexiones anómalas, así que pude descartar un ataque externo por el momento. En retrospectiva, tal vez fue un error ser tan apresurado.
Agente Ross: ¿Creyó que era un fallo en el hardware?
Ing. Patai: Sí, pensé que, a lo mejor, alguna variación en la corriente eléctrica o algo por el estilo había provocado daños en las unidades de memoria de esos servidores en particular. Llené un ticket de mantenimiento. Esas cosas tardan, no podemos simplemente desconectar un rack de servidores. Y, por otro lado, tenemos cierto margen en el que podemos poner a trabajar de más los demás servidores mientras solucionamos los problemas sin afectar el servicio. El próximo mantenimiento era… el 28, me parece.
Agente Ross: Y los servidores permanecieron operativos durante ese tiempo, ¿es así?
Ing. Patai: Así fue. Pero, unos tres días antes, los servidores volvieron a funcionar normalmente, como si no hubiera pasado nada.
Agente Ross: ¿Así sin más? Tal vez hubo un reinicio, una actualización. ¿Un pulleo a un repositorio?
Ing. Patai: Fueron las primeras cosas que revisé. Na-da. Un acto divino. Cancelamos la desconexión, nos confiamos, y no pensamos que pudiéramos averiguar demasiado en las seis horas de mantenimiento. [Patai ríe brevemente, luego suspira] Un chico de mantenimiento hizo un chiste sobre eso. Dijo que eran grémlins, que nos querían molestar. Fue gracioso.<Fin de Registro>
5 de Abril, 202█: Uno de los servidores afectados se apaga repentinamente, lo que provoca una caída en el servicio para al menos 500 usuarios. Los empleados reportan dificultades a la hora de encender el dispositivo, lo que derivó en cinco horas hasta la normalización del servicio. Se emite un nuevo ticket de soporte técnico pidiendo la desconexión y reparación del equipo.
10 de Abril, 202█: El servidor que falló el día anterior es desconectado y retirado. Se utiliza un equipo de reemplazo de menor capacidad operativa para cubrir al retirado. Esto provoca un aumento en la carga operativa de los demás servidores del centro.
13 de Abril, 202█: 153 clientes, tanto corporativos como particulares, quienes habían contratado un servicio de almacenamiento de datos en la nube por parte de ██████████, reportan corrupciones generalizadas en la información guardada en los servidores. Parte de los datos se logran recuperar a través de respaldos, pero se pierden aproximadamente 50 terabytes de la información almacenada. Se comienza una investigación interna para determinar las causas de la corrupción.
Entre el 14 y el 23 de Abril, se reportaron doce errores distintos provenientes de todos los servidores afectados que aún no habían sido desconectados. Estos fallos mostraban un claro aumento en la seriedad y alcance, derivando en caídas de servicio que duraban entre una y tres horas, afectando a un gran número de abonados.
24 de Abril, 202█: Los 4 servidores afectados restantes fallan al mismo tiempo. La baja de servicio provocada afectó a un mínimo de diez mil usuarios durante ocho horas. Los cuatro equipos son marcados para desconexión y reparación. Ante la falta de equipos apropiados para el reemplazo, se indica que estos deben seguir en funcionamiento hasta que sea posible reemplazarlos, dando un tiempo de espera de 15 días.
26 de Abril, 202█: Un grupo de 28 estudiantes de una secundaria local realizan una excursión al centro de datos, permitiéndosele a los alumnos ingresar a la sala de servidores acompañados de un guía. Se les dio permiso de entrar con sus teléfonos celulares, siempre que estos permaneciesen apagados durante la excursión. Durante la excursión, se dieron distintos eventos informáticos anómalos, incluyendo el envío de un mensaje de error, no registrado en la documentación, a las computadoras utilizadas para el control de los sistemas del centro. El mensaje de error reportado mostraba el siguiente mensaje:
servidor detenido, ¡favor de respetar la ausencia por maternidad!
Los servidores previamente afectados se bloquearon hasta la desaparición del mensaje 21 minutos luego. Pasado el evento anómalo, se reportó un aumento repentino en el consumo de RAM en el resto de los servidores del cuarto donde se encontraban.
A partir del 27 de Abril, los alumnos que visitaron el centro de procesamiento reportaron, al ser cuestionados, haber experimentado una ralentización generalizada de sus dispositivos.
30 de Abril, 202█: Los cuatro servidores afectados sufren un borrado de archivos correspondientes a subsistemas indispensables para mantener los servicios a clientes entrantes. Esto, efectivamente, los dejó inutilizables durante siete horas, al fallar también los intentos por recuperar los archivos desde el repositorio remoto. Debido al aumento de consumo de memoria de los demás servidores, esto provocó una sobrecarga que resultó en la caída completa del servicio para todos los usuarios dependientes de estas instalaciones. Como medida de emergencia, se da la orden de redistribuir las conexiones destinadas a este CPD a otros en distintas zonas cercanas.
3 de Mayo, 202█: Una franquicia local de la tienda venta y reparación de dispositivos electrónicos ████ ███ recibe, a lo largo del día, cinco clientes que reportan, en todos lo casos, un funcionamiento anormalmente lento de sus celulares. Los tickets de reparación generados revelan que los clientes fueron los jóvenes que visitaron el CPD la semana anterior.
Entre el 4 y el 12 de Mayo, se ingresan diez dispositivos más a reparación. Varios de los clientes retiraron sus celulares luego de que los técnicos de la franquicia no pudieran determinar la causa del problema.
13 de Mayo, 202█: Durante una partida de un juego móvil online, un estudiante entrevistado reportó haber perdido momentáneamente el control del personaje que controlaba. El evento duró alrededor de 30 segundos y fue notificado por el sistema de reporte de bugs del propio videojuego.
17 de Mayo, 202█: El celular afectado de un estudiante comenzó a reproducir, durante una clase, música al volumen máximo. Al querer apagarla, el dispositivo no respondía, requiriendo su reinicio.
IDEAS DE SITUACIONES ANÓMALAS CHISTOSAS:
- Los gremlins crean una cantidad absurda de hilos de procesamiento para "tejerse bufandas". Esto claramente colapsa el sistema.
- Una interpretación muy literal de lo que es una clase padre e hija, provocando comportamientos inesperados.
- Kernel = semilla = pochoclos = gracioso?
- import antigravity (o alguna otra referencia a xkcd)
- Los gremlins acceden a los repositorios de código internos de la fundación (SGitP?), chaos ensues.
- Los gremlins, de cierto modo, terminan reflejando ciertas cualidades de los usuarios principales de los dispositivos que infectan.