Mike Davis [email protected]858-537-8778 Information Assurance (IA) for Service-Oriented Architecture (SOA) August 2008 Offered for Discussion and Consideration by SPAWAR 5.1.8 IA Technical Authority For (list audience) IA and C&A for SOA A General Overview
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 [email protected] 858-537-8778. - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
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
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!
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
-- 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• …
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)
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