ISSA

PREEMINENT TRUSTED GLOBAL INFORMATION SECURITY COMMUNITY

ISSA Journal | October 2011

SECaaS Security as a Service

By Marcelo Carvalho ISSA member, Brasil Chapter
This article explores Security as a Service, a necessary trend meant to cover the various security gaps in the different types and models of cloud implementations.

Abstract
Cloud computing offers enterprises many advantages and cost savings through Software as a Service, Platform as a Service, and Infrastructure as a Service offerings. However, one of the barriers for more widespread cloud adoption is the sense of lack of security in the unknown and uncontrolled structure. This article explores Security as a Service, a necessary trend meant to cover the various security gaps in the different types and models of cloud implementations.

es and APIs, such as the management access for customers, using Wapp/WS.2 These services are delivered through four cloud-based models: Public, Private, Community, and Hybrid.3 Each of these has associated potential threats we should be aware of as well. Security as a Service (SECaaS) can address a number of cloud security needs in the same way we see other deliveries.4 Several security tools available in non-cloud environments could be offered such as IDS as a Service, Virus Protection as a Service, Logging as a Service, Identity Management as a Service, Cryptography as a Service, and many others addressing cloud vulnerabilities.

Cloud essentials

loud computing is defined as a large scale, distributed computing paradigm, driven by economies of scale, in which a pool of abstracted, virtualized, dynamically scalable, managed computing power, storage, platforms, and services are delivered and made available on demand to customers over the Internet.1 Cloud computing offers the possibility of high reward in terms of containment of costs and features such as agility and provisioning speed. However, as a new initiative, it also brings the potential for high risk. Software as a Service (SaaS) and Platform as a Service (PaaS) are deeply tied to web application (Wapp) and web services(WS) technologies and vulnerabilities. SaaS deliveries are typically implemented as Wapp/WS, while PaaS deliveries provide development and runtime environments for web applications and services. For Infrastructure as a Service (IaaS), administrators typically implement associated servic-

Cloud vulnerabilities
A vulnerability could be said to be cloud specific if it is intrinsic to the core cloud computing technology, e.g., data custody or physical access control; has its root cause in one or more essential cloud characteristics,5 e.g., cryptographic key management, low or no ability to monitor and control operational access or service management actions (i.e., change management, patch management, vulnerability management, etc.); or is caused when cloud environments make traditional controls ineffective, difficult, or impossible to implement, e.g., monthly security audit, forensics, or security assessments, etc.

1 Modeling and Performance Analysis on Network Virtualization for Composite NetworkCloud Service Provisioning, Qiang Duan, 2011; Cloud Computing and Grid Computing 360-Degree Compared, Proc. Grid Computing Environments, Ian Foster, 2008, pages 110.

2 Management of Security in Cloud Computing, Ramgovind S, Eloff MM, Smith E, 2010. 3 Peter Mell,Timothy Grance, The NIST Definition of Cloud Computing (SP 800-145), 2011, http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_clouddefinition.pdf. 4 Cloud Computing: Business Benefits With Security, Governance and Assurance Perspectives, ISACA, 2009. 5 Peter Mell,Timothy Grance.

20

2011 Information Systems Security Association www.issa.org editor@issa.org All rights reserved

SECaaS-Security as a Service | Marcelo Carvalho

ISSA Journal | October 2011

Cloud computings core technologies such Wapp/WS, virtualization, and cryptography have vulnerabilities that are either intrinsic to the technology or prevalent in the cloud implementations. Three examples of such vulnerabilities are virtual machine escape (intrinsic), session abuse or hijack (prevalent), and insecure confidentiality methods (prevalent). For instance, the lack of sufficient network controls over IaaS platforms from outside and limited use of standard scan techniques can result in a scenario where white hat checkings/testings cannot be distinguished from attacker activity. Hence, a close integration with the virtual machine manager (VMM) and a controlled inside approach to ensure full network traffic visibility seems to be actually missing. Also, virtualization implies that network traffic occurs on both real and virtual network interfaces, such as when plural virtual machines hosted on the same physical machine communicate. Thus, the boundaries from hosted applications could pose a real threat. For the same insulation issue, resources reuse is a concern. Due to cloud characteristics of pooling and elasticity, resources allocated to one user may be reallocated to a different user at a later time. It might therefore be possible to recover/retrieve data written by a previous user (possibly in a malicious way) from memory, memory dispatcher,6 or storage resources. For encryption purposes, the cloud computing infrastructure requires management and storage of many different kinds of keys. It is hard to adopt conventional controls to store and manage keys such as hardware security modules (HSM) due to virtualization and the geographically distributed nature of the cloud. Unauthorized access to the management interface is also an especially relevant vulnerability for cloud systems in that the probability of unauthorized access could occur in much higher scale than for traditional systems where the management functionality is accessible only to a limited number of administrators. Since ubiquitous network access implies cloud services being accessed via traditional, standard protocols over the Internet, the embedded vulnerabilities of an untrusted network also pose a threat to cloud services.

rity auditing and monitoring from a client/user perspective is then difficult or impractical. To diminish this feeling of enclosed solutions and gain visibility into the processes, a few initiatives are trying to cast what is inside the services, allowing providers to publish their embedded security, including specifications and recommendations followed. One, based on CSA best practices is the Security, Trust & Assurance Registry (STAR) initiative which encourages transparency of security practices within cloud providers.8 Even though, many unanswered questions still remain: Will integration and dependency issues between SECaaS offered at different cloud providers raise new issues? Seeking compliance, will SECaaS sufficiently adhere to existing and new standards such as HIPAA, SOX, PCI, SAS 70? For U.S. federal agencies, the major security and privacy compliance concerns include the Privacy Act of 1974 and the Federal Information Security Management Act (FISMA) of 2002. For Brasil this includes E-PING 9 among others.

SECaaS challenges
Delivering Security as a Service on a cloud basis is not trivial, considering the various architectural, functional, and intrinsic aspects, some of them discussed briefly in this article. A worldwide accepted framework/taxonomy for security delivery, including minimal specifications, seems to be the bigger actual challenge. Current research from groups mentioned above includes but is not limit to the following areas: Abuse and nefarious use of cloud computing Insecure application programming interfaces Malicious insiders Shared technology vulnerabilities Data loss/leakage Account, service, and traffic hijacking Unknown risk profile

Security perception
Trust can have an enormous importance to the success or failure of any cloud service. From the users perspective, cloud services are often seen as black boxes. Thus, despite contracts and policies surrounding cloud environments, it is difficult to perceive security applied.7 Also, security metrics are not adapted to cloud infrastructures and cannot be easily managed by outsiders. Despite huge efforts such as the Cloud Security Alliance (CSA), ISO/IEC SC27 WG4, and other working groups, there are no current cloud-specific security metrics that cloud customers can use to monitor the security status of their cloud resources in a standard manner. Secu6 Memory Dispatcher,USP-Artur Baruchi, 2010. 7 User experience and Security in the Cloud, Nilay Oza, Kaarina Karppinen, Reijo Savola, 2010.

What do we gain?
By using SECaaS, a cloud customer could access a diverse set of tools (services) to address security. But with these advantages come potential risks.

Advantages
Multiple services: At the corporate environment level we typically choose security tools from one vendor or an other or from one technology or an other (usually due to budget

8 CSA Security, Trust & Assurance Registry (STAR), https://cloudsecurityalliance.org/ star/ (last viewed 9-20-2011). 9 E-PING, http://www.governoeletronico.gov.br/biblioteca/arquivos/documento-da-eping-versao-2011/, (last viewed 9-22-2011).

2011 Information Systems Security Association www.issa.org editor@issa.org All rights reserved

21

SECaaS-Security as a Service | Marcelo Carvalho

ISSA Journal | October 2011

limitations); in the cloud there could be multiple SECaaS solutions for the same purpose so users can choose convenience. On-demand costs: For the same reasons cloud services are valued, the security offerings will also better suit on-demand needs including the advantage of no permanent investments. Focused: The specialized profile of the services is another advantage, if you think that cloud providers offering SECaaS are focused and therefore better prepared to deliver state-of-art products. Outsourcing of security tasks, such as log management, allows an organization to devote more time to its core competencies. Ready: Automated fail over capabilities and higher SLA assurance can be a possible cloud advantage that also applies to SECaaS.

cryptographic co-processor, which can only take care of either encryption or decryption to the cloud scope. Technically, this encryption and spread storage could be achieved by adding chunk, customer ID, and other items to the header and tail of customer-processed data (Figure 1). The service will offer customers the control over the encryption solution by interacting with the Operation Control. A good thing among possible interactions is the ability to set key, mode, algorithm(s) used so users do not need to rely on built-in, predefined security mechanisms, making their own security provisioning.

Operation Control Buffer Out Buffer In Algorithm Core Encrypted Data

Risks
Domino effect: Nonetheless, the ubiquitous and replicated SECaaS can negatively affect the whole cloud context in the event of security feature malfunction or weaknesses found generating a cascading scenario. This effect might be experienced in the event of a service being broken/hacked, generating a domino effect due the magnitude of scale the cloud offers. Shared: From a risk perspective, a shared tool can concern a more skeptical user, but the centralized concept can compensate by delivering patched, updated, and best practices aligned solutions. General approach: By using centralized solutions though, the limitation of customization on services deliveries might force a consumer to adapt processes or business characteristics to available security treatment if affected or restricted somehow.

Header

Tail

Figure 1 Crypto co-processor architecture and encrypted data structure

A customer may not be storing sensitive data all the times, though. In that case the extra time and processing of encryption is not needed. Before storing any data, the cloud vendor may then ask whether that data has to be segmented and better secured through the solution interface. This procedure could provide for on-demand billing for the SECaaS, possibly reducing customer costs based on label and security of their data.

IaaS assessment scanning

Another interesting proposal addresses the virtualizations offered, so cloud consumers could have a standard and best-practices aligned SECaaS service checking on their infrastructure and better securing systems by hardening and patching them. Since the administration and control of these machines is mostly handed to cloud client, a service that could scan and evaluate their security status, alerting system owners about misconfigurations or vulnerabilities, might be very useful, suggesting corrections and patches for resuming secure state (Figure 2). The idea could be applied at different testing levels, from simple service banner exam to OS-agnostic detection of unpatched code in a VM.
SECasS Interface SECasS Access Control
Patched Binary DB Interpreter DB Unpatched Binary DB Unpatched Non-Binary DB

SECaaS examples
Crypto co-processor
Several proposals to address one or more cloud security challenges emerge from academic or industry specifics daily. One that caught my attention, maybe because of my cryptography background, is called Securing User Data by Co-Processor and Distributing the Data,10 addressing confidentiality, integrity, and key management in the cloud. The mechanism achieves maximum security by leveraging the capabilities of a processor called a cryptographic co-processor and relies on customer/client ability to enhance the security by defining security based on trust models. The protocol aims to encrypt data by dividing and distributing it within the cloud as chunks. Unlike processors, co-processors cannot fetch instructions from memory. Cryptographic co-processors help in defining the security protocols and implementing them. This solution assumes the use of a dedicated set of hardware that forms a
10 Security as a Service (SasS), Praveen Ram C, Sreenivaasan G, 2010.

IaaS VMs
Figure 2 Patch audit suggested diagram

Unfortunately, patches can have unintended side effects; unnecessary patches can needlessly cause system failures or

22

2011 Information Systems Security Association www.issa.org editor@issa.org All rights reserved

SECaaS-Security as a Service | Marcelo Carvalho

ISSA Journal | October 2011

performance degradation, especially in the cloud due greater diversity of OSs and software environments and previously discussed isolation issues. We must consider as well, eventual performance reduction. For example, Lionel Litty and David Lies implemented prototype of binary and non-binary checking experiments showed that it accurately reports the execution of unpatched code while imposing performance overhead of 4%.11 Imagine a scenario that allows a customer to reliably and remotely determine whether the service backend is running in a trusted/scanned environment before requesting the service from the cloud (like a tag or WS response, for instance). Moreover, this SECaaS capability could extend the notion of attestation to the entire service by comparing and testing it against knowledge databases, and thus allowing a customer to verify if its computation will run more securely12 as well as possibly reducing the exploitable window of vulnerable states of tested cloud systems.

foundation for this SECaaS implementation. In this scenario, the client admin of this SECaaS feature could take full control over the federated single sign-on (SSO) between owned and collaboration services. If we see it done in two phases, first the admin would assign accounts of the owned service and the collaboration services to members/users. Service Name Owned Service Collaboration Service Account ID marcelo.carvalho marcelo@issa.org

Table 1 The accounts assigned to author

Secondly, the admin would create a cross-service access between owned service and collaboration services linking the identification thru SECaaS. Source Service Owned Service Target Service Collaboration Service Cross Service Access-Type/Action Allow SSO

Identity management as a service (IMaaS)

A third interesting reading and possible implementation as SECaaS Id like to highlight is Identity Federation Broker (IFB). It addresses identification and accounting cloud issues, which are particularly important for Internet-facing environments. These two are actually at the top of the OWASP Cloud Top 10 Security Risks that should be addressed by security controls.13 For service providers, typical pairwise identity federation solutions are not scalable to support single sign-on service composition for large environment like SaaS.14 Thus, this solution could possibly address multiple cloud provider integrations for authentication purposes and simplify identity management, especially for those having a large number of in-cloud service users. The solution components include broker server, service/on-premise gateway, and gateway plug-in. The IFB proposes an identity federation broker that introduces a trusted third party (SECaaS entity) as a trust broker for establishing identity federation between services in cloud or across clouds in a user-centric approach. The broker server, as the core of the solution, is in charge of managing and brokering the cross-service access and identity control. A few well-known open standards and specifications for identity federation, such as Security Assertion Markup Language (SAML)15 and WS-Federation16 could be used as the
11 Patch Auditing in Infrastructure as a Service Clouds, Lionel Litty, David Lie, 2011. 12 Infrastructure as a Service Security: Challenges and Solutions, Wesam Dawoud, Ibrahim Takouna, Christoph Meinel, 2011. 13 OWASP Cloud Top 10 Security Risks, http://www.owasp.org/images/4/47/CloudTop10-Security-Risks.pdf , (last viewed 9-22-2011). 14 Identity Federation Broker for Service Cloud, He Yuan Huang, Bin Wang, Xiao Xi Liu, Jing Min Xu, 2011. 15 Security Assertion Markup Language (SAML) V2.0 Technical Overview, http://www. oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0cd-02.pdf (last viewed 9-22-2011). 16 Web Services Federation Language (WS-Federation) Version 1.2 Specification, http://www.oasis-open.org/committees/download.php/31658/ws-federation-1.2spec-cs-01.doc (last viewed 9-22-2011).

Table 2 Cross service access configuration for SECaaS SSO

In this process, the admin does not need to understand any security- or federation-related concepts. As federation is required for enabling SSO between these two services, the transitive federation between them is established transparently. Imagine a scenario where we could publish applications in different SaaS environments at possibly different providers and hand customer identification in a secure manner to SECaaS. The management of trust relationships among parties, foundation of a federation solution, can not only promote easy access to cloud published services requiring identification but also seamless alignment to enterprise governance.

Conclusion
As we have seen briefly, the security in the cloud environment is a great concern and there are a few fronts dealing with how to address it properly, preferably in a systematic approach. The offer of necessary protection can be done in the same format as other cloud deliveries: as a service (SECaaS). This could be achieved as a whole solution or as part of an actual scenario protection but preferably (more feasibly achieved) granularly addressing one or few security domains/challenges items, maybe resulting in solution packages available to the end user.

About the Author

Marcelo Carvalho, CISSP, CISA, CRISC, has 12 years of information security experience at telecom and digital certificate companies and is currently an IS auditor for Information Assurance Security IAS Brasil in Sao Paulo, Brasil. He is a member of ISSA Brasil Chapter and an active participant in chapter lectures and courses related to CISSP preparation. He may be contacted at marcelo. carvalho@ieee.org.

24

2011 Information Systems Security Association www.issa.org editor@issa.org All rights reserved