TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: Who gets the magic scepter when there are three of it?
Subject:Re: Who gets the magic scepter when there are three of it? From:Jefe de redacciÃn <editorialstandards -at- gmail -dot- com> To:Paul Goble <pgcommunication -at- gmail -dot- com> Date:Fri, 1 Oct 2010 12:11:22 -0400
>> 2010/9/27 Jefe de redacciÃn <editorialstandards -at- gmail -dot- com>
>>
>>> I had a nice table where I described a system of authentication tokens that
>>> should normally be held by different people. ÂWe can hardly suggest that the CSO keep one split of
>>> his token, give one to his secretary, one to the janitor...
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On Fri, Oct 1, 2010 at 9:22 AM, Paul Goble <pgcommunication -at- gmail -dot- com> wrote:
> Another variation is to have the secretary hold the janitor's token in
> a lockbox to which the janitor has a key, thus adding a layer of human
> authentication for the less-than-perfectly-trusted token holder.
>
> Of course, any such multi-factor authentication system needs to
> consider what happens when the CSO and CIO are both involved in, say,
> a plane crash when they violate the organization's "no two key people
> in one place at one time" rule. An organization this
> security-conscious needs to have enough people to hold the split
> tokens, AND enough people to act as backups in any conceivable
> contingency, AND a plan to activate the backups.
You would, indeed, think that any organization big enough, and
self-important enough to want to implement such measures
and layers would be overrun with suitable candidates for each
role.
But then, you have small shops and start-ups that are sub-contracting
pieces of a larger 'solution', and because they're in that supply chain,
they are compelled to adhere to the same standards. Often it might
be mandated by some third party compliance-verifying/enforcing
agency, or it might be that a certain nameless government department
is the ultimate customer.
When I worked at another big multi-national before 9/11, we thought
planes crashing into the building was too far-fetched, so we worked
up one disaster scenario where the bulk-propane or bulk-gasoline
trucks that regularly drove past the front door might jump the curb
and blow up. One outcome of having that scenario in the official
disaster-recovery/business-continuity plan was to move some of
the execs from offices with views over the street to offices with
views out the back of the building (a sports-field-length away).
One exec who moved for that reason, looking out his new window
over the huge backup generators, asked (only half-kidding) "Diesel
fuel doesn't blow up does it?" To which I replied, "Well, in diesel
engines it doesn't even need a spark to explode", and then I backed
out of his office with a big insincere smile on my face.
> To bring the topic back around to tech writing... Not having worked
> with a system quite this secure, I wonder who typically writes the
> security policies--the system vendor or the client organization? ÂHow
> does one write and convey a plan so that the backup people can step
> into their roles with a minimum of confusion and delay?
The client, with help from wherever they can get it. So a thoughtful
vendor provides suggestions and talking points.
The topic never left techwriting, did it? :-)
Being the sort who apprehends things when he sees a few sufficiently
different examples, I like to provide illustrative examples for the benefit
of people who are just getting into the biz or into the more stratospheric
levels of information and asset security. Use cases, you might say.
In other words, I'm not providing a prescription, but some possibilities
that suggest how an eventual "custom" solution should work. In fact,
that poor tech writer who was hired to write up those procedures - or
the poor engineer who's been hauled off his real work to set up the
in-house security scheme - might appreciate the hints and background
when they embark on the new instructions for the new procedures.
Probably the best solution for a small company was the suggestion
(thanks, Sally) that each officer hold part of the key to her/his own
domain and parts of the keys to the domains of other officers. That way,
the separation and mullti-person requirements are met from a small
pool of trusted persons. Or from the small pool of persons whose
security clearances have so far come back approved, while the rest
are still pending, pending, pending.
Sorry for slow reply. I was away.
</kevin>
--
 Â__o
_`\<,_
(*)/ (*)
Don't go away. We'll be right back. Â.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help.
Choose your authoring formats and get any output you may need. Try
Doc-To-Help, now with MS SharePoint integration, free for 30-days. http://www.doctohelp.com
LavaCon 2010 in San Diego Sept 29 - Oct 2 is now open for registration.
Use referral code TECHWR-L for $50 off conference tuition!
See program at: http://lavacon.org/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
