VMware Cloud Community
michael_40catbi
Enthusiast
Enthusiast

Resources for building a secure image library

Hello All,

Between NIST, CIS, NSA, DISA, and others we have plenty of resources for hardening guides.

I am looking for resource(s) of pre-built OVF (or other) images of systems that have already been hardened to a particular specification.

TIA

0 Kudos
10 Replies
michael_40catbi
Enthusiast
Enthusiast

Here's a site that has a few in vhd format: http://usgcb.nist.gov/

0 Kudos
Texiwill
Leadership
Leadership

Hello,

I would assume the issue would be the format of the images as well as the content. Not everyone uses ESX formats, or OVF. Not only that how would you handle the case of the difference between applications installed within one VM and not inside another?

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
michael_40catbi
Enthusiast
Enthusiast

Hello Ed,

The configuration standards may require specific versions of the OS and Applications.

An area of difficulty is that the configuration requirements may sometimes be inconsistent with the current software version.

For example, this is a problem with the DoD STIG for ESX, based on version 3, and folks who are required to apply it to ESX 4.

The virtual machine formats seem to be a lessor issue because of the availability of converters between formats.

Ideally, the community would standardize on OVF for the library and then the platform vendors would supply the required conversion tools.

v/r,

Michael

0 Kudos
Texiwill
Leadership
Leadership

Hello Michael,

Ideally I agree with you, but the industry has NOT standardized on OVF, and I just do not see that happening anytime soon. Nor does OVF currently store much in the way of security context, and that has been in the works now for several years. It is almost as if OVF has stalled.

As for ESX, the DISA STIG for v4 I believe will be based on the VMware hardening guide, but that process also looks like it stalled.

But given the myriad of little things that can be installed within any OS, how can we create such a library without having a HUGE set of images, probably in the 10s of millions just for Linux systems not to mention Windows systems which we cannot store anywhere due to licensing issues....

This could get too large to manage very quickly....

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
DSTAVERT
Immortal
Immortal

Rather than hardened images -- which still tend to be rather general purpose -- I would much rather see a build process that created highly specific images. I don't mean compile from source but to draw from controlled signatured binary repository. The idea being not to have a JEOS like approach (still a slimmed down general purpose) but an Almost Not Enough or in my mind barely enough to keep the application from hitting the pavement. Somewhat like a hypervisor for applications. Reducing the footprint as has been demonstrated by ESXi, removing local access, a secure channel for managing and monitoring and communicating between applications.

-- David -- VMware Communities Moderator
0 Kudos
Texiwill
Leadership
Leadership

Hello,

I keep reading about ESXi being more secure than ESX and I gasp everytime I read it. It is not more secure, it actually requires more security than ESX currently. One can hope this will change. Reducing the Management console footprint does not actually reduce its Network footprint, nor does it reduce the hypervisor footprint.... This is an old argument and my preso at RSA 2010 demonstrated this. Security is not much different except I have to do 'defense-in-depth' security for ESXi quite a bit differently not better, but differently. Patching is different, not necessarily better as well.

However, a library of 'scripts' to perform hardening would certainly be useful but a generic repository of binaries does exist, you want to look at SignaCert and a few others.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
DSTAVERT
Immortal
Immortal

I wan't pointing to ESXi as being more secure but simply a smaller more specific OS. I wouldn't consider running ESXi without firewalling the management network and VPN only access.

My thoughts

You mention scripts to perform hardening and I am suggesting that if the OS is built with just the modules required to run the application there is far less hardening to script for. Today if I have an Apache server and it requires Perl, I install Apache from some package and Perl from some package and they make use of the preinstalled C libraries and bring in other dependency packages and other dependencies of dependencies.

I would love to see this reduced to perhaps a statically compiled Apache, the statically compiled Perl executable and the three modules required by my application. Another approach might be using something akin to LDD which would run through the execution of my application and copy in just the specific C modules required for my application. Eliminate local access and there would be no need for all of the generic unix apps that one could use for a local attack.

The OS doesn't need any more than what is required to launch my application, and perform normal disk and file operations. Linux running on ESX(i) does not need every hardware driver module known    to man. It can be precompiled with all the VMware specific hardware   into a signatured binary.

I realize this is too simple an example and certainly requires much more to make it viable but just my thoughts. VMware understands how to provide Virtual machine access to resources. Perhaps if the OS layer were reduced to little more than a shim we could get to application vMotion. ???

-- David -- VMware Communities Moderator
0 Kudos
Texiwill
Leadership
Leadership

Hello,

Unfortunately defense in depth for JeOS is much different than defense in depth for Apache, once you put users on a system, you are now in a completely different realm. Must defense in depth within the Guest OS is tied to Application Security and User Security. Which means your JeOS needs to include things like syslog, PAM, and all the sundry tools that make PAM work. That becomes the issue. FOr example, if you are required to have 3 failures only on a password there is a PAM module for that but you need 'faillog' to make it work which is another package.

Eventually you just keep adding more and more packages to achieve the desired controls.

Apache without the necessary underlying security is just not enough and generally where there is Apache there is MySQL which requires its own hardening, which most likely implies the need for iptables, etc.

Yes the 'OS Layer' can be thin, but not that thin....

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos
DSTAVERT
Immortal
Immortal

I am not disputing the need for DID, just that I think we need a need a different approach providing OS services to applications. Obviously my example lacked anything realistic and yes logging needs attention and and . .  The more un necessary stuff within an image or package means more to be accounted for. I am appalled at how often we still see updates to fix buffer overflows.

I would suggest that the complexity is mostly our enemy when it comes to security. We keep adding new layers rather than fixing the existing ones. As complexity increases, our comprehention decreases and so we add a new management tool to look after it. And the cycle begins again. I think the complexity has made it far more difficult for us to comprehend our own processes to the point that it may become easire to breach. OK I suppose if your job is selling security tools.

I just think we need to start looking at how we supply application services and the OSs they sit on. We are using the same approach we have for a long long time and I am not sure it serves us well today.

-- David -- VMware Communities Moderator
0 Kudos
Texiwill
Leadership
Leadership

Hello,

The unfortunate truth of the matter is that we can concentrate on the Application as much as we want, but eventually from a security perspective we need to also understand the OS. There are no 'Applications' without an OS at the moment, no matter how much marketing would like to say otherwise. JeOS is just that an OS.

A hardened JeOS done by one organization will NOT meet the requirements of another and another, etc. If we harden to DISA for example, we miss quite a bit that Bastille does or even CIS specifies. There are also collisions on some of the hardening guides, etc. Then we have auditing, continual monitoring, etc. to put on which require their own hardening, etc. Eventually we make it to the application.

Now if the VM Object provided a 'kernel' per say, then we would not need a Guest OS but just the VM Object Container and the applications that run on top of it... Not sure how to do users yet, but that would be part of the application perhaps? I think this is where we are headed... but at the moment we still have an OS....

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
0 Kudos