Matriz de Control de Riesgos
Las defensas en serie superpuestas pueden reducir significativamente la posibilidad de un ataque exitoso. Ese es un paso crítico para evitar una brecha de datos.
Anteriormente hablamos sobre la seguridad centrada en los datos y la necesidad de contar con defensas herméticas. El uso de IDS e IPS es un primer paso en esa dirección, pero vamos a ir más allá creando controles superpuestos que reforzarán aún más la seguridad.
La matriz de control de riesgos es el núcleo de la planificación de la seguridad. La matriz asigna nuestros riesgos a los controles que planeamos aplicar. No es un concepto revolucionario, pero llevarlo a la práctica puede resultar complicado. Para que el debate sea menos teórico y más práctico, tomaremos un ejemplo real de la seguridad de las bases de datos y utilizaremos la matriz de control de riesgos de auditoría básica.
Riesgos
Enumerar los riesgos es el primer paso para crear una matriz. Para asegurarnos de que cubrimos todos los riesgos y facilitar su asignación a los controles, hemos optado por hacerlo por cuenta de base de datos.
Las bases de datos suelen tener cuentas para los administradores de bases de datos, la aplicación y otros. Al enumerar todas las cuentas de la base de datos, nos aseguramos de que no hay ningún hueco en el lado de los riesgos de la matriz.
También hay riesgos fuera de nuestra lista de cuentas. Por ejemplo, las nuevas cuentas, las vulnerabilidades de la base de datos que no requieren cuentas, el acceso a la base de datos desde dentro de la máquina de la base de datos y los datos copiados fuera de la base de datos.
A continuación, debemos determinar los posibles exploits para cada cuenta. Por lo general, cualquier cuenta, incluidas las cuentas DBA, puede ser explotada por sus propietarios (un abuso de privilegios), un hacker que utilice credenciales robadas o alguna otra suplantación de identidad, como comprometer el escritorio del propietario de la cuenta.
Las cuentas de aplicaciones tienen factores de riesgo adicionales. El principal es una vulnerabilidad en la aplicación. Por ejemplo, un ataque de inyección SQL engañará a la aplicación para que ejecute un SQL que no debe ejecutar. Otro riesgo es un cambio no aprobado que se salió del proceso de control de cambios.
La ventaja añadida de enumerar los riesgos por tipo de cuenta es que así es también como los controlamos. Desde la perspectiva de la base de datos, una sesión DBA es una sesión DBA. La base de datos no puede distinguir entre el DBA real y una suplantación de identidad exitosa. En ese sentido, hay poca diferencia entre un abuso de privilegios por parte del DBA y una suplantación de identidad: en ambos casos, la cuenta DBA ejecutó una actividad maliciosa.
Controles
Cada riesgo debe tener controles correspondientes. El truco para lograr una seguridad más estricta es tener múltiples controles que se superpongan. Veamos algunos ejemplos:
El primer nivel en Core Audit consiste en identificar cambios en la configuración, los usuarios, los permisos, los objetos, etc. Además de validar el control de cambios, este tipo de control identificará algunos efectos secundarios de los ataques. Por ejemplo, si un hacker crea un usuario para una puerta trasera, crea una tabla para extraer datos, etc.
Obviamente, eso no es suficiente, y en el nivel 2 podemos crear informes y alertas sobre sesiones y SQL específicos. Estos controles son eficaces para actividades de bajo volumen. Desde la perspectiva de la supervisión de cuentas DBA, podríamos supervisar los DML, los DDL y el acceso a tablas confidenciales. Si nos fijamos en la cuenta de la aplicación, podemos comprobar si hay sesiones que se originan fuera del servidor de la aplicación. Es mejor dejar los informes sobre otras actividades de la aplicación para el nivel 3, ya que su volumen es demasiado alto para que sean eficaces en el nivel 2. Estos controles no detectarán todos los ataques, pero son un buen comienzo.
En el nivel 3, tenemos el Análisis de anomalías, que identifica cambios en el perfil de actividad conductual. Se trata de una automatización que puede escalarse a volúmenes de actividad extremadamente altos. Esto lo convierte en un control potente y eficaz sobre la actividad de las aplicaciones, ya que tiende a ser repetitiva. También puede eliminar las consultas SQL repetitivas de los administradores de bases de datos y señalar las nuevas. Otro uso es el análisis de las fuentes de actividad para identificar a las personas que se conectan desde diferentes máquinas, programas, en momentos inusuales y mucho más.
Otra capacidad del nivel 3 es el análisis forense proactivo, que ofrece al personal de seguridad visibilidad sobre quién está haciendo qué en la base de datos. El personal puede investigar las fuentes de actividad, la cantidad de datos a los que se accede, la relación entre las sentencias SQL y las filas, y mucho más.
Y eso nos lleva al nivel 4, que es preventivo. Aquí debemos tener cuidado de no bloquear actividades legítimas. Esos son los falsos positivos que son problemáticos en IPS. Pero aún así podemos bloquear ciertas actividades, como el acceso de los administradores de bases de datos a esquemas confidenciales, el acceso a una tabla confidencial desde fuera de la aplicación, la aplicación de la separación de funciones y mucho más.
Controles superpuestos
Como puede ver, cada columna de riesgos tiene muchos controles potenciales, cada uno de los cuales aborda un aspecto diferente de los riesgos. Podemos tener múltiples informes y alertas que aborden la misma amenaza desde una perspectiva diferente. También podemos tener controles preventivos y detectivos calibrados con diferentes sensibilidades.
También utilizamos cinco tipos diferentes de controles: Nivel 1, auditoría declarativa (Nivel 2), análisis de anomalías (Nivel 3), análisis forense proactivo (Nivel 3) y preventivo (Nivel 4). Cada tipo tiene diferentes fortalezas y debilidades, como la inversión de tiempo, la participación del personal de seguridad, la visibilidad, la prevención o la detección, entre otras.
Estas superposiciones son las que hacen que este tipo de seguridad sea mucho más estricta. Aunque probablemente no implementará demasiados informes y alertas, puede planificar su implementación en función de la tasa de falsos positivos y del tiempo que pueda dedicar a esta seguridad.
Aplicaciones
Y también podemos ir más allá e implementar defensas similares en la aplicación. Se trata de controles de actividad de la aplicación independientes de los controles de la base de datos que se describen en este artículo. Auditoría declarativa, análisis de anomalías, análisis forense proactivo y mucho más: todo ello funciona en los perfiles de actividad de la aplicación.
Al añadir controles adicionales sobre la aplicación, reduciremos aún más el riesgo de vulnerabilidad de la misma. Esto añadirá barreras adicionales entre el atacante y los datos.
Si desea obtener más información, póngase en contacto con nosotros en info@bluecoreresearch.com/esnew