Security Considerations When Evaluating Google Apps Marketplace Applications Arrow to Content

July 19, 2012 | Leave a Comment

By: Tsahy Shapsa, VP of Sales & Marketing and Co-Founder, CloudLock

 

 

Customers care about the security of their data in the cloud, and security of customer data is obviously important to Google, which is why Google has invested in completing numerous security audits and certifications such as FISMA, SSAE 16, and recently, ISO 27001.

 

Since 2010, we’ve had the honor of engaging with some of the largest Google Apps customers in the world. When dealing with these large organizations (as well as smaller ones that care about the security of their data), at some point during the evaluation process, “security assessment” questions arise.

 

One might argue that the real value of Google Apps is not contained to messaging and collaboration, but rather in the ability to transform the way businesses consume applications. This transformation is demonstrated and driven by the Google Apps Marketplace, offering hundreds of applications, broken down into multiple categories, which any Google Apps customer can add to their domain with a click of a mouse.

With great power, comes great responsibility, and as enterprise IT Security professionals know, adding Google Apps Marketplace applications extends the security perimeter of the organization to include that application, and the company behind it (including the employees).

 

Here’s the warning message displayed when installing a marketplace application:

Explanation:

 

Technically speaking, adding non-Google services (aka “installing” marketplace applications) to a domain, is really granting privileges for that application to access the domain and end-user data. Different applications require access to different data repositories: documents, spreadsheets, and calendar are just a few examples.

 

Security of organizational data is a critical part of any comprehensive DLP strategy. Security audits and certifications can be equally important to internal auditors, legal and compliance teams, as well as customers (if the company is hosting customer data).

Google reminds customers that it is their responsibility to trust and verify 3rd party (non-Google) services they would like to add to their domain.

 

How do customers trust and verify 3rd party applications?

 

Here’s a quick checklist that any organization can use in evaluating whether to add a marketplace application to their domain:

 

Assessing the trustworthiness of a marketplace application provider

Here’s a quick explanation around each one of the security controls and its impact on the level of trustworthiness of the marketplace application provider. Highly trustworthy 3rd party application vendors will be able to provide the security assurances customers require proactively:

 

  • SSAE 16 Audited – having this means that a 3rd party auditing company has reviewed and attested to the security controls reported by the application vendor
  • System Security Plan (SSP) – a system security plan is a ‘must have’ to be considered even somewhat trustworthy. Just having an SSP isn’t enough as anyone can write their own, and security officers should look for independent verification of the controls, procedures and processes reported in the SSP
  • Ongoing Application Vulnerability Scanning - A standard practice for any SaaS application
  • Customer Security Assessment - In lieu of an industry standard security audit, prospective customers should demand the app provider to respond to a security assessment which will capture the controls they have in place. These include employee background checks, documented and implemented policies and procedures, change management, monitoring, and vendor self-audit verification
  • Application is strategic to the vendor – if the app is not strategic to the vendor’s core business, chances are that the necessary investment in security controls didn’t take place. And security does require an ongoing investment (as anyone who’s gone through a security audit will testify)

 

In summary, security of customer data should be important to all of us.

 

Security is important to Google - As is evident by their heavy investment and excellent track record in world class security

 

Security is important to customers - To protect organizational data, to adhere to legal requirements, and to ensure that the organization’s security perimeter is not compromised by adding non-trustworthy services.

 

Security must be a top priority for vendors to be trusted - Trustworthy third party vendors make no compromises, and continuously invest, audit, and innovate around their security practices.

 

Though the transition to the cloud has brought unprecedented sharing, availability, and collaboration benefits to organizations of all sizes, companies must be aware of the 3rd party vendors that now have access to corporate data, and must be able determine whether those vendors pose a security risk.

 

 

Tsahy Shapsa is the VP of Sales & Marketing and Co-Founder of CloudLock, where helps the largest Google Apps customers in the world bring DLP to their data in the cloud. Prior to founding CloudLock, he held various business and technology management roles with companies like Sun Microsystems and Network Appliance, both domestically and internationally.

 

Some Things To Consider When Extending Your IdM Into The Cloud Arrow to Content

July 19, 2012 | Leave a Comment

 

About Author
Mark O’Neill is CTO of Vordel, a company which enables companies to connect to mobile and cloud

 

Like many organizations, you no doubt face the challenge of extending your IT operations into the cloud to take advantage of the many cloud-based services demanded by your users today. As you make the transition from a firewall-protected in-house IT infrastructure to an IT environment that extends into the cloud, one challenge you cannot ignore is how to also transition your identity management (IdM) platform in such a way that you ensure the security of your new hybrid on-premises and cloud-based IT approach.

Indeed, IT organizations today must consider a number of things before they transition to a cloud-centric IdM strategy, including the probability that they must deal with a number of complex security challenges posed by multiple identity storage siloes.

 

IT organizations historically have had their own on-premises identity stores containing directories such as Active Directory or Novell. Their IdM challenge was to successfully federate these IdM stores if, for example, they were doing business with, or merging with, another company and needed to tightly integrate the identity stores of both entities. This historical IdM federation challenge, as a result, was small and contained within a small number of organizations working together.

 

In today’s cloud-centric IT environment, the challenge of IdM federation has grown exponentially.  As organizations extend their IT infrastructures to take advantage of the many cloud-based services available, they are faced with a proliferation of different on-premises and cloud-based identity stores because their users have multiple IDs – both corporate and personal – that they use at access multiple cloud-based services.

 

The proliferation of cloud-based identity siloes has clearly gotten out of control, so corporate IT organizations are now trying regain control – starting by taking a tally of all the different cloud-based services that are being used by employees and then developing a strategy for managing these identities. Meeting this challenge increasingly falls to CIOs and their staffs.

 

How should they proceed? In many situations, the choice comes down to either integrating identities across their cloud-based services on a one-by-one basis, linking each one back into the on-premises system, or instead adopting a socialized model using an off-the-shelf product to link together their on-premises IdM systems with many cloud-based services in one go, thereby avoiding the complexity of doing it on a one-by-one basis.

 

Consider your options

 

IT organizations must consider three options in developing an IdM strategy that successfully manages multiple identity storage siloes in a hybrid on-premises and cloud-based IT environment. If their company’s employees use a number of cloud services such as SalesForce.com, Dropbox, Concur for expenses and Google apps for email, then they can either (a) give the employee five passwords (which the employee is likely to forget), (b) have the employee use the exact same password everywhere (but then require it to be changed everywhere at once if they suspect it has been compromised), or (c) enable the employee to log  into all of the cloud services by logging into the company’s system with a single sign-on.

 

Option (c) clearly is preferable. It’s simple for the employee to remember and use. And it’s much more easily provisioned and managed by IT.  The employee never needs wrestle with, or even know, the passwords for the company’s cloud-based services.

 

Complete visibility is critical for the success of this single sign-on strategy. The IT organization must have visibility of all the cloud-based services that are being used. If single sign-on services have been implemented, IT can turn the cloud-based services off, just as easily as they turned them on.

 

One of our clients — an education management firm that manages over 100 private colleges with 150,000 students inNorth America– provides an excellent example. Each college has its own portal and homepage providing the students with access to the various student services offered by the college. The common portal creates a common identity across all of the student applications and services – making it far easier for IT to manage. As a result, the student’s college password allows single sign-on access to a number of different cloud-side applications, including various Google offerings, that otherwise would each require its own password. When students log into the college portal, we log them into Gmail. Google Apps or Google Docs based on a single sign-on. And when the students graduate and leave college, we turn off single sign-on and remove the account.

 

Leverage industry standards

 

Industry standards also must be considered when extending your IdM platform into the cloud. Standards are shaping the way the federation of on-premises and cloud-based services can be set up and managed to ensure security.

 

A number of standards are in use today. For single sign-on, there’s Open ID and OAuth that allow you to log into one service – your internal systems – then use that identity to log into the other systems without handing your password over to those systems. You log into an Identity Provider and, if the other systems (the Service Providers) trust the Identity Provider, they allow you to log into their systems. For example, powered by Open ID and OAuth, today you can log into other systems using your Facebook, Google or Twitter credentials instead of theirs. And you don’t even need to create a new account with a new password for these systems.

 

Another standard, called SCIM (Simple Cloud Identity Management), is also important to consider when you are addressing the need for cloud-based user management. SCIM allows you to manage user identity up in the cloud, enabling your users to be easily provisioned and de-provisioned for cloud-based services.

 

Adhering to standards to build a secure cloud-based IdM platform, however, is not enough. You also must construct an entire framework for identity management, including an audit trail for transactions to ensure identities are not compromised and real-time monitoring that provides a real-time view of what’s going on.  This framework also must provide the scalability needed to accommodate all of the users who need to log in at any one time.

 

… And don’t forget the regulations

 

Last, but certainly not least, you must be aware of and address the regulations governing the use of the cloud for IdM. Different jurisdictions have different rules governing data retention, how and where information about your users can be stored, and the user notifications required regarding changes to personal information stored in the cloud. These regulations can vary greatly from country to country and must be considered based on the geographies in which your company is doing business.

 

 

Cloud Security Best Practices: Sharing Lessons Learned Arrow to Content

July 10, 2012 | Leave a Comment

By Frank Simorjay, Sr. Product Marketing Manager, Microsoft Trustworthy Computing

Compliance regulations and frameworks can be difficult to comprehend and even harder to explain to management when it’s time to invest in mastering IT governance. TheCloud Security Alliance (CSA) has taken steps to help make this complex effort simpler for everyone as they work to be in compliance. Looking at the STAR, Microsoft has worked to outline the critical thinking steps required to understand the complexity of complying with any framework or regulation. The STAR assessment makes this effort a bit cleaner and simpler to understand.

To help customers better understand compliance efforts, Microsoft published a newMicrosoft approach to cloud transparency white paper that illustrates the benefits of using the STAR to enable the transparency of cloud services. The paper focuses on three cloud service offerings including Windows Azure, Office 365, and Microsoft Dynamics CRM and provides visibility into how these services are operated using the evaluation criteria documented in the CSA STAR. Since the ISO 27000 standards family is important to many of Microsoft’s customers, the paper also outlines how Microsoft’s cloud services are operated to meet or exceed the standards. The paper provides an overview of various risks, governance and information security frameworks and standards to consider when looking at cloud computing as a solution includingISO/IEC 27001, the Control Objectives for Information and related Technology (COBIT) framework, and NIST Special Publication (SP) 800 series.

If you are considering using a cloud service provider, check to see if they have submitted answers to the CSA STAR to learn more about their security and privacy practices.  If the cloud provider has not submitted a self-assessment to the CSA STAR, you can use the free framework provided by the CSA to ask the cloud provider the questions that are relevant to your organization.  Understanding how your cloud provider manages security and privacy to operate their cloud services can help to minimize headaches down the road that might arise.

Frank Simorjay, Sr. Product Marketing Manager, Microsoft Trustworthy Computing, CISSP. Currently, Frank heads  up the Trustworthy cloud effort for security, privacy and reliability effort for Microsoft.  Most recently Frank was responsible for the Security Intelligence Report ( www.microsoft.com/sir) and a security subject matter expert . Frank is the founder and long standing member of ISSA Puget Sound, and a standing CPAC member for ISSA International. Additionally Frank is a CSA solutions provider representative.  Formerly, Frank was a Security Product, and Program Manager and compliance subject matter expert (SME) for Microsoft Solutions Accelerator. Prior to joining Microsoft Frank was a senior engineer for NetIQ and for NFR Security, where he designed security solutions for enterprise networks in banking and telecommunication for more than 10 years.

 

 

 

Think beyond securing the edge of the enterprise. It’s time to secure the “edge of the Cloud” Arrow to Content

July 9, 2012 | 2 Comments

By Ed King, VP Product Marketing, Vordel

 

Everyone is familiar with the notion of securing the edge of the enterprise.  With the growing adoption of cloud technologies, IT must now also think about securing the “edge of the Cloud”.  The edge of the Cloud is the perimeter around any Cloud environment where it touches the open Internet.  In this post we examine just what security at the edge of the Cloud means and how enterprises can achieve a Cloud security strategy that is consistent with their existing on-premise strategy. How an enterprise chooses to secure the edge of the Cloud has a direct impact on what Cloud strategy it adopts. The various flavors of  SaaS, IaaS, PaaS, private, public and hybrid Cloud solutions all have individual security requirements that we will examine.

 

Edge of the enterprise security includes what gets deployed in the demilitarized zone (DMZ) and beyond, and can be divided into the three following areas of network, application and data security.

 

  • Network security focuses on keeping the bad guys out and securing communication channels.  Technologies include network firewalls, intrusion prevention and detection systems (IDS/IPS) and virtual private networks (VPN).
  • Application security is about giving good guys access to approved resources under the right context, by securing application access points. Technologies include web application firewalls (WAF), application/XML/SOA gateways and identity management.
  • Data security is about maintaining the data on the inside, as well as securing any data going out. Technologies include leakage prevention (DLP), encryption and tokenization.

 

So how does edge-of-the-enterprise security apply to the edge of the Cloud? With public and hybrid Clouds there is at least one third-party company involved, so who owns what aspects of security needs to be clearly defined.  By default, an enterprise should assume it has the ultimate responsibility for securing the Cloud services it uses, including security at the edge of the Cloud, despite whatever reassurances the Cloud provider might offer.  The enterprise needs to define a security strategy for Cloud usage and delegate to Cloud service providers what they can provide and manage.

 

Security for the edge of the Cloud differs by the type of Cloud based services.

 

Software-As-A-Service (SaaS) Security

A SaaS vendor owns its application delivery infrastructure, which makes things simple but limiting for enterprises looking to secure SaaS.  Enterprises have no say in how security is implemented and have to trust the SaaS vendor’s documented security policies and SAS-70 certification. In an earlierCSAblog we discussed how enterprises can adopt a “don’t-trust” model when dealing with Cloud based services.

 

While network security and data security are take-it-or-leave-it, some SaaS vendors offer a few application security options.  Multi-factor authentication is a popular option, especially with software tokens such as Verisign ID Protection (VIP).  Many SaaS vendors also provide SAML (Security Assertion Mark-up Language) based integration so enterprise users can single sign-on from on-premise identity management platforms such as CA SiteMinder, IBM Tivoli Access Manager, or Oracle Access Manager.  OAuth based federation is also quickly catching on for enterprise use.  This in-deptharticle on SSO to Cloud based services provides extra reading.

 

While enterprises have a limited choice when it comes to directly securing the edge of SaaS Clouds, they should as a minimum, ensure the protection of the API keys.  API keys are used to authenticate applications calling SaaS APIs.  API keys are frequently distributed directly to application developers and hard-coded into applications.  This is a insecure and unscaleable practice.  Consider using a DMZ-based solution to securely manage and store the API keys, and broker the authentication of on-premise applications to the SaaS.  Technologies designed for this purpose go by a number of different names: API Server, API Gateway or Cloud Service Broker.  These technologies also monitor data traffic going to the Cloud to block, mask or encrypt sensitive data.  This podcast offers more information about API key security.

 

Infrastructure-As-A-Service (IaaS) Security

An IaaS vendor provides hardware, the operating system and some software options.  Network security is typically provided as a standard service.  Communication is secured using SSL and VPN.  As with SaaS, network security for IaaS is also a take-it-or-leave-it proposition.  In contrast to SaaS, since the enterprise has complete ownership of what applications are deployed in the IaaS environment, it has complete responsibility and a good degree of flexibility when securing its applications at the edge of the Cloud.

 

Application security starts with an application firewall.  Network firewalls are not content aware and cannot protect applications against attacks such as cross-site scripting and injections.  A WAF is good for protecting web applications but provides limited protection for APIs.  API security products offer comprehensive API protection but lack WAF’s self-learning capabilities.  Application firewalls should be deployed as standard services for the IaaS, so every time an application is deployed in the IaaS, an application firewall service is spun up to protect that application.  Look for firewalls that can be deployed in the Cloud, can be spun up and down elastically, and can protect REST/JSON style APIs.

 

Once the IaaS perimeter is protected from attacks, the next task is to control access to the application resources, including the API and data.  Identity management technologies typically handle access control and single sign-on (SSO) to enterprise applications deployed on-premise.  For IaaS environments that are accessed exclusively via VPN, enterprises can treat the applications deployed there like on-premise application.  This typically requires deploying an agent as the policy enforcement points (PEP) for each application.  Deploying agents can be expensive and error prone, especially in a highly dynamic IaaS environment where applications are spun up and down frequently.  Using a proxy based PEP is more scalable and secure for IaaS deployed applications.  For applications that need to be accessible to third-parties, consider using a federation model instead of requiring third-parties to obtain VPN access.  To enable proxy based access control and federation, enterprises have two technology options.  Cloud based federation services are single-purpose products that do well for user/browser access.  It is a good low-cost option if API access is not important.  To support both user and API access to IaaS deployed applications, consider the API security products mentioned above.

 

For data security, DLP technology can work equally well for applications deployed in IaaS and for applications deployed on-premise. DLP should be made available as a standardized service that can be automatically provisioned as part of the IaaS provisioning process.  Since API security and security gateway products offer standard DLP functions as well, it may be feasible to use those products for both application and data security.

 

Platform-As-A-Service (PaaS) Security

PaaS lets enterprises develop and deploy applications completely in the Cloud.  While there are public PaaS offerings such as CloudFoundry.com, Force.com,and Engine Yard, enterprise adoption of PaaS will likely be predominantly in the form of private Clouds.  In terms of network security, application security and data security, PaaS is very similar to IaaS.  Regardless how an application is developed, once it is deployed in the Cloud, the run-time security is much the same.

 

What is unique about PaaS is the infrastructure services required for the development of applications, especially those services that need to connect PaaS applications to on-premise systems.  These services can be for integration of security, data, process or management.  Take identity management as an example.  Applications developed on PaaS should not have their own identity silos in the Cloud.  These applications will need access to identity, policy and entitlement data from on-premise identity management systems.  For instance, developers need an Account Service in the PaaS that can provide identity data from the corporate directory.  Leading PaaS providers do offer a library of standard infrastructure services, but the backend integrations that connect these services to on-premise systems remain the responsibility of the enterprise.

 

To create these infrastructure services for PaaS involves two parts.  First, create Cloud-ready APIs for on-premise systems.  In other words, create REST style APIs out of existing SOAP based web services (or JavaAPI, JMS, MQ, PL/SQL or other legacy interfaces).  Use a technology like an API Server to create, manage, deliver and secure these APIs so they can be exposed to the PaaS.  Next, at the edge of the PaaS Cloud, deploy API Brokers to mediate the security and protocol requirements from different on-premise API sources.  Vordel’s CTO Mark O’Neill has blogged about an interesting example of edge-of-the-Cloud security for VMware’s Horizon Applications Manager.  See post here.

 

It’s Time To Take Edge-of-The-Cloud Security Seriously

Too often security is an afterthought when enterprises adopt new technologies.  Cloud is no exception.  Cloud computing introduces new wrinkles to existing security best practice and technologies.  Cloud computing creates an additional perimeter, the edge of the Cloud, that the enterprise must now secure.  How an enterprise chooses to secure the edge of the Cloud has a direct impact on what Cloud strategy is feasible.  SaaS, IaaS, PaaS, private, public and hybrid Cloud solutions all carry their unique security requirements that need to be factored in.  The good news is that enough security technologies already exist today to make secured Cloud computing a reality even for the most risk-averse enterprises.

 

CNIL (French Data Protection Authority) recommendations on the use of cloud computing services Arrow to Content

June 28, 2012 | Leave a Comment

On June 25, CNIL – the French Data Protection Authority – published its recommendation on the use of cloud computing services. This recommendation is the result of a research project on cloud issues, which started in the Fall of 2011 with a consultation with industry. The documents released by CNIL include a summary of the research and documents; a compilation of the responses received to the consultation, and a set of recommendations.

Below are a summary of the recommendations, provided by CSA’s General Counsel, Francoise Gilbert, and reproduced here from her blog with permission:

http://www.francoisegilbert.com/2012/06/cnil-on-cloud-computing/

The recommendations includes:

  • Clearly identify the type of data and type of processing that will be in the cloud
  • Identify the security and legal requirements
  • Conduct a risk analysis to identify the needed security measures
  • Identify the type of cloud service that is adapted for the contemplated type of processing
  • Choose a provider that provides sufficient guarantees

The CNIL document also provides an outline of the contractual clauses that should be included in a cloud contract and contains “Model Clauses” that may be added to contracts for cloud services.  These model clauses are provided as a sample, are not mandatory, and can be changed or adapted to each specific contract.

Except for a high level summary in English, the documents described above are currently available only in French on the CNIL website.  According to CNIL representatives, English translations of these documents should be available shortly.

  • Overview of CNIL Recommendation – Summary in English:

http://www.cnil.fr/english/news-and-events/news/article/cloud-computing-cnils-recommandations-for-companies-using-these-new-services/

  • Overview of CNIL Recommendation – Summary in French

http://www.cnil.fr/la-cnil/actualite/article/article/cloud-computing-les-conseils-de-la-cnil-pour-les-entreprises-qui-utilisent-ces-nouveaux-services/

  • Compilation of the responses to the CNIL consultation on cloud computing (in French)

http://www.cnil.fr/fileadmin/images/la_cnil/actualite/Synthese_des_reponses_a_la_consultation_publique_sur_le_Cloud_et_analyse_de_la_CNIL.pdf

  • Recommendation for companies wishing to use cloud services (in French)

http://www.cnil.fr/fileadmin/images/la_cnil/actualite/Recommandations_pour_les_entreprises_qui_envisagent_de_souscrire_a_des_services_de_Cloud.pdf.

 

 

Free Your Data & the Apps Will Follow – But what About Security? Arrow to Content

June 22, 2012 | Leave a Comment

About Author
Mark O’Neill is CTO of Vordel, a company which enables companies to connect to mobile and cloud


Application Programming Interfaces (API) represent such an important technology trend, that new business models are evolving on top of them, and this has led to the term “The API economy”. The API economy encompasses API developers, the businesses providing the APIs, the businesses hosting APIs and app developers. This growing API economy has resulted in a switch in the mindset of many organizations that are now making access to internal data readily available to third parties, enabling partners and customers to develop value-added applications on top of this data. As such, many organizations no longer hold information close, but actually are seeking to make it available for external developers to write apps on top of the data. While many organizations are naturally concerned about the security risks posed by opening up and sharing access to data and indeed how they can derive long-term revenues from new API-led business models, the good news is that these concerns are being addressed. In fact, if organizations are not prepared to play in the API economy, they run an even greater risk of being left behind. In this article we look at some of the security challenges APIs pose, and how these can be addressed to ensure organizations don’t miss out on the opportunities API offer.
The Organization is now the Platform

APIs thrive on data. Examples include shipping information APIs (shipping data), financial quote APIs (financial data), and geographic APIs (location data). The popular maxim around the API economy notes that if an organization is willing to free its data, the applications will follow.

This new paradigm shift driven by APIs has also impacted at board room level. CEOs now expect their CIOs and CTOs to be able to showcase iPhone and Android app versions of their latest service offerings. However rather than asking “why are we not building iPhone applications,” the CEO should be asking, “why aren’t we allowing others to write iPhone applications on top of our data?” In other words, the goal of the organization should be to become a transparent platform for serving up data to third parties who can develop mobile apps on top of this platform. This means that the business effectively becomes a platform. For example, if a Financial Services company provides APIs enabling any developer to write the application, then it becomes a platform itself.

 

 

 

 

Secure API Delivery

So we’ve seen how APIs enable enterprises to deliver business services via Cloud, mobile, and partner channels quickly and flexibly. Enterprises need an agile API Server platform to ensure quick time-to-market with new business services. APIs handle critical business transactions and often have direct impact on customer interactions and business’s ability to execute. Poor API security and performance can result in lost sales, missed opportunities and inability to deliver. Every API requires a supporting infrastructure to make sure the APIs are properly managed, delivered, and secured.

 

Strong security is also essential as organizations need to monitor any suspicious usage of APIs in order that their APIs can be safely deployed, without compromising the data. Critical business functions such as ordering, fulfilment and payment are conducted via APIs. Attacks on these business critical services can result in loss of revenue and sensitive data. On the one hand, “enemy fire” attacks and exploits are becoming more sophisticated and organized, while on the other hand, the proliferation of API clients is subjecting APIs to increased levels of “friendly fire” from poorly engineered or malfunctioning clients. Organizations need to protect their APIs from both enemy and friendly fire alike.

Protect APIs Against Enemy and Friendly Fire

Threats that organizations need to consider protecting their enterprises against include such all common attacks as outlined in the NIST SP800-95 document “Common Attacks Against Web Services”[i] which include:

  • Denial of service attacks
  • Command injection attacks
  • Malicious code, virus
  • Sniffing
  • Spoofing, tampering, and impersonation
  • Data harvesting
  • Privilege escalation
  • Reconnaissance

The increase in both number and variety of API clients can also lead to a larger number of poorly engineered clients, as well as an increase in incidents of client malfunction. A misbehaving client repeatedly sending requests can cause as much damage as a denial-of-service attack. Organizations need to protect their APIs from potential “friendly fire” by monitoring API call volume and client behaviours. Clients exhibiting disruptive behaviours can be blocked or throttled.

 

Conclusions
APIs are increasingly being exposed to larger and more diverse populations of developers and applications. With this increased exposure, comes inevitably increased levels of operational and security risks. To guarantee good availability and user experience; IT must have security, control and monitoring capabilities as part of its API delivery platform. Having an API Server to manage, deliver and secure APIs is central to any coherent API strategy.

 



[i] Link to http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf

Outline of BCR for Processors Published by Article 29 Working Party (EU) Arrow to Content

June 20, 2012 | Leave a Comment

On June 19th, the Article 29 Working Party, which is composed of Data Protection Authorities from the member states of the European Union, released an important opinion on the use of a legal means to move personal data outside of the border of the EU, called Binding Corporate Rules (BCRs). The guidelines apply to data processors. This has implications for cloud computing in Europe. The following blog entry on the Working Party’s opinion was written by the external legal counsel of the CSA, Ms. Francoise Gilbert of the IT Law Group. We repost it here with her permission.
http://www.francoisegilbert.com/2012/06/outline-of-bcr-for-processors-published-by-article-29-working-party/

Outline of BCR for Processors Published by Article 29 Working Party

Posted by fgilbert on June 20th, 2012

On June 19, 2012, the Article 29 Working Party adopted a Working Paper (WP 195) on Binding Corporate Rules (BCR) for processors, to allow companies acting as data processors to use BCR in the context of transborder transfers of personal data, such as in the case of cloud computing and outsourcing.

WP 195 includes a full checklist of the requirements for BCR for Processors and is designed both for companies and for data protection authorities.  The document provides a checklist outlining the conditions to be met in order to facilitate the use of BCR for processors, and the information to be found in the applications for approval of BCR to be presented in the application filed with the Data Protection Authorities.

Are Network Perimeters the Berlin Walls of Cloud IdM? Arrow to Content

May 14, 2012 | 1 Comment

A single enterprise wide identity and access management (IAM) platform is a noble but unattainable goal. The network perimeter is now a metaphorical “Berlin Wall” between the two identity platform domains of Cloud and On-Premise. It is time for enterprises to formalize a strategy of integrating their IAM silos using identity middleware.

 Over the last decade, Identity Access Management (IAM) has grown into a well-established product category anchored by the three big vendors: CA, IBM, and Oracle.  Despite all the hard work and technologies developed, most customers have implemented just basic web single sign-on (SSO), have provisioned only a handful of core systems, and still have far too many directories.  Oh, then there is still that Microsoft problem.  The integration of Microsoft technologies such as SharePoint with enterprise IAM is still like mixing oil and water.  Microsoft centric customers turn to Microsoft centric vendors such as Quest and Omada, while other customers treat Microsoft integration like a red-haired stepchild.  Furthermore, whilst most organizations are still struggling to implement enterprise-wide IAM across on-premise assets, along came Cloud Computing to muddy the water even more.

Cloud based services post a new set of challenges as they are not owned by the enterprise and each service offers its own flavor of IAM integration.  Vordel’s CTO Mark O’Neill has written extensively about the different challenges of IAM integration for IaaS, PaaS, and SaaS.  Mark affectionately refers to this topic as “covering your *aaS”.  As often is the case, leading IAM vendors are slow to address the Cloud integration problems.  Seeing opportunities, new IAM vendors have emerged offering Cloud based IAM services.  This group of vendors includes startups such as Okta, Symplified, and Tricipher (acquired by VMware), as well as large vendors like Intel/McAfee and Symantec, new to the IAM space.  The basic offering of these Cloud based IAM services is a Security Assertion Markup Language (SAML) based security token service (STS) with pre-built SSO integrations to popular Cloud based services, usually referred to as “application catalogs”.  There is usually some means of integration with an enterprise directory using an on-premise agent.  These services make it very simple to SSO into the most popular Cloud based services, and have gained good traction from enterprises large and small.  That is positive progress, right?  Not exactly.

Instead of further consolidation and moving towards a true vision of enterprise-wide IAM, enterprises now find themselves with more identity silos than ever.  Let me count the ways:

  • “Enterprise IAM” solutions from CA, IBM, Oracle, or one of the smaller vendors.  Many large enterprises have more than one of these.
  • Microsoft silo with integrations directly to Active Directory using Integrated Windows Authentication (IWA) and Active Directory Federation Server (ADFS).  Each Windows domain or SharePoint instance may be an individual silo.
  • Many point solutions exist specifically to solve the SharePoint mobile access challenge.
  • Mainframe IAM integration is notoriously challenging.  Instead of tackling RACF and ACF2 integrations, most companies opt to delay these projects, hoping these legacy applications will be modernized soon.
  • Cloud-based IAM for Cloud-based services.  This is often adopted by the business, bypassing enterprise IAM efforts.
  • Large business application vendors such as Oracle and SAP continue to push integrated IAM capabilities.  This limited interoperability is by design, leveraging their business application footprint as a mean to push their middleware sales.

 

This proliferation of IAM silos has led to an explosion of agents, proxies, plug-ins and integration modules.  For many enterprises, the management of these integration points consumes the majority of their IAM project resources.  For some, they have long lost track of how many of these integrations modules exist in the enterprise.

I think it is time to pronounce that a single enterprise wide IAM platform is just a noble but sadly unachievable idea.  While enterprise should strive to reduce the number of IAM silos, at some point the effort becomes prohibitively expensive.  However much we wish it to be the case, Cloud based IAM services is not the solution to this problem, it is just compounding the problem.  It is time for enterprises to formalize a strategy of integrating their IAM silos.  It is time to introduce the concept of “identity middleware”.  Identity middleware is a class of technologies that integrates identity silos introduced by different technologies, vendors, standards, network boundaries and business ownerships.  Identity middleware does not duplicate capabilities offered by standard IAM products.  It does not introduce another identity silo.  Identity middleware’s sole purpose is to consolidate IAM silo integrations into a single technology and platform to enhance manageability and scalability.  Identity middleware should have these capabilities at a minimum:

  • Exchange standard-based and proprietary tokens (security token service)
  • Authentication scheme that can handle combination of user, device and application identities
  • Encryption and signing
  • SSL termination
  • Certificate and key management, with integration to key stores and certificate authorities (CA), as well as integration to Hardware Security Modules (HSM)
  • Token and session caching and management
  • Add, delete, and modify security artifacts to and from messages and APIs running on HTTP, FTP, TCP, and other popular protocols
  • Configurable orchestration of IAM mediation tasks
  • Route messages and API requests based on policy
  • Out-of-the-box integrations with leading IAM products and services
  • Support leading standards, such as SAML, OAuth, WS-Security, XACML, OpenID… etc.
  • Secure operations at the edge of the enterprise and edge of the Cloud to mediate both Cloud-based and on-premise access
  • High performance and low latency

 

IAM is not a pure infrastructure technology.  IAM technology shares many of the characteristics of business systems.  It is closely integrated and often embedded within business systems.  It also needs to integrate with other IAM systems from business partners.  Just like application integration requires mediation middleware, so does IAM integration.

Where can you find identity middleware technologies?  While identity federation technologies handle standard token mediation tasks (mostly SAML based), it lacks the configurable orchestration and message manipulation capabilities required to be a true identity middleware platform.  Today your best bet is look to integration technologies such as application gateways and enterprise service buses.

 

 

 

 

 

 

Look for a gateway or service bus that offers:

  • Out-of-the-box integrations with leading IAM products and services
  • Strong support for Microsoft security technologies, namely Integrated Windows Authentication, Kerberos, and SPNEGO
  • Support for mainstream standards such as SAML and OAuth

If your use cases involve integration across network boundaries to Cloud, B2B, and mobile endpoints, then only the gateway will suffice, since enterprise service bus is not suitable for deployment in the DMZ.

Ed King VP Product Marketing, Vordel
Ed has responsibility for Product Marketing and Strategic Business Alliances. Prior to Vordel, 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 joined
Oracle as Senior Director of Product Management, where he built
Oracle’s identity management business from a niche player to the undisputed market leader in just 3 years. Ed also held product management roles at Jamcracker, Softchain and Thor Technologies. He holds an engineering degree from the Massachusetts Institute of Technology and a MBA from theUniversity ofCalifornia,Berkeley.

Cloud Market Maturity Arrow to Content

May 2, 2012 | Leave a Comment

by Henry St. Andre, CCSK | Trust Office Director | inContact

The Cloud Security Alliance, in conjunction with ISACA will be initiating a new working group to perform research on what it means to have Market Maturity in the Cloud.  This is a very interesting subject for me.  I have been working in the telecommunications and data industry now for over 25 years.   During that time, I have observed in real terms the application of the phrase ‘ahead of its time’ and what that can mean to a nascent industry or technology.  As an example, people are amazed to discover that the technology that would become the fax machine was first invented in 1843, in England by Alexander Bains (a psychologist).    Yet it took almost 100 years for the fax machine to become the common business tool it is today.   Some of the technological factors that influence the maturation of a product include communication, computing, fabrication, miniaturization and materials.   Ultimately, one of the most critical factors is whether or not the technology exists to manufacture the product or perform the functions in a cost effective fashion, and whether there is sufficient ubiquity of that technology to allow the masses to utilize it.  There are, however, two other important elements, I believe in the maturation of a product or service.  Are people psychologically disposed to using it and is there a legal and regulatory environment that describes its use?

Psychology has a huge impact on the acceptance and use of a technology and product.  I am 50 years old now, and I remember slide rules, record players, cassette tapes,  typewriters, Cobol , acoustic modems, DEC Writers, Archie and Gopher.  I have been engaged in technology all my life and am fairly comfortable with it, but still, I know that I view technology and in particular the Internet very differently than my children do.    Take my smart phone.  It does 101 things, and oh yeah it makes phone calls.  I know about those 101 things, and I some of those 101 things, but the main reason I have a cell phone is to make calls.  But, personally, I prefer not using a cell phone to make calls.  I think it is inferior to my traditional ‘land line’ phone and I will use a land line phone if I have the choice.  My children, on the other hand, use their smart phones for 101 different purposes, and sometimes to make phone calls.   Similarly, I find that the maturity of the cloud as a product that is both used and accepted by the masses is not simply a function of whether the technology exists to provide the service in a cost effective fashion, but also whether or not people are comfortable using it.   For this reason, I believe that the younger generations, will be greatest drivers of the cloud market and its maturation.   People of my generation are adopting the cloud because of the economics.  Our children will use the cloud because they will think it is the obvious way to do things.

Finally, laws and regulations, in some ways we hate them, but ultimately businesses need them.  While it is true that businesses can be choked by over regulation, it is also true that businesses flounder when there is uncertainty.  When there is an absence of laws and regulations that establish the rules of the game and the field of play, it creates uncertainty and fear for businesses.  Uncertainty and fear can kill a business model.  Because the cloud and the technology that has supported and enabled it has changed and developed so quickly, laws and regulations are struggling to keep up.

That is changing, and organizations like ISACA and the Cloud Security Alliance have been and will be instrumental in that change.

This Cloud Market Maturity project will be an important endeavor.   The results and guidance from this project will provide legislators, technologists, consumers and businesses with the guidance and information that each needs in order to further the progress of this new Cloud Model.

Outsourcing B2B Integration: The Forgotten Option Arrow to Content

May 1, 2012 | Leave a Comment

Business continuity remains a major concern for enterprises as they move more mission-critical processes to the cloud. Outsourcing B2B integration while ensuring cloud security in order to effectively integrate business processes is challenging at best and ambiguous for certain.   All too often, IT professionals feel that they will lose the reliability and availability needed if they don’t implement an on-premise cloud environment.  However, there can be strategic approaches to outsourcing integration that include both a secure cloud environment for business processes as well as reliability and availability that extends beyond traditional borders.

 

Gartner defines outsourcing as follows: “A model in which a business acts on behalf of consumers of one or more cloud services to intermediate and add value to the service being consumed. Providers of cloud services can also benefit through the establishment of an ecosystem of partners which enhances the provider’s service and draws customers to it.”  October 2010: Defining Cloud Services Brokerage: Taking Intermediation to the Next Level.

 

When comparing outsourcing B2B cloud integration to on-premise solutions, a major area of consideration is the security of cloud implementations. The burden of addressing the needs of an enterprise’s partner community while meeting the needs of moving to a more secure connection methodology is difficult, especially when it comes to the disparity of transport protocols utilized. And let’s not forget the cost of adhering to the multiple of security compliance organizations to help safeguard the data can be astronomical. For example, an outsourcer gets to spread the cost of implementing PCI DSS compliance over their multiple tenants. Everyone benefits without the individual capital outlay.

 

Before implementing any cloud strategy, there’s a basic set of questions that all organizations should address before moving forward. This includes: ”Which cloud implementation is best for our company’s needs? Do we outsource the cloud or manage it ourselves?”  Also be sure to educate your self on common industry terms and jargon such as cloud outsourcing, cloudsourcing, and cloudware. Eventually as you continue to compare outsourced and on-premise cloud security concerns, you’ll notice that it ultimately boils down to whether both options can be as secure as enterprises require.

 

Clearly, one of the implementations an enterprise can address is B2B integration. The process of an enterprise extending its IT processes to its business and trading partner community including customers, vendors, suppliers and distributors is no easy task, but can be done efficiently and securely. The pressure for enterprises to connect more closely with their partner communities, tear down walls and optimize business processes such as procurement, eCommerce, supply chain management, inventory visibility, and logistics optimization is higher than ever.

 

It has been debated whether B2B integration is really needed by enterprises or whether companies can get by with putting their applications in the cloud and provide broader access.  From thorough conversations with enterprise customers, it is evident that there is a lot of pressure on IT departments today to mitigate data center overhead and provide a more efficient way to incorporate others into their ecosystem.

 

Many in the industry also question whether providing B2B integration on-site is an IT department’s charter or whether the IT pros should instead spend their time on more strategic projects and initiatives to help drive revenue. If there is agreement to integrate processes, which more and more companies are considering, then the options are: keeping things as status quo, build it yourself and keep it on premise, as many IT departments have today, or outsource to a cloud-based platform.

 

Taking a look at these three options can certainly result in a lively discussion.  Keeping things at status quo for most organizations means having manual processes, time-intensive quality control resulting from errors that occur, requires in-house expertise on subject matters such as cloud security, and the loss of revenue and/or opportunity because of the lack of implementing in a timely and cost effective manner.  However, building the cloud integration environment yourself and keeping it on-premise may solve a specific integration challenge but does not necessarily provide the broader implementation that is conducive to the changing business environment.

 

The burden of finding and selecting the right combination of software, middleware, appliances, and hardware falls on you as opposed to relying on someone else that already has the environment where those decisions and tests have occurred. The outsourcer has invested their time and resources to ensure a secure and robust environment those other companies can leverage. This allows for quicker implementation resulting in achievement of business goals.  In fact, the high upfront and ongoing capital expense to create a battle-tested cloud environment is clearly something all IT managers need to consider. Typically, the cost just to get started will entail a $50K to $100K hardware and software expense; implementation and consulting services is about $25K to $50k or more and the cost for the on-going support and maintenance is at least $50K to $100k annually.

 

However, by leveraging a cloud platform to integrate your business processes, companies don’t have to pay any of the upfront cost. Instead, they can leverage the power of the internet without having to install additional hardware or software.  The limited upfront cost is focused around getting an organization and its community on-board quickly. The subscription based model that the “outsourcer” adheres to is an operating expense and eliminates the capital expenditure approval process.

 

While there is criteria to evaluate when considering whether to build or outsource, many organizations will find that planning resources related to the core competency of a business as opposed to whether a team has the skill set to implement and manage the B2B integration will be another hurdle they must address.  The ability to minimize the time-to-market, enabling enterprises to be more competitive in a timely manner, is critical to meeting the demands of the ultimate consumer.  Do enterprises have the resources needed to on-board partners quickly? Most, if not all, do not.

 

Last but not least, we must consider the security and compliance implications. When an outsourcer has integrated data it’s important to transport security into their model as well. This indication is best suited to ensure a safe full loop data process.  Since many companies work with partners that have their own security policies, it is unrealistic for the enterprise to expect their community to follow their security guidelines.  An outsourcer mitigates the disparate security policies to ensure a smooth and secure experience.

 

As companies continue to evaluate their cloud strategy and debate the implementation of an on-premise solution or utilize an outsourcer, there are many considerations to ponder. Discuss these issues and realize for your own organization that there are many ways to successfully implement a cloud integration strategy.

About the Author:

Stuart Lisk is a Senior Product Manager for Hubspan, working closely with customers, executives, engineering and marketing to establish and drive an aggressive product strategy and roadmap.  Stuart has over 20 years of experience in product management, spanning enterprise network, system, storage and application products, including ten years managing cloud computing (SaaS) products. Stuart holds a Certificate of Cloud Security Knowledge (CCSK) from the Cloud Security Alliance, and a Bachelor of Science in Business Administration from Bowling Green State University.  For more information, go to www.hubspan.com or follow the company on Twitter @Hubspan

 

Page Dividing Line