Application Security – A Shared Responsibility in the Cloud?
Back in 2010, when the cloud was young and security a top concern, security practitioner Chris Hoff made a statement that should be known more widely as Hoff’s Law. That statement was typically Hoff – straightforward and unashamedly honest: “If your security sucks now, you’ll be pleasantly surprised by the lack of change when you move to cloud.”
Eight years later, that statement is still true – particularly when it’s applied to applications.
Since the very beginning, cloud providers have made no secret that security in the cloud is a shared responsibility. The provider agrees to deploy tools and enforce policies across the network, infrastructure, and host systems of their environments. But they place the responsibility for securing applications – from the platform to the protocols to the actual code – on the individual or organization that owns it.
That’s only logical. The cloud provider has intimate knowledge of the systems it deploys and manages, but not yours. The converse is true – you have intimate knowledge of the application stack you deploy and manage, but not necessarily systems that belong to the cloud provider.
In recent years, cloud providers have delivered application services designed to provide the protections necessary for customers to execute on that responsibility. Application services such as web application and network firewalls are common offerings in cloud marketplaces today. Providers of security-related application services have stepped up, as well, to ensure availability in every major cloud provider. Access control, identity federation, single-sign on, web application firewalls, bot prevention, and DDoS protection are available in every cloud environment – on-premises and off.
But like a lock on your door, unless these application services are actually used (deployed and active), they can't defend and protect your application against the onslaught of attacks that occur on any given day.
When you deploy an app in a public cloud, there are three key defenses you should be deploying:
1) Bot protection: Defending against the more than 50% of requests generated by “bad bots” today is not only good security, it’s a wise business decision. Bad bots conduct probes for vulnerabilities, execute DoS attacks, and otherwise perform actions that are not beneficial to the business. When bot traffic is allowed to connect with your application, that’s money being burned. Every cycle a bot consumes is a cycle you paid for that customers can’t use. If your application requires more than one instance to maintain availability and acceptable performance, consider it’s more than likely that you’re paying twice as much as you need to. Bot defense not only proactively deters exploits and prevents denial of service attempts but saves operational costs in the long term.
Attackers are well aware that they’re being watched, so carefully consider your bot protection services and ensure they’re not just simple signature or reputation-based solutions. Bot protection capable of fingerprinting and identifying bots based on behavior as well as traditional identifying characteristics.
2) Account Takeovers: A significant number of organizations deploy consumer-facing applications to the cloud. Ease of access is a typical driver. Sadly, if it's easy for the consumer, it's also easy for an attacker. The data that app is guarding is valuable, and attackers can – and do – attempt to gain access on a fairly regular basis. Armed with databases full of exfiltrated credentials, attackers will try to force their way in by stuffing usernames and passwords into logins until one of them invariably works. Protecting against this common attack requires some smarts and ability to recognize evasion techniques that avoid captchas and other protections built into applications.
3) App-Layer DDoS: Stymied by the mature protections at the network layer against volumetric DDoS attacks, bad actors have moved up the stack and are now aiming at the softer target that is the application. Security provider CloudFlare noted that the rate of application layer attackers had risen from 160 per day in 2016 to over 1000 per day in 2017. App-layer DDoS is particularly frustrating because many attacks appear to be legitimate requests and they easily evade signature-based solutions.
Behavioral analysis in conjunction with fingerprinting techniques is quickly becoming the best defense against these nefarious attacks.
Additionally, the risk of open management and admin consoles cannot be understated when operating in the cloud. The number of wide-open consoles for Kubernetes, for example, grows with each security report that is published. This lack of attention to the security of operational consoles is concerning, especially given the current immature state of intra-container security for container-based applications. Lock all your doors and ensure you aren’t offering free compute and access to your applications through the back door.
Security in the cloud is a shared responsibility. It’s perhaps a sad commentary on the state of the Internet that the bulk of attacks are moving up the stack and thus forcing a greater burden on app owners to pay attention to security.
Then again, perhaps they’re moving up the stack specifically because app owners aren’t paying attention to their share of security in the cloud.
Recommended For You
DNSSEC authentication helps to ensure that a compromised DNS server won't send you to a hijacked server when you point a browser to a specific domain name.
In a world where numerous types of attacks pose as a serious threat to your PC or mobile device, it has always been known that ransomware is among the deadliest.
As with most fledging technologies, containers are constantly plagued by concerns over security.
All good things eventually come to an end. When is it time to create an entirely new network security strategy rather than updating an old one?
Here are six threats that every Wi-Fi system should be able to protect against.
Many companies, as well as 44% of the top SaaS providers, don’t have a fallback DNS option. A single outage could completely take their businesses offline.