The primary goal of any IT organization should always be strategic alignment with the business. In an ideal world, the IT group consults with the business units and develops a clear strategy around application needs. The business units then wait for the budget to be approved, the infrastructure to be built, and the security and compliance controls to be implemented. This whole process could take weeks, months or years and still not meet the expectations of the business units.
Organizations can use existing security technologies and controls to help stem the tide of rogue cloud services.
What would happen if the business unit could discover and implement technologies without IT involvement? Would the average business unit accurately define the risks to the proprietary information being placed in the cloud? This is the new reality that IT security departments face. A plethora of cloud services are readily available and claim to be capable of solving just about any business problem at the click of a mouse. IT security departments must somehow detect these services and demonstrate the value of identifying and mitigating the associated risks to the business before their companies become another data breach headline.
The good news is there are a number of available products for mitigating risks with cloud-based services, some of which include capabilities for provisioning services, federating identities and managing virtual infrastructure. The bad news is that there are not many products capable of monitoring or preventing the use of unauthorized cloud services. However, organizations can use existing security technologies and controls to help stem the tide of rogue cloud services.
When monitoring cloud services, use what you've already got
The first method for detecting and monitoring cloud services is to utilize existing investments in current Web-filtering, next-generation firewall (NGFW) or data loss prevention (DLP) products. These systems are already positioned in the network to intercept traffic that could contain proprietary information or detect access to inappropriate websites. DLP systems can be particularly useful, since they can even look into SSL-encrypted traffic using man-in-the-middle techniques. DLP and Web-filtering systems may already have definitions configured to detect or block access to cloud-based file-sharing sites, such as Dropbox and Google Drive. These definition files need to be modified to allow detection of other potential cloud-based services.
There are several registries of cloud services that can be referenced to help build custom definitions for either a DLP or Web-filtering system. However, building custom definitions with these registries is labor-intensive, because there are so many potential cloud providers from which to choose. To make this task easier, prioritize the cloud providers on the list to focus on those most likely to be used by the business. The security software vendors will most likely add cloud provider registries to future DLP and Web-filtering products, but in the meantime, detection will continue to be a manual process.
If a security team is budget-challenged and doesn't have access to these types of tools, there are also some great open source options. The tool of choice for many security pros with limited budgets is the open source version of the intrusion-detection system (IDS) Snort, which includes free rules that can turn any old PC into a first-class IDS machine. The real power of Snort is its ability to easily add custom rules to fit the environment. These rules are typically inserted into the local.rules file included in the default Snort installation.
From the editors: More on cloud network security
What to consider when implementing intrusion detection in the cloud.
Review firewall options in Amazon's cloud, including the AWS firewall.
This is a simple example of a custom Snort rule that could be used to detect access to Rackspace:
Alert tcp any any -> 220.127.116.11 any
This rule would detect any TCP access from any port to the IP address 18.104.22.168 on any port. This IP address maps to the management portal for Rackspace services at manage.rackspacecloud.com. Configuring Snort in this way would alert the IT security team whenever an employee on the inside of the network accessed the Rackspace portal to manage cloud-based services.
Remember to work with the business
NGFWs, Web filters, DLP and IDS systems are all great tools for monitoring access to cloud-based services. However, they are all inline tools that assume that the user is accessing the cloud from a corporate Internet connection. If users access unapproved cloud-based services from mobile devices with their own Internet connectivity, IT must use a different method to detect them, one that can be quite effective despite being less technical.
The IT security team needs to partner with the business to educate users on the risks involved with using unapproved cloud services and to build strong policies around creating and managing them. The value in this approach should never be underestimated. These cloud-based services could quickly become a large expense for the business, so financial controls should be created as well. Financial controls are easier to implement, because they are more definitive and simpler to explain to the business than potential risk scenarios. These controls should include policies requiring review by IT, finance and legal before any implementation. Establishing such a partnership may also help rebuild the wavering IT-business strategic alignment that caused the business units to shop outside of IT in the first place.
A problem with existing answers
While the problem of users accessing unauthorized cloud services in the enterprise will likely grow as cloud applications become more affordable and accessible to a wider variety of users, IT security teams should consider utilizing the tools that are already present within most mature organizations. Limited additional funding will be necessary for new technology, and the best options for solving this problem, including building the IT-business relationship, are worth pursuing for benefits beyond just this issue. Security teams just need to stay out in front of this problem so they aren't left explaining a serious data breach down the road.
About the author
Joseph Granneman, CISSP, has more than 20 years in information technology and security, with experience in both health care and financial services. He has been involved in the Health Information Security and Privacy Working Group for Illinois and the Certification Commission for Health Information Technology Security Working Group, and is an active InfraGard member.
This was first published in February 2013