Some of the more prominent concerns facing cloud computing adopters are those involving security. Specifically at the Software as a Service (SaaS) level, threats such as insufficient password management and insecure protocols can lead to breaches in your system' privacy, leaked data and possible legal ramifications for your business. In this tip, we'll explore the top three threats a SaaS offering will face and preemptive strategies to alleviate these concerns.
For the purpose of this tip, the top three threats discussed will be those you can mitigate, not those that you rely on your provider to mitigate. This distinction will be made at the "model" level (i.e., SaaS, Platform as a Service [PaaS] and Infrastructure as a Service [IaaS]), as defined by in the National Institute of Standards and Technology's
Note that while provider-side threats can still affect your services, risk transference insures that they are dealt with at the contractual level.
What are the most likely threats in a SaaS cloud service?
As the SaaS model is typically provided as a thin, or Web-based, client or a set of Web services, most of the threat surface area is pushed to the provider. As a matter of fact, the provider handles almost all of threat mitigation. This is important to understand and deal with appropriately in your contracts.
With that said, my experience has shown that the top three threats you'll have to deal with in a SaaS offering are:
- Weak credentials
- Insecure protocols, and
- Web-based application flaws
Weak or insecure credentials
All cloud-based applications with any level of privacy expectation will require a user to log in. While there are many secure mechanisms for providing that access, such as tokens or smartcards, the most commonly used method is reusable usernames and passwords. There is typically no management for those credentials, meaning that there are minimal strength settings (i.e., length and character sets required) and no password management (expiration, history).
Compromised passwords are the number one way attackers gain access to information, and easily guessable passwords are a primary target. The best mitigations for this threat are to:
- Create a strong password. I suggest using passphrase-based passwords that are at least eight characters long. For example, take the phrase, "What a great one for me to know!" and convert that into "Wagr814me2know!" (Note: Do not use this actual example).
- Change your password every 90 days. The length of time should be dependent on the sensitivity of the data, but as most people do not change their passwords ever, every 90 days is a good starting point. The more sensitive your password is, however, the more often you should change it.
- Do not reuse passwords.
The cloud is remote by definition, and thus requires network-based communications in the form of protocols to function. Problems can arise, however, when a provider configures an application to use an insecure protocol. This means that the application passes information between the client and server with a protocol that does not provide confidentiality or integrity.
This can take place primarily as a user and as an administrator. Applications that use insecure protocols such as Telnet for remote access, File Transfer Protocol (FTP ) for file transfers, Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) for email, and Hypertext Transfer Protocol (HTTP) for Web-based access will be exposing data to anyone along the path the data traverses.
To mitigate insecure protocol threats, you have three options:
- Ask the provider to replace the protocol. For example, use Secure Shell (SSH) instead of Telnet for remote terminal access.
- Ask the provider to support a secure version of the protocol. For example, secure versions include FTP Secure (FTPS), POP over Secure Sockets Layer (SSL), IMAP over SSL and Hypertext Transfer Protocol Secure (HTTPS).
- Use the application to protect the data over the connection. This would require the application to encrypt data before it is placed on the wire. Note that this is the least desirable of the options because of the key management issues raised.
A tangent on HTTP
It is important to realize that when we talk about HTTP , we are not talking about your mother's HTTP. The use of the HTTP protocol, XML, AJAX, etc. as a generic encapsulation transport allows applications to push almost anything over the HTTP pipe. When you hear HTTP, you might just think "Web." In reality, however, the application may be sending data you're not even aware of.
Web-based application flaws
The third major threat is when a customer has the ability to extend the application and in doing so introduces application flaws and security exposures. The actual threats in this class vary with specific applications but should not be overlooked.
To successfully mitigate this category of threats, you need to understand the application you are extending. Proper training on the application programming Interfaces (APIs) and security features provided is critical to successful mitigation.
We have addressed the top three threats in a public cloud SaaS offering. Properly managing your credentials, using the proper protocols to protect data and credentials and avoiding the introduction of security exposures will take you most of the way towards a secure SaaS solution.
This tip and the next two in my series will also build on each other. Threats flow "down" the model stack, meaning that threats in SaaS will apply to PaaS and SaaS/PaaS threats will apply to IaaS. Since you will run a platform and software on infrastructure, for example, all threats at the PaaS and SaaS level will be applicable to an IaaS deployment as well. The corollary, however, is not true.
One last point to stress it that all of the threats to cloud computing already exist in other computing environments. There is nothing new under the sun as it relates to threats and cloud computing. Therefore, the old adage that "good security is good security" still applies in the cloud.
ABOUT THE AUTHOR:
Phil Cox is a principal consultant of SystemExperts Corporation, a consulting firm that specializes in system security and management. He is a well-known authority in the areas of system integration and security.
His experience includes Windows, UNIX, and IP-based networks integration, firewall design and implementation and ISO 17799 and PCI compliance. Phil frequently writes and lectures on issues dealing with heterogeneous system integration and compliance with PCI-DSS. He is the lead author of Windows 2000 Security Handbook Second Edition (Osborne McGraw-Hill) and contributing author for Windows NT/2000 Network Security (Macmillan Technical Publishing).
Phil holds a BS in Computer Science from the College of Charleston
This was first published in December 2009