blog

En muchas grandes organizaciones e incluso en algunas de tamaño pequeño o mediano, se han encontrado buenas probabilidades de al menos algunas de las funciones de TI sean subcontratadas. Si una investigación requiere una tarea sea realizada por un proveedor externo, pueden existir muchos desafíos para realizar el trabajo. Usualmente se implementan procesos para los requerimientos laborales, los cuales pueden requerir planificar proyectos, aprobación, y otro tipo de trámites. También pueden existir costos adicionales, algunas veces cargados por sistema, para cambios menores de configuración como reglas del firewall.

En algunos casos puede no existir un vehículo para cumplir una tarea requerida, porque cae fuera del alcance correspondiente al contrato. Se pueden experimentar situaciones donde se requiera los archivos logs de la organización desde un servicio subcontratado para su análisis. Estos desafíos pueden prevenir la investigación avance de manera efectiva.

Cada organización debe hacer su trabajo con sus respectivos proveedores para asegurarse se incluyan SLAs o Acuerdo para los Niveles de Servicio, para responder a peticiones críticas, además de opciones para realizar trabajos los cuales estén fuera del alcance del contrato. Sin los acuerdos apropiados se puede estar indefenso en casos de emergencia.

Fuentes:

https://www.dflabs.com/resources/blog/incident-response-solutions-in-ho…
https://pdfs.semanticscholar.org/aca8/2a29f64bc4024bc9aefc012d54ef6b933…

Cada etapa de la investigación realizada por un equipo durante una respuesta de incidentes es impactado por políticas, las cuales deben ser definidas mucho antes de ocurra la primera notificación. En muchas situaciones, las políticas para la seguridad de información son escritas y ejecutadas por el consejero legal de la organización, en cooperación con la oficina del CISO y oficiales de cumplimiento. Las políticas típicas incluyen:

Políticas de Uso Aceptable: Gobierna cual es el comportamiento esperado para cada usuario

Políticas de Seguridad: Establece expectativas para la protección de datos y recursos dentro de la organización. Subsecciones de esta política deben abordar asuntos de seguridad de datos, físicos y electrónicos.

Políticas de Acceso Remoto: Establece quien puede conectarse hacia los recursos de la organización, y cuales controles son implementados sobre las conexiones.

Políticas de Uso de Internet: Establece un uso apropiado general de los recursos de Internet, incluyendo expectativas de privacidad y notificación para la vigilancia por parte de la organización o en su nombre.

Las políticas por las cuales los equipos para respuesta de incidentes deberían estar más preocupadas, son sobre las expectativas de la búsqueda y captura de recursos propiedad de la compañía, además de la interceptación del tráfico de red. Si estos dos temas (ciertamente generales) son abordadas, el equipo debe ser capaz de realizar muchas acciones de investigación. Es importante considerar las leyes locales afectando el accionar. Una acción realizada en una oficina puede estar en contra de alguna ley.

Fuentes:

https://www.sans.org/information-security-policy/
https://www.iso.org/home.html

Las etapas iniciales de una preparación previa a incidentes involucra obtener una gran imagen del riesgo corporativo. ¿Cuales son los activos críticos?. ¿Cual es la exposición?, ¿Cual es la amenaza?,¿Cuales requerimientos de regulación debe cumplir la organización? (Estos generalmente tienen algún riesgo asociados). Identificando el riesgo, se puede asegurar de invertir recursos para la preparación de incidentes, los cuales son los más probables afecten a la empresa. Los activos críticos son las áreas dentro de la organización, los cuales son críticos para el funcionamiento continuo de la organización. A continuación algunos ejemplos de activos críticos:

Reputación corporativa: ¿Los consumidores seleccionan sus productos y servicios en parte debido a su confianza en la capacidad de la organización de mantener sus datos seguros?

Información confidencial de la empresa: ¿Se tiene planes críticos de marketing o una formula secreta de producto?, ¿Dónde se almacenan sus patentes, código fuente, u otra propiedad intelectual?

Información personal identificable: ¿La organización almacena o procesa datos de información personal identificable (PII)?

Datos de cuentas de pago: ¿La organización almacena o procesa datos de PCI?

Los activos críticos son aquellos los cuales producen la mayor responsabilidad o pérdida potencial para la organización. La responsabilidad ocurre a través de la exposición. Considerar lo generado por la exposición de las personas, procesos, o tecnología, o como contribuye a su pérdida. Ejemplos de exposición incluyen servidores web sin parches, sistemas de cara hacia Internet, empleados descontentos, o empleados no entrenados.

Otro factor contribuyente es quien puede actualmente explotar estas exposiciones; ¿Alguien conectado hacia Internet?, ¿Alguien con acceso físico hacia el edificio corporativo?, ¿Únicamente individuos físicos dentro de una área segura?. Combinar estos factores para priorizar el riesgo. Por ejemplo, los activos más críticos con exposiciones accedibles únicamente por personas de confianza dentro de un entorno físico controlado, puede presentar menos riesgo comparado con activos con exposición accedible hacia Internet.

La identificación del riesgo es critico porque permite invertir recursos en una manera más eficientes. No todos los recursos dentro del entorno deben ser asegurados el mismo nivel. Lo activos introduciendo el mayor riesgo reciben más recursos.

Fuentes:

https://www.dhs.gov/xlibrary/assets/itsrm-for-provide-incident-manageme…
https://www.oreilly.com/library/view/incident-response/0596001304/ch01s…
https://www.bankinfosecurity.com/blogs/cybersecurity-incident-response-…

Los reportes son los documentos fundamentales para los clientes. Crear buenos reportes toma tiempo, el cual muchas veces se podría pensar es mejor dedicarlo a otras tareas. Sin embargo, sin los reportes es fácil perder el rastro de aquello hecho. Es importante considerar; incluso dentro de una única investigación pueden existir muchos hallazgos, los cuales deben ser comunicados completamente sobre la investigación, lo cual podría ser difícil sin un reporte formal y periódico. En muchas investigaciones los hallazgos de alto nivel se basan en numeroso hechos técnicos, sin la documentación adecuada puede ser difícil comunicarlos.

Los reportes también son el principar documento entregado para los equipos de respuesta de incidentes, por las siguientes razones. Los reportes no solo proporcionan resultados documentados de los esfuerzos, sino también ayudan a mantenerse enfocado y realizar investigaciones de calidad. Se sugiere utilizar una plantilla estándar y seguir directrices para reportes y lenguaje, lo cual tiende a hacer más consistente el reporte. El reporte fuerza a reducir la velocidad, documentando los hallazgos en una manera estructurada, verificar la evidencia, y pensar sobre lo ocurrido.

Casi todo el mundo ha experimentado una interesante consecuencia de la documentación. Esto es similar hacia aquello ocurrido cuando se debate sobre escribir una tarea en una lista de tareas para hacer. Si no se escribe la tarea existe una alta probabilidad de olvidar hacerla. Una vez realiza el proceso físico de escritura, es probable no se deba mirar nuevamente la lista escrita, pues ya se la recuerda. Es muy importante escribir notas informales o reportes formales, pues ayuda a recordar más, lo cual hacer mejor a las investigaciones.

Fuentes:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2…
https://bok.ahima.org/PdfView?oid=76732
https://security.berkeley.edu/incident-response-planning-guideline

Muchos de lo desafíos para una respuesta de incidentes efectiva no son técnicos. El mantenerse organizado es uno de estos retos, siendo especialmente grande. Tal vez el termino “conciencia de la situación” no sea agradable, pero es de lo cual se habla. Las investigaciones deben tener un mecanismo para rastrear de manera fácil información y compartirla con los equipos auxiliares, además del líder de la organización. También se debe tener una manera para referirse específicamente a los incidentes, aparte de “todo comenzó el último martes”. Se debe establecer una numeración o sistema de nombramiento para incidentes y utilizarlo para su referencia, además de documentar cualquier información o evidencia relacionada hacia un incidente específico.

¿Qué es “información signficativa de investigación”?. Se han encontrado algunos puntos de datos útiles los cuales son críticos para cualquier investigación. Estos elementos deben ser rastreados en tiempo real tan cercanamente como sea posible, porque los miembros del equipo los utilizarán como una “verdad fundamental” cuando se trate el estado de la investigación actual. Estos datos también son lo primero lo cual miembros del equipo referirán cuando provengan consultas desde la gerencia.

Lista de evidencia recolectada: Esto debe incluir la fecha y hora de la recolección además de la fuente de datos, ya sea una persona o un servidor. Asegurarse la cadena de custodia se mantiene para cada elemento. Mantener una cadena de custodia de cada elemento, y su presencia en una lista como un indicador del elemento ha sido manejado adecuadamente.

Lista de sistemas afectados: Rastrea como y cuando un sistema fue identificado. Anotar “afectado” incluye sistemas los cuales son sospechosos de un compromiso de seguridad, como también aquellos en los cuales simplemente se accede desde una cuenta sospechosa.

Lista de archivos de interés: Esta lista usualmente contiene solo software malicioso, pero también puede contener archivos de datos o resultados de comandos capturados. Rastrear el sistema donde un archivo fue encontrado, como también los metadatos del archivo.

Lista de datos accedidos o robados: Incluye nombres de archivos, contenido, y fecha de la exposición sospechosa.

Lista de actividad significativa del atacante: Durante el examen de una respuesta en vivo o datos forenses, se puede descubrir actividades significativas como logins o ejecución de malware. Incluir el sistema afectado además de la fecha y hora del evento.

Lista de IOCs basados en red: Rastrear direcciones IP relevantes y nombres de dominio.

Lista de IOCs basados en host Rastrear cualquier característica necesaria para formar un indicador bien definido.

Lista de cuentas comprometidas: Asegurarse de rastrear el alcance del acceso de cuentas, local o de todo el dominio.

Lista las tareas realizándose y las solicitadas por los equipos: Durante las investigaciones, usualmente se tienen tareas pendientes en cualquier momento. Desde peticiones por información adicional desde equipos auxiliares, hasta exámenes forenses, lo cual puede fácilmente dejar algo sin atender si no se está correctamente organizado.

Se puede utilizar una hoja de cálculo, o utilizar una interfaz web optimizada para múltiples usuarios. Es factible construir un sistema personalizado, pues tal vez no se encuentre una solución para la gestión de incidentes y casos el cual satisfaga nuestros requerimientos. Independientemente de aquello lo cual se decida utilizar en la organización, debe simplificarse tanto como sea posible los procesos.

Fuentes:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2…
https://www.sans.org/reading-room/whitepapers/incident/paper/36092

Los planes para remediar variarán enormemente dependiendo de las circunstancias del incidente e impacto potencial. El plan debe tener en consideración factores desde todos los aspectos de la situación, incluyendo el legal, empresarial, político, y técnico. El plan también debe incluir un protocolo de comunicación el cual defina quien en la organización dirá que y cuando. Finalmente el tiempo para remediar es crítico. El remediar tan pronto como sea posible, podría fallar en considerar información nueva o por descubrir. Al remediar muy tarde podría ocurrir un daño considerable, o el atacante podría cambiar de tácticas. Se debe considerar el mejor momento para comenzar a remediar, es cuando los métodos para la detección implementados entran en un estado estable. Es decir la instrumentación configurada con los Indicadores de Compromiso dejan de alertar sobre nuevos eventos únicos.

Se recomienda iniciar la planificación para remediar lo antes posible durnte el proceso para respuesta de incidentes, de tal manera se evite sobrecargar el equipo y cometer errores. Algunos incidentes requieren un esfuerzo significativamente mayor en lo referente a las actividades para remediar comparado con la investigación real. Existen muchas partes moviéndose en cualquier organización, y emprender la coordinación para remover la amenazas no es una tarea fácil. La perspectiva a implementar es definir las actividades apropiadas a realizar para cada una de las siguientes tres áreas:

• Postura
• Táctico (Corto plazo)
• Estratégico (Largo plazo)

La postura es el proceso de tomar pasos los cuales ayuden a asegurar el éxito para remediar. Actividades como establecer el protocolo, intercambiar información de contacto, diseñar las responsabilidades, incrementar la visibilidad, programar los recursos, y coordinar las cronologías, son todas parte de la etapa correspondiente a la postura.

La táctica consiste en tomar las acciones consideradas apropiadas para abordar el incidente actual. Las actividades pueden incluir reconstruir los sistemas comprometidos, cambiar las contraseñas, bloquear direcciones IP, información a los clientes de la brecha, hacer un anuncio interno y público, y cambiar un proceso del negocio.

Finalmente a través de una investigación, las organizaciones podrían típicamente notar áreas en las cuales mejorar. Por lo tantono se debe intentar arreglar cada problema de seguridad descubierto durante un incidente. Se sugiere hacer una lista de tareas pendientes para luego abordarlas cuando termine el incidente.

La porción estratégica de remediar aborda todas estas áreas, los cuales comúnmente son mejorar a largo plazo, los cuales pueden requerir cambios significativos dentro de una organización. Aunque el remediar de manera estratégica no es parte del ciclo de vida estándar para respuesta de incidentes, se menciona aquí para conocer esta categoría, y considerar utilizarla para ayudar a mantenerse enfocado en aquello importante.

Fuentes:

https://cipher.com/blog/the-core-phases-of-incident-response-remediatio…
https://www.nttsecurity.com/docs/librariesprovider3/resources/emea_solu…

Analizar datos es el proceso de tomar la evidencia preservada en la etapa previa, y realizar un examen enfocado en responder las preguntas de la investigación. Los resultados del análisis son normalmente documentadas en un reporte formal. Esta etapa en el ciclo de vida para respuesta de incidentes es donde usualmente se invierte la mayor parte del tiempo. La organización debe decidir cual análisis realizar por si mismo, o cuales porciones si lo hubiera se tercerizan. Las tres principales áreas para el análisis de datos son:

Análisis de malware: Durante la mayoría de investigaciones se encuentra con archivos sospechosos de malware. Se debe tener un equipo dedicado al análisis de malware, quien se encargará de analizar estos archivos. Producirán reportes los cuales incluyan indicadores de compromiso, además de una descripción detallada de la funcionalidad. Aunque tener un equipo dedicado a malware no se ajusta a la mayoría de presupuestos, las organizaciones deben considerar invertir en una capacidad básica para hacer triaje a malware sospechoso.

Análisis de respuesta en vivo: El examen de los datos recolectados en la respuesta en vivo es una de las etapas más críticas del análisis durante una investigación. Si se está buscando por datos de una respuesta en vivo, esto es normalmente porque existe algún indicio de actividad sospechosa en un sistema, pero existen detalles limitados. Durante el análisis se tratará de encontrar más pistas y explicación de lo ocurrido. Si se pierden detalles en esta etapa, el resultado podría ser se pase por alto una parte de la actividad del atacante, o se descarte el sistema por completo. Los resultados de un análisis de respuesta en vivo debe ayudar a entender el impacto de un acceso no autorizado hacia el sistema, y podría directamente impactar los siguientes pasos. Cada organización realizando funciones de seguridad en TI debe tener una capacidad básica para análisis de respuesta en vivo.

Examen forense: Un examen forense realizado sobre imágenes de disco durante una respuesta de incidentes, es una tarea enfocada y urgente. Cuando las balas están volando, no se tiene tiempo para realizar un examen completo y metodológico. Normalmente se escribe un conjunto de preguntas las cuales deben ser respondidas, decidir sobre una perspectiva requerida para descubrir información útil para responderlas, para luego ejecutar. Si no se obtienen respuestas, se debe utilizar una perspectiva diferente, pero esto depende sobre cuanto tiempo se tiene, y aquello esperado de obtener. Esto no quiere decir no se debe invertir tiempo realizando exámenes, se debe únicamente ser muy conciso en como se invierte el tiempo. Si el incidente al cual se está respondiendo es más tradicional, como con una investigación interna la cual no involucra una intrusión, este es el análisis al cual se dedicará más tiempo. Existe un grado de minuciosidad aplicado hacia exámenes forenses tradicionales de medios, con los cuales la mayoría de firmas y personal de respuesta de incidentes no tiene experiencia.

Al realizar un análisis de intrusión recordar, “no se encontrará toda la evidencia”. Muchas veces se trabajaran con organizaciones las cuales sufren del algunas veces llamado “Efecto CSI”, donde el equipo cree puede encontrar y explicar todo utilizando “herramientas interesantes y costosas ”. Durante la vida laboral se asimilará el hecho de la inexistencia de una herramienta mágica.

Anotación:

Otros tipos de investigaciones se basan en un proceso muy metódico durante los exámenes forenses. La meta es descubrir toda la información la cual sustente o refute la alegación. Si el estatuto del equipo incluye otros tipos de investigaciones, ser consciente de como escalar el esfuerzo apropiadamente, y mantener las habilidades necesarias para responder a otros tipos de consultas.

Fuentes:

https://blog.rapid7.com/2017/02/13/detection-and-analysis-phase-of-inci…
https://cybersecurity.att.com/blogs/security-essentials/incident-respon…
https://en.wikipedia.org/wiki/CSI_effect

Una vez los sistemas han sido identificados y se tienen los indicadores de compromiso, el siguiente paso es recolectar datos adicionales para el análisis. El equipo para respuesta de incidentes debe crear un plan para recolectar y preservar evidencia, ya sea esta capacidad sea interna o de un tercero. Las metas principales cuando se preserva evidencia implican utilizar procesos los cuales minimicen los cambios hacia un sistema, minimicen el tiempo de interacción con un sistema, y permita crear la documentación adecuada. Se puede recolectar evidencia desde un sistema en funcionamiento o decidir apagar el sistema para posteriormente realizar las imágenes.

Debido a cualquier equipo para respuesta de incidentes tiene recursos limitados, no tiene sentido recolectar grandes volúmenes de datos los cuales nunca serán examinados (a menos exista una buena razón). Por lo tanto para cada nuevo sistema identificado, se debe tomar una decisión sobre cual tipo de evidencia recolectar. Siempre se deben considerar las circunstancias para sistema, incluyendo si existe algo diferente sobre el sistema, o si una revisión de los datos de una respuesta en vivo generan nuevos hallazgos. Si se cree existe algún aspecto único o existe otra razón convincente, preservar la evidencia necesaria para avanzar con la investigación. Las categorías para la preservación típica de evidencia son; respuesta en vivo, recolección de memoria, e imagen forense de un disco, como se detalla a continuación:

Respuesta en vivo: La respuesta en vivo es el proceso par recolección de evidencia más común a ser realizada en una respuesta de incidentes. Una respuesta en vivo es el proceso de utilizar herramientas automáticas para recolectar un conjunto estándar de datos sobre el sistema en funcionamiento. Los datos incluyen información volátil y no volátil, el cual rápidamente puede proporcionar respuestas sobre preguntas de la investigación. La información típica recolectada incluye elementos como listado de procesos, conexiones activas de red, registros sobre eventos, lista de objetivos en el sistema, y los contenidos del registro. Se puede también recolectar el contenido de archivos específicos, como archivos de eventos o sospechosos de contener malware. Debido a los procesos son automáticos y el tamaño de los datos no es muy grande, se debe realizar una respuesta en vivo sobre la mayoría de los sistemas. Un análisis de respuesta en vivo usualmente será capaz de confirmar aún más un compromiso, proporcionar detalles adicionales sobre aquello hecho por un atacante sobre el sistema, además de revelar pistas adicionales a investigar.

Recolección de memoria: La recolección de memoria es más útil en casos donde se sospecha el atacante está utilizando mecanismos para ocultar sus actividades, como un rootkit, y no se puede obtener la imagen de un disco. La memoria también es útil para casos donde la actividad maliciosa únicamente residente en memoria, o deja muy pocos artefactos sobre el disco. Aunque algunas veces se pueden encontrar elementos sorprendentes al analizar la memoria, siempre todo esto dependerá del escenario en investigación, pues algunas veces podría no proporcionar datos suficientes para responder a ciertas preguntas. Aunque es posible identificar malware en funcionamiento sobre un sistema, algunas veces no se podría explicar como llegó allí, o aquello lo cual estuvo haciendo el atacante en el sistema.

Imagen forense de disco: Las imágenes forenses de disco son duplicados completos de los dispositivos de almacenamiento en un sistema. Durante una respuesta de incidentes es común recolectar imágenes en modo en “vivo”, cuando el sistema no es apagado, y se crea una imagen sobre un dispositivo de almacenamiento externo. Debido a las imágenes de discos son grandes y puede tomar tiempo analizarlas, normalmente se recolectar únicamente en situaciones donde se cree una imagen de disco es necesario para proporcionar beneficios hacia la investigación. Las imágenes forenses de discos son útiles en los casos donde un atacante realiza muchas acciones durante un largo lapso de tiempo, cuando existen preguntas sin resolver con las cuales otra evidencia no es de ayuda, o cuando se espera recuperar información adicional, la cual se cree únicamente está disponible en una imagen de disco. En incidentes las cuales no involucran una intrusión sospechosa, la recolección de imágenes de disco completo es una norma.

Fuentes:

https://cybersecurity.att.com/resource-center/ebook/insider-guide-to-in…
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-secu…

Después de desplegar los Indicadores de Compromiso, se debería empezar a obtener lo denominado como “coincidencias”. Estas coincidencias implican una herramienta para Indicadores de Compromiso, encuentra una coincidencia para una regla definida o Indicador de Compromiso. Antes de tomar acciones sobre una coincidencia, se debe revisar la información de la coincidencia para determinar si es válido. Esto es normalmente requerido porque algunas coincidencias tienen menos fiabilidad por ser muy genéricos, o debido a los falsos positivos inesperados. Algunas veces se obtiene una pequeña cantidad de datos adicionales para ayudar a poner la coincidencia en contexto. A menos la coincidencia sea altamente fiable, en este punto aún se desconoce si el sistema es o no realmente parte del incidente. Consecuentemente se deben tomar una serie de pasos para determinar si el sistema es realmente de interés.

Conforme los sistemas son identificados, se debe realizar un triaje inicial sobre la nueva información. Estos pasos ayudan a asegurar se invierta tiempo en tareas relevantes, y mantener así la investigación enfocada en:

Validar: Examinar los detalles iniciales de los elementos coincidentes y determinar si son fiables. Por ejemplo, ¿Si un Indicador de Compromiso coincide únicamente con el nombre de un archivo, podría ser un falso positivo?. ¿Son los nuevos detalles consistentes con el lapso de tiempo conocido de la investigación actual?.

Categorizar: Asignar el sistema identificado hacia una o más categorías para mantener organizada la investigación. A través de los años se ha aprendido el etiquetar sistemas como “Comprometidos” es muy vago, y los investigadores deberían evitar utilizar estos términos. Resulta más útil utilizar categorías las cuales indiquen con más claridad el tipo de hallazgos y las actividades del atacante, como “Puerta trasera instalada”, “Acceso con credenciales válidas”, “Inyección SQL”, “Recolección de credenciales”, o “Robo de datos”.

Priorizar: Asignar una prioridad relativa para futuras acciones sobre el sistema identificado. Una práctica común dentro de muchas organizaciones es priorizar basándose en los factores relacionados a la empresa, como el usuario principal o el tipo de información procesada. Sin embargo esta perspectiva carece de un punto critico, el cual no considera otros factores de investigación. Por ejemplo, si los detalles iniciales del compromiso del sistema identificado son consistentes con los hallazgos de otros sistemas, una investigación más profunda del sistema no proporcionará ninguna nueva pista de la investigación, y podría tener una prioridad baja. De otro lado, si los detalles sugieren algo nuevo, como con diferente malware, puede ser beneficioso asignar una alta prioridad para el análisis, sin importar otros factores.

Fuentes:

https://www.sans.org/reading-room/whitepapers/forensics/paper/34200
https://www.trendmicro.com/vinfo/us/security/definition/indicators-of-c…
http://www.reydes.com/d/?q=Creacion_de_Indicadores_de_Compromiso_IOC_Du…

Utilizar Indicadores de Compromiso (IOCs) es grandioso, pero su real poder está en permitir a los equipos de respuesta de incidentes encontrar lo dañino de una manera automática, ya sea a través de una plataforma para respuesta de incidentes empresarial o a través de guiones WMI o VB. El éxito de una investigación depende de la habilidad de buscar Indicadores de Compromiso a través de la empresa y reportarlos de una manera automática; esto es lo considerado como el despliegue de los Indicadores de Compromiso. Por lo tanto la organización debe poseer alguna capacidad para implementar Indicadores de Compromiso o no serán de mucha utilidad. Para los Indicadores de Compromiso basados en red esta perspectiva es sencilla; muchas soluciones soportan reglas de Snort. Sin embargo esto no es necesariamente un estándar aceptado para los Indicadores de Compromiso basados en host. Debido a esto la utilización efectiva de los Indicadores de Compromiso basados en host, en el proceso de investigación puede ser un desafío.

Formatos de la Industria e IOCs

Existe una principal deficiencia en la industria de seguridad en computadoras cuando se trata de Indicadores de Compromiso basados en host: no existe un estándar aceptado. Aunque Snort es ampliamente aceptado y utilizado para Indicadores de compromiso basado en host, no existe una solución libre basada en host el cual incluya un lenguaje de indicadores y herramientas, para efectivamente utilizarlas en una empresa. Sin una solución, los profesionales en respuesta de incidentes continuarán enfrentando desafíos significativos en busca de Indicadores de Compromiso basados en host, durante sus investigaciones.

Al momento de realizar la presente publicación, existen STIX (Structured Threar Information Expression), el cual es un lenguaje y formato de serialización utilizado para intercambiar inteligencia de ciber amenazadas (CTI). STIX es de fuente abierta y libre, lo cual permite a todos los interesados su contribución libre. En el caso de YARA, es una herramienta con el propósito (no limitado) de ayudar a identificar y clasificar muestras de malware. Con YARA se pueden crear descripciones de familias de malware, basados en patrones textuales o binarios.

No se necesita un gran presupuesto para utilizar Indicadores de Compromiso, aunque la habilidad de utilizarlos efectivamente a través de la empresa, probablemente requerirá una financiación significativa. Existen herramientas tanto gratuitas y comerciales las cuales pueden ser utilizadas. Estas herramientas son bastante efectivas en una diversidad de empresas, pero tal vez no se amplíen muy bien. Para buscar eficazmente Indicadores de Compromiso en una empresa, se necesita invertir en soluciones de gran escala. Se debe tener en consideración se necesita software y procesos maduros para soportar el uso de Indicadores de Compromiso. Este aspecto en la industria de la seguridad mejora en el tiempo.

Fuentes:

https://github.com/VirusTotal/yara
https://virustotal.github.io/yara/
https://cyboxproject.github.io/
https://oasis-open.github.io/cti-documentation/