DOMAIN 14

SECURITY AS A SERVICE

Cloud Computing represents one of the most significant shifts in information technology the industry has experienced. Reaching the point where computing functions as a utility has great potential, promising expansive innovations. One such innovation is the centralization of security resources.

The security industry has recognized the benefits of a standardized security framework for both the providers and consumers. In the context of a cloud service level agreement between providers and consumers, a standardized security framework takes the form of a document that specifies which security services are provided how and where.

With the maturation of security offerings based on standard frameworks, cloud consumers have recognized the need to centralize computing resources for providers and consumers.One of the milestones of the maturity of cloud as a platform for business operations is the adoption of Security as a Service (SecaaS) on a global scale and the recognition of how security can be enhanced.

The worldwide implementation of security as an outsourced commodity will eventually minimize the disparate variances and security voids.

SecaaS is looking at Enterprise security from the cloud – this is what differentiates it from most of the other work / research on cloud security.
Predominantly cloud security discussions have focused on how to migrate to the Cloud and how to ensure Confidentiality, Integrity, Availability and Location are maintained when using the Cloud.

SecaaS looks from the other side to secure systems and data in the cloud as well as hybrid and traditional enterprise networks via cloud-based services.
These systems may be in the cloud or more traditionally hosted within the customer’s premises. An example of this might be the hosted spam and AV filtering.

Overview. This domain will address the following topics:

I) The Ubiquity of Security as a Service in the Marketplace
II) Concerns when Implementing Security As a Service
III) Advantages of Implementing Security As a Service
IV) The Diversity of Services that can be categorized as Security As A

Service

14.1 Ubiquity of Security as a Service

Customers are both excited and nervous at the prospects of cloud computing. They are excited by the opportunities to reduce capital costs and excited for a chance to divest infrastructure management and focus on core competencies.

Most of all, they are excited by the agility offered by the on-demand provisioning of computing resources and the ability to align information technology with business strategies and needs more readily.

However, customers are also very concerned about the security risks of cloud computing and the loss of direct control over the security of systems for which they are accountable.

Vendors have attempted to satisfy this demand for security by offering security services in a cloud platform, but because these services take many forms and lack transparency regarding deployed security controls, they have caused market confusion and complicated the selection process.

This has led to limited adoption of cloud-based security services thus far. Security as a Service is experiencing an exponential growth with Gartner predicting that cloud-based security service usage will more than triple in many segments by 2013.

Numerous security vendors are now leveraging cloud-based models to deliver security solutions. This shift has occurred for a variety of reasons including greater economies of scale and streamlined delivery mechanisms.

Consumers are increasingly faced with evaluating security solutions that do not run on premises. Consumers need to understand the unique, diverse, and pervasive nature of cloud delivered security offerings so that they are in a position to evaluate the offerings and to understand if the offerings will meet their needs.

14.2 Concerns When Implementing Security as a Service

Despite the impressive array of benefits provided by cloud security services such as dynamic scalability, virtually unlimited resources, and greater economies of scale that exist with lower or no cost of ownership, there are concerns about security in the cloud environment. Some security concerns are around compliance, multi-tenancy, and vendor lock-in. While these are being cited as inhibitors to the migration of security into the cloud, these same concerns exist with traditional data centers.

Security in the cloud environment is often based on the concern that lack of visibility into security controls implemented means systems are not locked down as well as they are in traditional data centers and that the personnel lack the proper credentials and background checks. Security as a Service providers recognize the fragility of the relationship and often go to extreme lengths to ensure that their environment is locked down as much as possible. They often run background checks on their personnel that rival even the toughest government background checks, and they run them often. Physical and personnel security is one of the highest priorities of a Security as a Service provider.

Compliance has been raised as a concern given the global regulatory environment. Security as a Service providers have also recognized this and have gone to great efforts to demonstrate their ability to not only meet but exceed these requirements or to ensure that it is integrated into a client’s network. Security as a Service providers should be cognizant of the geographical and regional regulations that affect the services and their consumers, and this can be built into the offerings and service implementations. The most prudent Security as a Service providers often enlist mediation and legal services to preemptively resolve the regulatory needs of the consumer with the regional regulatory requirements of a jurisdiction. When deploying Security as a Service in a highly regulated industry or environment, agreement on the metrics defining the service level required to achieve regulatory objectives should be negotiated in parallel with the SLA documents defining service.

As with any cloud service, multi-tenancy presents concerns of data leakage between virtual instances. While customers are concerned about this, the Security as a Service providers are also highly concerned in light of the litigious nature of modern business. As a result, a mature offering may take significant precautions to ensure data is highly compartmentalized and any data that is shared is anonymized to protect the identity and source. This applies equally to the data being monitored by the SecaaS provider and to the data held by them such as log and audit data from the client’s systems (both cloud and non-cloud) that they monitor.

Another approach to the litigious nature of multi-tenant environments is increased analytics coupled with semantic processing. Resource descriptors and applied jurimetrics, a process through which legal reasoning is interpreted as high-level concepts and expressed in a machine-readable format, may be employed proactively to resolve any legal ambiguity regarding a shared resource.

When utilizing a Security as a Service vendor, an enterprise places some, many or all security logging, compliance, and reporting into the custody of a provider that might sometimes have proprietary standards. In the event the enterprise seeks a new provider, they must concern themselves with an orderly transition and somehow find a way for the existing data and log files to be translated correctly and in a forensically sound manner.

It is important to note that other than multi-tenancy, each of these concerns is not “cloud unique” but are problems faced by both in-house models and outsourcing models. For this reason, non-proprietary unified security controls, such as those proposed by the Cloud Security Alliance Cloud Control Matrix, are needed to help enterprises and vendors benefit from the Security as a Service environment.

14.3 Advantages When Implementing Security as a Service

The potential strategic benefits of leveraging centralized security services are well understood by technical experts who witness the daily efficiencies gained. Just as cloud computing offers many advantages to both providers and consumers, Cloud Security as a Service offers many significant benefits due to a number of factors, including aggregation of knowledge, broad actionable intelligence, and having a full complement of security professionals on hand at all times, to name a few. Companies that are actively involved in the centralization and standardization of security best practices typically gain significant medium and long-term cost savings and competitive benefits over their rivals in the market due to the efficiencies gained. Security delivered as a service enables the users of security services to measure each vendor by a singular security standard thus better understanding what they are getting.

14.3.1 Competitive Advantages

Companies that employ third party security service providers gain a competitive edge over their peers due to early access to information helpful in understanding the risk proposition of a given IT strategy. Furthermore, through the use of a centralized security infrastructure, consumers are better able to stem the inclusion of undesirable content. Companies making use of a third party to report on regulatory compliance and measure obligatory predicates —the inherited legal and contractual obligations connected to identities and data—might result in the avoidance of costly litigation and fines that their competitors are vulnerable to. Once holistic security services are adopted and implemented, providers reap the competitive benefits of being able to assure their clients that they meet security best practice. Clients making use of these services have the advantage of being able to point to security providers as a part of their compliance framework and to third party assurance providers for proof of the achievement of service level agreement obligations.

14.3.2 Improved Vendor Client Relationship

There are many clear-cut benefits of security as a service. Transparency provided by a third party assurance service enables customers to understand exactly what they are getting, enabling easier comparison of vendor services and holding vendors to clear and agreed standards. Migration services enable the migration of data and services from one vendor to another. By leveraging migration services, consumers and providers are better enabled to exert market
pressures on their tertiary suppliers, enhancing the value for the enterprises that consume the services and securing the supply chain.

14.4 Diversity of Existing Security as a Service Offerings

Security as a Service is more than an outsourcing model for security management; it is an essential component in secure business resiliency and continuity. As a business resiliency control, Security as a Service offers a number of benefits. Due to the elastic model of services delivered via the cloud, customers need only pay for the amount they require, such as the number of workstations to be protected and not for the supporting infrastructure and staffing to support the various security services. A security focused provider offers greater security expertise than is typically available within an organization. Finally, outsourcing administrative tasks, such as log management, can save time and money, allowing an organization to devote more resources to its core competencies.

Gartner predicts that cloud-based security controls for messaging applications such as anti-malware and anti-spam programs will generate 60 percent of the revenue in that industry sector by 2013.

The areas of Cloud Security as a Service that most likely will interest consumers and security professionals are:

a) Identity Services and Access Management Services
b) Data Loss Prevention (DLP)
c) Web Security
d) Email Security
e) Security Assessments
f) Intrusion Management, Detection, and Prevention (IDS/IPS)
g) Security Information and Event Management (SIEM)
h) Encryption
i) Business Continuity and Disaster Recovery

j) Network Security

14.4.1 Identity, Entitlement, and Access Management Services

Identity-as-a-service is a generic term that covers one or many of the services that may comprise an identity eco-system, such as Policy Enforcement Points (PEP-as-a-service), Policy Decision Points (PDP-as-a-service), Policy Access Points (PAP-as-a-service), services that provide Entities with Identity, services that provide attributes, and services that provide reputation.

All these Identity services can be provided as a single stand-alone service, as a mix-and-match service from multiple providers, or today most probably a hybrid solution of public and private, traditional IAM, and cloud services.

These Identity services should provide controls for identities, access, and privileges management. Identity services need to include people, processes, and systems that are used to manage access to enterprise resources by assuring the identity of an entity is verified, then granting the correct level of access based on this assured identity. Audit logs of activities such as successful and failed authentication and access attempts should be managed by the application / solution or the SIEM service. Identity, Entitlement, and Access Management services are a Protective and Preventative technical control.

14.4.2 Data Loss Prevention

Monitoring, protecting, and demonstrating protection of data at rest, in motion, and in use both in the cloud and on premises, Data Loss Prevention (DLP) services offer protection of data usually by running as a client on desktops / servers and enforcing policies around what actions are authorized for particular data content. Where these differ from broad rules like ‘no ftp’ or ‘no uploads to web sites’ is the level to which they understand data, e.g., the user can specify no documents with numbers that look like credit cards can be emailed; anything saved to USB storage is automatically encrypted and can only be unencrypted on another office owned machine with a correctly installed DLP client; and only clients with functioning DLP software can open files from the file server. Within the cloud, DLP services may be offered as something that is provided as part of the build such that all servers built for that client get the DLP software installed with an agreed set of rules deployed. In addition, DLP may leverage central ID- or cloud brokers to enforce usage profiles. The ability to leverage a service to monitor and control data flows from an enterprise to the various tiers in the cloud service supply chain may be used as a preventative control for transborder transport, and subsequent loss, of regulated data such as PII. This DLP offering is a preventative technical control.

PII-Personally Identifiable Information

14.4.3 Web Security

Web Security is real-time protection offered either on premise through software / appliance installation or via the Cloud by proxying or redirecting web traffic to the cloud provider. This provides an added layer of protection on top of other protection such as anti-malware software to prevent malware from entering the enterprise via activities such as web browsing. Policy rules around types of web access and the time frames when this is allowed can also be enforced via these technologies. Application authorization management can be used to provide an extra level of granular and contextual security enforcement for web applications. Web Security is a protective, detective, and reactive technical control.

14.4.4 Email Security

Email Security should provide control over inbound and outbound email, protecting the organization from phishing, malicious attachments, enforcing corporate polices such as acceptable use and spam prevention, and providing business continuity options. In addition, the solution should allow for policy-based encryption of emails as well as integrating with various email server solutions. Digital signatures enabling identification and non-repudiation are also features of many email security solutions. The Email Security offering is a protective, detective, and reactive technical control.

14.4.5 Security Assessment

Security assessments are third party or customer-driven audits of cloud services or assessments of on premises systems via cloud provided solutions based on industry standards. Traditional security assessments for infrastructure, applications and compliance audits are well defined and supported by multiple standards such as NIST, ISO, and CIS 144. A relatively mature toolset exists, and a number of tools have been implemented using the SecaaS delivery model. In the SecaaS delivery model, subscribers get the typical benefits of this cloud-computing variant—elasticity, negligible setup time, low administration overhead, and pay per use with low initial investments.

While not the focus of this effort, additional challenges arise when these tools are used to audit cloud environments. Multiple organizations, including the CSA have been working on the guidelines to help organizations understand the additional challenges:

a) Virtualization awareness of the tool, frequently necessary for IaaS platform auditing
b) Support for common web frameworks in PaaS applications
c) Compliance Controls for Iaas, PaaS, and Saas platforms

d) Automated incident and breach notification tools for maintenance of cloud supply chain integrity
e) Standardized questionnaires for XaaS environments, that help address:
- What should be tested in a cloud environment?
- How does one assure data isolation in a multi-tenant environment?
- What should appear in a typical infrastructure vulnerability report?

- Is it acceptable to use results provided by cloud provider?

14.4.6 Intrusion Detection/Prevention (IDS/IPS)

Intrusion Detection/Prevention systems monitor behavior patterns using rule-based, heuristic, or behavioral models to detect anomalies in activity that present risks to the enterprise. Network IDS/IPS have become widely used over the past decade because of the capability to provide a granular view of what is happening within an enterprise network. The IDS/IPS monitors network traffic and compares the activity to a baseline via rule-based engine or statistical analysis. IDS is typically deployed in a passive mode to passively monitor sensitive segments of a client’s network whereas the IPS is configured to play an active role in the defense of the clients network. In a traditional infrastructure, this could include De-Militarized Zones (DMZ’s)145 segmented by firewalls or routers where corporate Web servers are locate or monitoring connections to an internal database. Within the cloud, IDS systems often focus on virtual infrastructure and cross-hypervisor activity where coordinated attacks can disrupt multiple tenants and create system chaos. Intrusion Detection Systems are detective technical controls, and Intrusion Prevention Systems are detective, protective, and reactive technical controls.

144 CIS-Center for Internet Security

145 DMZ-De-Militarized Zone

14.4.7 Security Information & Event Management (SIEM)

Security Information and Event Management (SIEM) systems aggregate (via push or pull mechanisms) log and event data from virtual and real networks, applications, and systems. This information is then correlated and analyzed to provide real time reporting and alerting on information or events that may require intervention or other types of responses. The logs are typically collected and archived in a manner that prevents tampering to enable their use as evidence in any investigations or historical reporting. The SIEM Security as a Service offering is a Detective technical control but can be configured to be a protective and reactive technical control.

14.4.8 Encryption

Encryption is the process of obfuscating/ encoding data using cryptographic algorithms, the product of which is encrypted data (referred to as cipher-text). Only the intended recipient or system that is in possession of the correct key can decode (un-encrypt) the cipher-text. Encryption for obfuscation systems typically consist of one or more algorithms that are computationally difficult (or infeasible) to break one or more keys, and the systems, processes, and procedures to manage encryption, decryption, and keys. Each part is effectively useless without the other, e.g., the best algorithm is easy to “crack” if an attacker can access the keys due to weak processes.

In the case of one-way cryptographic functions, a digest or hash is created instead. One-way cryptographic functions include hashing, digital signatures, certificate generation and renewal, and key exchanges. These systems typically consist of one or more algorithms that are easily replicated but very resistant to forgery, along with the processes and procedures to manage them. Encryption when outsourced to a Security as a Service provider is classified as a protective and detective technical control.

14.4.9 Business Continuity and Disaster Recovery

Business Continuity and Disaster Recovery are the measures designed and implemented to ensure operational resiliency in the event of any service interruptions. They provide flexible and reliable failover and DR solutions for required services in the event of a service interruption, whether natural or man-made. For example, in the event of a disaster scenario at one location, machines at different locations may protect applications in that location. This Security as a Service offering is a reactive, protective, and detective technical control.

14.4.10 Network Security

Network Security consists of security services that restrict or allocate access and that distribute, monitor, log, and protect the underlying resource services.

Architecturally, network security provides services that address security controls at the network in aggregate or those controls specifically addressed at the individual network of each underlying resource. In cloud / virtual environments and hybrid environments, network security is likely to be provided by virtual devices alongside traditional physical devices. Tight integration with the hypervisor to ensure full visibility of all traffic on the virtual network layer is key. These Network Security offerings include detective, protective, and reactive technical controls.

14.5 Permissions

A) Implementers may employ pattern recognition of user activities..

B) Implementers may employ secure legal mediation of security metrics for SLA  expectation management


C) Implementers may employ provide trusted channels for penetration testing.

14.6 Recommendations

a) Implementers should ensure secure communication channels between tenant and consumer.

b) Providers should supply automated secure and continuous notification throughout the supply chain on a need-to-know basis.

c) Providers should supply secured logging of internal operations for service level agreement compliance.

d) Consumers should request addition of third party audit and SLA mediation services.


e) All parties should enable Continuous Monitoring of all interfaces through standardized security interfaces such as SCAP (NIST), CYBEX (ITU-T), or RID & IODEF (IETF).

14.7 Requirements 

14.7.1 Identity as a Service Requirements

1) Providers of IaaS must provide cloud customers provisioning/de-provisioning of accounts (of both cloud & on-premise applications and resources).

2) Providers of IaaS must provide cloud customers authentication (multiple forms and factors).

3) Providers of IaaS must provide cloud customers identity life cycle management.

4) Providers of IaaS must provide cloud customers directory services.

5) Providers of IaaS must provide cloud customers directory synchronization (multi-lateral as required).

6) Providers of IaaS must provide cloud customers federated SSO.

7) Providers of IaaS must provide cloud customers web SSO (granular access enforcement & session management - different from federated SSO).

8) Providers of IaaS must provide privileged session monitoring.

9) Providers of IaaS must provide granular access management.

10) Providers of IaaS must provide tamper-proof storage of audit records (including an option for non-repudiation).

11) Providers of IaaS must provide policy management (incl. authorization management, role management, compliance policy management).

12) Providers of IaaS must provide cloud customers authorization (both user and application/system).

13) Providers of IaaS must provide cloud customers authorization token management and provisioning.

14) Providers of IaaS must provide cloud customers user profile and entitlement management (both user and application/system).

15) Providers of IaaS must provide cloud customers support for policy and regulatory compliance monitoring and/or reporting.

16) Providers of IaaS must provide cloud customers federated provisioning of cloud applications.

17) Providers of IaaS must provide privileged user and password management (including administrative, shared, system and application accounts).

18) Providers of IaaS must provide cloud customers Role-Based Access Control (RBAC) (where supported by the underlying system/service).

19) Providers of IaaS must provide cloud customers optionally support DLP integration.

20) Providers of IaaS must provide cloud customers optionally support granular activity auditing broken down by individual.

21) Providers of IaaS must provide cloud customers segregation of duties based on identity entitlement.

22) Providers of IaaS must provide cloud customers compliance-centric reporting.

23) Providers of IaaS must provide cloud customers centralized policy management.

25) Providers of IaaS must provide cloud customers usable management interfaces.


26) Providers of IaaS must provide cloud customers unified access control & audit.

27) Providers of IaaS must provide cloud customers Interoperability and heterogeneity among various providers.


28) Providers of IaaS must provide cloud customers scalability.

14.7.2 DLP SecaaS Requirements

1) Providers of DLP must provide cloud customers with data labeling and classification.

2) Providers of DLP must provide cloud customers with identification of Sensitive Data.

3) Providers of DLP must provide cloud customers with predefined policies for major regulatory statues.

4) Providers of DLP must provide cloud customers with context detection heuristics.

5) Providers of DLP must provide cloud customers with structured data matching (data-at-rest).

6) Providers of DLP must provide cloud customers with SQL regular expression detection.

7) Providers of DLP must provide cloud customers with traffic spanning (data-in-motion) detection.

8) Providers of DLP must provide cloud customers with Real Time User Awareness.

9) Providers of DLP must provide cloud customers with security level assignment.

10) Providers of DLP must provide cloud customers with custom attribute lookup.

11) Providers of DLP must provide cloud customers with automated incident response.

12) Providers of DLP must provide cloud customers with signing of data.

13) Providers of DLP must provide cloud customers with cryptographic data protection and access control.


14) Providers of DLP must provide cloud customers with machine-readable policy language.

14.7.3 Web Services SecaaS Requirements

1) Providers of Web Services SecaaS must provide cloud customers with web monitoring and filtering.

2) Providers of Web Services SecaaS must provide cloud customers with Malware, Spyware, and Bot Network analyzer and blocking.

3) Providers of Web Services SecaaS must provide cloud customers with phishing site blocker.

4) Providers of Web Services SecaaS must provide cloud customers with instant messaging scanning.


5) Providers of Web Services SecaaS must provide cloud customers with email security.

6) Providers of Web Services SecaaS must provide cloud customers with bandwidth management / traffic control.

7) Providers of Web Services SecaaS must provide cloud customers with Data Loss Prevention.

8) Providers of Web Services SecaaS must provide cloud customers with fraud prevention.

9) Providers of Web Services SecaaS must provide cloud customers with Web Access Control.

10) Providers of Web Services SecaaS must provide cloud customers with backup.

11) Providers of Web Services SecaaS must provide cloud customers with SSL (decryption / hand off).

12) Providers of Web Services SecaaS must provide cloud customers with usage policy enforcement.

13) Providers of Web Services SecaaS must provide cloud customers with vulnerability management.


14) Providers of Web Services SecaaS must provide must provide cloud customers with web intelligence reporting.

14.7.4 Email SecaaS Requirements

1) Providers of Email Security SecaaS must provide cloud customers with accurate filtering to block spam and phishing.

2) Providers of Email Security SecaaS must provide cloud customers with deep protection against viruses and spyware before they enter the enterprise perimeter.

3) Providers of Email Security SecaaS must provide cloud customers with flexible policies to define granular mail flow and encryption.

4) Providers of Email Security SecaaS must provide cloud customers with rich, interactive reports and correlate real-time reporting.

5) Providers of Email Security SecaaS must provide cloud customers with deep content scanning to enforce policies.

6) Providers of Email Security SecaaS must provide cloud customers with the option to encrypt some / all emails based on policy.

7) Providers of Email Security SecaaS must provide cloud customers with integration capability to various email server solutions.

14.7.5 Security Assessment SecaaS Requirements

1) Providers of Security Assessment SecaaS must provide cloud customers with detailed governance processes and metrics (Implementers should define and document and process by which policies are set and decision making is executed).

2) Providers of Security Assessments and Governance offerings should implement an automated solution for notifying members of their immediate supply chain in the event of breach or security incident.

3) Providers of Security Assessment SecaaS must provide cloud customers with proper risk management (Implementers should define and document and process for ensuring that important business processes and behaviors remain within the tolerances associated with those policies and decisions).

4) Providers of Security Assessment SecaaS must provide cloud customers with details of compliance (Implementers should define and document process-of-adherence to policies and decisions).

5) Providers of Security Assessment SecaaS must provide cloud customers with policies that can be derived from internal directives, procedures, and requirements or external laws, regulations, standards and agreements.

6) Providers of Security Assessment SecaaS must provide cloud customers with technical compliance audits (automated auditing of configuration settings in devices, operating systems, databases, and applications).

7) Providers of Security Assessment SecaaS must provide cloud customers with application security assessments (automated auditing of custom applications).

8) Providers of an assessment and governance service offering must provide cloud customers with vulnerability assessments—automated probing of network devices, computers, and applications for known vulnerabilities and configuration issues.

9) Providers of Security Assessment SecaaS must provide cloud customers with penetration testing (exploitation of vulnerabilities and configuration issues to gain access to an environment, network or computer, typically requiring manual assistance)


10) Providers of Security Assessment SecaaS must provide cloud customers with a security rating.

14.7.6 Intrusion Detection SecaaS Requirements

1) Providers of Intrusion Detection SecaaS must provide cloud customers with identification of intrusions and policy violations.

2) Providers of Intrusion Detection SecaaS must provide cloud customers with automatic or manual remediation actions.

3) Providers of Intrusion Detection SecaaS must provide cloud customers with Coverage for Workloads, Virtualization Layer (VMM/Hypervisor) Management Plane

4) Providers of Intrusion Detection SecaaS must provide cloud customers with deep packet inspection using one or more of the following techniques: statistical, behavioral, signature, heuristic.

5) Providers of Intrusion Detection SecaaS must provide cloud customers with system call monitoring.


6) Providers of Intrusion Detection SecaaS must provide cloud customers with system/application log inspection.

7) Providers of Intrusion Detection SecaaS must provide cloud customers with integrity monitoring OS (files, registry, ports, processes, installed software, etc.)

8) Providers of Intrusion Detection SecaaS must provide cloud customers with integrity monitoring VMM/Hypervisor.


9) Providers of Intrusion Detection SecaaS must provide cloud customers with VM Image Repository Monitoring.

14.7.7 SIEM SecaaS Requirements

1) Providers of SIEM SecaaS must provide cloud customers with real time log /event collection, de-duplication, normalization, aggregation and visualization.

2) Providers of SIEM SecaaS must provide cloud customers with forensics support.

3) Providers of SIEM SecaaS must provide cloud customers with reporting and support.

4) Providers of SIEM SecaaS must provide cloud customers with IR support.

5) Providers of SIEM SecaaS must provide cloud customers with anomaly detection not limited to email.

6) Providers of SIEM SecaaS must provide cloud customers with detailed reporting.


7) Providers of SIEM SecaaS must provide cloud customers with flexible data retention periods and flexible policy management

14.7.8 Encryption SecaaS Requirements

1) Providers of Encryption SecaaS must provide cloud customers with protection of data in transit.

2) Providers of Encryption SecaaS must provide cloud customers with protection of data at rest.

3) Providers of Encryption SecaaS must provide cloud customers with key and policy management.


4) Providers of Encryption SecaaS must provide cloud customers with protection of cached data.

14.7.9 Business Continuity and Disaster Recovery Requirements

1) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with flexible infrastructure.

2) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with secure backup.

3) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with monitored operations.


4) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with third party service connectivity.

5) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with replicated infrastructure component.

6) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with replicated data (core / critical systems).

7) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with data and/or application recovery.

8) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with alternate sites of operation.

9) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with tested and measured processes and operations to ensure operational resiliency.

10) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with geographically distributed data centers / infrastructure.


11) Providers of Business Continuity & Disaster Recovery SecaaS must provide cloud customers with Network survivability.

14.7.10 Network Security SecaaS Requirements

1) Providers of Network Security SecaaS must provide cloud customers with details of data threats.

2) Providers of Network Security SecaaS must provide cloud customers with details of access control threats.

3) Providers of Network Security SecaaS must provide cloud customers with access and authentication controls.

4) Providers of Network Security SecaaS must provide cloud customers with security gateways (firewalls, WAF, SOA/API).

5) Providers of Network Security SecaaS must provide cloud customers with security products (IDS/IPS, Server Tier Firewall, File Integrity Monitoring, DLP, Anti-Virus, Anti-Spam).

6) Providers of Network Security SecaaS must provide cloud customers with security monitoring and incident response.

7) Providers of Network Security SecaaS must provide cloud customers with DoS protection/mitigation.

8) Providers of Network Security SecaaS must provide cloud customers with Secure “base services” like DNSSEC, NTP, OAuth, SNMP, management network segmentation, and security.

9) Providers of Network Security SecaaS must provide cloud customers with traffic / netflow monitoring.


10) Providers of Network Security SecaaS must provide cloud customers integration with Hypervisor layer.

                               ===// END //===

DOMAIN 13

VIRTUALIZATION

Virtualization is one of the key elements of Infrastructure as a Service (IaaS) cloud offerings and private clouds, and it is increasingly used in portions of the back-end of Platform as a Service (PaaS) and SaaS (Software as a Service) providers as well. Virtualization is also, naturally, a key technology for virtual desktops, which are delivered from private or public clouds.

The benefits of virtualization are well known, including multi-tenancy, better server utilization, and data center consolidation. Cloud providers can achieve higher density, which translates to better margins, and enterprises can use virtualization to shrink capital expenditure on server hardware as well as increase operational efficiency.

However, virtualization brings with it all the security concerns of the operating system running as a guest, together with new security concerns about the hypervisor layer, as well as new virtualization specific threats, inter-VM (Virtual Machine) attacks and blind spots, performance concerns arising from CPU and memory used for security, and operational complexity from “VM sprawl” as a security inhibitor. New problems like instant-on gaps, data comingling, the difficulty of encrypting virtual machine images, and residual data destruction are coming into focus.

Overview:. While there are several forms of virtualization, by far the most common is the virtualized operating system, and that is the focus for this domain. This domain covers these virtualization-related security issues:

1) Virtual machine guest hardening
2) Hypervisor security
3) Inter-VM attacks and blind spots
4) Performance concerns
5) Operational complexity from VM sprawl
6) Instant-on gaps
7) Virtual machine encryption
8) Data comingling
9) Virtual machine data destruction
10) Virtual machine image tampering

11) In-motion virtual machines

13.1 Hypervisor Architecture Concerns

13.1.1 VM Guest Hardening

Proper hardening and protection of a virtual machine instance, including firewall (inbound/outbound), HIPS, web application protection, antivirus, file integrity monitoring, and log monitoring can be delivered via software in each guest or using an inline virtual machine combined with hypervisor-based API’s

13.1.2 Hypervisor Security

The hypervisor needs to be locked down and hardened using best practices. The primary concerns for enterprises and virtualization users should be the proper management of configuration and operations as well as physical security of the server hosting the hypervisor.

13.1.3 Inter-VM Attacks and Blind Spots

Virtualization has a large impact on network security. Virtual machines may communicate with each other over a hardware backplane, rather than a network. As a result, standard network-based security controls are blind to this traffic and cannot perform monitoring or in-line blocking. In-line virtual appliances help to solve this problem; another approach to this issue is hardware-assisted virtualization, which requires API-level integration with hypervisors and virtualization management frameworks. Migration of virtual machines is also a concern. An attack scenario could be the migration of a malicious VM in a trusted zone, and with traditional network-based security controls, its misbehavior will not be detected. Installing a full set of security tools on each individual virtual machine is another approach to add a layer of protection.

13.1.4 Performance Concerns

Installing security software designed for physical servers onto a virtualized server can result in severe degradation in performance, as some security tasks like antivirus scanning are CPU-intensive. The shared environment in virtualized servers leads to resource contention. Especially with virtual desktops or high-density environments, security software needs to be virtualization-aware or it needs to perform security functions on a single virtual machine to support other virtual machines.

13.1.5 Operational Complexity from VM Sprawl

The ease with which VM’s can be provisioned has led to an increase in the number of requests for VM’s in typical enterprises. This creates a larger attack surface and increases the odds of a misconfiguration or operator error opening a security hole. Policy-based management and use of a virtualization management framework is critical.

13.1.6 Instant-On Gaps

The ease with which a virtual machine can be stopped or started, combined with the speed at which threats change, creates a situation where a virtual machine can be securely configured when it is turned off, but by the time it is started again, threats have evolved, leaving the machine vulnerable. Best practices include network-based security and “virtual patching” that inspects traffic for known attacks before it can get to a newly provisioned or newly started VM. It is also possible to enforce NAC (Network Access Control)-like capabilities to isolate stale VM’s until their rules and pattern files are updated and a scan has been run.

13.1.7 VM Encryption

Virtual machine images are vulnerable to theft or modification when they are dormant or running. The solution to this problem is to encrypt virtual machine images at all times, but there are performance concerns at this time. For high security or regulated environments, the performance cost is worth it. Encryption must be combined with administrative controls, DLP, and audit trails to prevent a snapshot of a running VM from “escaping into the wild,” which would give the attacker access to the data in the VM snapshot.

13.1.8 Data Comingling

There is concern that different classes of data (or VM’s hosting different classes of data) may be intermixed on the same physical machine. In PCI terms, we refer to this as a mixed-mode deployment. We recommend using a combination of VLANs, firewalls, and IDS/IPS 139 to ensure VM isolation as a mechanism for supporting mixed mode deployments. We also recommend using data categorization and policy-based management (e.g., DLP) to prevent this. In cloud computing environments, all tenants in the multi-tenant virtual environment could potentially share the lowest common denominator of security.

139 IDS - Intrusion Detection Systems; IPS- Intrusion Prevention Systems

13.1.11 In-Motion VM

The unique ability to move virtual machines from one physical server to another creates a complexity for audits and security monitoring. In many cases, virtual machines can be relocated to another physical server (regardless of geographic location) without creating an alert or track-able audit trail.

13.2 Recommendations

A) Customers should identify which types of virtualization the cloud provider uses, if any.

B) Implementers should consider a zoned approach with production environments separate from test/development and highly sensitive data/workloads.

C) Implementers should consider performance when testing and installing virtual machine security tools, as performance varies widely. Virtualization-aware server and network security tools are also important to consider.

D) Customer should evaluate, negotiate, and refine the licensing agreements with major vendors in virtualized environments.

E) Implementers should secure each virtualized OS by using hardening software in each guest instance or use an inline virtual machine combined with hypervisor-based API’s.

F) Virtualized operating systems should be augmented by built-in security measures, leveraging third party security technology to provide layered security controls and reduce dependency on the platform provider alone.

G) Implementers should ensure that secure by default configurations follow or exceed available industry baselines.

H) Implementers should encrypt virtual machine images when not in use.

I) Implementers should explore the efficacy and feasibility of segregating VM’s and creating security zones by type of usage (e.g., desktop vs. server), production stage (e.g., development, production, and testing), and sensitivity of data on separate physical hardware components such as servers, storage, etc.

J) Implementers should make sure that the security vulnerability assessment tools or services cover the virtualization technologies used.

K) Implementers should consider implementing data automated discovery and labeling solutions (e.g., DLP) organization-wide to augment the data classification and control between virtual machines and environments.

L) Implementers should consider patching virtual machine images at rest or protect newly spun-up virtual machines until they can be patched.


M) Implementers should understand which security controls are in place external to the VM’s to protect administrative interfaces (web-based, API’s, etc.) exposed to the customers.

13.3 Requirements

1) VM-specific security mechanisms embedded in hypervisor API’s must be utilized to provide granular monitoring of traffic crossing VM backplanes, which will be opaque to traditional network security controls.

2) Implementers must update the security policy to reflect the new coming security challenges of virtualization.

3) implementers must encrypt data accessed by virtual machines using policy-based key servers that store the keys separately from the virtual machine and the data.

4) Customers must be aware of multi-tenancy situations with your VM’s where regulatory concerns may warrant segregation.

5) Users must validate the pedigree and integrity of any VM image or template originating from any third party, or better yet, create your own VM instances.

6) Virtualized operating systems must include firewall (inbound/outbound), Host Intrusion Prevention System(HIPS)141, Network Intrusion Prevention System (NIPS)142, web application protection, antivirus, file integrity monitoring, and log monitoring, etc. Security countermeasures can be delivered via software in each guest virtual instance or by using an inline virtual machine combined with hypervisor-based API’s.

7) Providers must clean any backup and failover systems when deleting and wiping the VM images.


8) Providers must have a reporting mechanism in place that provides evidence of isolation and raises alerts if there is a breach of isolation.

141 HIPS - Host Intrusion Prevention System

142 NIPS - Network Intrusion Prevention System


                          ===/ END //========  

DOMAIN 12 ::

IDENTITY, ENTITLEMENT, & ACCESS MANAGEMENT

The concepts behind Identity, Entitlement, and Access Management used in traditional computing require fundamental changes in thinking when implementing a cloud environment, particularly splitting it into three discrete functions, Identity, Entitlement, and Authorization/Access Management (IdEA).

For most organizations, implementing a traditional application means implementing a server, possibly in a DMZ, and in most cases tied into a Directory Service (DS) (such as Microsoft’s Active Directory, Novell’s eDirectory or Open LDAP) for user authentication. In some cases it means implementing an application or using a web-delivered service using its own stand-alone authentication system, much to the annoyance of the users who then have to remember sets of credentials (or worse, reuse credentials from other, perhaps more trusted, domains).

DS or "Directory Service" is used through this section as an abbreviation for a generic corporate directory service, used for username and password login.

In contrast, a well implemented cloud service or application-identity should be consumed from a variety of external sources together along with the associated attributes (remembering that an identity applies not only to Users, but also Devices, Code, Organizations and Agents which all have identity and attributes). Leveraging all the multiple identities and attributes involved in a transaction enables the cloud system to make better holistic risk-based decisions (defined by the entitlement process and implemented by the authorization & access management components) about granular access to the system, processes, and data within the cloud system / application.

Code includes all forms of code, up to including applications and self-protecting data.
"Entitlement" is the process of mapping privileges (e.g., access to an application or its data) to identities and the related attributes.

This process of using multiple sources of Identity and their related attributes is critical when a cloud application is likely to be Internet-facing, and is also likely to be one of the main hurdles for organizations wanting to use “true” cloud services and instead opt to implement virtualization technologies in their own DMZ connected to their own internal DS.


This de-perimeterized approach to identity, entitlement, and access management provides a more flexible and secure approach but also can be implemented equally well inside the corporate boundary (or perimeter).


De-perimterization is a term coined by the Jericho Forum® (www.jerichoforum.org)

 The following sections cover the key aspects of Identity, Entitlement, and Access Management in a cloud environment:

(I) Introduction to Identity in a cloud environment
(II) Identity architecture for the Cloud
(III) Identity Federation
(IV) Provisioning and governance of Identity and Attributes
(V) Authorization and Access Management
(VI) Architectures for interfacing to Identity and Attribute providers
(VII) Level of trust with Identity and Attributes
(VIII) Provisioning of accounts on cloud systems
(IX) Application Design for Identity
(X) Identity and Data Protection

12.1 Terminology Used in this Document

The language used around identity is confused, with some terms having diametrically opposite means to different people. To avoid confusion while reading this domain, some of the identity terms used within this domain are defined below:

Identity : The means by which an Entity can consistently and comprehensively be identified as unique.

Identifier : The means by which an Identity can cryptographically asserted, usually using public-key technology.

Entity : Discrete types that will have Identity; these are to Users, Devices, Code, Organizations and Agents.

Entitlement : The process of mapping privileges (e.g., access to an application or its data) to Identities and the related Attributes.

Reduced Sign-on (RSO) : The use of an account and/or credential synchronization tool to minimize the number of credentials (usually username and password) a user has to remember; most of these solutions result in some form of security compromise.

Single Sign On (SSO) : The ability to pass Identity and Attributes to a cloud service, securely, using secure standards such as SAML and OAuth.

Federation : The connection of one Identity repository to another.

Persona : Identity plus the particular Attributes that provide context to the environment the Entity is operating within. A Persona may be an aggregation of an individual Identity together with an Organizational Identity and Organization Attributes (e.g. a corporate Persona, Fred Smith as CEO of ACME Corp., or a Personal Computer belonging to ACME Corp.).

Attributes : Facets of an Identity

12.2 Introduction to Identity in a Cloud Environment

An identity eco-system faces scaling problems (think of the move from a small village where everyone knows everyone else, to a large town or city). As the industry expands identity systems from single computers into global enterprises and then into cloud deployment models, the ability to identify all the entities involved in a transaction become significantly more difficult.

However, with cloud, the use of Identity for all Entities in the transaction value-chain, and the move to risk-based decisions, cannot only mitigate the risk but also potentially improve security.

The following key points need to be considered when implementing a cloud based solution that needs to use identity information:


(a) The strength with which an Identity can be asserted will feed into the risk calculation when interacting with that Identity (examples include Anonymous; self-assert; validated by a known reputable organization with a strong assertion of organizational Identity).

(b) The Attributes of a Persona, like Identity, will have a strength with which an Attribute can be asserted that feed into the risk calculation when interacting with that Persona. Assertion strength ranges from self-asserted to validated by a known reputable organization (with a strong assertion of organizational Identity).

(c) Identity and Attributes will need to be consumed from multiple sources, thus cloud solutions / architectures will need the ability to consume multiple disparate sources of Identity and Attributes.

(d) There will be instances when a transient Identity is sufficient (enough information about an Entity to deem them unique).

(e) There will be instances where pseudo-anonymity is desirable (such as voting).

12.3 Identity Architecture for the Cloud

The move from a traditional architecture of a perimeterized organization with traditional server based applications in internal computer centers affords little flexibility to an organization. The move to cloud-based architectures allows greater flexibility, whether deployed internally within the organizational boundaries (a private cloud) or external public clouds (SaaS, PaaS or IaaS).


The table on the following page shows how identity needs to vary between traditional implementation and cloud implementation, dependent on the type of cloud architecture implemented.

Whereas in a traditional “IAM” architecture, often all the components are stand-alone as part of a single server, a cloud architecture is potentially more complex taking Identity and Attributes from a number of sources and making authorization / access management decisions via a set of Entitlement Rules defined by the Entitlement Process.

IAM-Identity and Access Management

In Figure 1, Identity and Attributes are sourced from (potentially) multiple sources and feed into an authorization/access management layer that translates the entitlement rules into access.

Access Management should (depending on the business / security requirements, and the type of cloud model, IaaS, PaaS or SaaS being deployed) govern access to the;

(i) Network layer : Without meeting the entitlement rules it may not even be possible to “see” (i.e. Ping or route) to the cloud system. The entitlement rules may also direct access to particular interfaces.

(ii) System layer : The entitlement rules may define the protocols that are permitted to access and modify systems, such as terminal server vs. web.

(iii) Application layer : The entitlement rules may map Identity and/or Attributes to functionality provided by a specific application, such a being presented with a reduced set of menus or options.

(iv) Process layer : The entitlement rules can be used to define the processes (or functions) that can be run within an application. Entitlement may also define that enhanced functions (such as transferring money out of the eco-system) need additional verification (which may be obtained directly or derived in the background).

(v) Data layer : The entitlement rules may limit access to areas of the data and file structure or even individual files or fields within files (e.g., in a database). At a more advanced level, entitlement could be used to auto-redact documents, such that two users accessing identical documents would view different content (e.g., constructing a specific dynamic view of a database table).


The entitlement process starts with the customer to turn business requirements and security requirements into a set of entitlement rules. This process will define the identities and Attributes required to be able to evaluate the rules. These rules in turn drive the authorization/ access system.

12.4 Identity Federation

Conceptually speaking, federation is the interconnection of disparate Directories Services. Some organizations opt for a federation gateway, (a “Bridge” or “Federation Hub”) in order to externalize their federation implementation, where the federation and the rules by which Identity is managed within that “bridge” is governed by a set of rules, usually a legal contract, thus allowing other partners in this bridge a defined level of trust in identities not directly issued by themselves.

Technologically speaking, federation is the use of SAML to offer portability to disparate and independent security domains with some organizations extending their DS environment via a gateway product that will handle SAML assertions. Other organizations will consume native SAML assertions from an identity service.

In both these types of federation architectures, it is essential to understand the provenance of the Identity and Attributes that are being asserted.

Federation standards are used widely for SaaS deployment models for both identity federation and access control. There are no similar standards for PaaS or IaaS deployment models.

Cloud Consumers leveraging IaaS deployment models should take into consideration how they manage the lifecycle of identities (shared accounts, named accounts, privileged accounts etc.). 

Enterprises that leverage the Privileged Identity Management (PIM) tools for Super User Management (SUPM) and Shared Account Password Management(SAPM) should investigate extending these tools to support cloud deployments. Enterprise or Cloud Consumers must have a well-defined policy for HPA (Highly Privileged Access).

12.5 Provisioning and Governance of Identity and Attributes

When talking about provisioning, typically we think about user provisioning, but to make rich, risk-based decisions, the cloud system / application needs Identity and Attributes from all entities involved in the transaction and potentially other Attributes from other systems / processes.

Some examples of Identity and Attributes are as follows (not an exhaustive list):

(A) User Assertions: User Identifier (The public part of a Public/Private key pair)

(B) User Name (User Name should be just another Attribute of Identity)

(C) Credential strength/trust

(D) Location Assertions; IP-Address, Geo-location, GPS, Cellular Service Location

(E) Organization Identity (Identifier – crypto) and Organization Assertions

(F) Device Identity (Identifier – crypto) and Device Assertions; Functionality Required, Functionality Offered, Sandbox capability, Secure container, Cleanliness of device

(G) Code Identity (Identifier – crypto) and Code Assertions

(H) Training record / compliance, etc.


The master source of Identity and the Attributes of an Identity (which may be from a different source) need to be identified in the design of the entitlement process.

As a rule, the cloud service or application itself should avoid being the master source for Identity (exceptions may be a cloud based HR service, or a cloud Identity-as-a-Service offering). However, during the transition to cloud services (not best practice) the cloud service / application may need to hold identities or operate a mixed-mode model.


All Attributes should be linked to an Identity, as without the associated Identifier and level of trust with that Identifier the Attributes have no provenance. While this may at first sight be counterintuitive, the strength in the entitlement process lies in defining those Attributes necessary to make the rules work the way the business requires them to and then identifying the authoritative source (or as close as possible) to provide those Attributes (with the related Entity Identifier). Examples would include:

(1) Security threat level : Organizational, Government, or Outsourced provider Identity

(2) Approvals or prior decisions made by other Entities: Entity Identity


(3) QoS or throttling policies related to a protected target resource; System Identity

12.6 The Entitlement Process

The entitlement process starts with the customer to turn business requirements and security requirements into a set of rules that will govern authorization and access to the various aspects of the cloud system. This process will then define the identities and Attributes that are required to properly evaluate the entitled rules. The entitlement process and the derived rules should not only drive the authorization and access management of a cloud system, they can also specify a degree of negotiation/entitlement at all layers of the cloud infrastructure, e.g., to allow protocols and interfaces at the network and/or system layer.

The entitlement process should be embedded into any business requirements document and also the technical requirements document; it should also feature as an integral part of the cloud vendor’s provisioning / “customer on-boarding” process.

The entitlement process does not stop once the cloud service is up and running, but the entitlement rules and the subsequent rules that drive authorization and access must be the subject of regular review. The entitlement process must then be audited by the business “system-owner” against the business requirement. Any audit must include the threat and risk assessment and any regulatory requirements.

Current solutions include automated approaches to turn high-level security policies into (low-level) technical access rules, including:

(a) Model-driven security, a tool-supported process of modeling security requirements at a high level of abstraction and using other information sources available about the system (produced by other stakeholders)

(b) Clustering technical access rules into similar groups to reduce the complexity


(c) Visual attempts to make technical policies easier to understand

The entitlement process should define those Entities, Identities, and Attributes that are required to make meaningful authorization and access decisions. It should also define those Attributes that are fixed within the process, or those that have a temporal (change over time) aspect to them, and therefore either the time interval at which they must be revalidated, or the trigger within the process, will force revalidation.

Where Identity and Attributes that need to be sourced from outside the business’s control are defined in the entitlement process, the Organizational Identity (Identifier) of that provider (Entity) must be on-boarded as well, and thus (at some point in time) off-boarded.


Typically the entitlement rules are interpreted in one of three places:

1. Using a central/external Policy Enforcement point / Policy Server / Policy-as-a-Service

2. Embedded as part of the Cloud application


3. Using an Identity-aaS (IDaaS)

12.7 Authorization and Access Management

Authorization and Access Management is the process by which the entitlement rules are translated (via the Authorization layer) into Access Management rules.

In most cloud based systems, the Authorization layer is likely to be a “Policy Decision Point” (PDP) or the point that evaluates and issues authorization decisions, and the Access Management layer, the “Policy Enforcement Point” (PEP), the point that enforces the PDP's decision.

The PDP and PEP will be part of an authorization eco-system that uses XACML (eXtensible Access Control Markup Language) as a declarative access control policy language implemented in XML.

A PEP could be as simple as an IF (conditional) statement in the cloud application or as advanced as an agent running on an application server or a filter in an XML-gateway that intercepts access requests, gathers necessary data (Attributes) to be able to evaluate the Entitlement Rules, and then makes and implements these decisions.

This is not to mandate the use of XACML, PDP’s, and PEP’s in a cloud environment, as the functionality could potentially be implemented in other ways (probably in a closed or proprietary eco-system).

PDP’s can be implemented outside of the cloud environment, possibly within the customer’s environment. This can potentially have a number of advantages such as interfacing to an internal DS and/or the ability to integrate logs about the decision made directly into an internal logging system.

12.8 Architectures for Interfacing to Identity and Attribute Providers

There are three basic architectures for interfacing to Identity and Attribute providers:

1. A “hub-and-spoke” model where Identity and Attributes are centrally managed (coordinated) by the hub, which then interacts with the cloud service(s) or cloud application(s)

2. The free-form model where the cloud service and/or application can be configured to accept Identities and Attributes from multiple sources


3. The hybrid solution, where the components are distributed, potentially using other cloud services.

Each model has its merits, and the choice will be based on the number of factors, including:

(i) Where the customers for the service have their identity

(ii) The capability of the cloud service chosen


(iii) The capability of the enterprise to provide assertion-based Identity and Attributes.

12.8.1 Hub and Spoke Model

The “hub and spoke” approach typically allows the cloud service to interface directly with the organization for its Identity and Attribute information, ideally in the form of standards-based assertion protocols, such as OAuth & SAML.

The organization’s internal systems are responsible for keeping track of users, other entities and the Attributes. This is most like a traditional IAM system, and thus probably the easiest to transition to for cloud solutions being implemented by organizations, as most DS or LDAP systems can have a SAML capability “bolted-on”.

It is likely in this model that the entitlement process might also be handled within the organization through the use of a Policy Enforcement Point and Policy Server and communicated via XACML (though XACML isn’t that widely used for this yet). Figure 2 illustrates the hub-and-spoke approach.

One benefit of this approach is that maintaining a Policy Enforcement Point within the organization allows the integration of audit logs to be maintained within the organization and even correlated with other disparate audit trails (outside of the cloud environment, or from other cloud environments) to get the complete picture required. 

  Examples of this include Segregation of Duties analysis and satisfaction of regulatory requirements.

The hub-and-spoke approach is likely to be used when a high degree of control is required over all “users” with a central enrollment process. This is more likely in organizations that are subject to heavy regulation. The hub-and-spoke should also lessen the dependency on the Identity/Attribute providers, as Attributes are often stored (duplicated) within the central hub.

This is also the model used when an organization subscribes to a Bridge or “Identity Hub.”

12.8.2 Free Form Model

In the “free-form” model, the cloud service / application is responsible for maintaining the sources of Identity and Attributes. This solution is more suited for a public facing solution or a solution with a large number of disparate partners.

The free form approach has the advantage that it is easier to setup, at least for current federation protocols (such as SAML) but relies on a good implementation of the entitlement model to allow it to scale to a large amount of “users.”

One approach is to setup a point-to-point federated trust relationship (using protocols such as SAML and OAuth) between the service and Attribute/Identity providers, but this approach needs an efficient process to on-board and off-board those providers.

The free-form model provides challenges to provisioning “users”, as the environment of new entities connecting is likely to be more ad-hoc. Again, careful design of the Entitlement Process will help to alleviate this problem. Figure 3 above illustrates the point-to-point approach.

12.8.3 Hybrid Model

The Hybrid model is (by definition) a mix of both the hub & spoke and free-form model. For example, the entitlement rules may be held inside the organization and pushed to a PDP, which in itself is a cloud service, and then those decisions are delivered to multiple disparate PEP’s that are part of separate cloud services. In more large-scale deployments, there can be several federated policy servers that service many different PDP/PEP’s. The hybrid model will also be found in organizations that mix traditional and/or legacy computing with a (public and/or private) cloud environment.

The hybrid model may offer an efficient use of distributed resources, but it risks becoming complex with the attendant scope for security loopholes to creep in. It also makes long-term maintenance more problematic (the reasoning behind simple rules is easy to understand when all who implemented them are long gone).

The hybrid model will also have issues of logging decisions and actions taken with the potential need to bring all logs back into a single place in a common format to allow a holistic view to be taken.


The potential complexity of the hybrid model stresses the need to be able to use visualization tools to develop, maintain, and audit the translation of the Entitlement Rules into actual access control.

12.9 Level of Trust with Identity and Attributes

Identity and Attributes come with many levels of trust, both in the various identities being used in a transaction and with the Attributes attached to those identities. Traditionally this lack of trust has led to organizations having to maintain identities for anyone who needs access to their systems, which can be (in some cases) for hundreds of thousands of people who they do not employ or directly manage.

Some organizations (Military/Aerospace, Pharmaceutical, etc.) that need to collaborate with a pre-agreed level of trust use a “Bridge” or “Federation Hub” (see section 12.4), where trusted identities also have trusted Attributes associated with them.

During the entitlement process it is essential to understand not only the Attributes required, but also the source of those Attributes, the organization that will provide them, and the strength (level of trust) with which they can be asserted.

To accept Attributes from an external organization with any defined level of trust will require an on-boarding process for that organization, and the Identity (Identifier) of the organization that will be asserting those Attributes.

As a rule, the aim should be to source Identity and Attributes from the master / authoritative source of those Attributes with all Attributes having a known Identity asserting them, as the level of trust that can be placed in the Attribute cannot exceed the level of trust that can be placed in the Identity asserting the Attribute.

Where Attributes are being uniquely generated within the cloud system itself, then a governance process must be in place to ensure that all Attributes are accurate and have appropriate lifecycle management.

12.10 Provisioning of Accounts on Cloud Systems

Where it is necessary to provision an “account” on cloud systems (typically for a user, but it could be for any Entity type) there are challenges when provisioning (and de-provisioning) these accounts, as the normal “push” model used within organizations is generally not a viable solution for a cloud implementation.
At the time of writing, there are no widely used or de-facto provisioning standards; SPML (Service Provisioning Markup Language) has not been widely adopted by the cloud providers, and SCIM (Simple Cloud Identity Management) is only starting to emerge as a potential standard.

The key to provisioning entities on a cloud system is to understand the complete lifecycle management of an account, from creation, management, and eventually de-commissioning (including deletion and/or archiving) across all the systems that both provide and consume the Identity and Attributes.

There are some key issues that need to be addressed with sources of Identity and Attributes when it comes to provisioning:

(a) The link to Human Resources (or the authoritative source of person-user information) is problematic as HR is often only the master source for staff on regular payroll.

(b) There are usually no authoritative information sources for partner information and their devices.

(c) The ability to provision other entities (particularly organizations and devices) does not exist in most organizations.

(d) Public Identity services generally only provide self-asserted Identity and only about people; it does not extend to the other Entity types.

(e) De-provisioning needs to extend to all entities, thus most organizations do not have the ability to off-board another organization when the contract finishes or revoke code from operating on systems when it is found to be faulty or obsolete.
These issues and the immaturity of provisioning standards stress the need for good planning and a holistic approach to how Identity, Attributes, accounts, and lifecycle management of all Entity-types will operate in the cloud eco-system being developed.

12.11 Identity-as-a-Service

Cloud Identity as a Service (IDaaS) is a broad term that covers the management of any part of the Identity, Entitlement, and Authorization/Access Management in the cloud service.

This encompasses service for software, platform, or infrastructure services, and for both public and private clouds. Hybrid solutions are also possible, whereby identities can still be managed internally within an organization, while other components such as authentication are externalized through a Service Oriented Architecture (SOA). This effectively creates a Platform as a Service (PaaS) layer to facilitate a cloud-based IAM solution.

12.12 Compliance & Audit

The outcome of the entitlement rules may well need to be logged together with the decisions made by the entitlement rules / authorization process for compliance or security reasons. Compliance and audit is integrally tied to Identity. Without proper Identity management, there is no way to assure regulatory compliance. Auditing also requires proper Identity management, and the use of log files is of little value without a working Identity system.

12.13 Application Design for Identity

This section applies just to application design as it applies to Identity and should be read in conjunction with Domain 10 – Application Security.

Designing cloud based systems or applications necessitates a change in mindset when it comes to Identity as Identity and Attribute information will be consumed by the cloud service or application, needing to be held for at least the duration of the transaction, and probably some facets maintained longer, but because the cloud environment may likely not be a part of an organization’s physical or logical jurisdiction, and may even be in a different legal jurisdiction, the service and application design may need to be substantially different from the design practices used in traditional client server in a DMZ owned and managed by the organization.

The design goal should be to minimize the need for Identity and Attributes. When possible, start from the principle that identification is not required while understanding the threshold where there will be a need to switch from basic “on-the-fly” account provisioning to an “identified” user account. Examples include:

(a) Unique sessions can be established using other Attributes, e.g., the IP address of the connecting device (understanding that IP addresses can be spoofed) or a unique session cookie.

(2) In many cases Attribute-based entitlement alone will be adequate with no need for user information or an actual Identity; don't assume a Persona is needed to tie to a session or even an account.

(3) When encountering a new Entity for the first time (say authenticating with a SAML assertion) then create a basic account on-the-fly. [Note that this approach requires thought about de-provisioning.]

(4) Use Attribute derivation whenever possible, (e.g. don’t ask for date of birth, instead query “if over 18” [if DoB > (today – 18 years)].

When generating any unique accounts, decide whether the system will consume an external unique Identifier from the Entity or whether the system will need to generate its own unique Identifier (such as a customer reference number).

There must be careful thought put into cloud systems that maintain user accounts. There must be careful design thought put into how the cloud user accounts will be synchronized with existing user accounts in other systems (either internal or other cloud systems), particularly around the integration with a “joiners and leavers” process, and the changes in access required when people move internally. 

Designing a cloud system to scale (think of 100,000 users with an unconnected username and/or unsynchronized password) requires the need to avoid forcing a common help desk process, including manual or semi-automated synchronization scripts, password strength validation processes, password reset processes, password resets after a compromise, etc. all due to a lack of initial design thought about consuming external identities.
Avoid trying to extend an internal DS into the cloud service and/or replicating the organization’s DS over the Internet (generally very insecure) or via a back-channel (leased line or VPN) as this exposes an organization’s entire DS into an environment the organization does not control. Also be wary of the promise of RSO (reduced-sign-on) products as RSO generally works by compromising on-log-in security internally, more so when trying to extend RSO to a cloud environment.

As a rule, cloud services, and thus cloud applications, should accept the standard SSO federation formats such as SAML and OAuth (or even the less widely accepted WS-Federation).

When designing an application to consume Identity and Attributes, remember that Identity encompasses all Entities, and that the application security should, where possible, be part of a holistic approach that includes all layers; the Network layer; the System layer; the Application layer; the Process layer; and the Data layer (as detailed in section 12.3). 

An application could (for example) offer two methods of connecting a full, rich connection using Web/AJAX/Java or an Citrix style “screen-scrape” connection with the type of connection permitted determined by the Entitlement Rules (defined in the Entitlement process).

12.14 Identity and Data Protection

Holding aspects of an Identity that comprises Personal Identifiable Information (PII), and particularly information classified as Sensitive Personal Information (SPI), is an issue for all organizations. Cloud services managed or located outside of the organization will need specialist advice to ensure all applicable laws and regulations are being adhered to.

When considering which laws or jurisdictions might apply, the following (non-exhaustive) list should be considered:

(a) All the countries of the data subjects
(b) The country in which the organization operates
(c) Countries in which the organization has legal entities
(d) Countries in which the organization lists on the stock exchange or issues shares
(e) The country or countries where the cloud services are physically located
(f) The relevant legislation, regulations, and also pseudo-regulation (such as PCI-DSS)

12.15 Consumerization and the Identity Challenge

Interacting with consumers and/or consumer devices brings a number of challenges and opportunities in cloud-based services and applications. The ability of the consumer and consumer devices to interface directly to an Internet-facing cloud service strips away a layer of network complexity but introduces a series of security challenges which can potentially be mitigated using Identity.

However, in the consumer space, standards for device and user Identity are fragmented and (by definition) will rarely have the same level of conformance and standardization that can be achieved in a corporate environment.

Unfortunately, most consumer devices and consumers themselves have no easy or standard way to enroll themselves or their devices into an authentication system providing strong authentication, and thus, authorization without strong Identity is difficult. Even when users have an existing strong authentication method (for example with their bank) for one account, this can almost never be reused with another account/provider. This has resulted in a situation where Identity for the consumer has already passed the limits of scalability. Over 61 percent of people use the same password whenever they can; this results in every additional registration or authentication causing the loss of potential customers.

Solving this problem with seamless access to applications will facilitate business, and clear separation between Identity and authorization will facilitate additional uses, for example allowing one individual to delegate use of their Persona linked to a specific credit card on behalf of another's transactions.

12.16 Identity Service Providers

Consuming information about Identity from an external service brings its own issues. Levels of trust in the providing organization and validation of Attributes are just two examples. Most current proposals or actual offerings for comprehensive and consistent Identity frameworks are extrapolations of single or group players’ needs by those with little or no understanding of other communities’ needs.

Nearly all open/public consumable Identity services deal only with user verification. Those that offer personal information (Attributes as well as Identity) do so using Attributes that are either self-asserted or not from authoritative sources.

Examples of sources of Identity and Attributes are as follows: 


(A) National Government

1) United States, NSTIC – strategy & aspiration only
2) German “EID card,” Austrian “Citizen Card,” Estonian “ID Card,” Finland “Citizen Certificate,” Hong Kong “Smart ID Card,” Malaysian “MyCad”

(B)) Public – integration via API's

1) Facebook
2) Amazon
3) Google
4) Microsoft Passport (Windows Live ID)
5) OpenID providers (Various)
6) Twitter

(c) Bridges or “Hubs”

1) Research / Education Bridge (REBCA), serving the US higher education sector
2) Federal PKI Architecture (Federal Bridge) serving all US federal agencies.
3) CertiPath/Transglobal Secure Collaboration Program, serving the aerospace and defense industries
4) SAFE-BioPharma Association, serving the biopharmaceutical and healthcare industry

(D) Identity Service offerings

1) Check / validate my postal code and address (various)
2) Experian / Equifax
3) 3D card verification (Visa/MasterCard)
4) eBay / PayPal / X.Commerce

12.17 Recommendations

12.17.1 Federation Recommendations

a) Consumers, Implementers, and Providers should agree on the context and definition of “federation” being used.

b) Implementers should understand what trust relationship and transitive trust exist and the need for bi-direction trust relationships.

(c) Implementers should, where possible, use federation based on open standards such as SAML and OAuth.

(d) If using a “Bridge” or “Federation Hub”, then Implementers should understand the nature and relationship of the trusts that exist between different members of the club. Understand what it could mean to your entitlement rules if there is another member signed up to the cloud or federating to another bridge.

(e) Implementers should understand that public Identity providers such as Facebook, Yahoo, or Google provide a source of (low grade, typically self-asserted) Identity with no guarantees that they will not federate to other providers in the future.

(f) Implementers should deprecate examples of bad solution design solutions to get Identity from a DS linked into the access management system of a cloud solution. Such examples include in-band VPN’s and out-of-band leased-lines.

12.17.2 Provisioning and Governance Recommendations

(1) All Attributes should be sourced from as close to the authoritative / master source as possible.

(2) As a rule, the cloud service or application itself should avoid being the master source for Identity.

(3) The cloud service or application itself should only be the master source for Attributes it directly controls.

(4) All Attributes consumed should have a known level of trust.

(5) All Attributes consumed should be linked to an Identity.

(6) The Identifier of a defined Entity should sign all Attributes consumed.

(7) Each Attribute should have a lifecycle that is fit-for-purpose.

(8) Each Identity (and related Identifier) should have a lifecycle that is fit-for-purpose.

12.17.3 Entitlement Recommendations

(1) All parties in the entitlement (definition) process should be clearly identified.

(2) There should be clear designated responsibilities for entitlement rule approval and sign-off.

(3) A process to manage changes to the Entitlement Rules should be clearly defined.

(4) A frequency (or trigger) for auditing the Entitlement Rules should be clearly defined.

(5) The entitlement process should focus on producing Entitlement Rules that are simple and minimal and designed using the principle of least privilege.

(6) The entitlement process should focus on producing entitlement rules that minimize the exposure of Identity or avoid needing to consume Identity altogether.

(7) Attributes that are temporal (such as geolocation) need real-time Attribute checking through a lifetime of transaction to revalidate the entitlement rules.

(8) Entitlement rules should be triggered by a process (or attempt to initiate a process, such as money transfer out of environment). In some environments, best practice would be for the entitlement rules to disable such functions. In others, best practice would be to require additional Identity or Attributes at the point of execution to ensure the Entity is entitled to perform the process.

(9) Implementers should ensure bi-directional trust to ensure the optimal secure relationship for the transaction. The entitlement process should define this.

(10) The design of the entitlement rules should include delegation (133) of access by a secondary Entity to some, but not necessarily all, information the primary Entity can access.

(11) The design of entitlement should include the seizing of access (including legal seizure), although the designer of the entitlement rules will need to take into account the jurisdiction of the system, organization, and entities involved. Legal advice must be taken prior to implementing any seizure of access.


(12) Where practical, management interfaces, tools, or other visualization technologies should be used to help in management of Entitlement and to help ensure the interpretation meets the business and/or regulatory (e.g. SOX Segregation-of-Duties) requirements.

133. Delegation is newly supported in XACML 3.0

(13) Implementers should consider the use of “policy-as-a-service” as the policy server if there is a need for a central policy server (for example for cloud mashups).

12.17.5 Architecture Recommendations

(1) Implementers should ensure any cloud provider offers authorization management PEPs/PDP’s that can be configured with entitlement rules.

(2) Implementers should ensure that all components of the Identity, Entitlement, and Authorization / Access Management (IdEA) work correctly together.

(3) Implementers should ensure that Policy Decision/Enforcement Points (PEP’s/PDP’s) use standard protocols (e.g. XACML) and avoid (or depreciate) proprietary protocols (e.g. direct web service or other middleware calls).

(4) Implementers should ensure any strong authentication service is OAuth compliant. With an OAuth-compliant solution, organizations can avoid becoming locked into one vendor’s authentication credentials.

(5) Cloud services and applications should support the capability to consume authentication from authoritative sources using SAML.

(6) Implementers should ensure services have an import and/or export function into standards such as OASIS XACML.

(7) Implementers should ensure services can interface with PEP/PDPs installed in the cloud infrastructure and with Policy Monitoring Points for incident monitoring/auditing.

(8) Implementers should ensure that logging of authorization decision and access actually granted can be logged in a common format using standard secure protocols.

12.17.6 Entitlement Recommendations

(1) Implementers should ensure that each Identity and Attribute defined in the entitlement process matches the level of trust that is needed (or is acceptable) in both the Identity/Attribute itself and also matches the source that provides it.

(2) Implementers should ensure all sources of Identity / Attributes provide organizational Identity.

(3) Implementers should ensure that Attributes are validated at master / source whenever possible, or as close as possible.

(4) Implementers should ensure Attribute use correctly leads to the right conclusion. (Your context may be different to the originator of the Attribute)

(5) Implementers should ensure that the Identity / Attribute source has both the standards of data quality and a governance mechanism that meets your needs.

(6) Consumers should be aware that reputational trust can be an important source of trust. Through the entitlement definition, consumers should be aware of small value transitions, leading to an increase in transactional trust, which may be defrauded on a subsequent large transaction.

12.17.7 Provisioning Recommendations

(1) Providers should understand whether SPML or SCIM could be a viable option for provisioning.

(2) Implementers should follow the rule of least privilege when provisioning an account. In the case of entities such as computing devices, a link to organizational asset registries is desirable.

(3) Most systems and applications have a one-to-one relationship between the user and access and no concept of delegation.

(4) Implementers should ensure that provisioning and de-provisioning are not limited to user identities. Architectures must include authorization for all Entity types.

(5) Implementers should ensure provisioning and de-provisioning are done in real time.

(6) Providers should ensure the maintenance of both Identity and Attributes are critical if entitlement is to be accurate.

12.17.8 Identity Compliance & Audit Recommendations

(1) Implementers should ensure that the applicable logs from the entitlement rules / authorization process are capable of being made available.

(2) Implementers should ensure where logs need to be integrated into a wider (possibly remote) system (e.g. for wider fraud detection or segregation of duties analysis) to ensure the availability, timeliness, format, and transmission security of the logs is adequate.

(3) When logging access decisions, implementers should group the Attributes together with the entitlement logic used at the time of the decision, and the outcome should be recorded.

(4) All cloud participants should remember that Attributes with a temporal component might need to be revalidated, and hence re-logged, during the lifetime of the session.

(5) When logging PII or SPI then, whenever possible, implementers should use Attribute derivation to minimize the exposure of PII or SPI in the logs.


(6) Consumers should be aware that logs containing PII or SPI will be subject to data protection legislation.

12.17.9 Application Design Recommendations

(1) Implementers should use ITU X.805 / 3-layer definition of User, System, and Management layers to ensure segregation.


(2) Implementers should minimize the need for Identity and Attributes in an application design.

(3) When possible, design cloud systems to consume Identity and Attributes from external sources.

(4) Implementers should ensure the cloud system supports standard SSO federation formats such as SAML and OAuth.

(5) Implementers should take a holistic approach to security, using Identity and Attributes across all the layers of the system.

(6) Implementers should remember that mutual authentication is critical at all levels, and even more important in cloud environments, just as the cloud environment needs entities and other systems to authenticate who they are, so the cloud system needs to be able to authenticate in return.

12.17.10 Data Protection Recommendations

(1) Implementers should minimize the use and storage of PII or SPI. This should be done in the design phase of the entitlement process to ensure only Identities and Attributes essential to the process are used.

(2) The implementer should consider the following technologies to minimize exposure of PII or SPI:
• Encryption
• Tokenization
• Homomorphic Encryption  

Refer to Domain 11 “Encryption & Key Management” for more information.

(3) Implementers should consider using best practice approaches to protecting SPI such as using a dual-key approach, one held by the subject (or keyed against their log-in), and one by the system for use with processing.

(4) Implementers should understand how administrator access to PII and SPI might be restricted or stopped.

(5) Implementers should understand how a “Subject Access Request 135” can be dealt with in the legal timeframe mandated especially when the data may be held on a cloud system not owned / managed by the organization that received the request.

135 A “Subject Access Request” is the legal right in some countries to request any PII or SPI held about yourself

(6) If there is a need to share PII or SPI, consumers should understand how the approval of the subject of the PII/SPI will be obtained.

(7) Implementers should reduce PII/SPI being stored, especially when not the authoritative source, and only reference those attributed from the authoritative source rather than store (and maintain) them.


(8) Implementers should understand the processes by which the maintenance of PII/SPI (whether Identity or Attributes) will be handled in a timely manner.

12.17.11 Identity Implementation Recommendations

(1) Implementers should start from the principle of Identity re-use rather than the unique enrollment of new users and/or devices.

(2) Consumers should understand where existing sources of Identity can provide sufficient levels of trust and be re-used.

(3) Providers should understand what Attributes about the user and devices can be asserted to a sufficient level of trust for the transaction being undertaken.

(4) When appropriate, consumers should allow low risk transactions to take place using low grade level of authentication. Only escalate the Identity required when the transaction value / risk increases.

(5) Providers should provide a critical assessment of the Identity and Attributes being required during the Entitlement Process when considering consumers and consumer devices.

(6) Providers should understand what technologies can be used with consumer devices to increase assurance levels, especially technologies than can be used in the background.

(7) Consumers should understand where the management of consumer devices will not be performed and the level of assurance this provides; this could range from no assurance to good assurance.

(8) Consumers should understand where a level of assurance and legal liability resides should an issue arise with a transaction from a consumer device.

12.18 Requirements

(1) Implementers must design the common service layers to act independently to enable the removal of application silos without sacrificing existing information security policies and procedures.

(2) All cloud participants must respect the integrity of the supply chain and respect existing IAM practices in place. Elements such as privacy, integrity, and audit ability must be respected. Identity integrity and audit must be preserved when moving data off-site and/or decoupling the pillars of the solution into web service architecture.


===// END //=====