An Adventure in Cloud Security

I recently registered for a website hosted by a government agency that handles some of the most sensitive personal information available within U.S. Government. While the site is only a simple scheduling system, imagine my dismay when I received an email confirming my registration that included both my username in password in the email body. That email demonstrates that, despite all of the reported attention to security over the past several years, especially within the Federal Government, we are failing to build an effective information security culture.

After receiving the offending email, I started to do some digging into this service that I was required to use to retain access privileges. My very cursory research exposed a number of warning signs for organizations planning to roll out new cloud services. Admittedly, I only discovered the following after reexamining a service that I had already successfully used and donated my personal information to.

• Branding I should have realized from the outset that I was in trouble when the service URL pointed outside of the agency intranet, to a site hosted by a company called TimeTrade. Users should immediately recognize this as being a potential phishing attack and should question the legitimacy of the service.

  The link then directed me to a web site that contained some text announcing that it was associated with the agency, but gives no additional information to allow the user to validate its authenticity. The site is mostly a generic web page with no linkage to the organization it supposedly supports. Searching the agency intranet also failed to provide any clues. For all I knew, the web site was simply a means to capture my personal information for some other use.

  These are all signs of a very immature service and a failure by the contracting organization to enforce a minimum set of good security practices.

• Privacy Policy There was no Privacy Policy available from the web site that was provided to me. Most major online companies recognize the need to communicate, at minimum, what information is collected, how it will be used, how it will be stored, how it will be secured, etc. This web site only gave the following statement:

  "TimeTrade Systems, Inc., the contractor operating the website, will not use the information for any purpose beyond scheduling an appointment."

  According to the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, the document that generally governs the implementation of security controls for U.S. Government systems, the minimum standard would be to include an "approved system use notification message…that provides privacy and security notices."

  Searching the main web site for TimeTrade, I did find a general privacy policy. The policy contains a section devoted to "Scheduling & Appointment Confidentiality" that states:

  "TimeTrade never shares a service provider's schedule with anyone. For persons scheduling appointments with a service provider, TimeTrade will not share their personal schedule information with anyone except the service provider with whom they make an appointment. All scheduling and appointment information will be confidential. Each service provider can view only information relating to his or her appointments."

  More importantly, the site provides no method to clear user information from its database. Once you register, you're stuck.

• Credentialing I'll credit TimeTrade with cautioning users to not use their agency password to log in to the system. However, after directing first time users to a registration page, it fails to include the same warning for a user entering a password for the first time, negating the effectiveness of the warning for all users (since current users have already registered and have likely given their agency password to this unverified external company).

  The biggest problem, though, comes from the confirmation email that I mentioned at the beginning of this post. While providing a clear text email is a violation of just about every security standard, including NIST SP 800-53, it also points to a host of other violations. Most striking is the failure to protect the password with a very common hashing or encryption process so that even system administrators cannot easily recover it. By applying this very common practice, TimeTrade users would be protected even if they did make the common mistake of using their agency password to access the service.

  Beyond those violations, TimeTrade also fails to provide an ability to cancel user accounts and to change passwords. The "Forgot Password" function simply sends a new email that contains both the username and password of record for the given user.

I'm using TimeTrade here as an example rather than a target. It is one company of several that I've recently noted fail to follow even the most basic of security standards. But, the use of it by a large government agency combined with the very apparent security vulnerabilities gave me pause.

Perhaps we've just become immune to security messaging. After all, what real threat is there to divulging little more information than my LinkedIn profile already contains? Given that companies continue to make the same mistakes that their predecessors made in years past, I'm not sure that we're really learning from those mistakes. In this case, TimeTrade is just as at fault for selling a product that demonstrates questionable security practices at the agency that procured it is for not conducting even a cursory security assessment. Users, including myself, are just as at fault for not recognizing the many threats associated with using the site. Being required to use it doesn't mean that we shouldn't ask questions.

Organizations need to take care when moving to cloud services such as this one marketed as a "Software-as-a-Service." While cloud services provide the ability to rapidly deploy simple solutions, organizations should know what they are buying before they sacrifice quality for cheap and easy delivery.

This posting originally appeared on the InfusionPoints blog site on February 8, 2012.