Operational Patterns For Information Sharing 17 May 2006 Chris Daly [email protected]

IEEE Computer Society of Northern Virginia / Washington DC

04/22/23 © 2006 IBM Corporation

Operational Patterns For Information Sharing17 May 2006Chris [email protected]

mailto:[email protected]

Operational Patterns for Information Sharing

© 2004 IBM Corporation2 04/22/23

Net-centricity and Information Sharing

Move to net-centricity reflects thinking by organizations about the need for shared infrastructures and shared services to reduce costs of infrastructures, improve efficiencies of information exchanges, and increase event responses

– Net-centric environments and services-oriented architectures provide dynamic flexibility in matching resources to mission requirements for delivery of “products”

– Net-centricity enables survivability and efficiency of value chain (supply chain, etc.) through federated processes and autonomic resources

– Supports plug-and-play convergence of communication modes – voice, data, multimedia – and greater ability to fuse data types, thereby enabling a richer analytical fabric and ability to interoperate quickly

Net-centric environments provide easier ability to collaborate within the enterprise and between partners

– Provides ability to tear down stovepipe processes and provide coordinated response to events and business needs

– Net-centricity enables mobility of users through self-forming, dynamic workplaces– Net-centricity features perimeterless, virtual organizations and business

processes



Why is Trust Important for Net-centric Environments?

Net-centricity suggests establishment of an “end-to-end trust model” which is directed at situational awareness of value chain activities, risk control, and to promote secure and coordinated event response across domains.

– Data sensitivity issues with cross-domain exchanges – Need to share coupled with need-to-know and need-to-hide

– Extra emphasis on strong authentication, pedigree of code and information, and platform integrity

Trusted computing provides a secure foundation for net-centricity by:– Supporting interoperable and verifiable confidentiality and integrity

mechanisms for chaining of services across the application layer,

– Employing negotiation protocols that support appropriate controls over information sharing,

– Providing the core “roots of trust” for all services though all layers of the stack (physical layer through application layer).



Why Dynamic End-to-End Trust? The Threat is growing and is dynamic: Amateurs to well-organized, professional

hackers with specific targets– Professionals use trap doors, worms, in-circuit emulators, mod chips, etc. to

bypass crypto and separations in systems– Steal keys, forge certs, steal plain text – Extortion, denial of service, etc

The Need to Share is Dynamic: Need to integrate Internet into business processes – net-centricity

– Share/fuse data and provision computing resources in real-time– Need to know and need to share and need to hide information– Grid computing– Global reach of infrastructure– Respond to incidents– Integrity is critical – can I trust this person, this information, this software?

Dynamic trust framework is only way to build end-to-end mission assurance



Trust Requirements for the Net-centric Environment Trust in organization based on policies, ethics, regulatory compliance, financial

standing, alliances, contracts, business line/mission, proven performance (brand image or other credibility factors) – cross-domain PKI, compliance solutions

Trust in personnel as measured by background/identity checks, observations of personal conduct, polygraphs, training, knowledge or expertise levels, roles, certifications – portable reputation systems, smart cards, biometrics, IDMS

Trust in process based on practices and procedures that have been vetted over time and/or by licensing or by other authoritative bodies – CMMi, location-awareness, guards and classifiers, source authority rationalization, privacy-preservation protocols, workflow solutions

Trust in data (or code) based on an assessment of the pedigree and sensitivity of the data or code, collection/development method(s), as well as the employment of integrity, confidentiality, and quality mechanisms for the development and delivery of the information or code – digital signatures, CC evaluations, vulnerability analysis tools, watermarks, runtime SVT and discovery, DRM, trusted compilers

Trust in infrastructure based on scientific theory, enterprise architectures or proven references, testing, fab pedigree, and the application of diversity / redundancy – integrity awareness, label enforcement, cryptography, anti-tamper, MLS EDA/SOA, hardware roots of trust, autonomic policy mgrs



Trust Associations Must Consider Multiple Horizontal and Vertical “Bindings”

Organization (Policy)

Personnel

Process

Information

Object

Infrastructure

Organization (Policy)Personnel

Process

Information

Object

Infrastructure

TransactionalContext

(Purpose)

Node A Node B

TrustedThird Party /

Gateway

Trusted semantic interpretation / transformation

Trusted Identity assertion

Integrity / pedigree of data

Confidentiality of data

Throughput



Overview of Requirements for Information Sharing Systems

Customers are looking for solutions and are willing to pay for the right solution – focus is on e2e, services-based, infrastructure solutions that promote cross-domain and dynamic collaboration, information sharing, and transparency to applications

What customers want is multilevel access management and data management in a SOA and/or EDA environment– Data in motion– Data at rest– Resource in motion– Resource at rest

Protection against virtual and physical threats– Unauthorized disclosure, interruption of services, unauthorized

access or use– Pedigree awareness, anti-tamper, software protection



A SOA environment poses trust challenges when signaling and executing strategic intent among different domains

How to signal intent and trustworthiness of an “aggregated service” (i.e., a plan or order) without exposing the complete schema (e.g., the complete OPplan)?

How to determine if specific services should not be used to execute strategic intent due to “chaining” of services to untrusted nodes? And how to determine which services are degraded in their ability to deliver?

How to discover and aggregate the permissions of services that will satisfy strategic intent?

How to maintain the semantic equivalence of the “supervisor’s” strategic intent across multiple services in different domains?

How to ensure that strategic intent is communicated intact (and not spoofed or intercepted) to all essential (consumer) units? And semantically interpreted correctly?



As such, E2E Netcentric Information Sharing Requires Services That Support: Multilevel Boundary Integration and Mediation

– Across consumers and providers with identities, pseudonyms, privileges, attributes operating under different security policies or levels/categories

– By adaptive mission rules (e.g., RoE) that modulate, constrain or augment events and transactions

– By discovery and registry services that modulate, bind or complete the transaction definition

Multilevel Semantics and Syntax– Among cooperating data providers with individual label structures and

different data semantics and syntax– Among cooperating trust authorities with distinctive [classification and

identity] policies– Among cooperating services and domains with cumulative business rules

and access permissions Multilevel Transport and Distribution

– Over global transits that may require recovery and rollbacks– Over performance and availability contingencies that break siloed

infrastructure bindings– Over networks that require balancing of encryption of data, transactional

control (routing / QoS / QoP) information, and performance (low latency)



E2E Net-centric Information Sharing Must Consider QoS and QoP Differences Among the Layers (Domains) of Processing

Situational Awareness (MRP)

Non-RT Events (ERP)

RT Events (Factory)

Course of Action

Common Operational Picture

Collaboration

ActuatingSensing / TrackingEvent Fusion

WorkflowData Mining

Mission

RT EDA

RT SOA

SOA

QoS – HighQoP – Med - Low

QoS – MedQoP – Med - Low

QoS – Low - MedQoP – High - Med



Event Driven Architectures and RT SOA pose unique trust challenges that must be considered

Non-real time

seconds

milliseconds

microseconds Radar Weapon

Tracking

Command & Control

Logistics

EDA may entail multiple domains of time-dependent control and security control that must be synchronized for creating a COP and mission success

Each domain has different QoS and QoP attributes that reflect differences in infrastructure, performance, roles, policies, etc.



C2 systems must be integrated into an open loop, end-to-end workflow / decision-making process – not just the information sharing process

Think it’s true, It’s true

Think it’s false, It’s true

Think it’s true, It’s false

Think it’s false, it’s false

Have it, Know I have it

Don’t have, Know I don’t have

Have it, Don’t know I have it

Don’t have, Think I have it

It’s fair, I accept

It’s unfair, I accept

It’s fair, I reject

It’s unfair, I reject

Fits model, it’s right

Doesn’t fit model, it’s right

Fits model, it’s wrong

Doesn’t fit model, it’s wrong

Message is clear, Msg enables

Msg is clear, Msg doesn’t enable

Msg is ambiguous, Msg enables

Msg is ambiguous, Msg doesn’t enable

High reliance, clear terms

High reliance, unclear terms

Low reliance, clear terms

Low reliance, unclear terms

DataCollectAssets

History/ Discernment

ReductTool

Pacts Beliefs

Emotion Policy Position TrustLevel

ChoiceRange

Cognitivegap

Intelligence Analyst

Decision-maker

Observe Orient Analyze

Stipulate Act Decide



























DataCollectAssets


ReductTool

Pacts Beliefs


ChoiceRange

Cognitivegap


Decision-maker



























DataCollectAssets


ReductTool

Pacts Beliefs


ChoiceRange

Cognitivegap


Decision-maker



High

External

Sources

(Sensors)

Low

External

Sources

(Sensors)

High

ActuatorCascading control info

High

Policy

Sources

Low

Policy

Sources

Low

Actuator

Cascading control and sensor info causes latency in current MSL architectures, resulting in unsynchronized actions between levels



Globalization is also increasing concerns about the integrity of net-centric environments and their respective development environments

User

Identity proofingprocess

CI

Data collectionprocess

A D S

A

ASensor

CI

CI

Grid

D

D

S

S

A D S

A

A

D

D

S

S

Code productionprocess

Org A

Org BHW production

process



Customers also want to minimize the burdens associated with current IA mechanisms used to manage information sharing

Examples of IT control infrastructures that must be provisioned and managed:– PKIs and/or other security policy, identity, authentication, directory/DNS, access

control and provisioning systems– Guards, relabelers, and classifiers; smart cards, biometrics– NIDS / HIDS / IPS / AV / extrusion & steganography filters / Alert management– Patch and vulnerability management / remediation– Platform configurations. STIGs– Audit infrastructure– VPN, encryption, and related key management infrastructures– Business continuity, back-up and recovery, and secure storage management

infrastructures Often, these infrastructures are siloed across an organization or value-chain, or

application-specific – you pay for them multiple times Still do not solve the security problem The security problem gets in the way of efficient information sharing – we need to

do better with less and with a more holistic approach



New Approaches? Current and future challenges to information sharing will not be met with

existing solutions and approaches alone A fundamentally new approach is required

– Dynamic trust establishment and strong containment guarantees

New patterns such as Trusted Virtual Domains promise …– Satisfy on demand requirements and radically simplify IT security management

– Significant challenges / risk / opportunity• Theory, scalability, composition / decomposition of policies

Hypervisor Security Architecture– A logical first step for foundational security and distributed Trusted Computing

Base

– Introduces a new integrity-based Access Control framework



Cross-Domain Information Sharing Technology Enablers Infrastructure Services View:

– Controlled interfaces / guards– Labels at rest / Labels in motion– Network-based and file-based crypto– NAC and integrity-based computing (e.g.,

TVD)– Virtualization of nodal resources– Coordinating Policy managers

• DAC, MAC/MIC• Autonomic

– Trust managers• AT, RTM, TCB

– Provisioning managers• Policies• Identifiers• Applications• Infrastructure• Remediation

Application and Data Services Views:– Cleansing, Staging, Transformation– Mining and Entity Resolution– Federation (directories, queries, identities)– Metadata management / Semantics

management– XML tags at rest / XML tags in motion– XML object crypto– XMLds– DRM– Policy Managers

• RuBAC, RADAC, RBAC, DAC– Trust Managers

• WS-Trust, .Net, Liberty



Some pain points about current environments that present hurdles to moving to cross domain information sharing environments

Data is often overclassified and not labeled– Legacy from system high operations– Need to profile, cleanse and label data from different sources– Need discipline on source authorities and common metadata

Certification and accreditation of multilevel environments is hard and time-consuming– No good reference implementations– SOA environments also pose more questions due to dynamic properties of composite

services– No integration of static certifications to runtime environments

Controlled interfaces often act as bottlenecks– A mindset as well as a protection mechanism– A backstop for lack of security engineering behind it

Information types and access methods, network strategies, and storage strategies are not synched up in ways that strictly rely on the extended attributes of a MLS OS– CAS/unstructured data vs database and block-level/SAN vs application and

file-based/NAS– CIPSO/RIPSO support in network router fabrics or IPsec labeling support at nodes or

label formats of MLS DBs



Key IA Challenges for Cross-Domain Information Sharing

Key Mgmt /

Distribution /

Keystores

Crypto MLS MSL

Label-enforcement

mechanisms / Labeled Objects

Multi-functional Guards / Identity

Federation$

$$

Assurance Mountains

COTS COTS



Some assumptions about the net-centric information sharing environment of the future

Controlled interfaces will be consolidated and multi-functional but there will be less reliance on them

Endpoints will be virtualized, tamper-resistant, and crypto-enabled Integrity of endpoints, subjects, and objects will become more assured and

integrity states (including pedigree) will be known at runtime Security policy enforcement points will move to the endpoints and off the

network Information flows and objects will be protected and labeled at runtime and

over the information life cycle Security policy decision points will be distributed, net-centric, autonomic,

high assurance, and multi-level Security policy and provisioning managers can be distributed or

centralized, and interwoven with the mission events and planning cycles to synchronize QoS and QoP with mission packages

Security policy control flows will be virtually separate from the mission runtime environment

Different level networks will collapse into black or striped core, while requiring multi-core endpoints



Some Tenets for Cross-Domain Information Sharing

Assurance and robustness lower in stack as possible– Leverage hardware / SoC / Multi-core / Anti-tamper– Minimize size of other HA components – reference monitor, hypervisor– Work out composite evaluation issues

Separate concerns / minimize complexity– Containerize/virtualize, componentize, standardize– Minimize application impacts using “swim lanes” and protected shims /

JVMs– Separate inspection from evaluation; reduce reliance on guarded

chokepoints; separate QoP from mission logic Maintain runtime trust equilibrium and interoperability

– Integrity/secrecy/privacy – use hybrid deterministic and non-deterministic methods (e.g., DAC/attestation on MAC/MIC)

– Organization, process, code/data, personnel, infrastructure pedigree and trust standards and bindings

– Distributed, cross-domain, autonomic policy managers and runtime discovery of permissions for internodal exchanges across a grid



Elements of Cross-Domain Information Sharing Patterns

Componentization /Common Event Infrastructure

Common OperationalPicture

Interoperability /Performance

Digital ID Mgmt Java / Web Services

Virtualization / Multi-Core

Composability of Assured Elements

Strategic Intent /BPELAutonomic Policy

Confidentiality / Integrity / Anti-Tamper

Classification /Labeling

Open Standards

Controlled InformationSharing

Metadata /Semantic Design

Choreography / Simulation / Complex

Event Processing

Infrastructure Management Risk Management

OrchestratedResponse

Mission Management

Tooling, Usability, SE Processes, and Services



Incorporating Stakeholder Views is Critical for Cross-Domain Information Sharing

Stakeholders include services provider’s infrastructure manager, network manager, mission manager, services consumer, etc. with different perspectives regarding:

Governance - Layered architectures – who owns what piece? Complexity and Usability – security policies must be simple to

configure and administer, transparent to applications, and adaptive to the mission needs

Interoperability and Performance - PKI across domains; SOA across domains; Policy management across domains; Provisioning across domains, Systems management across domains; Information exchange across domains

Hierarchies of processing - Must address layers of processing through which data enrichment is provided that encompass event-driven architectures (EDAs) operating under different temporal constraints, different infrastructure objectives (QoS, QoP) at hard RT to soft RT SOA to pub/sub SOA enterprise systems



Information Sharing Patterns

Each pattern focuses on specific information sharing challenges and cultural barriers to sharing

Each pattern highlights a particular technology approach

Patterns can and should be combined into composite patterns

Composite patterns reflect evolution of customer needs and vendor capabilities



Cross-domain information sharing patternsGovernance Key Features Primary Tools Integration Solution

Pattern“Shared” Enterprise owns all assets

Extract, Transform, Label, Load

Pub/sub and smart pull, DB extenders; DIS

B/E integration; data warehouse

Shared Space

Enclave owns assets

Federation and web services

Smart pull, DB extenders, fed query and Id Mgr; EAS; Datapower

Service integration (thru guards); anonymization

Distributed or Federated Enclave

Extended Enterprise (COI) owns assets

Endpoint / Network fusion; reputation systems

Intelligent caching, HAP client, strong authentication

Virtualized grid (crypto and label-based); autonomic policy mgrs

Dynamic Community of Interest (COI)

Originator-controlled &/or release-controlled

Multi-domain objects / portion marking

Content Mgr, Omnifind, derivative class. tools; DRM

Trusted JVM; semantic level integration, XMLsig, XMLencrypt, XACML, XMLQuery

Content-Based Information Sharing

Ad hoc personal and mobile networks that own a COA / COP

Pervasive systems, RT EDA; SCADA; sensors

Anti-tamper, Small footprint; low power / low latency

Simple guards, trusted RTOS / RT SOA; wireless links; t-spaces

Pervasive and embedded systems



Distributed Enclave Pattern

Data Tier Application Tier Client Tier

TS

S

U

Security Tier (RBAC/PKI/Directory)



Problems with Distributed Enclave Pattern Distributed Systems Management

– Many servers require more administrators– Greater risk of security vulnerabilities– More difficult to audit, back-up and recover multi-tiered applications over

distributed platforms Multiple Network Management

– Many networks at different classification levels – the networks must be air gapped and/or connected only thru trusted guards

– Separate workstation connections for each network– Separate certification for each network connection

Data Management– Copying of data between security classifications is time consuming and

expensive; Separate guards may not interoperate; Hard to keep data synchronized

– Ability to fulfill need-to-share mission is limited – cascading problem Security

– Doesn’t provide real-time access to data residing at different levels - write down process is very hard; write up process is not timely nor efficient

– Doesn’t preserve the original classification of data as its moved to higher levels for analysis (data contamination)



Federated Enclave Pattern


TS

S

U

Security Tier (Federated IM/PKI/Directory)



Problems with Federated Enclave Pattern

Similar problems as Distributed Enclave Pattern … Federated Identity Management provides some cross-

domain access for services at same level– Must still ensure binding and assurance of cross-domain token

or assertion to requestor’s identity and PKI domain– May require privacy preservation protocols / pseudonymity

Federated queries between different enclaves are possible but may require reclassifiers for aggregated results– Anonymized queries may be helpful, with pointers to real data,

however, this assumes pre-runtime setup of anonymization mechanisms between enclaves



Shared Space Pattern


TS

S

U




Problems with Shared Space Pattern

Must replicate data to shared space Lose “ownership” and control of data once in shared space

(assume no DRM) Must determine common label format and meaning for

shared information End-to-end trust needs an end-to-end integrity fabric that

permits interoperable engagement on collaborative issues– Shared space lacks ability to maintain and measure integrity of trust

chain– Shared space lacks ability to embed integrity controls in cross-

organizational collaborative flows Shared space exhibits implicit transitivity; mandatory

integrity guarantees must help bridge these transitive relationships while not revealing vulnerable integrity states



Dynamic COI Pattern


TS

S

U

Security Tier (MAC/RuBAC/PKI/Directory)

Access mediated thru MLS policy managers, hardware TCB, and labels



Problems with Dynamic COI Pattern

Requires ubiquity and virtualization of hardware roots of trust

Places significant demand on provisioning and policy services

Demands high assurance integrity controls at client nodes and attachment points

Articulation of trust and integrity policies needed– Hierarchical taxonomy of policies needed for negotiation,

conflict resolution and policy enforcement– Need scalable nodal integrity administration; most service

requests will require labels, crypto keys, and ensure integrity of requestor identity and tokens



CBIS Pattern


TS

S

U


Data and applications bound thru crypto and digital signatures



Problems with CBIS Pattern

Heavy reliance on cryptographic mechanisms– Performance and scalability questions– Key management questions

Has similar problems as DRM systems with attack at the seams if software only protected

Has similar problems as Dynamic COI pattern if hardware is involved

Requires ubiquity and virtualization of secure keystores Complexity of trying to deal with different data types and

viewers / players – discrete, unstructured text, collaborative, RT, streaming, imagery, etc.



Pervasive / Embedded Systems Pattern

Client TierSecurity Tier (MAC/RuBAC/

PKI/KMI/Directory/Provisioning)

Out-of-bandTrust

SometimesConnected

Integrity-basedReputation systemscontrolled interfaces

And multi-core crypto forP2P collaboration

CollaborationT-Space



Problems with Pervasive / Embedded Pattern Trust propositions in a pervasive, transitive environment depend on integrity of

devices and the integrity of an entity relying on such device– Need strong binding of identities and identifiers– Need strong and consistent integrity of authentication credentials and containers –

personal credential and reputation stores Common metadata for P2P trust needed

– How much additional metadata is needed to support peer-to-peer, net-centric trust fabric, and at what level – data element labels, pedigree info, etc.?

– Source authorities for integrity policies and trust attributes must be determined Various types of software systems used to execute pervasive, event-driven

services, such as CORBA, DDS, J2EE, .NET, MQ Series, etc., generate and manage various kinds of context data for important features and functions that vary from system to system. – To correctly execute these features and functions in a pervasive application, a

solution is needed to manage and coordinate the integrity of this context data across arbitrary control systems.

– Integrity state management is needed to reliably monitor the integrity level of a set of collaborative and transitive application services

Support for multiple concurrent CAs



Architecture Evolution for E2E Information Sharing – Distributed Enclaves with a Shared Space

MLS Shared Space

Org ADomain

Org BDomain

Org CDomain

DAC/RBAC PEPSystem High

DAC PolicyMgr



InfoIntegration

DataPrivacy

DirectoryIntegration

ContentMgmt

PublicDomain



Shared Space Model is Place to Start

– Virtualization, enclaves, and crypto provide domain-specific swim lanes at application and network layers

– DAC (Discretionary Access Controls) provides entrée to Application and Network “swim lanes”

– MAC (Mandatory Access Controls) provides separate “swim lanes” at consolidated Data Tier

– Need to adjust “swim lane” allocations statically based on events and/or business changes in required Quality of Protection (QoP)



Evolution of Strategy – 2- 3 years

MLS Shared Space

Org ADomain

Org BDomain

Trusted Virtual Domain(“swim lanes”)

Org CDomain

PublicDomain

Universal Access Classes

Labeled and CryptographicallyProtected Collaboration within TVD

Unified and Merged Secrecy Lattices

MAC/DAC Policy-enforcedDomain attachment points

Risk-adaptive access policies

Privacy controls over data, And anonymized data and users

Federated user access from single domain to virtual domain and within organizational domains

InfoIntegration

DataPrivacy

DirectoryIntegration

ContentMgmt

TVD PolicyMgr

TVD PolicyMgr

TVD PolicyMgr

TVD PolicyMgr



Trusted Virtual Domains (TVDs) add dynamic COI management capability

– Virtualization, packet labels, and crypto provides swim lanes at application and network layers

– DAC (Discretionary Access Controls) provides entrée to Application and Network “swim lanes”

– MAC (Mandatory Access Controls) provides separate “swim lanes” at Data Tier and/or consumes packet labels

– TVD policy manager adjusts “swim lane” allocations dynamically based on labels, resource properties, events and/or business changes in required Quality of Protection (QoP) and Quality of Service (QoS)



TVD BTVD A

Virtualization Virtualization

Virtualization Virtualization Virtualization

AApp

AApp

AApp

Virtualization

AApp

BApp

BApp

BApp

Communications are authenticated

and protected

BApp

SecurityPolicy for domain A

Strongisolation

TVD is virtual overlay of a trust domain on multiple platforms

SecurityPolicy for domain B



Basic Architecture of Trusted Virtual Domains

Container

PE

P C

PE

P A

PE

P B

Node

DomainPolicy

ContainerP

EP

D

PE

P A

PE

P B

Domain Controller(s)

Node

ChannelGateway(s)

Security Policy Management

Policy Enforcement Point – Enforces

Assurance Policies

Gateway – Enforces Flow Policies



Policy of a virtual domain could be defined as a collection of policies such as authentication, access control, and platform assurance – e.g., RADAC

Type Example

Ownership PEP is owned by a given party (e.g., COI A)

Information flow / access control

Confidential information must never leave the domain and be accessed only by users with appropriate authorization

Channel protection All the communication in the channel must be authenticated and encrypted by type 1 encryption

User authentication All users of the domain must be properly authenticated using biometric and CAC card

Monitoring / Auditing All security-critical operations in the domain must be recorded in an audit log

Platform assurance Platform OS and hypervisor must be at least EAL-4 certified and Software integrity of platform must be verified by TCG attestations

Third party trust Only a specific set of trusted third parties (e.g., DoD and UK PKI) can be used

Operational policy The platform must be operated by [name certification] certified operator



EDA, SOA, and TVD

Complex EventC2 System(RT SOA)

Key

Mgmt

ID

Mgmt

Provision

Mgmt

RegistryPolicy

MgrCOI

Mgmt

Remediation

Services

NAC

Mission Packages

Events / TOs

Virtualized

Nodes

Taxonomies

Secure Token

MissionServices(SOA)

HWRTHWRT

VLANs

Secure Token

Sensors Actuators

(RT)

Management Domain



Mission-integrated Autonomic Policy Manager

Mission Goals

SystemsGoals

GoalSynthesis &

Disambiguation

Requirements

Constraints Metrics

Mission

Process

and Flows

System Threads

Goal Reporting

State Monitor

Operations and Maintenance



Evolution of Strategy – 3-5 Years

MLS Service Gateway

(MLS Choreographer)

Org ADomain

Org BDomain

Org CDomain

PublicDomain

DataPrivacy

ChoreographyContentMgmt

On Demand Audit Infrastructure

TVD PolicyMgr

TVD PolicyMgr

TVD PolicyMgr

TVD PolicyMgrFederated

Query

Trusted Virtual Domain(“swim lanes”)

Services

ServicesServices

ServicesIntegrity Awareness Domain

(runtime)

Distributed Rights Management



Integrity awareness adds dynamic trust management capability ~ dynamic C&A?

– Virtualization, packet labels, and crypto provides swim lanes at application and network layers

– Services and data “live” on the network – not in enclaves– MAC (Mandatory Access Controls) provides mediation and

semantic services at trust broker hub for cross-domain discovery and choreography

– Integrity agents at each node – critical nodes also require anti-tamper and/or software protection

– Integrity policy manager maintains positive runtime controls over access to “swim lanes” dynamically based on on-demand integrity measures and attestations that are protected by hardware roots of trust (high robustness) and/or software agents (basic to medium robustness)



Integrity Measurement – Integrity & Attestation

Provide runtime integrity guarantees upon which to base trust

– Certificates provide static endpoint identity only (and secure communications SSL / IPSec)

– Does the system currently satisfy security-related requirements / QoPs?

Leverage HW Root of Trust for Measurement– Remotely attest system configuration

(software-stack measurement)– Detect cheating / compromise (load

guarantees)– Protect sensitive data (binding data)– Non-intrusive / negligible overhead

Core Root of Trust

OS Loader

OS

Applications

1

3

5

2

4

6

measureexecute



Industrial automation high level scenario: multilevel

Machine tool 1 Machine tool 2

Factory Automation system

Manufacturing Resource planner

Transport logistics

Materials warehousing

Enterprise ERP

Supply chain

Invoicing / billing

Individual hw / sw leaf Programmable Logic Controls ( components)

Print-verify-ship appl

RFID print

RFID read

package actuator

Sensors (on-sitestocks)

setup

Work routing



Nodal Stack (IBM) View

Hardware RTM

Virtualization Layer

System Services Layer

Application Layer

PEP

PolicyLayer

Data Layer

SecureBlue on PPC, Cell BE, TPM, ATPPC, CMOS, Crypto co-processor, Intel/AMD

Xen, pHype, PR/SM, MAC/DTEMLS AIX, MLS zOS, Trusted Linux, IMA

Virtualized services (e.g., Guards, Labelers, TPMs)

APM and Universal Access Classes

J2EE, WS*, TJVM / RT Java, TFIM, TAM,TIM, SOA Explorer, DataPower, CDI Hub

DB2 LBAC, MLS DB2 for zOS, II, CM SPARCLE; WIS, MDM, DataPower, EAS

Con

fiden

tialit

yInte

grit

y

Aut

onom

ics



CO

I Attach

Mgr

APP

SVR

MLS SC SCR Compute /CommDevice

MRPW/S

NW AttachMgr

NW AttachMgr

SHAREDSUPPLIER

CONTROLLED

SENSITIVESECRET

CO

I A

ttachM

gr

CO

I A

ttachM

gr

CO

I A

ttachM

gr

CO

I A

ttachM

gr

CO

I Attach

Mgr

CO

I A

ttachM

gr

CO

I A

ttachM

gr

CO

I Attach

Mgr

CO

I A

ttachM

gr

CO

I A

ttachM

gr

CO

I A

ttachM

gr

NW

A

ttachM

gr

NW

A

ttachM

gr

NW

A

ttachM

gr

NW

A

ttachM

gr

NW

Attach

Mgr

NW

A

ttachM

gr

RB

AC

RB

AC

APP

SVR

RB

AC

APP

SVR

APP

SVR

DATA SVR

DATA SVRDATA SVR

RB

AC

APP

SVR

RB

AC CO

I A

ttachM

gr

CO

I Attach

Mgr

CO

I A

ttachM

gr

DATA SVR

ENTERPRISEIT MGMT DOMAIN

Machine Tool1

CO

I Attach

Mgr

APP

SVRC

OI

AttachM

gr

RB

AC

DATA SVR

Machine tool2

COI AttachMgr

COI AttachMgr

NW/COI AttachMgr

NW AttachMgr

Inter -EnterpriseBlackCore

NW

/ C

OI

PolicyM

gr

Provision

Mgr

Integrity&

C

ompliance

Mgr

Key Mgr

Registry

Taxonom

yM

gr

NW

A

ttachM

gr

MRPDOMAIN

FACTORYDOMAIN

ERPDOMAIN

CO

I A

ttachM

gr

Operational Patterns For Information Sharing 17 May 2006 Chris Daly [email protected]

Documents