Taming the SaaS security wilderness
- 03 April, 2017 21:04
The security risk that I am most focused on right now is this: Shadow IT and the consumerization of IT have put too many employee work activities out of sight of the security department.
Employees at my company now use more than 90 cloud-based apps that I know of. Most of these are categorized as software as a service (SaaS). Many are corporate-sanctioned, meaning the business unit or IT went through a selection process to identify and procure an application, and my department was at least consulted. This list includes applications such as ADP for payroll, Salesforce, Workday, Oracle, WebEx, Google Docs, Microsoft Office 365 and SAP.
Other apps are unsanctioned but tolerated. These include Github for source code and Skype and Yahoo IM for communication.
Then there are apps that I only find out about because I get invited to join or I observe the application’s traffic while monitoring events on our firewalls. One recent invite was for a team collaboration tool that allows for the collection and sharing of ideas. An engineer introduced the free app to our network and was using it to share some fairly sensitive information regarding security weaknesses in our product. Although his intentions were good and the tool got the job done, it was a security nightmare. Authentication? Nonexistent. Encryption? Same story. The app uses http instead of https, and worst of all, everything shared to it gets indexed by Google, meaning it can be discovered by anyone.
When I find out about a risky app like that that’s being used in the company, I explain the dangers to the parties for whom it is useful and we try to come up with an alternative that will be more secure.I’m also wary of applications that don’t accommodate our company’s single sign-on (SSO) solution to control account management or don’t provide a mechanism for restricting access by IP address. The latter failing means we can’t restrict access to users in our corporate offices or connected via virtual private network (VPN). In other words, users could be anywhere in the world working with sensitive corporate information on public PCs or on unsafe Wi-Fi networks.
So, as always, my job is to identify and prevent risky behavior. I know I can’t eliminate all risk — heck, there will always be apps in use that I don’t even know about. But doing nothing is not an option.
My first goal is to control the apps that I have categorized as high risk: those that store or process sensitive data (for example, HR records, customer data, health data, financial data, critical business information, SSO) or that provide critical services to the business (for example, DNS, content delivery networks, data center management portals, and alarm and phone systems).
One approach to gaining such control involves a fairly new category of security services called cloud access security brokers (CASB). CASBs are designed to sit between the end user and the SaaS application to control everything from access to risky behavior. Some CASBs require a client to be installed on each worker’s PC, and others rely on a device on the network that acts as a proxy between the user and the SaaS application. The idea is that all traffic to the SaaS application is intercepted and evaluated, and then action is taken depending on the assessment. For example, if a user is about to store a document containing a credit card number, Social Security number or sensitive source code, the client or proxy can identify this data leakage and either prevent the user from completing the risky activity or encrypt the data prior to storing.
You see the problem, of course. The CASB is out of the loop anytime an employee is off the network and using a machine that doesn’t have the client installed. For me, it’s a significant problem, because about 50% of our employees work remotely — usually on their corporate laptops, but not necessarily, especially when most applications only need a web browser for access.
But there is an alternative method of CASB functionality that I’m very interested in: the application program interface (API) approach. A CASB vendor that uses an API to maintain tight integration and communication with a SaaS application will not require you to use a client application or a proxy. Drawbacks of this approach involve prevention in real time. For example, I’ve been evaluating an API-based CASB that integrates with Google Drive. If I set a rule for identifying users who share a document outside the company, the CASB doesn’t prevent the sharing but merely sends an email to the user saying that the document may not be suitable for sharing outside the organization. This is a great way to change behavior, but it doesn’t prevent the risky behavior from happening in the first place. So I want API CASBs with real-time capabilities.
For now, I’m still in learning mode. My current sense is that I might end up using either an API approach or a combination of API, endpoint and proxy, depending on the situation.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at email@example.com.
Click here for more security articles.