Securing Greenfield Service Provider Clients

Fri Oct 9 23:26:21 UTC 2020

Dear Mr. Curtis and Nanog;

Thank you for your responses.  Yes, I am investigating the feasibility of public internet access to help with Digital Divide issues in light of the COVID-19 pandemic as well as the challenges of security in this public application.

It’s relatively straightforward to segment East-West traffic; however, I’m not so sure about the case of North-South.  I need to address this issue somehow in my assessment of risks in public networks.

I do *not* want to decrypt SSL traffic.  But I would *like* to be able to have some black box with a subscription at the network edge prevent malware from being downloaded through the network.

My question was whether this is even possible in a public context.  Secure DNS services would go a long way toward this goal.

Is it fair to say that an NGFW *must* decrypt SSL traffic in order to fully categorize for IPS/IDS prevention?

Thank you,
CJ

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Curtis, Bruce <bruce.curtis at ndsu.edu>
Sent: Friday, October 9, 2020 5:23:45 PM
To: Christopher J. Wolff <cjwolff at nola.gov>
Cc: nanog at nanog.org <nanog at nanog.org>
Subject: Re: Securing Greenfield Service Provider Clients

EMAIL FROM EXTERNAL SENDER: DO NOT click links, or open attachments, if sender is unknown, or the message seems suspicious in any way. DO NOT provide your user ID or password. If you believe that this is a phishing attempt please forward this message to phishing at nola.gov

If you search for this phrase

        During 2020 more than fifty percent of new malware campaigns will use various forms of encryption and obfuscation to conceal delivery, and to conceal ongoing communications, including data exfiltration.

you will find lots of vendors of decryption have the phrase from Gartner mentioned prominently on their web site.

I don’t think TLS decryption would be viable in our university environment.

Your email address indicates that you are in a government environment and if so you might have more control over devices and could have a better chance of making decryption work.
On the other hand if you have more control over devices a better choice might be to spend your resources on implementing whitelisting rather than decryption.

Keep in mind that if you implement decryption your decryption device is in scope for PCI and subject to the various PCI duding and logging requirements.

Attackers abuse Google DNS over HTTPS to download malware

https://www.bleepingcomputer.com/news/security/attackers-abuse-google-dns-over-https-to-download-malware/

More general and as focused on decryption but I recommend you watch these sessions from RSA conferences.

https://www.youtube.com/watch?v=d90Ov6QM1jE

https://www.youtube.com/watch?v=qzI-N0p9hFk

And also the NIST draft on Zero Trust Architecture.  The document is mainly about Zero Trust but does briefly mention decryption.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

https://csrc.nist.gov/publications/detail/sp/800-207/final

> On Oct 9, 2020, at 2:09 PM, Christopher J. Wolff <cjwolff at nola.gov> wrote:
>
> Dear Nanog;
>
> Hope everyone is getting ready for a good weekend.  I’m working on a greenfield service provider network and I’m running into a security challenge.  I hope the great minds here can help.
>
> Since the majority of traffic is SSL/TLS, encrypted malicious content can pass through even an “NGFW” device without detection and classification.
>
> Without setting up SSL encrypt/decrypt through a MITM setup and handing certificates out to every client, is there any other software/hardware that can perform DPI and/or ssl analysis so I can prevent encrypted malicious content from being downloaded to my users?
>
> Have experience with Palo and Firepower but even these need the MITM approach.  I appreciate any advice anyone can provide.
>
> Best,
> CJ

Bruce Curtis
Network Engineer  /  Information Technology
NORTH DAKOTA STATE UNIVERSITY
phone: 701.231.8527
bruce.curtis at ndsu.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201009/1e695afc/attachment.html>