Metaphorically speaking, force-feeding security solutions translates to the industry’s persistent push of the latest security products and solutions down the throat of the enterprise. Continuing with this metaphor, a company becomes unable to properly digest the newly adopted solution into their overall security program. Ironically, this usually takes place on the heels of a fairly new security process or technology that has been recently adopted.
More often than not you see many security experts speaking on how various enterprise security solutions fail. From identity management solutions to public key infrastructures, security experts are quick to identify the shortcomings of security efforts in the enterprise. What is amazing to witness is the timing of these comments in relation to the length of time in which these criticized solutions are implemented. Regardless of how new and/or recent the technology or process, experts are quick to abandon their worth. Amazingly enough, most of these security efforts are criticized as quickly as they were introduced into the enterprise. Quick to judge, many security experts will fault either the technology or the idea as an effective way to solve any given problem. Blatantly missing from their analysis is the idea that the solution was not given enough time to be properly introduced, adopted, and matured within the enterprise. Also important is to understand the efficacy in which it was implemented and managed.
A great example is the issue of security training for developers. On one side, some contend that a well trained developer of security principles will be able to write secure code since they will be made aware of common flaws and how they become exploited. Others will cite that security training does not work, is too expensive, and goes against the natural inclination for developers to simply write code, not secure code since they are not paid to do that. Although these counter points seem well thought out on the surface, they do not consider how the training was conducted, what incentives or requirements were made of developers to complete the training, as well as the frequency of the training. These shallow observations are again unsupported by any empirical, objective, analysis on the subject matter, thereby leaving many with having to qualify these observations as being founded on truth. At best, individual client feedback has shaped these ‘experts’ quick perceptions on newly implemented technologies or processes. Unfortunately, many in and beyond InfoSec take the viewpoints of these experts as gospel. As a result, many will write off efforts such as security training for developers, governance, risk management or any other solution that is marketed yet perhaps not well executed and quickly criticized by security pundits.
Ultimately, it is how security solutions are executed and managed over a sustained period of time that will provide the industry with credible information in determining how they can be improved and not how they can be eliminated. Until we properly execute and measure, we cannot begin to FAIL products and processes due to a handful of poorly implemented cases on a given security discipline or product. There is nothing wrong with discrediting broken solutions/ products however for the benefit of the industry as a whole; they must be made in consideration of the time and effort spent to implement. I don’t care what automation is introduced via a product solution, if there is not a formidable underlying security process, any organization’s security solutions will continue to be wavering as they are force fed the latest and greatest promises from security product evangelists and the like.
Sage advice of the month: Question security sensationalism and opt for founded, strategic solutions.