App-ID is a critical feature of our next-generation firewall. It’s one of the features, in fact, that lead to the market’s acceptance of next-generation firewalls and established Palo Alto Networks as a clear leader. This post will provide a few use cases to highlight App-ID’s purpose and power and why it’s foundational to our prevention-based approach to security.
Single Pass Parallel Processing is what allows Palo Alto Networks to maintain performance while using all of the firewall’s available features. User-ID integrates identities into the platform giving administrators the ability to create security policies with a source attribute of users and groups in addition to the typical IP address. User-ID also enables administrators to quickly identify who is doing what in an environment during an investigation. Many other features, including Content-ID and SSL Decryption, help make Palo Alto Networks the next-generation security platform that it is.
App-ID provides visibility into the applications being used in the environment regardless of the port. Once visibility is available, control can be achieved. App-ID uses all of the information provided by a stream of network traffic and uses a combination of IP addresses, ports, transaction characteristics, protocol decoders, heuristics, decryption, and more to identify the application.
Today’s widespread acceptance of SaaS applications is a challenge for IT because those applications are managed by a third party and the data is being stored in that third party’s data center.
One way to manage this type of SaaS while still providing users with the flexibility they want is to choose a cloud-based file collaboration solution that allows for identity directory integration. Microsoft OneDrive, Google Drive, and several other solutions offer identity integration.
Take Box.com as the example. When a user is added to the directory server they are also enabled with a Box.com account. When a user leaves an organization for whatever reason and directory accounts are disabled, so is the user’s access to all of those files in the Box.com cloud. Furthermore the IT administrator can change the password and gain access to the files.
The residual challenge is that even though the organization has standardized on Box.com there is nothing preventing users from uploading corporate data to other SaaS solutions.
This is one of many places where App-ID can help. A security policy can be implemented to allow access to Box.com with the source of all authenticated users. In the same policy we will then decrypt the SSL traffic. We can see whether people are uploading, downloading or both, as well as determine if known or unknown threats are being transmitted, and block them. This is all configured in a single policy.
People also use cloud-based file collaboration tools for personal data. We don’t want to stop them from listening to their music or sharing pictures of their family vacation – we want to safely enable them to do those things. As a second security policy we would permit all users to the application sub-category filesharing. However, we will decrypt the SSL traffic to gain visibility into what is happening in the sessions. If they are downloading non-malicious files, we are OK with that. If they download something malicious it will be blocked. And we can add a File Blocking profile that only permits downloads and not uploads.
The result? People can use the applications they have become accustomed to, and the organization prevents malware from getting into the network and data from going to unmanaged and undesirable destinations.
Compared to the way traditional firewalls work, App-ID can drastically reduce the amount of security policies needed.
Most routers, switches, SANs and network security, among other network infrastructure technologies, have dedicated management interfaces. These products run a standard service like a web server but do so on various ports: 80, 8080, 8888, 7000, the list goes on.
With a legacy firewall a security policy will need to be implemented with both a source network of the LAN and the destination network of the management network. Each of the ports would then need to be configured as a custom object and added to the destination services to permit the traffic. This is a cumbersome and outdated way of doing things. And it could also lead to undesirable traffic.
Because App-ID doesn’t rely exclusively on ports, this rule could be consolidated to include just a single application -- web browsing -- rather than each of those ports individually. When permitting the application web browsing from the LAN into the management network you have the option to use the default port (80) or any port. By using any port the Palo Alto Networks appliance will determine if this really is regular web-browsing to a web server and if so permit the traffic. As in the previous example, you could also decrypt the SSL if it is enabled, prevent anything known to be malicious, and control uploads and downloads.
Users and malicious actors misuse or exploit regular TCP and UDP services to bypass security controls.
For example, regular users may want to get to a website that is prohibited by the security infrastructure. They will find or setup an HTTP proxy server of their own outside of the firewall. They configure their browser to point to their HTTP proxy server so that all requests will be sent over HTTP to their proxy server. The security infrastructure will simply see HTTP requests to some random destination on the Internet, the proxy server, and permit it. The proxy server then makes the connection to the desired website and then responds with that data to the user from the proxy server. The security infrastructure typically only sees HTTP requests.
A malicious user or malicious piece of software will eventually want to exfiltrate data. In many cases attackers will have an FTP server in the attacker network to which to dump data. If the FTP protocol is not permitted out of the compromised network, the attacker will find a service that is permitted, such as DNS, HTTP, or SSL. From there, attackers can easily change the port number on their FTP server to something that is allowed out of the compromised network and the data can be transferred.
Using App-ID prevents both of these issues. When the application web-browsing is permitted, App-ID can tell the difference between visiting a normal website and when HTTP is being used to wrap and proxy traffic to a different destination. There is an http-proxy application that could be used if there is a legitimate proxy server in the environment. Likewise, when an attacker attempts to use DNS (UDP/TCP port 53) to disguise FTP traffic, App-ID will identify this and the traffic will not be permitted unless it is actual DNS.
Application firewalling is a critical component of any network infrastructure today, but it’s just one piece of the puzzle. User-based security policies, visibility into encrypted traffic, prevention of known and unknown malicious behavior, and the ability to architect the same solution everywhere are also part what make Palo Alto Networks a true platform that can go well beyond the outmoded approaches provided by stateful inspection firewalls, endpoint products and UTM appliances.
Look out for future posts where we take a deeper dive and provide examples of how other components support the platform.
By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement. Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.