Microsoft Workplace Join Part 1: The Security Timebomb

By Chris Higgins, Technical Support Engineer, Bitglass

timebomb countdown to Workplace Join infosecurity riskIt’s no secret that enterprise users wish to access work data and applications from a mix of both corporate and personal devices. In order to help facilitate this mix of devices, Microsoft has introduced a new feature called Workplace Join into Azure Active Directory, Microsoft’s cloud-based directory and identity service. While the intent of streamlining user access to work-related data is helpful, the delivery of this feature has resulted in a large security gap—one that can’t easily be disabled. This is another example of an app vendor optimizing for user experience ahead of appropriate controls and protections—demonstrating the basis for the cloud app shared responsibility model and the need for third-party security solutions like cloud access security brokers (CASBs).

According to Microsoft, “…by using Workplace Join, information workers can join their personal devices with their company’s workplace computers to access company resources and services. When you join your personal device to your workplace, it becomes a known device and provides seamless second factor authentication and Single Sign-On to workplace resources and applications.”

How does it work?

When a user links their Windows machine to “Access Work or School,” the machine is registered in Azure AD, and a master OAuth token is created for use between all Microsoft client applications as well as Edge/I.E. browsers. Subsequent login attempts to any Office resource will cause the application to gather an access token and log in the user without ever prompting for credentials. The ideology behind this process is that logging in to Windows is enough to identify a user and give them unrestricted access to all Office 365 resources.

In plain language, this means that once you login to Office 365 from any device (Grandma’s PC, hotel kiosks, etc.), you, and anyone accessing that device, are logged in to Office 365 automatically moving forward.

Why is this such a big security issue?

Workplace Join undoes all of your organization’s hard work establishing strong identity processes and procedures—all so that an employee can access corporate data from Grandma’s PC (without entering credentials). Since Grandma only has three grandkids and one cat, it likely won’t take a sophisticated robot to guess her password—exposing corporate data to anyone who accesses her machine. Making matters worse, user accounts on Windows 10 don’t even require passwords, making it even easier for data to be exfiltrated from such unmanaged devices.

Workplace Join is enabled by default for all O365 tenants. Want to turn it off? You’ll have to wait for the next blog post to sort that out.

In the meantime, download the Definitive Guide to CASBs to learn how cloud access security brokers can help secure your sensitive data.

Cloud Security Trailing Cloud App Adoption in 2018

By Jacob Serpa, Product Marketing Manager, Bitglass

In recent years, the cloud has attracted countless organizations with its promises of increased productivity, improved collaboration, and decreased IT overhead. As more and more companies migrate, more and more cloud-based tools arise.

In its fourth cloud adoption report, Bitglass reveals the state of cloud in 2018. Unsurprisingly, organizations are adopting more cloud-based solutions than ever before. However, their use of key cloud security tools is lacking. Read on to learn more.

The Single Sign-On Problem

Single sign-on (SSO) is a basic, but critical security tool that authenticates users across cloud applications by requiring them to sign in to a single portal. Unfortunately, a mere 25 percent of organizations are using an SSO solution today. When compared to the 81 percent of companies that are using the cloud, it becomes readily apparent that there is a disparity between cloud usage and cloud security usage. This is a big problem.

The Threat of Data Leakage

While using the cloud is not inherently more risky than the traditional method of conducting business, it does lead to different threats that must be addressed in appropriate fashions. As adoption of cloud-based tools continues to grow, organizations must deploy cloud-first security solutions in order to defend against modern-day threats. While SSO is one such tool that is currently underutilized, other relevant security capabilities include shadow IT discoverydata loss prevention (DLP), contextual access control, cloud encryptionmalware detection, and more. Failure to use these tools can prove fatal to any enterprise in the cloud.

Microsoft Office 365 vs. Google’s G Suite

Office 365 and G Suite are the leading cloud productivity suites. They each offer a variety of tools that can help organizations improve their operations. Since Bitglass’ 2016 report, Office 365 has been deployed more frequently than G Suite. Interestingly, this year, O365 has extended its lead considerably. While roughly 56 percent of organizations now use Microsoft’s offering, about 25 percent are using Google’s. The fact that Office 365 has achieved more than two times as many deployments as G Suite highlights Microsoft’s success in positioning its product as the solution of choice for the enterprise.

The Rise of AWS

Through infrastructure as a service (IaaS), organizations are able to avoid making massive investments in IT infrastructure. Instead, they can leverage IaaS providers like Microsoft, Amazon, and Google in order to achieve low-cost, scalable infrastructure. In this year’s cloud adoption report, every analyzed industry exhibited adoption of Amazon Web Services (AWS), the leading IaaS solution. While the technology vertical led the way at 21.5 percent adoption, 13.8 percent of all organizations were shown to use AWS.

To gain more information about the state of cloud in 2018, download Bitglass’ report, Cloud Adoption: 2018 War.

Bitglass Security Spotlight: Twitter, PyRoMine, & Stresspaint

By Jacob Serpa, Product Marketing Manager, Bitglass

Here are the top cybersecurity stories of recent weeks:

—Twitter exposes user credentials in plaintext
—PyRoMine mines Monero and disables security
—Stresspaint malware hunts Facebook credentials
—MassMiner malware mines cryptocurrency
—Access Group Education Lending breached

Twitter exposes user credentials in plaintext

Despite the fact that Twitter doesn’t store or display users’ credentials in plaintext, the social media company recently had a security mishap. Passwords were stored in internal logs before they were successfully obfuscated, exposing them to employees in plaintext. While the information wasn’t made viewable to outside parties, it’s still a cause for concern for Twitter’s users.

PyRoMine mines Monero and disables security

New malware, PyRoMine, leverages a host of previously disparate capabilities featured in other strains of malware. For example, it uses NSA exploits while mining Monero, a cryptocurrency. Malware is continuing to grow more sophisticated, compelling organizations to adopt advanced anti-malware solutions.

Stresspaint malware hunts Facebook credentials

Disguised as a stress-relieving paint program, Stresspaint is a piece of malware that is attacking users in an attempt to gather their Facebook credentials. In particular, the malware is targeting influential users – those who manage Facebook pages or have numerous friends and followers. It is primarily distributed through emails and messages on Facebook.

MassMiner malware mines cryptocurrency

MassMiner is the latest in a slew of malware strains that engage in malicious cryptomining. This threat seeks to take advantage of known vulnerabilities in order to commandeer web servers and mine Monero – which continues to be a common target in malicious cryptomining.

Access Group Education Lending breached

Unfortunately for those who have used the organization’s services for their student loans, Access Group Education Lending has been breached. Nearly 17,000 borrowers had their information exposed when a loan processing vendor working for the group shared their information with an unauthorized, unknown company.

Fortunately for the enterprise, cloud access security brokers (CASBs) can defend against zero-day malware and countless other threats. To learn more, download the Zero-Day Solution Brief.

How ChromeOS Dramatically Simplifies Enterprise Security

By Rich Campagna, Chief Marketing Officer, Bitglass

Google’s Chromebooks have enjoyed significant adoption in education, but have seen very little interest in the enterprise until recently. According to Gartner’s Peter Firstbrook in Securing Chromebooks in the Enterprise (6 March 2018), a survey of more than 700 respondents showed that nearly half of organizations will definitely purchase or probably will purchase Chromebooks by EOY 2017. And Google has started developing an impressive list of case studies, including WhirlpoolNetflixPinterestthe Better Business Bureau, and more.

And why wouldn’t this trend continue? As the enterprise adopts cloud en masse, more and more applications are available anywhere through a browser – obviating the need for a full OS running legacy applications. Additionally, Chromebooks can represent a large cost savings – not only in terms of a lower up-front cost of hardware, but lower ongoing maintenance and helpdesk costs as well.

With this shift comes a very different approach to security. Since Chrome OS is hardened and locked down, the need to secure the endpoint diminishes, potentially saving a lot of time and money. At the same time, the primary storage mechanism shifts from the device to the cloud, meaning that the need to secure data in cloud applications, like G Suite, with a Cloud Access Security Broker (CASB) becomes paramount. Fortunately, the CASB market has matured substantially in recent years, and is now widely viewed as “ready for primetime.”

Overall, the outlook for Chromebooks in the enterprise is positive, with a very real possibility of dramatically simplifying security. Now, instead of patching and protecting thousands of laptops, the focus shift towards protecting data in a relatively small number of cloud applications. Quite the improvement!

Majority of Australian Data Breaches Caused by Human Error

By Rich Campagna, Chief Marketing Officer, Bitglass

It wasn’t long ago that the first breach under the Office of the Australian Information Commissioner’s (OAIC) Privacy Amendment Bill was made public. Now, OAIC is back with their first Quarterly Statistics Report of Notifiable Data Breaches. While the report doesn’t offer much in the way of detail, it does highlight a couple of interesting trends.

The statistic that jumps out most is that of the 63 reported breaches in this first (partial) quarter, the majority (51%) were the result of “human error.” According to OAIC, “human error may include inadvertent disclosures, such as by sending a document containing personal information to the incorrect recipient.” Sounds like too few Australian organizations are controlling things like external sharing, even though sharing (and many other potentially risky activities) can be controlled quite easily with a Cloud Access Security Broker (CASB).

human error leading cause of breaches

The report also breaks down number of breaches by industry. Health service provides had the misfortune of leading the charge in this initial quarter, representing nearly a quarter of breaches. Healthcare organizations have a particularly difficult task with data protection. On one hand, they have a very mobile workforce that requires immediate access to data, from anywhere and from any device. On the other hand, medical records are some of the most valuable sources of personal data, including not only medical history, but personal information, financial information, and more.

healthcare most breaches

Fortunately, this first quarter didn’t include any large, “mega-breaches,” as more than half involved the personal information of fewer than 10 individuals, and 73% involving fewer than 100 individuals.

most breaches small

It will be interesting to see whether schemes like this, and the upcoming GDPR, have an impact on overall data protection outcomes.

Bitglass Security Spotlight: LinkedIn, Vector, and AWS

By Jacob Serpa, Product Marketing Manager, Bitglass

Here are the top cybersecurity stories of recent weeks:

—LinkedIn security gap exposes users’ data
—Vector app reveals customers’ information
—AWS misconfiguration makes LocalBlox user information public
—New malware steals data via power lines
—Banking apps deemed the most unsecured

LinkedIn security gap exposes users’ data
LinkedIn’s AutoFill functionality was recently discovered to be easily exploitable. The feature allows users to have fields on other websites automatically populated with information from their LinkedIn accounts (for rapid registrations and logins, for example). Researchers quickly realized that this could be exploited by malicious websites that initiate AutoFill, regardless of where visitors click, in order to steal information.

Vector app reveals customers’ information
New Zealand energy company, Vector, developed an application designed to update users on the status of their power; for example, by providing estimates on when power might return during outages. Unfortunately, the app didn’t provide the functionality that the company originally intended. Additionally, it made all of its users’ information (including home address) accessible to anyone who downloaded the app.

AWS misconfiguration makes LocalBlox user information public
Another AWS misconfiguration has exposed the personal information of various individuals – 48 million of them. LocalBlox, which gathers information from public online profiles, was recently found to be leaking Twitter, Facebook, and LinkedIn information through an unsecured AWS S3 bucket. Leaked information included email addresses, job histories, and even IP addresses in some cases.

New malware steals data via powerlines
PowerHammer, a new type of malware, can steal data in a variety of complex, frightening ways. For example, through computers’ power cables. To learn more about the ins and outs of PowerHammer, click here.

Banking apps deemed the most unsecured
A recent study found that banking applications are typically the most vulnerable type of cloud app. Despite the fact that these services are used by hundreds of millions of people, they consistently hold security flaws that leave them open to the advances of hackers.

Learn more about cloud access security brokers (CASBs) and how they can help you secure data in our cloud-first world with the Definitive Guide to CASBs.

Orbitz: Why You Can’t Secure Data in the Dark

By Jacob Serpa, Product Marketing Manager, Bitglass

On March 1, 2018, Orbitz discovered that a malicious party may have stolen information from one of its legacy platforms. The compromised platform housed Orbitz customer information such as mailing addresses, phone numbers, email addresses, and full names, as well as details about nearly 900,000 payment cards.

This breach highlights the struggle that many companies face on a day-to-day basis.

Stated simply, organizations cannot afford to secure their data in the dark. Lacking comprehensive visibility makes it nearly impossible to protect sensitive information – you cannot defend against threats that you can’t see. Where enterprises fail to maintain automatic, thorough logging of all events involving corporate data, breaches are sure to follow.

The fact that Orbitz was unable to confirm whether a hacker had stolen information is evidence that it lacked adequate visibility. If the company had tools that provided said visibility, then identifying a breach would have been fairly simple. Additionally, with real-time capabilities, the company could have identified the potential breach the moment that it occurred (somewhere between October and December of 2017), rather than months after the fact.

The speed at which hackers, malware, and malicious insiders can exfiltrate data demands real-time security and comprehensive visibility. Incomplete, reactive security tools are incapable of providing protection in today’s rapid, cloud-first world. Only a cloud access security brokers (CASB) can provide what the modern enterprise needs.

One Simple Way to Avoid 57 Percent of Breaches

By Rich Campagna, Chief Marketing Officer, Bitglass

I recently caught wind of a survey of 3000 cybersecurity professionals commissioned by ServiceNow and Ponemon. One of the first statistics that jumped out at me?

“57% of data breach victims said they were breached due to an unpatched known vulnerability.”

That’s bananas!

And this massive number of breaches due to lack of vulnerability patching comes despite respondent companies spending 321 hours per week – or approximately 8 full time employees vulnerability response process.

So, an average of eight people chasing a manual process, and they’re always behind, resulting in the majority of data breaches coming as the result of KNOWN vulnerabilities for which THERE IS A FIX?

What’s the average enterprise to do?

Move to the cloud!
With cloud apps, you’re not only outsourcing the application itself, you’re outsourcing many of the mundane, manual tasks like patching, that your organization never quite keeps up on. Microsoft spends more than $1 billion per year on security. Do you think you’d get patching under control if you had that kind of coin dedicated to security? Of course you would.

The fact remains that the major cloud vendors are doing a pretty good job of protecting their apps and their infrastructure against widespread, service impacting security events (such as unpatched vulnerabilities being exploited).

The enterprise cloud security and compliance challenge is not to take an inherently insecure app and make it secure. Rather, it’s to secure the usage of those cloud applications. That’s where Cloud Access Security Brokers come into play.

The Case for CASB: Healthcare

By Rich Campagna, Chief Marketing Officer, Bitglass

Over the past couple of years, Cloud Access Security Brokers (CASBs) have gone from a nascent, barely known technology to the de facto standard for secure public cloud enablement in every enterprise vertical. Early on, it’s tough to draw patterns across industries, but once you have a few hundred enterprise deployments under your belt, it becomes quite interesting to observe how organizations in one industry use the same technology (CASBs) in an entirely different way than organizations in another industry.

With that in mind, I’m creating a series of blog posts to cover some of the key differences in CASB usage that we see across industries. First up? Healthcare.

Like most industries, healthcare organizations are adopting cloud applications at a very rapid clip. Most start with major SaaS applications (like Office 365), but once they get a handling on security and compliance, start expanding their cloud footprint, with even applications like Electronic Medical Record (EMR) systems moving to the cloud. Across this massive change, the organization must still comply with HIPAA – no small feat.

So what are the big security and compliance drivers that lead healthcare organizations to adopt a CASB?

  • Protecting PHI and Complying with HIPAA
    This one is quite obvious, but this post wouldn’t be complete without mentioning it. Protected Health Information (PHI) makes its way to cloud applications, and not just EMR and other clinical systems designed to store PHI. Email and files, via productivity suites like Office 365, typically contain PHI as well. The organization’s cloud footprint must have mechanisms in place to identify PHI, to eliminate access by unauthorized individuals, and to control the flow of PHI out of cloud applications. Healthcare organizations use either keyword and regular expression-based DLP policies, or increasingly, exact data match capabilities where electronic health record (EHR) data is exported from an application like Epic, tokenized, and uploaded to a CASB DLP engine to provide matching on patient data with much less risk of false positives.
  • Protecting Data That Leaves the Cloud
    Healthcare organizations have gotten comfortable with the fact that major cloud vendors are investing heavily in security, and doing a pretty good job of protecting data-at-rest, so their primary objective is to protect data once it leaves the cloud, via mechanisms such as BYOD and external sharing.
    Note that this is in contrast to other industries, like financial services, where a big driver is to keep sensitive data from getting to the cloud.
  • Protecting Data on BYO Devices
    Most healthcare workers are mobile, requiring access from both home and from the bedside, alike. Complicating matters is the fact that clinical staff are not typically employees of the organization. This means that IT’s ability to force management control over personal mobile devices is even more difficult than with employees. It’s impossible if that user’s device is already controlled by another organization’s Enterprise Mobility Management/Mobile Device Management solution.
    Regardless of these challenges, the organization must continue to protect PHI and other sensitive data that is synchronized or downloaded to both managed and unmanaged devices.

In summary, healthcare organizations are adopting cloud applications, and their leading objective is to protect patient data as it leaves the cloud – with the top concerns being BYOD and external sharing.

Australia’s First OAIC Breach Forecasts Grim GDPR Outcome

By Rich Campagna, Chief Marketing Officer, Bitglass

The first breach under the Office of the Australian Information Commissioner’s (OAIC) Privacy Amendment Bill was made public on March 16. While this breach means bad press for the offending party, shipping company Svitzer Australia, more frightening is the grim outcome it forecasts for organizations subject to GDPR regulations, which go into effect on May 25, 2018.

In the Svitzer case, 60,000 emails containing sensitive personal information on more than 400 employees were “auto-forwarded” to external accounts, a not uncommon way for employees to “get access” to their work emails from outside of the office. While the details of why these auto-forwarding rules were set up, and whether the intent was malicious or benign, in many cases, the objective is to avoid IT management of the user’s device while still gaining access to sensitive data.

Another common scheme to bypass unwanted IT controls is to set up sharing of one’s cloud file sharing drive to a personal email account. Both of these challenges are easily solved with Cloud Access Security Brokers (CASBs), which can secure employee devices without taking management control (helping to avoid auto-forwarding outcomes), and control the flow of data into/out-of cloud apps (including external sharing control).

The outcome in this case is bad press for Svitzer, causing loss of goodwill and perhaps some customers. It could have been worse, however. Under the Australian scheme, when OAIC if notified of the breach, which Svitzer has apparently done, the breach is made public but there are no direct financial penalties. If Svitzer hadn’t notified, they would have been subject to fines of “up to $1.8 million.” Penalties initially start with public apologies and compensation payments to the victims, with continued examples of non-notification ratcheting up fines to a maximum of $1.8 million.

What does all of this have to do with GDPR? Simple. With the upcoming GDPR enforcement deadline, some organizations are scrambling to reach compliance, while others are taking a wait-and-see approach. Once we pass the deadline, there WILL be companies with similarly simple issues that have a breach. The difference is in the penalties with GDPR. Rather than starting with simple fixes such as apologies and victim compensation, GDPR comes with severe penalties of up to €20 million or 4% of annual revenue, whichever is greater. Depending on the size and health of the organization, penalties like this could be terminal.

My prediction? We’ll quickly see the first examples, like Svitzer, and before the end of 2018, we’ll see the first bankruptcy as a result of GDPR fines and loss of business.

Zero-Day in the Cloud – Say It Ain’t So

By Steve Armstrong, Regional Sales Director, Bitglass

Zero-day vulnerabilities are computer or software security gaps that are unknown to the public – particularly to parties who would like to close said gaps, like the vendors of vulnerable software.

To many in the infosec community, the term “zero-day” is synonymous with the patching or updating of systems. Take, for example, the world of anti-malware vendors. There are those whose solutions utilize signatures or hashes to defend against threats. Their products ingest a piece of malware, run it through various systems, perhaps have a human analyze the file, and then write a signature. This is then pushed to their subscribers’ end points in order to update systems and defend them against that particular piece of malware. The goal is to get the update to systems before there is an infection (sadly, updates are not always timely). On the other hand, there are some vendors who reject this traditional, reactive method. Instead, they use artificial intelligence to solve the problem in real time.

When assessing threats, it comes down to what you don’t know. It can be difficult to respond to unknown threats until they strike. As they say, it’s not what you know that kills you. This is also true in the SaaS space. The analogy is simple, new applications appear daily – some good, some bad – and even the good ones can have unknown data leakage paths. Treat them as a threat.

In order to respond to unknown cloud applications, you can do one of two things.

First, the standard practice from CASBs (cloud access security brokers) is to find the new application, work to understand the originating organization, analyze the application, identify the data leakage paths, gain an understanding of the controls, and then write a signature. This is all done by massive teams of people who have limited capacities to work – very much like the inefficient, signature-based anti-malware vendors. It can take days, weeks, or even months until an application signature is added to a support catalog. For organizations who want to protect their data, this is simply not good enough.

Option two is to utilize artificial intelligence and respond to new applications in the same manner as advanced anti-malware solutions. This route entails analyzing the application, identifying the data leakage paths, designing the control, and securing the application automatically in real time.

New, unknown applications should be responded to in the same fashion that an enterprise would respond to any other threat. Rather than waiting days, weeks, or months, they should be addressed immediately.

 

Cloud App Encryption and CASB

By Kyle Watson, Partner/Information Security, Cedrus Digital

Many organizations are implementing Cloud Access Security Broker (CASB) technology to protect critical corporate data stored within cloud apps. Amongst many other preventative and detective controls, a key feature of CASBs is the ability to encrypt data stored within cloud apps. At the highest level, the concept is quite simple – data flowing out of the organization is encrypted, as it is stored in the cloud. However, in practice there are nuances in the configuration options that may have impact on how you implement encryption in the cloud. This article outlines important architectural decisions to be made prior to the implementation of encryption solutions through CASB.


Gateway Delivered, Bring Your Own Key (BYOK), or Vendor Encryption

There are three generic methods in cloud-based encryption.

Gateway delivered encryption – In this model, the CASB may integrate with your organization’s existing key management solution through Key Management Interoperability Protocol (KMIP) or provide a cloud-based key management solution. In either case, the keys used to encrypt your data never leave your CASB.

  • Data is encrypted before it leaves your environment and is stored at the vendor
  • You control the keys
  • The vendor retains no capability to access your data

BYOK encryption – In this model, the keys are generated and managed by your organization, and then are supplied to the vendor. BYOK allows you to manage the lifecycle of the keys, which are then shared with the vendor. This includes revoking and rotating keys. The keys are then provided to and utilized by the vendor to decrypt requested data for use by authorized users. CASB can be involved as a broker of the keys to simplify, centralize, and streamline the process of key management by allowing you to perform this administration directly in the CASB User Interface (UI). This also may be done using KMIP with your existing key management solution. Alternatively, without a CASB you may still enjoy the benefits of encryption with your own keys, but administration would be manual on an app-by-app basis.

  • Data is encrypted at the vendor
  • You can control the keys
  • The vendor retains the capability to access your data

Vendor provided encryption – In this model, the vendor provides keys and key management. The administration may be provided through user interfaces provided by the vendor. The CASB is not involved.

  • Data is encrypted at the vendor
  • The vendor controls the keys
  • The vendor retains the capability to access your data


Important Considerations

There is not a “best” way to manage encryption for cloud apps. One important consideration for you to make the best decisions for your company begins with your motivation. Is your primary concern compliance, mitigating risk of vendor compromise, protecting data from being disclosed in blind subpoenas, all three?

  • Compliance – Encryption for compliance can be met easily by any of the three approaches, and is simplest with vendor provided encryption.
  • Mitigating risk of vendor compromise – Using encryption to mitigate the risk of vendor compromise implies the need to manage your own key, since your data will not be accessible without the key. Gateway delivered encryption is the approach that can provide the highest level of risk mitigation due to vendor compromise, as your keys never leave your environment. Cyber- attackers stealing your data will not be able to decrypt it without using your key or breaking your encryption. Risk may also be mitigated through BYOK, but agreements must be secured from the vendor to communicate breaches in a timely fashion. Then you must take appropriate revocation actions in your key management process.
  • Protecting data from being disclosed in subpoenas / blind subpoenas – Using encryption to protect data from being disclosed in subpoenas also implies the need to manage your own key. Gateway delivered encryption is the approach that can provide the highest level of risk mitigation from blind subpoena through a completely technical means, as third parties retrieving your data will not be able to decrypt it without your key. Risk may also be mitigated through BYOK, but agreements must be secured from the vendor to communicate third-party requests for your data in a timely fashion. Then you must take appropriate revocation actions in your key management process.


Unstructured and Structured Data

To further explain these approaches we must break out two very different types of data prevalent in the cloud: Unstructured and structured data. Unstructured data refers to data generated and stored as unique files and is typically served through end user apps, for example, Microsoft Word documents. Structured data refers to data that conforms to a data model and is typically served through relational databases and User Interfaces (UI), for example, Salesforce UI.


Structured Data

  • Gateway delivered encryption – Since the CASB sits between your end user and the application, structured data can represent a challenge to usability. From a usability perspective, whenever the application vendor changes field structures, the encryption must be addressed in order to maintain usability. From a security perspective, the app must decrypt and reveal some information in order to allow search, sort, and type-ahead fields to work properly in a cloud app UI. This is known as “Format Preserving”, “Order Preserving”, and “Order Revealing” encryption, which can lower the overall standard. A growing body of research is challenging this method and exposing weaknesses that may lead to compromise. For example, if you were to type “JO” in a field and it revealed all of the persons with names beginning with JO, this data has to be retrieved decrypted to support the UI.
  • BYOK encryption – since you supply the keys to the vendor, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. From a security perspective, BYOK does not suffer from the same risk of compromise in “reveal”, as exists in gateway delivered encryption.
  • Vendor provided encryption – Since the vendor owns the keys, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. From a security perspective, vendor provided encryption does not suffer from the same risk of compromise in “reveal”, as exists in gateway delivered encryption.


Unstructured Data

  • Gateway delivered encryption – Risk of usability problems is low on unstructured data in cloud storage. However, an important consideration is key rotation. Data encrypted under one set of keys can only be opened with those keys. Keys may need to remain available in archive, for reads, even if they have been retired.
  • BYOK encryption – Since the keys are supplied to the vendor, encryption/decryption occurs within the vendor application architecture as does key rotation and management.
  • Vendor provided encryption – Since the vendor owns the keys, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. Key management processes will be dependent upon the vendor.


Industry Direction

Most major cloud vendors are moving toward the support of a BYOK model. Some of these include Salesforce, ServiceNow, Box, Amazon Web Services (AWS), and Microsoft Azure to name a few. As more and more vendors are offering this type of capability, at Cedrus we believe that this is the direction of cloud encryption.


Opinion

  • Gateway delivered encryption – This is the highest level of security that can be provided when it comes to cloud app encryption, but may have an impact to the business in usability issues, especially when applied to structured data. High-risk apps and data are safest in this configuration and require the most care and feeding.
  • BYOK encryption – This implementation can provide a very high level of security without the impact that comes with gateway encryption. Through integration with a CASB as a broker of keys to centralize this management, this solution provides an excellent balance between protection and usability for high-risk apps and data.
  • Vendor provided encryption – This implementation provides a much higher level of security than not implementing encryption. This solution may be best suited for apps and data of lower criticality or meeting compliance requirements, only.


Recommendations

As with all security decisions, risk and compliance must be the yardstick in any decision. Since we do not know the industry, application, or risk to your business; this is a generic recommendation.

Where possible, always leverage your own keys over vendor-provided keys. Remember, a breach into a lower-risk app may provide clues to breach other apps.

When provided as an option, the best trade-off between security and usability is BYOK. It is very important to gain agreement from vendors for proactive communication. Where BYOK is not offered, the risks must be weighed carefully between vendor provided and gateway delivered encryption, especially for structured data.

When considering a move to gateway encryption, risk analysis of the app and data are critical. The risk of compromise should be clear and present danger. This is because a decision to move to gateway encryption for structured data means a commitment to the management and maintenance at a much higher level than BYOK or vendor provided encryption. This is not a recommendation against taking this course, but advice to consider this path carefully and plan the resources necessary to maintain this type of implementation. In a recent exchange with a customer they articulated the challenge: “We use CASB to provide field level encryption for our Salesforce instance. There are many issues requiring a lot of support and we have plans to move away from it and leverage encryption that is part of the Salesforce platform.”