Dave's Bit Bucket

Mobile / Home-based Computing and Duress

With the continued rise in home-based and mobile working, the possibility of staff being forced to access and potentially modify data by suitably-armed ne'er-do-wells becomes a genuine - if niche - security issue.

I was chatting to a pal on Friday evening who has an Armed Forces background, about duress situations and passwords which might be required.

It turns out that there are actually three categories of duress, these being:

• local: a threat to your person, which will be exercised unless you do what you are told (eg: a gun to your head)
• divorced: a threat to your family or other people you personally care about (and who are in a different location), which will be exercised unless you do what you are told (eg: a gun to your wife's head)
• remote: a threat to individuals unknown to you, which will be carried out unless you do what you are told (eg: a bomb in a populated area).

Taking this into account, it's possible that a well-designed system which authenticates users based on a username and password would require up to 4 passwords per user - one for legitimate login in a non-duress situation, and three more, one for each type of duress!

It's entirely possible that all these different categories would be required, as different actions would be desirable based on the nature of the duress. For instance:

Local duress:

• log me in, increase level of user activity logging on my account, start signing logs if not done already
• start backups / snapshots of databases to which I have access, my home directory, etc
• alert security personnel as to my location and the fact I'm in peril, request their intervention

Divorced duress:

• log me in, increase level of user activity logging on my account, start signing logs if not done already
• start backups / snapshots of databases to which I have access, my home directory, etc
• alert security personnel to the fact that folk I care about are in peril, contact appropriate authorities but remain on standby

Remote duress:

• log me in, increase level of user activity logging on my account, start signing logs if not done already
• start backups / snapshots of databases to which I have access, my home directory, etc
• alert security personnel to the fact that there is a threat to some remote location which can't be disclosed right now, contact appropriate authorities and remain on standby

...or whatever is considered appropriate for the situation, by organisational policy. If it is not considered useful to make a fine-grained characterisation of the duress in order to be able to instruct authorities, the different situations above can be collapsed somewhat.

To re-iterate, in these days of remote working and given the nature of data which many folk have access to, the need for a duress password (or other duress-alerting) system is becoming increasingly important. In an infrastructure designed around "Defence in Depth" principles, a duress password is not only the "last line of defence" for an imperiled legitimate user, but it does for them what smartcards, shared-secret tokens, etc cannot, by enabling them to surreptitiously raise a useful alert.

In fact, for some kinds of protectively-marked data, it's fair to say "if a user's physical location isn't inside a suitable building with appropriate authenticating physical access controls and on-site security personnel, then it's in battlespace".

I can see various points in Sun products at which a duress capability could be inserted; an LDAP server would be the most obvious place (as both normal and duress passwords would be stored there, and the LDAP server would be the natural point at which to record the use of a duress password, approve access as though the password was correct, and raise an alert to some workflow system which would do all the audit and snapshot-wrangling). Changes in account maintenance software would be required, in order to be able to change both normal and duress passwords, but otherwise the surrounding impact would be small provided LDAP was used for pretty much all user authentication (which, frequently, is the case)...

(2007-08-30 10:04:07.0) Permalink Comments [0]