Common Security Certifications & Audits: A Review of Some Standard Security Certifications for SaaS Vendors

If you’re working at a small firm and you realize that you need to find a new tool to help you process widgets, you might go to a hardware store and find one that has a UL certification. This certification gives you some assurance that the widget processor won’t catch fire in your office. However, what if your widgets are digital and you need a widget processor as a service (WPaaS)? If you’re not a security expert, how can you find one that will protect your widgets?

To start with, you’d probably want to list out all your known WPaaS vendors, and then select one that’s a good combination of price and security. How do you make this determination?  Well, congratulations: for the security side of this, you've just been asked to perform a vendor security review. Roughly, this is the process of trying to ensure that partners we entrust with sensitive data will take reasonable care of that data.

The reason why you might now be getting asked to perform this sort of verification is because so many tools that companies use are hosted online, either in a vendor’s own datacenter or within a cloud provider such as AWS, Azure, or Google Cloud, rather than being a tool that you would install in your own network. Combine this with a general increase in the awareness of security best practices due to a remarkably high public awareness of recent security incidents, and all of a sudden many security teams are being asked to implement some form of vendor review immediately. Vendor review management programs are designed to review tools and services used by an enterprise, with the goal of making an informed decision about whether the risk of using a particular tool is worth taking on.

In response to these inquiries, SaaS companies can demonstrate their security maturity level in a few ways, including through the use of one or more standardized security audits and certifications. While compliance is certainly not the totality of security, audits can demonstrate a certain level of organizational maturity and require evidence of some security safeguards; in other words, they show that someone is likely meeting a minimum bar of security best practices, but they do not demonstrate “unhackability” (and indeed, nothing can). These audits also do not cover technical security controls, such as protections against SQL injection, cross-site scripting, or a host of other controls; to check that a vendor has implemented adequate protection against those threats, you should review a recent technical application security assessment from a reputable vendor.

Below, we’ve reviewed a few different types of compliance certifications that offer some level of assurance to potential purchasers of SaaS programs. Each of these is slightly different, but they all have the goal of attempting to indicate that the assessed company has met a minimum level of compliance and security.

ISO 27001

ISO 27001/27002 controls cover most of the fundamentals of good security, requiring encryption of sensitive data, access control reviews, and a formal charter for the information security program.  The ISO 27001 certification is an information security management certification that assesses the maturity of a company’s security program and processes; this is the operation of the security program. It can include, as its Annex A, the controls from ISO 27002 that cover information security controls, such as policies, asset management, access control, operation, systems acquisition, and incident management. To receive this certification, a company must demonstrate that they have the required security processes in place, as well as a mature information security management program. Once a company has put all the required tools and processes in place to meet the 27001/27002 controls, they would hire an independent auditor to come perform the audit and issue their certification. 

SOC 2

The SOC 2 certification can assess a company on any of a variety of standards; however, the vast majority of SOC 2 audits are performed using the five Trust Services Criteria (abbreviated TSP, for historical reasons). These come in five categories:

•  Security

• Availability

• Processing Integrity

• Confidentiality

• Privacy

While a SOC 2 audit against the TSP must always include the Security category, a company may choose to add on some or all of the other areas, resulting in a SOC 2 auditing against, e.g., Security, Availability, and Confidentiality. This common set of three categories touch on some of the most important aspects of protecting sensitive information in the cloud. The Security category includes whether a company has an information security program, and whether it has implemented some common security controls, such as user security awareness, access control reviews, encryption of sensitive information, and change management processes. The Availability category ensures that the organization has done some business continuity planning and disaster recovery prep work. Finally, the Confidentiality category looks for a data classification scheme, and evidence that sensitive information is appropriately protected, as well as controls to ensure sensitive information on disks is destroyed when they are decommissioned. Processing Integrity focuses on the accuracy of system inputs and outputs and ensures that any errors introduced will be corrected. The Privacy category covers the privacy commitments to protect Personally Identifiable Information within a system, and the requirements to protect those from accidental disclosure. While these two categories are valuable, many companies choose to use other resources to assess their privacy and (if necessary) integrity programs separately.

The SOC 2 certification comes in two variants. A SOC 2 Type I audit reviews a company’s security program with the goals of assessing whether, if the company followed all of their written procedures, it would fulfill the requirements of the selected Trust Services Criteria. It does not assess whether the company does, in fact, do so. The Type I is therefore more of a proof-of-concept audit.

A SOC 2 Type II audit, in contrast, covers how well a company follows its written policies and procedures during an audit period, which is usually one year long. An auditor will randomly select statistically significant samples of servers, Jira tickets, employees, and so forth, distributed throughout the year. For each sample, the audited company will provide evidence showing that the controls operated correctly; for instance, for a server they may provide logs to show that error logging is running, or screenshots of a monitoring tool to show what alerts fired on a selected day. For employees, they may show that an employee received security training and that permission grants were tracked, and that employee permission groups are regularly reviewed.

Companies will often request that potential customers sign an NDA before viewing their full SOC 2 report during a vendor security assessment. Some companies, such as AWS and Atlassian, have dashboards where you can agree to the NDA and download the SOC 2 to review, but most will ask you to contact their sales teams first.

CSA STAR REGISTRY

The CSA STAR Registry is another certification that you might come across. Organizations hosted in the registry are either self-assessed, or audited against the Cloud Controls Matrix (“CCM”). The CCM is a set of security standards that are customized to apply to software that runs in a cloud environment. These standards cover logging and monitoring, identity management, auditability, privacy, encryption, and several other domains. Organizations who are audited against the CCM are listed as CSA Trusted Cloud Providers. If you find a widget maker listed as a Trusted Cloud Provider, you will know that they have passed a third party audit of their security controls, though there may be differences in how each provider is audited or what the required levels of success are.

FEDRAMP

The Federal Risk and Authorization Management Program (“FedRAMP”) assesses the security and privacy controls of organizations for federal government agencies. FedRAMP controls are drawn from the NIST SP 800-53 control set, with Low/Medium/High baselines based upon the sensitivity of the data that can be stored within the system (as delineated in another standard, FIPS 199). A FedRAMP Low and a FedRAMP High system both must implement many of the same security controls drawn from 800-53, but in addition to extra controls, the High system will have shorter timelines for things like removing former employee accounts, or more stringent monitoring controls. The FedRAMP Low control set, for instance, has 125 controls, while FedRAMP Moderate has 325 controls, and FedRAMP High has 421 controls.

These controls cover access control and identity management, vulnerability management, auditing, system acquisitions, change management, and several other domains. An independent third party auditor, called a 3PAO, performs an audit of the in-scope system against the FedRAMP control set, and reviews the supporting documentation to ensure that the system is well secured and managed.

WRAPPING UP

Hopefully this overview gives you an idea of how to check your potential partner organizations. As you review systems that will interact with your sensitive data, check to see if they have one of these certifications, indicating that they have taken basic security measures to protect your confidential information.

If you’re interested in achieving a certification like one of these for your organization, Leviathan’s Risk Advisory Services team would be happy to assist your organization with a gap assessment and assistance through the audit process.