Making The Case For SSL Inspecting Corporate Traffic

Almost every stakeholder, from Enterprise Security Architect to CISO that I speak with these days wants to be able to inspect their organization’s encrypted traffic and data flowing between the internet and the corporate devices and end users that they are chartered to safeguard.

When asked what are their primary drivers for wanting to enable SSL/TLS inspection the primary top of mind concerns are as follows:

  • Lack of visibility – Upwards of 75-80% of our traffic headed to the internet and SaaS is SSL/TLS encrypted
  • We know that bad actors are leveraging SSL/TLS to mimic legitimate sites to carry out phishing attacks as well as hide malware downloads and Command and Control (C&C) activities
  • I need to know where our data resides – We know bad actors are using SSL/TLS encrypted channels to attempt to circumvent Data Loss Prevention (DLP) controls and exfiltrate sensitive data. Our own employees may intentionally or unintentionally post sensitive data externally

With a pretty clear understanding of the risks faced by not inspecting SSL/TLS encrypted traffic one would assume that every enterprise has already taken steps to enable this right? Well…not neccessarily. There are 2 main issues to overcome in order to implement this initiative, one is a technical hurdle, the other is a political hurdle.

The technical hurdle is essentially ensuring that your enterprise network and security architecture supports a traffic forwarding flow for both your on-prem and off-net roaming users which traverses an active inline SSL/TLS inspection device capable of scaling to the processing load imposed by 75-80% of your internet and SaaS bound traffic being encrypted. In an enterpise network and security architecture where all end user traffic, even remote users, flows through one or more egress security gateway stack choke points comprised of traditional hardware appliances the processing load imposed in doing SSL/TLS interception dramatically reduces the forwarding and processing capacity of those hardware appliances as evidenced in recent testing by NSS labs.

This is critical in that most enterprises would need to augment their existing security appliance processing and throughput capacity by at least 3x to enable comprehensive SSL/TLS inspection. This constitutes a signficant re-investment in legacy security appliance technology that doesn’t align with a more modern direct to cloud shift in their enterprise network and security architecture design

The second concern, and the primary topic of a recent whitepaper issued by Zscaler, is balancing the user privacy concerns of SSL/TLS inspection versus the threat risks of not inspecting a enterprise’s corporate device internet traffic.

Some of the key things to consider in the privacy vs risk assessment and subsequent move to proceed with an SSL/TLS inspection policy are as follows:

  • An organization can not effectively protect the end user and the corporate device from advanced threats without SSL/TLS interception in place
  • An organization will also struggle to prevent sensitive data exfiltration without SSL/TLS interception
  • Organizations should take the time to educate their end users that instituting an SSL/TLS inspection policy is a security safeguard and not a ‘big brother’ control
  • Organizations should inform employees as to the extent of what will and will not be inspected. This should be defined as part of an acceptable usage policy for internet use on corporate issued assets and this policy should be incorporated into their terms of employment agreements
  • Organizations should review this policy with in house legal counsel, external experts and any associated worker’s councils or unions as well as paying careful consideration to regional data safeguard compliance frameworks like GDPR
  • Organizations should take the neccessary steps to ensure appropriate safeguards are put in place for the processing and storing of the logs associated with decrypted transactions such as obfuscating usernames

For a more comprehensive review of how to navigate the security vs privacy concerns and implement a successful SSL/TLS inspection campaign take a look at the recent whitepaper that Zscaler has authored – https://www.zscaler.com/resources/white-papers/encryption-privacy-data-protection.pdf

Disclaimer: The views expressed here are my own and do not necessarily reflect the views of my employer Zscaler, Inc.

Is the future of security cloud based delivery?

It seems every single news article these days contains numerous vendors espousing how they could have prevented the latest malware threat.  Every software and hardware vendor seems to have a solution that could have stopped the WannaCry ransomeware outbreak and will protect from the new Petya variant and then the next variant and so on.

Naturally this piqued my curiousity and begged the question “If every vendor has a preventative solution then why do exploits like this continue to keep happening at such alarming rates and with such devastating financial impact?”

I recently spent some time talking with folks who are the forefront of this who helped me to understand that while preventative measures do exist they are traditionally very complicated to deploy at scale and are only as good as the coverage applied.  First off end system anti-virus software is utterly ineffective in keeping up with adaptive persistent threats in today’s landscape. You are just chasing your tail trying to keep up with the bad actors who actually test their exploits using your commercial anti-virus software.  Not saying don’t use it or bother to keep it updated, just pointing out that this is not going to save us.  Next, and really most important, is the reality that not every enterprise has the same security posture in every location that their users are accessing the internet and cloud based applications from.  For various reasons it’s very difficult to have the same level of advanced security applied in all locations.

In order to really grasp this you first have to look at the history of traditional enterprise WAN design and where the security perimeter got applied.  The legacy enterprise WAN was a Hub-and-Spoke topology designed to provide connectivity between branch offices (spokes) and the Corporate DC (Hub) because that’s where all the applications were running that you needed to access.  With the advent of a mobile workforce VPN concentrators also got added to allow connections to these Corporate DC Hub hosted applications from anywhere.  Internet access breakout was typically implemented at the Corporate DC Hub.  With this Hub-and-Spoke model all end user traffic was coming into the Corporate DC so this is effectively the ‘chokepoint’ where all of the security measures were implemented.

So what do the security measures actually look like in one of these Corporate DCs? Well it’s pretty complex as no single security appliance can handle all of the functions required. Attempting to deliver comprehensive security at scale required multiple disparate components from multiple vendors.  This means forcing your end user traffic through separate appliances for URL filtering, IDP/IPS, anti-malware, Data Loss Prevention (DLP), Next-gen FW, sandboxes and SSL inspection.  This complicated and expensive array of appliances all need to be managed, updated and capacity planned independently as they all scale differently depending on the type of heavy lifting that they are doing.  Then there is the need to interpret logs and threat data coming from all these devices in different formats in order to see whats happening and how effective these security measures really are.

The reality is that not every enterprise has or can deploy all of the above security measures at scale and make them available to every single end user.  Some don’t have a expensive WAN circuit from every one of their remote branch offices to the Corporate DC and instead have deployed at the branch a local subset of the security measures that are normally found in the Corporate DC.  Others may not be able to inspect all SSL encrypted traffic at scale creating a huge blindspot when looking for threats.

Enter WAN transformation…if you read the same tech trade rags that I do you may have heard about this thing called SD-WAN about a hundred times a day.  With ever increasing Enterprise adoption of cloud based SaaS applications the end destination of most user traffic is the cloud and not the Corporate DC Hub where the security perimeter was built.  Maintaining this Hub-and-Spoke model is costly from a WAN circuits perspective and highly inefficient leading to poor cloud based application performance.  This is leading to Enterprises wanting to implement local internet access breakouts at each branch to allow for lower cost yet higher performance access to critically important cloud based applications like Office 365.

So if most of the applications my end users access are in the cloud and I want to provide direct internet access to those applications for high performance how do I secure my traffic headed to directly to the internet?  As mentioned above stamping out a copy of the patch work of security appliances typically deployed in the Corporate DC security perimeter is cost prohibitive and an adminstrative nightmare.  Shortcuts will be taken, coverage won’t be comprehensive and as expected the security posture of the entire Enterprise is only as good as it’s weakest link.

What would be really useful is the ability to point all of my end user locations whether branch offices or my mobile workforce to a cloud based security on-ramp.  Hmm…isn’t this just another version of the hub-and-spoke design?  If done poorly then yeah, it would be.  To do this right you would need to have a cloud based security platform that has a global footprint of DCs colocated at IXPs (Internet Exchange Points) where all the major cloud providers interconnect as well.  This provides high availability as well as high performance in that each end user location is serviced by the closest cloud DC based security platform.  The security platform itself should efficiently scan ALL (including encrypted traffic) of my end user traffic through a comprehensive and optimized pipeline of security functions.  What this would essentially provide is an elastically scalable,  high performance w/ low latency,  advanced security platform that is always on with single pane of glass management and reporting and of course utility based pricing.  Basically all of the promises of the cloud, just now applied to advanced network security.  Adding new branch sites or mobile workforce users in this model and calculating future costs is incredibly simple.  You would no longer need to worry about procuring applicances, capacity planning, designing for HA, software updates, licensing or any of the other hurdles encountered in attempting to implement this in your own environment.

It sounds like unicorns and rainbows…however this cloud based security platform model already exists.  Zscaler with it’s Internet Access service appears to have pioneered the approach of going “all in” on completely cloud based delivery with other companies like Opaq adopting a cloud first security platform model as well.  Traditional security vendors like Palo Alto have come on board last week with Global Protect, their own version of a cloud based offering.  Juniper, through their Software Defined Secure Networking (SDSN) solution, is delivering sandboxing in the cloud via Sky ATP combined with automated mitigation and quarantining via their traditional sw or hw based on-prem security appliances and a growing ecosystem of multi-vendor switches. Besides aspects of their solutions being delivered from the cloud, what else is common in all these offerings is the ability to share detected threat data immediately across all of their customer base.

My goal was not to list every vendor or get into the merits of the specifics of each vendor’s implementation or who you should evaluate…lets leave that as an exploratory exercise for the Enterprise looking for a security solution to accomdate their WAN transformation projects and up level their existing security posture across the Enterprise.  Just wanted to acknowledge that moving advanced security measures to the cloud appears to be the future of Enterprise security and for really good reasons.

 

Disclaimer: The views expressed here are my own and do not necessarily reflect the views of my employer Juniper Networks

 

 

 

AWS Certified Solutions Architect Study Prep

After recently passing the AWS Certified Solutions Architect – Associate level exam several folks had asked what I did in preparation for the exam and whether I had any advice.  Figured I might as well just post this for others who may be interested.

By blocking out 2-3 hour chunks of focused time every few days I figure about 1.5 months is a safe ballpark figure on how long the prep work took between ~15 hours of video lectures and a 14 chapter certification guide + lab exercises.

One thing I do have to say about this particular industry certification is that its never been so easy to quickly gain access to the end product that you are learning and prepping to certify on.  I mean lets be honest, the ease with which you can quickly spin up resources to practice and tear them down when you are done all while minimizing the cost of certification prep is indeed a perfect illustration of the power and value of cloud computing.

A couple of suggestions:

1.) Go and open up an AWS account so you can get in and gets some real stick time.  You can utilize a lot of services in the free tier just to get your feet wet.  Remember, for the stuff you create that is not free, it will only need to exist for a few mins which results in minimal damage to the wallet as you are learning.

2.) Know the core services inside and out. You really have to understand things like VPC Networking constructs, S3/Glacier, RDS, CloudFront, Route53, Auto Scaling and ELB.

3.) Understand how to secure what YOU put into the cloud. Know the differences between what you need to manage the security of versus what AWS manages the security of.

4.) Understand AWS best practices as this is a large part of the exam. As a Solutions Architect you are expected to be able to design highly-available, scalable, fault tolerant and cost-efficient systems. When you take the exam pay very close attention to these themes as you answer the questions. The right implementation choice answer absolutely depends on the theme mentioned.

5.) If you do get the certification guide spend a solid day before the exam reviewing the end of chapter summaries of the key concepts for the exam. If it takes you as long as it did me to get through all the material (while still managing my day job and being a sports parent) then a quick refresher will certainly help.

The following are the particular test prep resources that I decided to use:

AWS Certified Solutions Architect Official Study Guide: Associate Exam

A few people left crappy reviews for the book, but I found it to be a very good in depth look at AWS in general. For someone who is looking for some organized guidance this provides a solid outline for what concepts you will need to know for the exam. There are quizzes at the end of each chapter and several chapters have hands on exercises at the end. If you decide not to do all of the available exercises in the book I would suggest you at least do the exercises at the end of Chapter 14.  Ch 14 is pretty critical as it ties together all of AWS’s recommended best practices which are a large part of the exam.

Pluralsight Courses

Architecting Highly Available Systems on AWS
AWS Security Fundamentals
AWS VPC Operations
AWS Certified SysOps Administrator – Associate