Previous month:
June 2012
Next month:
August 2012

July 2012

Is Security Awareness Time and Money Wasted? A Different Perspective

Dave Aitel recently published an article that generated a fair bit of controversy. In Why You Shouldn't Train Employees for Security Awareness, David claims that money spent on security training for employees would be better spent on securing networks and assets, concluding that "organizations will be much better off if the CSO/CISO focuses instead on preventing network threats and limiting their potential range. Employees can't be expected to keep the company safe; in fact it is just the opposite. Security training will lead to confusion more than anything else."

Aitel makes many valid points. These should not be discounted or ignored because he's arguing against a seemingly prevailing opinion regarding security awareness. One important argument Aitel raises is that users are overmatched, outgunned, and out numbered. This argument is hard to dispute, and no awareness program I know of can prepare users for the diverse and constantly changing threat landscape they face. Combine this with the "trajedy of the URL", where we often teach users to be secure at the expense of making use of the very convenience hyperlinks offer, and I'll admit that, in this context, it is hard to argue that awareness makes a difference.

Aitel explains that the efficacy of security awareness programs is not corroborated by "broad statistical evidence", and offers anecdotal data suggesting that on average, organizations with security programs still see "a click-through rate on client-side attacks of at least 5 to 10 percent."

Here is where my perspective on security awareness programs begins to differ from Dave Aitel's. His conclusions are not wrong, but

Security awareness programs ought to do more than teach users how to avoid click-through and client-side attacks.

"How to" oriented security awareness programs tackle the simplest aspect of client side attacks: how to avoid them.  A program that focuses on "how to" is useful for situations that have predictable, easily replicated sequences of events and are thus easily recognized by users. For example, you can teach a driving student how to parallel park by explaining the act step by step and having the student learn by repetition. The steps are so methodical and rote that some automobiles are "self-parking". We know (and have statistical evidence;-) that attack methods evolve and become more sophisticated, and frankly, rote won't get the job done. If this is all your program does and all you intend to do, it's not doing enough. In this case, Aitel would be right in suggesting you spend your money elsewhere.

We want to help users become safe drivers not rote drivers.


You can't teach driving students how to avoid accidents by exposing them to and teaching them how to react to every possible threat situation, road and weather condition. Instead, you teach them the basic warning signs to look for as they drive: observe and maintain safe distance from other vehicles in all directions, observe weather conditions and adjust speed to provide ample braking time, note shoulder condition, position of sun, and hundreds of other cues and clues. More importantly, you explain why certain responses to threat situations are better than others. The good driver is one who applies the basics - how to, when, and why - and complements these with skills he acquires through experience.

These kinds of awareness skills are as valuable for Internet users as for driving students and experienced drivers.

Security Awareness Is a Necessary Complement to Security Management

Aitel concludes his article with a list of  "what organizations should do instead of wasting time on employee training".  While I truly believe that every one of Dave Aitel's recommendations is rock solid advice and every organization ought to embrace these, I'm not convinced that there is no value to security awareness training.

Before I would juxtapose these recommendations against awareness training, I'd observe that organizations that are not investing in Aitel's list are probably not investing in security awareness, or doing it in the unproductive way I described earlier. Moreover, I think it remains unclear whether an organization should choose to jettison awareness programs to implement Aitel's organization, or whether the broadest benefit is realized if you put no effort into awareness.


Photo by Asgood

Consider the recommendation to "Isolate and Protect Critical Data". What constitutes critical data is not a decision that can or ought to be made exclusively by IT, security staff, or the CSO/CIO. Think of the number of employees who may come up with an innovation, novel idea, business strategy or tactic at any given time or day.  An organization simply cannot delegate the task of accurately cataloging what data are critical, where and how they are stored, or whether they are being developed or communicated from a corporately managed or BYOD to any department or team. Given this, doesn't an organization that has made no investment in making everyone from secretarial staff to senior management aware and attendant to data classification or archival, for example, face a greater challenge to effectively implementing this recommendation?


Next, consider "Access Creep". Security and IT professionals fail to realize how great a divide exists between what they and other employees know about security. How can an organization expect employees to respect principles of least privilege if they haven't explained what it is, why it is important, and what relevance it has to defining access to data, applications, or network segments?

Lastly, consider "Segment the network".  Preventing cyber attacks from spreading laterally across an organization's entire network addresses an important problem, but not the only one. Isn't it better for an organization to make employees aware of why anonymous sharing or un-secured USB ports and drives are dangerous? Is it really a waste of money explaining basic mitigation techniques (and while we're at it, explain what "mitigation" means) to employees, so that like the driving student, they have the basics - how to, when, and why - and can complement these with skills they acquire through experience?

While it is hard to argue that employees can't be expected to keep the company safe, it's equally hard to argue that they can't contribute to reducing the attack surface. And they can only do so if they are informed and motivated to do so. These ought to be the objectives for security awareness programs.

Author Note: My apologies for only referring to Dave Aitel by surname but I found  using his given name "Dave" to be much to disconcerting as I wrote this article.




Looking to hire a programmer? Ask for more...

A colleague linked a job posting to Twitter for a PHP programmer. Interesting timing: I've been in the process of writing a report on the results of a web vulnerabilities survey *and* had just finished the discussion on how frequently PHP was identified as the application platform in the reported attacks (over 80%).

I decided to look to see what job requirements are typically listed for PHP programming positions.

I'd just spent some time looking for resources to share with readers that would help them understand how to better manage and secure PHP so some of the recommendations and considerations in the PHP Security Guide were fresh in my mind.

As I read the job posting, I realized, there's not a single mention of knowledge of security, or secure programming practices here.

Perhaps familiarity with security measures is the sort of knowledge that interviewers ferret out from candidates, but would it be so hard to raise the bar - even in job postings - and make explicit that "we want PHP programmers who have the skills to keep us off the victim list"?

I noticed that "troubleshooting" is mentioned twice and "investigation" once, so I'm guessing that whomever created the job description anticipates "trouble".

Rather than only seeking troubleshooting skills, maybe it's time we ask for trouble avoidance skills, too.


Note: I intentionally did not identify the job posting page. I'm not trying to single out or embarrass anyone. I suspect that this is posting is representative of many for PHP - or other - programming positions.