1998-04-29-16:01:00 Darren: > > I'd point to our security policy. > > So what ? Who's verified that your security policy is any good? How do you verify a security policy, anyway? Since a security policy is just a written cache of decisions you've worked out the hard way (by analysis and negotiation) it comes to, how do you verify a decision-making process? Rotsa Ruck. Gotta have one to get the job done, no way to prove you're doing it right. > The need for 3rd party review simply cannot be ignored. _Sure_ it can. At the level of policy setting, third-party review is somewhere on beyond neurotic, and on into downright bizarre. If you're doing your job right, your policy is the essence of the job you are doing, and is your most valuable company property. I can sorta barely conceive of maybe hiring some truly world-class elite to review the policy and more importantly the policy-makers, if you can find 'em. Does Wheelgroup still do that? I haven't heard of any other company I'd think about trusting to do something like that. And I'm pretty sure mjr is out of that business. But if your independant reviewer doesn't like the policy, your choices come down to ignoring the independant reviewer, or firing the makers of the policy. It's hard to fire policymakers. I've seen it done; the usual process is to rearrange the company around them until they're all alone, then wait for them to leave of their own volition. Slow and expensive work. > I don't trust the interview method. I've come across one person who was > employed on the basis that they did well in cross examination but when > put in the field...well...they failed mine :-) If the people who interviewd this hire were competant to perform the examination, then the hire should have been up to your standards --- unless there was a personality conflict. But it sounds more like the interviewers got fooled. Always a risk. That is why you check references unless you know a lot more than the person you're interviewing. ``The interview method'' doesn't stand on its own; it's reinforced by checking references carefully, except in the case of junior hires. > What about cases where there's a need to get certificates in order to > get business? Never worked in such a field. Some of my employers have, but never anywhere near the computer side of operations. > If you wanted to get in on a Government Contract but in order to do so > you needed ISO 9000, would you decide to turn it down based on that? Put it more simply: are you a beltway bandit? I'm not, so I wouldn't dream of pursuing ISO 9000, and I have trouble imaging me working at a place that would pursue ISO 9000 certification. On the other hand, if I were an amoral leech hooked up to the federal udder and sucking for all I was worth, I'd have my ISO 9000 certification in a shiny frame, and have cerified copies printed up to give away to prospective ``customers'', before I serviced them. > In my mind, it is reasonable to expect that some certificates > are there because they don't represent just a desire to get the > certificates, but a desire to do the work required to get them too and > a desire to meet a client's needs. In some industries this is true. Such industries aren't places where I'd work. Interestingly, such industries have been quite impressively conspicuous for poor security. Hmm. Probably too much to hope that there's a meaningful correlation there. But back to our muttons, in the industry where I'm employed, step one is _always_ to review the customer's claimed needs and make sure the customer got them right. All too often the customer latches on to an implementation method and states that as a need. When that happens I double-check the decision-making process behind that implementation choice, and if I think it's flawed I take that up with the customer. When the customer isn't interested in getting their needs well defined, but just wants to buy the solution that's in their eye, I tend to go away --- unless of course they've found a good solution. That happens occasionally. -Bennett
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:57:29 PDT