20

ISSA PREEMINENT TRUSTED GLOBAL

INFORMATION SECURITY COMMUNITY

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.

By Marcelo Carvalho – ISSA member, Brasil Chapter

SECaaS – Security as a Service

AbstractCloud 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 “uncon-trolled” 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.

Cloud essentials

Cloud computing is defined as a large scale, distributed computing paradigm, driven by economies of scale, in which a pool of abstracted, virtualized, dynami-

cally 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 deliver-ies are typically imple mented as Wapp/WS, while PaaS de-liveries provide development and runtime environments for web applications and services. For Infrastructure as a Service (IaaS), administrators typically implement associated servic-

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

es and APIs, such as the management access for customers, using Wapp/WS.2

These services are delivered through four cloud-based mod-els: 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 Sev-eral security tools available in non-cloud environments could be offered such as IDS as a Service, Virus Protection as a Ser-vice, Logging as a Service, Identity Management as a Service, Cryptography as a Service, and many others addressing cloud vulnerabilities.

Cloud vulnerabilitiesA vulnerability could be said to be cloud specific if it is intrin-sic 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 man-agement, low or no ability to monitor and control operational access or service management actions (i.e., change manage-ment, patch management, vulnerability management, etc.); or is caused when cloud environments make traditional con-trols ineffective, difficult, or impossible to implement, e.g., monthly security audit, forensics, or security assessments, etc.

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_cloud-definition.pdf.

4 Cloud Computing: Business Benefits With Security, Governance and Assurance Perspectives, ISACA, 2009.

5 Peter Mell,Timothy Grance.

ISSA Journal | October 2011

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

21

SECaaS-Security as a Service | Marcelo Carvalho

Cloud computing’s core technologies such Wapp/WS, vir-tualization, and cryptography have vulnerabilities that are either intrinsic to the technology or prevalent in the cloud implementations. Three examples of such vul nerabilities are virtual machine escape (intrinsic), session abuse or hijack (prevalent), and insecure confidentiality methods (preva-lent). For instance, the lack of sufficient network controls over IaaS platforms from outside and limited use of stan-dard 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 plu-ral virtual machines hosted on the same physical machine commu nicate. Thus, the boundaries from hosted applica-tions 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 there-fore 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 com puting infrastructure requires management and stor age 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 vulner ability for cloud systems in that the probability of unau thorized access could occur in much higher scale than for traditional systems where the manage-ment func tionality is accessible only to a limited number of administrators. Since ubiquitous network access implies cloud services being accessed via traditional, standard pro-tocols over the Internet, the embedded vulnerabilities of an untrusted network also pose a threat to cloud services.

Security perceptionTrust can have an enormous importance to the success or failure of any cloud service. From the user’s 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. Secu-

6 Memory Dispatcher,USP-Artur Baruchi, 2010.

7 User experience and Security in the Cloud, Nilay Oza, Kaarina Karppinen, Reijo Savola, 2010.

rity auditing and monitoring from a client/user perspective is then difficult or impractical.

To diminish this feeling of enclosed solutions and gain vis-ibility 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 recommen-dations followed. One, based on CSA best practices is the Se-curity, 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 SE-CaaS offered at different cloud providers raise new is-sues?

• 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 se-curity and privacy compliance concerns include the Privacy Act of 1974 and the Federal Information Se-curity Management Act (FISMA) of 2002. For Brasil this includes E-PING9 among others.

SECaaS challengesDelivering Security as a Service on a cloud basis is not trivial, considering the various architectural, functional, and intrin-sic aspects, some of them discussed briefly in this article. A worldwide accepted framework/taxonomy for security deliv-ery, 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

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

AdvantagesMultiple 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-e-ping-versao-2011/, (last viewed 9-22-2011).

ISSA Journal | October 2011

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

22

SECaaS-Security as a Service | Marcelo Carvalho

limitations); in the cloud there could be multiple SECaaS so-lutions 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 ad-vantage, 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 manage-ment, allows an organization to devote more time to its core competencies.

Ready: Automated fail over capabilities and higher SLA as-surance can be a possible cloud advantage that also applies to SECaaS.

RisksDomino 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 expe-rienced in the event of a service being broken/hacked, gen-erating 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 com-pensate 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 character-istics to available security treatment if affected or restricted somehow.

SECaaS examples

Crypto co-processorSeveral proposals to address one or more cloud security chal-lenges 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, in-tegrity, 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 defin-ing security based on trust models. The protocol aims to en-crypt 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.

cryptographic co-processor, which can only take care of ei-ther encryption or decryption to the cloud scope. Techni-cally, 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 solu-tion 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.

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 encryp-tion is not needed. Before storing any data, the cloud vendor may then ask whether that data has to be segmented and bet-ter 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 scanningAnother interesting proposal addresses the virtualizations offered, so cloud consumers could have a standard and best-practices aligned SECaaS service checking on their in-frastructure 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-agnos-tic detection of unpatched code in a VM.

Figure 2 – Patch audit suggested diagram

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

Header Encrypted Data Tail

Buffer In

Operation Control

Algorithm Core

Buffer Out

Patched Binary DB Interpreter DB Unpatched Binary DB

Unpatched Non-Binary DB

SECasS Interface

SECasS Access Control

IaaS VMs

ISSA Journal | October 2011

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

24

SECaaS-Security as a Service | Marcelo Carvalho

foundation for this SECaaS implementation. In this scenario, the client admin of this SECaaS feature could take full con-trol 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 Account ID

Owned Service marcelo.carvalho

Collaboration Service marcelo@issa.org

Table 1 – The accounts assigned to author

Secondly, the admin would create a cross-service access be-tween owned service and collaboration services linking the identification thru SECaaS.

Source Service Target Service Cross Service Access-Type/Action

Owned Service Collaboration Service Allow SSO

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 re-quired for enabling SSO between these two services, the tran-sitive 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 SE-CaaS. The management of trust relationships among parties, foundation of a federation solution, can not only promote easy access to cloud published services requiring identifica-tion but also seamless alignment to enterprise governance.

ConclusionAs 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/challeng-es items, maybe resulting in solution packages available to the end user.

About the AuthorMarcelo Carvalho, CISSP, CISA, CRISC, has 12 years of information security ex-perience 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 mem-ber 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.

performance degradation, especially in the cloud due greater diversity of OSs and software environments and previously discussed isolation issues. We must consider as well, even-tual performance reduction. For example, Lionel Litty and David Lie’s 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 ser-vice 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.

Identity management as a service (IMaaS)A third interesting reading and possible implementation as SECaaS I’d like to highlight is “Identity Federation Broker” (IFB). It addresses identification and accounting cloud issues, which are particularly important for Internet-facing environ-ments. 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 in-tegrations for authentication purposes and simplify identity management, especially for those having a large number of in-cloud service users. The solution components include bro-ker server, service/on-premise gateway, and gateway plug-in. The IFB proposes an identity federation broker that introduc-es 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 bro-kering the cross-service access and identity control.

A few well-known open standards and specifications for identity federation, such as Security Assertion Markup Lan-guage (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/Cloud-Top10-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.0-cd-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.2-spec-cs-01.doc (last viewed 9-22-2011).

ISSA Journal | October 2011

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