(ISC)2 Blog

Recovering a dead hard drive in the freezer

I've heard about this technique a few times and, having never tried it myself, I've always been cynical ... but by all accounts it looks like I'm wrong.

The basic idea is to put a failed hard drive in the freezer for at least an hour, preferably overnight, before trying to read the drive. 

Responses to another blog piece on this include plenty of success stories, and a few clues about why it might work.  The reason seems to be not the cooling per se but avoiding the heat generated in the drive when it is working normally.  Presumably those delicate mechanical parts go out of tolerance when hot, or possibly the electronics inside the drive enclosure fail.  Well that makes sense to me, anyway.

So, the techniques basically involve cooling and then keeping the drive cool enough while recovering data from it.  You might install the drive in an external USB drive caddy and put the whole caddy in the freezer, or just use long IDE/SCSI/SATA and power cables.  With long enough leads to reach a laptop or computer nearby, you would probably be able to recover the data from the drive without removing it from the freezer.  Alternatively, you could try to keep it cool (perhaps even in situ) with icepacks (bags of frozen peas for example, or dry ice if you have some handy) but be wary of moving it directly to a warm room as that can create condensation (the critical bits are hermetically sealed, though, so in theory it shouldn't really matter).  Either way, you need to work quickly, and be careful not to knock the drive - ordinary desktop drives are quite fragile.  Don't install the cooled drive inside the computer, or boot from it, as both operations will just warm it up more quickly.  Pre-boot the system from a good disk (a operating installation disk or recovery disk will do fine), get ready to restore the data to another drive, and then plug in the frozen drive, initiate the transfer and cross your fingers while the operation completes.  It may take more than one attempt to recover all the data.

Having hopefully recovered most if not all of your data, it's time to develop a proper process for regular data backups.  If you skip this final step, you really haven't learnt much from this episode have you?  In fact, why wait for a drive failure?  Sort out your backups now!

Regards,
Gary Hinson   NoticeBored.com

Christchurch 6.3 quake today

Yet another powerful earthquake today in Christchurch, the main city in New Zealand’s South Island, reminds us once again of the importance of physical security measures to protect essential, valuable and yet fragile information assets (not least our people!). Our friends and colleagues in Christchurch have already suffered thousands of aftershocks since the Big One in September but occurring at lunchtime on a busy working day puts today's quake into a different category.  It may not have been as severe a shake in geological terms but being much nearer the surface and closer to the city centre has led to significant structural damage, injuries and deaths.

The need for physical disaster planning is crystal clear to New Zealanders, and hopefully to those of you in other geologically active regions of the world, but others shouldn’t be too glib about it.  Physical disasters caused by serious floods, severe storms and other extreme weather incidents, power cuts, fires and so forth are all too common, while decent disaster plans also take account of the possibility of non-physical disasters such malware outbreaks, major frauds, business supply chain failures and global economic crises, network and comms failure, maybe even war and civil disruption (and not just in the obvious hotspots such as Afghanistan, Iraq, Tunisia, Egypt and Libya, this week anyway: who knows what will hit the news headlines next week?).  Aside from planning for incidents and disasters that are to some extent predictable, contingency arrangements help us cope with pretty much anything that comes our way, including by the way coincident events (such as both the twin towers being destroyed in 911).

We are never short of opportunities to link information security to current events, unfortunately.  Think on as you see the chilling news footage appearing on a TV screen near you right now.  Is it time to refresh and update your disaster plans and contingency arrangements?

Pragmatic ethics

Is it ethically acceptable for workers to pinch the odd pencil or Post-It note from work, or is this just the thin end of the wedge that leads to fraud, theft, corruption, Enron and Global Economic Meltdown?

It's a tricky issue when you factor in the difficulties of writing and enforcing corporate policies on ethics, the effects these have on the workforce, and the prospect of tacitly or even formally endorsing unethical and perhaps illegal behaviours through weak policies and lax attitudes towards compliance.  It's also a cultural issue, which makes it fuzzy and complex both to characterise and even more so to address.

In the information security context, an obvious illustration of ethical ambiguity concerns the passing-on of proprietary information by former employees to their new employers.  We've all done it to varying extents, though most of us would justify it by referring to "experience" rather than admitting to any overt misuse of intellectual property, oh no.  The former employer may well be concerned at being drained of valuable assets in this way (and many try to clarify and codify their concerns in employment contracts, policies, even non-compete agreements and exit interviews), but at the same time they are only too pleased to take on "experienced" new employees.  OK so employers may refuse to exploit a new employee's specific knowledge of a competitors strategies, products or processes in such terms, but benefitting from their general expertise and knowledge is universally accepted as fair game. 

Where should we draw the line dividing ethical/acceptable from unethical/unacceptable behaviours?  Some argue passionately that it is a mistake even to attempt to draw ethical dividing lines in this way.  One suggestion is to 'embrace ambiguity', relying on strong, ethical leadership practices to guide the corporate culture instead of voluminous ethic policies, codes of practice and the like.  Taking that a stage further, shouldn't we be using ethics, honesty, integrity and trustworthiness as factors in selecting new employees, especially for privileged and trusted positions that clearly demand them?  If a candidate appears willing to disclose confidential proprietary information from former employers in a job interview, the likelihood is that they will do the same thing when they move on to subsequent jobs, perhaps even while still employed.  Do you really want to take on the liability?

Kind regards, Gary

Digital redaction standard

Receiving the 1st working draft of new international standard ISO/IEC 27038 on digital redaction this morning prompted me to think about the risk associated with redaction, more specifically the information security risks associated with the redaction of electronic documents and other digital data files (e.g. digital still photos and video images; spreadsheets and numeric/statistical data sets and databases).

Two cups of tea and a bit of head scratching later, here's my 'top 10' list of information security risks associated with redaction:

1. Failing to identify correctly all the sensitive data that must be redacted.
2. Failing to delete all the sensitive data e.g. overlaying or modifying rather than actually deleting the sensitive data using methods that can be completely or partially reversed; accidentally leaving one or more copies of the sensitive data completely unredacted; partially deleting the sensitive data leaving data remnants or cached copies, or sufficient information to ‘undelete’ the data; or neglecting to redact sensitive metadata (e.g. in document properties or reviewer comments, or alternate data streams).
3. Excessive redaction, removing more than the specific sensitive items that were supposed to be redacted.
4. Inappropriately altering the meaning of the remaining data as a result of contextual issues (e.g. deleting specific data records may invalidate statistical analysis of the remainder), or by causing collateral damage to the file structure (such as file integrity issues and inappropriate formatting changes) during the redaction process.
5. Leaving sufficient data in the file to enable recipients to infer sensitive information, perhaps in conjunction with other available information sources (e.g. replacing people’s names with anonymous labels in a redacted file but separately disclosing the relationship between labels and names; disclosing anonymous statistical data on known small populations).
6. Accidentally disclosing unredacted versions of the file, whether at the same time and through the same disclosure mechanism or separately.
7. Deliberate disclosure or ‘leakage’ of unredacted versions of the file without permission or inappropriately (e.g. to Wikileaks!).
8. Accidentally or deliberately disclosing the redacted information by some means other than by releasing the digital data (e.g. by releasing the redaction instructions, or being overheard discussing sensitive matters).
9. Placing excessive reliance on redaction, believing it to keep sensitive data totally confidential under all circumstances whereas technical and process failures are possible and incidents sometimes occur in practice, or conversely placing zero reliance on redaction, believing it to be totally incapable of protecting sensitive information (governance and assurance risks).
10. Confidentiality failures that are incidental to the redaction process (such as sending the original file, redaction instructions or redacted file to the wrong email address or these being intercepted by a third party en route to the right person);

While I press ahead with other things, I'd be interested to know what digital redaction risks you think I've either missed or miss-stated.  I'd also love to hear from you about redaction incidents, particularly those involving digital files but even those old-skool hardcopy redaction failures can be quite illuminating.

Regards,
Gary (Gary@isect.com)

PS By all means comment on this blog if you have something to say, or better still join the discussion on the ISO27k Forum or CISSPforum.

PPS  Thanks to the discussion so far, the list of risks has been modified.

The true meaning of "security awareness training"

My eye has been caught once again this afternoon by yet another advertisement disguised as a press release breathlessly informing us that the company can deliver "security awareness training".  It seems innocuous enough, but what does this three-word phrase really tell us about them?

Let me explain.  I consider myself an information security awareness professional - that is, I help customers improve their employee's awareness of information security matters.  Awareness, in my book at least, is a generalized approach, spreading the good word about information security and so leading to a broad company-wide understanding of information security, along with the motivation for employees to behave more securely and help protect valuable yet vulnerable information assets.  My aim is very much to establish a widespread but deep-rooted security culture among the workforce, leading to information security being just "the way we do things around here".  To be truly effective, the default corporate behavior (even when the boss is looking the other way) has to be security-minded, almost instinctive.  I'm not talking about making everyone paranoid security freaks, but something far more subtle: a genuine appreciation of the true worth of information security (both to their employer and to them personally), along with sufficient useful, practical knowledge about typical everyday information security risks and how to deal with them. 

To achieve cultural change on this scale takes patience and persistance.  For all sorts of reasons, it's not something one can achieve overnight, and the moment we stop pushing, the level of awareness starts to decay naturally.  It needs to be delivered continually, barely peeping above the parapet.  Furthermore, it takes skill to draw out the essential and meaningful security messages from the great morass of information security issues we all face, and to present actionable suggestions.  The real creativity comes not in raising awareness of the basics such as viruses and spam but in confidently tackling more important but narrower and often deadly dull security topics in a way that also brings them to life and makes them resonate with the audience.  I challenge anyone to inject some zest into awareness topics such as securing industrial control systems or business continuity planning, no matter how important these issues are. 

To me, training is something quite different.  It's what we do to performing seals - well OK maybe that's a bit harsh but the fact is that it's a decidedly different method with quite distinct aims to awareness.  For a start, training courses usually take place in discrete episodes either in dedicated or temporary training facilities or, these days, through Computer Based Training systems.  Either way, students have to set time aside from their working routines to attend - and I use that specific word advisedly.  "Attend" means they are physically present, and maybe afterwards they collect a tritle little certificate of attendance establishing that they were there.  They didn't necessarily participate or learn, mind you, nor even enjoy the experience.  Truly talented passionate trainers or teachers delivering well-designed and constructed training courses can achieve great things, but clearly they are not all in the same league.  From what I've seen of them, some CBT course providers evidently make a living turning out mind-numbingly dull voiceovers on crude PowerPoint or Flash graphics, maybe interspersed with some amateurish video footage or even worse childish games and cartoons as if they are teaching pre-schoolers to count.  The actual content of security training courses is distinctly variable in scope, quality and effectiveness, but who really cares eh, just so long as the students get their wallpaper and management can tick the "security awareness training" box? 

Finally I'd like to point out the first word in the phrase "security awareness training".  Does that mean physical security, IT security, national security, or something else?  OK, I admit I'm biased here but I consciously and deliberately use the term information security, meaning the protection of valuable information assets (including information, computer data, knowledge, experience, both proprietary and personal, plus the processes and systems used to gather, analyze, output and communicate information) against all manner of risks.  Fair enough, "security awareness" is a convenient contraction but little details like that matter to those of us who notice.

So, to sum up, companies promoting "security awareness training" raise serious doubts in my mind regarding their understanding and appreciation of the field, let alone their competence to deliver.  I wonder if they have read NIST's standard SP800-50 "Building an Information Technology Security Awareness and Training Program" or the hot-off-the-press the new second edition of Rebecca Herold's outstanding book "Managing an Information Security and Privacy Awareness and Training Program", both of which expound on the difference between awareness and training.

Caveat emptor.

Kind regards,
Gary Hinson   www.NoticeBored.com

When Open means Closed

In conjunction with my friend Rob Slade, I'm currently researching and writing about a broad range of information security frameworks.  There is no shortage of them!  Right now, I'm interested in ISECOM/Pete Herzog's OSSTMM (Open Source Security Testing Methodology Manual) and the ISM3 Consortium/Vicente Aceituno Canal's ISM3 (Information Security Management Maturity Model) frameworks but have lucked out on both of them this morning.  I respect both Pete and Vicente for the stirling work they have done but the fact is that neither framework is freely available at the moment, despite the 'open' banner.  OSSTMM version 3 is only available to ISECOM subscribers, while ISM3 has been pulled from the web pending its imminent transfer to The Open Group.

To be fair, we have to pay to get many other security frameworks such as ISO27k (the ISO/IEC 27000 series information security standards), but thankfully not the excellent SP800-series security standards from NIST.  NIST's Special Publications are extremely well written and comprehensive, on the whole, and the series is actively maintained, meaning that older and less popular SP800s are updated and refreshed from time to time.  That they are made available at no charge is a real plus point, especially for those of us with limited security budgets.

Regards,

Gary HInson CISSP

Protect or exploit?

The perennial discussion about the value of risk analysis has broken out yet again over on CISSPforum.  It's close to being classed as one of our zombie topics - the ones that we think we've successfully killed off after getting nowhere but some time later they arise from the grave to haunt us again, over and over.  I wouldn't mind so much but we seem to dance around the same old handbags every time:

• Quantitative versus qualitative risk analysis - the pros and cons of each, and innumerable associated methods, tools and techniques 
• Risk-based versus experience and good practice-based security investment decisions
• Risk- or experience-based versus compliance-based decisions
• All of the above versus risk-based standards such as ISO27k
• The futility of any form of information security risk analysis if management can undermine any argument versus the need for us to be "risk-focused", for various reasons expressed with varying degrees of hand-waving

This afternoon, I'm contemplating a different argument, the contrast between what general business and financial managers think of "risk" versus what it means to CISSPs.  For management, risk is something to be embraced and exploited, where appropriate, because risk brings opportunity.  For CISSPs, risk is something to be avoided, controlled/mitigated or transferred because it is BAD.  We're worlds apart.

So, how about we turn our argument on its head: instead of asking "How can we best minimize information security risk X?", ask "How much information security risk X can the organization stand before it becomes intolerable?" or, for kicks, "How lucky do you feel?".  I find this kind of approach quite liberating, in a funny sort of way, a bit like extreme sports.  Extreme CISSPs deliberately take chances and enjoy the thrill that entails.  I'm not talking about being totally reckless - we're still CISSPs at heart, so we understand the value of contingency measures - but knowingly pushing the boundaries where appropriate, in the full knowledge that some of our risk-taking will fail (just as it will even if we are ultra-conservative!).  The key to success, as in extreme sports, is to know when to stop the game, but the difference with this approach compared to the usual risk-averse-verging-on-paranoid traditional play is that we are not automatically saying "No!" to everything, so if and when we do actually say "No!", it inevitably has more impact. 

Taking this a step further, it is fascinating to discuss such an approach with management, particularly as they have more at stake being the information asset owners, accountable for their protection and exploitation.  It may be counterintuitive, but I suspect a CISO who asks "How much information security can we do without?" stands just as good a chance of getting the funding she needs for critical projects as her more traditional peers - but with a very definite additional advantage, namely the genuine management support that we stick-in-the-muds so often lack.

Resilience - the missing link?

While reading IT Grundschutz, the German information security baseline standards, and in particular the BSI standard 100-4 on Business Continuity Management, I've been thinking about a curious gap that I believe has opened up between the fields of information security and business continuity. 

The way I think of it, 'resilience' (and related concepts such as 'over engineering', redundancy, automated failover and so forth) is very definitely an integral and essential part of 'business continuity' (in other words, keeping vital business operations running as near normally as possible, despite whatever threats and vulnerabilities might materialize).  Keeping unauthorized users out of the applications, systems and networks, preventing data and systems corruption (including that deliberately introduced by corrupt fraudsters, as well as incompetent or indolent users, designers, administrators, developers and managers), avoiding unplanned and unwelcome changes, avoiding/neutralizing malware and maintaining adequate IT performance and capacity are, for me, all important business process resilience controls, and are therefore all valid aspects of 'business continuity'. 

Avoiding or at least reducing the extent/impact of incidents, crises and disasters has got to be better than recovering from them, surely?

However, most 'business continuity' standards are purely concerned with 'Assume a disaster has happened: we need to prepare ourselves to cope with what happens next'.  They talk about timely resumption and recovery, all post-event of course, while most information security standards major on maintaining confidentiality, with a few token nods towards data, network, application or sysem integrity but very little in the way of process or personal integrity and even less about availability, other than referring to 'business continuity' (often meaning IT Disaster Recovery in fact) as if that settles the matter.

Most organizations I've worked with seem to separate information security from business continuity management, in the same way that most separate physical from information security, and have other stovepipes for fraud, risk management and compliance. 

So what on Earth happened to resilience?  Where did it go?  Have you seen it, hiding in a corner somewhere?  While I totally support the need for contingency planning to prepare the organization to cope more effectively with disasters that result from the failure of preventive controls, I strongly suspect that many organizations would be better off diverting some of their not inconsiderable business continuity budgets towards resilience and prevention, or at the very least creating a more coherent strategy linking information security with business continuity through their common interest in resilience.

I'd be especially interested to hear from anyone who is familiar with standards, guidelines etc. that cover resilience (as outlined above) in some detail, whether they claim to cover information security, business continuity or something else entirely.  Go on, give us a clue about where to find the missing field.

... 97, 98, 99, 100, coming, ready or not!

Kind regards,
Gary Hinson
ISO27001security.com
NoticeBored.com

PS  A well-written piece on Investing in software resiliency by Dr. C. Warren Axelrod, U.S. Cyber Consequences Unit, lays out several aspects of resilience, including a number of availability threats, software development process issues and of course a range of IT resilience controls such as fault tolerance and failure recovery, system fail-over and recovery and restoration.  Even cloud computing merits a mention.  However, once again, business continuity and the wider aspects of identifying and maintaining critical business functions are largely implied. 

Security awareness video

If your organization relies on "proximity cards" or "swipe cards", or even good ol' fashioned staff passes, to restrict access to secure areas, I heartily recommend a BBC security awareness video featuring, um, pigs.

Whoever said security awareness sessions have to be boring?  :-)

Gary

Add "human factors"? No.

OK, Gary has asked if the CISSP CBK should be expanded to cover "human factors" in security?

And I answer "No."

With that kind of beginning, you could be forgiven for thinking that I disagree with Gary about the importance of human factors in security.  Nothing could be further from the truth.  I agree with everything he has said about the fundamental significance of human factors in information security, as well as the difficulty of dealing with them, and will defend to the death his right to say it.

What I disagree with is the question.

The CBK already addresses human factors.

When I teach CBK review seminars, I start with the security management domain.  Yes, Gary is right that this field started out with a bunch of technical people who had difficulty understanding that people don't always do what you tell them.  So candidates coming in, who are not prepared for dealing with human factors, get a good scare right off the top.  They have to deal with management, which means dealing with people (and probably politics).  And organizational roles (which have to do with people).  And security awareness training. (Oh, and ethics.)

Moving on to access control, we talk about social engineering there.  (As well as the password choice problem Gary mentioned.)  Good scope for human factors.

Crypto's a technical field, so no human factors, right?  Wrong.  We talk about implementation problems, and the inability of people to be truly random.

Physical security talks about human factors.

BCP talks about human factors.  As long as you are truly recovering the business, as you should be, and not just systems.  (Common mistake.)

Security architecture is pretty technical.  But it deals with the security frameworks, with all those guideline documents.

Applications security has a lot to do with human factors.  (If you actually do it properly.)

Telecom?  Sure, that's technical.  But it also has to do with spam, social networking, phone phreaking, and all kinds of social engineering/human factors implications.

Operations?  You're dealing with people.  In fact, most of the stuff in operations could equally be dealt with in other domains, except for the extra provisions you have to make for your employees who need escalated privileges.  Your classic insider situation.

Law and investigation?  If you don't think that is mostly dealing with human factors, you are in the wrong field.

So, no, the CBK doesn't need to have human factors added.

If you want to talk about whether we need to pull all the human factors stuff out, and put it in a separate domain, that's a different question.

(And, to that one too, I'd say no.  We'd have a human factors domain that takes up three days of a five day seminar, and have to squish the existing domains into the remaining two days.)