I just got back from New York where I saw a number of our financial customers – some of the largest banks, money management firms, and insurance companies in the world. I’m always amazed at the level of talent in this group of customers. These are folks who are truly at the front lines, whether of regulatory compliance, fending off data breaches, or protecting some of the world’s most sensitive data.
This group also uses Netskope in some of the most sophisticated ways, including using layered policies across sanctioned and shadow IT cloud apps. A layered policy is one in which there’s a “base policy” and an “exception policy.” By layering the exception policy above the base one, you execute that policy when the contextual factors you specify are present, and otherwise the base policy kicks in. It’s kind of an “if else” for Segurança na nuvem, and useful when you want to allow apps while blocking risky behaviors. Here are four good policy ideas from this group:
Let people use social media for research, but don’t let them post. Several of our asset management customers want users to take advantage of social media apps like Twitter for research purposes, but don’t want them posting messages. Using Netskope, they allow social media apps, but block users from the activities “create,” “post,” and “share.” There are variations of this policy, for example, “Don’t post if the message contains the ticker symbol of one of the stocks on our watch list.”
Don’t let people email about “watch list” stocks from their personal email. One of our investment banking customers wants to enable users to write and upload to sanctioned apps the names and stock tickers of companies they analyze without triggering a data violation, but doesn’t want users putting those same names or tickers in personal email like Gmail or Yahoo! Using Netskope, they upload the stock watchlist and create DLP alerts only in the webmail category.
Allow people to use personal Dropbox, but not upload corporate data. Most of our financial services customers have some variation of this policy. Using Netskope, they separate out their corporate sanctioned app from the rest (in this case, it’s corporate vs. personal Dropbox), and rather than take an “allow” or “block” approach, they allow both, but simply disallow the upload of corporate data to personal Dropbox. Then, when users upload those sensitive corporate data to corporate Dropbox, the company enforces a policy to encrypt that file with its on-premises-managed keys.
Drive cloud storage users to Box. This is also a common layered policy across not just the financials, but many industries. The company wants to drive users to the corporate instance of Box using automated coaching messages when those users try to access an alternative app. They can be nuanced about it, though, and for certain users allow a “business justification” as part of that coaching message. For example, a Director of Business Development may need to download a partner’s contract from the partner’s Google Drive or Dropbox). The company can also layer on another nuanced policy to deal with sensitive data. If they want to quarantine or encrypt only sensitive data, they can layer a DLP policy on the other policies to take the appropriate action.
There you have it: Four sample “layered” policies from our friends in the financial services industry to help us protect data and comply with regulations. What’s your favorite example of a layered policy?
