On Mon, Apr 6, 2009 at 11:53 AM, Larry Ludwig <la...@reductivelabs.com> wrote: > > Hi Alessandro, great start! > > I personally would make these changes to your modules.
Well the two things I missed were: A documentation outlining all the steps being done, and that this is more of a hardening document. It can't bring a system to EAL3/4/x because the hardware and other parts need to be evaluated in toto by some 'authority'. If the Dell Optiplex 360 is the evaluated model and I use the same configurations on an IBM Xserver... the system is not EAL4. The hardware would require evaluation and the software interfacing with it would require stuff. I don't want to come across as a nitpicker, but the difference is important for people who really need EAL-X. A common problem I have seen is that someone will find something listed as EAL4 and then finding out when the auditors show up they didn't have what they expected. I don't know the best solution to this, but labeling things as hardening guidelines to help meet CAPP is probably better (and then a pointer to the document that showed what that meant and what a person would need to do to know if they comply with CAPP/LSPP/WXYZ/etc. > - The hardening module I would break out each of these services into > separate modules, so it's more generic. The hardening class itself I > would consider a 'role' that would then include all of these modules > (I have roles exist in the manifest folder and called by site.pp) > - your logindefs class I would consider part of a shadow module that > then has your specific security policy > - your modules are very centos/RH specific any plans on making them > apply to other OSes? > - If you are removing packages I would suggest by default installing > the package and then creating an ::absent class to remove or > a ::disable to stop the service but have the module installed. This > also then allows for keeping the package current via that module. Ah so thats the best practice for that. > I'm not really familiar with EAL4+ CAPP can you tell me more about > this? How is something certified EAL4+ CAPP, and can something be > certified? CAPP is outlined here http://www.niap-ccevs.org/cc-scheme/pp/PP_OS_CA_V1.D.cfm The saying is that CAPP is the new C2 (Orange book) from the old DoD security guidelines. In reality CAPP is a basic set of configurations that can be evaluated (eg checkmarked against a known checklist). The other common ones people use are LSPP and RBAC which are also at the CC scheme page. My favorite quote about CAPP is: The CAPP provides for a level of protection, which is appropriate for an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The profile is not intended to be applicable to circumstances in which protection is required against determined attempts by hostile and well-funded attackers to breach system security. The CAPP does not fully address the threats posed by malicious system development or administrative personnel. CAPP-conformant products are suitable for use in both commercial and government environments. Which can be interpreted as don't put this box on the internet... but really means that the various evaluations were meant for a physically controlled network and may not work in other items. From the newer niap listings, I would expect that they would consider this 'Basic Robustness'. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
