Posted on

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.

Posted on

Adapting to evolving Ransomware extortion tactics

Effective ransomware controls will now have to go past well maintained backup programs and SSL/TLS inspection backed zero-day threat detection to include comprehensive Data Loss Prevention programs.

In the beginning the cybercriminals launching ransomware campaigns simply demanded infected organizations pay a ransom in cryptocurrency in order to get their encrypted files back

As part of a defense strategy against the impacts of a potential ransomware outbreak, organizations began backing up critical assets in order to be able to more quickly mitigate the impact and resume business critical operations in the event that they were compromised by such an attack. In addition to the obvious benefit of protecting business continuity this also effectively helps mitigate the need to pay the campaign’s ransom.

This tightening of business continuity/disaster recovery plans to lessen the impact of ransomware infections has in turn prompted  ransomware campaign originators to counter by adapting their extortion plans to include new impact elements.

The first shift was noted in mid-December of 2019 via a ‘naming and shaming’ campaign whereby the authors of the Maze ransomware strain began posting a list of the companies who fell victim to their ransomware, yet refused to pay the actual ransom.

Publicly shaming victims was apparently just the beginning. Within less than a month, the Maze Ransomware campaign began to demand that the organization’s actual encrypted data (which they had successfully exfiltrated) would be exposed publicly.  The most recent example being US cable and wire manufacturer Southwire, which was threatened with exfiltration of their data if they did not pay a $6 million ransom. 

In some cases, this exfiltration of potentially sensitive corporate data may be more costly and have longer lasting effects than the short term interruption to critical business functions posed by the temporary lack of access to the ransomware encrypted data itself

To combat and help mitigate this latest round of extortion tactics from ransomware campaigns an enterprise should consider looking at:

  • This should go without saying, but as with any cyber security initiative end user education around not clicking on suspicious links and exhibiting more caution with email attachments is critical
  • Well maintained backup programs of business critical systems and data
  • SSL/TLS decryption to aid zero day threat detection controls like active inline Sandbox solutions applied to both on-prem and roaming user device traffic
  • Implementing caution or coaching pages within your web proxy service that informs an end user that they are about to download a certain file type from a site that falls into a category deemed risky by their organization
  • Consider replacing legacy VPN technology with a more secure zero trust approach (https://www.zscaler.com/blogs/research/remote-access-vpns-have-ransomware-their-hands?utm_source=linkedin&utm_medium=social&utm_campaign=linkedin-remote-access-vpns-have-ransomware-their-hands-blog-2019)
  • A comprehensive Data Loss Prevention program that covers both on-net and off-net users while inspecting SSL/TLS encrypted outbound data 
  • Since no set of security controls is ever infallible, an appropriate amount of cyber security insurance coverage may prove to be a helpful additional compensating control

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

Posted on

Visualizing A Zero Trust Architecture

It’s more than just re-branding VPNs and NGFWs

Photo by Petter Lagson on Unsplash

Enterprise Network and Security Architects are faced with sifting through the myriad of Cyber Security Vendors all espousing their ‘Zero Trust’ offerings. Before we get into how to break down each vendor’s offering lets first start by identifying some of the key principles and benefits of a Zero Trust architecture.

  • Establish user identity and authorization prior to access
  • Access to private applications, not access to the network – (no need for VPN)
  • Since no network access is granted, the focus can shift to application level segmentation as opposed to network level segmentation
  • No inbound listeners means applications are invisible to unauthorized users, you can’t attempt to hack or brute force what you can not even see

So how should one go about visualizing what a security vendor offering actually looks like in order to see if a vendor solution really walks the zero trust walk? I’m going to introduce two scenarios which should help easily draw the distinctions between a re-branded VPN solution and a real zero trust offering

Traditional VPN

Lets picture a scenario where your Security Vendor Sales Rep comes to visit you. He or she checks in at the front reception desk, is given a badge and then escorted to a conference room. On the way to the conference room they can easily survey how many floors are in the building, where there are individual offices, media/printing rooms, open floor plan seating areas, telecom equipment closets and maybe even where the corporate Data Center server room is. If your vendor rep leaves the conference room they could hypothetically walk up and down the hall where they can jiggle the door handles of any office door they see, scan the visible content on whiteboards or on top of desks in the open floor plan seating areas for sensitive information and strike up casual conversations with anyone in any area they can manage to roam through. This is akin to level of trust provided when giving network level access to a user via a traditional VPN. Instead of the fictitious Sales Rep, imagine that this was a malware infected endpoint brought onto the network by one of your remote employees, a contractor or other 3rd party.

Zero Trust

In this model the same Security Vendor Sales Rep visits and checks in at the front desk to get their badge. This time the Rep only sees one door, the door to the conference room. There are no floors, no visbile office doors, media/printing rooms, open seating areas or telecom equipment closet doors. Only the door to the conference room appears as this is the only thing that your Rep is authorized to see or access. There is no hallway to walk down, no office doors to attempt to pry open and no visibility of the internal environment whatsoever. This is more like what access via a zero trust solution should look like.

To take this a bit further, a security vendor might still say that they can support the objectives of the Zero Trust scenario described above. What are some key red flags to look out for to ensure that this isn’t just a rebranded VPN or NGFW solution?

If a prospective security vendor says they meet the objectives of a Zero Trust implementation, but uses language like ‘perimeter’, ‘micro-perimeter’, ‘use your existing NGFW as a network segmentation gateway’, ‘verify and never trust anything ON your network’, or ‘there is no need to rip and replace your existing network appliances’ be very wary that this is likely just a perpetuation of a previous remote access model and not truly architecting for Zero Trust.

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