Do Amazon and Google get privilege? If you rely on a public cloud provider to manage highly sensitive applications, it's a question worth asking.

Within the context of the identity and access management space, privilege is generally understood in terms of controlling users who have high levels of authorization to, and control over, corporate IT systems, information assets and applications. In that important, but somewhat narrow context, poor control over privileged user accounts is an all-too-common source of risk both from a security and compliance perspective.

Whether you know it or not, privilege permeates your business: people, policies, processes, applications and data. Nevertheless, they are not always your people, or your infrastructure, your development platform, or your applications. As corporations outsource to managed service, hosting and cloud providers, they increasingly cede direct control to someone else's privileged users, who apply privileged processes and procedures to other people's data - your data. Truly, privilege is everywhere.

This understanding is at the core of privilege-centric risk management as enterprises balance the business benefits of increased outsourcing, especially in cloud environments, and the challenges of entrusting high-value business data and operations into the hands of third-party entities. As outsourcing and the various instantiations of cloud-based services become increasingly essential to business operations, enterprises need to find ways to exercise governance over their critical assets and operations by extending control over privilege, both internally and externally.

Service providers, for their part, must be prepared to address their clients' privilege/risk management requirements to maintain a strong competitive position in the market. By not effectively demonstrating strong privilege control policies and processes that are consistent with those of mature organizations - their potential customers - service providers could potentially leave a lot of business on the table.

That said, the onus remains on the enterprise to take a holistic view of privilege, risk and control across their IT environment - wherever it is - from the corporate data center to software as a service. Before committing critical or sensitive assets to a cloud service provider, organizations must assess the risk to the business if something goes wrong. Let's examine the key steps enterprises should be taking to ensure that risks of outsourcing are properly addressed.

Ten Steps for Securing the Extended Enterprise

1. Put privilege first: Implement a privilege-centric risk management program for internal IT operations so that the enterprise can insist that the service provider follow policies, processes and practices that are consistent with its requirements.
2. Policy follows the user: Make sure that the enterprise has privileged management policies, and processes and tools are applied to internal users leveraging outside services. For example, if you are licensing 100 Unix machines from a cloud vendor, you still need to use privileged identity management to make sure privileged accounts are recycled, that user access is audited, and that access adheres to policy.
3. Provider is in sync: Make sure the service provider has privileged identity policies and processes are consistent with those of the organization.
4. Reality check: Review and evaluate the service provider's security structure and processes as part of the vetting process. Make sure they are not "paper policies." In particular, look for privileged identity management tools that support and automate their policies and processes.
5. Put it in writing: Privileged identity management policies and processes, audit and report requirements, and use of appropriate technologies should be written into contracts and service-level agreements.
6. Define roles: Insist on policies that limit privileged user access and authorization. The service provider must be able to demonstrate clear separation of duties, especially for privileged users.
7. No hidden passwords: There should be no use of hard-coded embedded application passwords that grant database access.
8. Measure success: The service provider's program must demonstrate continuous control and monitoring. There should be clear metrics, mutually agreed upon, to show that security policies are being applied and that privilege control is continuously improving.
9. Log and report: All privileged user accounts, privileged asset access, and privileged process activity should be logged and audited. Service providers should issue weekly or monthly reports that give the enterprise visibility into its operations. This visibility is critical, particularly as contracted services move up the stack to SaaS.
10. It is in the details: Depending on the service model - more so for managed and hosted services, less so for higher-level cloud services - reports should include detailed reporting on each time a service provider used privileged accounts on the enterprise's systems.

As more and more of their IT environment moves to the cloud, enterprises must appreciate that the need for a privilege-centric approach to risk takes on even greater importance and understand that it is their responsibility to implement a program at the core of its IT operations. It is no less important to extend that program to its service providers, rewarding those that can meet its requirements with their business.

Fortunately, as service providers develop mature practices around privileged identity management, enterprises will be able to demand and expect, if not the same level of control, a level of assurance that is commensurate with the sensitivity and significance of the business assets they are willing to entrust.

At the end of the day, whether their solution is based on-premise or in the cloud, a vendor's goal should always be to gain the trust of their potential customers through whatever means possible. Across the extended enterprise, "Getting privilege" is a significant part of that equation.

That means you too, Google and Amazon.