Feeds

back to article The good, the bad and the ugly

Interested in software as a service (SaaS) but worried about the risks to your information? That’s understandable, given the chatter and FUD (fear, uncertainty and doubt) that surrounds this area. What are the risks you really need to consider in making an objective assessment? The answer will depend on your own situation and …

COMMENTS

This topic is closed for new posts.
Boffin

Networks

There is one glaringly obvious problem with SaaS however, especially full document and software solutions: connectivity and bandwidth. The medium/large companies with the resources to put into a large connectivity pipe will likely have WAN failover and the like. However, the small-to-mid-sized businesses, who would benefit most from SaaS due to limited resources, won't have the means to have WAN failover (or aggregating), high bandwidth, or even reliable connectivity from a local ISP. Moving 400KB (Google) docs is simple enough, but as data grows, the internet connection will be compoundingly taxed. Some regions only offer (crap) DSL or (highly expensive) T1-class connections, which present bandwidth issues. All this considering most small biz won't have an on-site IT tech, and will likely have an outsourced IT firm for their support anyway. These companies usually only support OS patching and physical network, charging extra (prohibitively expensive) for custom consultation or additional support.

SaaS for zero-downtime, mission critical email? Great. Local outages or clogged internet connectively won't bounce emails. SaaS Documents? Perhaps. Databases, POS, or other has-to-be-working network resources? Likely best to keep in-house. Why? SLAs for uptime during business hours, point-of-restore for backups and time-to-restore for those backups, shear bandwidth (and lag!) considerations, among others.

As a side note that no one really mentions: LAG. It can make the difference between productivity and turnover. A year or so ago, we moved from a SaaS solution to a local setup of our billing and accounts software. It ran fine as a hosted solution, but it wasn't until we deployed it locally that the users really felt the improvement. What used to take a couple seconds (yes, not very long, but forever when it's EVERY screen) was now nearly instantaneous. The users themselves were talking about how much more they could get done in a day. However, this is a database-attached complex piece of software. Something more web-friendly, such as email, isn't as big of a deal.

0
0
Bronze badge
Boffin

question about those SAAS-internal LDAP integrations

My company was looking at some SAAS-based providers for some HR stuff. Some of them told us that logging onto their system could be achieved by querying our LDAP server back and asking it if the entered user/password combination is valid. This allows our users to log onto the SAAS system with same the same company-wide password they already use for all our applications.

So, what is the actual risk of the SAAS provider being able to know that Jim Smith uses "bigDaddy101" as a password on our internal network? I realize that best practice is not to save a password, just pass it on to the authentication system, possibly after encryption/hashing and forget about it. But, if you control the source code, you can always log those passwords and you would be able to use them if you were physically on our internal network.

I definitely also realize that a provider who is in the SAAS business has no real incentive to do this, but how do other security conscious user companies feel about this risk?

0
0
This topic is closed for new posts.