Mike [email protected]
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!