On The "Bottom-Up" Approach To Data Security
Once I stated the title I immediately realized that there are many distinct dimensions having their own «bottoms» and «ups». So I must specify. The «bottom» is a set of elementary data manipulation operations available to you as a programmer or a data security specialist (although it is often the same «you»). The «top» is a transitive closure of this set. The set of operations available for a user is rather close to the «top», and mapping them into the basic data handling operations constitutes the essence of the programmer's job. The «bottom-up» approach to data security is a job of defining all the necessary data access rules in terms of the basic data handling operations — you apply certain restrictions to various data elements and they affect the data system overall behavior, namely data accessibility in the high-level terms used by the end users. The most elaborated text-book example of this approach is SQL — it gives you very low-level security bricks to build a custom building without specifying explicitly this building emergent properties.
In order to understand the following (rather unsual) reasoning, keep in mind the example of SQL's permission classes (in all their glory, multitude, and low-levelness), but do not forget that it is merely an example of a big family of ideas.
Hereafter I will speak about a problem of interpolation. You are free to call it an argument from analogy, but in fact it is a very precise mathematical model that captures the innermost core of the programming practice in question.
Imagine a 2-dimensional dataset: a target function is only known to deliver certain values in a few predefined points.
Let's say we have successfully applied a polynomial interpolation procedure to this dataset. In other words, we have found a standardized formula that describes our dataset in much more general terms (namely polynomial coefficients). Besides, the given dataset this formula describes infinitely many domain points, mapping them all smoothly into the given co-domain.
This is exactly what you do when composing a security policy from basic permission classes — you search for a «smooth» formula that describes all usecases at once in very general terms. And then you have to make sure that this formula gives you just one strictly defined value for ALL points inside the domain except the given data points.
This is called a «secure system». And you have to do this step in order to prevent security holes, this is the data security itself in its most condensed form.
Easy to see that you have just discarded the most of your labour's results. Building a secure system «bottom-up» is like searching for a «smooth» formula that must behave piecewise (or as close as possible to behave peicewise). Wouldn't be simpler to abandon the search for a generalized formula completely, and straightforward formulate a PIECEWISE definition of the target function?
It would be… Setting aside the fact that ALL tools we use strongly encourage the «bottom-up» approach, ALL the gurus openly preach the «bottom-up» approach simply because all gurus always preach user manuals and only user manuals… The Great IT Tradition of project management kinda prevents alternative approaches too. Let's say you come up with a piecewise defined access ruleset and submit it to a project manager. Guess his response?: "...and by the way, what if a user attempted a perfectly well intended operation (h) what is f(h)? fix it! and give me a PROPER general ruleset". Once you complete the job, here comes a security consultant: "...and by the way, if a user attempts an undocumented action (h) the system allows it, please, forbid it".
In order to understand the following (rather unsual) reasoning, keep in mind the example of SQL's permission classes (in all their glory, multitude, and low-levelness), but do not forget that it is merely an example of a big family of ideas.
Hereafter I will speak about a problem of interpolation. You are free to call it an argument from analogy, but in fact it is a very precise mathematical model that captures the innermost core of the programming practice in question.
Imagine a 2-dimensional dataset: a target function is only known to deliver certain values in a few predefined points.
Let's say we have successfully applied a polynomial interpolation procedure to this dataset. In other words, we have found a standardized formula that describes our dataset in much more general terms (namely polynomial coefficients). Besides, the given dataset this formula describes infinitely many domain points, mapping them all smoothly into the given co-domain.
This is exactly what you do when composing a security policy from basic permission classes — you search for a «smooth» formula that describes all usecases at once in very general terms. And then you have to make sure that this formula gives you just one strictly defined value for ALL points inside the domain except the given data points.
This is called a «secure system». And you have to do this step in order to prevent security holes, this is the data security itself in its most condensed form.
Easy to see that you have just discarded the most of your labour's results. Building a secure system «bottom-up» is like searching for a «smooth» formula that must behave piecewise (or as close as possible to behave peicewise). Wouldn't be simpler to abandon the search for a generalized formula completely, and straightforward formulate a PIECEWISE definition of the target function?
It would be… Setting aside the fact that ALL tools we use strongly encourage the «bottom-up» approach, ALL the gurus openly preach the «bottom-up» approach simply because all gurus always preach user manuals and only user manuals… The Great IT Tradition of project management kinda prevents alternative approaches too. Let's say you come up with a piecewise defined access ruleset and submit it to a project manager. Guess his response?: "...and by the way, what if a user attempted a perfectly well intended operation (h) what is f(h)? fix it! and give me a PROPER general ruleset". Once you complete the job, here comes a security consultant: "...and by the way, if a user attempts an undocumented action (h) the system allows it, please, forbid it".
0 comments