Smart Cloud Security: How to Protect Against Password Email Abuse

Raise your hand if you’ve ever shared passwords through email when a colleague asks for the credentials to a shared cloud service? I know I’ve been guilty of it. It’s easy and quick to be able to email the credentials to that cloud service (especially when it’s a shared account!).

But, sharing passwords over email is one of the most insecure ways of handling account credentials across SaaS, IaaS, and websites. Emails can be intercepted, easily shared or forwarded to outside parties, or even taken through compromised credentials and systems. The key is preventing this and coaching employees to use more secure methods of managing and sharing access across the cloud and web.

Netskope customers have deployed our unified, cloud-native platform to enforce policies across SaaS, IaaS, and web to protect against passwords being sent out in emails as well as other critical use cases. We have noted 20 of these use cases in our e-book, 20 Examples of Smart Cloud Security, and we’re highlighting each one on our blog.

Here’s use case #16: Enforce different policies for personal and corporate instances of the same cloud service.

The key here is to identify possible cases of credentials being shared in emails and restricting that – as well as coaching the employee on safer security practices when dealing with shared credentials.

How can a CASB enable this use case? A CASB sits in between the user and the cloud service provider and monitors usage, secures data, and guards against threats. In the case of blocking passwords being sent in any webmail app, a CASB needs to be able to inspect traffic and apply robust DLP to find sharing of passwords and credentials in all webmail.

This use case can be achieved with the CASB deployed as a forward proxy and reverse proxy to pick up all possible email traffic. To apply this policy to all traffic, including that emanating from sync clients and native and mobile apps, even in unsanctioned cloud services, your CASB needs to be deployed as a forward proxy (and if remote, with a thin agent or mobile profiles). For browser-based traffic to sanctioned services only and mobile traffic limited to a limited set, you can handle this use case with a reverse proxy.

We also recommend the use of password managers and integration with identity management services like single sign-on so that security teams can have control over sanctioned services. Combined with a CASB, these solutions can enforce multi-factor authentication and adaptive access controls across cloud and web.

Beyond deployment choices, here are some functional requirements needed to achieve this use case:

• Cloud DLP with custom keyword dictionaries to incorporate any variation of keyword that may signal that a password is being shared
• Cloud DLP support for business-led webmail accounts
• Support for category-level policies with specific support for webmail
• Decrypt TLS and decode the unpublished API to understand the transaction