Docstoc

Layer 7 Robust Netcentric Servies

Document Sample
Layer 7 Robust Netcentric Servies Powered By Docstoc
					Robust Net-Centric Services
Information Sharing to the Edge




                                  Layer 7 Technologies

                  White Paper
Robust Net-Centric Services


Contents

Executive Summary....................................................................................................................................... 3
Overview ....................................................................................................................................................... 3
Net-Centric Services at the Tactical Edge ..................................................................................................... 3
   Challenges at the Edge .............................................................................................................................. 4
       Availability and Robustness of the Network ......................................................................................... 4

       Availability of Resources ....................................................................................................................... 5

       Information Assurance (IA) ................................................................................................................... 5

   Robust Net-Centric Services ..................................................................................................................... 6
       The Policy Layer .................................................................................................................................... 6

       Web Services Policy Framework ........................................................................................................... 8

Conclusions ................................................................................................................................................... 9
About Layer 7 Technologies ........................................................................................................................ 10
   Contact Layer 7 Technologies ................................................................................................................. 10
   Legal Information .................................................................................................................................... 10




© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com)                                                                                             2
  Robust Net-Centric Services



  Executive Summary
  The “net-centric vision” is based on a consistent architecture that enables information sharing and component re-
  use across an organization. In pursuit of this vision, The Department of Defense (DoD) has adopted a Service
  Oriented Architecture (SOA) model, which encompasses Extensible Markup Language (XML) and Web services
  standards and technologies.
  SOAP and REST-based Web Services adequately address how applications get exposed and communicate with each
  other in order to exchange information in a platform agnostic way. In real-world applications however, security,
  reliability, routing, bandwidth conservation, versioning and other requirements still have to be dealt with. At the
  tactical edge, Web services are even more susceptible to these factors, having to operate in an environment where
  (for example) bandwidth and connection state are constantly changing. Only Web services that have situational
  awareness will be able to adapt to constantly changing conditions.
                                For example, an edge-based Web service consumer or provider that is initially
Only Web services
                                connected to DISA’s Net-Centric Enterprise Services (NCES) can become disconnected
that have situational           due to a kinetic or cyber attack. With situational awareness, information exchange can
awareness will be               continue to flow by redirecting traffic to locally deployed core enterprise services
able to adapt to                (machine to machine messaging), and/or potentially a cached business service – all
constantly changing             without impacting the tactical user.
conditions                  This whitepaper proposes the concept of “Robust Net-Centric Services,” which is
                            defined as Web services that have a high degree of continuity despite multiple internal
  application changes and/or external environmental disruptions.
  Given the distributed and federated nature of net-centric services, the ability to define robust contingencies in
  policy – policies that can be implemented in a distributed fashion; interoperate across implementations; and yet
  still remain easy to change – is key to achieving information superiority.


  Overview
  The IEEE publication entitled “Characterization Framework and Design Patterns for the Disadvantaged User,”
  recognized Fixed Center, Mobile Center, Mobile Swarm, and Dismounted as being the most typical tactical
  environments. The publication went on to establish a number of dimensions and attributes for each tactical
  environment, including:
      •    The availability and robustness of a network
      •    The availability of resources to execute a particular function
      •    Information Assurance (IA)
  This paper examines current deficiencies in net-centric enablement at the tactical edge related to the above
  dimensions, and proposes that more “robust” services are required for successful net-centric enablement.
  A robust net-centric service is capable of assessing its own particular situation, and taking intelligent action based
  on its own situational awareness without impacting the consumer or provider of the application themselves.
  Action can be taken based on network conditions, availability of resources, security related factors, and even on
  the current situation of the user.
  The following sections define net-centric services at the tactical edge; draw attention to the inherent challenges;
  and propose a policy-oriented approach to decoupling tactical awareness from applications.


  Net-Centric Services at the Tactical Edge
  Standards and technologies (i.e. XML, SOAP, REST, AJAX, WSDL and UDDI) provide developers and architects with
  the tools to implement and deploy net-centric services, which often incorporate other existing services (both
  business and infrastructure) to accomplish their particular goals.



  © Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com)                                                      3
   Robust Net-Centric Services

   In order to support the principles of flexibility and loose coupling of system components, net-centric enablement
   utilizes basic software engineering principles: flexible systems are achieved by decoupling the variable parts of the
   implementation from the invariant parts. The variable layer can then be managed without affecting the system
   invariants. This is evident in the government’s adoption of SOA, and their use of supporting technologies, such as
   Enterprise Service Buses, Business Activity Monitoring, Complex Event Processing, Policy Enforcement and Decision
   Solutions, XML Firewalls, Business Process Management, as well as others.
   For net-centric services, the invariant part of an implementation is the business functionality, such as a Global
   Combat Support System (GCSS) logistics system query, or a Blue Force Tracking: Situational Awareness (BFTSA)
   track request, or a Human Resources personnel request. Everything else, including credential mechanisms, access
   control, whether encryption or signatures are used, caching, data format transformations, versioning, routing, etc,
   is the variable part of the implementation, and resides in a layer that is declarative, configurable and centrally
   managed.
   On the Global Information Grid (GIG), service infrastructure is available from DISA NCES, providing an opportunity
   for cost savings and reduced time to market through use of services like Machine-to-Machine messaging,
   Orchestration, Collaboration, Mediation, Discovery, Enterprise Service Management, etc. In addition, each of the
   service branches (Army, Navy, Air Force, and Marine Corp) provide their own core enterprise services to be utilized
   in building composite net-centric systems. All of these initiatives are founded on the premise that programs of
   record should care first and foremost about the business capability they are looking to provide and not on the
   infrastructure necessary to support the requirements of net-centricity, thereby reducing total cost of ownership
   for the program.
   At the tactical edge, robustness can be achieved by adopting standards to maintain interoperability; creating core
   services for use and reuse; and by leveraging commercial off the shelf technologies in order to reduce the overall
   cost of the project. In this way, tactical system deployment can be accelerated, while ensuring changes can be
   made to the system as required.

   Challenges at the Edge
   Within the enterprise, it’s possible to create failover strategies, acquire more hardware/software, create custom
   code, or even implement human-driven processes to address new challenges. Infrastructure components like DNS,
   enterprise services and even the physical network itself can be relied upon and as such, applications can leverage
   these resources in order to meet Service Level Agreement (SLA) and Quality of Service (QoS) requirements. At the
   tactical edge, however, fewer resources are available; custom development is not possible in a timely fashion;
   networks are not stable; and enterprise infrastructure services are not always available.

   Availability and Robustness of the Network
   The network is the leading factor limiting net-centric operations at the edge. Part of the problem is due to the fact
   that the foundational element of net-centricity is XML, which is the de-facto way to disseminate and store data in a
                            SOA. While it’s true that radios and tactically deployed communication infrastructure are
The network is the          improving, and that compression algorithms and binary XML efficiency are allowing
leading factor              payloads to become smaller on the wire, XML message size still creates bandwidth issues
limiting net-centric        for communications between mobile swarm and dismounted users.
operations at the             For enterprise to swarm, swarm-to-swarm, or other tactical communications, network
tactical edge                 availability and robustness remain challenging, and often result in applications being built
                              with the worst-case scenario in mind. This equates to a static SLA driven by the worst
   network conditions the application may face short of being disconnected. As a result, developers, architects, and
   program managers typically end up using this minimum SLA to determine how much functionality their service will
   provide. Although this is the safest bet for the service owner (as the service will work extremely well if conditions
   are better than the minimum), the service will not be able to take advantage of more bandwidth when it is
   available.
   For example, consider identical services (providing the same data) deployed at two different Mobile Command
   Centers (MCC) designated MCC1 and MCC2. MCC1 is experiencing heat-related issues with its server, and thus is



   © Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com)                                                   4
    Robust Net-Centric Services

    only able to accept 10 requests/second, while MCC2 is effectively processing 200 requests/second. Under
    degraded network conditions, you would most likely use the MCC closest to your current position (MCC1).
    However, in cases where network conditions are optimal you may determine that your application should
    communicate with MCC2, which, while further away, is providing a more appropriate response time.
    This type of situational awareness and control is the primary motivation in proposing robust net-centric services. A
    robust net-centric service is aware of its particular network’s health, as well as the health of all interrelated
    networks, allowing it to determine which service it should use.
    Consider another example in which MCC2 processes a request from a caller that requires information from a
    tracking service available at the enterprise. In an ideal world, an enterprise-based tracking service should always
    be available to MCC2, but if the network becomes disconnected or the tracking service is inoperable, a robust net-
    centric service would be capable of determining an alternate route to a backup tracking service (perhaps one
    deployed locally, or one that serves cached responses previously stored from the actual enterprise service).

   Availability of Resources
   The availability of resources is a critical component of any net-centric edge system. According to best practices,
   reliance on external resources is to be avoided during tactical system design because consistent response times
   are desired, whereas external resource availability cannot be guaranteed. Although this is a valid risk mitigation
                                  approach, it results in increased cost because net-centric infrastructure services must
Robust net-centric                be redeployed at the tactical edge rather than leveraging the existing investment at
services can leverage             the enterprise.
enterprise services
                                   What’s required is a hybrid approach whereby robust net-centric services leverage
when they are                      enterprise services when they are available, and take advantage of a fallback position
available, and take                when they are not. This is especially true for programs of record, which are
advantage of a                     increasingly adopting the use of DISA NCES as a necessary component of their
fallback position                  architecture. Today, DISA NCES primarily leverages verbose XML standards such as
                                   SOAP, WS-Security, etc., and is only available at the GIG enterprise, making NCES
when they are not
                                   incompatible with the majority of edge-based applications.
    As an example, consider the ability to publish or subscribe to the DISA NCES SOA Foundation (SOAF) Machine to
    Machine Messaging Service. Here, the onus is on the application developer to manage all aspects of publishing
    messages to the messaging service. Within the enterprise, where network conditions are consistent, publishing is
    not an issue. But in a tactical environment, the developer must account for various network situations and
    challenges associated with their disadvantaged state. A robust net-centric service would remove network
    connectivity and bandwidth related concerns, allowing developers to focus on their business requirements.

   Information Assurance (IA)
   At the tactical edge, security is a critical requirement; one that severely limits the ability to create a loosely
   coupled system. A robust net-centric system would have appropriate security controls, while still maintaining the
                                  ability to adjust to changing network, resource, IA, and user challenges. This is not the
Today, security is                case today, where a “one size fits all” approach to security is the norm. Despite the
hard coded into                   fact that it is difficult to imagine all IA conditions that a tactical net-centric system may
                                  be faced with once deployed, security is hard-coded into applications, and cannot
applications in a “one            easily be changed.
size fits all” approach
                                  Because effective security is dependent upon resources like Robust Certificate
despite the fact that
                                  Validation (RCV), Attribute Services, Policy Decision Services, etc., and edge-based
IA conditions can                 applications cannot depend on these resources being available, effective security
change once a system              cannot be maintained. A robust net-centric system is one which provides for real-time
has been deployed                 changes to be made to the security requirements of the system. For example, a robust
                                  service might adjust to a network latency issue by falling back to using only transport
    encryption instead of its previous security configuration which required both transport encryption and message
    level encryption.



    © Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com)                                                      5
    Robust Net-Centric Services

    Tactical systems should be built to leverage existing enterprise security infrastructure, such as DoD RCVS, Attribute
    Services like JEDS, and Policy Decision Services whenever possible. When these enterprise security services are not
    available at the tactical edge, robust net-centric systems would have the ability to determine at run-time what
    their fall-back condition should be: either to not use the service, or else to use locally deployed resources without
    impacting the service providers and consumers.

    Robust Net-Centric Services
  In a tactical environment, multiple, conflicting constraints and capabilities need to be reconciled, managed and
  constantly monitored. For example, performance and response time requirements need to be weighed against
  security, confidentiality and privacy requirements. For this reason, robust net-centric services must adhere to the
  fundamental principles of software engineering: flexible systems are achieved by decoupling the variable parts of
                                the implementation from the invariant parts. The variable layer can then be managed
Robust net-centric              without affecting the system invariants.
services employ a
                                  Robust net-centric services employ a policy-driven, intelligent infrastructure that
policy-driven
                                  allows applications to be deployed without knowledge of the requirements they
approach that allows              might face. The infrastructure provides a light-weight, federated on-ramp to the GIG’s
them to be deployed               enterprise services, while policy facilitates connectivity and integration.
without knowledge of               For example, once a troop tracking service is implemented by developers, the policy
the requirements they              framework should allow it to be deployed on a variety of servers; under different
might face                         transports/messaging capabilities; with different access control and credentialing
                                   mechanism; and varying levels of security and availability – all without impacting the
    business application itself. And because the configurability around how consumers and services interact is now
    controlled by the runtime policy framework, Certification and Accreditation (C&A) is simplified.
    Finally, consider messaging, which is one of the key resources net-centric system builders employ, and is therefore
    also a key issue for tactical deployments where messaging services may not always be available. The policy
    framework of a robust net-centric service provides for situational awareness of the availability of messaging
    services. Thus, when one messaging service is unavailable, applications can, in a policy-driven fashion, find the best
    method to forward on messages using alternate messaging systems.

    The Policy Layer
    The policy layer describes how, when and where Web services are to be shared, applied, and enforced. This layer
    architecturally is made up of two fundamental concepts: a Policy Enforcement Point (PEP) and a Policy Application
    Point (PAP).




    © Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com)                                                     6
  Robust Net-Centric Services

                                            Figure 1: Policy Enforcement Point

  The PEP has been a well known and accepted concept in the IT community well before the advent of SOA,
  providing a centralized point of control (i.e., traditional firewalls). When applied to SOA, PEPs allow organizations
  to decouple the runtime policy framework from the business application logic, and manage it more easily.
  Operators can create and modify policies on the PEP to provide access control; enforce privacy and confidentiality;
  perform audit logging, and so on independent of the services themselves. This is the first step towards real-world
  implementation of loosely coupled SOA.

A client-side PAP                 But the same real-world policy issues that apply to providers also apply to
                                  consumers. In other words, consumers still have to deal with providing credentials,
intercepts requests and           confidentiality, privacy and other non-business logic-related information, which
applies policy to                 should be implemented as part of the same loosely coupled policy framework.
ensure requests                   Otherwise, policy conformance and security negotiation will have to be written into
conform to service                the client-side code base, which will have to be updated when policy changes. A
provider requirements             client-side equivalent to the PEP, commonly called a PAP or Policy Application
                                  Point, can eliminate these drawbacks. A PAP intercepts outgoing requests and
  applies policy to them. These requests are then intercepted by the PEP, which enforces existing, appropriate
  policy.




                                             Figure 2: Policy Application Point

                                 To better understand the role of a PAP, think of a Virtual Private Network (VPN)
PEPs intercept                   security solution. When a VPN is deployed server-side, a VPN client is always
requests and apply               deployed on the client-side machine in order to ensure applications like email clients
policy against them to           and Web browsers don’t have to implement security and policy in their code base. In
                                 this way, VPN clients provide security for any and all applications, no matter whether
ensure they conform
                                 they’re located inside or outside the organization’s LAN and firewall.
to predefined
requirements                     In much the same way, PEPs and PAPs allow applications to share information
                                 independent of location and project-specific requirements.




  © Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com)                                                 7
Robust Net-Centric Services




                    Figure 3: Policy Enforcement and Application across the War Fighting Domain

Web Services Policy Framework
The Web Services Policy (WS-Policy) Framework allows service providers to express the capabilities, requirements,
and characteristics of their Web Services in a machine executable policy vocabulary. WS-Policy contains a number
of WS* standard assertions, but custom assertions can be added to address unique requirements.
WS-Policy generally includes the following expressions:
    •    All: Must adhere to all of the required operations
    •    Exactly One: Must adhere to one and only one of the required operations

 This level of flexibility allows granular policies to be written that specify how service consumers must interact with
service providers based on unique situational factors. Logic operations can be used to place requirements on
service consumers to provide their organizational attributes, roles, and/or situational status.
An example “Security/QoS/SLA” policy could be written as follows:
    •    Do Threat Protection (Virus Detection, Denial of Service, Code Injection)
    •    Authenticate Entity Based on WS-Security (X.509 and Attribute Retrieval)

              o    [Exactly One ]
                             [All]
                                      Attribute: Location=IRAQ
                                      Require Transport Encryption: SSL/TLS
                                      Require Digital Signature: Message (Entire)
                                      Require XML Encryption: Message (Portion)



© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com)                                                   8
Robust Net-Centric Services

                                      Require Message Sanitization (Sensitive Portion Removed)
                                      Enforce Service Level Agreement (10 Requests/Hour/Requester)
                              [All]
                                      Attribute: Location=CONUS
                                      Require SSL/TLS
                                      Require Schema Validation: Entire Message
                              [All]
                                      Attribute: Location=ANY OTHER
                                      Issue Audit Record and Notify Operations of Unexpected Location

Another example where “situation based routing” is performed based on bandwidth could be written as follows:
              o    [Exactly One ]
                             [All]
                                      Bandwidth: [Average roundtrip time for last 10 transactions] >=1MB/Sec
                                      Use HTTP (No Compression)
                              [All]

                                      Bandwidth: [Average roundtrip time for last 10 transactions] >256KB/Sec and <1MB/Sec
                                      Use Efficient XML (EFX) Compression
                              [All]
                                      Bandwidth: [Average roundtrip time for last 10 transactions] <=256KB/Sec
                                      Require Message Transformation (Attachment Removed)
                                      Use Efficient XML (EFX) Compression

These are simple examples of the types of policies that can be created using WS-Policy. However, they serve to
show how requirements can be bound into a single policy that can subsequently be shared in a machine
consumable fashion.


Conclusions
Given a policy framework and SOA infrastructure services, robust net-centric systems can be deployed out to the
tactical edge. The PEP/PAP model outlined in this paper allows requirements to be enforced and applied in a highly
configurable, centrally managed, and dynamically updatable fashion, while still meeting the goals of just-in-time
integration, flexible system design (via loose-coupling), and reuse of software components across diverse business
processes.
The suite of policy enforcement and application point products available from Layer 7 Technologies is a direct
response to the set of problems acknowledged in this document. Layer 7 also provides guidance to organizations
through onsite professional services engagements and best practices discussions around building a robust policy
layer between service consumers and service providers.




© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com)                                                      9
Robust Net-Centric Services



About Layer 7 Technologies
With more than 150 customers across 6 continents, and successful partnerships with some of the largest ISVs and
resellers in the industry, Layer 7 Technologies is the leader in SOA and cloud security and governance. Our award-
winning SecureSpan™ family of XML Gateways feature sophisticated runtime governance, enterprise-scale
management and industry-leading XML security. Our CloudSpan™ family enables enterprises and service providers
to securely consume cloud services, as well as protect and control their own applications deployed in public and
private clouds. Founded in 2002, Layer 7 has a history of helping organizations address their security, visibility and
governance issues by enabling them to control, manage and adapt their Web services, no matter the deployment
model – in the enterprise or in the cloud.

Contact Layer 7 Technologies
Layer 7 Technologies welcomes your questions, comments, and general feedback.

Email:
info@layer7tech.com

Web Site:
www.layer7tech.com

Phone:
(+1) 604-681-9377
1-800-681-9377 (toll free within North America)

Fax:
604-681-9387

Address:
Layer 7 Technologies
1200 G Street, NW, Suite 800
Washington, DC 20005

Layer 7 Technologies
Suite 405-1100 Melville Street
Vancouver, BC
V6E 4A6 Canada

Legal Information
Copyright © 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com). Contents confidential. All rights reserved.
SecureSpan™ is a registered trademark of Layer 7 Technologies, Inc. All other mentioned trade names and/or
trademarks are the property of their respective owners.




© Copyright 2010 by Layer 7 Technologies, Inc. (www.layer7tech.com)                                                 10

				
DOCUMENT INFO
Shared By:
Stats:
views:66
posted:1/12/2011
language:English
pages:10
Description: The “net-centric vision” is based on a consistent architecture that enables information sharing and component reuse across an organization. SOAP and REST-based Web Services adequately address how applications get exposed and communicate with each other in a platform agnostic way. In real-world applications however, security, reliability, routing, bandwidth conservation, versioning and other requirements still have to be dealt with. At the tactical edge, Web services are even more susceptible to these factors, having to operate in an environment where (for example) bandwidth and connection state are constantly changing. Only Web services that have situational awareness will be able to adapt to constantly changing conditions.