Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 15 subscribers
  • Views 1603 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL/TLS decryption - Downloads

Axnfell

I am pleased this feature now exists in Intercept-X

We see one of the main attack vectors as follows:

  • User receives phishing e-mail or a macro-enabled attachment.
  • User clicks through warnings and executes the macro-enabled attachment. Or, they're tricked into a download.
  • It downloads an executable or payload etc, etc.

While we can block Downloads in a Web Control policy (particularly exe, DLL, etc) - it would never prevent Downloads through HTTPS connections.

Now we have the capability:

  • Given my use case above, is it possible to implement a policy on the endpoint that prevents users from downloading executables or potentially malicious payloads (i.e. Beacons)
  • If so, how do we avoid legitimate downloads (i.e. Microsoft Updates, Adobe, etc) - or do we simply have to whitelist wildcard domains?

I appreciate we can do this at the firewall level with SSL-inspection.

Ideas welcomed.

Thanks



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to Qoosh

    Simply put - we want to prevent drive by downloads or high risk file types, as you indicated.

    Prior to SSL support, this was pointless. Risky download protection only worked for HTTP, and most malicious actors would use HTTPS

    Now SSL is supported, if we implement these policies, will we hit upon many false positives? Mainly

    - O365 updates, Windows Updates, Sophos updates etc.

    Does Sophos already have global exclusions for these?

    Also, does the endpoint agent identify the file type based on payload or just extension?

Unfiltered HTML