Cloud Security - The New Challenge
Many clients use a combination of traditional perimeter security technologies like Firewalls and default public cloud security settings like ACL’s when designing and deploying applications. The focus is normally on public-facing web assets. This increasing sophistication of attacks means that these methods are no longer effective, and a new approach is required. The sheer scale IPv6 makes blacklisting of IP’s totally ineffective.
Problems with the Current Approach
The issue with the default Public Cloud settings is that they have no egress control, and this allows attacks to progress to next stages. Our security posture needs to support both outbound and inbound traffic. It is common for inbound traffic to be protected, but the challenge for an attacker is once they are in your environment how do they get out.
Usually people use virtual versions of their on-premises Firewalls and network security tools like ACL’s (Access Control Lists) with monitoring, however monitoring is not enough, as once they are in its hard to find and get them out. It's too late when they are already in your network, we need to protect proactively.
The "Edward Snowden" Challenge
In the past we used UTM gateways for Layer 1 to Layer 7 DPI (Deep Packet Inspection). After the Edward Snowden and WikiLeaks events, we transitioned to encryption to secure all transit traffic so security agencies couldn't see our traffic.
This created the "going dark" problem, where our traffic is so encrypted, we can't look at it and the UTM can't prevent it at the border.
DNS Comes to the Rescue
The silver lining is that we can use DNS to solve this challenge, as it is still visible. We can look at the destination Domain and determine if it is trustworthy. You can use DNS to check IPv4 and IPv6 address validity. There are new trends of DNS over HTTPS and TLS with encryption. These can allow the bad guys to hide as well and can't be blocked in the cloud. So, we must strive for a balance between privacy and visibility for security.
“Deny all” and Whitelisting is the Solution
The best way to address this is at source endpoint of the traffic before it's encrypted. Which is where Whitelisting tools are so useful. Start with “deny all” as the default and then add to cloud instance what services we will allow.
A cloud application normally interfaces with 5-10 -15 services. What we do is create a whitelist of very single destination domain that the application does need access to plus "deny all" for everything else.
This means that new threats don't affect you. An attacker may still get in but can't get out.
Your tool still needs the ability to add new domains as required, so you can see if the application makes changes by having “deny all” makes it easy to identify issues.
In summary: Old approaches aren’t as effective anymore, start with “Deny All” and whitelist only required services.
Look at whitelisting tools like Airlock and Applocker from Microsoft.