|By Adam Vincent||
|March 4, 2011 02:05 PM EST||
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.
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.