Google's gmail suffers from malicious archiving system
Serendipity, but just last week I was writing about Google and Microsoft's upcoming battle over enterprise data by way of Enterprise SaaS offerings. You can read about them and Autonomy in Autonomy, Google and Microsoft battle for SaaS. Over the weekend I stumbled across a story about a malicious archiving product that is sure to interest our readership.
This situation peaked my interest because it was an email archiving product for gmail. Specifically, the application is an end user archiving product called g-archiver. The product works by accessing a users gmail.com mailbox account and copying all their email to a local device. In order to copy the email from gmail.com the product requires that a user input their username and password. (Note: Here is the URL to download the product - www.brothersoft.com/g-archiver-58027.html)
The username and password combination are stored by the archiving application locally. Then, the archiving application uploads the username and password combination to a specific gmail.com account. The offending account and a short list of the stolen identities can be found here, passwords redacted of course.
Although this is unfortunate for the users affected, it is a good example of SaaS risk. This type of malicious development is why companies must review their security processes and policies if they intend to use SaaS, especially SaaS hosted data and archiving. This use-case breaks down to a user moving data from an online system to their local PC. The user intentionally entered their username and password so the archiving application could access their data. Their expectation was that the information was required to help them. The design of SaaS and Storage as a service, predict more data breaches and identity theft will happen based on these models.
By definition, SaaS stores data on remote systems. The SaaS data is susceptible to these types of breeches, by design. Data stored on a remote system has a usability perception that it may need to be copied locally for any purpose. For example, in an enterprise there is nothing that would prevent a user from running a web based application to copy data from a SaaS message and storage system. The reasoning behind end-user actions will always bewilder developers and product managers. It's not ours to reason why, but to manage risk.
SaaS exposes new security challenges to enterprises in the form of on-line storage, unknown user behaviors and application programming interfaces (APIs). Managing risk is far better than avoiding it. Here are some tips for managing risk with SaaS systems:
Managing any risk requires a keen understanding of the conditions and consequences. Identifying SaaS utilization is the first step in determining risk probability. SaaS applications and storage may improve productivity and reduce energy costs. They also help users accomplish more in their already busy days, but you can be assured thieves and other unethical types will be on the hunt for the digital identity required by SaaS. Perhaps Google can take a page out of Microsoft woe's with the Melissa virus and develop APIs that can access a users data without user credentials, but requiring the user respond with it being okay.
This situation peaked my interest because it was an email archiving product for gmail. Specifically, the application is an end user archiving product called g-archiver. The product works by accessing a users gmail.com mailbox account and copying all their email to a local device. In order to copy the email from gmail.com the product requires that a user input their username and password. (Note: Here is the URL to download the product - www.brothersoft.com/g-archiver-58027.html)
The username and password combination are stored by the archiving application locally. Then, the archiving application uploads the username and password combination to a specific gmail.com account. The offending account and a short list of the stolen identities can be found here, passwords redacted of course.
Although this is unfortunate for the users affected, it is a good example of SaaS risk. This type of malicious development is why companies must review their security processes and policies if they intend to use SaaS, especially SaaS hosted data and archiving. This use-case breaks down to a user moving data from an online system to their local PC. The user intentionally entered their username and password so the archiving application could access their data. Their expectation was that the information was required to help them. The design of SaaS and Storage as a service, predict more data breaches and identity theft will happen based on these models.
By definition, SaaS stores data on remote systems. The SaaS data is susceptible to these types of breeches, by design. Data stored on a remote system has a usability perception that it may need to be copied locally for any purpose. For example, in an enterprise there is nothing that would prevent a user from running a web based application to copy data from a SaaS message and storage system. The reasoning behind end-user actions will always bewilder developers and product managers. It's not ours to reason why, but to manage risk.
SaaS exposes new security challenges to enterprises in the form of on-line storage, unknown user behaviors and application programming interfaces (APIs). Managing risk is far better than avoiding it. Here are some tips for managing risk with SaaS systems:
• Interview your departmental champions about their use of SaaS
• Make an IP and domain list of online storage systems, i.e. Amazon S3, Nirvanix, Gmail, etc
• Identify new APIs that integrate with authentication systems like OpenID, SalesForce.com, etc
Managing any risk requires a keen understanding of the conditions and consequences. Identifying SaaS utilization is the first step in determining risk probability. SaaS applications and storage may improve productivity and reduce energy costs. They also help users accomplish more in their already busy days, but you can be assured thieves and other unethical types will be on the hunt for the digital identity required by SaaS. Perhaps Google can take a page out of Microsoft woe's with the Melissa virus and develop APIs that can access a users data without user credentials, but requiring the user respond with it being okay.
Bookmarks
Newsletter Signup
Leave a comment