As business adoption of cloud services continues to grow at a rapid pace, so does the need to adapt security methods to accommodate the myriad of options. Traditional best practices often still provide a solid foundation from which to build on, but depending upon the technologies you opt to migrate to the cloud, different challenges and solutions need to be explored in order to ensure that your security operations can maintain visibility and control and prevent critical risks and vulnerabilities. In this series, I’m going to explore the three different service approaches: Platform as a Service, Infrastructure as a Service and Software as a Service, reviewing examples of the operational or tooling updates necessary to keep your business secure. For this post, I’m going to focus on Software as a Service.
Software as a Service
Perhaps the easiest way to understand Software as a Service is from a traditional business’ approach to IT software purchases. SaaS covers a broad range of different product offerings many of which have already become recognizable brand names – from Office 365 to Salesforce.com, from Google Docs to WebEx, where software is delivered online via a subscription rather than bought and installed on individual computers.
In some cases, this may mean an entirely web-based method of access, whilst other SaaS tools may still have traditional “on device” software but with the benefits of online license management, automatic updates, etc. As a result, SaaS has seen some of the quickest adoption rates within organizations across the world.
In many ways, SaaS is a boon to the security of your organization – requiring users to provide credentials, applying updates before accessing data, centralizing management of access to give greater visibility into authorization and offering additional security controls (like remote wipe). All potentially provide massive assistance to security teams.
But there are downsides as well because SaaS makes the security surface area harder to define. Many mitigations for online services are dependent on vendor adoption and are thus outside of your own security team’s control. The configuration of controls, which help to secure your data, might require a different approach from your on-premises security operations. This could require additional human resources to set up and maintain the controls to achieve consistency with (or, indeed, improve upon) existing security controls.
Adapting for SaaS
Adapting your SOC operations for SaaS requires security teams to take some very specific elements into consideration. I’m going to look at addressing three items that I consider should be at high on the agenda for your SaaS security plans.
Assessing Products
When evaluating SaaS solutions, it’s critical to understand your vendor’s security track record and service level agreements (SLA) for resolving vulnerabilities. Fortunately, getting to know vendors in the internet era is much easier than it once was, but making sure that you know the partner to whom your service will be tied is important. Security team involvement in evaluating services can help speed up adoption by making sure that you know what new security controls will need to be implemented. Understanding how much effort it will take before you invest can help drive important decisions around staffing requirements, the number of required user/license numbers, etc.
Controls
For many SaaS offerings, there will be a number of configuration choices that will impact security. From authentication options to end-point verification, from geographical access control to internal application role-based-access-controls, there’s a plethora of security options that may need to be explored in detail to ensure a practical level of security restrictions are applied.
Some organizations with existing security programmes in place look to take existing onsite product strategies and map controls directly to those available in the cloud, whilst others might use this opportunity to revisit or build out their security models to reflect the SaaS application’s toolkit. Either strategy can work well, but it’s important to review with the vendor or seek security industry guidance. CIS and vendor-specific guidelines should be leveraged to make sure that new controls that could help you to advance your security systems and potentially improve your security posture significantly are implemented.
Testing security mechanisms is also key. For example, knowing the implications of disabling a SaaS user’s account can help you understand the risk associated with data leaks. For many SaaS products, disabling an account may instantly prevent the user from accessing any data, but if the SaaS tool offers some form of “offline” access, then users may be able to circumvent these controls by choosing to work offline and still have access sensitive data. Indeed, they may be alerted by the very control mechanism you’ve applied and taken the opportunity to exfiltrate data.
Applications with remote wipe may help to get around such risks, but the key step here is to make sure you appreciate the implications of utilizing a control so that you fully understand the limitations and can take any additional steps required to minimise the potential consequences.
Visibility and Reporting
Once implemented, maintaining your security controls and ensuring that issues are identified and resolved quickly is vital. From ensuring you are subscribed to new data sources that will keep you apprised of any new security risks associated with your new SaaS tools to having suitable auditing logging, these measures can help you keep on top of your SaaS implementation.
In particular, consideration should be given to your security logging tools which make sure that your security operations team have visibility into what’s happening outside of the organization. Making sure that important information is delivered in a timely and practical to process fashion can be the difference between prevention and disaster.
Reporting out to the rest of the business about your SaaS security is also important. Consider the level of effort it will require to add additional security insights reporting in your SaaS environment as well as how to appropriately summarize your overall security achievements. Scoring of vulnerabilities and compliance with internal SLAs for security cases, for example, might require some rethinking when you have a vendor managing out many of the mechanisms for securing your solution.
Coming Up
I hope this has helped give you some insight into some of the starting steps for adjusting your security strategies towards a SaaS enabled world. The next article in the series will explore some of the additional adaptions to consider with Platform as a Service.