Greetings, All!
This topic came up last August, with much the same response the Mr.
Johnson-Bryden produced:
On Thu, 9 Nov 1995, Johnson-Bryden, Ian wrote:
> If someone has produced a real risk/security policy it should not be
> released to anyone other than authorised users for obvious reasons. If it is
> similar to a 'Corporate Mission Statement' it wont be worth much. If it is a
> fully detailed document which someone has unwisely made public, it should
> only be meaningful to the owner because of those unique elements to that
> enterprise, other than it shows how one outfit approached the issues. There
> are now a range of books which cover risk/security policy generation in
> varying detail and from different perspectives.
> Ian J-B
> ----------
Aside from the fact that an enormous number of security policies and internet
usage guidelines are freely available on the net, there is a fundamental
breakdown of communication here. Warren S. Moore, CISSP, produced a good set
of definitions of terms and I quote his message to provide that
information once again.
BTW, IMHO the policy must be a public document.
Regards,
Al Dowd
dowd @
sctc .
com secure computing corporation
begin quoted material
<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>
From: warren .
moore @
cbis .
com Warren Moore
10 Aug 95 8:10:51 EDT
List: firewalls-owner @
greatcircle .
com
Message-Id: 9508101515 .
AA4890 @
notes
John Cougar writes:
>give away a copy of an organisations Security Policy?!? Not only must
>you be kidding, but also: fat chance. That'd be as negligent as giving
>away company trade secrets!
I may have missed something here, and certainly not to start a war, but
that's wrong. Copies of real, in-use, corporate security policies are
available from many different sources--starting with the Computer Security
Institute's old "Computer Security Handbook," and the MIS Training
Institute's "Information Security Resource Manual." (IBM, First American
National Bank, yadatayada). In some cases they're slightly sanitized, but the
base document is there. And, there's really no reason not to provide samples
(if management approves), simply because a true Corporate Security Policy
statement isn't going to say very much anyway -- it should be nothing more
than a short statement of what your corporate entity's leaders expect.
Perhaps it's splitting hairs, but many people don't understand (and often
confuse) the base meanings of the words "Policy," "Standards," "Guidelines,"
and "Procedures." If you use the definitions below, there's no reason not to
let people know your policy, but quite a few to guard your standards,
guidelines, and procedures closely.
Policy: A statement of *what* management expects; not how those expectations
will be met.
Standard(s): The criteria against which results are to be judged.
Guideline(s): Items that *should* be considered when a particular subject is
studied and analyzed. Guidelines are not always an exhaustive list, nor are
they always applicable to all things in all cases.
Procedure(s): A detailed step-by-step description of *how* a job is done,
defining *who* does *what*. Procedures are written to support policy, meet
standards, use guidelines when necessary, and *show the way to do something.*
Warren S. Moore, CISSP
Information Security Specialist
<warren .
moore @
cbis .
com>
Cincinnati Bell Information Systems Inc.
My Opinions Are Mine Only -- Who Else Would Claim Them?
<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>=<*>
end quoted material
I don't claim them, but I sure do quote them. {ad} ;-)
References:
|
|
