Re: Security Analysis (was Re: Bang for the buck for startup)
From: Meritt James (meritt_james@bah.com)Date: 05/28/02
- Previous message: John Horne: "RE: non-privileged port selection - how is it done?"
- In reply to: Bennett Todd: "Security Analysis (was Re: Bang for the buck for startup)"
- Next in thread: Daymon McCartney: "RE: Biometrics used for Authentication"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 28 May 2002 10:22:40 -0400 From: "Meritt James" <meritt_james@bah.com> To: Bennett Todd <bet@rahul.net>
Good shot - and not just for a startup, but for ANY vulnerability
analysis! Should be done often!
Jim
Bennett Todd wrote:
>
> 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
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
-- James W. Meritt CISSP, CISA Booz | Allen | Hamilton phone: (410) 684-6566
- Previous message: John Horne: "RE: non-privileged port selection - how is it done?"
- In reply to: Bennett Todd: "Security Analysis (was Re: Bang for the buck for startup)"
- Next in thread: Daymon McCartney: "RE: Biometrics used for Authentication"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
