The Sky Is Falling! No Wait, That’s Just Our Data in the Cloud!

Back in the good old days, we used to have to order physical servers to run our applications. When servers became too expensive, we found efficiency in virtualization. Why have one box running one server when I could have 10 or more on a single box? Who would have thought I could simply push a button and have a server ready in minutes as opposed to weeks? Well, guess what? It now takes weeks to get a virtual server. Who has time for that? As the information age has evolved, agile development teams can’t wait weeks for a server let alone a virtual server. When peak business times hit and an increase in load is needed, there has to be a better way! Lo and behold, someone started deploying servers in the cloud. Why should we wait to deploy our own servers when we can simply use a public cloud service? It’s brilliant! There’s no need to go through all the company red tape; it’s so cheap that I can even bill it on my credit card if I have to. Well, as security professionals, our goal is to protect the organization. So, how can we protect the enterprise from the additional risk introduced by these developers? We have regulators to answer to, and we have a security posture to maintain to protect our customers. Developers? They don’t necessarily care about us. Their goal is to make a product their customers (and actually our customers, as well) like and will use in the quickest amount of time possible. And they’ll be damned if security gets in their way. So as security professionals, how can we still maintain the security posture of these cloud assets without slowing down the agility of the business? The dynamic is different in the cloud, but the foundational security principles remain the same. If we take a look at the Critical Security Controls from the Center for Internet Security, we see that these same controls apply to cloud security as well as on-premise security. The key, however, is that we need to understand the differences between cloud development and traditional on-premise development. So, let’s examine the first five of these controls:

Control 1 / Control 2 – Inventory of all Hardware and Software Assets

This is actually easier in the cloud than it is on-premise. There is no need to run discovery scans on the network. Simply match up the host lists via the API against what you think you have and you’re done! This can be automated in a log collection tool so as soon as something does not line up, the team can be notified to act accordingly.  With cloud providers billing for the time. A server is live, this can save the organization a lot of money!

Control 3 – Continuous Vulnerability Assessment and Remediation

Traditional vulnerability assessment is done through scans. There are a few challenges here. These are as follows:

1. Amazon, Microsoft, Google don’t want their datacenters being scanned by every single one of their customers all the time. That’s way too much network traffic.
2. Cloud assets can sometimes only be up for a short period of time. If they miss the window, what do you do? How can an asset go by without being scanned?
3. When an asset is first provisioned, the vulnerability state needs to be checked prior to it being allowed on the network. If the cloud team has to wait for credentials and a scan to be provisioned, it can take too long.

Control 4 – Controlled Use of Administrative Privileges

The best approach is to adopt a Zero Trust model. Essentially, organizations refuse to trust anything inside or outside the network outright. Such a model places the onus on IT and security teams to verify everything that’s trying to connect, especially anything seeking administrative privileges. Once trust has been established, the organization can grant access.

Control 5 – Maintaining Secure Configurations

Every large organization is going to have a set of hardening standards, and it’s great that tools like Puppet and Chef can provision the systems with those hardening standards.  But who is verifying and auditing them? We trust, but we also need to verify. Any good auditor will tell you that there needs to be segregation of duties for this verification step. The other aspect to this is the nature of the development pipeline. Changes should only take place earlier on the pipeline and not on the production instance. If a change is detected on the production instance, it should be scrapped, and a new replacement system should come online.

Deploying Tripwire in a Zero-Trust Model

The above guidance should be considered from within a Zero Trust model, meaning that no user should be allowed to access those systems. The only account that should be making changes is the provisioning tool like Puppet or Chef. Additionally, organizations should consider automating many facets of their model in order to improve its efficacy. How can organizations meet these cloud security best practices? Fortunately, this is where Tripwire can help. Tripwire’s solutions can be deployed in a Zero Trust model and dynamically tell you how a system is configured, what the vulnerability risk is, and if something changed that shouldn’t have. All of this without manual user intervention! You might be wondering: what about if something changes in an S3 bucket or Azure Blob? It’s way too easy to accidentally change the permissions and not know it even happened, after all. These configurations need to be monitored. The beauty of Tripwire’s solutions is that as soon as a system comes online or goes away, the security posture gets verified. Information can be sent to multiple dashboards to which cloud teams are accustomed like Splunk and QRadar. Then when the system is torn down, it is automatically deprovisioned, with the data retained for audit purposes.  If a change happens while that system is in production, the security team and cloud teams can be notified right away. To wrap up, you need to remember two principles when looking for a cloud security solution:

1. Automation – Ensure that your security solutions can evolve with a move to the cloud. If your organization isn’t already doing something in the cloud, double check, because it probably is.
2. Vendor Consolidation – Some vendors handle cloud only, while some handle on-premise only. The key is going using a vendor that can handle both.

If you’d like to know more, see a demo, or get a trial, please feel free to reach out to your Tripwire account manager or hit the “Get a Demo” button on our website.