Operational Patterns For Information Sharing 17 May 2006 Chris Daly rcdaly@us.ibm

1. Operational Patterns For Information Sharing17 May 2006Chris Dalyrcdaly@us.ibm.com

2. 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

3. 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).

4. 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

5. 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 processbased 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

6. Trust Associations Must Consider Multiple Horizontal and Vertical “Bindings” Trusted Third Party / Gateway • Trusted semantic interpretation / transformation • Trusted Identity assertion • Integrity / pedigree of data • Confidentiality of data • Throughput Transactional Context (Purpose) Node A Node B Infrastructure Infrastructure Personnel Process Information Object Information Object Process Personnel Organization (Policy) Organization (Policy)

7. 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

8. 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?

9. 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)

10. E2E Net-centric Information Sharing Must Consider QoS and QoP Differences Among the Layers (Domains) of Processing Non-RT Events (ERP) SOA Workflow Mission Data Mining QoS – Low - Med QoP – High - Med Situational Awareness (MRP) RT SOA Collaboration Course of Action Common Operational Picture QoS – Med QoP – Med - Low RT Events (Factory) RT EDA Sensing / Tracking Actuating Event Fusion QoS – High QoP – Med - Low

11. Event Driven Architectures and RT SOA pose unique trust challenges that must be considered 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. Non-real time Logistics seconds Command & Control milliseconds Tracking microseconds Radar Weapon

12. C2 systems must be integrated into an open loop, end-to-end workflow / decision-making process – not just the information sharing process Intelligence Analyst Orient Analyze Observe History/ Discernment Pacts Beliefs Collect Assets Reduct Tool Data Policy Position Trust Level Emotion Choice Range Cognitive gap Stipulate Act Decide Decision-maker

13. High External Sources (Sensors) High Policy Sources High Actuator Cascading control info Low External Sources (Sensors) Intelligence Analyst Intelligence Analyst Low Policy Sources Fits model, it’s right Fits model, it’s right Doesn’t fit model, it’s right Doesn’t fit model, it’s right Have it, Know I have it Have it, Know I have it Don’t have, Know I don’t have Don’t have, Know I don’t have Think it’s true, It’s true Think it’s true, It’s true Think it’s false, It’s true Think it’s false, It’s true Fits model, it’s wrong Fits model, it’s wrong Doesn’t fit model, it’s wrong Doesn’t fit model, it’s wrong Think it’s true, It’s false Think it’s true, It’s false Think it’s false, it’s false Think it’s false, it’s false Have it, Don’t know I have it Have it, Don’t know I have it Don’t have, Think I have it Don’t have, Think I have it History/ Discernment History/ Discernment Orient Orient Analyze Analyze Observe Observe Pacts Pacts Beliefs Beliefs Collect Assets Collect Assets Reduct Tool Reduct Tool Data Data Policy Policy Position Position Trust Level Trust Level Emotion Emotion Choice Range Choice Range Cognitive gap Cognitive gap Stipulate Stipulate Act Act Decide Decide High reliance, clear terms High reliance, clear terms High reliance, unclear terms High reliance, unclear terms Message is clear, Msg enables Message is clear, Msg enables Msg is clear, Msg doesn’t enable Msg is clear, Msg doesn’t enable It’s fair, I accept It’s fair, I accept It’s unfair, I accept It’s unfair, I accept Low Actuator Msg is ambiguous, Msg enables Msg is ambiguous, Msg enables Msg is ambiguous, Msg doesn’t enable Msg is ambiguous, Msg doesn’t enable Low reliance, clear terms Low reliance, clear terms Low reliance, unclear terms Low reliance, unclear terms It’s fair, I reject It’s fair, I reject It’s unfair, I reject It’s unfair, I reject Decision-maker Decision-maker Cascading control and sensor info causes latency in current MSL architectures, resulting in unsynchronized actions between levels

14. Globalization is also increasing concerns about the integrity of net-centric environments and their respective development environments Org A Code production process A D S Data collection process CI A D S Sensor A D S Grid CI User A D S A D S CI Identity proofing process HW production process A D S Org B

15. 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

16. 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

17. 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 Cross-Domain Information Sharing Technology Enablers

18. 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

19. Key IA Challenges for Cross-Domain Information Sharing Multi-functional Guards / Identity Federation Label-enforcement mechanisms / Labeled Objects Key Mgmt / Distribution / Keystores Crypto MLS MSL $ $ $ COTS COTS Assurance Mountains

20. 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

21. 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

22. Elements of Cross-Domain Information Sharing Patterns Infrastructure Management Risk Management Mission Management Open Standards Autonomic Policy Strategic Intent / BPEL Componentization / Common Event Infrastructure Composability of Assured Elements Choreography / Simulation / Complex Event Processing Interoperability / Performance Classification / Labeling Metadata / Semantic Design Virtualization / Multi-Core Confidentiality / Integrity / Anti-Tamper Digital ID Mgmt Java / Web Services Tooling, Usability, SE Processes, and Services Common Operational Picture Controlled Information Sharing Orchestrated Response

23. 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

24. 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

25. Cross-domain information sharing patterns

26. Distributed Enclave Pattern Security Tier (RBAC/PKI/Directory) Client Tier Data Tier Application Tier TS S U

27. 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)

28. Federated Enclave Pattern Security Tier (Federated IM/PKI/Directory) Client Tier Data Tier Application Tier TS S U

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

30. Shared Space Pattern Security Tier (RBAC/PKI/Directory) Client Tier Data Tier Application Tier TS S U

31. 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

32. Dynamic COI Pattern Security Tier (MAC/RuBAC/PKI/Directory) Client Tier Data Tier Application Tier TS S U Access mediated thru MLS policy managers, hardware TCB, and labels

33. 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

34. CBIS Pattern Security Tier (RBAC/PKI/Directory) Client Tier Data Tier Application Tier TS S U Data and applications bound thru crypto and digital signatures

35. 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.

36. Pervasive / Embedded Systems Pattern Security Tier (MAC/RuBAC/ PKI/KMI/Directory/Provisioning) Client Tier Collaboration T-Space Integrity-based Reputation systems controlled interfaces And multi-core crypto for P2P collaboration Out-of-band Trust Sometimes Connected

37. 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

38. Architecture Evolution for E2E Information Sharing – Distributed Enclaves with a Shared Space Public Domain Org A Domain Info Integration DAC/RBAC PEP System High DAC Policy Mgr Data Privacy MLS Shared Space Directory Integration DAC/RBAC PEP System High Content Mgmt DAC/RBAC PEP System High Org C Domain Org B Domain

39. 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)

40. Evolution of Strategy – 2- 3 years Labeled and Cryptographically Protected Collaboration within TVD Privacy controls over data, And anonymized data and users Org A Domain Public Domain Trusted Virtual Domain (“swim lanes”) TVD Policy Mgr Info Integration Data Privacy TVD Policy Mgr MLS Shared Space Risk-adaptive access policies MAC/DAC Policy-enforced Domain attachment points Content Mgmt Directory Integration TVD Policy Mgr TVD Policy Mgr Org B Domain Universal Access Classes Org C Domain Unified and Merged Secrecy Lattices Federated user access from single domain to virtual domain and within organizational domains

41. 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)

42. App App App App App App App App B B B A A A B A TVD is virtual overlay of a trust domain on multiple platforms Security Policy for domain B Security Policy for domain A Strong isolation Communications are authenticated and protected Virtualization Virtualization Virtualization Virtualization Virtualization Virtualization TVD A TVD B

43. PEP C PEP A PEP B Container Security Policy Management Basic Architecture of Trusted Virtual Domains Gateway – Enforces Flow Policies Domain Controller(s) Domain Policy Channel Gateway(s) Policy Enforcement Point – Enforces Assurance Policies PEP D PEP A PEP B Container Node Node

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

45. Management Domain EDA, SOA, and TVD NAC Remediation Services Taxonomies Complex Event C2 System (RT SOA) Key Mgmt Mission Packages Events / TOs Provision Mgmt ID Mgmt Mission Services (SOA) Sensors Actuators (RT) Policy Mgr COI Mgmt Registry VLANs Virtualized Nodes Secure Token HWRT HWRT Secure Token

46. Mission-integrated Autonomic Policy Manager Goal Synthesis & Disambiguation Mission Goals Systems Goals Requirements Constraints Metrics Mission Process and Flows System Threads State Monitor Goal Reporting Operations and Maintenance

47. Evolution of Strategy – 3-5 Years Services Services Integrity Awareness Domain (runtime) Org A Domain Public Domain Trusted Virtual Domain (“swim lanes”) TVD Policy Mgr Federated Query Data Privacy TVD Policy Mgr MLS Service Gateway (MLS Choreographer) Content Mgmt Choreography TVD Policy Mgr TVD Policy Mgr Org B Domain Org C Domain On Demand Audit Infrastructure Services Services Distributed Rights Management

48. 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)

49. execute measure Applications 6 5 OS 4 3 OS Loader 2 1 Core Root of Trust 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

50. Industrial automation high level scenario: multilevel Enterprise ERP Invoicing / billing Manufacturing Resource planner Supply chain Transport logistics Factory Automation system Materials warehousing Work routing setup Machine tool 2 Machine tool 1 Print-verify-ship appl Sensors (on-site stocks) RFID print package actuator RFID read Individual hw / sw leaf Programmable Logic Controls ( components)