¿Qué riesgo de seguridad tienen los esquemas conceptuales publicados?

Estaba solicitando los esquemas conceptuales del sistema de información de una agencia gubernamental para mi investigación. Mi solicitud ha sido denegada por ser un riesgo de seguridad.

Realmente no tengo una amplia experiencia en bases de datos, así que no puedo verificar esa afirmación. ¿Revelar su esquema es realmente un gran riesgo para la seguridad? Quiero decir, son bastante abstractos y están divorciados de las implementaciones de hardware y software. Se agradecería una explicación de cómo un atacante podría explotar esquemas conceptuales. Gracias.

Estoy de acuerdo con gbn (entonces +1), pero creo que hay otras dos posibilidades en juego:

1. Es muy posible que su esquema conceptual se superponga mucho con su esquema físico. Conocer los nombres de las tablas le da una ventaja decente en la planificación de sus ataques de inyección SQL.

2. Es muy probable que no tengan documentado su esquema conceptual. Las organizaciones que permiten que los programadores diseñen sus propias bases de datos a menudo no tienen ningún rigor en su proceso de diseño de bases de datos, yendo directamente a la implementación física sin ningún diseño inicial. Es posible que no quieran admitir esto, o que no quieran pasar el tiempo y los problemas de volver a crear un documento conceptual que nunca existió.

Editar: OP ha comentado que la organización a la que se le pide su esquema conceptual es una agencia gubernamental. Esto en mi opinión agrega otra posibilidad probable:

Los funcionarios públicos no son conocidos por su amor por la toma de riesgos, por lo que es poco probable que un funcionario de nivel medio en un departamento gubernamental se esfuerce y divulgue información en caso de que pueda llamar la atención o la ira de alguien más arriba en la jerarquía .

Todavía creo que el # 2 es el más probable.

Sugeriría que es un riesgo de propiedad intelectual pero no quisieron decirlo

Estoy completamente de acuerdo en que el esquema conceptual detrás de la información secreta también debe mantenerse en secreto.

Si los espías recopilan pequeños fragmentos de información que de alguna manera se escapan de las grietas, todavía queda el problema de poner esos fragmentos en contexto. El esquema conceptual proporciona el contexto. La forma y el contenido de los tidbits recopilados pueden ser sustancialmente diferentes de la forma y el contenido de los datos en la base de datos, pero el esquema concurrente proporciona una excelente guía para decodificar las cosas.

Al trabajar en la recuperación de datos para empresas, siempre consideré que un esquema conceptual confiable era una mina de oro. Para estar seguros, estos proyectos no involucraron espionaje. Pero puede ver fácilmente cómo se realiza el mismo análisis.

Muchos proveedores intentan mantener sus esquemas de bases de datos cerca de su cofre. En la mayoría de los casos, se trata de controlar sus pequeños secretos sucios, como la falta absoluta de integridad de los datos o, obviamente, el diseño deficiente de la base de datos. Otras razones incluyen:

• Muchos productos de software tienen esquemas de bases de datos mal diseñados.

• Un deseo de no incurrir en la carga de trabajo de soporte.

• Intenta obligar a los clientes a comprar servicios de consultoría para el trabajo de integración de sistemas.

• Un deseo de maximizar los costos de salida para disuadir a los clientes de migrar a los productos de la competencia.

Desafortunadamente, no está trabajando para el cliente, pero si lo fuera, podría utilizar un argumento en el sentido de preguntar qué defectos arquitectónicos tiene el software, por lo que exponer el esquema de la base de datos podría ser un riesgo de seguridad.