Improving Operational Security in the Cloud

If you want to keep the costs of operating in the cloud down, take a look at your security practices on the management side of operations.

Most of the attention on security these days goes to application protocols and vulnerabilities in the application stack itself. That's no surprise given that the majority of breaches occur because vulnerabilities in common platforms and frameworks offer a rich set of easy targets.

But let's not ignore the increasingly accessible management side of the business. As we've moved apps out into the public cloud, we've often lost focus on the importance of isolating management traffic from easy access. On-premises, this was easy. The management network was inaccessible to the public. We kept them locked down on a non-routable network that was only accessible inside. As we've migrated both apps and their application services infrastructure to the cloud, we need publicly accessible management because operators are now remote.

While we've made the transition away from Telnet (except all those IoT devices that need to catch up) to SSH and even practice good password generation behaviors, we haven't necessarily looked at how to better leverage cloud-native security along with our own practices.

It is the use of cloud-provider security services that can dramatically impact the operational costs of doing business in the cloud - especially when it comes to managing application services infrastructure.

The Threat is Real

If you haven't had a chance to read F5 Labs' article on the top attacked usernames and passwords you should. In it, you'd learn that SSH is a highly targeted service. More so than any other it turns out.

From the article:

By attack volume, attackers focus more time and effort attacking SSH than any other online service. Brute forcing access to administrative logins of production applications over SSH occurs 2.7 times more than attacks against the application itself over HTTP (attackers trying to exploit web application vulnerabilities).

And why not? Administrative control over application services infrastructure gives you a lot of power - including the ability to modify policies that might otherwise prevent easy access to web applications. In the case of Kubernetes - often targeted due to failure to require any credentials - access is desired in order to farm resources on someone else's dime.

But you're security savvy, and you require strong passwords for all access to infrastructure. Your SSH password is so strong you have to stop and think about what it is to enter it. Every time.

Now for the obvious statement of the century: strong passwords do not prevent attacks. They only mitigate successful attacks. You can't stop someone from launching an attack. You really can't. You can only detect and prevent it from being successful.

But in the meantime, that attack has real operational costs associated with it. Because you practice smart security and all those failed attempts are logged. Every. Single. One.

And for every failed attempt you block, you're consuming resources. Bandwidth. Storage. Compute.  

Use Cloud Native Services to Augment Security Practices

All major cloud providers (and probably the minor ones, too) provide basic network security controls that can be used to lock down management access to application services infrastructure. AWS security groups (SGs) and Azure Network Security Groups (NSG) work much the same was a firewall - they filter traffic coming into (and out of) an instance. In the case of management access this can be a significant tool in your security tool chest. By locking down access to only known IP addresses (or specified ranges) you can dramatically reduce attack volume that reaches your infrastructure. This can keep costs down by preventing excessive consumption of compute, bandwidth, and storage.

This is the same principle that encourages the use of web application firewalls in the cloud as both protection for apps and best operational practices. The intent is to stop the attack before it can consume excessive amounts of resources.  Even if that attack would have failed, the fact is that the attempts are likely enough to force auto-scaling events that cost the business money or disrupt availability for legitimate users. Neither is a desirable outcome.

As a general rule, the closer to the source of the attack you can stop it, the safer you'll be and the less cost there will be to the business.

Augment. Don't Substitute.

The key to using cloud-native services in your security practice is "augment." The use of strong SSH passwords is good. Combining it with strong access control is better. But never, ever abandon strong password practices in favor of security groups alone. Use both together to ensure security and constrain the cost of doing business in the cloud.