2

I hear a lot of best practices saying that you should have 2 vSphere server stacks:

One for Production
One for Cybersecurity

For example, your enterprise might have a vSphere environment stack that has all your core services (Exchange, DCs, Sharepoint, etc...) run by your system administrators and your Cybersecurity vSphere server stack would have all your security servers that host the security tools (IDS/IPS, Antivirus, vulnerability scanner, etc.), which would be ran by your dedicated cybersecurity team

Are there any good framework references or security controls that mention why one should build the separated security vSphere environment? NIST, COBIT, ITIL, SANS documentation, or anything? I am having problems finding references of why my organization should do this.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Ninjaneer
  • 21
  • 3
  • 2
    Define "server stack". If you mean, "should security services not be run on servers that provide production services", then yes. If that is what you mean, then the ideas you are looking for is "separation of duties" and "least privileged access". There should be no need for an application admin to also have admin access to security services. – schroeder Apr 14 '16 at 15:26
  • @schroeder Yes your correct. I am looking at I would have virtual servers in their own virtual environment. separate from the production environment that only the security administrators can access and control 2 vSphere environments - one would be all the production servers and the second environment would be all the security servers I just hear all the time its best practice but having problems on paper connecting the dots of justification. I will look more into what your saying on "separation of duties" and "least privileged access" – Ninjaneer Apr 14 '16 at 15:44

2 Answers2

1

I think you could just use the security concept of least privilege to drive these concepts. For example, I would imagine you would not want your Sharepoint admins to have access to the DC's running on the same box. The other design problem for combining multiple services on a single host is if say an Exchange exploit takes the host down then you lose all of the other services that you have on that host as well.

Justin Andrusk
  • 305
  • 1
  • 6
  • In vmware, there are controls to limit a users access to only certain guests. Thus both guests could reside on the same host without allowing everyone access. – user2320464 Apr 15 '16 at 01:55
  • If your system administrators control the vSphere, they can add himself to any guest they want – Ninjaneer Apr 15 '16 at 10:06
  • @Ninjaneer, that is why *Insider Threat* is such a concern. Before going down that rabbit hole, leverage existing controls to mitigate this possibility. – user2320464 Apr 15 '16 at 19:32
0

Typically services are co-hosted based on levels of trust. Using the military as an example, this would be like hosting all "classified" services in the same environment and "top secret" services in a separate environment. If there's a vulnerable service in one area then only that area is immediately impacted. The idea is to mitigate vertical agility during post exploitation (i.e. prevent escalating trust levels).

Sometimes security services are carved off into their own environment so they're completely independent. That way, if there's a compromised or a serious mis-configuration then the security services will not be impacted. One can argue that security services should have a different trust level when compared to the rest of the environment.

All of this said, one must design these trust levels while maintaining a reasonable budget and having the company accept a certain level of risk. Suppose your company can only afford to have two hosting environments. This business decision now requires all services be categorized into one of two risk levels. This can be a difficult conversation so be sure all parties are fully informed.

Since you asked for documentation, here's an excerpt from NIST 800-125 Guide to Security for Full Virtualization Technologies

It is particularly risky to place multiple services on a host if they have significantly different security needs. For example, suppose that one service is considered critical and is secured very strongly, while another service on the same host is considered low-impact and is secured relatively weakly. An attacker wanting to compromise the critical service could compromise the low-impact service and use the fact that it is local on the virtual network to attempt to access the critical service or to compromise the hypervisor and thus gain access to the critical service. Organizations that have policies relating to allocation of computer resources should consider virtualization in such policies.

user2320464
  • 1,802
  • 1
  • 15
  • 18