Security as a Service, Does It Really Work?

June 2013

The cloud model has brought obvious benefits to the IT ecosystem. Unlike the early days of cloud services when enterprises had been reluctant to consume public cloud services -mostly due to security concerns in relation to the loss of control for in house technology and processes-, the market is now growing exponentially with varied solutions and matured vendor services boosted by evolved set of standards, practices and guidance for service assurance.

De-perimeterisation is one of the major impacts of cloud migration and requires new approaches for security controls. As the data to be secured is now outside the secured corporate perimeter, the complexity of protecting data and the risk of compromise is higher. Security as a Service (SecaaS) is the cloud solution set offering a standardized security framework with centralized resources of technology, processes and expertise. The SecaaS market promotes several benefits of this model however these benefits must be weighted together with the associated risks due to centralization of resources, loss of direct control for technology and possible conflicts and gaps in roles and responsibilities.

The most obvious benefit of a SecaaS solution is the cost savings due to the larger scale of deployment. The technical controls such as web & e-mail security, patch management, security information and event management (SIEM), vulnerability management services and others are available by SecaaS providers. When the centralized technology infrastructure is combined with the aggregation of knowledge and expertise of security professionals, the SecaaS model attracts many customers especially the SMBs with limited capabilities.

SecaaS relies on the economies of scale from providing a low cost, commodity service, as opposed to a service specifically tailored to a customer’s needs. Possible issue here is if the standardized set of these services can meet the enterprise security policy requirements. Security service providers hire professionals to serve a pool of customers. It is a question if these people understand the specific requirements of the customer and can respond timely during a crisis situation. Lack of transparency for the work practices of these teams is also a possible concern. Moreover, the SecaaS provider may outsource or sub-contract services to third-parties that may not offer the same level of assurance proved earlier.

Conflicts in roles and responsibilities may easily occur and this may not be overseen during the contracting process. Cloud customers are often unaware of the responsibilities assigned to them within the terms of service. Lack of completeness and transparency in terms of use may likely cause gaps which may not be foreseen before a conflict happens. For instance, in case of a security incident, is it always possible to identify the responsibilities of customer and provider clearly? Are there any scenarios overlooked? It may not be possible to identify clear line of responsibilities for all cases especially in case of challenges in fault isolation (is it an application issue? or a network issue?). Disputes may be likely happen in a complex incident if there are various parties involved in support of the service.

Weak security metrics is another issue as security functions are assumed as successful by tradition if there is no security incident with adverse impact to business operation occurs. Lack of transparency is a generic cloud issue and SecaaS providers are less likely to be transparent due to the concerns of maintaining appropriate levels of security for their operations. There are several standards and guidance available to assess the security practices of cloud vendors but covering all of the components may become a cumbersome process.

The security domains of the IT ecosystem are versatile and security controls need to be harmonized in coherence. It makes sense to provision some or many of the components in forms of public cloud services. Nevertheless, coherence of these controls is the main challenge that needs to be addressed by a security architecture framework. Several cloud providers package security solutions together combining technical and process controls with professional security services. Again, standardizing and packaging security solutions may not be appropriate for the whole customer base due to the customized set of policies and requirements.

All these concerns are manageable with effective governance and risk management activities. The obvious benefits of cloud models such as dynamic scalability, virtually unlimited resources, rapid deployment and others provide several opportunities. Enterprises can maximize value by balancing the risks and opportunities in line with their risk appetite and strategy.

Cloud Security Alliance published an extensive list of requirements and recommendations for the areas of critical focus* that can be referenced during this process. I also highlighted the key points of this writing below for consideration of practitioners planning to integrate SecaaS services for enterprise use.
  • Develop a security architecture framework (can be detailed depending on the business size). Establish your security services sourcing strategy.
  • Establish a risk based decision process to deliver building blocks of security services in forms of public cloud security services.
  • Work the prospective contract in detail. Make sure all processes are covered (ITIL provides very good guidance for the required processes). Responsibilities of parties and service metrics should be well defined.
  • Always make a trial. Assess the maturity of the SecaaS provider by having low risk services with limited scope.
  • In order to address possible conflicts, make sure that technical and hierarchical escalation paths are available and communicated properly.
  • Find out if there are third party dependencies. A customer may choose a particular cloud provider because of the conditions it offers, its reputation or professionalism, or its technical skills.
  • Keep in-house expertise for technical governance of the SecaaS service. The information from technical controls can be consumed by intermediate roles / processes within provider’s control but in house expertise should always be persistent to govern the process.

* "Security Guidance for Critical Areas of Focus in Cloud Computing" by Cloud Security Alliance.(https://cloudsecurityalliance.org/research/security-guidance/).