Incidente de Ataque DDoS em Servidores DNS

Vista previa del material en texto

IT - Governence | Equipos
	
 INSTITUTO POLITÉCNICO NACIONAL
 ESCUELA SUPERIOR DE CÓMPUTO
Actividad 13: Problemario NIST
Maestra: Guzmán Flores Jessie Paulina. Materia: IT Governence. Fecha de entrega: domingo, 08/01/23. Grupo: 3CM13.
Escenario 1	3
Escenario 2	11
Escenario 3	21
Escenario 4	32
Escenario 5	41
Escenario 6	43
Escenario 7	44
Escenario 8	46
Escenario 9	48
Escenario 10	53
Escenario 1
Huerta Camarena Max
Rodríguez Mireles Emilio
Zacarías Pineda Esmeralda
“Un sábado por la tarde, los usuarios externos comienzan a tener problemas para acceder a los sitios web públicos de la organización. Durante la siguiente hora, el problema empeora hasta el punto en que casi todos los intentos de acceso fallan. Mientras tanto, un miembro del personal de redes de la organización responde a las alertas de un enrutador fronterizo de Internet y determina que el ancho de banda de Internet de la organización está siendo consumido por un volumen inusualmente grande de paquetes del Protocolo de datagramas de usuario (UDP) hacia y desde los servidores DNS públicos de la organización. El análisis del tráfico muestra que los servidores DNS están recibiendo grandes volúmenes de solicitudes de una sola dirección IP externa. Además, todas las solicitudes DNS de esa dirección provienen del mismo puerto de origen.”
Preparación
¿Consideraría la organización esta actividad como un incidente? Si es así, ¿cuál de las políticas de la organización viola esta actividad?
Aquí el servidor se ve afectado por el ataque DDoS de inundación de Ping (ICMP). El Protocolo de mensajes de control de Internet (ICMP) se utiliza en este ataque. El atacante envía una solicitud ICMP al servidor para una conectividad correcta y una comunicación adecuada. Esta solicitud requiere un gran ancho de banda. Luego, al enviar grandes volúmenes de solicitudes, el servidor se bloquea para responder a las solicitudes, lo que finalmente conduce a la ruptura del sitio web. Todos los sitios web públicos de la organización son atacados por algunos piratas informáticos que pueden ser los enemigos de la organización. Intencionalmente taget el servidor e intentan bloquearlo. Aquí lo que realmente sucede es que el atacante está negando el servicio solicitado por los usuarios genuinos. Ocupan el servidor enviando solicitudes por medio de paquetes UDP. Esto literalmente afecta el ancho de banda de Internet de la organización y conduce a la caída del servidor.
¿Qué medidas existen para intentar evitar que ocurra este tipo de incidentes o limitar su impacto?
Para detener el tráfico lo antes posible, el método más preferible es ponerse en contacto con el proveedor de servicios de Internet (ISP) y solicitar bloquear el tráfico malicioso. Este es el primer paso. Configure un firewall fuerte que pueda ocultar la dirección IP de la organización de los atacantes y, finalmente, la configuración de una poderosa herramienta de control de tráfico será muy recomendable porque seguirá verificando si hay un amplio tráfico de red o no. Si hay organización puede tomar inmediatamente precauciones para superar o mitigar el ataque.
Detección y Análisis
¿Qué precursores del incidente, si los hay, podría detectar la organización? ¿Algún precursor haría que la organización tomara medidas antes de que ocurriera el incidente?
Al tener un ataque DoS, se tiene precursores, de saber que la seguridad de la organización no es confiable al 100%, se deben hacer un análisis del incidente, se debe hacer uso de los pasos 4,5,6,7 del marco para la mejora de la seguridad y evitar de forma más factible tener un ataque nuevamente.
¿Qué indicadores del incidente podría detectar la organización? ¿Qué indicadores harían que alguien pensara que podría haber ocurrido un incidente?
a) Entender el flujo lógico de un ataque DoS e identificar los componentes de la infraestructura afectados.
b) Determinar si se es el objetivo principal del ataque o una víctima colateral.
c) Revisar los archivos logs de servidores, ruteadores, firewalls, aplicaciones y cualquier otro recurso afectado.
d) Identificar qué aspectos del tráfico del ataque DoS se diferencia del tráfico benigno.
· Direcciones IP fuente, AS, etc.
· Puertos destino
· URLs
· Banderas de protocolos
¿Qué herramientas adicionales podrían ser necesarias para detectar este incidente en particular?
Ponerse en contacto con su ISP y asegúrese de que aplica las medidas correctivas:
· Filtración (si es posible a nivel Tier1 o 2) 
· Traffic-scrubbing/Sinkhole/Clean-pipe 
· Blackhole Routing
Si se han identificado los responsables del DoS, considere la posibilidad de involucrar a las fuerzas del orden. Esto debe realizarse bajo la dirección de los equipos ejecutivos y legales de la institución.
¿Cómo analizaría y validaría este incidente el equipo de respuesta a incidentes? ¿Qué personal estaría involucrado en el proceso de análisis y validación?
Se tendría que investigar si se recibió algún aviso previo al ataque y se analizaría si algún competidor quisiera o tendría algún motivo para amenazar a la institución, también se tendría que investigar al interior de la organización para ver si algún empleado haya realizado el ataque desde adentro o haya dado algunas claves para la ejecución del ataque, se tendría que realizar por medio del equipo de IT.
¿A qué personas y grupos dentro de la organización reportaría el equipo el incidente?
Se le hace el reporte del incidente al equipo de seguridad de la organización al igual se le debe hacer el reporte al proveedor del servidor para que aplique las medidas contra ataques de este tipo.
¿Cómo priorizaría el equipo el manejo de este incidente?
El equipo tendría que priorizar como muy alto el tema de un incidente como este ya que puede estar en riesgo toda la información de la organización, así como los clientes de la misma, se esperaría una pronta respuesta en contra del ataque debido a que en caso contrario la organización perdería mucho hablando económicamente como de información.
Contención, erradicación y recuperación
¿Qué estrategia debe tomar la organización para contener el incidente? ¿Por qué esta estrategia es preferible a otras?
La siguiente estrategia tendría que surgir de los siguientes puntos:
· Crear una whitelist de las IPs y protocolos que serán permitidos y priorizados durante el ataque.
· Diseñar una buena infraestructura de red sin un único punto de falla o cuello de botella. 
· Distribuir los servidores DNS y los servicios críticos (SMTP, etc.) a través de diferentes AS. 
· Reforzar la configuración de la red, sistemas operativos y aplicaciones que podrías servir como objetivo de ataques DoS.
· Crear una whitelist de las IPs y protocolos que serán permitidos y priorizados durante el ataque.
Se esperaría que con esta estrategia la información de la organización no se viera tan vulnerable mucho tiempo, esta estrategia es preferible a las demás debido que es el primer método de defensa o el método de defensa que se aplicaría de inmediato, esto para solo tener gente confiable de la organización dentro del sistema.
¿Qué podría suceder si el incidente no fuera contenido?
Lo que puede pasar si no se le hace frente al ataque, la organización podría en riesgo su información más sensible, así como la de sus usuarios, en caso de tener información bancaria de los mismos esta estaría en riesgo ya que quienes atacaron a la organización podrían ingresar a cualquier sitio restringido de la organización pudiendo extraer o inyectar cualquier información de la organización.
¿Qué herramientas adicionales podrían ser necesarias para responder a este incidente en particular?
Contención 
· Si es posible desactivar el servicio de los sitios WEB momentáneamente.
· Terminar las conexiones o procesos no deseados en los servidores de la organización para posteriormente revisar y cambiar las configuraciones TCP/IP.
· Cambiar los DNS del sitio WEB que está siendo atacado.
· Encaminar el trafico a un servicio dedepuración de trafico de cambios en las rutas o en los DNS.
Erradicación 
· Si el ataque proviene desde el ISP se tiene que poner en contacto con ellos para que tomen las medidas pertinentes.
· Intentar restringir el acceso a la IP que se tiene identificado como el atacante mediante el Firewall.
· Comunicarse con un CERT nacional y a la policía para que se tomen las medidas necesarias.
Recuperación
· Asegurarse que el ataque DDOS haya terminado.
· Asegurarse de que se haya restablecido el acceso a los servicios WEB afectados.
· Regresar el tráfico a su red original.
¿Qué personal estaría involucrado en los procesos de contención, erradicación y/o recuperación?
El departamento de TI, el departamento de sistemas principalmente el responsable de seguridad informática (CISO) y el departamento de soluciones y el departamento de soluciones principalmente el director de tecnología (CTO). Estos serían los principales actores durante la contención, erradicación y recuperación, aunque dependiendo de cada empresa u organización puede haber más o menos, en el análisis de este escenario no podemos definir con exactitud el personal o departamentos que estarán involucrados en este caso ya que no se proporciona una estructura organizacional.
¿Qué fuentes de evidencia, si las hay, debe adquirir la organización? ¿Cómo se adquiriría la evidencia? ¿Dónde se almacenaría? ¿Cuánto tiempo debe conservarse?
El departamento de soluciones y el departamento de TI deberían de trabajar en conjunto para recabar las pruebas necesarias, de igual forma si la organización lo decide se puede delegar esta tarea a un servicio de peritaje cibernético. 
Estas evidencias se deben documentar y estar fechadas y firmadas por los encargados del departamento de IT, la empresa puede decidir si almacena dicha documentación de manera física y digital al igual que el tiempo de se guardarán dichas evidencias del ataque pero por buenas prácticas dicha información debe almacenarse por al menos 3 años. 
Actividad post-incidente
¿Quién asistiría a la reunión de lecciones aprendidas con respecto a este incidente?
Los asistentes a las juntas donde se analizaran las cosas aprendidas durante el ataque DDOS en primera debería ser el departamento de TI que es el encargado de generar estrategias a futuro (junto con el CISO) para prevenir futuros ataques, pero el marco de ciberseguridad de NIST estipula que también se deben de incluir todo el personal que participo durante el ataque y los departamentos que se vieron afectados, por esta razón es que también deben de asistir el departamento de sistemas, el departamento de soluciones, el departamento de finanzas, el departamento de marketing, el CIO de la empresa.
¿Qué se podría hacer para evitar que ocurran incidentes similares en el futuro?
· Aumentar el ancho de banda, aunque es una de las acciones más básicas, al aumentar el ancho de banda se dificulta que nos dejen sin servicio en un futuro.
· Tener el activo duplicado en más de un servidor y poder asignar uno u otro dependiendo de la carga de trabajo (redundancia y balanceo de carga).
· Contar con un cortafuegos de aplicación, este servicio de cortafuegos en la nueve servirá como un intermediario entre los clientes y la WEB para evitar las interrupciones del servicio. 
· Mantener los softwares actualizados, ya que muchas de las veces esta es la principal razón de que se facilite o potencialice un ataque DDOS.
¿Qué podría hacerse para mejorar la detección de incidentes similares?
· Llevar un seguimiento de taques DDOS similares a servicios WEB que se encuentren dentro del rubro de la organización. 
· Mejorar nuestros planes de prevención y acción mediante la retroalimentación de los incidentes dentro de nuestra empresa y la externas.
· Contar con un departamento especializado en ciberseguridad.
· Monitorizar constantemente el tráfico de nuestra página WEB.
Preguntas Generales
¿Cuántos miembros del equipo de respuesta a incidentes participarían en el manejo de este incidente?
Al tratarse de un ataque a la WEB de una organización podríamos darle una mayor importancia, por este motivo se puede asignar un equipo de respuesta de unas 6 u 8 personas contando al coordinador del equipo.
Además del equipo de respuesta a incidentes, ¿qué grupos dentro de la organización estarían involucrados en el manejo de este incidente?
· El departamento de TI.
· El departamento de seguridad. 
· El departamento de mantenimiento.
· El departamento legal.
· El departamento relaciones públicas.
¿A qué partes externas reportaría el equipo el incidente? ¿Cuándo se produciría cada informe? ¿Cómo se haría cada informe? ¿Qué información reportarías o no reportarías y por qué?
· Departamento de policía: se le debe proporcionar toda la información que pueda ser considerada evidencias para poder tomar acciones legales ante el o los atacantes.
· CERT nacional: se le proporcionara la información acerca de cómo fue el ataque y como es que este se logró mitigar con la finalidad de llevar un registro de los ataques que se generan y este sirva como fuente de información para generar una mejora continua en las empresas al momento de generar un plan de prevención a este tipo de ataques.
· Otros equipos de respuesta: se proporcionaría toda la información ya que en futuros casos los otros equipos de respuesta con los que cuenta nuestra empresa podrían ser los encargados de atender un caso similar y es mejor que cuenten con documentación previa para atender dichos casos.
· Proveedores de internet: se les proporciona daros como cuando ocurrió la interrupción de servicio, la posible dirección del atacante, cuanto duro, etc. con la finalidad lleve un registro y mejore el servicio brindado.
· Otros departamentos de la empresa: se les proporciona información más sintetizada con la finalidad de generar una cultura de prevención ante este tipo de riesgos.
· Propietarios de la IP de ataque: si es que la dirección IP de ataque proviene de otra organización se comunica con ellos para ponerlos al tanto y pedirles que se proporcionen las pruebas necesarias en caso de que haya ocurrido un uso indebido por parte de su personal, esto generalmente se encarga de realizarlo u departamento legal o un CERT.
¿Qué otras comunicaciones con partes externas pueden ocurrir?
· Medios de comunicación: se les da un informa de lo ocurrido sin muchos detalles de los procedimientos de respuesta y las afectaciones a la organización, esto con la finalidad de mantener nuestra privacidad, pero, al mismo tiempo mantener informados a los usuarios del porque las interrupciones del servicio.
· Vendedores de software: se les brinda información acerca del incidente ocurrido (interrupción del sistema) con la finalidad de que nos brinden una propuesta de solución para atender nuestra problemática (nos vendan un servicio en la nube).
· Equipos de respuesta externos: se les brinda información de como fue el ataque y la manera de resolverlos con la finalidad de poder ayudar a otras organizaciones que sufran el mismo tipo de ataques.
¿Qué herramientas y recursos utilizaría el equipo para manejar este incidente?
· Filtración (si es posible a nivel Tier1 o 2) 
· Traffic-scrubbing/Sinkhole/Clean-pipe 
· Blackhole Routing
· Si es posible desactivar el servicio de los sitios WEB momentáneamente.
· Terminar las conexiones o procesos no deseados en los servidores de la organización para posteriormente revisar y cambiar las configuraciones TCP/IP.
· Cambiar los DNS del sitio WEB que está siendo atacado.
· Encaminar el tráfico a un servicio de depuración de trafico de cambios en las rutas o en los DNS.
· Si el ataque proviene desde el ISP se tiene que poner en contacto con ellos para que tomen las medidas pertinentes.
· Intentar restringir el acceso a la IP que se tiene identificado como el atacante mediante el Firewall.
· Comunicarse con un CERT nacional y a la policía para que se tomen las medidas necesarias.
· Asegurarse que el ataque DDOS haya terminado.
· Asegurarse de que se haya restablecido el acceso a los servicios WEB afectados.
· Regresar el tráficoa su red original.
¿Qué aspectos del manejo habrían sido diferentes si el incidente hubiera ocurrido en un día y hora diferentes (horas de trabajo versus fuera de horario)?
De acuerdo con lo que se menciona en la planeación del caso existen dos posibilidades, uno la posibilidad de que la organización no cuente con equipo y herramientas capaces de detectar este tipo de ataques, ni de monitorización continua de la red, en este caso no habría mucha diferencia pues habría llegado al punto de saturar el ancho de banda, para que alguien lo notara, repitiendo así las consecuencias o bien este proceso de monitorización está basado en mera vigilancia humana y en una hora fuera de trabajo no se cumplió, en ese caso se puede actuar de manera temprana si sucede en un día y hora laboral, iniciando con un plan de acción.
¿Qué aspectos del manejo habrían sido diferentes si el incidente hubiera ocurrido en una ubicación física diferente (en el sitio versus fuera del sitio)?
El equipo de respuesta debe llegar físicamente al lugar por lo que el manejo tendría que contemplar los tiempos de traslado, además de los accesos al lugar 
Preguntas adicionales para este escenario
¿A quién debe contactar la organización con respecto a la dirección IP externa en cuestión?
Se puede acudir con el proveedor del servicio de host y de los servicios de seguridad con lo que cuente la organización, buscado rastrear el origen del ataque.
Supongamos que después de que se implementaron las medidas de contención iniciales, los administradores de red detectaron que nueve hosts internos también intentaban las mismas solicitudes inusuales al servidor DNS. ¿Cómo afectaría eso el manejo de este incidente?
El manejo ahora tendría que contemplar la revisión de los nueve los hosts de forma que estos quedarían desconectados propiciando la perdida de la información, y no resolvería el problema.
Supongamos que dos de los nueve hosts internos se desconectaron de la red antes de que se identificaran sus propietarios del sistema. ¿Cómo se identificaría a los propietarios del sistema?
Todo lo que ocurre dentro de la red está en constante monitorización y es registrado en los archivos, revisar estos archivos y buscar irregularidades puede ser una manera de encontrar a los dos host.
¿Fue sólo un ataque DOS?/ ¿Y si no lo fue?
Aunque su principal consecuencia se trata de que el servidor quede inutilizable por un periodo de tiempo, también se presentan distintos riesgos, como son la extorción donde a cambio de una cantidad liberan el servidor del ataque, hasate temneter fines de robo de información.
¿Cuál es el alcance potencial?
Para detectar si fue un ataque DOS debemos comprobar los servicios a afectados, comprobar el funcionamiento de los servidores y el flujo de red, posteriormente revisar las salidas y entradas de datos mediante el análisis de tramas de entrada y salida, si durante el ataque se reconocen salidas de tramas lo más probable es que no fuera solo un ataque DOS si no que se hubiera sustraído información de la organización o página y esto puede llegar a afectar a muchos niveles, ya que este tipo de ataques con robo de información conllevan problemas como los del espionaje industrial pues se podrían conocer planear futuros de la página u organización, estrategias de marketing, estructura organizacional y más.
¿Solo comprobó los activos afectados vinculados al ataque?
No, de acuerdo a los protocolos de respuesta a ataques DOS propuestos por la uv-csirt (coordinación de gestión de incidentes de ciber seguridad) se debe hacer una revisión completa, revisando la funcionalidad de los servidores, el tráfico de datos, el rastreo de las direcciones IP y los DNS del ataque, el reinicio de los servicios y bloqueo de direcciones de las cuales proviene el ataque y posteriormente comprobar la salida de datos y los accesos a los mismos durante el ataque para comprobar posibles elementos departamentos o datos comprometidos mediante el ataque.
¿Hubo algún otro problema además del DOS?
Ante tal ataque existe la necesidad de reiniciar la configuración DNS de los enrutadores lo que costara tiempo, dinero y disponibilidad del servicio, aparte del perdido por el ataque, por lo que deberemos contabilizar estos daños además del posible daño a la propiedad o a la integridad de los datos el dicho servidor posteriormente llevar a cabo un reporte y hacer una revisión de los elementos relacionados con el reporte que ya se ha generado y así ir escalando la exploración hasta confirmas que no hay más fallos o peligros de una réplica del ataque
Escenario 2
Álvarez Luis Enrique Adrián
Morales Zaldívar Pablo
Valencia Sánchez Miguel Ángel
Zacarías Pineda Esmeralda
“Un martes por la mañana, se libera un nuevo gusano; se propaga a través de medios extraíbles y puede copiarse a sí mismo para abrir recursos compartidos de Windows. Cuando el gusano infecta un host, instala un agente DDoS. La organización ya ha incurrido en infecciones generalizadas antes de que las firmas antivirus estén disponibles varias horas después de que el gusano comenzó a propagarse.”
Preparación
¿Consideraría la organización esta actividad como un incidente? Si es así, ¿cuál de las políticas de la organización viola esta actividad?
Los gusanos en una computadora pueden traer consigo otras muchas consecuencias como el robe de información o la implantación de otro malware, por lo tanto este evento es un incidente que está violando las políticas de seguridad relacionadas a la información por ejemplo se ve afectada su disponibilidad de integridad.
¿Qué medidas existen para intentar evitar que ocurra este tipo de incidentes o limitar su impacto?
La medida principal es contar con software antivirus que detecte el malware, posteriormente genere una alerta y evite que otros dispositivos se infecten.
Detección y Análisis
¿Qué precursores del incidente, si los hay, podría detectar la organización? ¿Algún precursor haría que la organización tomara medidas antes de que ocurriera el incidente?
La actualización constante del sistema, además de instalar las actualizaciones de seguridad, además de un escáner de las vulnerabilidades a través de las entradas web, escáner del ancho de banda, el antivirus es parte de un indicador que si hay una amenaza se encarga de eliminarla
¿Qué indicadores del incidente podría detectar la organización? ¿Qué indicadores harían que alguien pensara que podría haber ocurrido un incidente?
El firewall y el antivirus son los dos indicadores que nos permitirán identificar un incidente, el que nos dará el aviso principal sería el antivirus.
¿Qué herramientas adicionales podrían ser necesarias para detectar este incidente en particular?
Serían los IDPSs, SIEMs serian otras herramientas importantes para poder detectar algún incidente
¿Cómo analizaría y validaría este incidente el equipo de respuesta a incidentes? ¿Qué personal estaría involucrado en el proceso de análisis y validación?
Deben realizar un análisis inicial para medir el alcance del incidente, todo debe ser documentado de ahí se debe validar quien lo hizo desde donde y como funciono el incidente el equipo debe saber cómo funciona cada aplicación normalmente, tener un perfil de redes y sistemas, tener una política de retención de registros y realizar una correlación de eventos y todo el equipo deberá estar involucrado
¿A qué personas y grupos dentro de la organización reportaría el equipo el incidente?
Se debe informar del incidente a todos los integrantes del equipo ellos a su vez deben informar al director de información, jefe de seguridad de la información, Oficial de seguridad de la información local, Otros equipos de respuesta a incidentes dentro de la organización, Equipos de respuesta a incidentes externos.
¿Cómo priorizaría el equipo el manejo de este incidente?
Deben darle la prioridad de acuerdo en función de factores en este caso se considera prioridad alta por el ataque DDOs.
Contención, erradicación y recuperación
¿Qué estrategia debe tomar la organización para contener el incidente? ¿Por qué esta estrategia es preferiblea otras?
La organización debe de adherirse al plan de contingencia previamente paneado, en este caso cambiar las direcciones URL, bloqueo de la IP y/o mover el sitio de servidor.
¿Qué podría suceder si el incidente no fuera contenido?
Podría caerse el sistema y por ende sería muy vulnerable al robo de información.
¿Qué herramientas adicionales podrían ser necesarias para responder a este incidente en particular?
Validar la detección del atacante mediante y el monitoreo de canales de comunicación del atacante.
¿Qué personal estaría involucrado en los procesos de contención, erradicación y/o recuperación?
El equipo de repuesta es el encargado de dar respuesta y solución.
¿Qué fuentes de evidencia, si las hay, debe adquirir la organización? ¿Cómo se adquiriría la evidencia? ¿Dónde se almacenaría? ¿Cuánto tiempo debe conservarse?
El equipo de respuesta son los encargados de recabar las pruebas, todo debes ser documentado y firmado con fecha y hora; cada organización decide a través de una política el tiempo estimado pero el Programa de Registros Generales (GRS) 24 especifica que los registros de manejo de incidentes deben mantenerse para tres años.
Actividad post-incidente
¿Quién asistiría a la reunión de lecciones aprendidas con respecto a este incidente?
Al tratarse de una infección por un gusano dentro de los equipos de los empleados, la primera área que se requiere en la reunión de lecciones aprendidas son las áreas de sistemas y seguridad informática, ya que son los encargados del mantenimiento y funcionamiento de todos los equipos dentro de la organización. El área de sistemas puede conocer más acerca del incidente y aprender del mismo para poder erradicar posibles ataques similares. Como lo indica el NIST, en las reuniones de lecciones aprendidas no sólo debe de participar el área involucrada en el incidente, también pueden participar las áreas que pueden cooperar para evitar un futuro incidente similar; en este caso el área que podría participar en la reunión de lecciones aprendidas es el personal que utiliza los equipos, puesto que se les puede dar información para prevenir un ataque y la propagación de gusanos mediante medios extraíbles como lo son memorias USB, discos y unidades de almacenamiento digital.
¿Qué se podría hacer para evitar que ocurran incidentes similares en el futuro?
Como se habló anteriormente en las reuniones de lecciones aprendidas, es necesario el dar una capacitación a los empleados que utilizan los equipos dentro de la organización. Dentro de las acciones para prevenir incidentes similares en el futuro está precisamente la sensibilización y formación de los usuarios, en la cual se puede dar a conocer el cómo es que ese incidente puede afectar a los procesos de la empresa. También es importante dar a conocer el correcto uso de los equipos y las medidas de seguridad que se tienen para prevenir ataques por gusanos, así como la capacitación de detección de posibles amenazas para una identificación oportuna por parte del área de sistemas y seguridad informática.
¿Qué podría hacerse para mejorar la detección de incidentes similares?
Para mejorar la detección de ataques similares se puede optar por la instalación de software de detección de malware en el nivel host (servidores y estaciones de trabajo) para que si se da un nuevo ataque en los equipos de los empleados el ataque no llegue a niveles altos dónde se almacena la información de la organización. Esta medida va de la mano junto con la medida de seguridad en el host, en dónde se aplican los estándares de configuración para filtrar los accesos a la información contenida en los servidores host. Una vez que se asegura el host de la información se pueden aplicar las medidas del host en los equipos de los empleados (instalación de software de detección de malware) para poder el origen de la infección de un gusano y detener su propagación mediante los demás equipos de la organización.
Preguntas Generales
¿Cuántos miembros del equipo de respuesta a incidentes participarían en el manejo de este incidente?
Se requiere de aproximadamente 4 personas para poder actuar ante este incidente. Como en todos los equipos de respuesta a incidentes, se requiere de la participación del administrador del equipo puesto que es el encargado de asegurarse que las actividades que se realizan para erradicar el incidente se lleven a cabo de forma adecuada. También es requerida la participación del técnico encargado de realizar las actividades técnicas con calidad dentro del equipo, puesto que el incidente presentado requiere de un técnico especializado para la aplicación de las medidas correctivas tomadas por el equipo de respuesta a incidentes. Aunque el jefe del área de sistemas no necesariamente es parte del equipo de respuesta a incidentes, para el incidente de infección por un gusano es necesario que trabaje dentro del equipo. Otro miembro importante de la organización y que también puede agregarse al equipo de respuesta a incidentes es el jefe del área de seguridad informática y redes, puesto que el gusano que comenzó la infección representa una amenaza en los servidores host para realizar un ataque DDoS.
Además del equipo de respuesta a incidentes, ¿qué grupos dentro de la organización estarían involucrados en el manejo de este incidente?
Como lo indica el NIST, se requieren de otros departamentos que pueden participar en las actividades para responder ante el incidente de la infección por un gusano informático. Se requiere del administrador de la empresa, el cuál es el encargado de la política de respuesta a incidentes. El equipo de protección de la información también es requerido en caso de que se necesite aplicar una seguridad adicional a los servidores host que almacenan la información de toda la organización. Un área que también es requerida es el área legal de la empresa, puesto que son los encargados de revisar el suceso para proceder legalmente contra los que originaron el incidente. Además, se requiere de la participación del área de recursos humanos, en caso de que el origen y propagación del gusano sea originado por un empleado de la organización. Finalmente, también se requiere del área de seguridad física de la organización en caso de que se requiera el acceso a áreas restringidas para actuar ante el incidente.
¿A qué partes externas reportaría el equipo el incidente? ¿Cuándo se produciría cada informe? ¿Cómo se haría cada informe? ¿Qué información reportarías o no reportarías y por qué?
El reporte del incidente se puede hacer público a los clientes de la organización, puesto que esto puede informar a los clientes de lo sucedido con la información que pudo estar en riesgo mediante el ataque, y las medidas empleadas para erradicar el ataque. Al dar acceso público al reporte habla del compromiso de la organización con la transparencia de la información y puede ayudar a que los clientes estén informados de que su información está segura dentro de la organización. Los reportes de seguridad dependen mucho del giro de la organización; si se trata de una organización de seguridad se puede optar por realizar un reporte cada mes, en caso contrario se puede optar por realizar reportes cada 3 o 6 meses. Los informes tendrían que ser realizados por el área encargada de la seguridad de la información dentro de la organización y tienen que ser revisados y aprobados por los departamentos administrativos y legales de la organización. El reporte de seguridad de la organización debe de contener la amenaza detectada, el responsable de realizar dicha amenaza, la información comprometida, las sugerencias a los clientes para protegerse ante la amenaza y el estado de la amenaza; esta información puede ser visible para todas las personas y puede dar alerta oportuna a los clientes para que protejan su información. La información que se puede omitir en el reporte es la manera en la que la organización erradicó la amenaza y las medidas de seguridad empleadas, puesto que esto hace podría representar una vulnerabilidad en la empresa para futuras amenazas.¿Qué otras comunicaciones con partes externas pueden ocurrir?
Además del reporte público para los clientes, se puede optar por usar medios de entretenimiento para poder dar a conocer el incidente y que este pueda servir de ejemplo para otras organizaciones. Los ataques a las organizaciones van evolucionando conforme evoluciona la tecnología, y esto abre la posibilidad del nacimiento de nuevas amenazas que sean complicadas de erradicar. El superar una nueva amenaza y darlo a conocer a otras organizaciones puede servir para prevenir a las demás organizaciones del nuevo ataque, o en caso de que una organización sea atacada de la misma manera pueda conocer algunas medidas que debe de implementar para erradicar la amenaza.
¿Qué herramientas y recursos utilizaría el equipo para manejar este incidente?
Los recursos y herramientas que requiere el equipo de respuesta a incidentes se listan a continuación:
· Información de contacto: incluye la información de contacto de los administradores de la organización para solicitar cualquier información que es de conocimiento limitado. También se requiere el contacto a los proveedores de servicios de seguridad de la información. 
· Mecanismos de reportes de incidentes: medios digitales en los cuales se va a realizar el informe de seguimiento a la respuesta del incidente.
· Sistema de seguimiento del incidente: sistema para conocer las actividades que se realizan para actuar contra el incidente.
· Información de licencias de seguridad: claves, manuales, contratos, vigencias y características de las licencias adquiridas para la seguridad en los equipos de la organización.
· Software de análisis de malware: programas de antivirus que permitan analizar los archivos infectados y separarlos de los archivos sanos.
· Software de recuperación de archivos: programas de recuperación y antivirus para poder limpiar los archivos infectados y recuperar la información contenida, liberándolos del virus.
· Equipos de cómputo: para realizar las actividades y realizar los reportes necesarios para el seguimiento del incidente.
· Analizador de protocolos y redes: software que permita vigilar el tráfico de la red en la organización para prevenir ataques a la red provocados por los gusanos.
· Equipos de almacenamiento seguro: unidades de almacenamiento para realizar respaldo de la información contenida en los equipos infectados.
¿Qué aspectos del manejo habrían sido diferentes si el incidente hubiera ocurrido en un día y hora diferentes (horas de trabajo versus fuera de horario)?
El incidente ocurrió un día de trabajo normal (martes), por lo que se supondría que el equipo de respuesta a incidentes y todas las áreas necesarias para poder erradicar el incidente se encontraban disponibles para poder actuar de forma rápida y al momento. El número de integrantes de la plantilla laboral es de vital importancia, ya que esto nos permite tener personal disponible las 24 horas los 7 días de la semana como lo indica el NIST para poder tener disponible al menos a algún miembro de la organización capaz de actuar ante una amenaza. Si el incidente ocurre en alguna organización que no cuente con personal suficiente, la hora y el día para realizar el ataque puede influir demasiado en la respuesta y el efecto que toma la infección. En este escenario, al tratarse de una infección por un gusano a una máquina de un empleado, se puede empezar a actuar de forma remota, por lo que, si el equipo de respuesta a incidentes o el área de sistemas y seguridad no se encontraban disponibles en el área de trabajo, se pueda contactar de forma remota y se pueda empezar a atender el incidente. 
También en este escenario si influye el tiempo en el que incidente ocurre, puesto que se comenzó el ataque en un equipo que opera un empleado de la empresa. Si el empleado no se encuentra en su horario de trabajo el equipo infectado no se encontraría en línea y la infección no se propagaría en los demás equipos de la organización.
¿Qué aspectos del manejo habrían sido diferentes si el incidente hubiera ocurrido en una ubicación física diferente (en el sitio versus fuera del sitio)?
El ataque por infección por gusano en un equipo de computadora puede ocurrir dentro o fuera de la organización. En este escenario ocurrió dentro de la misma organización, por lo que la propagación es evolutiva; es decir, se empieza con un equipo y el gusano pasa de equipo en equipo hasta infectar a la mayoría de los equipos. Si se detecta a tiempo se puede detener la infección antes de que llegue a un equipo host. En caso de que se realice por fuera de la organización puede ser mediante la red, descargando el gusano en más equipos de la organización y acelerando la infección, incrementando las posibilidades de llegar a un servidor host.
Preguntas adicionales para este escenario
¿Cómo identificaría el equipo de respuesta a incidentes a todos los hosts infectados?
A medida que las organizaciones agregan datos integrados y fuentes de inteligencia de amenazas a sus esfuerzos de respuesta a incidentes, las oportunidades para orquestar las respuestas de una manera sofisticada crecen, comenzando con la automatización de tareas repetitivas y de bajo nivel. Se destacan tres desafíos impulsores: volumen de incidentes, trabajos sin completar y complejidad de la herramienta.
· Volumen de incidentes: El volumen de incidentes de ciberseguridad está aumentando. Los profesionales de la ciberseguridad dicen que el volumen de alertas de seguridad ha aumentado en los últimos dos años. Y anteriormente, dijeron que su organización ignora una cantidad significativa de alertas de seguridad porque no pueden mantenerse al día con el volumen.
· Brecha de habilidades: Los equipos de seguridad están luchando por cubrir los puestos vacantes. 
· Complejidad de la herramienta: Los equipos gestionan un entorno de seguridad complejo con una cantidad vertiginosa de herramientas desconectadas. 
Las organizaciones pueden hacer frente a sus desafíos de tres maneras clave:
· Crear procesos de respuesta a incidentes que sean consistentes, repetibles y medibles, en lugar de ad hoc.
· Hacer de la comunicación, la coordinación y la colaboración una prioridad para toda la organización.
· Utilizar tecnología que ayude al equipo de respuesta a realizar su trabajo de forma más rápida y precisa.
¿Cómo intentaría la organización evitar que el gusano entrara en la organización antes de que se publicaran las firmas antivirus?
Existen varias prácticas recomendadas que las personas y las empresas pueden seguir para protegerse de un gusano informático. Los siguientes pasos reducen el riesgo de infección y facilitan la identificación y eliminación de gusanos informáticos:
Comportamiento seguro
Los archivos adjuntos y enlaces solo deben abrirse si provienen de una fuente confiable conocida por el usuario. Los correos electrónicos de remitentes desconocidos no deben abrirse, ya que muchos gusanos informáticos se propagan a través del correo electrónico. Las empresas deben realizar cursos de formación de sensibilización con sus empleados para que sean conscientes de los peligros y riesgos en Internet.
Actualizaciones periódicas
Los sistemas operativos y el software deben mantenerse actualizados con actualizaciones periódicas. Las actualizaciones del fabricante a menudo contienen parches de seguridad que protegen las computadoras de nuevos gusanos y corrigen errores. Esto es importante porque un gusano informático se beneficiará de las vulnerabilidades.
Software antivirus
El software antivirus es la primera medida preventiva para evitar gusanos informáticos. Es un programa que protege al ordenador de virus, gusanos, troyanos y malware de todo tipo. Analiza todos los archivos de la computadora y ayuda a prevenir daños. Los programas antivirus que pueden escanear descargas y que ya contienen herramientas para eliminar un gusano informático son particularmente efectivos.
Cortafuegos
Un firewall es una herramienta de seguridad que se utiliza para monitorear el tráfico de red entrante y saliente según las reglas deseguridad. El objetivo principal es crear una barrera entre la red interna y externa para protegerse contra los ataques cibernéticos.
Protege la bandeja de entrada de correo electrónico
Los gusanos informáticos a menudo atacan las computadoras a través del correo electrónico. Por ejemplo, pueden acceder a la computadora a través de un correo electrónico de phishing. Puedes protegerte antes de que el malware entre en la computadora. Esto funciona para empresas, por ejemplo, con protección contra spam y malware o protección avanzada contra amenazas.
¿Cómo intentaría la organización evitar que el gusano se propague por hosts infectados antes de que se liberen las firmas antivirus?
En casos extremos, la eliminación de un gusano informático puede implicar un reformateo. La gestión de la configuración puede ayudar a recuperar rápidamente los sistemas infectados y mejorar drásticamente la respuesta a incidentes.
Si puedes identificar el gusano en particular que ha infectado el sistema, puede haber instrucciones o herramientas específicas diseñadas para eliminar la infección.
Durante el proceso de eliminación, desconéctate de Internet y elimina todos los dispositivos de almacenamiento y escanéalos por separado para buscar el archivo host. Una vez que el sistema se ha desconectado, puedes seguir las instrucciones, ejecutar la herramienta o reformatear la computadora.
¿Intentaría la organización parchear todas las máquinas vulnerables? Si es así, ¿cómo se haría esto?
Dependiendo del caso, estas pudiesen ser parchadas por la organización, se deberá aislar los posibles infectados para la configuración y saneamiento de las vulnerabilidades, se llevará un control de cuarentena de forma dinámica para el rastro de dichos problemas y se sometería a una revisión activa.
¿Cómo cambiaría el manejo de este incidente si los hosts infectados que habían recibido el agente DDoS hubieran sido configurados para atacar el sitio web de otra organización a la mañana siguiente?
La acción en sitio seria suspender la brecha de conectividad para trabajar en el ambiente controlado, se requerirá, de una recepción de paquetes ajustados controlar el nicho del ataque y volcarse al respaldo que se tenga instalado en una segunda versión del sitio
¿Cómo cambiaría el manejo de este incidente si uno o más de los hosts infectados contuvieran información confidencial de identificación personal sobre los empleados de la organización?
Desarrollar a medida la etapa de contingencia ocupando los datos externos y resguardados, de forma adecuada, alojando de mejor manera el nuevo respaldo ejecutándolo en el ambiente de cuarentena, mientras las demás opciones están listas para la recuperación de datos.
¿Cómo mantendría informados el equipo de respuesta a incidentes a los usuarios de la organización sobre el estado del incidente?
De manera adecuada, realizar el seguimiento de avisos por administrador, de tal forma que se focalice el esfuerzo en ejecutar el control de dispersión de información, con tal de mantener la conexión del personal para todo tipo de comunicado al respecto.
¿Qué medidas adicionales realizaría el equipo para los anfitriones que actualmente no están conectados a la red (por ejemplo, miembros del personal de vacaciones, empleados externos que se conectan ocasionalmente)?
· Ocupar Llaves SSH
· Usar Cortafuegos
· Normalizar las VPN y redes privadas
· Infraestructura de llaves públicas y inscripción SSL/TLS
· Realizar la Auditoría de servicios para conexiones externas
· Realizar Auditoría de archivos y Sistemas de Detección de Intrusos
· Implementar Ambientes aislados de ejecución
¿Qué pasos deben tomarse en caso de una infección de una PC normal del empleado?
· Una vez identificado el equipo con problemas, este deberá aislarse del resto de equipos en red que puedan ser susceptibles a propagar el problema.
· En caso de que este sea un problema de red, deberá de ser puesto en cuarentena y pasado a una restricción de uso para su correcto análisis y solución
· Proceder a escanear con el antivirus asignado para su correcto repositorio de amenazas.
· Resguardar la información almacenada en las unidades de almacenamiento para su extracción por métodos de recuperación avanzadas.
· Dar actualización y reestructuración de contraseñas y credenciales para su nueva implementación en la infraestructura de la red
· Dar un soporte técnico y administrativo para su reincorporación dentro del ecosistema de red
· Proporcionar parte y reporte de los nichos afectados dentro de red para verificar su funcionamiento y correcto desempeño
· Hacer un barrido de vulnerabilidad escalar para detectar fracturas y fallas para parchar dichas acciones para elementos vinculados a la infraestructura montada y programada.
· Activar las alertas y recomendaciones a posibles afectados dentro y fuera del sistema
· Señalar un evento en la bitácora de historiales de sucesos.
· Hacer un test general para la correcta funcionalidad del sistema y su estabilidad dentro de todo el ecosistema montado.
· En caso de ser necesario montar una guardia para efecto de rastreo activo durante el periodo de vulnerabilidad acompañado de una asesoría externa para la seguridad.
· Reforzar candados y métodos de barrera para futuras referencias.
¿Qué políticas son necesarias para prevenir la infección?
1. Actualizaciones regulares
2. Protección del equipo con programas antivirus
a. Escáner en tiempo real
b. Analizadores de virus en línea
c. Escáneres manuales
3. Restricción a fuentes de datos desconocidas
4. Precaución con archivos desconocidos en Internet
5. Cuidado al instalar un software nuevo
6. Copias de seguridad regulares 
7. Seguridad del Navegador
8. Descarga de archivos irregulares
9. Usa contraseñas seguras
10. La protección de datos y la seguridad informática como políticas de estándar
¿Qué dispositivos se tendrían en cuenta para la mitigación de riesgos?
· Use un firewall
· Mantener todo el software actualizado
· Use el software antivirus y manténgalo actualizado
· Asegurar que las contraseñas estén bien seleccionadas y protegidas
· No abrir datos adjuntos sospechosos ni hagas clic en vínculos inusuales de mensajes.
· Navegar por la web de manera segura
· Mantenerte alejado del material pirateado 
· Evita el streaming o la descarga de películas, música, libros o aplicaciones que no provengan de fuentes de confianza. Es posible que contengan malware.
· No use dispositivos USB u otros dispositivos externos a menos que sean autorizados.
Escenario 3
Morales Gonzalez Pedro Antonio.
García Samperio Janice Amairani. 
Medina Posadas Enrique. 
Pantoja Rodríguez Lizbeth. 
Ramirez Benitez Brayan. 
Zárate González Erik Daniel. 
Arredondo Carbajal Salvador.
“Un lunes por la mañana, el departamento legal de la organización recibe una llamada de la Oficina Federal de Investigaciones (FBI) sobre alguna actividad sospechosa que involucra los sistemas de la organización. Más tarde ese día, un agente del FBI se reúne con miembros de la gerencia y el departamento legal para discutir la actividad. El FBI ha estado investigando actividades relacionadas con la publicación pública de documentos gubernamentales confidenciales y, según se informa, algunos de los documentos pertenecen a la organización. El agente solicita la asistencia de la organización y la gerencia solicita la asistencia del equipo de respuesta a incidentes para adquirir las pruebas necesarias para determinar si estos documentos son legítimos o no y cómo podrían haberse filtrado”
Para responder se debe revisar el siguiente documento, al final de cada pregunta se encuentra la sección que ayudara a responder dicha pregunta.
https://actualizacionyformacion.com/pluginfile.php/13493/mod_assign/introattachment/0/Editado%20-%20NIST.SP.800-61r2.pdf?forcedownload=1
Análisis
¿La organización consideraría esta actividad como un incidente? Si es así, ¿cuál de las políticas de la organización viola esta actividad? (sección 2.1)
En terminos generales este acto se considera un incidente a la seguridad computacional, ya que se han filtrado documentosde indole confidencial de la organización y se han violado las politicas de seguridad. En este caso las politicas que se estan violando son: 
· Integridad de los datos y su proteccion por fallos de soportes o borrado: Como aun no se verifica la veracidad de los documentos publicados, es dificil determinar si esa informacion fue parte de algun reporte anteguo o reciente, que bien pudo haber sido eliminado anteriormente. 
· Provacidad de la informacion y su proteccion frente accesos por personal no autorizado: La infomacion pudo haber no estado cifrada y por ello, fue de facil acceso para todo aquel personal interno o persona externa. 
· Notificacion de violaciones y brechas de seguridad: De ser verdicos los docuementos, el sistema tuyo fallas respecto a detectar el filtrado de la informacion. 
¿Qué medidas existen para intentar evitar que ocurra este tipo de incidentes o limitar su impacto? (sección 3.1.2)
· Seguridad del anfitrion (host): Debido a que se esta investigando si la vulneracion fue de parte interna o externa, es necesario que todos aquellos que tienen el rol de host tengan configuraciones estandar donde cada acceso este protegido se tiene que seguir el principio de menor provilegio – Los usuarios tienen solamente permisos necesarios para realizar sus tareas, mientras que los host son auditados periodicamente y registrar los eventos significativos relacionados con los eventos de seguridad. En este caso existe el Protocolo de Automatizacion de Contenido de Segutidad (SCAP en ingles) que muestra el sistema operativo y la aplicación de sus listas configuración para apoyar consistentemente la seguridad hots de manera efectiva. 
· Seguridad de Red: El perimetro de la red tiene que configurada para negar toda la actividad que no es permitida, esto incluye asegurar todos los puntos de conexión como las redes virtuales privadas (VPNs) y las qe van dirigidas a otras organizaciones. 
· Prevencion de Malware: Es necesario un software que detecte y detenga el malware. Este se ejecuta en desde el nivel de host (servidores y sistemas operativos de estaciones de trabajo), a nivel del servidor de aplicación (servidor de email, web proxies) y al nievel de aplicación del cliente (correos de los clientes, mensajes instantaneos a clientes)
· Capacitacion a los usuarios: Los usarios deben de estar al tanto de ls politicas y procedimientos respecto al uso apropado de las redes y sus funciones. De existir incidentes previos, es necesario compartir la experiencia para identificar el daño que causa a la empresa. Capacitar a los usuarios reduce a frecuencia de los incidentes, sim embargo, es necesario un mantenimiento de las redes, sistemas y aplicaciones de aguardo con los estandares de seguridad de la organización. 
¿Qué precursores del incidente, si los hubiere, podría detectar la organización? ¿Algún precursor haría que la organización tomara medidas antes de que ocurriera el incidente? (sección 3.2.2, 3.2.3)
· Precursores del incidente
· Recibir demasiadas detecciones de alertas por dia – Con esto la organización puede preveer un incidente alterando su seguridad para salvar un posible objetivo de un ataque
· Alerta por parte de antivirus – Con esto la organización puede preveer un incidente monitoreando la actividad respecto a un objetivo de manera mas cercana. 
· Detección automatica de los IDPSs de las bases de red y de hosts: Los IDPS identifican eventos sospechosos y guardan la informacion pertinente de estos, incluyendo la fecha y el tiempo en que el ataque fue detectado, el tipo de ataque, su fuente y el Ip destino y el usuario (si es conocido). 
· Problemas reportados por los usuarios
· Correos con links a dudosos dominios o con archivo no reconocidos para descargar. 
· Un usuario detecta un archivo con nombre o letras raras. 
· Precursor con medidas antes del incidente.
· Software para identificar la integridad de los archivos: Detecta los cambios hechos en los documentos importantes durante los ataques. Obtiene un checksum encriptado para cada archivo. 
¿Qué indicadores del incidente podría detectar la organización? ¿Qué indicadores harían que alguien pensara que podría haber ocurrido un incidente? (sección 3.2.2, 3.2.3)
· Detector de la organización
· Detección automática de los IDPSs de las bases de red y de hosts
· Alertas de malware o spam en los correos. 
· Detección de falsos dominios de las organizaciones. 
· Indicadores que permitieras saber que ocurrió un accidente
· Software para identificar la integridad de los archivos: Detecta los cambios hechos en los documentos importantes durante los ataques. Obtiene un checksum encriptado para cada archivo. En este caso, si el archivo alterado con coincide su checksum antiguo al ser recalculado entonces se trata de una la alteración. 
¿Qué herramientas adicionales podrían ser necesarias para detectar este incidente en particular? (sección 3.2.3)
· Software de detección de malaware y spam
· Antivirus
· Software para revisar la integridad de los archivos 
· Monitoreo de un tercero de los servicios
· Monitoreo de los accesos a sistemas operativos y sistemas de red
· Monitoreo de la comunicación de redes entre hosts. 
· Reportes constantes de los encargados de los sistemas, los de seguridad y otras organizaciones a los que se le spueda reportar los sincidentes
¿Cómo analizaría y validaría este incidente el equipo de respuesta a incidentes? ¿Qué personal estaría involucrado en el proceso de análisis y validación? (sección 3.2.4)
El equipo de respuesta de incidentes debe de revisar las alertas que se tuvieron en ese periodo donde se deben descartar los falsos positivos y evaluar lo legítimos, en el caso de notar un cambio en alguna base respecto a la modificación de los archivos identificar si este fue causado por un ataque o bien por un error humano. Se determina el evento y, si es necesario, se verifica con el demás personal técnico de seguridad. 
· Analizar los perfiles de redes y sistemas: Medir sus caracteristicas esperadas para notar cambios más fácilmente. 
· Entender los comportamientos normales con tal de identificar los raros.
· Crear una política de retención de acceso: Esto es cuánto tiempo se va a almacenar los datos de los anteriores ataques para un análisis posterior. 
· Tener sincronizados toso los relojes del host: Tiene como fin saber un tiempo específico en que se tiene acceso a un host y su posible ataque haciendo de manera más sencilla de analizar e identificar. 
· Mantener y utilizar una base de conocimientos de información con tal de poder referenciar los manipuladores durante un análisis.
· Filtrar los datos: investigar en lo mínimo la actividad más sospechosa filtrándolas por categorías, ya sea mostrando solo las más bajas o las más altas. El riesgo que tiene esto es que luego la actividad maliciosa puede n caer en las categorías de los indicadores elegidos. 
¿A qué personas y grupos dentro de la organización informaría el equipo del incidente? (sección 3.2.7)
· Director de la información
· Jefe de seguridad de la información
· Oficial de seguridad de la información local
· Equipos de respuesta a incidentes externos (ya que no sabemos quien filtro la información)
· Recursos humanos (en caso de haber sido trabajo interno)
· Departamento legal (si los documentos confidenciales pueden causar algun incidente legal)
· Agencias y sistemas federales operados bajo el gobierno federal (en el caso del ejemplo es el FBI)
¿Cómo priorizaría el equipo el manejo de este incidente? (sección 3.2.6)
· Considerar el impacto funcional del incidente: se debe analizar el estado actual y el posible impacto de no ser contenido e incidente inmediatamente. En este caso, se debió considerar el impacto de que esos documentos se vean publicados. 
· Impacto de la información del incidente: En este caso, afecta la confidencialidad de la información de la organización. Se debe considerar como es que estos resultados se infiltraron y si es información sensible. 
· Recuperación tras el incidente: Dependiendo del tamaño del incidente corresponde el tiempo quese necesitará para recuperarse. En este caso, se requerirá más recursos. 
Una vez categorizado el daño, se determina que la organización debe establecer un proceso escalonado donde se determina la respuesta a un incidente con un tiempo de respuesta. En este caso, una vez que se colabora con el FBI se determina la veracidad de los documentos, de ser verídicos, se busca como es que se expusieron y se protegen aún mas los archivos por medio de políticas y protocolos. 
Erradicación - Soluciones
¿Qué estrategia debe tomar la organización para contener el incidente? 
La contención es importante antes de que un incidente desborde los recursos o aumente los daños. 
Empezar inmediatamente a registrar todos los hechos relacionados con el mismo todos los hechos relacionados con el incidente
¿Por qué esta estrategia es preferible a otras? 
La contención proporciona tiempo para desarrollar una estrategia de reparación a medida. Una parte esencial de la parte esencial de la contención es la toma de decisiones (por ejemplo, apagar un sistema, desconectarlo de la red, desactivar determinadas funciones).
¿Y por qué? 
Una parte esencial de la contención es la toma de decisiones (por ejemplo, apagar un sistema, desconectarlo de la red, desactivar determinadas funciones).
(sección 3.3.1)
¿Qué podría pasar si el incidente no fuera contenido? 
Los documentos se harían públicos, afectando a la organización y también un 
atacante podría escalar el acceso no autorizado o comprometer otros sistemas.
¿Se contuvo/controló?
Si, se pudo detectar la actividad sospechosa, detectando por donde se estaban filtrando los documentos.
 (sección 3.3.1)
¿Qué personal estaría involucrado en los procesos de contención, erradicación y/o recuperación? 
El equipo de respuesta a incidentes debe discutir esta estrategia con su departamento legal para determinar si es factible.
(sección 3.3.1, 3.3.4)
¿Qué fuentes de evidencia, si las hay, debería adquirir la organización?
Aunque la principal razón para reunir pruebas durante un incidente es resolverlo, también pueden ser necesarias para un procedimiento judicial.
¿Cómo se adquirirían las pruebas? 
los ordenadores portátiles, las grabadoras de audio y las cámaras digitales también pueden servir para este propósito. Documentar los eventos del sistema, documentar los eventos del sistema, las conversaciones y los cambios observados en los archivos puede conducir a una gestión del problema más eficaz, más sistemática y menos propensa a errores. 
¿Dónde se almacenaría? 
El hardware original (por ejemplo, discos duros, sistemas comprometidos) que se almacena como prueba, así como los discos duros y los soportes extraíbles que se utilizan para guardar imágenes de disco.
¿Cuánto tiempo debe conservarse?
Los registros de gestión de incidentes deben conservarse durante tres años.
 (sección 3.2.5, 3.3.2, 3.4.3)
Post incidente
¿Quién asistiría a la reunión de lecciones aprendidas con respecto a este incidente? (sección 3.4.1)
La gerencia, el encargado de seguridad TI, el equipo de respuesta a incidentes, el encargado del área legal, jefe de seguridad.
¿Qué se podría hacer para evitar que incidentes similares ocurran en el futuro? (sección 3.1.2)
Primero realizar una lista con posibles ataques y dividirlos por categorías:
· Web
· Email
· Externo
· Ataque
· Robo
· Mal uso
· Perdida de quipo
· Otros
Con base en estas categorías hacer una evaluación de riesgos y de la seguridad, ya sea en el sistema, como físico, para detectar vulnerabilidades.
Con estas vulnerabilidades se debe hacer una priorización dependiendo el tipo de incidente que paso, así como que respuestas hay que realizar para evitar o detener en el momento.
Además en este caso analizar quien posiblemente este involucrado en la publicación de los archivos, ya sea que esa persona los sustrajera o ayudara a alguien externo.
¿Qué se podría hacer para mejorar la detección de incidentes similares? (sección 3.1.2)
La creación de un informe de seguimiento para cada incidente, que puede ser muy valioso para uso futuro. El informe proporciona una referencia que se puede utilizar para ayudar en el manejo de incidentes similares.
Las auditorías identificarán problemas y deficiencias que luego pueden corregirse. Como mínimo, una auditoría de respuesta a incidentes debe evaluar los siguientes elementos frente a las normas, políticas y prácticas generalmente aceptadas aplicables:
· Políticas, planes y procedimientos de respuesta a incidentes
· Herramientas y recursos
· Modelo y estructura del equipo
· Capacitación y educación del manejador de incidentes
· Documentación e informes de incidentes
· Las medidas de éxito discutidas anteriormente en esta sección
¿Cuál es la estrategia futura para tomar?
· Realizar un análisis de riesgo.
· prevención de malware
· Reforzamiento a la seguridad del host
¿Qué otros vectores se consideran de mayor riesgo?
· Acceso al servidor
· Perdida de un equipo con información
· Manipulación de equipo
Preguntas generales:
¿Cuántas personas y organizaciones se involucraron en este incidente? (sección 2.4.3)
Para este caso se involucraron dos organizaciones la organización en la cual se tiene registro de actividades sospechosas y la Oficina Federal de Investigaciones (FBI), en cuanto a las personas involucradas en el incidente por parte del FBI, son todos aquellos que monitorean la actividad de la organización y el agente del FBI que discutió sobre esta actividad, por parte de la organización, el equipo de respuesta a incidentes debe estar disponible para cualquiera que descubra o sospeche que ha ocurrido un incidente que involucre a la organización, en este caso el FBI, en donde uno o más miembros del equipo, según la magnitud del incidente, se encargarán del incidente, además es importante recordar que el éxito del equipo de respuesta a incidentes depende de la participación y cooperación de las personas de toda la organización.
¿A qué partes externas informaría el equipo del incidente? ¿Cuándo ocurriría cada informe? ¿Cómo se haría cada informe? ¿Qué información reportaría o no reportaría y por qué? (sección 2.3.2)
Con respecto a un incidente, el equipo de respuesta debe comunicarse con partes externas siempre que sea apropiado, como contactar a las fuerzas del orden público y buscar expertos externos. En este caso se debe discutir con las otras partes involucradas en la publicación de los documentos gubernamentales, como proveedores de servicios de Internet, el proveedor de software vulnerable u otros equipos de respuesta a incidentes. Además, el equipo de respuesta a incidentes debe analizar el intercambio de información con la oficina de asuntos públicos, el departamento legal y la gerencia de la organización, previamente para establecer políticas y procedimientos relacionados con el intercambio de información. También, el equipo debe documentar todos los contactos y comunicaciones con terceros a efectos de responsabilidad y evidencia. FISMA requiere que las agencias federales informen incidentes al equipo de preparación para emergencias informáticas de los Estados Unidos (US-CERT), que es una organización de respuesta a incidentes de todo el gobierno que ayuda a las agencias civiles federales en sus esfuerzos de manejo de incidentes. Cada agencia debe designar un POC primario y secundario con US-CERT e informar todos los incidentes de acuerdo con la política de respuesta a incidentes de la agencia. Las organizaciones deben crear una política que establezca quién está designado para informar incidentes y cómo se deben informar los incidentes. Los requisitos, categorías y plazos para informar incidentes a US-CERT se encuentran en el sitio web de US-CERT.
Cada organización debe crear su propia lista de elementos basada en varios factores, incluido su modelo y estructura de equipo de respuesta a incidentes y su definición del término "incidente".
A continuación, se muestra un listado sobre la información que se recopila para los informes de incidentes.
· Información de contacto para el informador y el encargado del incidente:Nombre, role, unidad organizativa, dirección de correo electrónico, número de teléfono y ubicación.
· Detalles del incidente: Fecha de cambio de estado/marcas de tiempo como cuándo comenzó el incidente, cuándo se descubrió/detectó el incidente, cuándo se informó del incidente, cuándo se detectó el incidente resuelto/terminado, etc. ubicación física del incidente, estado actual del incidente, origen/causa del incidente (si se conoce), incluidos nombres de host y direcciones IP, descripción del incidente (p. ej., cómo se detectó, qué ocurrió), descripción de los recursos afectados (p. ej., redes, hosts, aplicaciones, datos), incluidos los sistemas nombres de host, direcciones IP y función, si se conoce, categoría del incidente, vectores de ataque asociados al incidente e indicadores relacionados al, factores de priorización, factores atenuantes, acciones de respuesta realizadas, otras organizaciones contactadas.
· Comentarios generales.
¿Qué medidas tomó para este informe?
La organización debe tener algunos métodos para reportar de acuerdo con la sensibilidad del incidente, además se debe establecer un número de teléfono para reportar emergencias y se debe proporcionar una dirección de correo electrónico para la notificación informal de incidentes, también un formulario basado en la web puede ser útil para la notificación formal de incidentes. Además, es necesario proporcionar información confidencial al equipo mediante el uso de una clave publicada por el equipo para cifrar el material.
¿Qué otras comunicaciones con partes externas pueden ocurrir? (sección 2.3.2)
Para este caso, la organización puede necesitar la ayuda de un Proveedor de Servicio de Internet (ISP) para bloquear un ataque importante basado en la red e incluso rastrear su origen, también el equipo de incidentes puede necesitar hablar con un proveedor de software sobre actividades sospechosas, si los ataques se originan en el espacio de direcciones IP de una organización externa, posiblemente el equipo de incidentes debe comunicarse con los contactos de seguridad designados para la organización con el objetivo de alertarlos sobre la actividad o solicitar que recopilen pruebas, también es posible que otra organización experimento un incidente similar, entonces compartir información de manera proactiva puede facilitar un manejo de incidentes más eficaz y eficiente, además si el incidente afecta directamente a partes externas; En algunas jurisdicciones, las organizaciones deben notificar a todas las partes afectadas por un incidente de este tipo. Independientemente de las circunstancias, es preferible que la organización notifique a las partes externas afectadas.
¿Qué herramientas y recursos usaría el equipo para manejar este incidente? (sección 3.1.1)
La organización deberá contar con algunas herramientas y recursos específicos para el manejo del incidente, a continuación, se muestran algunas de las herramientas y recursos para el manejo de este incidente.
· Información de contacto de los miembros del equipo y otras personas dentro y fuera de la organización, como el FBI y otros equipos de respuesta a incidentes.
· Sistema de seguimiento de problemas para rastrear información de incidentes, estado, etc.
· Software de cifrado que se utilizará para las comunicaciones entre los miembros del equipo, dentro de la organización y con partes externas (FBI).
· Instalación de almacenamiento seguro para asegurar pruebas y otros materiales sensibles.
· Computadoras portátiles para actividades como el análisis de datos, la detección de paquetes y la redacción de informes.
· Estaciones de trabajo, servidores y equipos de red de repuesto que pueden usarse para muchos propósitos, como restaurar copias de seguridad.
· Rastreadores de paquetes y analizadores de protocolos para capturar y analizar el tráfico de red.
· Software forense digital para analizar imágenes de disco.
· Medios extraíbles con versiones confiables de programas que se utilizarán para recopilar evidencia de los sistemas.
· Listas de puertos, incluidos los puertos de uso común y los puertos de caballos de Troya
· Documentación para sistemas operativos, aplicaciones, protocolos y detección de intrusos y productos antivirus
· Diagramas de red y listas de activos críticos, como servidores de bases de datos.
· Acceso a imágenes de instalaciones limpias de SO y aplicaciones con fines de restauración y recuperación
¿Qué aspectos del manejo habrían sido diferentes si el incidente hubiera ocurrido en un día y hora diferentes (en horario versus fuera de horario)? (sección 2.4.2)
Para el manejo del incidente en este caso se debe considerar si la organización cuenta con el personal de respuesta a incidentes disponible las 24 horas del día, los 7 días de la semana, debido a que esto significa que es posible contactar al equipo de incidentes por teléfono o es posible la presencia del equipo en el sitio del incidente en donde la disponibilidad en tiempo real es lo mejor para la respuesta a incidentes porque cuanto más dura un incidente, mayor es el potencial de daños y pérdidas.
Por otro lado, la organización puede tener solo miembros del equipo de respuesta a incidentes en tiempo parcial, que actúan como un equipo de respuesta a incidentes con un manejo más virtual, es decir, cuando ocurre una emergencia, los miembros del equipo son contactados rápidamente y aquellos que pueden ayudar lo hacen. Para este caso los miembros del IT help desk, pueden actuar como un primer POC para informar incidentes, además pueden recibir capacitación para realizar la investigación inicial y la recopilación de datos y luego alertar al equipo de respuesta a incidentes.
Un aspecto muy importante es el costo, especialmente si se requiere que los empleados estén en el sitio las 24 horas del día, los 7 días de la semana dispuestas, disponibles, experimentadas y debidamente capacitadas para participar.
¿Qué aspectos del manejo habrían sido diferentes si el incidente hubiera ocurrido en una ubicación física diferente (en el sitio versus fuera del sitio)? (sección 2.4.2)
Con respecto al manejo de incidentes en diferentes ubicaciones, para este caso se debe considerar dónde está ubicado, qué tan rápido puede actuar el equipo de respuesta a incidentes en cualquier instalación y cuánto costará, además, se deben considerar las visitas al sitio en donde tal vez hay ciertas instalaciones o áreas donde no es posible que trabaje el equipo de respuesta. También, si se utiliza un subcontratista pueden surgir situaciones en las no esté disponible, por lo que la organización debe estar preparada para realizar su propio manejo de incidentes. 
Preguntas adicionales:
Describir los pasos y procedimientos a seguir en caso de rootkit. 
Describa los pasos y procedimientos en caso de que una persona filtre los datos. 
¿Qué políticas se necesitaban aplicar para el manejo de datos confidenciales? 
En caso de que sus expertos no puedan encontrar ninguna fuente de fuga, ¿qué sigue? 
¿Solo el FBI debe tomar parte en esta investigación?
Escenario 4
Morales Gonzalez Pedro Antonio.
García Samperio Janice Amairani. 
Medina Posadas Enrique. 
Pantoja Rodríguez Lizbeth. 
Ramirez Benitez Brayan. 
Zárate González Erik Daniel. 
Arredondo Carbajal Salvador.
“Un martes por la noche, un administrador de base de datos realiza un mantenimiento fuera del horario laboral en varios servidores de base de datos de producción. El administrador nota algunos nombres de directorio inusuales y desconocidos en uno de los servidores. Después de revisar las listas de directorios y ver algunos de los archivos, el administrador concluye que el servidor ha sido atacado y llama al equipo de respuesta a incidentes para obtener ayuda. La investigación del equipo determina que el atacante obtuvo con éxito acceso de root al servidor hace seis semanas”
Análisis
¿La organización consideraría esta actividad como un incidente? Si es así, ¿cuál de las políticas de la organización viola esta actividad? (sección 2.1)
¿Qué medidas existen para intentar evitar que ocurra estetipo de incidentes o limitar su impacto? (sección 3.1.2)
¿Qué precursores del incidente, si los hubiere, podría detectar la organización? ¿Algún precursor haría que la organización tomara medidas antes de que ocurriera el incidente? (sección 3.2.2, 3.2.3)
¿Qué indicadores del incidente podría detectar la organización? ¿Qué indicadores harían que alguien pensara que podría haber ocurrido un incidente? (sección 3.2.2, 3.2.3)
¿Qué herramientas adicionales podrían ser necesarias para detectar este incidente en particular? (sección 3.2.3)
¿Cómo analizaría y validaría este incidente el equipo de respuesta a incidentes? ¿Qué personal estaría involucrado en el proceso de análisis y validación? (sección 3.2.4)
¿A qué personas y grupos dentro de la organización informaría el equipo del incidente? (sección 3.2.7)
¿Cómo priorizaría el equipo el manejo de este incidente? (sección 3.2.6)
Erradicación - Soluciones
¿Qué estrategia debe tomar la organización para contener el incidente? 
Redirigir al atacante a un sandbox (una forma de contención) para que pueden monitorizar la actividad del atacante, normalmente para reunir pruebas adicionales.
¿Por qué esta estrategia es preferible a otras? 
La contención proporciona tiempo para desarrollar una estrategia de reparación a medida.
¿Y por qué? 
Para poder visualizar las modificaciones y tener las pruebas contundentes de las modificaciones realizadas y los accesos no permitidos.
(sección 3.3.1)
¿Qué podría pasar si el incidente no fuera contenido?
En este caso como se entró a la base de datos tiene acceso a nombres y registros 
 ¿Se contuvo/controló? 
Si, se puedo detectar los accesos y obtener las pruebas para deslidar responsabilidades.
(sección 3.3.1)
¿Qué personal estaría involucrado en los procesos de contención, erradicación y/o recuperación?
El equipo de respuesta a incidentes debe discutir esta estrategia con su departamento legal para determinar si es factible, además el administrador de la base de datos.
 (sección 3.3.1, 3.3.4)
¿Qué fuentes de evidencia, si las hay, debería adquirir la organización? 
La base de datos, antes del respaldo y después del respaldo, así como todos los cambios realizados durante esas 6 semanas.
¿Cómo se adquirirían las pruebas?
Los ordenadores portátiles, las grabadoras de audio y las cámaras digitales también pueden servir para este propósito. Documentar los eventos del sistema, documentar los eventos del sistema, las conversaciones y los cambios observados en los archivos puede conducir a una gestión del problema más eficaz, más sistemática y menos propensa a errores.
¿Dónde se almacenaría? 
El hardware original (por ejemplo, discos duros, sistemas comprometidos) que se almacena como prueba, así como los discos duros y los soportes extraíbles que se utilizan para guardar imágenes de disco.
¿Cuánto tiempo debe conservarse?
Los registros de gestión de incidentes deben conservarse durante 
tres años.
 (sección 3.2.5, 3.3.2, 3.4.3)
Post incidente
¿Quién asistiría a la reunión de lecciones aprendidas con respecto a este incidente? (sección 3.4.1)
El encargado de gobierno de Ti, gerente, el administrador de la base de datos y el jefe de seguridad.
¿Qué se podría hacer para evitar que incidentes similares ocurran en el futuro? (sección 3.1.2)
Analizar como es que se tuvo acceso si por medios externos, Email, Web, robo de equipo. Con base en eso realizar una revisión del sistema a nivel general para revisar que mas se modificó, checar las cámaras de seguridad por si el ataque se inicio desde dentro de la empresa o fuera, buscar las puerta por la que tuvo acceso y si hay personas involucradas (personal).
¿Qué se podría hacer para mejorar la detección de incidentes similares? (sección 3.1.2)
La creación de un informe de seguimiento para cada incidente, que puede ser muy valioso para uso futuro. El informe proporciona una referencia que se puede utilizar para ayudar en el manejo de incidentes similares.
Las auditorías identificarán problemas y deficiencias que luego pueden corregirse. Como mínimo, una auditoría de respuesta a incidentes debe evaluar los siguientes elementos frente a las normas, políticas y prácticas generalmente aceptadas aplicables:
•	Políticas, planes y procedimientos de respuesta a incidentes
•	Herramientas y recursos
•	Modelo y estructura del equipo
•	Capacitación y educación del manejador de incidentes
•	Documentación e informes de incidentes
•	Las medidas de éxito discutidas anteriormente en esta sección
¿Cuál es la estrategia futura para tomar?
•	Realizar un análisis de riesgo.
•	prevención de malware
•	Reforzamiento a la seguridad del host
¿Qué otros vectores se consideran de mayor riesgo?
•	Acceso al servidor
•	Perdida de un equipo con información
•	Manipulación de equipo
Preguntas generales:
¿Cuántas personas y organizaciones se involucraron en este incidente? (sección 2.4.3)
Respuesta:
En esta parte la descripción del escenario no detalla demasiado acerca de las condiciones extra de la problemática si no que redacta de forma directa el incidente. 
Sin embargo, con la información proporcionada los el primer involucrado en el incidente es el administrador de la base de datos debido que dentro de sus funciones esta realizar pruebas y evaluaciones periódicamente para garantizar la seguridad, privacidad e integridad de los datos. 
Debido a que en la descripción comenta que el atacante cibernético tuvo acceso a la base de datos desde hace seis semanas (mes y medio) era responsabilidad directa del administrador monitorear la base de datos y este al no percatarse y monitorear de forma correcta es el primer involucrado y responsable del incidente sucedido.
Esto antes mencionado es redactado y se afirma debido a la información proporciona, y es que también podría darse la situación de que existiera un área además del administrador de la base de datos que se dedicara exclusivamente al monitoreo de la base misma, sin embargo, no todas las organizaciones u empresas tienen un área destinada exclusivamente a esta parte, regularmente se le conoce como INFRA a esta área, a pesar de que es muy recomendable tenerla debido a la separación de funciones. Por lo que en este caso la responsabilidad recae directamente sobre el administrador y aunque estuviera esta área antes mencionada el administrador también tendría responsabilidad en esta parte ya que entra dentro de sus funciones gestionar la responsabilidad y la seguridad de la misma cumpliendo con la triada de Integridad, confidencialidad y disponibilidad de los datos de acuerdo a la norma ISO 27001 dedicada a la seguridad de la información.
Por otra parte, el área o equipo de respuesta a incidentes del cual hace referencia el incidente tiene dentro de sus funciones provee servicios y da soporte para prevenir, gestionar y responder ante los incidentes de seguridad de la información, sin embargo, el prevenir y evitar no es lo mismo, se tendría que hacer una auditoria y peritaje para evaluar que, en el caso ideal, este equipo haya hecho de forma exitosa su trabajo y aunque se presentó el incidente en caso de haber desempeñado sus funciones de forma exitosa, al ser reportados del incidente casi mes y medio después y percatarse del problema de seguridad aunque están involucrados no serían responsable directos .
¿A qué partes externas informaría el equipo del incidente? ¿Cuándo ocurriría cada informe? ¿Cómo se haría cada informe? ¿Qué información reportaría o no reportaría y por qué? (sección 2.3.2)
Se debe hacer un reporte indicando tanto el administrador de la base de datos como el equipo de respuesta a incidentes de su participación en el incidente.
El administrador debe realizar un informe de cuánto tiempo paso en detectar el error porque paso ese tiempo y la forma en que descubrió el error, esos aspectos deben de ir en el informe respondiendo las preguntas ¿Qué fue lo que paso?, ¿Cómo lo descubrió?, ¿Cuándo lo descubrió?, ¿Por qué paso ese tiempo en detectarlo?, ¿Dónde lo descubrió? Y el flujo que realizo para llegar a esa anomalía detectada.
El equipo de respuesta