Mike DavisMichael.h.davis@navy.mil858-537-8778

Information Assurance (IA) for Service-Oriented Architecture (SOA)

August 2008Offered for Discussion and Consideration

by SPAWAR 5.1.8IA Technical Authority

For (list audience)

IA and C&A for SOA

A General Overview

Bottom Line Up Front• Strategy – follow DISA / NSA lead

– Notional, high-level guidance exists, NCES, et al, but no implementation level details – especially for the “last mile” - no clear enterprise governance

• SOA (and overall OA in general) approaches add governance and communications complexities within DOD / DON / Navy

• No enterprise federal, coalition, first-provider implementation• IAW SysEngr principles, SOA must follow an EA & standards• Few top down C&A plan exists (this MUST be our DOD end-state)

• Navy Plans: Develop enterprise IA strategy / CONOPS / Requirements– USN Bounding the C&A problem (90% autonomous; “service” is one-way)– PEO C4I / PMW 160 leading Multi-Service SOA consortium– Other SOA coordination efforts (NGEN / CANES sync, ONR/NRL tests, etc)– Taking a Federation strategy (for example use/configuration of SAML)– NESI IA&A pilot supporting the JFCOM (joint) security management pilot

Collectively “most” answers / approaches are there, but not structured

Security and SOASO what’s still potentially missing?

• SOA (& web services overall), is generally thought of as service producer-to-consumer, not system-to-user. But security has to be user-focused AND data centric as well, for example:– What metadata is discoverable? what is the schema for crypto-binding data– Data aggregation, dynamic “re”classification authority, overall data schema

• The ROI for SOA is based on applications, NOT security– Unclear measures/metrics/SLAs wrt data-based assessments & decisions

• Security must be institutionalized enterprise-wide — beyond single applications – e.g., enforcing an EA and select “specified” standards– Which versions and extensions? We must agree or “global” SOA can’t work!

• Fine grained “IA” (C-I-A) access control – supporting the “need to share”– IA&A beyond the first application; supporting automation and “NPEs”– Current “JEDS” 13+2 attributes not adequate for specific services / NPE use..– Will PKI scale to what is needed – IS it even needed? What is plan “B” – IBE?

• An enterprise-wide policy statement, schema and enforcement needed– No federally proposed schema socialized, let alone implemented digitally

• Residual major design items to consider, accommodate– Re: Trust federation, loosely coupled Identity Management (IdM), Autonomy central

to Navy SOA strategy, PKI-centricity, etc…

SOA IA Questions to clarify

• E2E access control implementations can create security risks

• Enterprise E2E IA/security strategy still needed – many options• IA Security SLAs / E2E audit processes - weak / unclear• “Standard” Standards needed (and versions and extensions, options therein)

• IV&V / operational security T&E processes unclear – new NNWC C&A Process pushes “ST&E” to user environment

• Unclear E2E security CONOPS and IA requirements traceability

• IA / security / IA&A taxonomy, lexicon, definitions differences• No recognized state, local, allied, and coalition PKI / token

• Numerous “common” implementation resolutions/details neededThere are some plans to address most, but nothing found enterprise wide

SOA IA Questions to clarify• Verbose protocols problematic wrt IA overhead at the tactical edge

• Digital policy standardization, collaboration and implementation is an immature capability DoD wide, which affects the ability of PDPs in mixed domains

• GIG designs are going to require a different approach to difficult last mile bandwidth constraints. This creates asymmetric IA patterns and integration patterns which can create significant emergent behavior issues.

• C&A for Programs should be developed in parallel to the system functions as it will be a complex, coordination and governance task

• IA validation testing is impacted by the maturity of STIGs for web services/SOA where testing is already complex – and now must include inheritance aspects!

• Scalability can also be an issue with disadvantaged low bandwidth environments and the increase in numbers of users / NPE.

There are some plans to address most, but nothing found enterprise wide

Information “Protections” Overview

IA

CMI/KMI CND

Policy Training

C&A

Typical Acquisition part

Enterprise Risk Mgmt.P = Hard IA Product

P

P

P

P

PP

P

P P

Pp

p

p

p

p

p

p

p

p = Soft IA Product

IA Services

CA Support

Multiple playersMultiple PEs/LinesMultiple threatsMultiple PMW/S/As

“IO” and

CNODefendAttackExploit

Requirements

Strategy AND Governance critical to “implementation” success!

CIOFISMA

OperationsIAMs PKI/CAC

ID Mgmt

(or why “IA” is so complex / hard… because it’s way more than that!)

(yes, and PIT too)

7

An “Overall” Enterprise Picture(what are the minimal elements, who “owns” them, & how do they get integrated?)

IA/Security strategy must consider much more than “just” SOA

There is more to the enterprise IA/C&A picture than “just” CCE, SOA and Apps, which are hard enough to integrate

CCE

SOA/ESB/Services

Dynamic Access Control

Data privacy protection and Auditable anonymity

Data strategy / ownership

Hardware / Software Assurance

Business processes

ITIL/ITSM execution

Apps & COIs

GIG IA Protection Strategy Evolution

• Manual Review to Release Information Classified at Less than Sys-high

• Manual Analysis and Procedures determine allowed interconnects

• Information “authority” determines required level of protection (QoP) for the most sensitive information in the sys-high environment – high water mark determines IT/IA/“Comms” Standards for all information

• Privilege gained by access to environment and rudimentary roles

• Common User Trust Level (Clearances) across sys-high environment

• Automated mechanisms allow information to be Shared (“Released”) when users/devices have proper privilege and Transaction can meet QoP requirements

• Information “authority” determines required level of end-to-end protection (QoP) required to access information – translates to a set of IT/IA/“Comms” Standard that must be met for the Transaction to occur

• Privilege assigned to user/device based on operational role and can be changed

• User Trust Level sufficient across Transaction/COI – varies for enterprise

Static “Perimeter” Protection Model

Common level of Information Protection provided by System

High Environment

Transactional “Enterprise IA”

Protection ModelRequired level of

Information Protection “Specified” for each

Transaction

We will be loosely connected, sharing information – and protected?

NCES Overview (A high level view, with minimal protections integrated or called out)

Core EnterpriseServices

Product Lines

Needed Capabilities• Collaboration

– Web Conferencing– Instant Messaging

• SOA Foundation– DOD Web Services Profile

• Web Service Profile Update– Service Discovery

• Service Registry Integration• Metadata Registry Integration

– Service Security• Attribute access control

– Service Management• Alerts• Automated Failover & Recovery

– Identity Management– Metadata Services– Service Mediation

• Orchestration– Machine-to-Machine Messaging

• Content Discovery & Delivery– Federated Search Service– Enterprise Catalog Service– Data Source Integration– Content Delivery

• Portal

Service Management

Discovery

IA / Security

Mediation

Collaboration

User Assistant

Messaging

Application

Storage

SOA Foundation

Content Discovery &Delivery

Enterprise Portal

Collaboration

E2E IA/Security for “SOA / services in general” is still not clear, finalized

“E2E trust model”?Authorization Mgmt? And what else???

Overall enterprise security management

10

Heterogeneous SOA Fabric

DECIDE

OBSERVE

ACT

IGE

Future Planning

Current Operations

Future Operations

MOC Command Element

ORIENT

PATPAT

Mobile Ad HocNetworks

Forward DeployedNetworks (ADNS, etc.)

FixedNetworks(GIG-BE)

Other Edge Nets

Reach-Back Reach-FWD

Strategic

Operational Deploy/Employ

Engage/Maneuver

KILL

Border Services Border Services

IA/Security must span/support all levels, enclaves, especially at the border services

IA / C&A must accommodate all aspects, technical and non-technical

JOINT IA / C&A needed “at the edge” too!

• Promotes exchange of actionable information between tactical and operational units• MHQ/MOC, NCES, DIB, Tactical Edge Network (TEN), Bandwidth

Clearly one size does not fit all!

Other SOAs?

ServiceInfrastructures

Service-BasedApplications

• Example: 1 is a C4I system and 2 is a weapon system • Different “Vertical Stacks 1 and 2” use different standards for similar goals• “Horizontal Slice” ties the two vertical slices together so they can share data

Infrastructure X

Application A

Infrastructure Y

Application B

Infrastructure Z

Application C

Architecture Determines Interoperability … or Lack of!!

Web Services

ProfileCorbaProfile

DDS Profile

Other SOA Implementations1 2

STILL, what of the other methods as well…like REST, Web2.0 / AJAX, Gateways (DDS), etc…

IA / C&A must be E2E!

25 June 2008 1

DAHIEFYSTEMSNGINEER

Figure 2. Inheritance of IA Controls

• Systems contained within the boundaries of the aggregation inherit the controls of the aggregation

Each sub-aggregation is responsible for the IA controlswithin their boundaries but inherit the controls of the

environment in which they reside

Each subEach sub--aggregation is responsible for the IA controlsaggregation is responsible for the IA controlswithin their boundaries but inherit the controls of thewithin their boundaries but inherit the controls of the

environment in which they resideenvironment in which they reside

HW, SW, FW

System Network/ SOS

Enclave EnterpriseApplications Type

Derived from Marine Corps IA Briefing

The IA controls and interfaces in each element / boundary must be quantified / agreed to upfront!

13

Software & IA Security

ENTERPRISE IA/C&A strategies must surround / protect all functions

USERInputs!

IA / Security in SOA

01/15/2008 - 27

SOA Security Concerns

SOA Infrastructure

COMPUTER NETWORK DEFENSE

AUTHENTICATION SERVICES

AUTHORIZATIONSERVICES

AUDITSERVICES

CREDENTIAL MAPPING SERVICES

ROLE MAPPINGSERVICES

Identity Management Provisioning Business Processes and Workflows

SOA SECURITY SERVICES

SECURITY INFORMATION MANAGEMENT

IAVA & PATCH MANAGEMENT

INTRUSION DETECTION & PREVENTION

VULNERABILITY ASSESSMENT

FIREWALL SERVICES

Scorecards and Management Dashboards

ONE perspective of the IA/Security “services” that must ALL be integrated

Handlers

Enterprise Service Bus

Enterprise Service Bus (JMS, MSMQ, SOAP, SMTP, FTP….)

Security Service EnvironmentLDAP Directory OCSP Identity Provider PDP

Authenticate

NECC

MDC Portal Discovery

Create AssertionCRL Check

STD IF - EndpointSTD I/F STD I/F STD I/F

STD I/FSTD I/FSTD I/FSTD I/F

Get Policy

STD ServiceHandlers

“ALL” of these processes / functions MUST be prescribed under an EA and use the same “standard” standards, extensions therein

OR SOA can’t work globally!

(DO folks even know what security service chaining means, its impacts the way implemented now?)

The Big Picture: XML Family of Specifications

17

Still, are ALL WSS IA standards needed? Which do we invoke – it depends!

Security Management

Message Security

SOAP Foundation

Access Control

XML Security

Transport Layer Security

Network Layer Security

PolicyReliable Messaging

Security ManagementWeb Services Security (WSS) Standards (From NIST 800-95 Notional Reference Model)

SOAP 1.1

W3C XML-EncryptionW3C XML-Signature

SAML 1.1

WS Security 1.0

XACML 1.0 (and/or PAL?)

GIG ES Standards

TLS 1.0

NECC Standards

WS-Reliability 1.1WS-ReliableMessaging

SAML 1.1

IPSec?

WS-Policy?

WS-Trust?XML Key Management?

WS-Federation? (N/a?)

WS-SecureConversation?

SAML 2.0 (Liberty IDFF)?

No guidance to implement?

“Standard” Standards (versions and extensions therein) essential to E2E IA

WS-SecurityPolicy?WS-PolicyAttachment?WS-MetadataExchange?

SSLAnd/or WSS

18

According to Federal Guide to Securing Web Services (NIST 800-95)-- Confidentiality of Web service messages using XML Encryption (W3C standard)-- Integrity of Web service messages using XML Signature (W3C) and X.509 certificates (IETF)-- Web service authentication and authorization

SAML, XACML (OASIS standards)Web Services Security (OASIS standard)End-to-end SOAP messaging security

-- Security for UDDI - Universal Description, Discovery, and Integration

STILL, there are many more elements / functions needed: BOTH JEDS and additional NPE “service” attributes are needed Service Policies collaboration and implementations still needed Optimize the Process Flow (Services must trust assertions, no additional lookups) Handler interoperability methods / rules (compliance, extensions, etc) Service security chaining – not “just” assertions, but an E2E trust model!

Key Elements of SOA

The bare basics for SOA IA / security, so what others MUST be invoked?

19

Notional Network / Services ArchitectureOpen architecture can breed complexity and governance issues

Mis

sion

Ass

uran

ce (I

A /

CN

D)

COI Services & Applications

Basic Information

Services

FoundationServices

Other Enterprise Services

Network Infrastructure

Long Haul Communication Infrastructure

Ente

rpris

e Se

rvic

es M

anag

emen

t

Warfighting Mission Area• Command and Control• Navigation• Weapon Systems • HM&E• …

Business Mission Area• Financial Management• Logistics• Military Personnel• …

Intelligence Mission Area• ISR• …

• Operating Systems• Email• Office Productivity• Software / Patch Delivery• Browser• …

• Mediation• Metadata• Orchestration • Discovery• Messaging / Middleware• IA / Security• …

• Enterprise Collaboration• Content Discovery & Delivery• User Assistance (Portal)• …

(i.e. LAN)

Enterprise Services Bus (ESB)

Governance – NESI, OACE, etc!DATA:1.1 Make Data Discoverable1.2 Make Data Accessible1.3 Make Data Understandable1.4 Make Data Trustable1.5 Make Data Interoperable1.6 Provide Data Management1.7 Be Responsive to User NeedsSERVICES:2.1 Service Oriented Architecture2.2 Open Architecture2.3 Scalability2.4 Availability2.5 Accommodate Heterogeneity2.6 Decentralized Operations & Mgmt2.7 Enterprise Service ManagementINFORMATION ASSURANCE SECURITY3.0 DoD Net-Centric IA Strategy3.1 Net-Centric IA Posture & Continuity3.2 ID Management, Auth, & Privileges3.3 Mediate Security Assertions3.4 Cross-Security Domains Exchange3.5 Wireless Security3.6 Other IA: Integrity &, Firewalls, Log &

Audit, RAdAC

start our IA/C&A strategy at a high-levelInclude all enterprise architecture views

CCE

SOAESB

App

Address IA/C&A in the whole OSI stack / layers – including users!

20

COI/APP

SOA/ESB

CCE

Divide into major layers

Define interface

Define interface

List major “IA” attributes

PKI / PKEUserID / passwordEtc…

SOAP / SAMLWS* Security…Access Control, ID Mgmt, Secure JavaBiometrics, Etc…

IP SEC, NAC,Crypto - IP/LinkHAP, Trusted OS,SwA, A-T, Etc…

Notional approach to understand / track itFunctionally decompose the IA elements

We try for transparent IT/IA, but users AND designers must ALL engage

Mis

sion

Ass

uran

ce (I

A /

CN

D)

MAP to stack andfunctionalenclaves

IA controls(categories listed - as they could number up to 157)• Security Design & configuration• Enclave and computing environment• Enclave boundary defense• Physical and environmental• Personnel• Continuity• Vulnerability and incident management• Identification and Authentication

Certification Boundary

Certification Boundary

21

Notional C&A Enterprise Approach (The implementation end-state for any effort is passing “C&A” - which is still in work)

COIsApps

SOAESB

Services

CCE

Standards VerificationIA Controls*

• Conformity to APIMethods & protocols at this layer(in development)

Access ControlAuditI&ASystem Integrity

Certification boundary one

Certification boundary two

• Individual system C&A• Security services

• Protection of app and data

• Cryptography• Audit consolidation

• Conformity to API• Composabilty

• Consistency• Non-conflicting• Completeness

Access ControlAuditI&ASystem ProtectionSystem Integrity

Access ControlAuditI&ASystem ProtectionSystem Integrity

Methods & protocols at this layer(in development)

Methods & protocols at this layer(e.g., STIGs)

* NSSI 1253

Loosely–coupled architectures and asymmetric applications make IA and C&A more complex!

SOA C&A schemeUsing the concept of Type C&A, we envision a notional SOA C&A scheme using inheritance of component certifications. This includes:

o Services-level (SCAP) certification. o Services will be placed in service catalogs complete with “off-the-shelf”

certifications for operation.

o Mission Capability (MCAP) – level certification. Tier-2 security inheritance. o Analogous to the present STIG processo There should be a published repository of profile test procedures that

any implementer can apply to confirm the configuration is compliant with the certification dependencies.

o Enterprise Capability (ECAP) – level certification. o Universal service sets (like NCES, NECC, etc.) would be certified for

everyone to use in their “normal” manner of deployment, as a Tier-3 security inheritance.

SOA cannot become operational without C&A factored in, upfront !

SOA IA CONTROLS Per NSSI 1253Control Name SOA DoD 8500.2 DCID 6/3 Control Name SOA DoD 8500.2 DCID 6/3Access Enforcement AC-1 DCFA-1 Discretionary Incident Monitoring IR-1 VIIR-1 8.B.7.a

AC-2 ECAN-1 Access Control Fire Protection AC-1 PEHC-1 8.D.2AC-3 EBRU-1 (DAC): 4.B.2.a(2) PETC-1

PRNK-1 Mandatory Access PEHC-2

ECCD-1 Control (MAC):Temperature and Humidity Control AC-1 PEHC-1 8.D.2

ECSD-2 4.B.4.a(3) PETC-1Least Privilege AC-1 ECLP-1 4.B.2.a(10) PEHC-2Concurrent Session Control AC-4 ECLO-1 4.B.2.a(17)(a) Water Damage Protection AC-1 N/A 8.C.2.aDistinct Levels of Access AC-1 ECRR-1 N/A 8.D.2Auditable Events AC-1 ECAR-3 4.B.2.a(4)(d) Delivery and Removal AC-1 N/A 8.B.5.e

AU-1 Alternate Work Site AC-1 EBRU-1 N/A

Non-repudiation AC-1 DCNR-1 5.B.3.a(8)Location of Information System Components AC-1

Session Audit AC-1 N/A N/ASecurity Assessments CA-1 DCII-1 DCID: B.2.b;

ECMT-1 B.3.a Information Leakage AC-1PEPS-1 Manual:

4.B.2.b(6);5.B.1.b(1); System Security Plan PL-1 DCSD-1 1.F.69.B.1; 2.B.6.c(3)9.B.4 2.B.7.c(5)

Alternate Processing Site CP-1 COAS-1 6.B.3.a(2)(d) 9.E.2.a(1)(d)COEB-1 9.F.2.aCOSP-1 Appendix CCOSP-2 DOC1COEB-2 DOC1

User Identification andAuthentication AC-1 IAIA-1 4.B.2.a(7) Boundary Protection SC-3 COEB-1 4.B.4.a(27)

IA-2 I&A EBBD-1 5.B.3.a(11)(b)IA-4 ECIM-1 7.A.3IA-5 ECVI-1 7.B

Device Identification andAuthentication IA-3 N/A 4.B.5.a(14) EBBD-2 7.CIdentifier Management SC-1 IAGA-1 4.B.1.a(2) EBBD-3 7.D

SC-2 IAIA-1Software and InformationIntegrity SI-1 ECSD-2 4.B.1.c(2)

IAIA-1 5.B.1.a(3)IAIA-2 5.B.2.a(6)IAIA-2

A good perspective to focus on the “middle” security requirements

What SOA C&A might look like?

HW / Firmware / HAP / etc

OS / VM / core services / IO Security

Monitor

“ ’Service Manager’ (and / or a XML gateway) ”

Enterprise Network / Service manager *

PDP, policy manager, PEP *

SERVICES

WEB / P&S Applications

Each box is “plug and play” C&A’d

Within the interfaces of above & below AND any inheritance needed

To facilitative open competition and various providers, thus multiple products to select from, items are C&A’d within these boundaries…

? ?

Legacy Applications

Middleware bridge (”SLAIN”)

(* = may be part of Service Manager or gateway)

25

CANES Early Adopters Services Model(Accreditation boundary varies with system model)

Services & Security Boundary

Model I

Model II

Model III

Model IV

Must quantify, even be prescriptive, all interfaces, inheritance and controls

So what really matters E2E? A notional Quality of Protection (QoP) Hierarchy

(A general defense in “breadth” perspective – but what REALLY matters?)

“DATA QoP”(C-I-A and N & A)

IA&A and CBE / DCS(distributed / transitive trust model … E2E data-centric security and protections)

Core / Security Services( WS* and other security policy / protocols / standards (including versions & extensions therein)

network protection – CND – FW / IDS / VPN / etc (in general, mature capabilities – but multiple unclear “CM” processes are persistent and problematic)

IO … and ... IA

CNO/E/A, “I&W”, OPSEC, etc Crypto, KMI, TSM/HAP, policy, etc

Complex… Dynamic…

Known… Static…

Settings

A&E / Policy

Standards

IA devices

WHAT really matters is; IA standards, IA&A and CBE/DCS!

Authorization / access control deltas(from the OSD / NSA/GIAP / DISA / IC “SIE” Panel – Sep 08)

• Establish / codify digital authorization policy model, schema and adjudication process

• Establish attribute governance process• Trust Model / details (& Supply chain issues)• Define / Identify Authoritative attribute sources• Identity management foundation• Measure and respond to authentication assurance level;

measure confidence• Authorization schema / guidance needed

Still much to quantify and agree on in the whole E2E IA&A process

Auth & AC SIE Panel Conclusions (from the OSD / NSA/GIAP / DISA / IC “SIE” Panel - Sep 08)

• Understand and define trust models that align with the enterprise (e.g., DoD, IC, DHS, coalition, industry)

• Create robust authentication technologies • Create smarter PDPs and PEPs• Define/identify/collect better attributes (e.g.,

location, situation)• Long term goal is to move toward RAdAC

AKA – We still do not know how to fully build SOA IA yet, let alone C&A

29

Summary• IA/Security must be “built in” – including SOA / web

services

• Major Enterprise “IA / C&A” barrier is leadership / governance, not technical (what & who to follow)

• Need an enterprise DOD IA Design “implementation” level approach

• All architectures / standards / approaches must synchronize, interoperate (wrt some overall DoD/Federal CONOPS!)

• ISSE training / education – both implementation and A&E

SOA makes great business sense, but the assurance must be determined, including C&A, before it is implemented!