Por qué las convenciones de nomenclatura son importantes para la supervisión de registros
La supervisión de registros es difícil por muchas razones. Por un lado, no hay muchos eventos que indiquen indiscutiblemente una intrusión o actividad maliciosa. Si fuera tan fácil, el sistema simplemente evitaría el ataque en primer lugar. Una forma de mejorar el monitoreo de registros es implementar convenciones de nomenclatura que incorporen información sobre objetos como cuentas de usuario, grupos y computadoras, como el tipo o la sensibilidad. Esto facilita que las reglas de análisis de registros relativamente simples reconozcan objetos importantes o combinaciones inadecuadas de información que de otro modo serían imposibles.
Sin embargo, puede resultar difícil solicitar cambios especiales en la convención de nomenclatura para supervisar los registros. Es común tratar el monitoreo de registros como una actividad estrictamente unidireccional en relación con el entorno de producción. Con esto quiero decir que se espera que los analistas de seguridad monitoreen los registros y detecten intrusiones sin interacción o participación con los administradores de los sistemas monitoreados más que para facilitar la recopilación de registros.
Me doy cuenta de que tal situación puede no ser fácil de cambiar, pero si los analistas de seguridad pueden aportar algo sobre los estándares y procedimientos seguidos desde la recopilación de registros, pueden aumentar en gran medida la detectabilidad de eventos de seguridad sospechosos o cuestionables. A continuación se muestran algunos ejemplos.
Hay al menos tres tipos de cuentas de usuario que utiliza cada organización:
• Cuentas de usuario final
• Cuentas privilegiadas para administradores
• Cuentas de servicio/aplicación
Cada una de estas 3 cuentas se utiliza de diferentes maneras y debe estar sujeta a ciertos controles de mejores prácticas. Por ejemplo, ninguna persona debería iniciar sesión en una sesión de inicio de sesión interactiva (consola local o escritorio remoto) con una cuenta de servicio o aplicación. Pero, por supuesto, un actor interno malintencionado o una amenaza externa está más que feliz de explotar dichas cuentas, ya que a menudo tienen autoridad privilegiada y frecuentemente son inseguras debido a las dificultades para administrarlas. Por el contrario, las cuentas de usuario final y administrador asignadas a personas no deben usarse para ejecutar servicios y aplicaciones. Hacerlo causará todo tipo de problemas. Por ejemplo, si el Servicio A se ejecuta como Usuario B y ese usuario abandona la empresa, el Servicio A fallará la próxima vez que se inicie después de que el Usuario B esté deshabilitado. En las auditorías, he visto cuentas de administrador con privilegios elevados de empleados que se fueron hace mucho tiempo todavía activas porque el personal sabía que había diferentes aplicaciones y servicios ejecutándose con estas credenciales. Por supuesto, esto crea todo tipo de agujeros de seguridad, incluido el acceso residual para el empleado despedido.
El ID de evento 4624 facilita la distinción entre diferentes tipos de sesiones de inicio de sesión con el campo Tipo de inicio de sesión. Vea la tabla a continuación. Pero, por supuesto, Windows no puede decirle qué tipo de cuenta acaba de iniciar sesión. Windows no conoce la diferencia entre cuentas de usuario final, administrador o servicio. Pero si su convención de nomenclatura incorpora esa información, puede comparar fácilmente el tipo de cuenta y el tipo de inicio de sesión y alertar sobre combinaciones inapropiadas. Digamos que su convención de nomenclatura especifica que todas las cuentas de servicio comienzan con "s-". Ahora todo lo que necesita hacer es configurar una regla para que le avise cada vez que vea el ID de evento 4624, donde el tipo de inicio de sesión es 2 o 10 y el nombre de la cuenta es como "s-*".
Este es sólo un ejemplo de por qué es tan valioso implementar convenciones de nomenclatura que incluyan información clave sobre los objetos. Si nombra grupos con prefijos o cualquier otra cosa que etiquete a grupos privilegiados como tales, ahora será muy fácil detectar cada vez que se agrega un miembro a un grupo privilegiado. Quizás siga ciertos procedimientos para proteger las cuentas privilegiadas de ataques de paso de hash, como limitar a los administradores a iniciar sesión únicamente en determinados Jump Boxes. Si las cuentas privilegiadas y los sistemas Jump Box son reconocibles como tales por su nombre, entonces podrá alertar fácilmente cuando una cuenta privilegiada intente iniciar sesión desde un sistema que no sea Jump Box.
Por supuesto, esto requiere la cooperación directa de los administradores que pueden resistirse a cambiar sus estilos de nombres sólo por el bien de los registros. Y necesita conocer los procedimientos y controles utilizados para mantener su red segura para poder configurar su SIEM para reconocer cuando intrusos o personas internas malintencionadas eluden estos controles. Pero vale la pena afrontar ambos desafíos.