Cloud Computing Trends: Assessing IT Maturity and Adoption Practices Arrow to Content

May 23, 2013 | Leave a Comment

By John Howie, COO, Cloud Security Alliance

MSFT considering cloud pic

In keeping with our CSA mission to promote best practices for providing security assurance, I have a few resources to share that can help organizations understand cloud computing trends and assess their own current IT environment with regard to security, privacy and reliability practices, policies and compliance.

Microsoft released a new Trends in cloud computing report, which analyzes the results of current IT maturity and adoption practices of organizations worldwide that have used the free Cloud Security Readiness Tool (CSRT).  The report data consists of answers provided by approximately 5700 people whose anonymized responses to the CSRT’s 27 questions were collected over a six-month period between October 2012 and March 2013.

This report helps organizations understand current cloud computing trends and evaluate IT security areas that are strengths and weaknesses. For example, areas of strength for those who utilized the tool are information security (through deployment of antivirus/antimalware software), security architecture, and facility security whereas areas of weakness are human resources security, operations security, information security (through consistent incident reporting), legal protection and operations management. I encourage you to read the report and see how these trends are evolving over time.

A few months ago CSA recommended Microsoft’s Cloud Security Readiness Tool (CSRT). The CSRT helps organizations review and understand their IT maturity level and their readiness to consider adopting or growing cloud services. The tool’s foundation builds on the Cloud Security Alliance’s Cloud Control Matrix (CCM) to ensure a common set of controls objectives are used to evaluate organizations maturity. The tool is a simple way to adopt Security, Trust, and Assurance Registry (STAR) and CCM principles.

The CSRT tool helps organizations understand their IT readiness so they are in a better place to make informed comparisons and evaluate the benefits of cloud adoption.

 

Building Trust and Security Through Transparency of Service Arrow to Content

May 21, 2013 | Leave a Comment

David Baker Okta

By David Baker, CSO at Okta

 

With the growing movement of enterprises to the cloud, it’s more important than ever that service providers demonstrate and prove good security practices to their customers, in good times and in bad. During an incident, how a cloud provider communicates to its customers says a lot about its commitment to security. Sounds obvious, right? Well, three different times during the past seven months — and once while I was on a panel at the 2012 CSA Congress in Orlando — I’ve learned that it isn’t clear after all. As CSO at Okta, I work closely with our customers and they always ask, “What will you guys do if a breach occurs?”

 

When I tell customers that we’ll proactively reach out to them with written communication within hours of any important incident, they are surprised … which surprises me.We include transparent communication into every service level agreement (SLA), alongside availability guarantees and recovery point and time objectives.

 

SLAs exist so that customers have a means to measure the basic service performance of their providers. SLAscan sometimes be very complex and involve many components. But it’s the communication aspect that I see most commonly omitted. It’s important for cloud providers to incorporate communication protocols into their SLAs to ensure trust and transparency with their customers.

 

Proactive Communication

 

The most basic question that customers have for their cloud providers is finding out if there’s been a breach in service. During last year’s CSA conference in Orlando, the same question came up again and again: “How would I even know if the service is breached?”

 

Typically, when a large consumer-facing provider goes down the company posts a “We’re sorry” or a failmessage on its homepage. This works for a service such as Google, which expects users will visit the site, see the service interruption and then wait for the site to come back online. Users might Tweet about how annoyed they are that Google’s down, but they wouldn’t expect a phone call from a Google rep explaining the problem and detailing the company’s plans to resolve the problem. Large, consumer services such as Google simply have too many millions of users.

 

But for enterprises that rely on cloud services to run their businesses, an impersonal “sorry” on the provider’s website is little consolation during an interruption or breach. They should expect, as part of the signed SLA, a proactive message alerting them to the problem and detailing the response. Maintaining a high-touch customer interaction is essential to building and maintaining trust with customers. Cloud providers may think this seems futile or silly if they have several thousand enterprise customers and need to alert an administrator point of contactat each customer during a service-wide incident. Welcome to the big leagues of enterprise SaaS IT!

 

Transparent Expectations

 

As importantly, communication shouldn’t stop after the initial notification. It’s important for the vendor to update customers throughout the disruption, whether an outage, a breach or a service interruption. Transparency is essential from an enterprise standpoint in order to educate customers about the details of what’s going on, and to build trust that the problem is being addressed, what the target resolution steps are, and what work-around steps can be implemented..

 

Typically, recovery point objectives (RPOs) and recovery time objectives (RTOs) are standard SLA elements that set customer expectations for when the service will be recovered. What these elements don’t do is dictate how — and how frequently — the provider communicates to its customers during the recovery process.Okta provides identity management (IAM) in the cloud and is an extension of customers’ IT team, so we maintain high-touch communication with our customers’ IT teams as frequently as possible. Companies should expect the same when they extend their mail, system log facilities or HR services into the cloud, all of which are important extensions of the enterprise.

 

By setting customer expectations from the outset with a detailed SLA, cloud vendors can assuage their customers’ anxieties — and develop trust for when or if breaches or servicedowntime occur.

 

Continuity

 

Earlier this year, I wrote about how enterprise cloud IT services allow companies to enhance their business continuity plans. Geographic redundancy and layering across multiple AWS availability zones signifies a service’s investment in disaster avoidance and translates into customer’s disaster recovery and business continuity plans. But lets face it, every disaster recovery and business continuity plan document assumes a worst-case scenario, so responsible service providers should work with their customers to develop continuity plans that account for specific worst-case disasters, whether a serious extended service degradation or a significant outage.

 

Though not necessarily baked into SLAs, customers should be able to leverage their providers tohelp assemble a continuity plan tailored to their needs. Objective plans between a cloud service provider and its customers aboutoutage protocols in advance can save a lot of time, frustration and anxiety when a service misses a beat. It can be appropriate to have global or customer-wide SLAs spell out precisely the measures that will be taken in different scenarios to ensure a speedy recovery.

 

The businesses that thrive in the cloud are highly available, disaster resilient and prepared for anything. And they clearly communicate these guarantees to customers through SLAs. These agreements are intended to build trust by guaranteeing open communication when a problem arises and clear explanation about how (and when) the problem will be fixed. The detail in the SLA, and how a cloud provider follows through on those details, says a lot about its commitment to security — during the good times and, most importantly, during the bad times.

 

—-By David Baker, chief security officer of Okta, an enterprise-grade identity management service that addresses the challenges of a cloud, mobile and interconnected business world. Follow him on Twitter at@bazaker.

Plugging “Cloud Identity Leaks” – Why Your Business Should Become an Identity Provider Arrow to Content

May 15, 2013 | Leave a Comment

Vordel tap image

By Mark O’Neill VP Innovation – API & Identity Management, Axway (following Vordel acquisition)

markoneill

Most people have used the Facebook, Twitter, or Google Apps buttons located on Websites to log into third party services. This approach is useful within consumer IT as it enables the user to access various services via their own Facebook, Twitter or Google Apps passwords without the effort of setting up multiple accounts on different websites. This trend has also transferred to the enterprise with employees now actively logging into business sites or business-to-business marketplaces via their own personal Facebook, Twitter or Google passwords. While employees may enjoy this convenience, organizations need to consider if this practice is good for their business?

Cloud Identity Leaks

Let’s take a look at some of the issues associated with employees using their personal passwords to access third party services. If employees are identifying themselves as Gmail or Facebook users and not as employees of an organization, it is difficult for the organization to have an audit trail of employee behaviour on business sites or within business-to-business marketplaces. For example, when the user is logged into Salesforce, ADP or similar services via their own social login it is impossible for the organization to verify their identity, track their activity and govern access. Additionally, the organization has lost all power of de-provisioning these employees from accessing these services once they leave the organization as, they are still logged into the third party services via their consumer identity and the organization can’t do anything about it.

Corporate IT & CSOs Must Regain Lost Ground

At the moment the majority of employees are accessing third party services via their social log-ins. This means they have effectively transferred control of their identity, with associated provisioning and account management abilities, to Google, Twitter or Facebook. As such, corporate IT is at risk of becoming irrelevant and being viewed as an inconvenience to the employee. To use an American Football analogy this is similar to the employee making an end run around corporate IT. Corporate IT can fight back by making it company policy for employees to use the corporate ID to access third party services, and by making it very easy to do so.

The lack of control over employee identities is also of concern to Chief  Security Officers (CSO) who need to know how users are managing passwords, which type of services they are accessing, and evaluate the risk of their identities being hijacked. Typically CSOs will have password policies to address these issues. However, if users are simply bypassing the corporate log-in and logging into third party systems via Gmail– the CSO’s policies are rendered redundant and irrelevant.

Identity Providers

It is clear that organizations need to control how employees are using their social identities to access work related services. Within an identity context, Twitter, Facebook and Google are considered to be Identity Providers (IDPs). This means they literally provide the user’s identity. These services are the location where a user logs-in, usually with a user name and password. Facebook or a similar service will then log the user in and vouch for the user’s identity to other systems the employee is trying to use. Of note, it’s technologies such as OAuth and OpenID which have enabled Facebook, Twitter and Google to become IDPs. There is nothing preventing an organization who wants to become its own Identity Provider from  also leveraging these technologies to do so.

Organizations who want to regain control of their employees’ identities can make it a company policy for employees to log into third party services via the company Intranet. In this way, the organization can become its own IDP enabling the business to vouch for the identity of its employees. Within this scenario employees could log-in via the company Intranet with the organization providing its own links as a springboard to the various third party services the employee uses. In this way, the business can provide an on-ramp from the users log-in to any third party services the employee may be using, and become an  Identity Provider.

An organization can become an identity provider by engaging its developers to produce an internal portal for its employees. However, this approach involves climbing a mountain of complex identity standards. Alternatively, Identity Mediation products offer a Gateway that acts as a spring board from the corporate identity out to third party services allowing the organization to become an Identity Provider and govern employee identities.

Ownership

To conclude, it’s important to understand that Identity Providers such as Google, Facebook and Twitter own the user’s log in, so in effect they own the user. For example, if a user is logging in via Facebook to several services and they cancel their Facebook account, they will no longer be able to log into the service. Therefore, employee identities are becoming increasingly tied to platforms such as Facebook, Twitter and Google. To alleviate this trend, organizations need to take control of how their employees are accessing services and offer an alternative — the corporate login. The organization needs to make it company policy for employees to use the corporate log-in, and most importantly make it very easy to use. Otherwise, employees will continue to use their personal log-ins to access third party sites while continuing to expose the organization to potential risks and a complete lack of governance.

About the author
Mark O’Neill is a frequent speaker and blogger on APIs and security. He is the co-founder and CTO at Vordel, now part of Axway. In his new role as VP Innovation, he manages Axway’s Identity and API Management strategy. Vordel’s API Server enables enterprises to connect to Cloud and Mobile. Mark can be followed on his blog at www.soatothecloud.com and twitter @themarkoneill

Cloud-to-Ground, The Last Frontier? Arrow to Content

May 15, 2013 | Leave a Comment

 

 

 

 

 

Whilst Cloud-to-Cloud service integration is relatively straight forward, Cloud service to on premise integration presents more challenges for the enterprise architect

 

By Ed King, VP Product Marketing –  Axway (following acquisition of Vordel)

Cloud-to-Cloud security integration is now a fairly well solved problem.  Cloud based services allow extremely limited access to backend infrastructure and data store. Typically integrations are done via highly constrained REST APIs and occasionally SOAP Web Services.  Thus, security integration between Cloud based services has largely been focused on access control and API security.  Cloud-to-Ground security integration is the last frontier that must be concurred before Cloud adoption can hit its full stride.  Cloud-to-Ground security integration is a much more difficult and complex technical problem compared to Cloud-to-Cloud integration.  In this blog post we will discuss three key challenges in linking security from Cloud-to-Ground and how to leverage new and existing security technologies to make it work.

It’s 10pm, do you know where you users are?

The first common Cloud-to-Ground security integration problem for an enterprise to solve is to enable an on-premise user already signed-on locally to have single-sign on (SSO) access to Cloud based services.  This is a straightforward problem to solve because most Cloud based services today support SAML and increasingly OAuth 2.0 based federated SSO.  The Cloud service providers invariably offer well-documented APIs for SSO integration based on these standards.  Unfortunately, the preparedness on the on-premise side is not as good.  Traditional identity management platforms support at least SAML, but often as a bolt-on, extra-cost federation module.  OAuth 2.0 support is still more miss than hit.

Instead of just adding a bolt-on federation module, consider deploying a stand-alone Security Token Service (STS) instead.  STS solutions provide token mediation for standard and proprietary token types and broker trust between on-premise and Cloud identity platforms.  The STS approach provides you with the flexibility you’ll need as you expand your Cloud and mobile usage, as well as safeguard you against future changes in federation standards.  There are a number of standalone STS products such as Ping Identity, or you can find it as a feature of most API server and gateway products from companies such as Axway/Vordel and Oracle.

The challenge with Ground-to-Cloud SSO is that today’s employees are no longer bound to the office.  Even if we aren’t all road warriors or work in a field job, most of us take some work home or work from home part-time.  The instinctive IT response is to ask remote workers to use VPN, then the normal SSO flow would work perfectly.  VPN is a cumbersome but viable solution for home working scenarios, but is technically challenging for mobile workers.  VPN while on mobile networks, hotel and public WiFi, or enterprise guest networks can be frustrating to downright impossible.  To solve this problem you need to move the initial login point into the Cloud or in the DMZ, which we will discuss next.

Knock, knock, who’s there?  The outside-in use cases.

Network perimeter security does a good job of obscuring on-premise resources to the outside and blocking direct access from external endpoints.  This creates a technical challenge for integrating Cloud based services with on-premise systems.  Let’s look at two use cases:

(1) SSO from Cloud based identity platforms, and
(2) Data and functional integration between on-premise with Cloud based services.

Above I proposed moving the initial login point from behind the firewall to the Cloud or the DMZ.  A number of Cloud based SSO solutions now exist to do just that.  These Cloud-to-Cloud SSO solutions offer users a comprehensive catalog of prebuilt integrations to popular Cloud based services such as Salesforce, Workday, and Google.  Users can log into services such as Okta, Symplified, and VMware, then SSO to a catalog of Cloud based services without having to tangle with the company VPN.  However, SSO is a misnomer because it is really Dual Sign-On: Cloud and on-premise.  On-premise assets are still protected by on-premise identity management systems such as Oracle Access Manager and CA SiteMinder and are inaccessible to the Cloud based SSO platforms.

To achieve true SSO across Cloud and on-premise, a user who is authenticated by the Cloud/DMZ SSO platform must be able to SSO to on-premise systems and be able to see Cloud and on-premise applications in a single integrated application catalog.  This can be done by introducing a trusted gateway into the DMZ.  The gateway is trusted by the on-premise SSO platform and can take a SAML token from the Cloud SSO platform in exchange for the proprietary token used by the on-premise system, such as Oracle’s Obsso cookie or CA’s Siteminder session token.  The gateway can also perform dynamic URL mapping so the internal applications can be accessed without VPN.  Here is a video showing an example of a user logged into VMware’s Horizon Application Manager in the Cloud then SSO to an on-premise application protected by Oracle Access Manager.

The second case is the integration of a Cloud based application to an on-premise system.  For example, Salesforce.com pushing new customer records into an on-premise Siebel CRM.  Instead of poking a hole in the firewall to allow direct access, the better way to achieve a secured integration is to make on-premise systems look like a Cloud endpoint, thus leveraging the web oriented architecture (WOA) for integration.  This means putting up a REST API façade that can be exposed externally.  This API based integration approach makes integration easier and more secure.  API security can be easily achieved using off-the-shelf API Server, API Gateway, and API Management products.  These products not only control access to the APIs, but can also monitor the flow of date from on-premise systems to the Cloud and enforce data redaction policies for security and privacy purposes.

Are you an identity pusher?  Try to be an identity provider.

Whether it is SaaS, PaaS, or applications you stand up inside IaaS, all these applications still have access control built-in to ensure users can only see and do what their job roles permit.  Where do these applications go for identity data to make authorization decisions?  Traditional software architecture uses either an embedded user repository, or can point to an LDAP Directory.  Either way, an identity needs to be provisioned into the application or local LDAP.  In the case of Cloud, this means pushing identity records from on-premise identity platforms to Cloud based services.  This is the traditional provisioning nightmare that the enterprise has not been able to solve despite throwing millions of dollars at it.  Except the problem just become more complicated by adding external Cloud based resources.  Emerging standards like SCIM and more modern provisioning solutions such as Identropy attempt to solve the Cloud provisioning problem.

The better solution is to have applications, especially Cloud based services, support the claims based identity model, such as Microsoft SharePoint 2010.  The claims based model enables the application to reply on an external identity provider to supply user authentication and role information.  By delegating to an external identity provider, the application can control access without retaining the identity locally.  Here is a video showing how to set up SharePoint 2010 for claims based access control.

Two major challenges have to be overcome for this model to scale.

1)    More Cloud based applications have to support the claim based identity model.

2)    The enterprise must develop its own identity provider service.  This is best achieved by exposing the identity provider service as a REST API.

If you are interested in learning more about this topic, you can view this webinar I presented with Eve Maler of Forrester Research: The IAM-As-An-API Era: You Must Become A Cloud Identity Services Provider

Summary
Cloud-to-Ground security integration is still a challenge and most solutions are not very elegant, yet.  However, enough technologies already exist such as API Servers, Cloud Gateways, Cloud SSO and Security Token Service that can build on your existing security infrastructure to provide good solutions today.  New emerging technologies and standards such as OpenID Connect, SCMI, UMA, HTML5 WebSocket all hold promises to make these solutions increasing better, more secured, and more scalable.

 

Ed King VP Product Marketing Emerging Technologies Axway (recently acquired Vordel)
Ed has responsibility for Product Marketing of emerging technologies around Cloud and Mobile at Axway, following their recent acquisition of Vordel. At Vordel, he was VP Product Marketing for the API Server product that defined the Enterprise API Delivery Platform. Before that he was VP of Product Management at Qualys, where he directed the company’s transition to its next generation product platform. As VP of Marketing at Agiliance, Ed revamped both product strategy and marketing programs to help the company double its revenue in his first year of tenure. Ed has also held senior executive roles in Product Management and Marketing at Qualys, Agiliance, Oracle, Jamcracker, Softchain and Thor Technologies. He holds an engineering degree from the Massachusetts Institute of Technology and a MBA from the University of California, Berkeley.

 

Page Dividing Line