Following up on our recent discussion of App-ID as critical for safely enabling applications, here we will cover a related feature: User-ID.
Visibility is the foundation of what makes the Palo Alto Networks next-generation security platform so powerful. User-ID provides visibility into user activity in the environment and allows you to enforce least privilege – one of the fundamental security principles. In other words, once you have defined what people are allowed to do on the network, you will very quickly be able to identify what they are actually doing. The purpose of this post is to offer examples of how User-ID provides operational efficiency over IP only-based security policy with better security at the same time.
User information can be obtained in a variety of ways; and, most often, several methods are combined to provide the most thorough coverage. Once integrated, user and group information can be used in security policy and also found in logs during investigations. Here are a few of the ways user information can be integrated into the Palo Alto Networks platform:
- Directory services – Most environments will have Active Directory, Radius, or LDAP to centrally authenticate and authorize users. The platform can either remotely collect the relevant information or an agent can be deployed to gain access to it. This will cover the majority of systems in the environment.
- Microsoft ActiveSync – Many personal devices will not be connected to the domain. People will bring their own laptops, phones, and tablets into the environment. Most of the time, these users will check their corporate email from these devices so their information can be gathered from the email server.
- Application Program Interface (API) – User information can be gathered from any device that logs user authentication using the API. Some strategic partners, such as Aruba Networks, have already built this integration with Palo Alto Networks. Otherwise you can build it with the help of our channel partners.
Operational Efficiency With Better Security
Every network has elements that need management, such as routers, switches, security appliances, and servers. These management systems should be segmented into their own subnets so that you can control who accesses them and how. Traditionally this segmentation was accomplished by providing the network administrators with static IP addresses to identify them. An access control list would be implemented to allow only those static IP addresses to access the management network on the specified ports.
This approach means numerous security and operational issues. It takes time for a new administrator to get the static IP address, and then more time to request and wait for the access control to be implemented. Anyone can take the administrator’s static IP address and now have administrative access. The ports permitted into the management network can be used for anything (see App-ID post). Threats are not being prevented. When an administrator leaves the organization, nobody goes back to clean up the security policies and anyone can still take that static IP address to gain access. Cumbersome and inefficient -- not a great combination!
User-ID and App-ID provide significant operational efficiencies. The security policy would be configured to allow people in the administrators’ user group on the directory server to access the management network on the actual applications (SSH, HTTPS, RDP, etc.). Within that traffic we can also prevent any known and unknown malicious traffic, which is helpful if you have a rogue administrator or a compromised administrator account. When a new administrator joins the organization, that person’s user account will be created on the directory server, and that person will automatically be enabled to perform his or her job securely. When a user leaves the organization, the first thing to happen is that person’s directory user account is disabled and access to the systems is automatically revoked at the network layer, in addition to the host.
Safe Application Enablement
Safely enabling applications means permitting only the actual applications you want to allow, using App-ID, and then preventing threats within that traffic. In most cases it is also important to permit whom you want to access those applications.
In the previous example, we covered how only network administrators can access the management applications in the network. This methodology can be extended to any application or groups of applications.
For example, in highly sensitive environments, uploading data to social media sites may be prohibited. But the human resources and marketing teams in an organization may require social media given the importance of its use in their jobs. One rule could be created to permit people in the HR and marketing directory server groups to use social media applications. SSL would be decrypted to ensure there is visibility into malicious behavior, and uploads and downloads would be permitted. A second policy could optionally be created for all other authenticated users that allows them to use social media applications. Again the SSL traffic would need to be decrypted, which would allow visibility into the traffic and enable administrators to prevent any malicious activity. Decrypting SSL also provides the visibility to enable downloads and prevent uploads.
The same methodology of providing access based on people applies for any other group of web 2.0 SaaS tools, like cloud-based email and cloud-based file collaboration. What this allows administrators to do is give the right people sufficient privileges to do their jobs and maintain an acceptable amount of personal activity while at work.
Incident Handling
When something suspicious is happening in the network, the first place to look is the firewall because of the traditionally more detailed logs it provides. The challenge has been, once the source or destination IP address has been identified, it can take several more hours to track down the specific device and then user. The security team typically hands the IP address to the network and server administration teams. The network team traces the IP and MAC address through the switch fabric trying to identify a port or device. Simultaneously the server administrators pour through DHCP server logs trying to find the IP address and then identify who was using the IP address at the exact time of the incident. This is very time-consuming. And when you look at the number of incidents in a typical network these days, it is also not scalable.
As an example, say the network starts to slow down in one of your organization’s branch offices. The network administrator can log on to the Palo Alto Networks platform, select ACC (Application Command Center), and quickly identify that someone is downloading and seeding files via BitTorrent. From there the administrator can drill down into the BitTorrent application and immediately have the source IP address and the user’s name. The administrator can now pick up the phone and call the user to let that person know what kind of impact he or she is having on the network. Alternatively the administrator can implement policies to either stop allowing the application or tune the policy to apply QoS (Quality of Service) rules so that a non-mission-critical application like this can’t slow down business applications.
In a worst-case scenario, a user device is compromised, command and control software is installed, and the host starts communicating with a command and control server outside of the network. From ACC, Threat Activity, Compromised Hosts, the security administrator can monitor for compromised hosts. The user may have been delivered a piece of zero-day, never-before-seen malware. Or perhaps the person was off the network with his or her laptop when initially infected. In either case the Compromised Hosts dashboard will provide the administrator with correlated alerts indicating issues that surely require attention. Drilling down into the alert, the administrator will be presented with which user’s device has been compromised. Rather than all of the rigor required to track down IP addresses, the administrator can very quickly contact the user or quarantine that person until he or she is available.
In our final example, say the Compliance team is concerned about a particular file leaving the environment. The security administrator can navigate to the Monitor tab and Data Filtering logs. From there the administrator can search for the filename. If the file crossed the path of the Palo Alto Networks platform, evidence will be presented with the time, application used to transmit the file, destination where the file went, and the user responsible.
In all of these cases, the organization benefits from operational excellence and better security because of User-ID. Leveraging User-ID, along with the rest of the platform, helps to optimize security efforts. App-ID, User-ID, SSL Decryption, URL Filtering, Threat Prevention, and WildFire all work together to safely enable applications and prevent known and unknown threats. User-ID, App-ID, and SSL Decryption focus on enablement, whereas URL Filtering, Threat Prevention (to prevent known threats), and WildFire mitigate residual risk by taking unknown threats and making them known within minutes.