Mike Davis Michael.h.davis@navy.mil 858-537-8778

IA and C&A for SOA A General Overview Information Assurance (IA) for Service-Oriented Architecture (SOA) For (list audience) August 2008 Offered for Discussion and Consideration by SPAWAR 5.1.8 IA Technical Authority Mike Davis Michael.h.davis@navy.mil 858-537-8778

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 needed There 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 (or why “IA” is so complex / hard… because it’s way more than that!) “IO” and CNO Defend Attack Exploit p CIO FISMA Operations IAMs CND p CMI/KMI PKI/CAC ID Mgmt p p P P C&A CA Support p P P p p P P IA P p P P P Policy Training IA Services Multiple players Multiple PEs/Lines Multiple threats Multiple PMW/S/As Typical Acquisition part Requirements Enterprise Risk Mgmt. P = Hard IA Product (yes, and PIT too) p = Soft IA Product Strategy AND Governance critical to “implementation” success!

An “Overall” Enterprise Picture(what are the minimal elements, who “owns” them, & how do they get integrated?) Apps & COIs SOA/ESB/Services Business processes There is more to the enterprise IA/C&A picture than “just” CCE, SOA and Apps, which are hard enough to integrate CCE ITIL/ITSM execution Data strategy / ownership Dynamic Access Control Hardware / Software Assurance Data privacy protection and Auditable anonymity IA/Security strategy must consider much more than “just” SOA 7

GIG IA Protection Strategy Evolution "Need to SHARE" and Distributed / transitive trust models Transactional “Enterprise IA” Protection Model Required level of Information Protection “Specified” for each Transaction Static “Perimeter” Protection Model Common level of Information Protection provided by System High Environment • Common User Trust Level (Clearances) across sys-high environment • User Trust Level sufficient across Transaction/COI – varies for enterprise • Privilege assigned to user/device based on operational role and can be changed • Privilege gained by access to environment and rudimentary roles Today Future • 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 • 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 • Manual Review to Release Information Classified at Less than Sys-high • Manual Analysis and Procedures determine allowed interconnects • Automated mechanisms allow information to be Shared (“Released”) when users/devices have proper privilege and Transaction can meet QoP requirements We will be loosely connected, sharing information – and protected?

NCES Overview (A high level view, with minimal protections integrated or called out) Needed Capabilities Core EnterpriseServices • 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 Collaboration Product Lines Mediation IA / Security Collaboration Discovery Enterprise Portal Service Management Content Discovery & Delivery Storage Application SOA Foundation Messaging “E2E trust model”? Authorization Mgmt? User Assistant And what else??? Overall enterprise security management E2E IA/Security for “SOA / services in general” is still not clear, finalized

Heterogeneous SOA Fabric • 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! Strategic KILL Operational Deploy/Employ Reach-Back Reach-FWD JOINT IA / C&A needed “at the edge” too! PAT Border Services Border Services Fixed Networks (GIG-BE) Engage/Maneuver Forward Deployed Networks (ADNS, etc.) Mobile Ad Hoc Networks Other Edge Nets IA/Security must span/support all levels, enclaves, especially at the border services 10 IA / C&A must accommodate all aspects, technical and non-technical

Other SOAs? Architecture Determines Interoperability … or Lack of!! Other SOA Implementations 2 1 Application A Application B Application C Service-Based Applications Corba Profile Web Services Profile DDS Profile Infrastructure X Infrastructure Y Infrastructure Z Service Infrastructures • 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 STILL, what of the other methods as well… like REST, Web2.0 / AJAX, Gateways (DDS), etc…

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

Software & IA Security USER Inputs! Lots of parts and perspectives to consider, integrate and govern! ENTERPRISE IA/C&A strategies must surround / protect all functions 13

IA / Security in SOA Scorecards and Management Dashboards ONE perspective of the IA/Security “services” that must ALL be integrated

PDP LDAP Directory OCSP Identity Provider Authenticate Handlers Discovery Portal NECC MDC Security Service Environment (DO folks even know what security service chaining means, its impacts the way implemented now?) STD I/F STD I/F STD I/F STD I/F Enterprise Service Bus Enterprise Service Bus (JMS, MSMQ, SOAP, SMTP, FTP….) CRL Check Create Assertion Get Policy STD I/F STD I/F STD I/F STD IF - Endpoint STD Service Handlers “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!

The Big Picture: XML Family of Specifications

Still, are ALL WSS IA standards needed? Which do we invoke – it depends! Web Services Security (WSS) Standards (From NIST 800-95 Notional Reference Model) Security Management Security Management SAML 1.1 WS-Trust? XML Key Management? WS-Federation? (N/a?) SAML 2.0 (Liberty IDFF)? Policy Message Security Reliable Messaging WS-Policy? WS-SecureConversation? WS-SecurityPolicy? WS-MetadataExchange? WS-PolicyAttachment? WS-ReliableMessaging WS-Reliability 1.1 WS Security 1.0 Access Control SAML 1.1 SOAP Foundation SOAP 1.1 XACML 1.0 (and/or PAL?) XML Security W3C XML-Encryption W3C XML-Signature SSL And/or WSS Transport Layer Security TLS 1.0 Network Layer Security IPSec? GIG ES Standards NECC Standards No guidance to implement? “Standard” Standards (versions and extensions therein) essential to E2E IA 17

Key Elements of SOA 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 andadditional 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! 18 The bare basics for SOA IA / security, so what others MUST be invoked?

COI Services & Applications • Business Mission Area • Financial Management • Logistics • Military Personnel • … • Warfighting Mission Area • Command and Control • Navigation • Weapon Systems • HM&E • … • Intelligence Mission Area • ISR • … Enterprise Services Bus (ESB) Basic Information Services Other Enterprise Services FoundationServices Enterprise Services Management • Mediation • Metadata • Orchestration • Discovery • Messaging / Middleware • IA / Security • … • Operating Systems • Email • Office Productivity • Software / Patch Delivery • Browser • … • Enterprise Collaboration • Content Discovery & Delivery • User Assistance (Portal) • … Network Infrastructure (i.e. LAN) Long Haul Communication Infrastructure Notional Network / Services Architecture Open architecture can breed complexity and governance issues start our IA/C&A strategy at a high-level Include all enterprise architecture views Governance – NESI, OACE, etc! DATA: 1.1 Make Data Discoverable 1.2 Make Data Accessible 1.3 Make Data Understandable 1.4 Make Data Trustable 1.5 Make Data Interoperable 1.6 Provide Data Management 1.7 Be Responsive to User Needs SERVICES: 2.1 Service Oriented Architecture 2.2 Open Architecture 2.3 Scalability 2.4 Availability 2.5 Accommodate Heterogeneity 2.6 Decentralized Operations & Mgmt 2.7 Enterprise Service Management INFORMATION ASSURANCE SECURITY 3.0 DoD Net-Centric IA Strategy 3.1 Net-Centric IA Posture & Continuity 3.2 ID Management, Auth, & Privileges 3.3 Mediate Security Assertions 3.4 Cross-Security Domains Exchange 3.5 Wireless Security 3.6 Other IA: Integrity &, Firewalls, Log & Audit, RAdAC App SOA ESB Mission Assurance (IA / CND) CCE Address IA/C&A in the whole OSI stack / layers – including users!

Notional approach to understand / track it Functionally decompose the IA elements List major “IA” attributes Divide into major layers PKI / PKE UserID / password Etc… • 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 COI/APP Certification Boundary Define interface SOAP / SAML WS* Security… Access Control, ID Mgmt, Secure Java Biometrics, Etc… MAP to stack and functional enclaves SOA/ESB Mission Assurance (IA / CND) Define interface Certification Boundary IP SEC, NAC, Crypto - IP/Link HAP, Trusted OS, SwA, A-T, Etc… CCE We try for transparent IT/IA, but users AND designers must ALL engage

Notional C&A Enterprise Approach(The implementation end-state for any effort is passing “C&A” - which is still in work) IA Controls* Standards Verification Access Control Audit I&A System Integrity Methods & protocols at this layer (in development) • Conformity to API COIs Apps Certification boundary two Access Control Audit I&A System Protection System Integrity • Conformity to API • Composabilty • Consistency • Non-conflicting • Completeness Methods & protocols at this layer (in development) SOA ESB Services Certification boundary one Access Control Audit I&A System Protection System Integrity • Individual system C&A • Security services • Protection of app and data • Cryptography • Audit consolidation Methods & protocols at this layer (e.g., STIGs) CCE * NSSI 1253 Loosely–coupled architectures and asymmetric applications make IA and C&A more complex! 21

SOA C&A scheme Using the concept of Type C&A, we envision a notional SOA C&A scheme using inheritance of component certifications. This includes: • Services-level (SCAP) certification. • Services will be placed in service catalogs complete with “off-the-shelf” certifications for operation. • Mission Capability (MCAP) – level certification. Tier-2 security inheritance. • Analogous to the present STIG process • 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. • Enterprise Capability (ECAP) – level certification. • 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 1253 A good perspective to focus on the “middle” security requirements

What SOA C&A might look like? WEB / P&S Applications Legacy Applications Middleware bridge (”SLAIN”) SERVICES ? ? Enterprise Network / Service manager * PDP, policy manager, PEP * “ ’Service Manager’ (and / or a XML gateway)” Each box is “plug and play” C&A’d Within the interfaces of above & below AND any inheritance needed OS / VM / core services / IO Security Monitor HW / Firmware / HAP / etc To facilitative open competition and various providers, thus multiple products to select from, items are C&A’d within these boundaries… (* = may be part of Service Manager or gateway)

CANES Early Adopters Services Model(Accreditation boundary varies with system model) Model I Model II Model III Model IV Services & Security Boundary Must quantify, even be prescriptive, all interfaces, inheritance and controls 25

So what really matters E2E?A notional Quality of Protection (QoP) Hierarchy(A general defense in “breadth” perspective – but what REALLY matters?) “DATAQoP” (C-I-A and N & A) Complex… Dynamic… Settings 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) Standards IA devices network protection – CND – FW / IDS / VPN / etc (in general, mature capabilities – but multiple unclear “CM” processes are persistent and problematic) Known… Static… IO … and ... IA A&E / Policy CNO/E/A, “I&W”, OPSEC, etc Crypto, KMI, TSM/HAP, policy, etc 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

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! 29

Mike Davis Michael.h.davis@navy.mil 858-537-8778