Posts

Showing posts from June, 2010

Human factors awareness module released

Image
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...

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...

Phish or chups?

Image
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 ...

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 plagiar...

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 ...

Google Street View wifi privacy incident - a case study

Image
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. Howev...

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!