On Thu, Feb 28, 2008 at 2:48 PM, Ed Brown <[EMAIL PROTECTED]> wrote:
> I've asked RedHat to respond through our support channel, but I'd like
>  to raise this issue here too, for discussion, and to see if others see
>  a need for a response by RedHat.
>
>  There are third-party 'benchmarks' or configuration guides for RHEL5
>  that are becoming standards, or mandates, at least for some government
>  sites.  E.g.:
>  http://www.cisecurity.org/tools2/linux/CIS_RHEL5_Benchmark_v1.0.pdf
>  (requires registration to download)
>  or:
>  http://www.nsa.gov/snac/os/redhat/rhel5-guide-i731.pdf
>
>  Each is over a hundred pages of configuration recommendations, from
>  the common sense (turn off services you don't need) to the
>  micro-managed and essentially arbitrary (chmod /etc/sysctl.conf from
>  0644 to 0600).  Whether or not these documents induce a gag reflex,
>  compliance with some such configuration standard is becoming de rigeur
>  for some sites, how else to prove your system is securely set up?
>

I am probably preaching to the choir, but it doesn't really prove that
your system is securely set up. It proves that you have processes in
place to better control and understand your system (if you have
cfengine checkign that 0600 is what is set on the file and it changes
at 0:23 in the morning you know about it and will be able to find out
why...) Those processes can lead to better security, but they can also
be gotten around with enough work to make them completely useless...

>  So these are my questions:
>
>   - Are RedHat's "enterprise" operating systems insecure as shipped?
>  Is third-party expertise on how to secure RHEL systems necessary?
>

Well I hope so .. that way I can pay for my kids college by consulting
on this :). Actually no it isnt. Meeting processes and control
requirements for a site is what is really being done.

>   - Why isn't RedHat providing a certified secure OS installation?
>  Why aren't they working with CIS or other third-party 'authorities' to
>  either implement these security must-haves, or to educate the security
>  'experts' on what is appropriate?  Or are they?
>

Well the issue is that none of these guidelines have a definitive
setting as each site is completely different. I mean from experience
none of the national labs have the same desktop policies because each
one has come up with different threat models for their particular
setup. Then there is the nature of the matter being protected
organizational levels. The settings that DOD wants are different than
DOE which is different from DHS. Inside of each of those departments,
you end up with site specific changes (look at how different the items
between labs inside of NNSA are.) And then there is the cost of
keeping it up to date. The settings mandated by NNSA at the beginning
of a fiscal year may not be the same as 6 months later.

>   - To what degree are the so-called benchmarks arbitrary and unnecessary?
>

It depends on the threat model for the site and the data being
'protected'/audited. Its like the proposed change to put a locked room
and guard around mainframes containing sensitive data.. good idea..
but when it was extended to any and all Unix's because they were the
equivalent to mainframes and they might have sensitive data.. it
becomes a bad idea :).


>  Anybody else similarly concerned, or have other perspectives?

I have a book full of them :). It is one of the most aggravating
processes of dealing with very large organizations because the size
and changes make it very hard to understand why someone else wants
something done OR how to tell them that it isnt a good idea in this
situation without looking like a "We can't do that because we are
special".

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list

Reply via email to