NRL Security Architecture:

abdomendebonairSecurity

Nov 2, 2013 (3 years and 7 months ago)

90 views

NRL Security Architecture:

A Web Services
-
Based

Solution

?Anya Kim

Naval Research Lab

Washington D.C.

kim@itd.nrl.navy.mil

NRL Security Architecture


Initially developed to support a DoD project

WS

node

WS

node

WS

node

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 Architecture

Information 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