An interesting techtalk on security at work got me into tread of thoughts on security. The popular paradigm on security is that there is no such thing called secured. From my perspective what this explain is that the reality of secure is based on the factor: “secure enough”. This is also a very debatable relative measure hence it is open for discussion.
In my opinion, the entity which needs to be secured should be “secure enough” so that the effort that requires to compromise the entity, exceeds the benefits of compromising by a highly discouraging or technically challenging gap. This leaves us at the question how we can define this gap and to do that we will have to look at how attractive the entity to be subject to a security threat.
When we consider influences for security offenses, I believe they would fall into same categories that influence espionage as a crime. MICE! According to Ira Winkler the acronym MICE stands for Money, Ideology, Coercion and Ego that sums up influences for crime. These would make an entity more or less attractive for a security attack and depending on that it would set the price for the head - how much momentum or expense is worthwhile for the compromising process (monetary or other means). At operational stage, the momentum or expense would be converted into dollars, computation power, elapse for decrypting/brute-forcing or the size of a botnet employed.
As a developer I believe in adhering to best security practices for development from the ground level. But in realistic business scenarios, where time and money are highly appreciated and controlled resources, I believe it would be beneficial to identify a set of matrices that would roughly quantify and elaborate the security necessities for a given software or a system, to make it “secure enough”. Derived matrices and requirements, of course, would be focused on current context, will be agile and in need of constant improvement over the time like any other software requirement. If deriving such matrices is feasible, it should be possible to include that in estimations and planning frameworks that essentially provide great insight at project initiations. It would also be good support material to convince non-technical clients on resources they should spend for security aspects of their products. At the end of the day, no developer nor architect would complain having another tool to reduce the unaccounted risk and burden of software security from back their minds to a version-ed documentation.
