Einstein once said that “we can’t solve problems by using the same kind of thinking we used when we created them”. This quote works for many cases in life but it doesn’t really work if you want to solve the security threat behind cloud computing. So you have to think first of how would you attack what you have and use a reversal techniques to protect yourself.

So how the bad guys think? The criminals may be looking for a memory corruption bugs in the web server for instance, tries to figure out what IP addresses are used and looks for a service that is unpatched to break in. Once they break in to the web server, they can easily find their way to the Database and Application servers. Criminals can also send a file in a hope that someone could open this file, if this happens they can take-over the machine, establish interactive control, scan the network, escalate the user privilege in the active directory to become admin users, take over the machine and get the data they want. The question that asks itself here, how can they connect to the servers with all the firewalls and protection in place? They use Divert sockets to match traffic with the firewall rules and divert it into a piece of code, and then they look for SYN packets going to a server and alter the traffic using the generated code. They do the reverse coding on the remote site so that the hack is not captured by the security log files. Attacker also tries to create a huge amount of connections in the SYN received state until the backlog queue is overflowed so that the host kernel memory becomes exhausted. Moreover, the attacker can spoof their source IP addresses make it harder to trace the source of the attack. To add complexity, the attacker can use a distributed attack taking advantage of many drone machines in the internet. It is very important as well to know when you are under the attack, who is attacking you, what is the target and how can you stop it. Now we know the different ways of attacks, let’s design the best 5 lockers to close all the borders of our cloud architecture.

Lock#1 – Physical: Starting by the physical layer, there is a big demand in the market to use COTS hardware. From security perspective, although we are abstracting the software from the hardware, we do need to protect our hardware to better protect the software layers on top. The basic tip here, use built-in security in the infrastructure layer with hardware based root of trust and policy engines that checks hypervisor integrity and allow/deny work load migration from one host to another based on trust security profiles.

Lock#2 – Virtual Machines: On the virtualization layer, there are many cybersecurity attacks where malware creators inject viruses into the Virtual machines; these viruses are mainly written in open source programming language such as python and others. So if they manage to get into the VM, they can eavesdrop on all the traffic running within a specific tenant. VM environment is not static, VMs can be moved from one host to another, and when you move a VM from one host to another the network policies will go with them, so we need to protect the VMs during this transition. The virtual firewalls will prevent your virtual environment from external attacks but if the criminals manage to pass the Firewall, then the anti-malware Intrusion detection software should signal an alarm while the Intrusion prevention software should try to prevent or block it. From capacity dimensioning perspective, we don’t need anti-malware software and signature database on each VM as this will reduce the host performance and accordingly the number of VMs supported in a host.

Lock#3 – Hypervisor: In addition to tenant isolation where the hypervisor isolate guests so that each guest has only access to its own resources, we need to have a software firewall that protects the host itself and here we need to follow the attacker’s logic. So mainly the attacker would be looking into your operating system backlog size, how long are the TCBs kept in SYN-Received before timing out. The attacker can send a number of SYNs exactly equal to the backlog, and repeat this process again and again. The Solution for such “SYN DOS” attacks is proper filtering (Ingress/Egress) of traffic through firewalls and automatically dropping packets that are not explicitly allowed by policy, using IPSec to defend against the distributed spoofed packets, plus tuning the TCP/IP stack in the operating system. We also want to secure the interaction with the hypervisor by creating local users with admin rights other than the Root credentials. Moreover, when you move your compute, storage and networking services into the cloud, you want to centralize and secure the user authentication of these services. Attackers might bridge in and replace your LDAP or Radius server that you are using for authentication, so to mitigate the risk, review carefully your authentication process and make sure you have TLS and SSL in place and they are working properly.

Lock#4 – Domain Name System: Without DNS, there is no IP to domain mapping and accordingly there is no access to the outside world, so protecting your DNS is a key for deploying network security. Consider deploying multi-layer defense to protect against DDOS, DNS stateful firewall to protect against poison pill and DNSSEC for Cache poisoning. From design perspective, make sure to have geographical redundancy of your DNS servers, enable load balancing between your DNS servers, dimension for the future capacity for both throughput and response time and have your system ready to scale up in case of unexpected load increase.

Lock#5 – Application Programming Interface: We are moving into an open environment where any application (Telco or IT) would run on any virtual layer, any hardware and integrated with any other existing cloud based or legacy based applications, and here the API security comes into the picture. Every API is fundamentally different; whatever the protocol we are using, whether it’s REST/http, SOAP/XML or other, we need a trusted environment from the service layer up to the abstraction and orchestration layer. From API security design perspective, use SSL to protect the API end points, implement gateways that enforces security policies in front of these service APIs to protect them from DOS attacks, apply rate limiting, enforce federation relationships, and use service authentication & authorization based on orchestrated just-on-time data which would inform about who is accessing these APIs and under what conditions.

Finally, with all the above security lockers, we still need to have some kind of virtual robots or honeypots to know the frequency of attacks and how they vary geographically. The algorithm in the honeypots provides detail on the IP addresses of the source location, determine attack vectors, identify malwares and do reverse engineering. To provide early warning for new malwares, it’s very critical to design the right integration points between these honeypots and analytics and between your analytics platform and the cloud management system.