March 31st, 2011

The ESG pattern


Category Uncategorized
 
Are you still considering rolling out a major Enterprise Service Bus (ESB) stack — you know, the kind that involves a massive initial investment and takes 8+ months to deploy? This wasteful approach was a major factor in doomed corporate SOA initiatives that were common between 2003 and 2009. During this same period, clever architects ignored large vendor promises and realized that you simply cannot buy your way into an agile enterprise SOA. They instead focused on the tasks at hand, integrating existing IT assets, following SOA principles, using existing tools and adding lightweight strategic and specialized infrastructure to help them along the way. The winning enterprise SOA initiatives are the ones who made sure that the SOA was operational as it evolved. SOA Gateways gained popularity in recent years as a lightweight ESB that can span departmental boundaries. Like software ESBs, SOA Gateways can translate data formats, route content, service-enable data sources and switch between transport protocols. But SOA Gateways have a number of significant advantages over traditional software ESBs. For example, they scale easily and accommodate high volume traffic environments owing to their specialized acceleration of message validation, routing and translation. Also, SOA Gateways offer comprehensive security and identity federation features built in so they can be deployed at the service zone perimeter (think DMZ). Looking back, the pattern of using an SOA Gateway to integrate and service-enable existing IT assets has been a large success. Because of the appliance form factor and the configure, not code approach, the cost of integration and the time to react to new requirements both shrunk considerably. And with a focus increasingly shifting towards cloud computing, this ability to quickly accommodate new integration mechanisms has already paid off for those who invested in the lightweight, agile solution. This is especially the case for those who opted for the virtual appliance form factor. I like to refer to this pattern as the Enterprise Service Gateway (ESG). That is, the ability to execute integration, transformation and security using a specialized gateway appliance as opposed to coding using traditional software ESB frameworks.
March 30th, 2011

The API Gateway As Endpoint

Written by
Category API, Security, SOA
 
The US Customs and Immigration station at Point Roberts is a small building set on the edge of the coastal rainforest of Washington State. It is the last customs station in a vast western chain strung out along the 49 parallel. I enjoy crossing the border at Point Roberts. The abrupt change from sprawling Canadian suburbs to American rural countryside always appeals to me. The customs station, despite it’s small size, offers a range of services from granting a visa to simply giving advice about where to find a good deal for gas in Point Roberts. It’s not simply a gateway controlling access into the US, but a provider of a broad range of services associated with crossing an international boundary. There exists a similar duality with API gateways. Although the common deployment is as a border guard, protecting APIs hosted by an organization, an API gateway can also act as an endpoint providing valuable standalone services. Nearly all of my customers first purchase SecureSpan Gateways to fulfill the role the name implies: that is, an API or service gateway. The border guard deployment pattern is now so commonplace that I no longer need to evangelize it as I did in the early days of Layer 7, close to a decade ago. Architects recognize this pattern as an accepted best practice for securing and managing APIs. But like the Point Roberts border station, a SecureSpan Gateway can also provide services that have nothing to do with access control or transaction confidentiality, but provide value on their own, independent of any APIs they may be guarding. Here’s a very simple example illustrating the endpoint pattern using a SecureSpan Gateway. Normally I might deploy my gateway in front of a web server, acting as an authenticating reverse proxy for my web pages. In this role, the gateway is responsible for access control, SSL management, audit, lightweight load balancing, etc. All classic gateway functions. Figure 1: Gateway as boarder guard at the edge of a network. This is classic perimeter security. But suppose I wanted to use the gateway itself as the web server? In other words, it’s not acting as a gateway, but the server endpoint in itself? Figure 2: Gateway as service endpoint. Here the gateway is providing valuable APIs on its own without necessarily routing a request to an internal host. It’s very simple to configure a SecureSpan Gateway as an endpoint. You simply create a policy that never routes a request onward to an internal host, but instead acts on the message content internally. I sometimes think of it as an internal loop back mechanism. I’ll build a policy implementing my web site, and add the assertion Return Template Response to Requester. I will bind this policy to the gateway URL http://localhost:8080/helloworld as shown in the screen snippet below from the SecureSpan management console: With just one assertion, this is pretty much the simplest policy you can write, and so fitting for the time-honoured Hello World example. Let’s expand the assertion to examine at what the template actually contains: Pretty plain-vanilla HTML. The only departure I’ve made from the deliberate austerity of the Hello World tradition is to add a time stamp to showcase the use of predefined context variables. There are dozens of context variables that are automatically set as the gateway processes a transaction (regardless of whether it’s actually being a gateway or an endpoint—remember we consider this just a policy implementation pattern, not a different capability). Context variables cover everything from accessing individual fields in the X509 certificate used for client-side SSL authentication to storing the IP address of a request sender. And of course, you can set your own context variables at any time within a policy. Just to be complete, here’s what happens when I point my browser at the gateway-as-endpoint: Now, before you think I’ve gone mad, I am not advocating that you deploy a web site like this; there are much better tools for that purpose. But the point I’m making is that there are legitimate endpoint services that do indeed lend themselves to implementation on a gateway. These are just a little more complicated than what I’ve shown here, but nevertheless simple to implement using the declarative policy language in SecureSpan. For example:
  • Signing Services: In the notary pattern, a gateway with an on-board Hardware Security Module (HSM) responsible for protecting key material can easily provide authoritative signing services for all kinds of data, from XML documents to arbitrary text.
  • Encryption Services: Same idea as signing, with the goal to avoid insecure proliferation of keys.
  • Validation Services: Ensure data conforms to a particular schema.
  • Threat Detection Services: Scan content for SQL injection, Cross Site Scripting (XSS), XML threats, or custom threat signatures.
  • Security Token Services (STS): Issue security tokens like SAML or OAuth tokens. Validate or exchange tokens.
  • Centralized Session or Caching Management: Cache frequently used data items according to a scheme that is tuned to your application.
  • Policy Decision Point (PDP) Services: Receive and act on SAMLP requests.
  • XACML Services: Act as a centralized XACML engine providing authorization services.
The list above is by no means exclusive; however, at Layer 7 we’ve implemented all of these at one time or another using SecureSpan Gateways. It’s an important design point for us that the only real difference between a gateway and an endpoint is how you define your policy.
March 18th, 2011

RSA Hacked by Advanced Persistent Threat (APT)

Written by
Category Uncategorized
 

In the wake of the most highly coveted cyber security conference in the world - The RSA Conference, RSA has reported that they have been the victim to a highly sophisticated cyber attack. RSA, the world's leader in security products and solutions, utilized by countless customers worldwide to secure their business operations, stated in a open letter to customers that it had been infiltrated by a Advanced Persistent Threat (APT). Letter by Art Coviello, Executive Chairman.

APT's are highly skilled individuals who target the victim in various means in highly sophisticated mannerisms and have possible links to nation states. These actors attempt to gain access to the data inside the organization without being detected, presumably for the purpose of intelligence collection and potentially establishing a foothold within the network for destructive or deceptive operations.

The letter states that certain information was extracted from RSA's secure network and that some of the information was specifically related to RSA's SecurID two-factor authentication products. While the letter does state that RSA believes that the information extracted does not enable a successful direct attack on any RSA SecurID customers, the letter did not elaborate on the risk of information stolen which was not related to RSA's SecurID products.

SecurID is a two-factor authentication product allowing more robust authentication's through a requirement for something you know to be added to something you have. In this case your username and password is something you know, while the code provided on the display of your SecurID is something you have. With SecurID an attacker could obtain your username and password but still would not be able to gain access to the system as they would not have the rotating code displayed on the SecurID which is in your possession. If there was a way for the attacker to know the rotating code without having possession, it would pose a significant risk to the mission-critical data and applications that leverage SecurID.

RSA is confident that the information stolen alone does not enable a successful direct attack on any of their RSA SecurID customers. They do go on to state that this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. Reading between the lines, are they saying that this information makes SecurID ineffective without compromising username and password? If so, I think it's safe to assume that without the protection of SecurID, hundreds or thousands of companies and government agencies could be vulnerable to attack.

March 4th, 2011

Creating New NIEM Services with Policy Based Integration & Governance

Written by
Category NIEM
 

Problems with NIEM Enablement

There are several barriers to adoption of NIEM that must be dealt with. The first is that Data is currently represented in terms that the enterprise has defined and semantics likely differ between NIEM and the currently leveraged legacy data formats. Second, requirements for run-time security and governance of new NIEM-enabled services adds new complexities to which the current enterprise may not be accustomed to.

Database and Legacy Application Integration

Our philosophy is to allow for data integration through a logical model, which provides a necessary level of abstraction to achieve data decoupling and lifecycle management. A critical requirement of NIEM is to allow for integration and mediations between multiple back-end legacy data structures, and formats thus, it is critical that customers be provided the capability to import legacy data models, and file formats and translate them into the NIEM schema so they can carry out their information sharing needs.

Layer 7 Value: Layer 7 provides the capability to import models in standard formats, and enrich data integrations with rules, and mapping to produce NIEM-enabled services without writing a single line of code. With Layer 7, data integrations may be accomplished with a click of the mouse, and at run-time the Layer 7 appliance can transform and validate data before it is submitted to the connected legacy applications and services. The distributed deployment model improves performance and scalability relative to hub and spoke architectures. All data services use standard interfaces for incorporation into any business process or target application, and can be adapted to meet changing requirements over time.

NIEM Services Governance

NIEM as a framework is designed to fulfill the following four primary goals; to determine information sharing requirements, to develop standards, and vocabularies to meet these requirements, to provide technical tools to support development, discovery, dissemination and reuse, and to provide training, technical assistance, and implementation support.

Layer 7 Value: Through use of Layer 7’s policy governance products, run-time frameworks may be used between consumers and services to enforce and apply NIEM requirements in a highly configurable, centrally managed, and dynamically updatable fashion while still maintaining the desired ability to meet the goals of just-in-time integration, flexible system design by loose-coupling between software components and reuse of software components across diverse business processes. Examples of governance requirements met with Layer 7 include:

  • Threat Protection - While numerous cyber defense point solutions exist – crypto devices, firewalls, identity and access management systems that encompass biometrics, smart cards, audit software, etc. – they tend to be narrowly deployed and narrowly focused (i.e., by office, department or bureau), rather than integrated to form a government-wide or even a nation-wide security barrier. SOA and cloud security solutions, on the other hand, are designed to deal with the elimination of boundaries between systems and the ever-growing use of shared and common resources. As NIEM-based services are exposed outside of the enterprise it is critical that we look to not only traditional defense in depth concepts to enhance our security posture of these new services but further look to the new risks that we are exposing to our enterprise, and our legacy business systems. The Layer 7 product delivers inherent cyber defense capabilities to address common threats associated with SOA, Web Services, and Cloud implementations. It acts as a Policy Enforcement Point (PEP) which proxies and inspects every message destined for and/or returned from a Firewall-protected service, based on a user-defined set of policies. Policies can incorporate any combination of identity, authentication protocol, time of day, IP address, message count, message content or routing parameters. In addition, through Layer 7 robust audit and logging services can be created which audit usage and misusage of each NIEM service.
  • Access Control - With NIEM we require that newly created, and available services have access control applied, and reapplied as policies for access's change. In addition, supporting multiple credentials and authentication techniques is highly desired so that a single NIEM application can authenticate users from various agencies and authorize them using a common policy. The Layer 7 SecureSpan and CloudSpan product lines provide wide support for XACML, allowing it to be used directly within the appliance as an authorization policy language, or indirectly by supporting integration to third-party XACML-compliant enterprise products. Not only does this allow for high speed, XACML-based policy decision within the Layer 7 appliance for in-line authorizations as part of a PEP, but it additionally allows Layer 7 to be utilized as a central Policy Decision Point (PDP). If your agency doesn't have a externally available attribute service - Layer 7 can help. Layer 7 provides Attribute Service capabilities within its XML Gateway products, delivering support for X.509 Attribute Sharing Profile, as well as Homeland Security Presidential Directive (HSPD) – 12 Backend Attribute Exchange (BAE). Not only can Layer 7 provide support for building Attribute Services based on the leading standards, but it can also provide policy-based security for authentication, authorization, digital signing, and encryption to meet the highest security requirements for attribute dissemination.
  • Identity Federation - Sharing application data and functionality over the network to external divisions and partners requires trust between two applications in different identity domains. Establishing this trust in user-machine interactions is challenging, and harder still in machine-to-machine SOA and cloud environments. As NIEM aims to support federation across its user-base, this too is a requirement of the service governance layer and luckily is a capability that Layer 7 provides. Layer 7 is the only XML security vendor to offer enterprises a solution for managing Web services federation from client application to Web service without programming as well as a provide a built-in SAML based Secure Token Service. The Layer 7 Web service federation solution can integrate with leading identity management, federation and security token services. The Layer 7 SecureSpan XML Firewall and The SecureSpan XML Networking Gateway also provide customers a flexible SAML based Security Token Service (STS) appliance for consuming, validating, creating and transforming security tokens including Kerberos, SAML 1.1 and 2.0. Likewise the SecureSpan XML VPN Client provides a admin-configurable tool for establishing PKI based trust on a client application, managing token requests from an STS (3rd party of Layer 7), and packaging a token into a secure SOAP call. Layer 7’s SecureSpan XML VPN automatically manages token negotiation using standards like WS-Trust, WS-Federation, and packaging of SOAP calls on the client application using WS-Security and WS-I Basic Security Profile to name some standards. All this is accomplished with zero upfront code and no down-time for policy updates.
  • Monitoring - As SOA adoption has matured, new services have come online and been offered throughout the government enterprise, crossing organizational, network, and even classification boundaries. These newly formed IT Communities of Interest (IT COI) require a shared knowledge of their individual and collective purpose, mission objectives, service level agreements, security, etc., but also–critically–require a common interpretation of dependencies should one or more of the services go down. Today, services within one government organization are generally well constructed, secured and monitored to ensure availability. However, current monitoring solutions provide little to no service availability information for external members of an IT COI. As such, should a firewall go down at the boundary of a service provider’s domain, external entities may no longer be able to reach a service even though the service provider will still register it as being available. A new type of federated monitoring solution is required to solve this availability vs. “reach-ability” problem – one that monitors service characteristics not only within its own domain, but also from the service provider's network perimeter. Such a solution would allow external users to accurately measure a service’s availability, reach-ability and performance. A number of standards already exist for this purpose, including WS-Management and Web Services Distributed Management (WSDM) for metric collection, as well as WS-Notification or WS-Eventing which can be used for metric publishing/ subscription. In fact, the Department of Defense (DoD) and Intelligence Community (IC) have developed the Joint DoD/IC Enterprise Service Monitoring (JESM) specification, which is based on a subset of WSDM and WS-Eventing functionality.

Conclusion

Through Layer 7 Data and Services Governance, a common NIEM-supported data model may be created, and constantly managed through change management data lifecycle governance. In addition, Layer 7 incorporates a services governance layer onto the newly created data services to allow for NIEM-supportive Web Services to be provided securely across the enterprise, and with external partners.


March 2nd, 2011

Selecting a token format for your Web APIs, RESTful web services

Category Uncategorized
 

The most important token format that you need to support for your web apis and RESTful web services these days is: anything. So many platforms define their own authentication/authorization mechanism with what seems to be little concern for standardized formats: API keys here, HMAC signatures there, various OAuth interpretation, etc. Simple does trump standards. For the integration-focused enterprise architect, this reality creates a need for flexible infrastructure supporting arbitrary token formats.

About a year ago, I was proposing a simple approach for enabling RESTful web service requesters with SAML-based tokens for authentication/authorization. The pattern enabling a REST client to access a service using a SAML token is illustrated below.

SAML for REST

The fact that there are still no definitive SAML bindings targeting RESTful web services today does not seem to deter developers from leveraging SAML to control access to their RESTful web services. We encountered this again recently in the field in the form of a proof of technology project in which the main objective was to demonstrate the Layer 7 Gateway acting both as the token issuer for a REST client as well as an API proxy which controls access based on those very tokens. Two token formats were requested: SAML and OAuth.

For our gateway to authenticate RESTful requesters and issue tokens is a very common and straightforward process. In order for the REST client to be able to use this token however, it must be able to insert it in an Authorization header (the RESTful location for this token). In the case where the token is a SAML assertion, it can exceed in size the practical limit of what can be used as an HTTP header value (a rich SAML assertion with an XML digital signature can be quite verbose). This is where the Layer 7 Gateway policy language flexibility shines. By simply declaring the compression (gzip assertion) of the resulting SAML before sending it back to the client, the token has now been shrunk to a manageable size for the client. The reverse decompression at reception is just as straightforward using the reverse operation in our policy language.

SAML idp for REST with token compression

Note that although we could just as well create a session on the Gateway and return a cookie back to the requester, we are interacting with a REST client here; this is not a browser-driven interaction. Besides, server side sessions are not RESTful. If the client re-sends the token at each call, the authorization of the requester is validated each time through the evaluation of the SAML statements and this does not require any server-side session.

When implementing the same use case, but with a token format based on OAuth instead of SAML, this compression/decompression step is no longer needed. The rest of the configuration using our Gateway policy language is very similar. This compression is one of the technical tradeoffs when choosing between such token formats and relates to the so-called “open” vs “enterprise” identity camps. On one hand, you have a rich and standardized token format (SAML), which can be used to express a variety of statements about an identity. On the other hand you have a simple and lean token format but less standardized. On that last point, what constitutes an OAuth token format in this particular context is a bit of a moving target and various interpretations are not necessarily compatible.

In the end, choosing a token format should consider the requirements around authorization and the technical capabilites of the parties involved. Better yet, don’t narrow your support on a single format. Support and enable different token formats instead if that is what is needed.

When selecting supporting infrastructure to manage APIs and broker with cloud or partners, keep in mind this need to accommodate arbitrary authentication approaches. Although rich standard support provides value, the essential ingredient of an agile service gateway is its flexibility and its extensibility.