Welcome back once more to our series on building security programmes. A series we hope helps you not only better secure your organisation, but also highlights CDW’s commitment to help customers approach security holistically and effectively, with their unique business context in mind.  

In this instalment I want to focus on addressing security concerns from business; primarily SaaS applications. 

The Trouble with Cloud-based Applications

With the advent of cloud, more and more business applications have become cloud-based and therefore hosted on their own infrastructure and developed with their own standards and approaches.  

Note: their own approaches, not ours. For this reason, our security standards don’t always neatly map to these applications. Worse still, these applications are often not captured in the first place, and don’t have any standards applied to them at all. 

This has led to me creating this particular domain for my programmes. 

How to Address these Concerns Individually

The first component is an inventory of our SaaS applications. I highly recommend doing this with a solution that’s able to discover your SaaS applications rather than trying to maintain a list in a spreadsheet! 

We can then create one component (document) per application, with each presenting the business rationale and purpose of the application, its risk, and data protection assessment, what data is processed or stored, the business importance and criticality, who would be using the application (and for what, if there are different levels of access or functionality). 

The rest of each document defines, in detail, how the application should be configured. That includes the structure, the configuration, the user roles, associated permissions and so forth. 

The goal here is to force thought into how each application is used, make sure it’s used securely leveraging each application’s distinct security mechanisms, and to have all security-relevant elements be documented and tracked.  

Components of this domain could include platforms: 

Too often I’ve found the focus of SaaS security measures to be the access to the applications themselves. This is obviously necessary, but we should not ignore the configuration and use of the applications themselves. This is one of the key concerns this part of the framework needs to address.   

With Salesforce, for example, we would define the workflow, how access controls work, what sales, contract, or financial information each user should have access to, and what level of access should be granted. We would also define anything else that needs to happen within the application to meet our broader policies, around things like data retention/deletion or backups, for example. 

Business applications built and hosted on-premises tend to have gone through more scrutiny than cloud-based ones. As such, they are more likely to benefit from centralised services around elements like updates and backups, but this isn’t a given. I would still recommend covering these elements for your SaaS applications as well, which can be covered as part of the documentation set of each application we will maintain. 

Most organisations have thousands of SaaS applications in use to some degree. Realistically, it won’t be possible to address them all, but it should be possible to define the main ones with granularity. Those are the ones in widespread official use containing the bulk of sensitive data. They will usually have the biggest business impact if disrupted.  

The good news is that there are now excellent solutions on the market that can not only help you get more visibility to your SaaS footprint, but manage the more common ones in depth too. 

My Reflections on SaaS-based Apps

I’ll end with the personal observation that business applications, especially SaaS ones, are likely one of the biggest elements of unaddressed technology risk today.  

Not just because it’s an area with arguably fewer controls, but because these applications tend to serve business-focused functions. They often handle sensitive and critical data, such as sales information, financials, contracts, customer submitted data, payroll, internal data on staff, business plans, intellectual property and more.  

I hope this highlights not just the importance on focusing on these SaaS applications, but also of being familiar with all departments’ business processes, to identify which of these applications may be in use, where, for what, and by whom in your organisation. 

As always, if we at CDW can help you with manage your SaaS applications and associated risks, we’d love to tell you about some of the latest solutions to these challenges. 

Join us for our next instalment to take a closer look at security when it comes to Product and Engineering.