Connect981 – Content Dev

RSC Sphere: Data Integration, Security and Trust

The Data Integration, Security and Trust Sphere establishes the governance layer that makes everything else credible. It focuses on system interoperability, data mapping, version control, audit trails, and security alignment for regulated environments. The content makes clear how execution data can move safely across ERP, MES, QMS, PLM, and supplier systems without compromising control. This sphere proves that interoperability and security can coexist in aerospace ecosystems.

  • DMZ

    In industrial and manufacturing cybersecurity, a DMZ (demilitarized zone) is a logically separate network segment placed between two networks with different trust levels, most commonly between the corporate IT network and the industrial control system (ICS/OT) network.

    The DMZ is designed so that neither side can directly initiate unrestricted connections to the other. Instead, communication passes through controlled services hosted in the DMZ, such as application proxies, jump servers, data historians, or file transfer gateways. This limits the impact of a compromise on one side and reduces the attack surface of critical production systems.

    Key characteristics in manufacturing environments

    In regulated and industrial settings, a DMZ commonly:

    • Sits between the enterprise IT network and OT/ICS zones, often behind industrial firewalls.
    • Hosts intermediaries such as:
      • Data historians or replication nodes that receive OT data and publish it to IT systems.
      • Application gateways or APIs for MES/ERP integration with plant-floor systems.
      • Jump servers or remote access gateways used for vendor or maintenance access.
      • File transfer servers used for exchanging recipes, batch records, or reports.
    • Enforces strict, predefined traffic rules (for example, one-way data flows from OT to IT for monitoring).
    • Supports security zones and conduits concepts from standards such as IEC 62443, by acting as a controlled conduit between zones of differing criticality and trust.

    What a DMZ is and is not

    • Is: A network architecture pattern and dedicated segment used to isolate and broker traffic between networks with different risk profiles.
    • Is not: A single product or device. Firewalls, proxies, and servers can be components of a DMZ, but none of them alone is the DMZ.
    • Is not: A replacement for zoning within OT. Internal OT zones (for example, safety systems vs basic control vs monitoring) are still typically segmented separately, even if they connect via the DMZ to higher-level systems.

    Operational role

    Practically, a DMZ appears in workflows when:

    • Plant data needs to be shared with enterprise systems (MES, ERP, analytics) without exposing controllers and HMIs directly to the IT network or the internet.
    • Remote support or vendor access is required, but routed first through a controlled jump host and authentication layer.
    • Regulated environments need to demonstrate structured segmentation between business and control networks as part of risk management and alignment with cybersecurity frameworks.

    Common confusion

    • DMZ vs. firewall: A firewall is a device or function that enforces traffic rules. A DMZ is a network segment whose boundaries are typically enforced by one or more firewalls.
    • DMZ vs. OT zone: An OT security zone groups assets with similar security requirements inside the industrial network. A DMZ is usually a separate, intermediary zone between OT and IT, not a replacement for OT-internal zoning.
    • DMZ vs. VLAN: A VLAN is a Layer 2 segmentation mechanism. A DMZ is a higher-level security design concept. A DMZ may use one or more VLANs, but the terms are not interchangeable.

    Relation to IEC 62443 zoning

    Under IEC 62443 concepts, a DMZ is typically treated as its own security zone or set of zones with distinct security requirements. It functions as a controlled conduit between lower-level OT zones and higher-level IT or external zones, helping to isolate critical control assets while still enabling data exchange and integration.

  • Can a digital thread work if different sites use different MES platforms?

    Yes, a digital thread can work when different sites use different MES platforms. It should not depend on every plant running the same MES. It depends on whether the organization can maintain reliable traceability across systems, with common identifiers, agreed data definitions, controlled interfaces, validated mappings, and clear ownership for master data and evidence.

    The flawed assumption is that a digital thread requires one execution platform everywhere. In regulated brownfield environments, that is often unrealistic. Plants may have different qualified MES instances, legacy integrations, customer-specific processes, long-lived equipment, and local validation constraints. Forcing a full MES replacement across sites can create more risk than value because of qualification burden, validation cost, downtime exposure, integration complexity, and change control overhead.

    What has to be common

    The MES platforms can differ, but the business meaning of critical data cannot be left to local interpretation. At minimum, the organization usually needs a controlled approach for:

    • part, lot, batch, serial, work order, operation, tool, equipment, and personnel identifiers;
    • revision and effectivity rules from PLM or document control;
    • routing, operation, and inspection status definitions;
    • nonconformance, deviation, MRB, rework, and concession states;
    • time stamps, electronic signatures, approvals, and audit trail expectations;
    • links between ERP demand, MES execution, QMS events, PLM definitions, and maintenance or calibration records.

    If one site treats an operation as complete after operator confirmation and another treats it as complete only after inspection acceptance, the digital thread may appear connected while carrying inconsistent meaning. That is a common failure mode.

    Where different MES platforms create risk

    The main risk is not the number of MES products. The main risk is semantic mismatch. Different systems may use different data structures, status models, revision handling, attachment rules, or lot and serial granularity. Local customizations can make two instances of the same MES behave differently.

    Integration quality also matters. Point-to-point interfaces, manual uploads, spreadsheet bridges, and delayed batch transfers may be acceptable for some reporting use cases, but they are usually weak foundations for operational traceability. If evidence is moved or transformed, the organization needs to preserve provenance, timing, version context, and responsibility for the data.

    Validation is another boundary. Interfaces, data mappings, reports, and workflow changes may need to be tested and controlled according to the site’s quality system and regulatory expectations. A digital thread does not remove the need for local validation or documented change control.

    A practical architecture is usually federated

    In most mature brownfield programs, the digital thread is built as a federated model rather than a single monolithic replacement. PLM may remain the source for product definition and revision control. ERP may remain the source for orders, demand, and inventory accounting. MES remains the source for execution evidence. QMS remains the source for nonconformance, CAPA, deviations, and quality records. Maintenance or EAM systems may hold equipment status and calibration context.

    The digital thread connects those records through governed identifiers, integration services, APIs, event streams, data models, or controlled reporting layers. The exact architecture is site-specific. What matters is that the thread can explain where each data element came from, when it changed, which version was effective, and which system remains the system of record.

    When it will not work well

    A multi-MES digital thread is likely to struggle if master data is inconsistent, local process definitions are undocumented, interfaces are unvalidated, or sites do not follow common change control. It will also struggle if leadership expects analytics or enterprise traceability without resolving basic data ownership and lifecycle state definitions.

    It can work, but it is not a connector project alone. It is a governance, integration, validation, and operating model problem. Different MES platforms are manageable. Uncontrolled meaning is not.

  • industrial DMZ

    An industrial DMZ (demilitarized zone) is a dedicated network segment that separates operational technology (OT) systems, such as control systems and plant-floor networks, from corporate IT networks and external or cloud networks. It is designed to tightly control and monitor data flows between these environments, reducing the risk that threats from less-trusted networks reach critical industrial assets.

    Key characteristics

    An industrial DMZ commonly includes:

    • Network isolation: OT networks do not connect directly to IT or external networks. All traffic passes through the DMZ.
    • Controlled interfaces: Firewalls, proxy servers, VPN gateways, and application gateways enforce explicit rules for allowed traffic and protocols.
    • Hardened services: Shared services such as historians, jump hosts, patch servers, or terminal servers are placed in the DMZ to broker communication between OT and IT.
    • Monitoring and logging: Intrusion detection, logging, and other monitoring tools focus on the DMZ to detect suspicious activity at the boundary.

    Operational role in industrial environments

    In industrial and regulated manufacturing environments, an industrial DMZ commonly:

    • Separates plant-floor control networks (PLCs, DCS, SCADA) from enterprise systems (ERP, MES front-end, corporate IT)
    • Hosts intermediaries such as data historians or integration servers that replicate or buffer OT data for reporting or analytics
    • Acts as the termination point for remote access into OT, using jump hosts and strong authentication
    • Serves as a security zone when connecting OT systems to cloud services, with outbound, tightly controlled connections instead of direct plant-to-cloud links

    Standards and frameworks such as IEC 62443 commonly describe the industrial DMZ as a separate security zone between the enterprise network and the control network, but they typically do not mandate a single architecture. The exact implementation depends on the site risk assessment and system design.

    Common confusion

    • Industrial DMZ vs IT DMZ: An IT DMZ usually exposes public-facing services (for example, web servers) to the internet. An industrial DMZ focuses on protecting OT networks and brokering data between OT, IT, and cloud environments, often with more restrictive access and protocol control.
    • Industrial DMZ vs OT network zone: The OT network zone contains control and safety systems. The industrial DMZ is a separate, intermediate zone between OT and other networks, not the control network itself.

    Relation to cloud and external connections

    When OT data is exchanged with cloud services or external partners, an industrial DMZ is commonly used as the termination and control point for these connections. Cloud services are treated as external networks or zones, and the DMZ enforces segmentation, protocol filtering, authentication, and monitoring so that the OT network is not directly exposed.

  • Zone

    A zone is a defined area that is treated as a distinct unit because it shares specific characteristics, risks, or control requirements. In industrial and regulated manufacturing environments, zones are used to organize physical spaces, technical systems, or security boundaries so they can be managed and controlled consistently.

    Common types of zones in industrial and manufacturing contexts

    The term “zone” is used in several ways. The most relevant include:

    • Network or security zone: A logical segment of an IT or OT network with a defined security posture and access rules. For example, separating a plant-floor OT zone from a corporate IT zone, or creating a demilitarized zone (DMZ) for data exchange between MES and external partners.
    • Physical production zone: A specific area on the shop floor or in a facility that is grouped for operational control, layout, or safety. Examples include assembly zones, inspection zones, or packaging zones, each with defined equipment, workflows, and access rules.
    • Hazard or safety zone: An area designated based on exposure to hazards such as moving equipment, high voltage, or explosive atmospheres. These zones are used to define required protective measures, signage, and operating procedures.
    • Cleanliness or environmental control zone: A zone defined by air quality, cleanliness, or environmental conditions, such as cleanroom zones, temperature-controlled zones, or containment zones in regulated manufacturing.

    How zones are used operationally

    Zones appear throughout manufacturing systems and workflows:

    • In OT/IT architecture, zones group systems with similar security and reliability needs, supporting risk assessments, firewall policies, and controlled data flows between MES, SCADA, PLCs, and enterprise systems.
    • In MES and ERP, zones may be modeled as work centers, work areas, or locations to define where operations occur, where lots or batches can reside, and what resources are available.
    • In quality and compliance, zones define where specific procedures, gowning requirements, sampling plans, monitoring, or cleaning regimes apply, and where access must be restricted or logged.
    • In safety management, zones define where special training, PPE, or permits are required, and where interlocks, guards, or emergency systems are focused.

    What a zone is not

    • A zone is not inherently a single device or piece of equipment, although equipment resides within zones.
    • A zone is not necessarily a legal or regulatory designation, even when used to help meet regulatory expectations.
    • A zone is not the same as a cell or line, although those may be contained within a broader zone.

    Common confusion

    • Zone vs. cell/line: A production cell or line describes a specific sequence of machines or workstations. A zone is a broader concept and may contain multiple cells or lines, or be defined purely by safety or security criteria.
    • Zone vs. level: In models such as ISA-95/ISA-99, levels describe functional hierarchy (enterprise, site, area, cell). Zones typically describe security or control boundaries that may cut across or combine multiple levels.
    • Zone vs. area: In some plants, “area” is a formal construct in production modeling, while “zone” is used for security or environmental segmentation. The exact distinction is site-specific and should be clarified in site documentation.

  • Mapping table

    A mapping table is a structured list that shows how one set of values, fields, identifiers, or codes corresponds to another set. In manufacturing and enterprise systems, it commonly refers to configuration or reference data used to translate information between applications, data models, or process steps.

    A mapping table can be as simple as linking an ERP item code to an MES material identifier, or as detailed as converting defect codes, unit-of-measure values, work center names, status codes, or supplier IDs across systems. It is used to support consistent data exchange, reporting, and system interoperability.

    What it includes

    • Field-to-field relationships between systems

    • Code translations, such as status, reason, defect, or location codes

    • Value normalization rules, such as standard names or approved abbreviations

    • Cross-reference records used in integrations, migrations, or reporting layers

    What it does not mean

    A mapping table is not the same thing as the integration logic itself. It usually holds the reference relationships that the integration, ETL process, middleware, MES, ERP, or analytics layer uses. It is also not necessarily a full data model, master data record, or transaction history.

    Operational meaning in manufacturing systems

    In regulated and multi-system environments, mapping tables often appear wherever data must stay aligned across MES, ERP, PLM, QMS, LIMS, or warehouse systems. Examples include mapping part revisions between PLM and ERP, associating shop-floor equipment IDs with enterprise asset records, or translating nonconformance codes into reporting categories.

    Because mapping tables influence how records are interpreted, they are often treated as controlled configuration data. Changes to them can affect traceability, reporting consistency, interface behavior, and downstream business rules.

    Common confusion

    Mapping tables are commonly confused with lookup tables, crosswalks, and master data:

    • Lookup table: usually provides allowed values or descriptive labels within one system.

    • Crosswalk: often means a direct correspondence list between two coding schemes and may be used as a synonym for mapping table.

    • Master data: is the authoritative business data itself, while a mapping table links or translates between representations of that data.

  • Threat actor

    A threat actor is any individual, group, or system that carries out, attempts to carry out, or significantly enables actions that can harm an organization’s assets, data, or operations. In industrial and manufacturing environments, this typically refers to entities that pose cybersecurity, operational, or information security risks to OT and IT systems.

    Scope of the term

    In the context of manufacturing and industrial operations, a threat actor commonly includes:

    • External attackers such as criminal groups, hacktivists, or state-aligned groups targeting production, OT networks, or intellectual property.
    • Insiders such as employees, contractors, or partners who misuse access intentionally (malicious insiders) or accidentally (negligent insiders).
    • Supply chain–related actors such as compromised vendors, integrators, or service providers whose systems or credentials are used as a path into plant systems.
    • Automated systems under an actor’s control, for example botnets, scripts, or malware components that execute the attack activities.

    The focus is on the entity taking the action, not the vulnerability or the consequence. A threat actor may exploit vulnerabilities in MES, ERP, SCADA, PLCs, quality systems, or network infrastructure to disrupt production, corrupt data, or exfiltrate sensitive information.

    What a threat actor is not

    • It is not the same as a threat, which is a potential cause of an unwanted incident (for example, ransomware, phishing, or equipment sabotage).
    • It is not the same as a vulnerability, which is a weakness in a system, process, or control.
    • It is not limited to cyber specialists; anyone with the intent and capability to cause harm, including physical tampering with OT equipment, can be a threat actor.

    Operational relevance in manufacturing

    Identifying and characterizing threat actors is part of risk assessment and cybersecurity planning for industrial environments. Practitioners often:

    • Classify threat actors by motivation (financial gain, espionage, sabotage, activism, curiosity).
    • Assess their capabilities (access to tools, OT knowledge, ability to move between IT and OT networks).
    • Relate them to specific attack scenarios, such as altering process parameters, disabling safety systems, manipulating quality data, or disrupting MES/ERP integrations.

    This classification supports decisions on monitoring, access control, incident response workflows, and coordination between IT security, OT engineers, and quality/compliance teams.

    Common confusion

    • Threat vs. threat actor: A threat is the potential event (for example, a ransomware infection on an MES server). The threat actor is the person or group using ransomware to carry out the attack.
    • Risk vs. threat actor: Risk is typically expressed as the combination of likelihood and impact of a threat scenario. The threat actor is one element influencing the likelihood side of that risk.

    Use in regulated and industrial contexts

    In regulated manufacturing environments, the concept of a threat actor is frequently used in:

    • Cybersecurity risk assessments for OT networks, data historians, and MES/ERP integrations.
    • Incident investigation and root cause analysis, where part of the analysis is determining whether a human or automated threat actor was involved.
    • Access management and vendor oversight, where external partners, system integrators, and remote support providers are evaluated as potential threat actors or exposure paths.

    Using the term consistently helps distinguish who is acting (the actor), what method they use (the threat or attack vector), and where they succeed (the vulnerability exploited) when documenting and managing industrial cybersecurity and operational risks.

  • Information Asset

    An information asset is any collection of data, document, system, or technology resource that has value to an organization and therefore needs to be identified, managed, and protected. In industrial and regulated manufacturing environments, information assets include both digital and physical records that support operations, quality, safety, and compliance.

    What an information asset includes

    In manufacturing and industrial operations, information assets commonly include:

    • Production data, such as batch records, machine parameters, and process histories
    • Quality and compliance documentation, including nonconformance reports, CAPA records, and audit trails
    • Engineering and technical information, such as drawings, specifications, PLC logic, and recipes
    • Systems and databases, for example MES, historian databases, ERP master data, and LIMS data sets
    • Standard operating procedures, work instructions, and training records
    • Supplier and customer data, including material certificates and delivery records
    • Cyber-physical information, such as OT network configurations, access control lists, and system logs

    The term can apply to both structured information (databases, configuration files, log records) and unstructured information (PDF procedures, email threads with deviation approvals, scanned paper records).

    What an information asset is not

    An information asset is not just any piece of data. It typically:

    • Has identifiable business, operational, safety, or compliance value
    • Has an owner or custodian responsible for it
    • Requires control over accuracy, access, retention, and, in some cases, confidentiality

    For example, transient sensor noise that is never stored or used would not usually be treated as an information asset, while archived sensor trends used for investigations and optimization normally would be.

    Operational meaning in manufacturing

    In practice, classifying something as an information asset means it is brought under formal governance. Typical activities include:

    • Cataloging the asset in an information or asset register, including owner, location, and criticality
    • Defining access control rules, backup and restore needs, and change control requirements
    • Applying document control or data integrity practices, such as version control and audit trails
    • Assigning retention and disposition rules aligned with regulatory and business needs
    • Including the asset in risk assessments for cybersecurity, data integrity, and business continuity

    For OT and IT systems like MES, SCADA, historians, and ERP, the system itself and the data it stores are often treated as separate, but related, information assets.

    Relationship to risk and compliance

    Many information security and data governance frameworks expect organizations to identify and classify information assets before they can manage risks effectively. In regulated manufacturing, this often includes:

    • Identifying which assets contain regulated records, such as electronic batch records or device history records
    • Classifying criticality for safety, product quality, and regulatory reporting
    • Defining controls for data integrity, including traceability, completeness, and accuracy
    • Flagging assets that contain export-controlled or confidential technical data

    Common confusion

    • Information asset vs. physical asset: A physical asset is a tangible resource such as a machine, robot, or building. An information asset is the data and information associated with these resources, such as maintenance histories, calibration records, or control programs.
    • Information asset vs. record: A record is a specific type of information that provides evidence of an activity or decision. An information asset can be broader and may include records, reference data, configuration data, and working documents.
    • Information asset vs. data: Not all raw data is treated as an asset. An information asset usually represents data that has recognized value, context, and management responsibilities.