Assessing SaaS Security: A Top-Down Approach

Conventional wisdom has it that SaaS vendors – that is, those that market cloud-based software-as-a-service – often maintain higher levels of information security than their clients. The reason: security is closer to the SaaS vendor’s business model, and thus its profitability, than it would be for a non-SaaS vendor. Also, early SaaS sales often went to early adopters, who were smaller and less security conscious than their larger competitors.

That formula is changing. Today’s SaaS contracts are going to large and sophisticated customers, and SaaS solutions are increasingly used in business-critical applications. So if you’re shopping for a SaaS offering, such as BlackLine’s, that will function within strategically important process chains, you have every right – indeed, responsibility – to assess your prospective vendor’s security complement with a critical eye.

According to Max Solonski, BlackLine’s VP of information security, due diligence should start at a high level, and then work down to the details. First, he says, look for a framework that suits your organization’s security and business needs. That framework will shape the policies, processes and personnel that make up the information security architecture.

“If the vendor bases its information security system on the ISO27002 framework, that’s a great start,” he says. “It’s all-encompassing and time-proven. But ISO27002 takes a lot of effort and expense to implement. It’s too much for some SaaS vendors.”

Still, the vendor’s framework should be sufficiently comprehensive to address all the organization’s security risks. And the more familiar you are with the ISO27000 series of standards, the better you’ll be able to evaluate the vendor’s information security capabilities.

Solonski says you should then look closely into three main areas: qualified personnel, adequate controls, and effective governance.

Information security should be governed and operated by a dedicated staff, trained in information security. The info security function should report to a high-level executive, preferably outside of IT. To avoid conflicts of interest with other technical teams around security controls, that executive should report to the CEO, CFO, or to the legal office. Ideally, the info security group’s budget will be separate from the others, and info security will have the commitment of C-level and board executives.

Assembling a dedicated staff is just a first step in creating an effective info security personnel policy. Next, info security staff should collaborate with other employees to determine who’s best suited to carry out the various security- related functions.

“People shouldn’t think of info security as a bucket where they can toss everything that’s security-related,“ says Solonski. “In most cases, security tasks that are related to non-security employees’ functions should still be done by those employees. Info security people should be used for educating employees and facilitating employee interactions with security.”

He points to a company doing application development as an example, where software engineers will collaborate regularly with info security engineers to determine the best way to incorporate information security into software design. That collaboration saves time during QA and security testing, and can help shorten development cycles.

Finally, the responsibility for, and commitment to, security should extend out to all employees in the organization.

“At the end of the day, even the best safeguards can’t fully protect a company if the employees aren’t careful,” Solonski says. “Employee security-awareness is a necessary component to maintaining across-the-board info security success, and it’s up to the security people to promote security consciousness through training and other programs.”

Technical and administrative security controls should be placed strategically throughout the organization. At a high level, controls exist in administrative policies and governance; in vendor management, accounting, and so on. At a lower level, they’re present in hardware and software, in everything from network firewalls to physical plant security.

These should all be inspected and tested regularly, just as one would test backup and continuity processes to make sure that the systems will be effective in an emergency.

And the vendor should have well-defined and tested policies and procedures in place for responding to all incidents, whether security-related or not. An outage or other incident can turn out to be security-related. Effective procedures will allow for quick containment to limit the damage.

“A network might slow down for no apparent reason,” says Solonski. “In this case network engineers will have a procedure for identifying the cause. But incident response procedures will also determine if there’s a security component to the incident. If there is, a security incident-response process should evaluate the risk and trigger the remediation.”

You should also look for policies and controls specific to that vendor’s information architecture and business model. For instance, a vendor might be running a legacy application that’s been “modernized,” or they might be exposing often-exploited technologies such as PHP or WordPress to the Internet. In these cases, you should look for the presence of purpose-specific compensating controls such as web application firewalls or strict connectivity limitations.

A commitment to regular, ongoing review and feedback is essential to the success of the info security program. The SaaS vendor should perform regular internal risk assessments and reviews of its controls, and should contract with independent auditors for periodic audits of the entire info security infrastructure

“Customers can expect their vendors to disclose the state of their controls and security practices” says Solonski. “Typically this is done by the means of third-party audit reports such as SOC2 Type 2. Some vendors go beyond that and let prospects and customers perform controlled penetration testing of their applications.

“But bear in mind that not all certifications and audit reports are the same,” he says.

“A major certification like ISO27001-2013 shows that the vendor’s info security functions have passed stringent independent audits.”

Other standards-based audits may not be as encompassing. For instance, the SOC1 Type 2 (also known as SSAE-16) audit validates the list of controls that an organization provides to the auditor, while the SOC2 Type 2 audit report – which you should ask for – will describe how an organization compares against a set of prescribed controls that a service provider is expected to maintain.

Finally, pay close attention to the scope and subject of the audits. The audit report should cover the SaaS vendor and not just that vendor’s sub-provider, because the sub-provider report won’t include a description of the SaaS vendor’s security posture. Also, make sure the report covers all the vendor’s facilities and locations – not just the data center that houses the application.

As a SaaS prospect or customer you should expect a strong level of communication and a fair level of transparency from your vendor. Communicating security processes, audit feedback and related information to customers is good business, and SaaS vendors know that. Transparency into controls, personnel, and other security-related details can be useful, too, in helping you appreciate the vendor’s commitment to keeping your information and applications secure.

But you should realize that at some point the vendor has to go quiet, especially when it comes to proprietary security methods or tools. So don’t expect complete disclosure when you’re investigating SaaS vendors. After all, the data the vendor is protecting might someday be your own.