Human factors awareness module released

The rôle of human beings is arguably the most important topic in information security.  July's security awareness materials explain what it means to develop a “culture of security”, for example changing employees’ attitudes towards security, encouraging them not to tolerate insecurity but to comply with security policies and make things secure by design, and in general encouraging employees to behave more securely in whatever they are doing.

This was an enjoyable module to write, being our home territory, and I hope the topic resonates with our customers.

Reducing the number and/or severity of security incidents (compared to a culture of insecurity) is the aim, of course, which is about creating genuine business value.  Cost-effectiveness makes a huge difference between improving security by changing employee behaviors compared to changing IT systems and implementing additional technical controls.  Security awareness and training activities are significantly cheaper than new technologies.  Best of all, they help the organization get more value from its technical controls too - a double winner.

Physical security for coin traders

Replace "coins" with "valuable assets" in this item about coin dealers needing to protect the coins in their vehicles and the advice is sound - well maybe. Actually, the best advice is never to leave such attractive and portable valuables in an unattended vehicle but sometimes that may in fact be a safer option than carrying them with you, for example to a busy street cafe where bag snatchers ply their trade.

The same applies to laptops, PDAs and the other paraphenalia of modern life.  Don't forget that the value of the stored information may far exceed the hardware value, which is attractive enough in its own right to thieves.

Thieves who break into a car to steal briefcases, laptop bags and fancy electronics are going to be in and out in a flash.  They have no qualms about smashing a window, forcing a doorlock with a screwdriver, jemmying the door open or using a thin flat piece of metal to pop the lock.  Anything you can do to slow them down will help, while strong security is a deterrent for casual thieves.  Not leaving valuables obviously on show is arguably the simplest control - stuff hidden away is not going to attract the attention of a passing druggy.  And key to that is the awareness that your stuff is extremely vulnerable, so don't drop your guard. 

Why don't cars come with welded-in laptop safes or strongboxes, or at the very least those strong metal hoops allowing valuables to be secured in place with cable locks?   Answers on a postcard please.

Have a safe day,
Gary

Phish or chups?

Hi.

Here's a little challenge for you: is this email a legitimate, if somewhat reckless attempt at email marketing by McDonalds, or a cynical phishing attempt aimed at McD's more gullible patrons?  [Click the image to see it full-sized.][And yes, it is safe to click the image in the blog, but probably not a good idea to visit the URL shown in the image.  Trust me.][Bonus marks if you checked the URL in this blog before clicking it.][Extra bonus marks if you are running a relatively secure web browser in a hardened virtual machine, and are not that bothered about clicking links ...]

I'm lovin' it.

[PS  "Chups" are what my Kiwi colleagues buy from the excellent "fush and chup" shops here.  McDs probably call them French Fries but they are about as French as I am.]

Incident management principles

A blog explaining useful principles for managing incidents draws an interesting analogy I've not seen before:

"Incident management plans can be considered one element of a company's risk insulation policy. If risk management is considered in terms of the insulating layers surrounding a live wire (the program or business activity), each layer of mitigation or management affords an additional level of protection against disruptive or harmful influences—thus making a risk pass through several layers of protection or defense prior to being able to cause harm"

That's a neat description of the well-known principle of defense-in-depth, one of a handful of high level and very broadly applicable information security principles.

I have an abiding interest in such high level principles, triggered by compiling a set of them to guide the development of our information security policy based on ISO/IEC 27002.  The ISO standard presents a set of 39 control objectives which were relatively easy to convert into a corresponding set of 39 policy axioms, but needing an even more succinct and generic set of principles as well, I compiled a shortlist of 7 along the lines of: compliance with ISO/IEC 27002; information deserving protection as a valuable asset; controls needed to protect the confidentiality, integrity and availability of information; information security being pervasive throughout the entire organization; defense in depth ... and so on.  Personally, I wish ISO/IEC 27002 would incorporate a set of high level principles of this nature but ISO/IEC JTC 1/SC 27 has such ponderous and tortuous development processes that there's little realistic chance of this happening - unless someone finds a decent set of published infosec principles that would give us a head start.

What would you suggest?

Incident management processes

A blog item on Incident Management Plans caught my eye today.

"The incident management plan (IMP) is a generic and tactical component of the Business Continuity Management (BCM) Plan, offering pragmatic guidelines and responses to support immediate crisis events across a wide spectrum of risk issues as more mature and comprehensive measures are brought into play—typically meeting the needs of the first 24 to 72 hours of a crisis event."

Aside from the confusion of terms (exactly what is a 'crisis event'?), I support the author's key point about incident management spanning the gap between crisis management and continuity [and recovery] management.

In the same vein, information security incident management is but one form of incident management, which has a useful spin-off: if your organization doesn't already have a properly-thought-through process for managing information security incidents, there's a chance you might be able to tap into or plagiarise the processes used to handle other types of incident, for example health and safety incidents and perhaps even generic commercial events such as becoming a takeover target. 

Unfortunately, if your organization doesn't have those either, you're out of luck mate!  Managing information security incidents in a controlled and rational manner may be the least of your worries.


Gary

Social engineering site

Just had to share this with you - a good website about social engineering. I'm using it as part of the research for our forthcoming awareness module on human factors in information security, an enjoyable job this month.

ISACA Security Incident Management audit program

ISACA has released an audit program or checklist to guide IT audits or reviews of the processes and systems supporting the management of information security incidents.  It is free to ISACA members.  It offers a well structured suite of issues to review and questions to ask.  I like the fact that it identifies relevant requirements from COBIT and COSO, and covers the forensic aspects of incident investigation.

However, despite being 43 pages long, it almost completely ignores the final stages of a good practice incident management process where the organization applies the learning from incidents (including near misses) in order to improve its controls.  This significant weakness in the audit program presumably stems from a corresponding weakness in COBIT and COSO, or at least the failure of the checklist's author to identify and address those requirements.  Naturally our own incident management Internal Controls Questionnaire (supplied as part of this month's security awareness module) covers the entire process, and would suggest a number of additional checks and questions to add to the ISACA checklist for a more comprehensive review.

Google Street View wifi privacy incident - a case study

A significant information security incident came to light when Google was accused of secretly scanning WiFi signals and collecting data that some (most?) would consider private - details such as the WiFi SSID (network name) and MAC addresses (network addresses) of the WiFi devices - while its researchers were systematically driving around some 30 countries photographing places for its StreetView service (which itself raises some serious privacy issues). 

Google's initial response to the incident was to deny it but the incident grew more serious as the news media and various privacy commissioners got wind of it.  When Google admitted that it had been collecting WiFi data, it tried to underplay the significance: "Why did you not tell the DPAs that you were collecting WiFi network information?  Given it was unrelated to Street View, that it is accessible to any WiFi-enabled device and that other companies already collect it, we did not think it was necessary. However, it’s clear with hindsight that greater transparency would have been better." 

Later, Alan Eustace, Senior VP of Engineering and Research for Google, said "The engineering team at Google works hard to earn your trust—and we are acutely aware that we failed badly here. We are profoundly sorry for this error and are determined to learn all the lessons we can from our mistake." while CEO Eric Schmidt admitted Google "screwed up" and blamed a software engineer for writing the "rogue code" in 2006.  This illustrates the power of accountability and governance, but this incident is not over yet.

Now, despite Google saying it has deleted at least some of the WiFi data in question, a number of countries are still considering taking legal action over the incident, under privacy and/or unauthorized interception of communications laws ... in other words, the incident has not yet been contained, let alone resolved.

All in all, this would have made an excellent case study for our awareness materials on incident management, and might yet do so in a future revision of the module.  The incident clearly also has value on the privacy and wireless security topics. 

If a similar incident had beset your organization, how would your management have handled it?  What would you have done differently to Google?  Discuss.

Blog comments are open - go ahead, make my day.
Clint

Classifying information security incidents

Information security incidents come in all shapes and sizes, ranging from nil or negligible impact through to total devastation. Quickly classifying incidents as the initial information comes to light (in terms of the nature of the incident and the scale or gravity of it) is a good way to decide what kind of response is appropriate.  Do we add it to a to-do list for someone in IT, or call out the Army? GovCertUK's scheme suits incidents that may have a national impact but it's not hard to create something more useful for the average organization using theirs as a template or starting point.

For a more involved scheme, check out the Verizon Incident Sharing Framework

ITIL incident management

A paper by CA on ITIL incident management includes some unusual process flowcharts like underground maps.  Nice work!