> Bryan D. Boyle wrote:
> Rabid Wombat wrote:
> >
> > WTH does C2 security have to do with a system that should not have any
> > user accounts on it, no user access to it?
>
> Nothing. But, it is a good buzzword that can be thrown around to make
> it look like you know what you are talking about, when, in fact, if you
> run the full suite of C2, you probably have opened up more holes in your
> os than if you actually ran a stripped-down, tightly configured, and
> heavily controlled system environment.
A flatly false statement. C2 tightens up security -- its not a magic
bullet, but then what is? Adding C2 does _NOT_ open more holes than
it closes.
>
> But C2 is some sort of magic talisman for security. Like MTBE is a good
> oxygenate for gasoline. It impresses those that don't know any better.
This is a common misconception: i.e.; that C2 has no benefit for firewalls
or network security.
The audit trail alone is a _huge_ benefit for security. Proxy logging
occurs only if the proxy cooperates by writing log entries. A real C2
system will log all security relevant events by all programs with or
without their cooperation. C2 systems for application firewalls can
and should be extended to audit network security events.
Of course some firewalls don't have much of an OS to speak of. That
doesn't mean that they don't need a security analysis of whatever it
is that the _do_ have; it just means that C2 dosn't apply directly.
>
> Of course, if you don't run the system EXACTLY as the qualification
> suite specified, the system is not rated at the level you think you are.
The evaluation covers _one_ configuration. Trying to evaluate all
possible permutations of configuration options would be impossible
because of the sheer number of possible permutations.
But a C2 configuration at least gives the admin a _baseline_ for how the system
should be configured. If the admin deviates he has to _think_ "how
does this impact the security of my system" (what a novel idea).
Now I admit that it sounds pretty silly to take the stance "run this without
any networking if you want to be secure". But in light of the reality
of the situation thats not that far from the truth. The Red Book
gives a trusted network interpretation of "C2". This includes a
SECRECY POLICY that is "enforced on the network to prevent
unauthorized users from reading the sensitive information entrusted
to the network". So C2 _can_ be extended to encompase networking
concepts. How well the OB maps into networking is an issue that might
be worth discussing. But it can and does map.
Conclusion:
C2 is _not_ the holy grail of computer security, but
C2 security has positive benefits for the firewall OS,
especially for proxy application type firewalls.
I do a lot of work with audit trails (logs) for firewalls and B1/C2
systems. It never ceases to amaze me how under appreciated those logs
are. We have solved many complex mysteries by reviewing the log
files. On our system, its as if every process running were saving
a "truss" style output _all_ the time, but without noticable overhead.
The OS related security events and the network security events are in
the same log file, and every record is time stamped to the hundreth of a
second. I can write log analysis programs that test the integrity in
practice of my chroot jails and such. And whenever someone telnets
to my host, I can see the connection records and _also_ that tlid
forks and execs telnetd. Then I can see exactly which shared
libraries telnetd binds to; and that it exec's login. Then I can see
which libraries login binds to, and that it opens the utmp files,
/etc/default/login, /etc/passwd, /etc/shadow ...
This type of detailed logging is of tremendous value when you try
to analyze a breakin.
Mark Riggins
Secure Systems Engineering
AT&T Labs
References:
|
|
