Taking the first steps towards SASE Cloud Security

In my opinion, the first question that anyone considering Cloud Security should ask themselves is ‘What do we define as cloud migration and what do we need to secure?’

I say this because many people consider ‘Cloud Migration’ to solely involve moving their on premise resources to a Cloud Provider i.e. moving web servers from a physical data centre into AWS.

While the definition here is technically correct it is far too limiting, as one could also consider moving to a cloud based app solution to replace an existing on premise solution could also be considered to be Cloud Migration.

Lastly, with the changing face of the internet, adjusting mindsets from traditional web usage to cloud app usage could also be factored into ‘Cloud Migration’ when adjusting security principles within an organisation.

As a result, when it comes to Cloud Security, considering all facets of the Cloud and developing a documented ‘Cloud Security Baseline’ is key in the same way that organisations have developed internal baselines for IT Security, Web Usage, etc.

A good place to start in developing this baseline lies in reviewing the Gartner Secure Access Service Edge (SASE) ideology.

SD-WAN — Software Defined Networking
SWG — Secure Web Gateway
CASB — Cloud Access Service Broker
ZTNA — Zero Trust Network Access
FWaaS — Firewall as a Service

It’s overall guidance centres on ‘Any App, Any Device, Any User, Anywhere’ in that with the changing face of the internet and working methods, security principles have to adjust to ensure all eventualities for attack, threats or data leakage have to be accounted for.

To summarise this, in relation to Cloud App security, consider these true life examples from my time with a previous employer.

It was a Thursday and I was due to fly to Abu Dhabi from the UK to visit my brother. I was working from home and I logged off my laptop at 4pm. I would never take my work devices on personal trips and while at the airport I remembered that I had not sent an important email to a client. So, once I got to Abu Dhabi, I used my brother’s laptop to log into O365 Sharepoint, I opened O365 Outlook through this and sent the email and all was well. Or was it?

In this example, how did my employer at the time know that it was me logging into O365? I was logging into the app from the opposite side of the world within the same 24 hour period. I was using a non sanctioned work device that could have been compromised. All that prevented me from logging in was a simple username and password field on a public facing O365 page, there was no Multi Factor Authentication in use.

This O365 portal also gave me access to a variety of other apps such as Sharepoint and many published apps within — this in turn also allowed me to download vast swathes of corporate information from a variety of data stores as well as uploading malware to the same buckets. So if this wasn’t me, what damage could I have done if I was a nefarious actor? Lastly, at no time did anyone ever approach me to enquire about what I did, so it has to be assumed they either had no visibility of such actions or no alerting in place when it did. Now scale this out to the 80,000 employees that worked for them, how many are doing the same thing

Under the SASE guidance, a SASE focused solution such as Netskope Next Generation Secure Web Gateway could have mitigated the risks involved in the above by way of:

• Visibility — Netskope when integrated with O365 SharePoint and Outlook with their API integration, would have provided my employer with full visibility of my actions.
• User Behaviour Analytics — The strange behaviour I showed in logging in from the differing geographical locations would be flagged as an anomaly within the solution and could be alerted upon.
• Reverse Proxy — With Netskope’s Reverse Proxy, controls could have been implemented so that extra security rules could be implemented even when I was logging in with a non corporate device.
• Control — With Netskope’s API integration coupled with granular policy creation, various rulesets could have been defined to allow, limit, block me from doing certain things based on the criteria of my actions such as who I was, where I was logging in from, what machine I was using, etc.
• SIEM Integration — Netskope could have been integrated with a tool such as Splunk to pass events from my actions to a real time alerting process and allow for investigation as to why I did what I did to confirm it was me, etc.

The second example involves me again working from home. I had a VPN on the work laptop that I used to log onto back end corporate resources that could not be accessed via O365 such as payroll/expenses/timekeeping systems and RDP to a few key servers. When on the VPN two things of note would happen. The first is that I could access way more than I needed for my role, such as getting to datastores that were irrelevant to me and also RDP/SSH to servers that were not required. My web controls would also change, in that as my web traffic was now being hairpinned into corporate and now out the way, a number of sites would be blocked for me, however if I disabled the VPN which is how I worked for the majority of time, I had unrestricted access to the Internet.

In this example, we have me as a user being able to access resources when on the VPN that I should not have access to based on my role hence Zero Trust Network Access is not being implemented. Secondly, as I was able to have direct unrestricted access to the internet when off the VPN, it is apparent they were not using a cloud based web security tool.

This opens up key issues such as my ability to download sensitive info when on the VPN and then share this with no controls when off the VPN, as well as me being able to download malware (if not caught by the endpoint protection they must have relied on) and then have the ability to propagate this when on the VPN. Lastly, when you consider cost, I have a license for the VPN tool, a license for the endpoint protection they were using, likely needless user or bandwidth license on the on premise SWG.

Again, a tool like Netskope Next Generation Secure Web Gateway would assist with this via the following:

Netskope Private Access — From my work laptop in conjunction with a Netskope client / Private Access configuration I could have accessed the corporate private apps and resources (via RDP, SSH, etc) and be limited to only access what I need hence meeting the Zero Trust Network Access element of SASE.

Cloud Based Web Protection — With a Netskope client on my work laptop, it would not matter if I was on the VPN or not, all my web traffic and cloud app usage traffic could be passing through a cloud tenant and being inspected regardless of the network I was on, or where I was situated geographically. This allows for granular controls that are always on, regardless of the network I am on or geographical location.

DLP — Via the client and tenant, DLP controls could be implemented on the data I am sharing that limits type, content, sharing method again regardless of the network I am on or geographical location.

Threat Protection — Via the Netskope client & tenant, threats would be detected while in flight before they ever reach my machine again regardless of network I am on or geographical location.

Cost — A centralised solution such as Netskope would allow for less licenses / 3rd party solutions required to provide these aspects of SASE security and also allows for less support resources due to being controlled via a single pane of glass as opposed to spread out over various technologies.

The above were two examples of failures in SASE, though when looking at ‘Cloud Security’ when it comes to the ‘Any App, Any Device, Any User, Anywhere’ it should be stressed that while Netskope has been provided as an example solution above, no single tool that is available today will provide full SASE security, overlap will most definitely exist in the technologies required.

Some guidance could be followed in realising overall Cloud Security in relation to SASE and web / cloud app usage which could also be used for other SASE topics:

1. Don’t rush it — I have seen a fair few cases now where organisations have adopted a technology without proper investigation or planning. This could involve adopting a zero trust policy in relation to web usage and essentially blocking a number of key resources to employees once policies are implemented. Instead, define a clear strategy in the Cloud Security Baseline and with this, get as much visibility of the behaviour users / apps within the area you are currently focusing on. With this visibility, review and understand what users are up to, what apps are they using, which are ‘sanctioned’ i.e. paid for by the organisation, which are allowed and which are definitely not allowed. Now define your policies based on the guidance of the baseline and think of where exceptions to this may be required. Also have a clear strategy defined and regular reviews of visibility so as not to be overwhelmed when a solution is deployed — remember that modern web security solutions can understand the language of the internet better while also offering SSL inspection, hence legacy tools may not have provided you the full picture of web / cloud app usage within the organisation.
2. Remember ‘Any App, Any Device, Any User, Anywhere’ and place it at the heart of the baseline — When defining policies and making decisions, consider this key thought. Redefine your perimeter to encompass remote working, the ability to reach any app, how users authenticate to the app, if a public facing authentication screen what controls could be applied to it, if a private app what zero trust controls could be applied to limit who can reach it, what devices are users using.
3. Consider the Hourglass Methodology for policies and clearly define a naming convention in the Cloud Security Baseline — The hourglass methodology involves structuring policies to make them easy to maintain and define. Consider these two policies that would likely be created for every organisation:

Threat Protection — Block all Malware — All Users
Cloud Storage — Block Uploads to Unsanctioned Cloud Storage Apps — All Users

Now an individual marketing team of 10 users needs access to the unsanctioned Cloud Storage App Dropbox. So based on the hierarchy of policies, we place them like this:

Threat Protection — Malware — Block — All Users
Cloud Storage — Dropbox — Allow Upload — Marketing
Cloud Storage — Unsanctioned Cloud Storage Apps — Block Upload — All Users

Based on our users we have a widespread threat protection policy that affects everyone, an allow policy for Dropbox uploads for Marketing only, then a widespread policy cloud storage block policy for all users hence wide, narrow, wide which is an hourglass shape. The descriptions above are clear as to what each policy is doing and a naming convention could easily be adopted to keep these short.

Clearly defining policies and exceptions as part of the baseline is key, while also keeping in mind making the solution easy to understand.

Clearly Define Exception & User Education Process — Within the documented baseline, have a clear process for exceptions as you begin to roll out and don’t just whitelist for convenience. It is common that there will be push back whenever users have to change their way of working so as policies are rolled out, there may be complaints that unsanctioned / risky apps are now blocked when teams used to use them for convenience or to bypass controls that already existed, but they got away with due to lack of visibility from legacy tools.

A tool like Netskope allows for customising user education notifications in alerts such as informing end users how to use a sanctioned app like OneDrive to share a file as opposed to using a risky app like We Transfer, which would not only keep the user educated but prevent them in just seeking another risky app to send the file as is common.

Clearly defining the Security Baseline and Exception Process also allows end users and teams to follow a set process to request exemptions to the baseline such as allowing use of an app while also giving a clear direction on how to investigate the risk of allowing the exception as opposed to it being allowed based on who makes the most noise.

These were just some takeaways in what to consider when seeking to fully realise Cloud Security.