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
