Wall's Week - October 1st, 2018

by kwall00 2 weeks ago - last edited 2 weeks ago by (2,340 Views)

GlobalProtect Cloud Service – Plug-in 1.2.0 available

If you are using the Palo Alto Networks managed VPN service for branch locations and/or mobile users, the latest plug-in is available. The release notes can be found here. Some of the enhancements:

  • Gateway selection improvements
  • Status monitor improvements
  • All FQDN’s for the GlobalProtect Cloud Service are now viewable
  • Paloalto-shared-services App-ID recently released works with GlobalProtect Cloud Services

 

 

Palo Alto Networks receives highest recommendation from NSS Labs

NSS Labs awarded Palo Alto Networks with their highest award, “Recommended” for overall security effectiveness, performance, and total cost of ownership in the 2018 NSS Labs Next Generation Intrusion Prevention System (NGIPS) Test. In doing so, we blocked 99.8% of 1,900+ exploits and stopped 100% of 147 different evasion techniques.

 

These results add to other recent NSS Labs “Recommended” ratings for Next Generation Firewall, Data Center Security Gateway, Breach Prevention Systems, and Advanced Endpoint Protection. More information may be found on our blog site.

 

 

Magnifier – new features

Every month brings new features to our user behavioral analytics tool – Magnifier. Here are the ones for September 2018.

 

 

PANOS 6.1 End of Life October 25th

Just in case anyone is still on PANOS 6.1, you should know that it will no longer be supported on October 25th, 2018. For other end-of-life information for PANOS releases, see this page.

 

 

Trial Evident for public cloud

Do you have resources with one of these public cloud providers: AWS, Azure, Google Cloud Platform? If so, there are only two ways to know if security best practices are being followed in these environments. One way is manually, by logging in and looking at every resource on a frequent basis. The second way, is dynamic by making use of the API into the provider platforms.

 

There are hundreds of best practices that should be followed for each resource in the cloud, but here are a few to consider:

  • Are there any machine images in use which are not in compliant with IT policy?
  • Are any files or shares open to the Internet?
  • Are your security keys being rotated every 90 days?
  • Is anyone accessing these environments outside of a multi-factor authentication connection?
  • Is your data-at-rest encrypted if this is your corporate policy?

Since these environments can and often change quickly, it is not possible to manually keep an eye on resources and whether or not they comply with corporate security policies. The only tenable way is with automation using the API’s. This is what Evident does. If you want to trial Evident, all you need is this link and read-only access to your cloud’s environment.

 

 

Unit42 Playbooks

If you haven’t checked this site recently, you might want to try out the new playbooks from Unit42. Each playbook provides information on a specific malware campaign including the person/organization behind the campaign and detailed IOC’s. The player is 100% online and allows the reading of all of the playbooks. There are several new books including one on DARKHYDRUS. Access to the playbooks here.

 

  

TIP: Security policy evaluation with implicit applications

The firewall supports implicit application matching to prevent the need to configure security policies to explicitly match against these implicit apps. Implicit app matching does not deny traffic that can change App-ID as it progresses through the decoder.

A subtlety of the policy matching process is that the policy evaluation engine has a preference for a rule that matches an explicit App-ID with an Allow action over a rule that matches implicitly with an Allow action. This is easier to understand with examples. Consider the following three uses cases.

 

Firewall configuration for cases #1 and #2. 

Security Rule 1 - Allow facebook-base (facebook-base implicitly allows ssl and web-browsing)

Security Rule 2 - Deny-All (Application set to Any) 

 

Case #1 - User accesses facebook.com. 

  1. Initially, traffic is identified with App-ID ssl. 
  2. SSL is an implicit app of facebook-base, so it initially matches the allow rule because the second rule is a deny rule.
  3. Application changes to facebook-base after SNI parsing. 
  4. Due to the application change, policy lookup occurs again. 
  5. Security policy engine selects Rule 1 due to the explicit match with facebook-base.

 

Case #2 - User accesses google.com. 

  1. Initially, traffic is identified with App-ID ssl. 
  2. SSL is an implicit app of facebook-base, so it initially matches the allow rule because the second rule is a deny rule.
  3. Application changes to google-base after SNI parsing. 
  4. Due to the application change, policy lookup occurs again. 
  5. Security policy engine selects Rule 2 due to the fact that google-base does not match facebook-base and there is an explicit match with application, ANY.

 

Case #3 - User accesses facebook.com with an Allow-All Rule

Security Rule 1 - Allow facebook-base

Security Rule 2 - Allow-All (Application set to Any) 

  1. Initially, traffic is identified with App-ID ssl. 
  2. But unlike the use cases above, even though SSL is an implicit app of Facebook-base, it prefers Rule 2 because it is explicit match with the action ALLOW. 
  3. If Log setting were to set to log at session start, the log would show application as ssl. 
  4. Application changes to facebook-base after SNI parsing.  
  5. Due to the application change, policy lookup occurs again. 
  6. Policy lookup finds an allow rule with an explicit match that is higher in the rule order and therefore matches against Rule 1.  

Ask Questions Get Answers Join the Live Community