Application Visibility, what is it actually? – Tec-Bite IT-Security Blog

About the job

In a classic data centre, firewalls are mostly used to protect the perimeter. Often there is also a DMZ, which is usually protected by an internal and an external firewall. In larger companies, there are also so-called network zones, which are mostly separated by firewalls (to create a higher security area). However, when moving within a zone, the traffic between servers (the so-called East-West traffic) remains open and is not protected internally by firewalls. It would neither be economically sensible nor operationally feasible to insert so many firewalls to protect this local traffic as well. If it concerns internal web applications (intranet), this web traffic may still be controlled via internal proxies, but these usually follow the zone concept and are often installed parallel to the firewalls. What is the actual disadvantage of such a setup? If a breach occurs, the attacker can usually move very freely within this zone, i.e. they can scan this part of the network and try to identify and attack other servers specifically. If they have enough time, they can spread to many servers and try to piggyback on "normal" traffic to get through the firewalls. Protecting against this is not a simple task in a classic data centre with many physical servers. Security teams must, for example, scan network traffic at critical points and rely on endpoint security. Even if the servers are virtualised (e.g. VMware), it is still relatively complex; only with network virtualisation (such as NSX) does it become significantly easier. Application Visibility Now there are solutions that create or enable so-called "application visibility." That means they show which servers connect to which other servers and, above all, which applications communicate with which other applications (besides internal services like AD, SNMP monitoring, etc.). Application Visibility solutions install probes and continuously monitor servers, applications, and the network. Many can also create a so-called baseline, a basic behaviour that shows how the application normally behaves, how often and how much it communicates with other servers. Based on this baseline, monitoring can be set up that triggers an alert if an application causes anomalous traffic, allowing the ops team to quickly investigate the cause. What does this have to do with the cloud? Having an overview of applications and their mutual dependencies and connections greatly facilitates migration to the cloud. Even with a simple "lift & shift" approach (replicating exactly what is in the data centre in the cloud, just virtualised), you can benefit from this information. This makes creating microsegmentation much easier because you now know which applications and services "belong together" and over which ports they communicate. How does such a whitelisting policy work? By blocking all connections except those explicitly allowed. Thanks to the Application Visibility Map, you know which applications communicate over which ports and can explicitly allow these connections while blocking all others. And how does this work with containers? Once you know the dependencies of your applications, it is independent of how they are deployed (as VMs, Docker containers, via Kubernetes, or as serverless functions). Ideally, you have a policy that applies to the entire infrastructure. For example, front-end servers may only communicate with databases over port 3306. This should apply exactly the same in VM environments as in container environments. Implementing such a policy is particularly easy with container solutions, especially Kubernetes, because you work with so-called tags. A database server or service is classified (tagged) as such, and a front-end web server is also tagged. This allows you to write abstract policies (front-end servers may only communicate with databases over port 3306). As long as a new server is correctly tagged, it is automatically covered by this policy. For example, if five new front-end servers are automatically started when the load increases, they are automatically covered by the same policy as the existing front-end servers because they are identified by the tag as such. The interesting thing is that developers or the DevOps team do not have to explicitly manage the policy for the new servers; this happens automatically, with the correct tag added during deployment. And what about serverless functions? Functions (FaaS) are simply small programmes or short scripts. They are usually triggered by an event, execute a function (an algorithm), and then shut down again. You can think of these functions as a container that is started, performs a task, and then is shut down. Accordingly, such a function can also be tagged and embedded in a policy. Technically, this is done differently than with a container, but the basic idea is the same. And if a VM creates an unauthorised connection? If a front-end server tries, for example, to connect to a database over port 22 (SSH), this will be blocked by the policy because port 22 is not allowed in this whitelisting policy. This attempt is logged and triggers an alert for the security or DevSecOps team. If suddenly a database receives much more data from a web server than usual (this is monitored via the baseline), this is identified as an anomaly, logged, and also triggers an alert for the security team. It is also possible to program automatisms and enforce policies automatically (so-called "automatic enforcement"). If a VM or container tries to establish unauthorised connections, the suspicious element can be immediately isolated from the network (quarantine), or the VM can be shut down and the container killed, automatically starting a new (clean) VM or container. The DevSecOps team receives an alert and can verify whether there is a vulnerability in the code. How much you want and can automate depends mainly on the maturity of your applications and the experience of the DevSecOps team. TLDR*: Application Visibility solutions help to show which applications communicate with which other applications or services. Based on this data, microsegmentation with whitelisting can be created. The Application Visibility platform can also continuously monitor and identify anomalies and alert. The article Application Visibility, what is it actually? first appeared on Tec-Bite.