Introducción
Al tomar una decisión a favor de conectarse al SOC, la empresa a menudo considera al proveedor como una "red de seguridad" para hacer frente a incidentes y amenazas complejos, que serían potencialmente difíciles de afrontar por sí solo. Al mismo tiempo, a menudo sucede que ya en la etapa de prueba piloto de un servicio, aparecen cuellos de botella o fallas críticas en la estrategia existente para garantizar la estabilidad de la información de los activos digitales. Es por eso que SOC es un “viaje” colaborativo donde la empresa y el proveedor de servicios van de la mano, completándose y ayudándose mutuamente en toda la distancia.
Figura: 1. Debilidades comunes de la empresa
Hemos acumulado muchos años de experiencia garantizando la seguridad de la información, tanto la nuestra como la de nuestros clientes. Y queremos compartirlo con nuestros lectores. Como parte de este artículo, presentaré varios casos que fueron prevenidos con éxito por nuestro SOC comercial. Se pueden aprender muchas cosas útiles de ellos.
Caso 1. "Proxy-regular"
El asistente registró un ataque de red desde la dirección 10.XX250 en el host 10.XX70 (YYru) Resultó
que el software Kerio WinRoute Firewall estaba instalado en el host 10.XX250. Según el anfitrión responsable de la operación, este software se utilizó exclusivamente como firewall. El escaneo del host nos mostró lo siguiente:
La interfaz web de Kerio está cómodamente ubicada en el puerto 443:
Fig. 2. Kerio mirando directamente al alma
Sin embargo, el puerto abierto 3128, en el que se ejecutaba el proxy http, no despertó menos interés. Continuando con la verificación, se encontró que usando el proxy 10.XX250: 3128, era posible acceder a Internet sin tener que ingresar credenciales. El acceso a Internet se realizó con IP externa 89.XX18. El escaneo de la dirección IP externa mostró disponibilidad:
3128 / tcp - Puerto del servidor proxy Kerio WinRoute Firewall.
Para este servicio, resultó ser parcialmente posible utilizar el método Connect:
Resultado: a través de un proxy en el puerto 3128 / tcp, es posible el acceso desde Internet a la red interna de la empresa.
31415 / TCP: funcionamiento del servicio de software
mrelayd github.com/thinkberg/jta/blob/master/tools/mrelayd.c
Mrelayd funciona de manera similar a telnet-proxy. Para especificar la dirección de conexión, se utiliza el método "retransmisión", que se indica como una línea como: "retransmisión objetivothost targetport".
Por ejemplo:
para proxy de una conexión ssh en este caso, puede usar la opción ProxyCommand (openssh) o las opciones de conexión en Putty.
En pocas palabras: es posible acceder a la red interna, incluso a través de protocolos de control.
Este ejemplo ilustra, a pesar de su aparente simplicidad, la importancia de una correcta configuración del servidor proxy en una empresa. De hecho, de lo contrario, el impacto informativo en los activos digitales internos es posible incluso en ausencia de servicios vulnerables en el perímetro de la red y excluyendo las variaciones en los ataques con autenticación de fuerza bruta de los protocolos de control remoto.
Caso 2. Un enrutador que podría (en realidad no)
Durante el proyecto piloto, la atención de los especialistas del centro de monitoreo operativo fue atraída por la interfaz web del equipo de red accesible desde Internet. La contraseña predeterminada no funcionó, pero con la esperanza de una mala suerte, se intentó forzar una contraseña de 6 caracteres para la cuenta de administrador.
Figura: 3. Parece de fácil acceso (usando cuentas predeterminadas) El
intento fue exitoso, lo que permitió una mayor investigación. En la lista de interfaces, entre otras cosas, se notó un "paciente" del tipo "cliente PPTP", y en su configuración, se especificaron cuidadosamente las credenciales para conectarse a un host en la red interna de la empresa.
Se realizó una conexión exitosa con las credenciales encontradas y se determinó la dirección IP externa del dispositivo
Un escaneo de IP externo mostró la presencia de puertos asociados con la minería de criptomonedas (que es una señal de un posible compromiso del sistema). Además, el servicio en el puerto 5000 / tcp atrajo interés. El infortunado 5000 / tcp aloja un servicio vulnerable que permite el lanzamiento de scripts arbitrarios.
Ejemplo de operación:
Fig. 4. Haga ping a los servicios internos iniciados a través de la interfaz web
. 5. Salida del archivo / etc / shadow
Parecería que esto es más que suficiente, pero como parte de una verificación adicional, se encontró que el servicio de monitoreo en ejecución Cacti en 79 / tcp usaba la contraseña de acceso predeterminada.
Figura: 6. Dispositivos supervisados
El hecho de acceder a Cacti también nos permitió obtener información sobre la recopilación de logs y la comunidad SNMP:
Este ejemplo vuelve a plantear la cuestión del ya aburrido problema de utilizar credenciales para acceder a sistemas que no cumplen con la política de contraseñas adoptada por la empresa.
Caso 3. Pentest vs SOC
Cada vez más, es una buena forma para las empresas en el marco de las pruebas SOC MTC combinar un proyecto de servicio piloto con una auditoría regular de los sistemas de información en el formato pentest.
El SOC moderno tiene la capacidad de detectar, de acuerdo con el SLA, tanto los hechos del compromiso inicial del sistema como los intentos posteriores de un "atacante" potencial para afianzarse en el sistema, aumentar los privilegios y desarrollar un ataque en hosts que ya están dentro de la red corporativa. Para ello, las políticas de auditoría para los sistemas Windows / Unix del cliente y otros sistemas de seguridad de la información disponibles se configuran en consecuencia. Los eventos de seguridad recopilados se procesan en función de las reglas de correlación desarrolladas, lo que permite al analista de SOC detectar y responder de manera eficaz a los posibles incidentes.
Figura: 7. Para un pentester ordinario, la primera ronda de "contraataque" con el SOC finaliza muy rápido,
luego de eso, a modo de concesiones, haciendo la vista gorda a la actividad del contratista, los clientes sugieren que los pentest especialistas contratados continúen su trabajo. Esto una vez más subraya la eficacia del SOC: calculamos inmediatamente las actividades de los pentesters contratados por la empresa para verificar la seguridad de la infraestructura. La cuestión de la eficacia y viabilidad del uso de SOC desaparece de inmediato.
A continuación se muestra un breve caso de estudio con una de las empresas:
Como puede ver, todas las acciones del "atacante", incluido el momento de su conexión inicial a la red, fueron identificadas y presentadas a la empresa.
Se identificaron un compromiso de cuenta, la dirección IP de un atacante potencial y el hecho de que un pentester instaló servicios maliciosos en los hosts del cliente. En caso de un incidente real, toda la información recopilada sería más que suficiente para responder de manera adecuada y proteger los activos digitales de la empresa.
Y como conclusión
Me gustaría señalar que la descripción de los casos reales de SOC, como ninguna otra cosa, debería permitir a las empresas comprender la importancia y la conveniencia de utilizar dicho servicio.
La puesta en marcha competente de la recopilación de eventos de seguridad, su análisis, la redacción de reglas de correlación adecuadas para la empresa, el enriquecimiento de los eventos de seguridad de la información mediante plataformas de ciberinteligencia proyectadas sobre incidentes reales, permiten comprender y evaluar la eficiencia futura de la conexión a el proveedor de SOC.
Es necesario entender seriamente que ciertas herramientas de seguridad de la información brindan protección contra amenazas privadas, sin embargo, no brindan una imagen completa de lo que está sucediendo “en la frontera”. SOC, que reúne a personas capacitadas, tecnologías innovadoras y procesos estructurados, proporciona una protección integral de la organización contra las amenazas cibernéticas en tiempo real.
Por ejemplo, como parte del MTS SOC, acordamos con los clientes la lista final de sistemas fuente conectados y reglas de correlación. Junto con la empresa protegida, nos conectamos a los sistemas de origen a través de un túnel de acceso organizado y proporcionado por el cliente, establecemos una conexión segura entre ellos, el servidor de recopilación de registros de la empresa y el sistema SOC para transferir registros de los sistemas de origen al servidor de recopilación de registros de la empresa y de éste al sistema SOC en tiempo real.
Figura: 8. Esquema de conexión del cliente con el proveedor de SOC
El equipo de SOC, junto con los empleados de la empresa, adapta las reglas para detectar incidentes de seguridad de la información, perfilar la red y la actividad del host para minimizar los falsos positivos. Las capacidades adicionales pueden ser el control de las vulnerabilidades del perímetro externo y la investigación de incidentes de seguridad de la información.
A partir de los resultados de la investigación de incidencias se elabora un informe del trabajo realizado. El equipo de SOC, además de analizar el incidente y establecer el sistema de origen y las causas, forma un conjunto de recomendaciones técnicas para prevenir o reducir la probabilidad de incidentes similares en el futuro.
Autores del artículo:
Experto senior de MTS SOC Dmitry Berkovets y jefe de productos de seguridad de la información del proveedor #CloudMTS Alexander Karpuzikov.
Vacantes
Si desea unirse al equipo de #CloudMTS, tenemos nuevas vacantes:
Ingeniero de redes
Diseñador UI / UX
Desarrollador Golang
Ingeniero DevOps