blog

Con un escaneo de tipo ACK utilizando Nmap podría detectarse cuales puertos están filtrados. Sin embargo, este podría no determinar cuales de los puertos factibles de ser accedidos están abiertos o cerrados. Nmap ofrece muchos métodos para el escaneo, los cuales son buenos en el intento de evadir firewalls, al mismo tiempo proporcionaría la información requerida sobre el estado del puerto. El escaneo FIN es una de tales técnicas.

Para el siguiente ejemplo se utiliza una máquina con Windows Server 2012 R2. Únicamente se utiliza por defecto el firewall de Windows.

Se realiza un escaneo de tipo FIN utilizando Nmap contra el host.

# nmap -n -Pn -sF -v 192.168.0. 92

El resultado del escaneo realizado indica todos 1000 puertos escaneados están en estado abierto o filtrado.

Se sugiere intentar otros tipos de escaneos con Nmap, pues las reglas del firewall y el tipo de host, determinan cuales técnicas podrían funcionar.

A continuación se presentan los resultado de otros escaneos utilizando Nmap.

Null Scan

# nmap -n -Pn -sN -v 192.168.0. 92

Xmas Scan

# nmap -n -Pn -sX -v 192.168.0. 92

Window Scan

# nmap -n -Pn -sW -v 192.168.0. 92

Maimon Scan

# nmap -n -Pn -sM -v 192.168.0. 92

Para ninguno de los resultados producto de los escaneos realizados, se ha encontrado alguna diferencia o información adicional.

Todas estas técnicas de escaneo y otras más tienen una detallada documentación, la cual puede ser encontrada en el sitio web de Nmap.

Fuentes:

https://nmap.org/book/firewall-subversion.html
https://nmap.org/book/man-port-scanning-techniques.html

Generalmente el protocolo TCP es dominante para realizar los escaneos. Trabajar con UDP es frecuentemente más difícil porque el protocolo no proporciona un reconocimiento de los puertos abiertos, tal como sí lo hace TCP. Muchas aplicaciones UDP podrían simplemente ignorar paquetes inesperados, dejando a Nmap sin certeza de si el puerto está abierto o filtrado.

Para el siguiente ejemplo se utiliza una máquina con Windows Server 2012 R2. Únicamente se utiliza por defecto el firewall de Windows.

Se realiza un escaneo UDP por defecto contra el host, para determinar cuales puertos UDP están en estado abierto.

# nmap -n -Pn -v -sU 192.168.0. 92

En los resultados del escaneo se muestra el puerto UDP 137 en estado abierto. Así mismo la línea “Not shown: 999 open | filtered ports”, o traducido al idioma español; No mostrados: 999 puertos abiertos o filtrados; indican todos los demás puertos exceptuando el UDP 137 están en estado abierto o filtrado.

Una mejor manera de conocer cuales puertos están abiertos es enviar una gran cantidad de pruebas UDP, para docenas de diferentes servicios UDP conocidos, con la esperanza de generar una respuesta desde cualquier puerto abierto. Esto es exactamente lo hecho por el escaneo para la detección de versión, utilizando la opción “-sV”.

# nmap -n -Pn -v -sU -sV 192.168.0. 92

La detección de versión corrobora el puerto 137 UDP abierto encontrado con el escaneo simple UDP “-sU”. Los otros puertos siguen en estado “open|filtered”, porque no responden a ninguna de las pruebas. Probablemente estén filtrados, aunque esto no es seguro. Podrían ejecutar un servicio como SNMP, el cual únicamente responde hacia paquetes con la cadena de comunidad correcta. O podrían ejecutar un servicio UDP oscuro o personalizado, para el cual no existe en Nmap una prueba para la detección de versión. También anotar, este escaneo dura mucho más al escaneo anteriormente realizado. Enviar todas estas pruebas para cada puerto es relativamente un proceso lento. El añadir la opción “--version-intensity 0” podría reducir el tiempo de escaneo significativamente, únicamente enviando las pruebas más probables de generar una respuesta desde los servicios en un número de puerto definido.

Fuentes:

https://nmap.org/book/determining-firewall-rules.html
https://nmap.org/book/vscan.html

El escaneo ACK envía paquetes TCP con únicamente el bit ACK definido. Debido a los puertos están abiertos o cerrados, el sistema es requerido por el RFC 793 de responder con un paquete RST. Los firewalls bloqueando la prueba, de otro lado, usualmente no responden o envían de retorno un error ICMP de destino inalcanzable. Esta distinción permite a Nmap reporte los paquetes ACK están siendo filtrados. El conjunto de puertos filtrados reportados por un escaneo ACK de Nmap, es frecuentemente más pequeño a un escaneo SYN contra la misma máquina, porque los escaneos ACK son más difíciles de filtrar.

Muchas redes permiten conexiones salientes casi sin restricciones, pero requieren bloquear hosts de Internet iniciando conexiones a estas. El bloquear paquetes SYN entrantes (sin un bit ACK definido) es una manera fácil de hacerlo, pero aún permite el paso de los paquetes ACK. Bloquear estos paquetes ACK es más difícil, debido a no indican cual lado inició la conexión. Para bloquear paquetes ACK no solicitados (como los enviados por un escaneo ACK de Nmap), al tiempo de permitir paquetes ACK perteneciendo a conexiones legítimas, los firewalls deben vigilar de manera estática cada conexión establecida, para determinar si un ACK definido es apropiado. Estos firewalls de estado son usualmente más seguros porque pueden ser más restrictivos. El bloqueo de escaneos ACK es una restricción disponible adicional. Las desventajas son requerir más recursos para funcionar, y un reinicio de un firewall de estado puede causar el dispositivo pierda el estado y termine todas las conexiones establecidas atravesándolo.

Aunque los firewalls de estado están diseminándose y creciendo en popularidad, la perspectiva sin estado es bastante común. Por ejemplo, el sistema netfilter/iptables de Linux, soporta la opción “--syn”, para hacer la perspectiva sin estado descrita anteriormente fácil de implementar.

Para el siguiente ejemplo se utiliza una máquina con Windows Server 2012 R2. Únicamente se utiliza por defecto el firewall de Windows.

Se realiza un escaneo ACK contra el host, para determinar si está utilizando un firewall de estado.

# nmap -n -Pn -sA -v 192.168.0. 92

Se resalta la información obtenida en la línea “All 100 scanned ports are filtered”, o traducido al idioma español; todos los 1000 puertos escaneados están filtrados. La causa de esto es; únicamente se aceptan paquetes los cuales son parte o están relacionados hacia una conexión establecida. Los paquetes ACK no solicitados y enviados por Nmap son descartados.

El conocer como distinguir entre firewalls de estado y sin estado; ¿Porque es bueno esto?. El escaneo ACK puede mostrar algunos paquetes probablemente alcancen el host destino. Esto puede ser porque la falsificación del firewall es siempre posible. Si bien no se puede ser capaz de establecer conexiones TCP hacia aquellos puertos, estos pueden ser útiles para determinar cuales direcciones IP están en uso, pruebas para la detección del Sistema Operativo, ciertas manipulaciones ID de IP, y como un canal para hacer túnel a comandos para rootkits instalados en estas máquinas. Otros tipos de escaneos, como escaneo FIN, incluso puede ser capaz de determinar cuales puertos son abiertos, y por lo tanto inferir el propósito de estos hosts. Tales hosts pueden ser útiles como zombies para un escaneo “idle” ID de IP.

Fuentes:

https://nmap.org/book/determining-firewall-rules.html
https://nmap.org/book/firewall-subversion.html

Una característica útil del protocolo TCP es, por RFC 793 se requiere los sistemas envíen respuestas negativas para peticiones de conexión inesperadas, en la forma de un paquete TCP RST (reset) “reinicio”. El paquete RST permite los puertos cerrados sean fácilmente reconocidos por Nmap. Los dispositivos de filtrado como firewalls de otro lado, tienden a descartar paquetes destinados para los puertos deshabilitados. En algunos casos en su lugar, envían mensajes de error ICMP (usualmente “puerto inalcanzable”). Debido a los paquetes son descartados, y los errores ICMP son fácilmente distinguibles de paquetes RST, Nmap puede detectar puertos TCP filtrados, de aquellos abiertos o cerrados, y lo hace automáticamente.

Para el siguiente ejemplo se utiliza una máquina con Windows Server 2012 R2. Únicamente se utiliza por defecto el firewall de Windows.

# nmap -n -Pn -sS -v 192.168.0. 92

Una de las líneas más importantes es “Not shown: 995 filtered ports”, o traducido al idioma español; “No mostrado: 995 puertos filtrados”. En otras palabras, este host tiene una política del firewall de negación por defecto. Únicamente aquellos puertos, los cuales el administrador ha explícitamente permitido, son alcanzables, mientras la acción por defecto es negarlos (filtrarlos). Para este caso los cinco puertos mostrados están en estado “open” o abierto, los demás puertos son inalcanzables por este escaneo por defecto (filtrados).

Firewalls firtuvos devolviendo RST

Si bien la distinción de Nmap entre puertos TCP cerrados (los cuales retornan un paquete RST), y puertos filtrados (devolviendo nada o errores ICMP), es usualmente preciso, muchos dispositivos firewall son ahora capaces de falsificar paquetes RST, como si vinieran desde el host destino, alegando el puerto está cerrado. Un ejemplo de esta capacidad es el sistema iptables de Linux, el cual ofrece métodos para rechazar paquetes indeseables. Esta funcionalidad es “--reject-with type”.

El “tipo” puede ser “icmp-net-unreachable”, “icmp-host-unreachable”, “icmp-port-unreachable”, “icmp-proto-unreachable”, “icmp-net-prohibited” o “icmp-host-prohibited”, lo cual retorna un mensaje de error ICMP apropiado (por defecto puerto inalcanzable). La opción “tcp-reset” puede ser utilizada sobre reglas las cuales únicamente coinciden al protocolo TCP: esto causa un paquete TCP RST sea envía de vuelta. Siendo principalmente útil para bloquear pruebas “ident” (113/ftp), lo cual frecuentemente ocurre cuando se envía correo hacia servidores de correo defectuosos.

La falsificación de paquetes RST por firewalls e IDS/IPS no es particularmente común fuera del puerto 113, pues puede ser confuso para operadores legítimos de red, y también permite los escáneres pasen al siguiente puerto de inmediato, sin esperar el tiempo máximo causado por los paquetes descargados. Sin embargo esto sucede. Dicha falsificación puede usualmente ser detectado con un cuidadoso análisis del paquete RST en comparación con otros paquetes enviados por la máquina. Nmap tiene técnicas para esto.

Fuentes:

https://nmap.org/book/determining-firewall-rules.html
https://nmap.org/book/man-bypass-firewalls-ids.html
http://www.rfc-editor.org/rfc/rfc793.txt

La meta de una investigación es determinar los hechos describiendo lo ocurrido, como ocurrió, y en algunos casos, quien fue el responsable. Como un equipo comercial para respuesta de incidentes, el elemento “quien” puede no ser alcanzable, pero conocer cuando contratar ayuda externa o fuerzas legales es importante. Sin conocer los hechos, como la forma en la cual un atacante gana acceso hacia una red en primer lugar, o lo hecho por el atacante, no se está en una buena posición para remediar. Se puede sentir confortable simplemente desconectando el cable y reconstruir un sistema conteniendo malware, pero ¿se puede dormir en la noche sin conocer como el atacante ganó acceso, y aquello lo cual hizo?. Debido a todos valoramos el sueño, se debe desarrollar y refinar un proceso de cinco etapas, el cual promueve una investigación efectiva.

Tal vez sea mejo no actuar rápidamente

Durante una investigación, es probable se encuentre con descubrimientos, los cuales se considere requieran una acción inmediata. Normalmente el equipo para investigación inmediatamente reportará cualquier hallazgo crítico, hacia el individuo apropiado dentro de la organización afectada. El individuo debe sopesar el riesgo de actuar sin una comprensión suficiente de la situación versus el riesgo de actividades adicionales de investigación.

Por experiencia, en la mayoría de casos, es importante realizar un investigación adicional para poder conocer más información sobre la situación, y hacer una decisión apropiada. Esta perspectiva ciertamente tiene un riesgo, porque puede proporcionar al atacante con mayor oportunidad de causar daño. Sin embargo, se ha encontrado tomar medidas sobre información incompleta o información inexacta es mucho más arriesgado. No existe una respuesta final, y en cada incidente la organización debe decidir por si misma aquello aceptable.

Fuentes:

https://www.bankinfosecurity.com/tips-on-managing-incident-investigatio…
https://www.faronics.com/news/blog/incident-response-planning-7-stages-…

Las metas principales en la etapa denominada como respuesta inicial, incluyen ensamblar el equipo para la respuesta de incidentes, revisar los datos disponibles basados en red, y otros datos disponibles, determinar el tipo de incidente, además de evaluar el impacto potencial. La meta es reunir suficiente información inicial, lo cual luego permita al equipo de respuesta de incidentes determinar la respuesta apropiada. Típicamente esta etapa no involucra recolectar datos directamente desde el sistema afectado.

Los datos examinados durante esta etapa usualmente involucra la red, logs (archivos registrando sucesos o eventos), y otra evidencia histórica y contextual. Esta información proporciona el contexto necesario para ayudar a decidir la respuesta apropiada. Por ejemplo, si un troyano bancario es encontrado en la laptop del CEO, la respuesta probablemente sea algo diferente a si se encontrase en el sistema del recepcionista. Además, si se requiere una investigación completa, esta información será parte de las pistas iniciales. Algunas tareas comunes a realizar durante esta etapa son:

• Entrevistar a la persona(s) quien reportó el incidente. Obtener todos los detalles relevantes factibles de obtener
• Entrevistar al personal de TI, quien pueda tener una idea sobre los detalles técnicos del incidente
• Entrevistar al personal de la unidad de negocios, quien podría proporcionar un contexto para el incidente
• Revisar la red y logs de seguridad, para identificar datos los cuales pueden respaldar el incidente suscitado
• Documentar toda la información recolectada desde las fuentes

Fuentes:

https://www.sans.org/reading-room/whitepapers/incident/paper/1516
https://en.wikipedia.org/wiki/Computer_security_incident_management

El proceso para respuesta de incidentes está constituida de todas las actividades necesarias para lograr las metas de una respuesta de incidentes. El proceso global y las actividades deben ser bien documentadas, y entendidas por el equipo de respuesta, como también por las partes interesadas en la organización. El proceso está constituido de tres actividades principales, y se sugiere contar con personal dedicado a cada una de estas:

• Respuesta inicial
• Investigación
• Remedición

La respuesta inicial es una actividad la cual típicamente inicia todo el proceso para respuesta de incidentes. Una vez el equipo confirma el incidente se está suscitando, realiza la recolección inicial y las etapas de la respuesta, además la investigación y esfuerzos de remediación son usualmente ejecutadas de manera concurrente.

El propósito del equipo de investigación es únicamente realizar tareas de investigación. Durante la investigación, este equipo continuamente genera una lista la cual se denomina “Guías”. Estos “guías” son elementos como robo de datos, indicadores de red, identidades de sujetos, o problemas los cuales condujeron al compromiso o incidente de seguridad.

Estos elementos son inmediatamente útiles para el equipo de remediación, cuyos propios procesos requieren una significativa cantidad de tiempo para coordinar y planificar. En muchos casos, la actividad observada por el equipo puede obligar a tomar acción inmediata, para detener el avance de una intrusión.

Fuentes:

https://digitalguardian.com/blog/five-steps-incident-response
https://www.sans.org/reading-room/whitepapers/incident/incident-handler…

Contratar personal bueno es una tarea difícil para muchos gerentes. Si se tiene un equipo y se está creciendo, identificar buen talento puede ser más fácil: pues se tienen personas quienes pueden evaluar las capacidades y personalidad del postulante. Adicionalmente, un precedente ha sido establecido, y se está ya familiarizado con los roles requeridos, además de tener en mente los candidatos ideales para cada uno. Si se encuentra en una situación demasiado común; de un profesional en seguridad de la información a quien se le ha recomendado la tarea de crear un pequeño equipo para respuesta de incidentes, ¿Por donde iniciar?. Se sugiere un proceso de dos etapas: encontrar candidatos, para luego evaluarlos para calificarlos y encajarlos dentro de la organización.

Encontrar candidatos: Reclutar individuos de otros equipos para respuesta de incidentes es la opción obvia. Publicar posiciones abiertas en sitios como LinkedIn es bueno, pero una forma pasiva de llegar hacia los candidatos potenciales. Sin embargo, la orientación proactiva de los grupos técnicos, sitios de redes sociales relacionados, y tablones de mensajes, podría conducir a resultados más rápidos. Muchos profesionales forenses y para respuesta de incidentes de todos los niveles de habilidad, asechan en los tablones de anuncios.

Si se tienen los recursos para contactarse con las oficinas de carreras de las universidades locales, los analistas de nivel de entrada y miembros del equipo, pueden ser reclutados desde estos programas de ciencias de computación, ingeniería o forense de computadoras. Las habilidades fundamentales proporcionan el mayor beneficio para este campo, pues son las mismas a la mayoría de ciencias; observación, comunicación, clasificación, medición, inferencia y predicción. Los individuos quienes poseen estas habilidades típicamente suelen ser los mejores miembros del equipo para respuesta de incidentes. Si se puede encontrar una universidad local enfocada primero en ciencias básicas o habilidades de ingeniería, además de proporcionar seminarios, o tópicos electivos relacionados al forense, se estará en buena forma.

Evaluar lo adecuado. Capacidades y Cualidades: ¿Cuales capacidades se requieren en el equipo para respuesta de incidentes?. Generalmente se requiere un equipo completo de personas multitarea, personas con conocimiento y habilidades para moverse entre las diferentes fases de una investigación. Buscando a través del grupo propio de consultoría, se puede encontrar un número de conjuntos con habilidades relevantes sugeridas. Si se está contratando candidatos experimentados, se debe considerar a personas con las siguientes calificaciones:

• Experiencia en realizar investigaciones involucrando tecnología: Esta es una habilidad de amplio espectro, la cual abarca información y gestión, la habilidad de enlace con otras unidades de la empresa, gestión de evidencia y datos, y experiencia técnica básica.
• Experiencia en realizar exámenes forenses de computadoras: Esto incluye familiaridad con los fundamentos de los sistemas operativos, conocimiento del sistema operativo y artefactos de las aplicaciones, análisis de logs, y la habilidad de escribir una documentación coherente.
• Experiencia en el análisis del tráfico de red. Esto incluye experiencia con exámenes del tráfico de red y análisis de protocolos, además de la tecnología para utilizar la información en un sistema para la detección.
• Conocimiento de las aplicaciones relevantes de la industria para la organización: La mayoría de compañías tienen sistemas de información especializados, los cuales procesan datos sobre plataformas específicas de la industria (por ejemplo transacciones financieras alojadas en un main-frame).
• Conocimiento de TI empresarial: En la ausencia de una plataforma empresarial para respuesta de incidentes, nada supera a un administrador quien puede crear un script de dos líneas para buscar cada servidor bajo su control.
• Conocer de análisis de código malicioso: El análisis de malware es una habilidad importante a tener en el equipo; sin embargo, muchos equipos para respuesta de incidentes, puede realizar un análisis básico automático utilizando una sandbox. Si se tienen tres puestos disponibles, contratar uno multitarea, el cual tenga habilidades básicas de triaje.

¿Cuales cualidades se buscan en un miembro de un equipo para respuesta de incidentes?. Durante las entrevistas se intenta descubrir si el potencial candidato tiene las siguientes características:

• Altamente analítico
• Buen comunicador
• Atención a los detalles
• Una perspectiva estructurada y organizada para resolver problemas
• Éxito demostrable para resolver problemas

Frecuentemente se consulta sobre la aplicación o relevancia de las diversas certificaciones dominando los campos de la respuesta de incidentes y el forense de computadoras. Generalmente las certificaciones requieren una prueba periódica, y demostración de una educación continúa como un buen indicador, de la persona está activamente interesada en el campo. Cuando el currículum del postulante incluye poca experiencia, esto puede ayudar a determinar cuales áreas en sus antecedentes se discuten en detalle durante las entrevistas. Además esto da un indicador de las habilidades de comunicación y estilo de escritura del postulante. Sin embargo, no parece ser un indicador consistente de las verdaderas habilidades del postulante. De hecho, se pueden encontrar relaciones inversas entre la profundidad en el conocimiento del postulante, y el número de certificaciones poseídas, cuando su historial de empleo es sólido. Los proveedores de certificaciones son generalmente irrelevantes para el proceso de contratación, porque demuestran habilidades en herramientas específicas, opuesto a una teoría sólida y habilidades en procedimientos.

Fuentes:

https://blog.demisto.com/5-tips-on-hiring-and-retaining-the-right-cyber…
https://www.csoonline.com/article/3237732/how-to-hire-top-cybersecurity…

Al trabajar para una compañía proporcionando servicios de consultoría para otras organizaciones, quienes enfrentan problemas de seguridad de la información. En base a esto, se esperaría apoyar plenamente la contratación de consultores para ayudar a resolver un incidente. Sería como preguntarle a un representante de una marca de autos, si debemos comprar su último modelo. La respuesta directa a la pregunta de si una empresa debe utilizar servicios de una empresa consultora, o depender plenamente de esta, depende de muchos factores:

• Costo de mantener el equipo de respuesta de incidentes: A menos el ritmo de operaciones sea alto y produzca resultados demostrables, muchas compañías no puede pagar o justificar los gastos generales de mantener personas experimentadas para respuesta de incidentes.
• Cultura de subcontratación: Muchas organizaciones subcontratan funciones de la empresa, incluyendo servicios de TI. No es de sorprender varias empresas muy importantes subcontratan la vasta mayoría de sus servicios de TI.
• Mandato de regulación o autoridades de certificación: Un ejemplo de una parte externa la cual puede dictar como responder es PCI. Si la compañía trabaja o está involucrada en la industria de pago con tarjetas, esta organización requiere firmas “aprobadas” para realizar una investigación.
• Falta de experiencia en investigaciones: La contratación de los servicios de una firma consultora, puede ser la mejor manera de iniciar el propio equipo para respuesta de incidentes. Ejecutar las investigaciones es una habilidad altamente experimental, la cual mejora con el tiempo.
• Falta de o limitada especialización interna: Las investigaciones, en particular investigaciones de intrusión, requieren un amplio rango de habilidades, desde familiaridad con el funcionamiento interno de los sistemas operativos, aplicaciones, y redes, hasta análisis de malware y proceso de remediación

Con la excepción de una situación en la cual una empresa virtualmente no tiene capacidades internas de TI, se pueden encontrar organizaciones las cuales ensamblan un equipo de respuestas de incidentes por si mismos, aunque informalmente, tienen un mejor oportunidad de una investigación exitosa y resolución oportuna. Esto es cierto, incluso si el equipo de respuesta de incidentes está configurado para maneja únicamente las fases iniciales de un investigación, mientras está comprometida asistencia externa.

Fuentes:

https://www.pcisecuritystandards.org/

La respuesta de incidentes (IR) es un disciplina multifacética. Esto demanda capacidades lo cual requiere recursos desde varias unidades operacionales en una organización. El personal de recursos humanos, el asesor legal, equipo de TI, relaciones públicas, profesionales de seguridad, oficiales corporativos de seguridad, gerentes de negocio, trabajadores de mesa de ayuda y otros empleados, pueden verse involucrados en la respuesta hacia incidentes de seguridad en computadoras.

Durante un evento de respuesta de incidentes, la mayoría de compañías ensamblan equipos de individuos, los cuales realizan una investigación y remediación. Un gerente experimentado de incidentes, preferiblemente alguien quien tenga la capacidad de dirigir hacia otras unidades de negocios durante la investigación, lidera el equipo de investigación. La importancia del último punto no puede exagerarse. El gerente de incidentes debe ser capaz de obtener información o solicitar acciones a tomarse, de una manera oportuna por cualquier recursos a través de toda la organización. Estos individuos son frecuentemente los CIO, CISO, o alguien a quien directamente designan para tratar en su nombre. Esta persona se convierte en el punto focal de todas las actividades de investigación, y gestiona el estado de numerosas tareas además de las solicitudes generadas. Un individuo experimentado es el punto focal para todas las actividades de remediación, incluyendo acciones correctivas derivadas desde los hallazgos del equipo de investigación, la evaluación de la sensibilidad de los datos robados, y cambios estratégicos para mejorar la postura de seguridad de la organización.

Muchas organizaciones adoptan un enfoque escalonado y mixto para dotar de personal a los equipos de investigación y remediación. Ensamblados y dedicados durante el curso de la investigación, los equipos principales frecuentemente consisten de un persona de TI de alto nivel, especialmente aquellos con experiencia y revisión de registros, análisis forense, y habilidades en triaje de malware. El equipo de investigación debe tener la habilidad para acceder rápidamente a los repositorios de los registros de eventos, configuraciones de los sistemas, y si existe una plataforma de respuesta de incidentes disponible, autoridad para conducir búsquedas por material relevante. Este grupo central de individuos puede incluir también consultores para llenar vacíos operativos. Notar puede ser aceptable los consultores lideren la investigación táctica si su experiencia lo amerita. El equipo de remediación debe tener la autoridad para dirigir la organización realice los cambios necesarios para recuperarse desde el incidente.

Los equipos auxiliares quienes se ensamblan según sea necesario, generalmente no requieren personal dedicado a la investigación o remediación. Sus contribuciones al proyecto son típicamente tareas orientadas y realizadas según lo requerido por el gerente de incidentes. Miembros comunes de los equipos auxiliares incluyen:

• Representantes de asesores internos y externos
• Oficiales de cumplimiento de la industria (Por ejemplo; PCI, HIPPA; FISMA y NERC)
• Miembros del equipo de soporte de TI para servidores y escritorio
• Miembros del equipo de infraestructura de red
• Gerentes de línea de negocios
• Representantes de recursos humanos
• Personal de relaciones públicas

Aunque la constitución de los equipos centrales para investigación y remediación merecen un tema aparte. Se debe tener en consideración, las relaciones y expectativas deben establecerse por adelantado. El peor momento para conocer los requisitos de un abogado o personal de cumplimiento es en el medio de una investigación. Se estará mejor si se toma el tiempo para identificar todos los requisitos de reporte y procesos aplicables a la industria.

¿Con qué se debería estar familiarizado desde la perspectiva de cumplimiento?. Si aún no se ha reunido con el personal interno de cumplimiento, quien bien puede ser el asesor legal, tomarse un día para conversar sobre el ciclo de vida de un incidente. Entender cuales sistemas de información caen dentro del alcance y, cuales requerimientos de reporte existen. En algunas situaciones, la pregunta del alcance ha sido abordado a través de otros medios (por ejemplos evaluaciones PCI DSS). Entender quien debe ser informado de una posible intrusión o brecha, y cuales son los umbrales de notificación definidos por el gobierno. Más importante, identificar a la parte responsable interna de todas las comunicaciones externas, y asegurarse los equipos estén empoderados para hablar francamente hacia estos tomadores de decisiones.

El asesor interno debe ayudar a determinar los umbrales de notificación con lo cual se sienta confortable. Los diversos parámetros (tiempo de identificación de un evento, probabilidades de exposición de datos, el alcance de la potencial exposición), pueden no coincidir con los establecidos por terceros.

Fuentes:

https://www.ncsc.gov.uk/collection/incident-management/cyber-incident-r…
https://securityintelligence.com/what-is-incident-response-orchestratio…