Cloud security is no oxymoron
The cloud is frequently described as the next big thing in computing. Years ago, it was the Web, and before that it was the Internet. The cloud is in the forefront. Consumers are storing personal data in the cloud. You are likely using the cloud right now in some form.
Today, “the cloud” is frequently described as the “next big thing” in computing. Years ago, it was the Web, and before that it was the Internet. Currently, however, the cloud is in the forefront. Consumers are storing personal data in the cloud. You are probably using the cloud right now in some form. It is estimated that in 2013 over $148 billion will be spent on cloud computing.1 Companies large and small are using the cloud to conduct business and store critical information. The cloud is now mainstream.
At National Instruments (NI), one of our teams is working to leverage the cloud to help solve real-world problems. One product we developed to do this is the FPGA Compile Cloud, a cloud service that allows users of NI LabVIEW FPGA to perform the computationally complex chore of FPGA compilation in a cloud-based environment. These compiles can sometimes take up to 24 hours to complete and can contain highly sensitive control logic or other sensitive information. The FPGA Compile Cloud is a software service offering built on top of public cloud infrastructure products. (National Instruments uses Amazon Web Services (AWS) and Microsoft Azure to host its cloud solutions.) Because we know that our customers expect a high level of security (as well as performance and availability), we have addressed authentication, encryption, and network access control to make our cloud solutions secure.
The paradigm of cloud computing requires cloud consumers to extend their trust boundaries outside their current network and infrastructure to encompass a cloud provider. This article covers only a subset of the security implications of dealing with the cloud, but hopefully the information will help you get started on the road to securing your own cloud implementation.
To begin, it would be helpful to define the cloud. First and foremost, it is about elastic and scalable computing and storage resources that can be allocated on an as-needed basis (see Figure 1). When allocated, these resources are abstracted so that the developer doesn’t need to be concerned with the underlying infrastructure and can simply make use of an abstracted service layer to allocate or destroy resources. Typically, the cloud uses utility billing so you only pay for what you use.
The National Institute of Standards and Technology (NIST; www.nist.gov) defines three types of clouds: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). NIST also adds another layer of complexity by defining different cloud deployment models: public, private, hybrid, and community.2 Amidst all these definitions, it might be easier to determine what the cloud is not. It is not a return to mainframe computing, nor is it hosting, the Web, or virtualization. Some of the confusion around the cloud results from the inclusion of the word “cloud” in a lot of marketing material that used to read “Web.” The cloud is not the Web.
Security in the cloud
The core of the cloud—elastic computing, scalable resources, service layers, abstracted infrastructure, and utility billing—allows you to offload functional parts of your system to a provider and do things that were previously impossible to do. But with these new benefits come an inherent new form of risk and a security-threat landscape. There are three primary areas of cloud security that relate to almost any cloud implementation: authentication, encryption, and network access control.
Authentication. Authentication is different in the cloud than in other areas of computing. Many users of SaaS products expect to be able to use credentials that belong to them (for example, Google, OpenID, Twitter) to access services that use an open authentication protocol like OAuth (http://oauth.net). Even if it does not integrate with third-party credentials, authentication needs to be done over a secure connection such as SSL (secure sockets layer) and should issue a randomized token instead of sending the credentials back and forth with each request. This serves the same purpose as a session in traditional Web applications. Enforcing randomness on issued tokens, expiration, and secure transport are crucial to building secure Web services.
For IaaS cloud solutions, authentication is no longer done with a username and password. Because of the public nature of the cloud, this type of authentication is too vulnerable to brute-force and dictionary attacks. Instead, all services must be secured with keys and certificates that are no longer something you know (for instance, a password) but are now something you have. How, then, do you keep these keys and certificates hidden from others? One method to control key use is to use a key store or key service, and to use encryption pervasively. A second method to control keys is by putting policies and procedures in place to frequently change keys.
Encryption. Customer data and other sensitive items (such as the secure certificates you use for authentication) must be encrypted under three circumstances: when data is in transit over the network, when data is at rest, and when data is backed up. When data traverses the network, a standard asymmetric encryption protocol such as SSL/TLS or a VPN (virtual private network) should be used. This technique is standard in traditional Web applications. However, in the cloud it is important to remember that you are running across a network you don’t control. Therefore, it is important that as data moves across different instances in your cloud application that it is encrypted on those paths as well.
When data is at rest or backed up, different strategies can be deployed to encrypt the data, ranging from whole-disk encryption to encrypting only sensitive data in a particular record of a database. The key to implementing an encryption strategy that works is understanding your data and not necessarily the actual encryption used.
Because data is crucial, it is important to understand how your data flows through the system. One of the best exercises for any team creating a new application in the cloud is “threat modeling,” which traces data as it flows through the system and questions assumptions about the data. Once you know where sensitive data is exposed, you can focus on securing the data.
Network access control. Firewalls—the longtime security placebo—are also different in the cloud. No longer can you rely on perimeter protection to keep your systems safe. In the cloud, your assets are publicly available; they share network space with other cloud consumers. Most cloud vendors offer firewall-like functionality to consumers in which you can control traffic based on the source and port of the sender and the receiver. Using this feature, cloud consumers can create rules that white list traffic outside of their system and also from inside their cloud systems.
Amazon Web Services (aws.amazon.com), a popular cloud vendor, provides security groups to limit internal and external traffic. Instead of including one firewall to cover an entire network, a “firewall” can be in place for every instance in a cloud environment. With these rules in place, only traffic that matches the rules is allowed, and it is possible to make sure that the database server will never be able to ssh (secure shell) to the front-end Web servers or be able to scp (secure copy) files off the authentication system. Host-based firewalls and IDSes (intrusion detection systems) also are useful in cloud architecture.
Taking the next steps to embrace the cloud
At National Instruments, we have addressed authentication, encryption, and network access control through several methods. Authentication is implemented for our customers using a secure transport layer and by issuing randomized tokens that have forced expiration. For our build process for any persistent image, we wipe all private information and keys. In addition to adding encryption, several design decisions decrease the amount of sensitive data stored on the server side. For the FPGA Compile Cloud, once the finished result is returned to the customer, the job is no longer stored. In regard to network access control, we have implemented security groups in Amazon Web Services that are tightly scoped to only allow certain traffic to and from our different types of instances. We also use secure code analysis tools and third-party consultants (in addition to our own certified security staff) to ensure we are providing as secure a solution as possible.
The information presented here only scratches the surface when it comes to cloud security. Depending on your application architecture, you will have specific needs and should consider security for logging, monitoring, penetration testing, static code analysis, access to management interfaces, and more. Late in 2008, the security community recognized the need for additional information on cloud security and formed the Cloud Security Alliance (CSA; https://cloudsecurityalliance.org). The organization recently released Security Guidance for Critical Areas of Focus in Cloud Computing, a free document that covers specific areas of cloud computing security. This report, available on the CSA website,3 would be a good next step to learning more about cloud security.
In 2010, the computing security community took additional steps to create software that could withstand attacks and persist in the state of adversity. Adapting a term from the hardware world, the group proposed the building of rugged software, and the idea has begun to take root (www.ruggedsoftware.org). It will be interesting to see if and how rugged software—in which security requirements would be in-scope right from the start—may grow in the development community.
In any case, the cloud helps foster innovation and lowers entry barriers. The key is to remember that you are in an environment that you don’t completely control—or shouldn’t completely trust. It is crucial to implement the security controls that make sense for such an environment.
James Wickett, CISSP, CCSK, is web systems engineer, National Instruments. www.ni.com.
Also search “cloud” on the Control Engineering website at www.controleng.com for a collection of articles on cloud-based automation related to the December 2011 cover story.
1 For more, read 2010 Cloud Computing State of the Union at ReadWrite Cloud; http://www.readwriteweb.com/cloud/2010/11/3-infographics-about-cloud-com.php.
2 For more, read NIST Special Publication 800-145, The NIST Definition of Cloud Computing; http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.
3 Security Guidance for Critical Areas of Focus in Cloud Computing is available at https://cloudsecurityalliance.org/wp-content/uploads/2011/07/csaguide.v2.1.pdf.
Case Study Database
Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.
2012 Salary Survey
In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.
Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.