How much of a security risk are published conceptual schema?

Question

I was requesting the conceptual schemas from a government agency's information system for my research. My request has been denied on the grounds of it being a security risk.

I don't really have extensive database experience so I can't verify that claim. Is disclosing your schema really that big of a security risk? I mean, those are pretty abstract and divorced from the hardware and software implementations. An explanation of how an attacker could exploit conceptual schemas would be appreciated. Thanks.

Answer 1

Agreed with gbn (so +1), but I think there are two other possibilities at play:

1. It is quite possible that their conceptual schema has a lot of overlap with their physical schema. Knowing table names gives you a decent head start in planning your SQL injection attacks.

2. It is very likely they don't have their conceptual schema documented. Organizations that let programmers design their own databases often don't have any rigour in their database design process, going straight to physical implementation without any initial design. They may not want to admit this, or they may not want to go to the time and trouble of back-creating a conceptual document that never existed.

Edit: OP has commented that the organization being asked for their conceptual schema is a governement agency. This to my mind adds another likely possibility:

Civil servants aren't known for their love of risk-taking and so a mid-level functionary in a government department is unlikely to stick their neck out and release information just in case it might draw the attention or ire of someone further up the hierarchy.

I do still think that #2 is the most likely.

Answer 2

I'd suggest it is an Intellectual Property risk but they didn't want to say it

Answer 3

I completely agree that the conceptual schema behind secret information has to be kept secret as well.

If spies collect little tidbits of information that somehow slip through the cracks, there still remains the problem of putting those tidbits into context. The conceptual schema provides the context. The form and the content of the tidbits collected may be substantially different from the form and the content of the data in the database, but the concpetual schema provides an excellent guide to decoding the stuff.

In working on data recovery for companies, I always considered a reliable conceptual schema to be a gold mine. To be sure, these projects didn't involve espionage. But can easily see how the same analysis carries over.

Answer 4

A lot of vendors try to keep their database schemas close to their chest. As often as not, it's about keeping a lid on their dirty little secrets like abject lack of data integrity or obviously poor database design. Other reasons include:

• Many software products have poorly designed database schemas.

• A desire not to incur support workload.

• Attempts to force customers into buying consultancy services for systems integration work.

• A desire to maximise exit costs to discourage customers from migrating to competitor's products.

Unfortunately you're not working for the customer, but if you were you could use an argument along the lines of enquiring just what architectural flaws the software has so that exposing the database schema might be a security risk.