Cloud Security Blog

This one goes out to all the auditors out there. ;-)

 

In the course of getting audited, one of the stumbling blocks I've run into is helping folks wrap their brain around how security works within a public IaaS cloud. One of the particular sticky points is what the word "internal" means in the context of an auditing standard. For example PCI DSS v2, control 11.2 reads:

"Run internal and external network vulnerability scans at least quarterly and after any significant change in the network..."

In a Gen2 environment, as shown in Figure 1, this control makes perfect sense. The concept is that Gen2 networks are designed around the premise "We trust ourselves more than the outside world, so a larger amount of uncontrolled access is permitted from the internal network". So the "internal" network probably has access to ports and services on each of the DMZs that the Internet at large does not have. This is the classic "crunchy on the outside but soft in the middle" problem. This is also why most standards will want to see a review from internal as well as external, as a compromised internal machine can wreak far more havoc than a random IP out on the Internet.

In Gen3 however, this design looks a bit different. Refer to Figure 2 for the equivalent design deployed in a public IaaS cloud.

Note that we now have a logically flat network, as we are no longer grouping systems by subnet. On the down side, this negates the effectiveness of perimeter firewalls. On the plus side, we don't have an inherit trust between systems grouped on the same subnet. On the outermost DMZ in Figure 1, we showed two load balancers. In reality there are probably many other systems on that subnet including a marketing Web server, DNS, mail relay, etc. Because of the inherit trust in a Gen2 design, whacking any one of those systems will most likely provides a greater level of access to all other systems on the same subnet. So if the marketing folks don't implement security correctly, the road to compromising the mail server, the load balancers, etc. just became easier.

In Figure 2, we recognize that the network as flat, and thus there is no inherit trust between systems. Whacking any one system does not provide uncontrolled access to all others.

For the Gen2 folks I know what you are thinking; "How the heck am I suppose to implement that securely?". Read on Grasshopper...

As I've mentioned in earlier blog posts, public cloud security is more akin to laptop security than data center servers. We recognize the server will be running on an untrusted network, so we focus our security controls on each individual server. We leverage configuration tools such as RightScale, Chef and Puppet, or even security tools such as Halo and Dome9, to implement a host based firewall on each server that restricts access to only what is needed. So in Figure 2 the Web app servers have a firewall policy that only lets it receive HTTPS connections from the load balancers, and only supports outbound secure SQL to the databases. This locks down the network layer to only what is needed to perform the server's dedicated task. So while on the Gen2 network whacking the marketing Web server could provide additional access to all other systems on that subnet, in the Gen3 model this is no longer the case as the marketing Web site, DNS, mail relay, etc. have the same level of access (perhaps even less) than the rest of the Internet.

If you need to manage these servers, you can leverage security tools such as Halo GhostPorts or Dome9 Secure Access Leasing. These tools permit you to leave administrative ports closed to the outside world, except to specific IP addresses that pass an additional layer of authentication. For example in Figure 1 the entire internal network most likely has access to the SSH port on all of the DMZ servers. In Figure 2 you could restrict network layer access to only those IP addresses that pass two factor authentication. So our posture is "trust no one until they give us a reason to trust them", and even then they still have to properly authenticate to SSH through some other means.

So to circle back to the beginning of this blog post, where is the "internal" network in Figure 2? We have no soft squishy inside that gains a higher level of access than the rest of the Internet. If the site is not authenticating administrative IPs, then "internal" and "external" networks are effectively the same. If Admin IPs are being authenticated prior to access, then "internal" becomes that authenticated access. For example if I'm auditing a site that is using Halo GhostPorts to control administrative access, I need to be sure that scans are being performed from IP addresses that are first authenticated through this system.

One final comment, note that all the tools I mentioned are cloud provider agnostic. This means the techniques covered will work with any IaaS CSP.

Questions, comments, clarifications? Drop a comment below.

--Chris Brenton