Consumerization 101 – Employee Privacy vs. Corporate Liability Arrow to Content

July 31, 2012 | Leave a Comment

Mary D. joined MD&M Inc. in 2009. Being an Apple enthusiast, she was quite excited to learn that the company offered an innovative BYOD program that allows employees to use their own iPhone for work. As part of the new hire package, Mary signed the acceptable use policy and was granted access to corporate email on the go.

Mary’s started having performance problems in her second year and her manager put her on notice. After six months, Mary was terminated. When her manager clicked the ‘terminate’ button within the company’s HR system, a series of automated tasks were initiated, including the remote wipe of all information on Mary’s iPhone.

As it turned out, Mary had been performing poorly because her son John was dying of cancer. Just a few weeks before Mary was terminated, her husband took a picture of her and his son using Mary’s iPhone. It was the last photo Mary had of her son, and MD&M Inc. unknowingly destroyed it. Mary sued the company for damages.

Just how much is the last photo of a mother and son worth? Attorneys and expert witnesses sought to answer that question. They arrived at $5 million.

Three pitfalls your BYOD program can’t afford to ignore.   

While Mary’s story is a fictitious case debated last year by the International Legal Technology Association (ILTA), it’s just a matter of time before stories like this become mainstream reality. A recent survey by Trend Micro clearly shows that a majority of companies are already allowing employees to use their personal devices for work-related activities– 75% of organizations in the U.S. offer BYOD programs.

Besides preserving data security and managing a myriad of personal devices, companies must also consider a new set of legal and ethical issues that may arise when employees are using their own devices for work. Here are just three pitfalls to consider:

Pitfall #1: Remote deletion of personal data:  Under what circumstances (if any) should the company have a right to remove any non work-related content from an employee-owned device?

Pitfall #2: Tracking individual location: What corporate applications might ‘track’ the location of an employee-owned device?  Is the employee aware that this is possible?

Pitfall #3: Monitoring Internet access: Should accessing questionable websites be restricted, when an employee is also using a personal device for work?

 

NEXT: BYOD Best Practices – Three pitfalls you can’t afford to ignore.

 

Cesare Garlati, Vice President Consumerization and Mobile Security, Trend Micro

 

As Vice President of Consumerization and Mobile Security at Trend Micro, Cesare Garlati serves as the evangelist for the enterprise mobility product line. Cesare is responsible for raising awareness of Trend Micro’s vision for security solutions in an increasingly consumerized IT world, as well as ensuring that customer insights are incorporated into Trend solutions. Prior to Trend Micro, Mr. Garlati held director positions within leading mobility companies such as iPass, Smith Micro and WaveMarket. Prior to this, he was senior manager of product development at Oracle, where he led the development of Oracle’s first cloud application and many other modules of the Oracle E-Business Suite.

 

Cesare has been frequently quoted in the press, including such media outlets as The Economist, Financial Times, The Register, The Guardian, Le Figaro, El Pais, Il Sole 24 Ore, ZD Net, SC Magazine, Computing and CBS News. An accomplished public speaker, Cesare also has delivered presentations and highlighted speeches at many events, including the Mobile World Congress, Gartner Security Summits, IDC CIO Forums, CTIA Applications and the RSA Conference.

 

Cesare holds a Berkeley MBA, a BS in Computer Science and numerous professional certifications from Microsoft, Cisco and Sun. Cesare is the chair of the Consumerization Advisory Board at Trend Micro and co-chair of the CSA Mobile Working Group.

 

You can follow Cesare at http://BringYourOwnIT.com and on Twitter at http://twitter.com/CesareGarlati

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.

 

Page Dividing Line