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.

At this point, an evolution from the 5 to 10 year old messaging style of security awareness is desperately needed.  Today’s typical training outline can be oversimplified to encompass the following:

• state of information security,
• fallout related to the lack of InfoSec and
• generic steps for risk mitigation

Undoubtedly, there is some InfoSec training that has evolved from this rudimentary form and into more sophisticated variants with greater detail on risk mitigation, as an example.  However, omni-absent is the component of threat perception which is what security awareness programs need to encompass in their next evolutionary iteration.  Threat perception, builds upon security awareness by making some of the revealed security flaws, mishaps, and attacks relevant as viable threats to organization undergoing training.  From there, further relevancy can be built to the group of people that are being trained in respect to what they do to support their organization’s processes and technology.

The general message of today’s security awareness is well intended but it never formulates the message and urgency of baking security in at any level.  This (amongst other factors) is largely due to the fact that there is no sense of relevancy from a threat perspective, even if security awareness campaigns pepper information where comparable companies or roles receive bad fallout (bad PR, loss of accreditation, fines, etc) from the lack of security implementation.  This current message falls short of mobilizing awareness into action. This is not to say that other factors (such as a complete and utter disinterest to security) are responsible for hijacking plans to ramp up security programs, particularly in the aftermath of awareness training as a fire starter.  The cases where people do ‘get it’, are those who have a fundamental understanding of the threats that affect their organization and/or application environment and how missing technical or non-technical controls equate to the increased viability of this threat taking place.

From a purely technical perspective, engineers, developers, and even analysts are more likely to embrace security countermeasures once they see first and understand how attacks and exploits take hostage of what their entrusted to protect, whether that be a network, database, server cluster or even an endpoint.  Once an attack evolves beyond the theoretical or a news piece and into an attack agent threatening what their entrusted to protect, they become much more cognizant and appreciative of implementing risk mitigation strategies.  As a result, security becomes less of something they have to do and more of something they want to include.  This security enlightenment shifts the mindset of being able to not only be aware of security principles and threats, but also to perceive them as viable possibilities to what they do and how they do it.  This is a sharp contrast to InfoSec training efforts that are powered by FUD or knee jerk reactions to adverse events, which can often catalyze the importance of security, albeit for a short duration.

Security needs to become ebbed as a sub-conscience effort within the vein of any operational activity in order to become integrated versus auxiliary.  However, today’s messaging is not poignant enough and traditional FUD, compliance, and just-in-time security efforts cheapen the opportunities for greater security synergy. Threat perception is easily depicted via threat modeling exercises where smoking gun evidence is married to step-by-step logistics on attacks via attack trees.  This approach can be tailored to both technical developers and non-technical management.

Until threat perception accompanies awareness, we’ll go nowhere fast and instead stay with status quo perceptions that simply speaking on the subject goes far enough. Although not discrediting security awareness, but rather its current use and implementation, I’ll have to succumb to the reality of yet another security broken process, ironically this time by many security professionals. In fact, it could be worse than portrayed here in this or any other piece about the matter.  This was quite evident after attending a local security event where the keynote security ‘leader’ for a prominent, global security software company suggested that HR professionals would be best poised to communicate security awareness training.  Amazing.