I relate the need for this assessment, prior to jumping to security implementation conclusions, because this balance is a critical step in the security process that many people miss. I often use the work of Judge Learned Hand (what a great name) when I speak about security and liability, but it is helpful to treat Judge Hand's efforts as the bright line of appropriateness that we must straddle, trying to keep from falling into negligence on one side, and expensive delusional security paranoia on the other.
To keep it brief, Judge Hand was a real father of Tort Law thought, and in a case revolving around a drifting ship (U.S v Carroll Towing), Judge hand created a fundamental premise for the Tort judgements that would come after. In what was called, "The Calculus of Negligence", Judge Hand documented a relationship between responsibility, likelihood, and damage. In short, he ruled that if the cost of preventing an event is lower than the product of the likelihood of an event multiplied by the cost of the damage, then you are negligent if you are not preventing that event. This is very useful to determine when you are not doing enough, but I would add the Danahy extension to Judge Hand's seminal work which is this:
If the cost of preventing an event is much higher than the product of the event likelihood multiplied by the cost of the damage, then you would be much better off investing the extra money in the protection of something else, because something else doubtless needs more protection.Understanding this relationship brings us to a need to create a common methodology for understanding and measuring these ratios. In the litany of sources that are consistently passed around, I would recommend that a good place to start is (no shuddering) a government standard, called FIPS 199. While there will be much that instinctively causes many to think that this is probably not the right model for them, I'd differ. I am not saying that it is perfect, or that one can use it in its parochial form for any group, but the model is sound, and extremely helpful.
Speaking to security in its more primal terms, the standard recommends that assets be considered as having the traditional security properties of Confidentiality, Integrity, and Availability. Impacts are then measured according to the likely result of an impingement against any one of these. For different services, or data elements, or other assets, a better understanding of these criteria help to ensure a much more balanced and holistic approach, without the unfortunately commonplace experience of too much security in one place, the wrong security in another place, and no security at all in other's. Here are two examples:
In this example, the system under analysis is doing bookkeeping, for which both confidentiality and accuracy are critically important. While availability is important, one can almost always perform these functions at a later date in the case of a transient failure. Given the importance of these two characteristics, and the overall criticality of the system, the appropriateness test encourages a pretty robust investment of time and resources to ensure that this system is kept whole.
In this second example, My Blog, clearly confidentiality is not an issue, as I hope that everyone comes to read it. Integrity? Yes, I would like for any errors or controversial viewpoints to be my own, but I would not invest a ton of time or money to prevent someone from posing as me, or introducing their own comments, as I could clean them up later. As to availability, I would like it to be up and readable, but I know that people can circle back if I am simply down for a while.
It is typically the case that data or system categorization is viewed as an examination for areas of weakness, and to identify holes in security policy or practice. I would recommend using the same methodology to advance security thinking, to balance it, by considering the possibility of another insight: That too many resources may be in place in one area that could reasonably and appropriately be put to better use somewhere else.



0 comments:
Post a Comment