Favorite Quote

"..the market seems to have come to the conclusion that cloud computing has a lot in common with obscenity-- you may not be able to to define it, but you'll know it when you see it." James Urquant

Monday, November 15, 2010

Replacing Your Cisco XML Gateway? Forum Systems Can Help!

Company Augments Cisco ACE XML Gateway Replacement Program to Offer Direct Trade-in Credit for Any XML Vendor Gear, No-cost Training, Migration Best Practices and More

BOSTON, Nov. 15, 2010 /PRNewswire/ -- Forum Systems, a wholly owned subsidiary of Crosscheck Networks, Inc., today announced a comprehensive program to reduce costs, allay concerns and answer questions for organizations seeking to deploy XML Gateways.

On the heels of introducing the latest version of its flagship Forum Sentry XML Gateway, Forum Systems has extended its Cisco ACE XML Gateway Replacement Program. Effective now through March 31, 2011, the Program includes:

-Direct trade-in credit in exchange for any XML Gateway hardware and software;

-No-cost, on-site migration to Forum Sentry XML Gateway policies;

-No-cost Forum Sentry Training Certification Program;

-Dedicated 24x7x365 support by experts with a minimum of five years experience.

Additionally, to help organizations ensure a smooth migration, Forum Systems offers the following Best Practices for Selecting an XML Gateway:

-Choose a Patented Product: Selecting a non-patented XML Gateway only leads to product replacement, and ultimately, additional acquisition costs.

-Scrutinize XML Gateway Architectures: Understand XML Gateway and ESB/Application Server differences. With security of paramount importance, clear role segregation should be enforced – and custom code never introduced into an XML Gateway.

-Demand an Independent Security Assessment: Integrating an HSM crypto card into the appliance does not improve security or constitute compliance. The entire XML Gateway must be FIPS 140-2 certified in order to guarantee security and compliance.

-Validate Comparable Functionality: To eliminate functional gaps, the selected XML Gateway must be architected with modular policy design for fundamental constructs so that keys, encryption/signature policies and firewall rules can be easily transitioned.

-Stipulate Flexible Replacement Costs and Options: Demand vendors that will work within corporate budgets and timelines. Vendors should be flexible in offering options that help reduce capital expenditure expense, migration and maintenance costs.

"XML Gateways represent a critical, foundational element for IT groups and the run-the-business applications and services that drive their organizations," said Crosscheck Networks CEO Mamoon Yunus. "By abandoning the Cisco ACE XML Gateway, Cisco is forcing its customers to find other alternatives. Our expanded Replacement Program – coupled with our best-in-class Forum Sentry – gives these, and other enterprise organizations evaluating replacing their XML Gateway, a smooth migration path to a better solution from a company they can depend on."

Forum Sentry: The XML Gateway Gold Standard
Processing more than one billion transactions per day globally, Forum Sentry is the industry standard for XML and SOAP security, access control and integration. Unlike other vendors that introduce runtime code into their appliances to compensate for inherent design limitations, Forum Systems' Forum Sentry is certified by NIST and the U.S. Department of Defense, and the XML Gateway of choice for 300 global organizations in transaction- and security-intensive sectors including government, financial services, telecommunications and healthcare. The latest version, Forum Sentry v8.0, helps organizations securely extend their enterprise SOA deployments to harness the power of the public cloud.

-No-cost Cisco ACE XML Gateway Replacement Quote

-No-cost Forum Sentry XML Gateway Evaluation

-Cisco ACE XML Gateway Migration Strategies

-Forum Sentry XML Gateway Data Sheet

Press Releases
-Forum Sentry Eases Enterprise-to-Cloud Migration; Enable Seamless Extension of SOA to the Cloud

-Forum Sentry Issued Industry-first Patent for XML Security Functions Including XML-encryption, -XML-decryption and XML-signatures

-Forum Sentry Provides Secure, Unified Integration of XML and SOA Web Services and Portals for Seamless End-user Experience

About Forum Systems
Forum Systems and its parent company Crosscheck Networks deliver solutions for deploying robust, resilient, secure and reliable Service Oriented Architecture (SOA). More than 50,000 users in 42 countries across organizations such as the U.S. Treasury, British Telecommunications, Fidelity, Premera Blue Cross and the Dutch Health Care System rely on Forum Systems and Crosscheck Networks as the backbone of their secure transaction processing. Recognized as a technology innovator and security leader, Forum Systems is the only company granted a patent for its Forum Sentry XML Gateway and has been certified by NIST and the U.S. Department of Defense. Forum Sentry is the de facto standard for XML and SOAP security, and Forum Systems has key OEM relationships with Barracuda Networks and Radware, among others. For more information, please visit www.forumsys.com.

All product and company names herein may be trademarks of their respective owners.

Friday, January 8, 2010

Multi-cloud Mayhem

If you're having trouble getting your head around a single cloud deployment, please feel free to skip this article.  Now if you're someone who thinks that most IT resource will eventually live in a private or public cloud-based domain, you're not alone, and you may start looking into how best to work in a multi-cloud environment.

Paul Krill's article "Cerf urges standards for cloud computing" highlights cloud interoperability and portability issues discussed by Vint Cerf, co-designer of the TCP/IP protocol that forms the back bone of modern communication.  It behooves us to consider Cerf's viewpoint on what's required for successful cloud computing.  Some of the points that he makes are as follows:

According to Cerf, "Strong authentication will be a critical element in the securing of clouds."  We know that authentication is a core for establishing trust between transacting parties.  This requirement is now further heightened because of the expansion of corporate boundaries out to cloud-based services.  Authenticating to cloud services and accessing only authorized services in a multi-tenant environment will continue to be the most important aspect of establishing trusted connections between enterprises and IaaS, PaaS and SaaS providers.

Now imagine having a set of enterprise applications and systems that have to interact with a set of cloud providers, in a many-to-many topology.  You may, for example, call a SaaS for a commodity business service to create your composite service, while archiving information to Amazon S3 and running intensive business intelligence queries on Amazon EC2.  In this scenario, cloud services, even from the same vendor, may expect different identity tokens, some standards-based, others proprietary.  The problem of multi-cloud computing decomposes to fundamental issues including identity token management, security, and central management and control of such functions.

Here are a couple of resources that are helpful in highlighting identity related issues surrounding cloud computing:

The second item that Cerf points out is regarding moving your data (business information, virtual images, algorithms, database instances, etc.) between different cloud providers. According to Cerf, "At some point, it makes sense for somebody to say, 'I want to move my data from cloud A to cloud B,' " but the different clouds do not know each other."

Cloud interoperability has a number of dimensions including communication interoperability (HTTP, SOAP, REST), cloud management and interaction API interoperability (createImage, terminateImage, etc.), and image portability.

The good news is that at least most cloud providers have a REST-XML/JSON or a SOAP-based API.  The API calls signatures are all different, but one can readily consume such APIs for image provisioning/de-provisioning and other IaaS functions.  There has been a recent effort to standardize cloud API operations including Open Cloud Computing Interface Working Group.

In addition to such API standardization, moving entire images between various cloud providers would also provide the portability necessary for establishing reliability across multi-cloud environments.  Instead of maintaining multiple images for say Amazon EC2 and Rackspace, having a single image that runs across IaaS providers would reduce management burden on enterprises.  The DMTF Open Virtualization Format provides a common container formats for greater multi-cloud portability.  Here are a couple of resources that one should review while looking at best practices for cloud interoperability and portability:
Cloud gateways have become a core component of managing not just the traffic between enterprises and their cloud providers, but also for managing and protecting security and identity tokens required for enterprise-to-cloud interaction. To avoid Multi-cloud Mayhem, the industry now needs to show greater commitment towards standardization for inter-cloud interoperability, portability and security. Unless our desire is to relive the stone-age era of pre-TCP/IP communication, ask Vint Cerf, he'll give you a few reason on why not to.

Wednesday, December 30, 2009

Cloud computing may exacerbate security and file transfer issues

Here is an interesting article by Rob Barry titled: "In SOA, cloud resources may exacerbate security and file transfers issues." It highlights significant requirements for Federated SOA especially around large file transfer using SOAP Attachments. The article makes the following interesting points:

With increasing cloud adoption, there is an increase of large file transfers to external cloud providers such as Amazon S3 or Rackspace CloudFiles or to a company's internally hosted cloud.  The file size increase is driven by the a low-hanging use case for S3 and CloudFiles:  securely archiving rarely used corporate data in the cloud.  The result of such archiving of batch data is an ever-growing file transfer over HTTP as a MIME of MTOM attachments.  Consider the opposite scenario:  if the data is real-time the transaction rate is higher but the files sizes are usually small.  According to Frank Kenny,  Gartner Research Director:  "As we start to use more cloud-based services, the problem is going to exacerbate itself because we're dealing with bigger data, bigger attachments," said Kenney. "But we want the same performance that we've always been able to maintain."

MTOM and MIME are now widely used for real-time file transfer of large files over web services instead of legacy FTP (still the dominant, dirty protocol for batch data transfer).  Files are now readily transferred over SOAP with content-based security (XML-Security) as well as protocol security (SSL). Watch Managed File Transfer (MFT) vendors start to add HTTP-SOAP/XML stacks to their offerings and edge appliance vendors such as Forum Sentry start to encroach on the MFT space.  Such XML gateways already support FTP, sFTP, FTPs, AS/2, PGP, etc. for managing file transfers in addition to XML messaging. Standards such as MIME and MTOM are now being heavily deployed. For a deeper understanding regarding how MTOM works, see "Intro to MTOM."

Identity is critical to Federated SOA. SOA deployments are usually executed within "Domains" with distinct business and technical owners for a set of services that are provided internally or to external Domains. SOA Domain Jumping requires establishing establishing trust through identity token exchange. For cloud computing to succeed, identity management has to succeed and so does successful deployment of a Federated SOA model.

Tuesday, December 29, 2009

The Guillotine Effect of Cloud Computing

David Linthicum of InfoWorld wrote an intriguing article titled "Cloud Computing will kill these three technologies" in which he writes obituaries for:  i) design-time governance ii) older and smaller clouds iii) and Tier 2 enterprise software providers.  Of these predictions, the one that resonates most is design-time governance.

Design time Service Governance:  I am particularly happy to see this category listed on the chopping block (from David's perspective) and here is why.  Over the last decade or so, we have seen significant run-time SOA Governance deployments at the edge of an enterprise used for interacting with SaaS platforms using SOAP, XML or REST.  We have seen customers choose not use glorified UDDI registries. Instead, they have focused on using the SOA/Cloud/XML Governance Gateway as the system of truth for services produced and consumed (import and export WSDLs).  The Gateways serve as the catalog of services aggregated for centralize control at design-time.  Based on consumer credentials, access to only authorized services is provided to the consumer.

David is spot on in stating: "Many of the existing runtime SOA governance players support enough design and implementation capabilities that separate design-time tools are not required."  The burden of design-time SOA Governance has entirely been taken over by XML Gateways including service generation and consumption, service cataloguing, service virtualization, and most importantly, service monitoring.  Gateways are, by nature, non-intrusive and agent-less, whereas classic service monitoring companies are historically rooted in agent-based monitoring with weak gateway products, if any.  Such agent-based solutions are unlikely to work in highly distrubuted environments typical of cloud computing.  Try asking your SaaS partner to put an agent in their container -- good luck!

The writing is on the wall, so I quote David here directly:
Cloud computing is simply accelerating the focus on the requirement for runtime SOA governance, and sooner or later design time will fall by the wayside.
For addtional technologies that face a not-so-fun-filled future, see David's ominous article: "Cloud Computing will kill these three technologies."

Monday, December 28, 2009

MIT Techology Review covers Cloud Security

MIT Technogy review recently published a great article titled: Security in the Ether addressing security, privacy and reliability issues resulting from cloud computing.  Some of the interesting points in this article include:
  1. The cloud security threat is across two related dimensions:
    • cloud resident data may be lost due to equipment/software failure or stolen by a hacker because of the shared resouce nature of cloud computing.
    • cloud data may be mishandled by the cloud provider because of technology gaps, but more importantly, such information can be extracted through a court issued subpoena.  Whether the data resident in the cloud versus on-premise makes it more or less likely to a subpoena being exercised is yet to be seen.  Bit and bytes lost accidentally or intentionally have a strange way of persisting and being recovered eventually.  22 Million emails "lost" during Bush's era were "suprisingly" recovered by computer technicians recently.
  2. Cloud outages are directly related to security vulnerabilities.  A single corrupted bit caused Amazon S3 outage is 2008.
  3. Cloud vendors can provide rapid remidiation that is transparent to the cloud consumers.  If there is a security. reliability, or scalaibility flaw, cloud vendors can patch their platforms quickly and address the problem.  This is their core business, so theoritically, they should be on their toes more so that an enterprise IT team with only 5%-10% of the corporate budget tied to IT.  The continual battle/cost justification faced by CIOs for more IT budget to enhance infrastructure only delays the remediation process againsts new and emerging issues.  The speed of remediation by cloud vendor should be more rapid than enterprise IT Data centers owing to the scale of impact and the number of companies calling in for quick remediation.  Fault tolerance by using multiple cloud providers will become crucial for enterprises seeking to reduce the risk even further in case of failure cause by a security exposure is a particular cloud.  The ecomomics of using multiple cloud providers will be far more compelling that sticking with a single provider or an on-premise deployment for storage- and cpu- intensive applications.
  4. "The very term cloud computing should be replace by swamp computing." Ron Rivest, MIT Computer Scientist, co-inventor, RSA public key cryptography algorithm.
  5. Granular encryption will become a significant factor in protecting data in the cloud.  This has been the cornerstone of XML and SOAP Security where any element or fragment can be encrypted with any selected key.  Using XML/Cloud Gateways such as Forum Sentry, any information that is to reside on a public cloud can be granularly encrypted using a hierarchy of keys.
Security in the Ether, by David Talbot

Wednesday, December 23, 2009

Cloud Reliability will be bigger than Cloud Security for 2010-11

We have all the tools for securing information in a Cloud: establishing trust through identity, data privacy through encryption, and content integrity through signatures.  We are overly focused on Cloud Security  issues and less on reliability.  This is all about to change.  Following the outages experience by Amazon EC2 in 2009, another premiere cloud provide, Rackspace, suffered an outage on December 18.  Using technology such as Forum Systems XML/ Cloud gateways is essential for establishing multi-cloud reliability and fault tolerance.
Rackspace Cloud Computing Outage
— According to an Apparent Networks Performance Advisory issued today, cloud services provider Rackspace experienced a connectivity loss at its Dallas-Fort Worth data center on Dec. 18, 2009. Access to business services at that data center was not possible during the outage, which began at approximately 4:37 p.m. eastern time and lasted about 35 minutes. The Apparent Networks Performance Advisory is based on intelligence provided by the company’s Cloud Performance Center, a free service that utilizes Apparent Network’s PathView Cloud service to test the performance of cloud service providers such as Amazon, Google and GoGrid.

Thursday, December 17, 2009

Understanding Cloud Taxonomies and Security

OWASP AppSec DC 2009 had a compelling session that defined cloud taxonomies and the security implications associated with the cloud computing.  The three taxonomies that have become part of our vernacular are:
  1. Infrastructure as a Service (IaaS):  Set of virtualized components that can be assembled to build a application.  Amazon EC2, Rackspace, Opsource, and GoGrid are examples of IaaS where you can rent "virtual" hardware and software as a "pay-as-you-go" services.  If you need 5 Linux servers running MySQL Database for 3 months, you'd subscribe to an IaaS provider and using their REST or Web service-based API (or command line if you're too cool) to provision, de-provision and monitor your instance.
  2. Platform as a Service (PaaS): A runtime environment for application developer to deploy their applications in their desired programming environments with production issues such as scalability, security and reliability already addressed by the Platform.  Google App Engine, the support Java and Python is a good example of PaaS. Using PaaS developers can code applications locally on developer machines and push them to the cloud.  The developed applications can automatically scale to millions of invocations and thousands of users.  The developers do not have to concern themselves with managing threading, concurrency and load balancing issues for such almost unbound scalability.
  3. Software as a Service (SaaS): Fully functional application with potentially and API for external application integration.  SugrarCRM, Netsuite and Salesforce.com are classic examples of SaaS in the CRM space.  SugarCRM can be used as an fully functional enterprise CRM systems and can also be accessed through Web services APIs for integrating on-premise application.  See for example:  Web services Testing SugarCRM.
For more details on Cloud Taxonomies and Security, see Understanding Implication of Clouds on Application Security.