I recently read a LinkedIn discussion about SaaS vs. locally installed software. There were many myths presented, mostly to suit the agendas of the vendors and their respective technologies (I know, I know – shocking that such things would happen on LinkedIn).
The discussion spiraled towards the (incorrect) conclusion that treasurers are paranoid about cloud software’s security issues. However, I’ve not personally encountered such paranoia. What I’ve instead found is that treasurers are inquisitive about any pitfalls a cloud delivery model presents – as they should be. Most often they will engage their IT colleagues to evaluate the security, infrastructure, and technology of any proposed third party solution. Treasury is not often equipped to make this assessment, and would otherwise risk falling prey to the agenda (and technology choices) of the vendors.
Security assessments typically focus on three areas:
1. Unauthorized access to the hosting hardware. For on-premise software, this means the “server room,” so to speak. Internal controls must be evaluated to ensure employees cannot access the servers or databases that house treasury data. Interestingly, when I present about the cloud at treasury conferences I always ask who has had access to the server room where their treasury software is installed (at their company) – everyone puts up their hand. There is a distinct advantage to hosting the data externally to combat this risk, presuming of course that controls such as biometric access, etc. are in place at the hosting facility. In reality of course, physically getting into most data centers is about as difficult as getting into Fort Knox.
2. Unauthorized access through penetration attacks. This is the largest perceived risk, although not the largest actual risk. Media often focuses on high-profile companies being hacked suggesting that a company’s website was penetrated externally. What isn’t usually well understood is that the website itself isn’t often hacked; it is the access to it (i.e. the login process) that is compromised. This isn’t to say that penetration tests – performed by reputable firms – shouldn’t be evaluated by the potential customer to ensure the depth of testing aligns with internal security requirements. Evaluating protection of the hosting site is important.
3. Unauthorized login to the hosting site. This is the biggest risk to both ASP and SaaS application security, simply because there are both social engineering (typically through phishing) and external penetration risks to be protected against. Both can be mitigated by ensuring that strong password controls (resets, timeouts, strong characters, etc.) are employed, as well as two-factor authentication. The second factor can be random alphanumeric keypads at login, key fobs, Yubikey, or SMS. The treasury team’s IT colleagues can determine what options do/don’t meet their own security policies, just as they would with bank web portal access.
In addition, IT will quite often evaluate the technology and infrastructure from a performance standpoint. Can this hosted application meet the response times required by treasury – both in normal use and for disaster recovery?
While any application has the potential for unauthorized access, SaaS poses no greater threat than internally-hosted software, and in many cases is more secure. You certainly need to ensure that you thoroughly vet your vendor’s security processes, but choosing a reputable SaaS vendor will help you sleep easier at night.
Learn more about Kyriba’s security processes here.
If you are unsure about the different types of cloud software that are offered and what is best for you, and which is best for your organization, read Kyriba’s guide on SaaS vs ASP.