Last week I spoke with two different Security as a Service vendors, each with their own approaches to security as a service. The first company I spoke to was Cloud Passage who just exited stealth mode in time for RSA Conference, and Zscaler who is a well known company. Both provide Security as a Service with a similar approach by a different design. Both make use of large grids or computers to do all the heavy lifting of security, but from there they differ completely. While there is some overlap in the products, the different designs show us multiple ways to implement Security as a Service.First we should discuss the basic design and data flow of Security as a Service. In Figure 1 (below) we see that data from the organization flows through the organizations firewall into the Internet and then to the Security as a Service cloud service to be acted upon and eventually acting upon the organization’s machine. This is the simple data flow shared by all Security as a Service vendors.
What makes each vendor unique is:
- The service performed
- Whether or not agents are in use within the organization
- Can also be used on gesture based computing devices (Smart Phones, Tablets, etc.)
- Security for data transmittal
- Security of data at rest
In the case of Cloud Passage, there is a very small agent called the Halo Daemon that installs within the organization’s hosts, desktops, virtual machines, etc. Which is then used to communicate with their Halo Grid over an encrypted tunnel. The Halo Grid does all the heavy lifting for Service Account Management, Firewall Configuration, Network Access Control and Vulnerability Management. Coming later this year will be IDS/IPS and Forensics components.
The Halo Grid talks to a database or the Halo Daemon and the Halo Portal used to configure the service only talks to the database. So there is a physical separation from the detection side and the configuration side. Each component uses AES encryption to protect data in flight as necessary. The Halo Grid also integrates with Puppet Lab’s Puppet Master for configuration management. In this way, the daemon can continually assess the system in which it is installed, send the data to the grid, and in the future if there are any configuration management changes (such as a change in IP to an unsupported country) take corrective action.
Cloud Passage is designed for an EC2 cloud at the moment but is expanding to other clouds where jurisdictional issues come into play so Cloud Passage is working on ways to handle that now. Their approach was to find the lowest common denominator in all the possible cloud and organizational units. That unit was determined to be the operating system in use and chose to write the smallest and secure agent they could that does not do much but send data onto the Halo Grid. If a VM is cloned within EC2, Halo Grid will know this occurred and apply the same security policy and configuration as the original regardless of IP as they do not use the IP as part of the VM signature. This makes it easy to manage a given VM and fits directly into IT as a Service. Maintaining security posture across all deployed VMs whether in the cloud or not is a very important aspect of IT as a Service.
Update: Cloud Passage supports most IaaS platforms including Amazon EC2, Rackspace & GoGrid.
Cloud Passage works currently for all Linux operating systems except SuSe (which is coming this year). In addition, they are working on agents for BSD and Windows. They find their biggest customers are SaaS providers who want better control over their current firewall environments. Since an agent is required, this currently rules out most gesture based computing devices.
Zscaler’s approach is much different, they provide a web and email filtering service that only requires you to change proxy settings within your browser or email servers within your mail client to make use of their Security as a Service. Being agent-less Zscaler can work with nearly any device as long as you can change proxy settings or email servers. Zscaler provides a centralized location for Data Loss Prevention, Web Application Firewall, SPAM filtering, email or web based malware protection. In essence, Zscaler’s goal is to move all your web and email security into Security as a Service which eliminates the need for multi-point devices in large organizations to provide the same functionality.
Zscaler supports connections that are tunneled to them over Cisco, Juniper, and other GRE based tunnels as well as direct connection from any device. While not everyone would want to send data in the clear to Zscaler, this is one aspect they support. This is also why they support GRE based tunneling which could require you to first VPN into your organization before heading out to Zscaler. This is one method I would prefer as my mail is my business, etc.
Zscaler’s security is to separate the user from the data and from the log. They create an anonymous connection between the users and the data by using a Zscaler Central Authority which maintains the user data, a Zscaler Zen cloud which does the heavy lifting, and a Zscaler Nanolog server which stores the data for later auditing. However, there is no user information within the Nanolog servers. In order to get a full log, to track everything back to a user at least two of these three entities need to be involved in providing such a report. They also provide such reports quite quickly.
While they do not necessarily encrypt data going to Zscaler (unless you choose to use that option), they also do not encrypt the data within one of their Zen clouds (with 40 datacenters around the world). They can limit to which Zen Cloud you can access at anytime due to jurisdictional issues with the cloud but this takes talking to Zscaler instead of using the administrative portal.
Zscaler spends quite a bit of time analyzing well known sites to determine what is a social media game, social media, pornography site, and other well known productivity impacting sites. They continually monitor the web for new such sites as their subscribers go to access them. This provides an extremely granular approach to what to shut off, enable, or only enable for a time period. For example, you may wish to allow access to You Tube but limit the viewing time to just a few hours a day or none at all. They also provide DLP capability via the web by denying the ability to use forms, upload data, or email attachments, etc.
Both of these approaches to security are quite valid. The concern is how do you secure the data going to the Security as a Service cloud and how do you secure the data within the Security as a Service Cloud. Both companies have different methods to provide confidentiality and integrity of data from using encryption to modifying data to be anonymous and then splitting up its storage. Both provide encryption of data in motion.
So is it safe to use Security as a Service, I would say yes as long as the service provides integrity and confidentiality with the ability to audit as needed. As well as instantly applying security policies to new ways of accessing the Security as a Service clouds from an organization whether that be a new or cloned VM or a new handheld or gesture based computing device. Security as a Service leverage the large amounts of data received by all customers to benefit everyone with a fine grained level of control.
Share this Article:
Latest posts by Edward Haletky (see all)
- Secure Agile Cloud Development: Metrics - July 27, 2016
- Continuous Integration, Deployment, and Testing - July 22, 2016
- Serverless: Business Plan or an Approach to Technology? - July 21, 2016