2002-05-21-09:55:30 Meritt James: > [ start with ] review of the security plans, policies and > procedures in existence with the 'modification' where things are > found lacking and the creation of ones that no longer exist.
I would agree; security policies and standards are the place to
start when you've got nothing in place already. But where do they
come from?
I think when starting from scratch, the first step is to enumerate
computer-related resources of concern to the organization.
Start with a hardware vision; it's concrete and that's good.
Enumerating interesting hardware should be pretty easy, for a small
shop; you'll have one or more nets with client systems on them,
perhaps the client systems will justify being categorized into two
or more classifications (e.g. sort out HR from developers:-). You'll
have various servers. You'll have various core network components
gluing this goo together, you'll have various external interfaces.
When you've completed this enumeration, you've got a list, with two
interesting characteristics:
(1) All the computer gear you have that you care about is on that
list; and
(2) All the components collected within any single item on the list
have very roughly similar security threat profiles.
That item #2 is what I was hinting at when I suggested segregating
clients into different pools. For a small shop, this list can be
brained out in an hour or two over a conference table with the
sysadmins, and then double-checked with a walkaround.
Keep an eye out for exceptions, typically distributed software
subsystems that cut across attempts at hardware partitioning and
need to be separately enumerated. Email is a canonical example. Web
browsing is another.
Next, you need to have, either explicitly or just carried about in
your head, an exhaustive list of "interesting" threat categories. I
tend to use a double-list myself, with technical categories like
- denial of service
- corruption or deletion of data
- theft of data
- misuse of systems
which can then drive organizational costs like
- damage to reputation
- manpower expenses to repair damage
- opportunity costs from loss of access to resources
- theft of resources
For each item or category on your systems enumeration list, run it
against your threat list and note any that might apply with enough
concern to interest the organization; concern tends to be a product
of a non-negligible likelihood of occurrence times a non-trivial
cost associated with an incident.
Now you're equipped to prioritize technical fixes where appropriate,
and to write the detailed procedures and technical guidelines that
are used to provide compensating controls where technical measures
aren't available or appropriate.
When this is closing on done, the final step is to engineer, and
as much as possible automate, the periodic review and adjustment
process used to maintain the controls and the policies and so forth
in track with changing reality. Where possible, arrange for realtime
updates, where the change management process that controls making
changes in the environment drives security reviews. Similarly,
have people tracking threat reporting lists looking for new issues
and feeding them into your security review process. And since such
procedures can never be 100% comprehensive, schedule periodic
reviews, external audits, pen tests, etc. to catch things you miss.
Then you move on to the next shop and start over from step one.
If the above sketch sounds outlandishly excessive for a small
organization, keep in mind that a great many of the costs and
complexities of systematic security engineering can be reduced by
careful choice of tools. Use only components with the cleanest known
track records for security over time. Disallow use of any tool or
protocol unless careful security analysis supports a belief that it
will not be a source of security problems at _any_ point in the
future.
Sometimes the limitation to components free of security problems is
too confining in practice. So then you have to tear into the
detailed threat analysis. Remember to allocate the costs of the
analysis, of any protective measures, and of any adopted risks to
the chosen component; failure to do so has been at the root of the
worst problems I've seen.
-Bennett
msg06907/pgp00000.pgp
Description: PGP signature
