By virtue of the fact that the system is web-facing, SaaS systems are more likely targets of hackers. The more complex the solution being offered, the more ports are likely to be open, and the more risks exist. We mitigate security risks in a variety of ways, ranging from security code reviews, to vulnerability scanning and more. We have to design and scan against common vulnerabilities like cross-site scripting, cross site request forgeries, SQL injections and insecure direct object references, and also against many less common ones. We naturally use our own Rational AppScan tool for vulnerability scanning, but also other approaches and tools. For obvious reasons, I can’t share a full list. Almost all of these techniques apply equally to on-premises offerings. SaaS differs from on-premises environments by having the vast majority of the user traffic traverse the internet, not just a company intranet. That makes SaaS systems more likely targets of hackers. And as owners of the production environment, we're responsible for operational security. A top priority in managing a SaaS environment is to keep up to date with security and vulnerability patches. We, just like our customers with on-premises offerings, must set up the necessary processes to keep abreast of available security patches from vendors. We also own the responsibility to run penetration testing against the production environment. We need to distinguish between destructive and non-destructive testing when dealing with the production environment. It's ok to define a self-owned account in the production environment and attempt to gain unauthorized access to it, but it's not ok if that - or any other penetration testing - interrupts service for the subscribers. Interruptive or destructive testing must naturally be done against a test environment, built to mimic the production environment as closely as possible. Our teams also do functional security testing, that goes beyond vulnerability testing and penetration testing, as functional failures in the security and privacy functionality spaces – if they existed - could lead to very significant security risk exposures. A key aspect of security for Cloud solutions is that the security framework must rely more heavily on server side data security to prevent unauthorized data access, because the client side is usually a browser, over which we have rather limited control. When new browser versions are released, we rarely have a choice of whether or when to support them. Users expect to be able to use the latest version of FireFox, Safari, or whatever browser they prefer, the same day it is released. Given the importance of Security, which derives from the fact that security incidents can cause loss of trust by customers, we have to assume security flaws will exist in new browser releases, at least for a while until patched. Our server side security has to handle the task and ensure proper security without relying on browser side functionality. Security testing is a top priority for every release of LotusLive (SmartCloud).
To be precise, current browsers supported by LotusLive officially include Internet Explorer, Mozilla Firefox and Apple Safari. See system requirements here. Other browsers like Chrome, Wildfire, and Opera work for many interactions with LotusLive, but are not officially supported.