| Seems contradictory: the networking, Unix, and security folks shouldn't
| all be involved ("too many cooks"), but they should work together more
| closely? There must be some nuance I'm missing.
The difference that I intended to evince is analogous to the difference
between spaghetti code and good modular code. There is a need for well
defined interfaces and clearly defined responsibilities and authority.
Ultimately these groups do have to coordinate, but one doesn't want a
firewall designed, implemented or managed by a committee. OTOH, a
security policy is often defined by a committee, hopefully guided
sufficiently well so that the policies are reasonable, implementable,
and so on. As another poster pointed out, it is very beneficial for
the groups to cross-educate one other. That sort of involvement is
good. Working at cross purposes because of muddled divisions of
responsibility is not. Generally, cooperation is better than conflict.
For instance, there is often a desire for, but not necessarily by, the
networking group to administer the DNS system. Usually, but not always,
this means controlling a daemon running with privileges on a Unix host.
Even if there is great software automation to facilitate this, who should
be responsible for maintaining the BIND software and the rest of the Unix
system on which it depends? So, who is then ultimately responsible for
the name servers? Making three different groups responsible seems silly
to me. In this particular example, the Unix admins should be responsible,
IMHO, though they could then delegate some file maintenance as appropriate.
But, the authority and responsibility should flow through one administrative
group, not be split asunder. There is a difference between one group
delegating (and directing) some work, and a higher authority dividing the
responsibility, especially when those divisions only make sense at a
superficial level. For instance, the difference between hosts and
networks and comm equipment was relatively clear in the mainframe
environment. It is much less so in the days of NFS and diskless or
dataless client workstations.
In some sense, this is all a matter of engineering judgement. Metrics
have been written to evaluate code quality, for example, but in general
the organization and compartmentalization of complex systems is far from
an exact science. Ideally, the boundaries should be placed so as to
minimize the bandwidth and connectivity across them and to maximize the
clarity and cleanness of the division. For example, minimize the number
of shared or global variables, minimize the use of "friends" in C++,
don't use "goto's", and so on. Even firewalls can be viewed as an
example of a well defined interface (or boundary), designed to implement
a particular security policy.
| But another big danger is a lack of compartmentalization of the security
| function, resulting in conflicts of interest between maximum functionality
| and facility of use vs. security of the organization's resources.
Agreed. Someone has to watch the watchmen. Even I admit to the great
temptation of sweeping things under the rug that no one will notice or
inspect. But, there is a difference between cross-checking, auditing
and oversight on the one hand, and divided responsibilty on the other.
However, there are dangers to compartmentalization as well. It can be
counterproductive if not done properly. Somewhere, the global interests
of the enterprise have to be nurtured by someone. Optimization with
localized or compartmentalized knowledge does not necessarily lead to
global optimization. For instance, how many of us really believe the
legal notion that the truth will come out of two groups of lawyers duking
it out before a judge and jury?
Two quotes of an economic bent come to mind:
If you try to make every sector of your business a 'profit center',
you destroy the system as a whole. Every component must work to
accomplish the aim of the system. We have been misled in America
by 'competition'. We think competition is important but cooperation
is much better. We worry about market share, when everyone in the
corporation should be concerned about expanding the market.
-- W. Edwards Demming
In the American system narrow profit centers often lead to
noncooperation between different parts of the same firm, since
no one wants to sacrifice one's own output (and, hence, bonus)
to help some other part of the firm raise its output, even if
that sacrifice would lead to higher output by the firm as a whole.
-- Lester Thurow
One last example, if I may. When observing the sort of responsibility
sharing mandated by management, I've often felt that management was
dividing everything up so that each of the different groups would have
its own share of the pie. This might have some inspiration in workload
balancing or cross-training or whatever, but it reminds me greatly of
the manner in which military operations used to be organized, farming
out pieces to the various branches of the military so that everyone got
their fair share, largely oblivious to the ultimate objective. This
situation was addressed by congressional legislation (sorry, but I have
no available references, but AFAIR Sen. Goldwater was one of the sponsors).
The result was the undivided operational authority that Gen. Schwartzkopf
weilded in Desert Strom. Compare the results with those of the various
previous fiascos, e.g. Grenada and Desert-1.
BTW, I used to preach placing a router at every administrative boundary
in an IP network (back in the days when some folks argued about routers
and bridges). In many cases, that should be amended to be a firewall
these days, depending on your security concerns. YMMV.
Sorry for the ranting. Back to lurking.
Follow-ups to alt.management.theory?? 8-)
Regards,
Chuck
References:
|
|
