-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! Don't forget this aspect: A lot of statistics show that most internal intrusion comes from inside a lot of companies so don't say a network not connected to the internet is safe from internal intrusion. There are a lot of ways to bypass security mechanisms if systems are outdated. - From the SLES point of view there is a longer supported life time of products and updates will be available a longer time. Another aspect is the certification of hardware for SuSE - there are a lot of more drivers for difficult hardware than on other distributions with their way of thinking forbidding some kind of drivers - e.g. use of redmond kind wireless drivers od special Raid drivers. The best way to argue is to catch advantages and disadvantages for an argumentation (possibly having enough point for the supposed point of view). Don't think in your way try to get in the other persons point of view: Find ways to spare money for the entusiasts and bureaucrats e.g. price per license and compare RHES and SLES and their advantages and disadvantages and what they get of it (e.g. more productivity per $ as 10 licenses cost like 9 licenses of the other product ...). Good luck with argumentation! Regards Philippe Mark Armstrong schrieb:
Hi Crispin,
All your points are very true, unfortunately I'm looking to put a server into an environment where risk assessment and use of certified products makes the bureaucracy happy. It is currently an area dominated by certified versions of Solaris, Windows and RHES that were thought to be the only certified OS flavours available. Having used SUSE for over 8 years I'd be a lot more comfortable with SLES doing the work for me.
As for the strictness and hardware aspect, I'd be surprised if the RHES machines operating in the target environment are on the hardware they were certified for. This is a loophole in the beauracracy that I might be able to exploit. My problem is that I could argue until I was blue in the face the advantages of using the latest version of SUSE10 from a security perspective, then be told I can NOT connect the machine to their network. (This network will never be connected to the internet so live updates are a none starter)
But say this EAL3 product fills the gap in my risk assessment to CYA and off I go.
Also as a man who does not have the time to be a good system administrator, a good script from a reputable supplier that adds the features I need will make me a happy camper.
Mark
Crispin Cowan wrote:
Mark Armstrong wrote:
I recently discovered that there are security hardened version of SUSE that are certified/accredited to EAL 3 and even EAL 4.
Does anyone have any experienced feedback on how restrictive these setups are?
We are looking to implement a data retreival system that access disks over NFS and tape drives over SCSI, but does little else. Would like to know if I could still do these simple things.
What is it you are trying to achieve? Security, or compliance?
The SLES9 EAL3 and EAL4+ configurations are exceedingly strict; to be in compliance, you have to have the exact software and hardware configuration specified.
However, it is not a particularly secure configuration. Because it specifies an exact configuration, and it is now quite old (early 2004) many advances are technically not permitted in a compliant configuration.
To achieve a high level of server security, you should, first of all, keep it up to date by running the update tools frequently.
The second thing to do is to close all unnecessary network ports. There are several tools for that, including netstat (which lists the open ports) and Nessus (which does a detailed vulnerability assessment of the applications you are hosting).
You should also use the AppArmor tools to secure your applications. AppArmor also has a tool to scan your server for open network ports called aa-unconfined. This program lists open network ports, the programs listening to those ports, and the AppArmor profiles wrapped around those programs, if any.
Your goal here is to use AppArmor to confine all of the programs with open network ports. If you do that, then all network attackers are forced to go through your AppArmor policies. This does not perfectly prevent all intrusions (no policy mechanism can) but it does strictly bound what damage the attacker can do.
All of these steps (updates, netstat, Nessus, and AppArmor) will do lots to help your security, but nothing to help your compliance with regulations. The EAL certified configurations are rather the converse; it does little to help your security, other than by providing a lower bound that your security isn't absolutely horrid, but does a lot to provide CYA (Cover Your Assets :-) by being compliant.
Crispin
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQD1AwUBRk2RL0Ng1DRVIGjBAQLJSAb/Unw7l9tiPgKj2OKCiKEAHRISwK4UHPSP 6KUQHUDVlKBFTTxSXNhngxYZXGVchJCS41hkl1TZmlWy+5oN1sh4IUCFDbiBnFYV uwNjdGhjjhqpZf2LdWm1qAt7yqs666Ego8czbOJ/ys2PBBp/BZBNhAj3XdLKy4Ng gLmbh4hfzV2QAK3c4iROhtwaeyhV9FiqetUCWarO1AwG0eI9nQyUeBcjW5X4tB/q 8xx04lTyc2NpY7cQ37bA0wso8S2agRT0mFPlu6BsqMF+V0UToUp23YYTzps7kwJD CAvRRx5+FcQ= =MPdq -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org