WannaCry, SambaCry, and other attacks have pinpointed the need to not just protect from unwarranted access, but to define unwarranted better. It is not just about ports and firewalls, but also about applications, APIs, and processes. In other words, services. Many of these services need to communicate about the ports that need to be blocked to stop the threat of worms in their tracks. How do we address the need for services to talk using well-known communication protocols over well-known ports? How do we safeguard ourselves while blocking the bad actors in the world?
Security for cloud-native applications, whether containers or APIs, has a need to protect not just at the port level (à la firewalls), but at deeper levels. We need to know more and more about our services. We need our services to work on the mandatory access-control methodology instead of on the discretionary access control we often deploy currently. Today, we have what is depicted in Figure 1. This is a set of firewalls between all our services, with the most stringent usually at the edge between the clients and the ADC. Sometimes, the ADC is on the other side of the firewall. It depends on needs more than anything.
The biggest problem with Figure 1 is that the access controls are discretionary. In other words, it is up to the application to enforce them. If the application requires that everything talk over a certain port, then all traffic to and from that port is allowed, including traffic from unknown locations within a network. Ransomware can spread using well-known ports, but from applications not specifically allowed. Since we just have port-level controls, it is difficult to manage who can access the allowed ports. This is where Figure 2 comes in.
Figure 2 represents a cloud-native application security architecture that uses mandatory access controls for network functions. We still work with ports, but our controller stores more data—data perhaps from the clients but definitely from all stages of the application. Essentially, we are applying more control within each of the services and components than exist elsewhere. These are controls such as allowed users, devices, processes, applications, etc. The list can be pretty mind-boggling at times.
Each layer, service, or program checks with the controller to determine if it is allowed. If the controller allows the connection, then the connection is established and traffic can flow. However, if the device, user, process, or any number of other elements are not correct, then the communication is disallowed. This approach implements a mandatory access-control mechanism based on a policy established within the controller. The controllers can live anywhere and are themselves locked down pretty well. For any given application, there should be a redundant set of controllers to handle applications within multiple clouds. Yet, each controller may need to share data if the application crosses cloud boundaries.
In the end, you have network control at levels previously unheard of. While web application firewalls look for bad web traffic, cloud-native application security applies to all forms of applications, not just network. It can apply to traffic allowed to access file servers such an SMB. It can apply to anything that speaks over a network. By limiting who and what can establish connections, the applications are far safer.
There is much more involved than networking to securing an application. However, keeping bad actors from using unknown applications and devices is a good start.
Who delivers such? There are a few out there, including Vidder, Aporeto, and others. Vidder coined the phrase “Software Defined Perimeter” and applied this technology to mobile devices more than to applications. Aporeto is designed for the entire network and for any application. The real issue is that for existing applications, you need to discover and then approve policy changes. For cloud-native applications, where you are just starting, such control items could be part of the container definition.
The approach described is a good start—a start to take control back from the bad actors. However, it is still just one piece of the puzzle, one that has been missing until now. Greenfield applications have a leg up, while brownfield still needs some assistance.