federaldodcasestudyround04

Secure Discovery (SD)

One of the premier security products developed by InfoTech is Secure Discovery. Successfully developed over a four year period (2007-2011), the security and compliance product for SPAWAR and the U.S. Navy, garnered a grade of “exceptional” by the U.S. Navy.

Secure Discovery is a security layer built on top of UDDI (Universal Description Discovery and Integration) specification for services discovery that augments the security model to be compatible with the Intelligence Community SOA Security Reference Architecture, maintains the interface and behavior specifications of UDDI standard and it is an industry standards-based solution.

Secure Discovery is a customized solution to answer the lack of a strong and robust services discovery capability compliant with the security model recommended for all services by the intelligence community (i.e. Intelligence Community SOA Security Reference Architecture) that follow the guidelines of NCES, DON, CANES and other directives. For example, the available industry standard for services description and discovery (UDDI) lacked the required strong and robust security model.

For several years, the Navy unsuccessfully attempted to integrate widely disparate services into a global Service Oriented Architecture (SOA) environment to promote discoverability, reusability, interoperability and security. The Navy needed to implement a secure services registry, one of the main building blocks of any SOA ecosystem. InfoTech was approached by SPAWAR to design and develop this capability. The goal was to build Secure Discovery into a strong and robust security layer that wraps around the UDDI specification, does not alter the UDDI standard interface and behavior specifications, conforms to the SOA Security Reference Architecture and maintains an industry standards-based architecture.

secureDiscoveryDiagram

federaldodsecondlevelmenu06

Secure Discovery characteristics: Technical Profile

metcastbenefit03

The security layer is built on the Attribute Based Access Control (ABAC) model characterized by

Requestors are described by attributes
e.g. name / rank / organization / clearance
Resources are described by attributes
e.g. distribution / mission
External environment is described by attributes
e.g. time / location / threat level
Access to resources is computed based on predefined rules (policies)
Incorporating the attributes of the requestors, resources and environment
sdtechnology02

The security layer is two tiered

Coarse Tier
Enforces access control at interface operations level
Fine Tier
Enforces access control at data level
sdtechnology03

Secure Discovery is accessible via an industry standard based SOA interface

This makes SD easy to integrate in existing / future standards based systems / architectures
e.g. CANES, C2RPC, ISR-Lite Mini-Cloud Afloat
Supported industry standards
e.g. SOAP 1.1, SAML 2.0, XACML 2.0, DoD PKI (CAC), UDDI v.3.0.2

federaldodsecondlevelmenu04

Example Use Case

A software developer searches the repository for descriptions of services that provide “weapons inventory information.” In general, service descriptions are constantly added and removed from the repository.

Without Secure Discovery, the developer is able to discover all service descriptions that match the query. By repeating the queries over a period of time the developer can perform registry “traffic analysis” and infer information that he/she may not be allowed to know, only by looking at what services are brought up and/or removed from the registry, even without having access to the actual service(s).

For example, the developer may notice that a new edge service description is available that provides weapons inventory information for a specific geographic region. Using this information only, the developer can infer that a mission may currently be ongoing in that geographic region.

This represents a form of insider threat:

SDuddiDiagram02

With Secure Discovery, the developer will not be able to discover such service descriptions (even if they exist) unless there is a “prescribed need” (e.g. the THREATCON level is elevated). The “prescribed need” is dictated by predefined sets of rules that consider the attributes of the requestor, the resource and the external environment.

SDuddiDiagram01

sdmenu04

Next Generation Services Discovery

The research and design work on building Secure Discovery allowed InfoTech to gain tremendous insight and expertise in the service discovery and service discovery security domains. Using this experience, we are building the next generation service discovery framework called Dynamic Service Discovery and Binding Framework to achieve loose coupling of consuming applications to services, through run-time service discovery and binding.

The major goal of the framework is to free application developers from the burden of creating ad-hoc discovery and binding solutions, by moving these processes into a flexible and generalized local dynamic discovery and binding layer. This layer acts as an internal proxy to consumer service requests, transparently discovering service implementations from a standard UDDI service registry and dynamically configuring bindings based on discovered service description artifacts and locally configured security credentials.

To improve the robustness and availability of service consuming applications, the framework has the capability to rebind service implementations as changes to service descriptions are detected or inferred. The framework utilizes DNS-Based Service Discovery to discover and bind to the service registry itself, further simplifying configuration and deployment of service consuming applications.

InfoTech Solutions for Business

Comments are closed.

contactus01

Apply For A Position

Your Name

Your Resume

Email Address

Your Phone

Currently Employed?

Currently EmployedNot Employed

Company Name (Current/Prior)

Your LinkedIn URL

Your GitHub URL

Your Website

Other URL

Subject

Message

[recaptcha your-recaptcha]

×