Securing Greenfield Service Provider Clients

Sun Oct 11 19:30:05 UTC 2020

> On Oct 9, 2020, at 6:26 PM, Christopher J. Wolff <cjwolff at nola.gov> wrote:
> 
> 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?  

Another thing to keep in mind is that NGFW/IPS depend on blacklisting to block malware.

Even if you did install certificates on all devices to enable TLS decryption (and bring the decryption device in scope for PCI) that is not a guarantee that the NGFW/IPS can block an amount of malware worthy of the investment.

"By 2017, around 96 percent of all malware files detected and blocked by Windows Defender were detected only once on a single computer and never seen again.”

https://cybersecurityventures.com/the-devastating-effect-of-polymorphic-malware/

"For many years, the viewpoint on malware protection has been inclined towards investing in traditional security methods such as firewalls, antivirus as well as IPS. However, when it comes to protection against polymorphic malware, these solutions do not work properly.”

https://medium.com/@kratikal/how-polymorphic-malware-are-deceiving-the-traditional-cyber-security-method-b56e30655283

While blacklisting, either in a middle box or on the host, will not stop malware that is changed to have a different signature every time it is downloaded whitelisting on the end host might stop it.
In the example where whitelisting will stop malware but blacklisting will not you are better off spending your limited resources on whitelisting.

This is from 2014 but indicates the beginning of the trend to shortening times between malware morphing had started.

https://krebsonsecurity.com/2014/05/antivirus-is-dead-long-live-antivirus/

Insights from one year of tracking a polymorphic threat (another example of malware that a middle box would not stop)

https://www.microsoft.com/security/blog/2019/11/26/insights-from-one-year-of-tracking-a-polymorphic-threat/

> 
> Thank you,
> CJ
> 
> 
> 
> 
> Get Outlook for iOS
> 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
> 

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