NRL Security Architecture:A Web Services-Based

Solution

Anya KimNaval Research Lab

Washington D.C.kim@itd.nrl.navy.mil

NRL Security Architecture

– Initially developed to support a DoD project

WSnode

WSnode

WSnode

NRL Security Architecture

• Security Requirements– Information sharing

• While each node is autonomous, some information may need to be shared with coalition partners, law enforcement community, etc

• Uses complex sharing rules based on MOA, coalition participation, location, roles, etc

– Autonomy and survivability• Each node should be able to function (even in degraded mode)

independent of other nodes– Secure data management

• Data is coming from various sources and security levels– Label data based on sources, classification (e.g., levels of trust)– Enforce access control based on data labels and requestor credentials

NRL Security Architecture

• Architecture Features– Uses web services– Multiple instances of autonomous web service

nodes deployed within a service oriented architecture (SOA) infrastructure• Each organization maintains its own users• Each organization determines and maintains its own

web service access policy• Cross organizational access policies will be based on

pre-written agreements (MOU, MOA, etc)

NRL Security Architecture

• Security Features– Oracle Label Security– Federated A&A Model• Authentication• Authorization

– Network security *• All data in transit is transmitted across the network in

encrypted mode

Oracle Label Security

• Two aspects of data protection: access mediation to data and data separation– Oracle Label Security (OLS) provides mechanisms

for data protection via access mediation and has Common Criteria (CC) Evaluation Assurance Level (EAL) 4.

– By using correctly created data labels we can enforce policies by allowing us to label the data source.

Oracle Label Security (cont.)

• Use OLS to separate and label data from various organizations and implement label security policy that satisfies data owners’ rules and regulations – Regular user application is label unaware, and all data

separation and access mediation is performed by the OLS that implements the project’s overall label security policy

– User applications (i.e., Web services) do not mediate access to data. They pass user information to Oracle and OLS returns data that the user is allowed to read

Federated A&A

• Based on a service-oriented architecture– Users access the data via a series of web services– The web apps require the user to authenticate himself

before gaining access to the web pages. Additionally, the user’s attributes, such as role and organization are included to provide input to access control decisions

• Based on OASIS Security Assertion Markup Language (SAML) 2.0, and Access Control Markup Language (XACML)2.0

• Peer-to-peer trust relationships rather than multilateral- Provides better flexibility

Federated A&A (cont.)

• SSO/SLO (Single Sign-on, Single Logout)– Users need only to authenticate locally, hence

required to only know one username/password combo

– Reduces password associated risks• Ease of management

- Enables each organization to use pre-existing authentication mechanisms independent of others

- Allows organizations to create authorization policies according to their own policies

- Simplifies user management in a dynamic environment

NRL Security ArchitectureInformation Flow

Conclusion

• NRL Security Architecture– Uses commercial standards– Enables independent nodes to run in degraded

mode if necessary (survivability)– Provides strong authentication and authorization,

while preserving unique security and data sharing requirements of entities

– Is applicable to other areas where security, information sharing (e.g., need-to-know) and survivability are issues