>
> 0) Determine you organization's mission and goals,
> if you haven't already done so.
GREAT touch. Can't believe I missed that one...
>
> > 1) Determine your assets and organizational needs
>
> 1a) Determine what functions and services you need to get or
> to provide to do your mission with your resources.
>
> > 2) Decide which assets warrant extra protection
>
> 2a) Determine which services or functions can gotten or
> provided while providing an 'acceptable' level or risk or
> protection. If necessary, determine what is 'acceptable'
> for each asset.
>
> > 3) Form a consensus on the type/level of protection required
>
> 3a) Form a concensus that either performance or security comes first.
> There MUST be a buy in that security is the top priority or
> performance is the top priority. There are trade offs for
> each decsion.
>
> > 4) Write this information down
> > 5) Hand this document to your Technical and Legal departments, in order
> > to determine if policy implementation is feasible
>
> The technical and legal departments must be involved all along.
>
> A policy invented by management apart from the technical and
> legal players is often not worth the paper it is printed on.
>
> A concensus can't be built if the major players of technical and
> legal aren't atleast considered in the policy.
I agree... I should have written it down that way :-). Too bad I've never
had the chance to work for someone so "enlightened" :-(. Many upper-level
muckity-mucks I've had the pleasure to take money from like to "come down
from the mountain", to show their power and to prove they are security-savvy.
Such is life :-(.
>
> > 6) If step "5" is a go, have technical/legal author procedure docs
> > which will be referenced by the policy doc
>
> If anything, I would see the remaining effort of cleaning up the
> docs created in (4) to make changes out of (5) and set
> announcement and implementation dates.
I like that... nice.
>
> > 7) Make changes as organizational needs and/or assets change
> >
> > That's about as close to a policy template that you'll see. Policies tend
> > to be tailored, not one-size-fits-all. By definition, this requires
> > extra effort (effort well spent up front, _before_ implementation).
>
> I couldn't agree more!
>
> A good policy is made by LOTS of effort up front. Like most good
> engineering jobs, the more work put into the effort in the design
> phase, the less goes seriously haywire down the road!
>
> --
> John G. Thompson jgt10 @
amdahl .
com 1-408-992-2088
> Amdahl Corporation, P.O. Box 3470 MS 383, Sunnyvale, CA 94088-3470
>
> [The opinions expressed are MINE. They do not necessarily reflect the
> policies, procedures, press releases or opionions of the Amdahl Corporation.]
>
Man, if I didn't know any better, I'd say we were authoring a policy
template :-). A very hot management item these days, doncha know... I almost
feel "empowered" :-).
Have fun,
--
John Bell, CACI Inc. - Federal
Bloomington, Indiana (Midwest RE-Engineering Division)
job @
hprofsdv .
nwscc .
sea06 .
navy .
mil -OR- jbii @
mama .
indstate .
edu
"Hi ho! Yow! I'm surfing ARPANET!"
- anagram for "The Information Superhighway"
References:
|
|
