Welcome back to the Cloud Academy presentation of the CISSP examination preparation seminar. We're going to complete our discussion of domain five in the module three, and we're going to begin with identity as a service. We have the electronic identity or e-Persona. Now identity as a service, offers management of identity or information as a digital form, representing the human entity or h-Persona. This identity or e-persona, can be used during electronic transactions and transfers between components, representing that h-persona.

Identity itself refers to a set of attributes associated with something to make it recognizable. So IDaaS, is a variant of software as a service, of cloud-based services that broker identity and access management functions. This is a combination of administration and account provisioning, authentication, and authorization and reporting functions to establish accountability. As such, the IDaaS is a component of a larger, multi-layered security strategy. Primary responsibility is administrative in the creation of credentials and the assignment to resources. One of its primary functions, therefore, is to manage the passwords and their synchronization across the enterprise and its various systems and other components.

We have a number of pieces of functionality for the IDaaS. The first being identity governance and administration. This includes the ability to provision identities held by the service to target the various applications that are available to the entities. Then we have access. Access includes, of course, user authentication, single sign-on and authorization enforcement. The IDaaS functionality has to include a component that provides an intelligence function. Now, the intelligence function provides support and supports the capabilities to log and report on entity access attempts and their various usage activities thus supporting the accountability function of the AAA services of authentication, authorization, and accountability.

So, the features and benefits of most identity and access management systems include the following capabilities. We have single sign-on authentication. Now, this is one of the core services and it is the ability to authenticate users, based on provided credentials, and then allow each user to access multiple, both internal and external services, without having to repeatedly supply credentials to each service.

Then we have Federation. The function of Federation is that the federated identity is where identity and authorization settings are collected from multiple identity management systems. This enables different systems to define user capabilities and access. Identity and authorization are shared responsibility across multiple authoritative sources, and this identity is a superset of authentication and single sign on. Another of the benefits of federation is that it addresses the issue of maintaining control. Its core architecture helps this by combining and retaining in house control of user accounts, while leveraging cloud apps and data.

We have granular authorization controls. Now, access is typically not an all or nothing proposition. Each user is allowed to access to a subset of functions and data stored in the cloud. Authorization maps instruct applications about which resources to provide each user. How much control the security professional has over each user's access depends both on the capabilities of the cloud service and on the capabilities of the identity and access management system itself.

One of the things that we look to identity and access management systems to do is provide administrative functions, preferably a simplification of standard administration functions. We prefer a single management plane for administering users and managing identity across the multiple services. The goal of most cloud-based identity and access management systems is to do just this, but they need to offer granular adjustments to authorization across different applications, while still pulling data from different identity authorities.

One of the necessary features of an identity and access management system is that it can be smoothly and, one hopes, easily integrated with internal directory services. These will include things like LDAP, Active Directory, a human resources system, and other kinds of services to replicate existing employee identity roles and groups into cloud and combined cloud with internal services as well.

We also seek to have the services integrate with the external services typically provided by other providers or with the cloud itself. This should be one of the core benefits of a cloud-based IAM provider, as it offers connectors to common cloud services, so that we do not need to write our own integration code. The benefit here is by offering prebuilt connections to common platforms, the software as a service, the platform as a service, and the infrastructure as a service and their vendors. Integration with these new services becomes more straightforward. 

The cloud identity access management considerations that you see are about how we're going to get this to do what it needs to do and how to integrate it with both internal and external sources of data access. We have the APIs, the application program interfaces, which are going to act as the connectors between the various applications and systems, and between the internal and external components that we want to join the access of.

We have authorization mapping that goes along with it. Now, there are many possible ways to specify authorization rules such as by role or by attribute. The existing access rules already in place in the enterprise may need to be rewritten for a cloud service. Cloud services are not necessarily 100% naturally compatible with those that we have inside. And so rewriting these and acquiring specific APIs to enable connection of internal with external may be something we have to consider.

The access management system, of course, must deal with the subject of audit. In-house systems can be linked with log management and SIEM systems to produce compliance reports and provide monitoring and detection of security-related events. Getting audit logs from cloud service providers, however, remains somewhat problematic. Their multi-tenant models prevent most from providing full logs because the logs would necessarily disclose data from other contributors.

We have, of course, the perennial issue of privacy. Users, their attributes and other information are pushed outside the corporate network and into one or more of the cloud data repositories. The security and privacy controls for the external repositories are not fully under the control of the security practitioner. So, the security architect needs to explore what the vendor does and does not provide.

We have the issue of latency. Now, the rules that propagate from internal IAM to cloud IAM can take some time. For example, if an employee is terminated, or has his or her access rights reduced, there may be a lag between the internal rule change and the cloud services enforcing that change. Latency is the subject to discuss with the IAM provider and a cloud provider. As more and more enterprises move to have the connection between internal and external applications, and the distances that these things have to cover for the transactions that are being processed, latency is a continual problem.

We have the app identity. Once a user is logged in, you may still need to verify that the application he or she is using. And maybe there is no user at all just middleware only. But we have to verify where the requests are coming from. And the answer for many apps today is that as long as you know how to call the service, they don't verify the client, even with medium strength authentication. So once again, you need to consult with both the cloud provider and the architect to get answers to these questions before taking the leap.

And then ultimately, of course, we have to enfold mobile and all of the various issues into our overall strategy. Security teams in all different places are still wrestling with the implications of the cloud and mobile device waves. But technology does not sit still. There is yet another whole paradigm to gear up for. The hybrid of mobile and cloud or, as we know it, bring your own cloud or bring your own device, is of particular relevance because cloud clients are very likely to be mobile. Certainly, they must be constructed to facilitate mobile access. Consequently, there remains yet another account system and domain to manage for the security architect, practitioner and professional. Along with these aspects, we have to consider more. The security professional will need to consider IDaaS as part of the overall approach to identity management within the enterprise. And it means that we're going to have to consider some additional factors.

For example, scope of solution. How far does it reach? What does it integrate with? How much support does it really provide us? The scope of the solution needs to be explored to know the extent and limitations of the particular solution being considered.

As always in security, we need to be concerned with implementation quality. How the implementation is done, how far it reaches, how deep it goes, how superficial it might be, and overall the quality of the implementation to ensure that it is dealing with the actual operational issues properly, correctly and securely. We also need to be sure that we're looking at the standards that are being employed by the various solutions under consideration. The adherence to standards from open and public domains is another area where there is significant variance. The standards have significant implication on system operations as we know. Thus security architects should perform a diligent review to which if any, standards make sense for their business, both in the short and the long terms.

In addition to those, there are some additional considerations that must be made. All people involved in the security question of identity management need to familiarize themselves with the various aspects of identity as a service. Some recommendations would include looking beyond simple cost-cutting. It's well known that administration of identity management and access is a very expensive, oftentimes labor-intensive kind of function. What we have to consider, though, in looking at IDaaS as a potential solution is, is cost the only thing or the major thing? Or are there other benefits that we can accrue by choosing this as a particular service? We could spend less on IDaaS, but we have to consider whether or not there will be financial benefits and how services are accounted for as compared to depreciating purchased assets. It's important for the security architect to be aware of these issues and to address them during the initial planning phase of identity management architecture.

We need to be sure that we focus on both tangible and intangible characteristics and features. The whole point of IDaaS is to remove users and operators from the low-level components underneath so that most of what is going on cannot easily be seen. For example, the solution may have a key management function, but how does one know that the key material is being handled, or even if the service uses a hardware security module at all.

Architects cannot go by features alone. They have to dig in and do their due diligence so that they understand that the intangibles, both visibly and out of sight with a specific offering, are functioning properly to ensure that they understand the risks and benefits inherent in implementing the particular offering. Product comparisons are, of course, a vitally important component of making a decision about any form of identity and access management. But we need to stop fixating on product comparisons.

We need to look at each one for the various features that it offers, but we need to be sure that we're looking at both the positives and the negatives, and not worrying about fixating on a particular product. This is all of course part of our due diligence. And we need to look at making sure that we have a clear definition of requirements and benchmarking against which we can compare each product that we're doing in the comparison.

Comparisons themselves are, of course, relative. And as though they should be fairly transparent, we need to be sure that we have a clear understanding and solid internal requirements against which we can compare the products.

In looking at implementation, always a very serious area, we have to be sure that we don't fall victim to things called turn-key solutions. Architects often assume wrongly that because IDaaS eliminates a great deal of infrastructure deployment, they will be able to, as the saying goes, flip a switch and go. Turn-key does not mean instantaneously available. This kind of a solution, even if it is truly out of the box, does not mean that we can simply flip the switch and go. We have to decide on the various aspects such as deciding on workflows, setting policy, pushing out to clients, ensuring quality assurance, building a notification and support process and other factors to take into account when we consider the implementation and the infrastructure involved.

All of these will take time, first to plan, then to implement, then to assure functionality, and then ultimately, what the operational readiness state is before we actually do the go live. This is all part of the due diligence that we must perform with regard to the service providers to ensure that they have a complete understanding of what we need, and that we do as well. This all, of course, will take time.

Between scheduling, aligning resources and acquiring approval to go forward, it easily can take several months. But regardless of how much time it actually takes, what we must do is the due diligence to map out the proper way of getting all of this stuff designed, implemented and fully properly operationalized, so that whatever benefits we think we're going to accrue, we actually will.

Let's look at an example of one provider of the services. WidePoint Corporation, based in Virginia, provides various forms of identity-as-a-service management solutions. What they provide will be able to, when properly implemented, create secure VPN connections between the organization's network and devices without a proprietary software client, which on its face at least, simplifies implementation. It ensures that employees download sensitive data only to authorized, properly configured and protected devices. So it eliminates one point of concern and that is endpoint control. It also gives us the ability to remotely manage, such as remote revoking of certificates of devices that were lost or stolen, or belong to an employee who has left the organization much like the remote wipe service that we use when a BYOD device has been lost.