Thanks - I've used the hardening guide before, but it, like most resources hasn't really given me what I need. It gives you recommended settings for VMs, hosts, etc, but not really design principles. Take a compliance example, for HIPAA, when do I need to separate Vms into a different cluster? Once I separate them, what other components of the inrastructure can I share (storage array, UCS chassis, physical switches) and what need to be airgapped and why? If I share certain parts of the infrastructure between my HIPAA scope and what is outside of scope, what controls need to be in place to demonstrate compliance and maintain scope definition? If I define PCI compliance zones virtually instead of physically with some kind of reference architecture and use Hytrust and other tools to help me, who has done this kind of thing for a VCDX design?
Suppose I'm not doing compliance in my VCDX design but I have security related design questions - maybe I have a DMZ. Should I put my DMZ between two physical firewalls or create it virtually with VCNS and VMware tools? How does the DMZ requirement map onto virtual networking / distributed switch design? Who has created books, blogs, etc. that look at security related design decisions related to VCDX type prepration?
1 person found this helpful
Those are the questions you have to argue during your design. There is no easy answer to this, it depends on actual demand and customer requirements.
Simple example I had in a customer design discussion:
CSO: argues with me that he wants airgap for the physical hosts and switches.
ME: So you want to share vCenter, Storage and maybe firewalls between segments.
CSO: Yes, that's his idea.
ME: Okay what are you trying to achieve? What's the enemy you try to fight?
CSO: If someone get's from a VM into the hypervisor he can gain access to all hosts.
ME: Okay you say someone is clever enough to get from a VM into the hypervisor in your highly protected environment. And the same guy is not clever enough to get from there into your storage, vCenter or the communication between vSphere Client and host?
CSO: What do you mean?
ME: The airgap attempt will only fight one very specific attack pattern, without FULL isolation: Host, Switches, Network, vCenter, Storage and maybe even admin workstation. There is not that much of additional security. As long as we harden the hosts.
CSO: What else could we do?
ME: Implement (back then) vShield on multiple layers, introduce strong IDS, harden hosts and VMs. Ensure admin teams are trained etc.
This would go on much longer. So in the end we could get rid of airgap, because it was accepted, we had a risk mitigation while also adding actually more security on all layers.
There is like in many other areas no simple: This is the solution. Especially in security a lot is to really understand what they really try to achieve.
But that's only my two cents...
Really great input - thanks. I think that when you have these conversations all the time with executives, perhaps it triggers all the things you need to think through and be ready to design for. What I'm looking for are resources where not having had all these conversations, to get the raw information to learn from.
When we understand that there are dependencies and variables, we say "it depends" - but that means we understand what the potential dependencies are and know what the possible variables are. We don't know the values of the variables or the results of exploring the depencies, but we have background knowledge about the process needed to get started sufficient to start the problem solving process. Thanks Yves for sharing some of that kind of knowledge and process in this scenario.
But I think we all arrive at the ability to work that kind of process by learning, and we use resources, both on-the job experience and reading, seminars, training, conferences and the like. For those of us who have less on-the-job opportunities for learning, we have more control over the kind of learning that comes from books, blogs, conferences and like resources. So I'm looking for this kind of thing, and don't really see much for this subject. Someone who wrote a book taking Yves type of scenario and continued talking on experiences like this for a few hundred pages, covering as many of them and how the process and dependencies and variables were worked through, so that your preparation for VCDX has those processes well learned.
Have you looked out at the info in the solutions exchange around PCI and HIPPA? They have generalized approach to compliance, and then reference architectures around PCI and HIPAA. Alan Shortnacy developed a lot of this content before taking a more cloud focused role, if you look up his sessions at VMworld 2013 and 2014 there is a lot of good info. He did a 3 part PCI compliance sessions with coal fire that is really good.
1 person found this helpful
I would take the CISSP approach to Design Security.
Think about the security from physical to software, both insider and outside threats, think about what is high risk and low risk... how do you mitigate that risk and vulnerability. Also you must meet any requirements/constraints that the customer has around security (PCI, HIPAA, DoD STIGs, etc...)
thanks again for the input. Any other input welcome
1 person found this helpful
I will be defending my design this October and we went through a similar situation while creating the design. It came down to a conversation with the customer. In the end we had a few points that allowed us to shape the desig
Is PCI, HIPPA, ISO XXXX or any other security standard required?: No
Do you require any segmentation between Networks: Yes the DMZ needs to be separated
Does this need to be a physical separation, virtual separation, both, or can a collapsed infrastructure work?: Long story short, after a long conversation they went with a collapsed infrastructure with a mix of physical separation and virtual separation.
How much hardening do you require for each environment?: This is sometimes a tricky balance to find as to much hardening makes the admins job a nightmare, to little leaves holes open. Long story short after a conversation with the customers key stake holders and SME's they came up with a nice mix out of the hardening guide for production that still allowed for ease of administration while locking down the standard threats etc. While the DMZ was locked up pretty tight and the admin's will just have to deal with the work around's when having to administrator it.
Now of course there MANY more tables of security settings that went in blah blah blah, but when it comes down to it the security section is going to be mostly logical with lots of details in tables. On top of that you will need to be able to defend each answer for the design. For instance:
Why no PCI, HIPPA, ISO Standards? What if the customer wants this in the future:
Answer: After discussing this with the customer and with the current constraints / requirements laid out the customer decided it would be more benificial to use a cloud provider for any PCI requirements or stand up another environment to lower the overall PCI compliance check within the environment. Also no currently standing requirements for PCI compliance in the infrastructure the design revolves around.
Why a collapsed DMZ design over a FULLY segmented design: Due to the manufacture and solution selected the required segmentation laid out in the requirements can be met with the collapsed DMZ and virtual segmentation while not having to purchase any further equipment which assistance with the budget constraint (C03).
Why did you not lock down production as tight ad DMZ: The customer has some requirements around SLA's within the datacenter and having the additional security settings would effect the SLA's agreed upon by the customer. The customer found a happy medium to still leave the environment in a secure state which would not effect deployment times, troubleshooting, or their current SLA's
Anyhow you get the idea. Pretty much anything you put in your design can be okay as long as you can defend it. Sometimes constraints or requirements will force you into situations that isn't necessarily the "best practice" but it had to be done to meet the customers needs, wants, and requirements. As long as the solution isn't straight up bat crap crazy you should be okay if you have a rational reason to defend it with.
We have a VCDX group currently setup in Google+ for people who are writing there VCDX to help each out. Check it out, we are in the 2015 one.
Hope this has helped
Great input and considerations - definitely helpful - thanks!