<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Blocking a user in trusted zone from downloading files on the internet with macros in Advanced Threat Prevention Discussions</title>
    <link>https://live.paloaltonetworks.com/t5/advanced-threat-prevention/blocking-a-user-in-trusted-zone-from-downloading-files-on-the/m-p/421146#M1247</link>
    <description>&lt;P&gt;"&lt;SPAN&gt;the stateful function of the firewall will auto-permit the return traffic" this is only true if you enable DSRI in the security policy, otherwise the firewall will inspect both c2s and s2c flows.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;If the user checks their personal email, the traffic will be TLS encrypted, so you need to enable SSL decryption for the firewall to inspect the file download.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;The file will be inspected by the Antivirus engine and if there is a match, the file will be blocked.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;If it is not a match, it is useful to have a WildFire Analysis Profile in the policy as well, so that the file will be sent to WildFire for sandboxing. It may not block the file, but at the very least, you will receive a report in your WildFire Submission Logs indicating that a malicious file that wasn't blocked has been observed in transit to the user.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;If the user runs Cortex XDR Endpoint protection, and a malicious verdict was made by WildFire before the user opens the file, then there is the likelihood that you may be able to stop execution with Cortex XDR Endpoint.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;Otherwise, not allowing Macros to auto-run is always a good idea.&lt;/SPAN&gt;&lt;/P&gt;</description>
    <pubDate>Wed, 21 Jul 2021 21:25:33 GMT</pubDate>
    <dc:creator>mivaldi</dc:creator>
    <dc:date>2021-07-21T21:25:33Z</dc:date>
    <item>
      <title>Blocking a user in trusted zone from downloading files on the internet with macros</title>
      <link>https://live.paloaltonetworks.com/t5/advanced-threat-prevention/blocking-a-user-in-trusted-zone-from-downloading-files-on-the/m-p/421143#M1246</link>
      <description>&lt;DIV&gt;&lt;DIV class=""&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&lt;SPAN&gt;Hey Guys,&lt;/SPAN&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"&gt;&lt;SPAN&gt;So Follow me on this scenario if you would: User on their corp PC behind the trusted interface of the Palo goes to their personal web-based email, opens a bad email, and downloads a file with macros in it. How do I stop that, because the stateful function of the firewall will auto-permit the return traffic (in this case, the macro file) from the internet back through the untrust interface of the firewall and back to the user. That's a problem, obviously. Is there a way to set exceptions to the stateful function? For example: "All traffic sourced from the inside is auto-permitted back through the firewall UNLESS, it contains a macro?"&lt;/SPAN&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;</description>
      <pubDate>Wed, 21 Jul 2021 21:13:54 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/advanced-threat-prevention/blocking-a-user-in-trusted-zone-from-downloading-files-on-the/m-p/421143#M1246</guid>
      <dc:creator>dromanelli</dc:creator>
      <dc:date>2021-07-21T21:13:54Z</dc:date>
    </item>
    <item>
      <title>Re: Blocking a user in trusted zone from downloading files on the internet with macros</title>
      <link>https://live.paloaltonetworks.com/t5/advanced-threat-prevention/blocking-a-user-in-trusted-zone-from-downloading-files-on-the/m-p/421146#M1247</link>
      <description>&lt;P&gt;"&lt;SPAN&gt;the stateful function of the firewall will auto-permit the return traffic" this is only true if you enable DSRI in the security policy, otherwise the firewall will inspect both c2s and s2c flows.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;If the user checks their personal email, the traffic will be TLS encrypted, so you need to enable SSL decryption for the firewall to inspect the file download.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;The file will be inspected by the Antivirus engine and if there is a match, the file will be blocked.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;If it is not a match, it is useful to have a WildFire Analysis Profile in the policy as well, so that the file will be sent to WildFire for sandboxing. It may not block the file, but at the very least, you will receive a report in your WildFire Submission Logs indicating that a malicious file that wasn't blocked has been observed in transit to the user.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;If the user runs Cortex XDR Endpoint protection, and a malicious verdict was made by WildFire before the user opens the file, then there is the likelihood that you may be able to stop execution with Cortex XDR Endpoint.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;Otherwise, not allowing Macros to auto-run is always a good idea.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 21 Jul 2021 21:25:33 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/advanced-threat-prevention/blocking-a-user-in-trusted-zone-from-downloading-files-on-the/m-p/421146#M1247</guid>
      <dc:creator>mivaldi</dc:creator>
      <dc:date>2021-07-21T21:25:33Z</dc:date>
    </item>
  </channel>
</rss>

