Revisiting SaaS Security Controls at Intel

SaaS is not new. It has been used for both business and personal use for some time and for a few years in its cloud form. So what sort of security changes are required to use SaaS in the enterprise? What SaaS challenges is Intel IT encountering? Why now? In this blog I share some real-life SaaS experiences, as a cloud and mobile security engineer at Intel, as well as my view of SaaS security.

Matching Strategy to the Current Environment

The emergence of new and large use cases triggered Intel IT to reignite our SaaS architecture and look for more security solutions for the SaaS cloud space. Previously at Intel, use cases for cloud-based SaaS were small and limited to a few users. But the new use cases involved thousands of users, mainstream apps such as data repositories and collaboration, and big business models such as CRM. These large use cases required us to reexamine our SaaS strategy, architecture, and controls to protect those mass deployments. As documented in our recent white paper, these controls center mainly on data protection, authentication and access control, and logs and alerts. We strive to enforce these controls without negatively impacting the user experience and the time to market of SaaS solutions. The paper also discusses how we manage shadow IT—users accessing SaaS services without IT awareness.

How We Handle Cloud Traffic Inspection

While the white paper summarizes our SaaS security controls, I’d like to delve a bit deeper into cloud inspection.

As is often the case, the right approach wasn’t immediately apparent. We needed to examine the advantages and disadvantages of the various choices – sometimes a complicated process. We investigated two ways we could inspect activity and data:

• Cloud proxy. In this approach, we would pass all the traffic through a cloud proxy, which inspects the traffic and can also encrypt specific fields, a valuable process in controlling the traffic and information being passed to the cloud provider. The downside of this solution is that the traffic is directed through the cloud proxy, which might cause performance issues in massive cloud implementations, where the cloud provider has many presence points around the globe. Cloud proxies can also impact the application modules, in cases where reverse proxy is being used.
• Cloud provider APIs. This option uses the cloud provider’s APIs, an approach that allows inspection of user activity, data, and various attributes. The benefit of such an implementation is that it happens behind the scenes and doesn’t impact the user experience (because it is a “system-to-system” connection). But the downside of using APIs is that not all cloud providers offer the same set of APIs. Also, the use cases between SaaS providers can differ—requiring more time to fine-tune each implementation.

We reached the conclusion that each solution needs to match the specific use case security requirements. Some SaaS implementations’ security requires more control, some less. Therefore we believe it is important to have a toolset where you can mix and match the needed security controls. And yes, you need to test it!

I’d like to hear from other IT professionals. How are you handling SaaS deployments? What controls have you implemented? What best-known methods have you developed, and what are some remaining pain points? I’d be happy to answer your questions and pass along our own SaaS security best practices. Please share your thoughts and insights with me – and your other IT colleagues on the IT Peer Network – by leaving a comment below. Join the conversation!