1998-02-19-19:39:56 Larry Kwiat:
> I hope you don't interpret this as a flame. I don't intend it that way,
> some of these are probably going to be hard words for you to read.
Not at all, more are always welcome, come warm your toesies by the fire,
want a marshmallow?
:-)
> >The audit teams include people who are grovelling through paper records.
>
> If your view of that is "grovelling" it probably has a heavy influence on
> how you will interpret the results, and the way you state a case based on
> them.
When _I_ go digging through records, online or paper, depending on
manual examination to try to pick out something interesting, I use the
epithet ``grovelling''. This wasn't a slam at the people who do it, but
a commentary that they aren't doing the computer security audit.
People working with paper records can produce useful work; it's a very
human kind of work, since you're looking for problems in error-ridden,
inconsistent, and incomplete records --- that's the way it is with
paper.
However, no matter how noble and wonderful such work is, it has got
only the most nebulous connection with computer security work. Unless
you've managed to put a firewall system in front of your filing cabinet.
> I've found that information security is so much a larger subject than the
> technical details of an information network, that it is often a matter of
> choice to manage the information network portion of the whole subject by
> its inputs and outputs as a whole: the functional descriptions of the
> people who run it and use it and fix it for example. And also to add
> other considerations that deal with due process, physical access, waste
> control, vendor contracting, and so on.
That sounds like a good plan for someone who doesn't know computers. Of
course, that's just ignoring the computer security problem entirely.
Some of us have our job working on computer security, and so we can't
ignore it and confine ourselves to the human interfaces outside the
computer system. And when you have an internet connection, that adds up
to a lot of human interfaces.
> If you try to do information security in this day and age by
> micro-managing the technology, you are in more potential trouble than
> you can imagine.
If you perform a computer security audit without a detailed examination
of the technology being used, how it's configured, etc. you are in no
trouble at all; you're the grade of useless windbag we had for that
first and very educational audit. Since then we've used interviewing to
ensure we get people who know enough to do the job. That first team
didn't lose anything much, though. They got paid for the useless
``audit'', and left. Heck, their parent company fielded a competant team
for our next call, though we ended up going with another one that we
liked a little better. Our next call included a demand that the computer
security auditors know enough to be able to analyze our computer
security setup and teach us something. That's the critical difference.
> It is a small part (firewalls) but the concept of a firewall is that it
> reflects the information by its "meta-data" qualities to the policy and
> management perspectives of the organization. And from that perspective,
> I don't really care HOW a firewall performs in techie-detail, but as a
> manager of information security issues, I very much care THAT it performs
> to our specifications, and that we have realistic specifications.
> (same with the techie that runs it)
That's a reasonable point of view. Of course, unless you know details of
modern routing protocols, network implementation, application protocols,
and so forth you can't judge whether the policy as written is a good
match for the organization's security needs, nor whether it is
implemented as written. So if you're actually doing to do anything
useful you still need to know those annoying little details:-).
> >Most of us go for off-site replicated servers with enough info to
> >cover the first few hours, and tapes to pick up from there.
> ...and doesn't _that_ fry your security picture if it hasn't been worked
> out as well as the normal operation was, or better...
Better. Easily better. The access needs are far slimmer, so the security
can be cranked down way tighter for a given level of cost and user
hassle.
> The "big picture" of authenticity for a person managing information
> security issues well for an organization has so much in it. Detail, where
> that detail changes so quickly, must be sacrificed to a greater god. That
> doesn't mean throwing the baby out with the bathwater, it means building a
> good integrity around it - protecting it at a higher level by managing the
> concepts (inputs, outputs, design considerations, operation considerations)
> well.
That sounds pretty, but I don't see how to translate it into anything
other than a truly ghastly management structure. It just doesn't work to
have clueless idiots at the top. The people making the high-level
decisions need to understand the things they're deciding about. If the
management decisions that set the overall guidelines aren't informed and
appropriate, you can't backfill a working security implementation to fit
them. It just doesn't work. Been there, saw people fail to do that:-).
> I assume since the CISSP exists, and is held by many people, that it
> must have at least some kind of credibility to the overall subject of
> information security, and as such must deal in some kind of adequate
> fashion with the sub-domain of this that the post is about: firewalls
> and the design, technology and operational considerations around them
> on a network.
I wouldn't make that assumption.
I'd assume instead that since the thing claims to be for information
security professionals, but there's no substantive information about it
available online, that it's pure bunk, a complete waste of time, of
interest only to people with obsolete skills and no ability to learn new
ones who want to over-sell themselves, and bag jobs they cannot
competantly perform once they have them.
-Bennett
References:
|
|
