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 identify potential threats with increased speed, timeliness, and accuracy 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 Derived from the overview of CMA slide

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. It is important to understand that OLS in this system is not used to protect data from different security levels (e.g., Top secret, secret, unclassified). Rather, it is used to protect data from various organizations (e.g., Coast Guard, DoD) within the same security level.

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