blog

Probabilidad de Ocurrencia

De acuerdo al Instituto Nacional de Estándares y Tecnologías (NIST), la probabilidad de ocurrencia se basa en la probabilidad de un amenaza particular sea capaz de explotar una vulnerabilidad en particular, con posibles puntuaciones de bajo, medio o alto.

• Alto:

Un potencial adversario tiene alta capacitación y motivación, además las medidas implementadas para protegerse contra la vulnerabilidad son insuficientes.

• Medio:

El potencial adversario está motivado y tiene capacitación, pero las medidas implementadas para protegerse contra la vulnerabilidad pueden impedir su éxito.

• Bajo:

Un potencial adversario no está capacitado o no tiene motivación, además existen medidas implementadas para protegerse contra la vulnerabilidad, las cuales son parcialmente o completamente efectivas.

Impacto

El nivel de impacto es determinado por la evaluación de la cantidad de daño el cual podría ocurrir si una vulnerabilidad en cuestión fuese explotada, o aprovechada de otra manera.

• Alto:

Aprovecharse de una vulnerabilidad podría resultar en perdidas financieras muy significativas, daño serio hacia la misión o reputación de la organización, o incluso lesiones serias, incluyendo la pérdida de vidas.

• Medio:

Aprovecharse de una vulnerabilidad podría conducir a pérdidas financieras, daño a la misión o reputación de la organización, o lesiones humanas.

• Bajo:

Aprovecharse de una vulnerabilidad podría resultar en algún grado de pérdida financiera o impacto hacia la misión y reputación de la organización.

Una vez la probabilidad de ocurrencia e impacto han sido determinados, se puede luego determinar la puntuación del riesgo global, el cual se define como una función de las dos puntuaciones. El riesgo global puede ser calificado como Bajo, Medio, o Alto, lo cual proporciona una guía a aquellos responsables de asegurar y mantener los sistemas en cuestión.

• Alto:

Existe un fuerte requerimiento de medidas adiciones a implementar para protegerse contra la vulnerabilidad. En algunos casos el sistema puede ser permitido de continuar operando, pero un plan debe ser designado e implementado tan pronto como sea posible.

• Medio:

Existe un requerimiento de medidas adicionales a implementar para protegerse contra la vulnerabilidad. Un plan a implementar requiere las medidas deban ser hechas de manera oportuna.

• Bajo:

El propietario del sistema determinará si implementará medidas adicionales para protegerse contra la vulnerabilidad, o puede opcionalmente aceptar el riesgo y dejar el sistema sin cambio.

En Resúmen

Con tantos factores constituyendo el verdadero riesgo de una vulnerabilidad descubierta, la calificación previamente definida del riesgo generado como resultado de una herramienta, no debe únicamente ser utilizada como un punto de partida para determinar el verdadero riesgo para la organización.

Reportes creados de manera competente desde una evaluación de vulnerabilidades, cuando son analizados por un profesional, pueden proporcionar un fundamento inicial para otras evaluaciones como pruebas de penetración. Como tal, es importante entender como obtener los mejores resultados posibles desde esta evaluación inicial.

Kali Linux constituye una excelente plataforma para realizar evaluaciones de vulnerabilidades, y no necesita ninguna configuración especial. En el menú de aplicaciones de Kali se encontrarán numerosas herramientas para evaluaciones de vulnerabilidades, en las categorías de Captura de Información, Análisis de Vulnerabilidades, y Análisis de Aplicaciones Web. Muchos sitios incluyendo el propio sitio web de Kali Linux y su documentación oficial, proporcionan excelentes recursos para utilizar Kali Linux durante una evaluación de vulnerabilidades.

Fuentes:

https://kali.training/downloads/Kali-Linux-Revealed-1st-edition.pdf

Una vulnerabilidad es considerada una debilidad la cual podría ser utilizada de alguna manera para comprometer la confidencialidad, integridad, o disponibilidad de un sistema de información. En una evaluación de vulnerabilidades, la meta es crear un inventario simple de las vulnerabilidades descubiertas dentro del entorno en evaluación. Este concepto del entorno es extremadamente importante. Se debe estar seguro de permanecer dentro del alcance de la red del cliente y los objetivos requeridos. Salir del alcance de la evaluación pueden causar una interrupción del servicio, una brecha de confianza con el cliente, o una acción legal contra el profesional o el empleador.

Debido a su relativa simplicidad, una prueba de vulnerabilidades es frecuentemente completado en entornos más maduros sobre una base regular como parte de demostrar su debida diligencia. En muchos casos una herramienta automática como aquellas incluidas en las categorías “Análisis de Vulnerabilidades” y “Aplicaciones Web” en el sitio web de Kali Linux y su menú de aplicaciones, son utilizadas para descubrir sistemas en vivo en el entorno en evaluación, identificar servicios en atención, y enumerarlos para descubrir tanta información como sea posible, como el software servidor, versión, plataforma, etc.

Esta información es luego verificada por firmas conocidas de problemas o vulnerabilidades potenciales. Estas firmas están constituidas de combinaciones de puntos de datos, los cuales tienen como propósito representar problemas conocidos. Múltiples puntos de datos son utilizados, porque mientras más puntos de datos se utilicen más precisa la identificación. Existen un gran número de puntos de datos existentes, incluyendo pero no limitado a:

Versión del Sistema Operativo: Es común el software sea vulnerable sobre una versión del sistema operativo pero no a otro. Debido a esto el escáner intentará determinar tan precisamente como sea posible, cual versión del sistema operativo es hospedando la aplicación.

Nivel de Parche: Muchas veces los parches para un sistema operativo podrían ser publicados sin incrementar la información de la versión, pero esto cambia la manera en la cual responderá una vulnerabilidad, o incluso eliminan completamente la vulnerabilidad.

Arquitectura del Procesador: Muchas aplicaciones de software están disponibles para múltiples arquitecturas de procesadores, como Intel x86, Intel x64, múltiples versiones de ARM, UltraSPARC, etc. En algunos casos una vulnerabilidad podría únicamente existir sobre una arquitectura específica, con lo cual conocer esta pequeña información puede ser crítico para una firma precisa.

Versión de Software: La versión del software es uno de los elementos más básicos necesarios a ser capturados para identificar una vulnerabilidad.

Estos y muchos otros puntos de datos serán utilizados para constituir una firma como parte de una escaneo de vulnerabilidades. Como se espera, mientras más puntos de datos coincidan más precisa será la firma. Cuando se trata con coincidencias de firmas, se puede tener algunos potenciales resultados diferentes:

Verdaderos Positivos: La firma coincide y captura una vulnerabilidad verdadera. Estos resultados son aquellos necesarios a corregir, pues estos son elementos maliciosos los cuales pueden ser aprovechados por individuos para dañar a la organización (o cliente).

Falsos Positivos: La firma coincide sin embargo el problema detectado no es una vulnerabilidad verdadera. En una evaluación estas son frecuentemente consideradas ruidosas y pueden ser muy frustrantes. Nunca se desea descartar un positivo verdadero como un falso positivo sin una validación mas extensiva.

Verdaderos Negativos: La firma no coincide y no es una vulnerabilidad. Este es el escenario ideal, el verificar la vulnerabilidad no existe.

Falsos Negativos: La firma no coincide pero es una vulnerabilidad existente. Tan malo como es un falso positivo, un falso negativo es mucho peor. En este caso existe un problema, pero el escáner no tiene indicios de su existencia.

Como se puede imaginar, la precisión de las firmas es extremadamente importante para tener resultados precisos. Mientras más datos se proporcionen, mayor las probabilidades de tener resultados precisos desde una escaneo automático basado en firmas, lo cual es porque los escaneos autenticados son frecuentemente tan populares.

Con un escaneo auténticado el software para escaneo utilizará las credenciales proporcionadas para autenticarse a aquello a evaluar. Esto proporciona un nivel profundo de visibilidad dentro del entorno en evaluación de lo cual sería posible de otro modo. Por ejemplo un escaneo normal puede únicamente detectar información sobre el sistema, el cual puede ser derivado desde los servicios en atención, y la funcionalidad proporcionada. Esto puede ser algunas veces bastante información, pero no puede competir con el nivel y profundidad de datos los cuales podrían ser obtenidos si se autentica hacia el sistema, y revisar exhaustivamente todo el software instalado, parches aplicados, procesos en funcionamiento, etc. Esta amplitud de datos es útil para detectar vulnerabilidades, los cuales de otro modo no se habrían descubierto.

Un evaluación de vulnerabilidades bien realizado presenta una instantánea de potenciales problemas en una organización, y proporciona métricas para medir cambios a lo largo del tiempo. Esto es una evaluación bastante liviana, pero incluso así, muchas organizaciones regularmente realizar escaneos automáticos fuera de horarios, para evitar potenciales problemas durante el día, cuando la disponibilidad de los servicios y el ancho de banda son lo más crítico.

Un escaneo de vulnerabilidades deberá verificar muchos diferentes puntos de datos para obtener un resultado preciso. Todas estas diferentes verificaciones pueden crear una carga en el sistema en evaluación, como también consumir ancho de banda. Desafortunadamente es difícil conocer exactamente cuantos recursos se consumirán, pues esto depende del número de servicios abiertos y tipos de verificaciones los cuales podrían estar asociados con estos servicios. Este es el costo de hacer un escaneo, va a ocupar recursos del sistema. Tener una idea general de los recursos a ser consumidos y cuanta carga el sistema puede tener es importante cuando se ejecutan estas herramientas.

Cuando finaliza un escaneo de vulnerabilidades, los problemas descubiertos son típicamente enlazados con identificadores estándar de la industria, como número CVE, EDB-ID, y anuncios de proveedores. Esta información, junto con la puntuación CVSS de las vulnerabilidades, son utilizados para determinar la clasificación del riesgo. Junto con falsos negativos (y falsos positivos), estas calificaciones de riesgo asociado son problemas comunes necesario de considerar cuando se analicen los resultados del escaneo.

Debido a las herramientas automáticas utilizan una base de datos de firmas para detectar vulnerabilidades, cualquier desviación leve desde firmas conocidas puede alterar los resultados, y probablemente la validez de la vulnerabilidad percibida. Un falso positivo resalta incorrectamente una vulnerabilidad la cual no existe, mientras un falso negativo es efectivamente ciego hacia una vulnerabilidad y no lo reporta. Debido a esto, un escaner frecuentemente se dice únicamente es tan bueno como su base de reglas de firmas. Por esta razón muchos proveedores proporcionan múltiples conjuntos de firmas: uno podría ser libre para usuarios caseros y otro conjunto bastante costoso el cual es más completo, además de ser generalmente vendido hacia clientes corporativos.

Otro problema frecuentemente encontrado con los escaneos de vulnerabilidades es la validez de las calificaciones sugeridas del riesgo. Estas calificaciones de riesgo son definidos sobre bases genéricas, considerando muchos diferentes factores como el nivel de privilegio, tipo de software, y pre o post autenticación. Dependiendo del entorno estas calificaciones pueden o no ser aplicables, de tal manera estas no deben ser aceptados ciegamente. Únicamente aquellas bien versadas en los sistemas, pueden adecuadamente validar la calificación del riesgo de las vulnerabilidades

Aunque no existe un acuerdo universalmente definido sobre las puntuaciones del riesgo, la publicación especial de NIST 800-30, se recomienda como base para la evaluación de las calificaciones del riesgo, y su precisión en el entorno. NIST SP 80-30 define el verdadero riesgo de la vulnerabilidad descubierta como una combinación de probabilidad de ocurrencia e impacto potencial.

Fuentes:

https://cve.mitre.org/
https://www.first.org/cvss/
https://csrc.nist.gov/publications/sp#800-30

Teniendo Kali Linux en un entorno seguro, la siguiente etapa es definir exactamente el tipo de evaluación a realizar. A un alto nivel se pueden describir cuatro tipos de evaluaciones; evaluación de vulnerabilidades, pruebas de cumplimiento, una prueba de penetración tradicional, y una evaluación de aplicación. Un contrato puede involucrar varios elementos de cada tipo de evaluación, por lo cual es importante describirlos con cierto detalle, y explicar su relevancia para la construcción de Kali Linux y su entorno.

Antes de profundizar en los diferentes tipos de evaluaciones, es importante primero anotar las diferencias entre una vulnerabilidad y un exploit. Una vulnerabilidad se define como una falla, la cual cuando es aprovechada podría comprometer la confidencialidad, integridad y disponibilidad de un sistema de información. Existe muchos tipos diferentes de vulnerabilidades los cuales pueden ser encontrados, incluyendo:

Inclusión de Archivos: Las vulnerabilidades de inclusión de archivos en las aplicaciones web, permite incluir el contenido de archivos locales o remotos dentro de la computación o programa. Por ejemplo una aplicación web puede tener una función “Mensaje del Día”, la cual lee el contenido de un archivo y lo incluye en la página web, para luego mostrarlo hacia el usuario. Cuando este tipo de funcionalidad es programado incorrectamente, puede permitir a un atacante modificar su petición web para forzar al sitio a incluir el contenido de un archivo de su elección.

Inyección SQL: Un ataque de inyección SQL es aquel donde las rutinas para la validación de entradas del programa es evadido, permitiendo a un atacante proporcionar los comandos SQL a ser ejecutados por el programa. Esta es una forma de ejecución de comandos, la cual puede conducir a potenciales problemas de seguridad.

Desbordamiento de Buffer: Un desbordamiento de buffer es una vulnerabilidad la cual evade las rutinas para la validación de entradas, para escribir datos dentro de la memoria adyacente del buffer. En algunos casos la localización de memoria adyacente puede ser crítico para la operación del programa, y puede obtenerse ejecución de código a través de una manipulación cuidadosa de los datos sobrescritos en memoria.

Condiciones de Carrera: Una condición de carrera es una vulnerabilidad la cual toma ventaja de las dependencias del tiempo en un programa. En algunos casos el flujo de trabajo de un programa depende de una secuencia específica de eventos ocurra. Si se puede alterar esta secuencia de eventos, puede conducir a una vulnerabilidad.

Un exploit de otro lado, es un software el cual cuando es utilizado, toma ventaja de una vulnerabilidad específica, aunque no todas las vulnerabilidades son explotable. Debido a un exploit debe cambiar un proceso en ejecución, forzándolo a realizar una acción no intencionada, la creación del exploit puede ser complejo. Además existen un número de tecnologías antiexploit en las plataformas modernas de computación, los cuales han sido diseñados para dificultar la explotación de vulnerabilidades, como DEP (Data Execution Prevention), y ASLR (Address Space Layout Randomization). Sin embargo el hecho no exista un exploit conocido públicamente disponible para una vulnerabilidad específica, no implica su no existencia (o pueda ser creado). Por ejemplo muchas organizaciones venden y comercializan exploits los cuales no son hechos públicos, así las vulnerabilidades deben ser tratadas como potencialmente explotables.

Fuentes:

https://en.wikipedia.org/wiki/File_inclusion_vulnerability
https://en.wikipedia.org/wiki/SQL_injection
https://en.wikipedia.org/wiki/Buffer_overflow
https://en.wikipedia.org/wiki/Race_condition
https://kali.training/downloads/Kali-Linux-Revealed-1st-edition.pdf

Cuando se prepara la utilización de Kali Linux en el campo de trabajo, se debe primero estar seguro de tener una instalación limpia y funcional. Un error común en muchos profesionales novatos en seguridad, es utilizar la misma instalación entre múltiples evaluaciones. Esto es un problema por dos razones principales:

• En el transcurso de una evaluación, frecuentemente se instalará, ajustará, y se harán cambios de manera manual en el sistema. Estos cambios únicos pueden ayudar a rápidamente trabajar o resolver un problema particular, pero es difícil mantener el rastro; haciendo el sistema sea más difícil de mantener; complicando futuras configuraciones.
• Cada evaluación de seguridad es única. Dejar anotaciones, código, y otros cambios pueden conducir a confusión, o peor aún a contaminación cruzada de los datos del cliente.

Esto es porque iniciar con una instalación limpia de Kali Linux es altamente recomendado, y porque tener una versión previamente personalizada de Kali Linux; la cual está lista para una instalación automatizada; rápidamente proporciona dividendos. Asegurarse de revisar la documentación sobre “Construcción de Imágenes Personalizadas ISO de Kali Linux”, como la también sobre “Instalaciones Desatendidas”, pues cuanto más se automatice hoy menos tiempo se desperdiciará mañana.

Todos tienen diferentes requerimientos cuando se refiere a como configurar Kali Linux para el trabajo de campo, pero existen algunas recomendaciones universales las cuales realmente se deberían seguir. Primero considerar utilizar una instalación encriptada, revisar la documentación sobre “Instalación sobre un Sistema de Archivos Completamente Encriptado”. Esto protegerá los datos físicamente en la máquina, lo cual es un salvavidas si la laptop es incluso robada.

Para una seguridad adicional durante un viaje, es posible se deba utilizar una llave de desencriptación (revisar la documentación sobre Agregar una Contraseña Nuclear para Seguridad Adicional), después enviar una copia (encriptada) de la llave a un colega de trabajo en la oficina. De esta manera los datos están seguros hasta retornar a la oficina, donde se puede restaurar la laptop con la llave de desencriptación.

Otro elemento el cual debe ser doblemente verificado es la lista de paquetes instalados. Considerar cuales herramientas se podrían necesitar para el trabajo propuesto a realizar. Por ejemplo si se está embarcado en una evaluación de seguridad inalámbrica, se debe considerar instalar el matapaquete “kali-linux-wireless”, el cual contiene todas las herramientas disponibles en Kali Linux para evaluaciones inalámbricas, o si una evaluación contra una aplicación web está acercándose, se pueden instalar todas las herramientas de prueba disponibles para evaluar aplicaciones web, con el metapaquete “kali-linux-web”. Es mejor asumir no se tendrá un acceso fácil hacia Internet mientras se realice una evaluación de seguridad, consecuentemente asegurarse de prepararse tanto como sea posible por adelantado.

Por la misma razón se podría requerir revisar los ajustes de red, revisar la documentación sobre “Configurar la Red” y lo referente a “Asegurar Servicios de Red”. Verificar doblemente los ajustes DHCP y revisar los servicios atendiendo en la dirección IP asignada. Estos ajustes pueden tener un impacto crítico hacia el éxito. No se puede evaluar aquello lo cual no se puede ver, y los servicios en atención podrían marcar el sistema, además de hacer se apague antes de iniciar.

Si el rol involucra investigar intrusiones de red, poner atención hacia los ajustes de red es aún más importante, y se necesita evitar alterar los sistemas impactados. Una versión personalizada de Kali con el metapaquete “kali-linux-forensic”, iniciando en modo forense no montará automáticamente los discos ni utilizará una partición swap. De esta manera se puede ayudar a mantener la integridad del sistema bajo análisis, mientras se hace uso de muchas herramientas forenses disponibles en Kali Linux.

Es crítico preparar adecuadamente la instalación de Kali Linux para el trabajo. Se descubrirá un entorno de Kali Linux limpio, eficiente y efectivo siempre hará todo sea más adecuado.

Fuentes:

https://www.kali.org/news/kali-linux-metapackages/
https://kali.training/downloads/Kali-Linux-Revealed-1st-edition.pdf

Kali Linux tiene muchas características específicas, razón por la cual se sugiere tener un sólido conocimiento sobre aquello lo cual hace a Kali Linux especial, y como permite realizar una serie de tareas complejas. Antes de utilizar Kali Linux se necesitan también comprender algunos conceptos relacionados con las evaluaciones de seguridad. A continuación se presentan algunos conceptos con los cuales iniciar, como también algunas referencias para utilizar Kali Linux en una evaluación de seguridad. Se debe iniciar explorando el significado de “seguridad” cuando se trata de sistemas de información. Cuando se intenta asegurar un sistema de información se enfoca en tres atributos principales del sistema:

Confidencialidad: ¿Pueden actores quienes no deberían tener acceso hacia el sistema o información, acceder al sistema o información?

Integridad: ¿Pueden los datos o el sistema ser modificados en alguna manera no prevista?

Disponibilidad: ¿Los datos o el sistema puede ser accedido cuando y como debería?

Juntos estos conceptos constituyen la triada CIA (Confidencialidad, Integridad y Disponibilidad), además en una gran parte son los elementos principales en los cuales enfocarse al asegurar un sistema como parte de un despliegue estándar, mantenimiento o evaluación.

Es también importante anotar en algunos casos, se puede estar mas preocupado con un aspecto de la triada CIA comparado a otros. Por ejemplo, si se tiene un diario de trabajo el cual contiene los pensamientos más secretos, la confidencialidad del diario puede ser de lejos más importante comparado con la integridad y disponibilidad. En otras palabras, se podría no estar preocupado sobre si alguien puede escribir en el diario (opuesto a su lectura), o si el diario es siempre accedible. De otro lado, si se asegura un sistema el cual registre prescripciones médicas, la integridad de los datos sería lo más crítica. Mientras es importante prevenir otras persona lean los medicamentos utilizados por alguien, es importante se pueda acceder a esta lista de medicamentos. Si alguien es capaz de cambiar los contenidos del sistema (altera la integridad), esto podría conducir a una amenaza contra la vida.

Cuando se está asegurando un sistema y se descubre un problema, se deberá considerar cuales de estos tres conceptos, o en cual combinación de estos se encuentra el problema. Esto ayuda a comprender el problema de una manera más completa, además permite categorizar los problemas para responder en consecuencia. Es posible identificar vulnerabilidades los cuales impactan en uno o varios elementos de la triada CIA. Se utiliza a continuación una aplicación con una vulnerabilidad de inyección SQL como un ejemplo:

Confidencialidad: Una vulnerabilidad de inyección SQL permite al atacante extraer contenidos completos de una aplicación web, permitiendo tener acceso completo para leer todos los datos, pero sin la capacidad de cambiar la información o deshabilitar el acceso hacia la base de datos.

Integridad: Una vulnerabilidad de inyección permite al atacante cambiar la información existente en la base de datos. El atacante no puede leer datos o prevenir otros accedan hacia la base de datos.

Disponibilidad: Una vulnerabilidad de inyección SQL inicia una consulta de larga duración, consumiendo una gran cantidad de recursos en el servidor. Esta consulta cuando es iniciada múltiples veces, conduce hacia una situación de negación de servicio (DoS). El atacante no tiene la capacidad de acceder o cambiar los datos, pero puede prevenir usuarios legítimos accedan a la aplicación web.

Múltiples: Una vulnerabilidad de inyección SQL conduce hacia un acceso shell completamente interactivo en el sistema operativo ejecutando la aplicación web. Con este acceso el atacante puede romper la confidencialidad del sistema accediendo a los datos como le plazca, comprometer la integridad del sistema alterando datos, o si lo requiere destruir la aplicación web, conduciendo hacia un compromiso de la disponibilidad del sistema.

Los conceptos detrás de la triada CIA no son demasiado complicados, y de manera realista son elementos con los cuales se está trabajando con intuición, incluso si no se los reconoce. Sin embargo es importante interactuar conscientemente con el concepto pues ayuda a reconocer donde dirigir los esfuerzos. Este fundamento conceptual ayudará a identificar los componentes críticos de los sistemas, además de la cantidad de esfuerzo y recursos a invertir en la corrección de identificar problemas.

Otro concepto el cual se debe abordar es el riesgo, y como se compone de amenazas y vulnerabilidades. Estos conceptos no son muy complejos pero es fácil equivocarse. Lo mejor es pensar en el riesgo como aquello lo cual se está intentando prevenir ocurra, la amenaza como quien lo haría, y la vulnerabilidad como aquello lo cual permite hacerlo. Los controles pueden ser implementados para abarcar las amenazas o vulnerabilidades con la meta de mitigar el riesgo.

Por ejemplo cuando se visitan algunas partes del mundo, se tiene un riesgo substancial de contraer malaria. Esto porque la amenaza de los mosquitos es muy alto en algunas áreas, y es altamente probable no sea inmune a la malaria. Afortunadamente se puede controlar la vulnerabilidad con medicamentos, e intentar controlar la amenaza con el uso de repelentes de insectos y mosquiteros. Con controles establecidos abordando tanto la amenaza como la vulnerabilidad, puede ayudar a garantizar el riesgo no se actualice.

Fuentes:

https://en.wikipedia.org/wiki/Information_security
https://kali.training/downloads/Kali-Linux-Revealed-1st-edition.pdf

Una vez se ha instalado y configurado el sistema, la mayoría de archivos deberían permanecer relativamente estáticos hasta el sistema sea actualizado. Por lo tanto es una buena idea vigilar cambios en los archivos del sistema, pues cualquier cambio inesperado podría ser causa de alarma y debería ser investigado. A continuación se presentan algunas de las herramientas más comunes utilizadas para vigilar los archivos del sistema, detectar cambios, y opcionalmente notificar al administrador del sistema.

Auditar Paquetes con dpkg --verify

dpkg --verify (o dpkg -V) es una interesante herramienta, pues muestra los archivos del sistema los cuales han sido modificados (potencialmente por un atacante), pero el resultado debe ser tomado con criterio. Para hacer su trabajo “dpkg” se basa en las sumas de verificación almacenadas en su propia base de datos, el cual es almacenado en el disco duro (encontrado en /var/lib/dpkg/info/package.md5sums). Por lo tanto un atacante minucioso modificará estos archivos de tal manera contengan nuevas sumas de verificación para los archivos subvertidos, o un atacante avanzado podría comprometer el paquete en el repositorio espejo de Debian. Para protegerse contra esta clase de ataque, se debe utilizar el sistema para la verificación de firmas digitales de APT, para adecuadamente verificar los paquetes.

Ejecutar “dpkg -V” verificará todos los paquetes instalados e imprimirá una línea por cada archivo el cual falle la verificación. Cada carácter denota una prueba sobre algún metadato específico. Desafortunadamente dpkg no almacena los metadatos necesarios para la mayoría de pruebas, y por lo tanto generará signos de interrogante para estos. Actualmente solo la prueba para la suma de verificación puede dar un 5 en un tercer carácter (cuando falla).

Vigilar Archivos: AIDE

La herramienta AIDE (Advanced Intrusion Detection Environment) verifica la integridad de los archivos, y detecta cualquier cambio contra una imagen previamente registrada de un sistema válido. La imagen es almacenada como una base de datos (/var/lib/aide/aide.db), conteniendo la información relevante sobre todos los archivos del sistema (huellas, permisos, marcas de tiempo, etc.).

Se puede instalar AIDE ejecutando “apt-get update”, seguido de ”apt install aide”. La primera acción es iniciar la base de datos con “aide-init”; luego se ejecutará diariamente (mediante el script /etc/cron.daily/aide) para verificar no haya cambiado nada relevante. Cuando se detectan cambios, AIDE los registra en archivos log (/var/log/aide/*.log), y envía los hallazgos hacia el administrador mediante correo electrónico.

Se puede usar las opciones en “/etc/default/aide” para modificar el comportamiento del paquete AIDE. La configuración apropiada de AIDE es almacenada en “/etc/aide/aide.conf” y “/etc/aide/aide.conf.d/” (actualmente estos archivos son únicamente utilizados por “update-aide.conf” para generar “/var/lib/aide/aide.conf.autogenerated”). La configuración indica cuales propiedades de los archivos necesitan ser verificados. Por ejemplo, el contenido de los archivos log cambia rutinariamente, y tales cambios pueden ser ignorados siempre y cuando los permisos de estos archivos sigan igual, pero tanto el contenido y los permisos de los programas ejecutables deben ser constantes. Aunque no es muy complejo, la sintaxis de configuración no es completamente intuitiva y se recomienda leer la página de manual (5) de aide.conf para mayores detalles.

Tripwire es muy similar a AIDE; incluso la sintaxis del archivo de configuración es casi la misma. La principal adición proporcionada por tripwire es un mecanismo para firmar el archivo de configuración, de tal manera un atacante no puede hacer apunte hacia una versión diferente de la base de datos.

Samhain también ofrece funcionalidades similares, como también otras funciones para ayudar a detectar rootkits. También puede ser desplegado de manera global en una red, y registra sus rastros en un servidor central (con una firma).

Fuentes:

https://aide.github.io/
https://sourceforge.net/projects/tripwire/
https://www.la-samhna.de/samhain/index.html

top es una herramienta interactiva la cual muestra una lista de los procesos actualmente en ejecución. El ordenamiento por defeco se basa en la cantidad actual correspondiente al uso del procesador, lo cual puede ser obtenido con la tecla P. Otros ordenamientos incluyen un orden por memoria ocupada (tecla M), por el tiempo total de procesador (tecla T), y por identificador de proceso (tecla N). La tecla K mata o termina un proceso mediante su identificador. La tecla R cambia la prioridad de un proceso.

Cuando un sistema parece estar sobrecargado, top es una gran herramienta para ver cuales procesos compiten por tiempo de procesador, o también por cuanta memoria consumen. En particular, es frecuentemente interesante verificar si los procesos consumiendo recursos coinciden con servicios reales conocidos en la máquina. Un proceso desconocido ejecutándose como usuario “www-data” realmente debería ser destacado e investigado, pues probablemente sea una instancia de software instalado y ejecutado sobre el sistema a través de una vulnerabilidad en la aplicación web.

top es una herramienta muy flexible, además su página de manual proporciona detalles sobre como personalizar su visualización para adaptarlo a necesidades y hábitos personales.

La herramienta gnome-system-monitor es similar a top, y proporciona aproximadamente las mismas características.

Fuentes:

https://man7.org/linux/man-pages/man1/top.1.html
https://help.gnome.org/users/gnome-system-monitor/stable/
https://kali.training/downloads/Kali-Linux-Revealed-1st-edition.pdf

El programa de nombre logcheck vigila los archivos donde se registran los eventos (logs); por defecto cada hora; para luego enviar los mensajes inusuales encontrados en los logs, a través de mensajes de correos electrónicos dirigidos hacia el administrador, para este realice un posterior análisis. La lista de archivos vigilados se almacenan en el archivo “/etc/logcheck/logcheck.logfiles.”. Los valores por defecto funcionan bien si el archivo “/etc/rsyslog.conf” no ha sido completamente revisado.

logcheck puede reportar en varios niveles de detalle: paranoico, servidor y estación de trabajo. Paranoico es muy verboso y debería probablemente ser restringido hacia servidores específicos como firewalls. Servidor es el modo por defecto, y se recomienda para la mayoría de servidores. Estación de trabajo es obviamente diseñado para estaciones de trabajo, y es extremadamente conciso, filtrando más mensajes comparado con otras opciones.

En estos tres casos mencionados, logcheck debe probablemente ser personalizado para excluir algunos mensajes extras (dependiendo de los servicios instalados), a menos realmente se desee recibir lotes por hora de largos mensajes de correos electrónicos poco interesantes. Debido al mecanismo para la selección de mensajes es bastante complejo, es una lectura obligatoria el archivo de nombre “/usr/share/doc/logcheck-database/README.logcheck-database.gz”.

Las reglas aplicadas pueden ser divididas en varios tipos:

• Aquellos calificando un mensaje como un intento (almacenado en un archivo en el directorio “/etc/logcheck/cracking.d/”)
• Intentos ignorados (/etc/logcheck/cracking.ignore.d/)
• Aquellos clasificando un mensaje como una alerta de seguridad (/etc/logcheck/violations.d/)
• Alertas de seguridad ignoradas (/etc/logcheck/violations.ignore.d/)
• Finalmente aquellas aplicados al resto de mensajes (considerados como eventos de seguridad)

Los archivos “ignore.d” son utilizado para (obviamente) ignorar mensajes. Por ejemplo un mensaje etiquetado como un intento o una alerta de seguridad (siguiendo una regla almacenada en un archivo “/etc/logcheck/violations.d/myfile”) puede solo ser ignorada por una regla en “/etc/logcheck/violations.ignore.d/myfile” o un archivo “/etc/logcheck/violations.ignore.d/myfile-extension”.

Un evento del sistema siempre se señalada a menos una regla en uno de los directorios “/etc/logcheck/ignore.d.{paranoico,servidor,estación de trabajo/”, establezca el evento debe ser ignorado. De hecho los únicos directorios a tener en cuenta son aquellos correspondientes hacia niveles de verbosidad iguales o superiores al modo de operación seleccionado.

Fuentes:

http://logcheck.org/
https://kali.training/downloads/Kali-Linux-Revealed-1st-edition.pdf

Los usuarios tienen un rol crítico en la seguridad global. Las acciones tomadas por los usuarios frecuentemente eluden los mejores planes de seguridad. Por lo tanto la educación de los usuarios debe ser una parte de la preparación previa al incidente.

Los usuarios deben conocer cuales tipos de acciones tomarán y no en sus sistemas, desde una perspectiva de seguridad de computadoras y respuesta de incidentes. Los usuarios deben ser conscientes de las maneras más comunes por los cuales los atacantes los utilizan para comprometer y aprovechar la red. Los usuarios deben ser educados sobre la respuesta apropiada para incidentes sospechosos. Típicamente se desea los usuarios inmediatamente notifiquen a un contacto designado. En general, los usuarios deben ser instruidos a no tomar acciones de investigación, porque estas acciones pueden destruir evidencia e impedir una respuesta posterior.

Un problema específico el cual se debe abordar es el peligro inherente al software del servidor instalado por los usuarios. Los usuarios pueden instalar sus propios servidores web o ftp sin autorización, poniendo así en peligro la seguridad global de la organización. El eliminar los privilegios administrativos, es un cambio de configuración el cual ayuda a mitigar este riesgo. Sin embargo, los usuarios pueden algunas veces encontrar maneras de evitar las medidas de seguridad, y se debe ser consciente del peligro asociado con la instalación de software no autorizado.

Fuentes:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2…
https://www.cyber.gov.au/sites/default/files/2019-03/Mitigation_Strateg…

Durante las investigaciones se encuentran nuevos e interesantes desafíos, los cuales proporcionan ideas sobre lo difícil de investigar adecuadamente un incidente el cual traspasa fronteras internacionales. A continuación se mencionan algunos desafíos los cuales se podrían enfrentar.

Regulaciones Laborales y Privacidad

Como investigadores forenses normalmente se ve la red de un organización como una gran fuente de evidencia, la cual está esperando a nos acerquemos y la encontremos. No se podría considerar inmediatamente una red abarca cinco países en tres continentes, cada uno con sus propias leyes de privacidad y regulaciones. Es fácil meterse en problemas si se decide buscar por indicadores de compromiso, y este método viola leyes locales de privacidad o regulaciones federales laborales. Si se planifica investigar un incidente involucrando una red abarcando más de un país, se necesita hacer antes algo de tarea. Se debe contactar con el consejero legal de la organización dentro de cada país para discutir la situación, y determinar cuales acciones se pueden o no hacer.

Coordinación del Equipo

Otro desafío significativo con los incidentes extendiéndose por el mundo es la coordinación. Debido a los recursos de personal y tecnología podrían estar distribuidos sobre muchas zonas horarias, mantenerse organizado requerirá un cuidadoso plan y constante esfuerzo para asegurarse todo esté en sincronía. Debido algunos miembros del equipo pueden estar durmiendo mientras uno está despierto, el hacer las cosas puede demandar más tiempo. El hacer un seguimiento a las tareas y realizar las transferencias será crítico para asegurar se hace un progreso aceptable. Programar una reunión podría tomar días, porque los participantes están en diferentes zonas horarias.

Accesibilidad de Datos

Durante una investigación cantidades masivas de datos son recolectados para su análisis. Frecuentemente están en la forma de grandes conjuntos de datos singulares, como imágenes de discos duros. Cuando el equipo es responsable de realizar la mayoría de tareas de análisis, se debe encontrar una manera de transferir estos datos eficientemente hacia los miembros del equipo forense con experiencia de análisis. Aunque se debe tener en mente cualquier documentación personalizad o restricciones en los paises de origen y destino, el mayor desafío será el retraso en obtener datos relevantes en las manos correctas. Si existe cualquier pregunta sobre si es necesario transferir los datos, se debe comenzar el proceso inmediatamente. Pues se pueden perder muchos días por falta de comunicación o indecisión.

Fuentes:

https://www.first.org/conference/1999/ACDA-WP-GSIR.pdf
https://www.globalinfrastructureinitiative.com/article/critical-resilie…