Wall's Week - November 26th, 2018

by kwall00 3 weeks ago - last edited yesterday by (2,305 Views)

Palo Alto Networks Live Community uncovers deploying MineMeld within Azure and custom indicators with MineMeld. We also explore the Self-Service BP and details on new Aperture enhancements. Read some helpful TIPs on DNS Proxy, Data Filtering Logs, and Different User Credential Detection Methods.

 

 

 

Summary

How to deploy MineMeld within Azure

Self-Service best practice assessment 

Using custom indicators with MineMeld

New Aperture enhancements

TIP: DNS Proxy

TIP: Data Filtering logs – best practices

TIP: Differences between User Credential Detection methods

 

 

How to deploy MineMeld within Azure

MineMeld is an open-source tool from Palo Alto Networks to assist in threat feed aggregation and consumption. MineMeld’s “miners” are responsible for retrieving feed data on a defined basis and importing the data into MineMeld. Once imported, feeds are deduplicated and aggregated into one or more lists. After aggregation, the lists are published and ready for consumption by Palo Alto Networks firewalls and other security tools. MineMeld may be run on-premise or in a public cloud. I wrote this article to show the step-by-step process for deploying MineMeld within the Azure public cloud. 

 

 

Self-Service best practice assessment

This feature is now available through the Customer Support Portal! What is a best practice analysis? It is a comprehensive report run against your tech-support file from your Palo Alto Networks firewall or Panorama. The report reveals how your configuration compares to our best practice recommendations. For example, do you have DNS Sinkhole deployed on your Anti-Spyware rules? What percentage of your rulebase uses User-ID and App-ID? Are you performing decryption on outbound traffic? These are just a few examples. 

 

When you log into the Support Portal, choose Tools from the left menu pane and then select Run Best Practice Assessment. You will then be prompted to upload a tech-support file. To get a report on your entire deployment, be sure to upload a tech-support file from your Panorama instance. 

 

 

Using custom indicators with MineMeld

If you’re looking for a way to keep track of your own indicators, take a look at my latest article. Using MineMeld, you can enter your own URL, IP, or Domain entries and  publish to a list which can be consumed by the Palo Alto Networks firewall. This is a great way to keep track of manual IoCs outside of your usual digital feeds – which can also be managed by MineMeld. Enter IoC’s through the UI or use a script to populate multiple entries.

 

 

New Aperture enhancements

Hopefully you have noticed the update pattern with our SaaS applications. Every month you will see enhancements to products like Aperture, Magnifier, and Evident/Redlock. In case you are not familiar with Aperture, it is our SaaS product for governance and compliance for corporate data which resides outside of the data center (i.e., Box, Dropbox, O365, Salesforce, Github, etc). Here are some of the new features this month for Aperture.

  • File properties (metadata) data patterns
    • You can now define flexible data patterns for matching file properties. When adding new data patterns, there is now a dropdown to select adding either a traditional data pattern for examining file contents or a file property. Multiple matches may be specified. File properties can be added to the match criteria of asset policies for examination and remediation.
  • Clone rules
    • It is now possible to clone a rule so it can be adjusted or modified without losing the original. This option exists on all rules (asset rules, user activity rules, security rules).
  • Cisco Webex Teams (formerly Cisco Spark)
    • Aperture now provides content identification, exposure controls, activity monitoring, malware protection, and remediation for users of Cisco Webex Teams. This platform is similar to Slack and allows teams to leverage spaces, virtual rooms, whiteboards, and chats etc.

 

 

TIP: DNS proxy

Were you aware that your Palo Alto Network’s firewall can function as a DNS proxy server? If not, and now that you know, the next question might be - why would you want to enable this feature? You would want to use this feature so that the firewall can track DNS queries and responses. Some malware will make a DNS call to a legitimate site, or one that is categorized as “business and economy” for example, but then start a session to a different site. When this happens the HTTP portion of the packet will contain the legitimate URL (the one requested through DNS), but the destination IP address will not match any of the DNS responses. This is an evasion technique. Malware authors take advantage of sites which are likely permitted by URL Filtering Profiles in an attempt to bypass the firewall. 

 

Before enabling DNS Proxy, you should keep the following in mind:

  • Endpoints must point to the firewall in order to resolve DNS
  • You can enable DNS Proxy on a per-interface basis so it doesn’t have to be for all traffic
  • You should have an idea of the average DNS requests per second that will be processed by the firewall
  • Static entries are allowed
  • You can also configure specific domains to be resolved by specific DNS servers if needed
  • You must be decrypting SSL traffic in order to see TLS evasions

 

To configure DNS Proxy, go to Network > DNS Proxy > Add. To see the signatures that may be matched, go to Objects > Security Profiles > Anti-Spyware and select an existing profile. Go to the Exceptions tab, check the box to show all signatures, and search for “evasion” in the search bar. You will see one signature for HTTP and one for TLS. Check the box on the left-hand side to Enable the signatures. Optionally change the Action and Packet Capture fields. See the documentation for more information.

 

 

TIP: Data Filtering logs – best practices

You are probably aware that the Data Filtering logs contain information related to Data Filtering profile matches (social security numbers, credit card numbers, etc.). However, File Blocking profile matches also appear in the Data Filtering logs. It is important to configure File Blocking profiles and attach them to Security rules – even if your organization does not block any files. There are two File Blocking profiles included and the strict file blocking profile is the best practice. Not all security teams have success at convincing the business to block file downloads for the average user however. In this case, you should at least create a File Blocking profile which logs all file downloads and file uploads. Be sure to attach this profile to every allowed security rule. These entries will be logged to Data Filtering. 

 

You now have a record of every file passing through the firewall, what user or device was associated with the transfer, what IP was involved on the other side, the URL, the country involved, the URL category, and much more. How can you use this data? A best practice for URL Filtering is to block sites which are categorized as unknown. Again, not all organizations have this policy in place. I always recommend to at least block file uploads and downloads when the site is categorized as unknown. If you wanted to see whether or not any file transfers are taking place with unknown sites, you can use the Data Filtering logs to find out.

 

Go to Monitor > Logs > Data Filtering. In the search bar, use this string to filter on entries where the URL category was unknown:  ( category eq unknown )

 

This will provide instant intel on how much of this activity is taking place. Before enforcing the file transfer blocking policy on unknown sites, you will want to take note of the application involved. This may be used to create exceptions for legitimate transfers ahead of the blocking policy so that allowed traffic is not impeded.

 

 

TIP: Differences between User Credential Detection methods

Users are being duped into providing corporate credentials. We know it’s bad. We know it’s both endemic as well as pandemic. Unfortunately, attackers are still enjoying a high success rate at phishing. For a while now, you have had the ability to enable user credential detection within the Palo Alto Networks firewall. This means the firewall can watch for corporate credentials being entered in a site that is not appropriate for corporate credentials. Low hanging fruit in my opinion and everyone should be deploying this feature. 

 

There are three options when configuring this anti-credential theft mechanism. Here are the options and how they differ from one another.

  • Use IP User Mapping
    • If you are mapping User-ID with IP addresses within the firewall, there is a table that exists in Monitor > Logs > User-ID. This table is consulted when the firewall sees a username being entered on a website. The firewall compares the username being entered with the internal User-ID table to see if there is a match. If so, the entry is denied and the user is presented with a message.
  • Use Group Mapping
    • If you are using group mapping within the firewall (i.e., Active Directory groups), then the firewall has this information stored and is updated at specified intervals. When using this method, the firewall compares a username being entered on a site with any username within any of the groups mapped from the directory server (not just active users in the network). This means one user won’t be able to use another user’s corporate username on an inappropriate site (in addition to their own corporate username). 
  • Use Domain Credential Filter
    • The previous two methods are only concerned with usernames. This method compares both the username and the user password for a match. In order to do this, you must deploy the Palo Alto Networks User-ID agent on a read-only domain controller. The agent populates the firewalls with corporate usernames as well as a one-way triple-hashed password table called a bloom filter. At no time are actual user passwords stored on the firewall. The method compares the username and password being entered on a site. Like the Group Mapping option, this method does not require the user to be active on the network and prevents one user from using another user’s credentials. However, both the username and the hashed password must match using this method.

 

Educating users to understand why they shouldn’t user their corporate credentials on non-approved sites is still necessary. But until attackers are less successful at phishing for those credentials, the Palo Alto Networks firewall can help users from themselves. It only takes one open the door to the uninvited. It is highly recommended to decrypt SSL before implementing these User Credential Detection features.

Ask Questions Get Answers Join the Live Community
Labels