The Simple Cyber Governance Program OT security policy template

This material contains proprietary information and is copyrighted by Langner, Inc. Using the content of this document in production environments, in the process of planning or designing operations technology systems and architectures, in product development or any other commercial activity requires a commercial SCGP license. A commercial SCGP license may also allow you to modify SCGP documents and share them individually, apart from the full SCGP document set. You can also download a full copy of the Simple Cyber Governance Program documents in PDF format for a thorough evaluation.

Copyrighted Material

© 2018 Langner, Inc.

Using the content of this document in production environments, in the process of planning or designing operations technology systems and architectures, in product development or any other commercial activity requires a commercial SCGP license.

Content

0      Introduction

0.1       Scope and Intended Audience

0.2       Understanding User Roles, Policies, and SOPs

0.3      The SCGP Policy Philosophy

0.4       Revision Notes

1      External Engineers (Contractors)

1.1       Using Computer Systems

1.2       Using Mobile Systems that Enter and Leave the Facility (Nomad Laptops)

1.3       BYODs (Smartphones, Tablet Computers, MP3 Players etc.)

1.4       Using Networks

1.5       Using Mobile Media

1.6       Exchanging Files

1.7       Using Remote Access

1.8       Configuration Change Management Procedure

2      Operations Technology Users

2.1       Using Computer Systems

2.2       Using Mobile Media and Mobile Systems

2.3       Using the Internet and Email

2.4       Exchanging Files

3      Engineering and System/Network Administration

3.1       Using Computer Systems

3.2       Using Mobile Systems not Leaving the Facility (Resident Laptops)

3.3       Using Mobile Systems Entering and Leaving the Facility (Nomad Laptops)

3.4       Using Networks

3.5       Using Mobile Media

3.6       Exchanging Files

3.7       Maintaining Endpoint Security

3.8       Maintaining Network Security

3.9       Firewall Rule Set Update Procedure

3.10     Generic Configuration Change Management Procedure

4      OT Planning and Sytem Design

4.1       Exchanging Files

4.2       Planning Design and Configuration Change Procedure

4.3       System Acquisition Procedure

5      Visitors

5.1       Using Computer Systems and Networks

5.2       Using the Internet and Email

5.3       Exchanging Files

6      Using the OT-BASE Asset Management System for Policy Audits

6.1       Registration of Nomad Laptops

6.2       Monitoring Data Flow

6.3       Auditing Software Configuration

6.4       Change Management Workflow

0    Introduction

0.1        Scope and Intended Audience

This document specifies the cyber security policies and standard operating procedures (SOPs) that govern the interaction with Operations Technology (OT). It complements the SCGP Reference Architecture module which sets forth rules for robust and secure design and configuration of cyber systems in facilities subject to the SCGP process. Policies and SOPs govern activities of people interacting with OT, such as how to log off from Human Machine Interface (HMI) terminals or how to use USB sticks, whereas design and configuration rules govern the digital characteristics of artifacts (such as networks or computer software). Every individual interacting with Operations Technology, including contractors, regardless of specific roles, is subject to policies and/or SOPs listed in this document.

0.2        Understanding User Roles, Policies, and SOPs

The organizing principle of policies and SOPs within SCGP is in respect to typical user roles, affected OT components (targets), and use cases that can be found in virtually every OT environment.

  • User roles are specified in detail in the SCGP Workforce Management module
  • Targets may be specific system groups, networks, or media
  • Use cases may be typical activities like exchanging files or using email.

Within SCGP, the terms policy and SOP are differentiated as follows:

  • A policy states activities that are either mandatory or prohibited. For example, a policy may specify that mobile media must not be used with certain OT systems or networks.
  • A standard operating procedure is a step-by-step, checklist-like guideline on how to complete a specific task or use case. For example, a standard operating procedure may specify exactly how to perform backups for certain systems.

0.3        The SCGP Policy Philosophy

The philosophy for defining policies and SOPs is based on the following criteria:

  • Policies and SOPs must be as brief as possible, ideally allowing for memorization
  • Policies and SOPs must be as practical as possible, structuring and simplifying the addressee’s assigned work tasks rather than interfering with them
  • Policies and SOPs must be fully comprehensible by their intended target audience
  • Policies and SOPs must be teachable (if you can’t teach the target audience about it, it’s flawed)
  • Policies and SOPs must be auditable, and audited on a regular basis (annually)
  • Compliance to policies and SOPs must be expressible in metrics, based on audits (see the SCGP Capability Metrics module)

0.4        Revision Notes

0.4.1        Changes from RIPE-17 to SCGP-18

Changed product name to SCGP

Changed copyright details

Added a chapter on using the OT-BASE Asset Management Platform for policy enforcement

0.4.2        Changes from RIPE-16 to RIPE-17

Added reference marks (↗) for terms that are listed in the RIPE Terminology and Concepts document

Deleted provision 1.6.4 (file exchange via the myRIPE portal)

Extended configuration change procedure 1.8

Extended configuration change procedure 3.10

0.4.3        Changes from RIPE-15 to RIPE-16

Minor changes in section 0.3

Replaced Central Cyber Security Entity with OT Support Center

Appended policy provision 1.1.3 to specify “leaving a workstation”

Modified policy provision 1.2.2 on nomad laptops to apply to non-critical OT systems and networks.

Added new policy provision 1.2.3 for critical OT systems and networks.

Deleted policy provision on passwords for nomad laptops (previously 1.2.5) because it cannot be verified

Tightened policy provision 1.7.2 to specify the responsible entity (operator or OTSC)

Re-arranged engineering and system/network administration policies to better match the order of the corresponding training modules (moved sections 3.4 and 3.5 up)

Introduced the concept of ↗Controlled Software to policy provision 3.7.1

Deleted policy provisions 3.8.2, 3.8.3 and 3.8.5 because they reflect configuration guidance and are covered in the RIPE Reference Architecture guideline

Introduced the concept of ↗Controlled Software to policy provision 3.9.1

Changed the language of policy provision 4.3.2 to remove mandatory execution of interactive training (“classes”)

Replaced compliance in policy provision 4.3.3 with conformity

Added the requirement to check a visitor’s USB stick for known malware in policy provision 5.3.1

Textual improvements throughout the document, not affecting content

1    External Engineers (Contractors)

This chapter lists policies and standard operating procedures for contractors performing engineering tasks on systems within control networks.

1.1        Using Computer Systems

1.1.1       If dedicated workstations for contractors are provided by the asset owner, such workstations must be used and attaching mobile systems to control networks is not permitted.

1.1.2       System access credentials, such as user names and passwords, – must not be on display at the workplace – must not be stored in clear text files – must never be shared with others.

1.1.3       When leaving a workstation out of sight, logging off is mandatory if supported by the system.

1.1.4       System use is limited to the tasks contractually specified. Using the asset owner’s Computer systems for other purposes is not permitted.

1.1.5       No configuration changes of functionality used to detect and prevent unauthorized software, such as anti-virus, ↗whitelisting, or host-based intrusion detection are permitted. If such functionality presents a problem for executing contractually required tasks, the OT Support Center must be contacted.

1.1.6       Deletion, modification, or copying of files not in the responsibility of the contractor is prohibited.

1.2        Using Mobile Systems that Enter and Leave the Facility (Nomad Laptops)

1.2.1       Nomad laptops must be registered with the OT Support Center. Registration is required only once per contractual period and ends automatically with the contract term.

1.2.2       Nomad laptops that are intended to be connected to non-critical control systems and networks must be authorized by the OT Support Center if such authorization is not already part of the contract. Authorization must be renewed annually and ends automatically with the contract term.

1.2.3       Nomad laptops that are intended to be connected to critical control systems and networks must be authorized by the OT Support Center on a case basis. Authorization ends automatically when the laptop is removed from the controlled area of the facility.

1.2.4       If attaching nomad laptops to control systems or networks is permitted, such laptops must conform to the configuration specified in the SCGP Reference Architecture module for mobile engineering systems. The ↗OTSC is entitled to verify that a nomad system meets these specifications.

1.2.5       Nomad laptops attached to control networks are subject to automated network scanning.

1.2.6       If dedicated network access ports are available for contractors, such ports must be used to connect to control systems and networks.

1.2.7       Nomad laptops connected to control networks must not simultaneously be connected to the Internet, e.g. via UMTS, LTE, or CDMA.

1.2.8       When not in use for more than four hours, nomad engineering systems are kept in areas with physical access control and can only be accessed by authorized personnel. This extends to off-site storage.

1.2.9       When connected to control systems or networks, use of nomad laptops is limited to the tasks contractually specified.

1.3        BYODs (Smartphones, Tablet Computers, MP3 Players etc.)

1.3.1       Smartphones, tablet computers, MP3 players or other electronic devices must not be connected to ICS or control networks (e.g. via USB interface or Bluetooth), not even for the purpose of battery recharging.

1.4        Using Networks

1.4.1       Network use is restricted to the tasks contractually specified. Using the asset owner’s networks for other purposes is not permitted.

1.4.2       Specifically, accessing systems on the network other than what is required for the tasks contractually specified is not permitted. The asset owner is entitled to monitor and/or log network traffic.

1.4.3       Network ↗sniffing and scanning is only permitted if specifically authorized by the OT Support Center.

1.4.4       Internet and email access is only permitted via dedicated systems that have been designated for such purpose by the ↗OTSC.

1.4.5       Access to the Internet and email via personal smartphones, tablet computers, MP3 players or other electronic devices (BYODs) may be permitted, but such devices must not be connected to control systems or networks.

1.5        Using Mobile Media

1.5.1       Only company mobile media (such as USB thumb drives or CDs) that is clearly marked as such must be used with control systems, and only if required by the contractually agreed upon tasks. The use of Non-Staff mobile media is forbidden.

1.5.2       Mobile media (such as USB thumb drives or CDs) must only be inserted into a dedicated workstation, and only if required for the contractually specified tasks, and only if the medium has previously been checked for known malware by using a dedicated clearing station.

1.5.3       Mobile media intended to remain in the facility are labeled with company name, date and time, and content/purpose.

1.6        Exchanging Files

1.6.1       All files shared with the asset owner (either by passing to a staff member electronically or by copying on systems of the asset owner) must previously have been checked for known malware.

1.6.2       By sharing files with the asset owner the originator indicates to possess the required copyright and any other permission that may be required. Files for which this cannot be guaranteed must not be shared.

1.6.3       Files received from the asset owner must be treated in respect to all governing non-disclosure agreements and information security classifications. As a general rule, such files must not be shared with others until explicitly permitted by Organization.

1.7        Using Remote Access

1.7.1       Only approved procedures must be used for remote access that have been specifically authorized by the asset owner.

1.7.2       Remote access must be announced to and approved by either the operator responsible for the affected systems or the ↗OTSC. The announcement must include the identity of the individual(s) accessing remote systems.

1.7.3       Remote access must only be performed by approved individuals and systems specifically authorized by the ↗OTSC. Logical access control is applied to ensure that unauthorized users cannot access applications used for remote access.

1.7.4       Only systems may be accessed where such access is required to perform the tasks agreed upon by contract.

1.7.5       Users of remote access options give their consent that online traffic is monitored and logged by the asset owner.

1.8        Configuration Change Management Procedure

Before performing configuration change:

1.8.1       Plan the configuration change and document the plan

1.8.2       Check any rules from the SCGP Reference Architecture module that apply to the system or network to be changed.

1.8.3       Approve the change or ask for approval if necessary.

1.8.4       Ensure that the present configuration of the system to be changed is properly backed up.

1.8.5       If the configuration change involves copying of files to the system to be changed, check all files for known malware before copying. If malware is found, discontinue the change project and inform the OT Support Center.

1.8.6       Change the configuration.

After performing configuration change:

1.8.7       Test the system with the new configuration.

1.8.8       If the system does not function properly with the new configuration, escalate to have the conflict resolved.

1.8.9       Remove/restore all accounts, files, firewall rules etc. used/disabled for testing and diagnostics.

1.8.10    Save the new configuration to a backup medium and/or version control server (if applicable).

1.8.11    Perform the administrative tasks required for assurance of system integrity, such as calculating and storing new hash values.

1.8.12    Document configuration changes in the System Inventory, Network Diagrams, and Data Flow Diagrams (if appropriate).

1.8.13    Record the change project.

2    Operations Technology Users

This chapter lists policies and standard operating procedures for staff members using operations technology such as SCADA/DCS, quality management, historians, etc. It may also affect Non-Staff personnel if operations are conducted by a Non-Staff service provider.

2.1        Using Computer Systems

2.1.1       System access credentials, such as user names and passwords, – must not be on display at the workplace – must not be stored in clear text files – must never be shared with others, except face to face with fellow shift workers if shared accounts are used.

2.1.2       Any means for the detection and prevention of unauthorized software, such as anti-virus or ↗whitelisting, must not be disabled or circumvented.

2.1.3       Any system or network configuration changes are prohibited.

2.1.4       Accessing the operating system is prohibited unless explicitly permitted by the OT Support Center.

2.2        Using Mobile Media and Mobile Systems

2.2.1       Mobile media such as USB thumb drives, CDs, or DVDs, must not be used with systems in control networks. 2.2.2       Mobile systems, such as smart phones, MP3 players, or laptop computers, must not be attached to systems in control networks, or attached to control networks.

2.3        Using the Internet and Email

2.3.1       Internet and email access is permitted only from designated and marked workstations not connected to a control network.

2.4        Exchanging Files

2.4.1       Transfer of files to and from control networks is only permitted via the dedicated transfer route specified by the OT Support Center.

2.4.2       The use of shared network folders is not permitted for sharing files.

2.4.3       No files, whether obtained from staff members or non-staff individuals, or self-produced, must be copied to systems connected to control networks if not explicitly authorized by the OT Support Center.

2.4.4       Before sharing files with non-staff individuals it must be ensured that no copyright rules are violated, appropriate security clearances or non-disclosure agreements exist, and appropriate classification marks are attached to media and accompanying documentation.

3    Engineering and System/Network Administration

This chapter lists policies and standard operating procedures that affect control system engineers, electrical engineers and system and network administrators entitled to configure systems in control networks. It may also affect staff members from the IT department or network department if they are responsible for IT and network security within control networks. Even non-staff individuals may be affected in cases where system and network security is outsourced.

3.1        Using Computer Systems

3.1.1       System access credentials, such as user names and passwords, – must not be on display at the workplace – must not be stored in clear text files – must never be shared with others, except face to face with fellow shift workers if shared accounts are used.

3.1.2       Passwords for engineering systems and mobile systems must be changed at least every three months and, when supported by the system, comply with strong password standards.

3.1.3       Any means for the detection and prevention of unauthorized software, such as anti-virus or ↗whitelisting, must only be disabled or circumvented if checked with the OT Support Center.

3.1.4       System configuration changes must comply with the SCGP Reference Architecture standards and follow the respective standard operating procedure for change management.

3.2        Using Mobile Systems not Leaving the Facility (Resident Laptops)

3.2.1       Mobile computer systems attached to control networks must meet the specification of mobile engineering systems as specified in the SCGP Reference Architecture module.

3.3        Using Mobile Systems Entering and Leaving the Facility (Nomad Laptops)

3.3.1       Nomad laptops must be registered with the OT Support Center.

3.3.2       Nomad laptops that are intended to be connected to control networks must be authorized by the OT Support Center. Authorization must be renewed annually.

3.3.3       If attaching nomad laptops to control systems or networks is permitted, such systems must conform to the configuration specified in the SCGP Reference Architecture module for mobile engineering systems.

3.3.4       Passwords for nomad systems must be changed at least every month and, when supported by the system, comply with strong password standards.

3.3.5       Nomad systems connected to control networks must not be connected simultaneously to the Internet, e.g. via UMTS, LTE, or CDMA.

3.3.6       When not in use for more than four hours, nomad engineering systems are kept in areas with physical access control and can only be accessed by authorized personnel. This extends to off-site storage.

3.4        Using Networks

3.4.1       Network access to control networks is only permitted for operational and maintenance purposes approved by the OT Support Center.

3.4.2       Changes to network configuration, including changes of network architecture, changes of network device configuration, connecting or disconnecting systems to or from the network, must follow the rules specified in the SCGP Reference Architecture module.

3.4.3       Monitoring of network traffic is subject to permission of the OT Support Center.

3.4.4       Active network scanning of control networks is subject to permission of the OT Support Center.

3.5        Using Mobile Media

3.5.1       Mobile media must only be used for company purposes. Private media and private files must not be used with systems in control networks.

3.5.2       Non-Staff mobile media must never be used with systems in control networks.

3.5.3       Mobile media must only be used if the medium has previously been checked for known malware by using a dedicated cleaning station.

3.6        Exchanging Files

3.6.1       Before sharing files with others it must be ensured that no copyright rules are violated, appropriate security clearances or non-disclosure agreements exist, and appropriate classification marks are attached to media and accompanying documentation.

3.6.2       The use of shared network folders is not permitted for sharing files.

3.6.3       Files intended for sharing with systems residing in the office network or in remote networks are only transferred via the dedicated transfer route.

3.6.4       Staff members must use company media to pass documents to visitors in case such document transfer is required for the visitor to perform designated and authorized tasks.

3.7        Maintaining Endpoint Security

3.7.1       The OT Support Center maintains a list of authorized applications for every computer system (↗Controlled Software).

3.7.2       ↗Whitelisted computer systems subject to configuration change (and therefore subject to whitelist update) are disconnected from the control network before performing configuration change. After performing configuration change, the system is checked for known malware by running anti-virus software from a live CD or USB stick. A new whitelist is produced only after such malware scan didn’t produce positive hits.

3.7.3       If a ↗whitelisting solution blocks the execution of authorized software, thereby indicating compromise, the software in question is not permitted to execute manually. Instead, the OT Support Center is notified and a cyber security incident process is started.

3.7.4       Operations Technology servers are backed up on a daily basis. The integrity of backups is checked at least once per month.

3.7.5       When not in use, mobile engineering systems are kept in areas with physical access control and can only be accessed by authorized personnel.

3.8        Maintaining Network Security

3.8.1       For every network filtering device, the OT Support Center produces documentation describing authorized network connectivity, along with a description of purpose and functionality.

3.8.2       Any changes to the configuration of network equipment must be authorized by the OT Support Center.

3.8.3       Faulty network filtering devices are replaced as soon as possible, but no later than within one day. The replacement unit is configured with the saved configuration of the failed device.

3.8.4       In emergency situations such as the outbreak of malware the uplink network connections of devices that are labeled appropriately may be disconnected.

3.8.5       Wireless access points that are not permanently required are switched off during times of inactivity, e.g. by using a timer.

3.8.6       Remote access is technically enabled only for specific authorized non-staff individuals and only for the duration required to perform authorized diagnostic and maintenance tasks. Preventive activation of remote access points, for example before holidays or weekends, is not permitted. Start and finish times of every remote access session is logged.

3.9        Firewall Rule Set Update Procedure

3.9.1       Identify use cases for allowed traffic, checking with stakeholders if any existing use cases are still valid. Use cases must reference only ↗Controlled Software; network traffic from any other software is unauthorized by default.

3.9.2       Document use cases in a descriptive text document, identifying stakeholders and potential end-of-life for specific use cases.

3.9.3       Create firewall rules for all use cases based on the principle of default deny.

3.9.4       Create a final firewall rule “deny all”.

3.9.5       Have the OT Support Center check the rule set against the high-level documentation of use cases.

3.9.6       Backup the existing rule set.

3.9.7       Configure the new rule set.

3.9.8       Check if the firewall access credentials need to be changed and update if appropriate.

3.9.9       Test the firewall.

3.9.10    Backup the new rule set.

3.9.11    Document the changes for the OT Support Center.

3.9.12    Record the change project.

3.10   Generic Configuration Change Management Procedure

Before performing configuration change:

3.10.1    Plan the change and document the plan.

3.10.2    Determine the ↗Criticality of the system or network under consideration.

3.10.3    Check any OT Configuration rules that apply to the system to be changed by referring to the SCGP Reference Architecture.

3.10.4    Approve the change or have it approved if necessary.

3.10.5    Ensure that the present configuration of the system to be changed is properly backed up

3.10.6    If the configuration change involves copying of files to the system to be changed, check all files for known malware before copying. If malware is found, discontinue the change project and inform the OT Support Center.

3.10.7    Change the configuration.

After performing configuration change:

3.10.8    Test the system with the new configuration.

3.10.9    If the system does not function properly with the new configuration, escalate to have the conflict resolved.

3.10.10 Remove/restore all accounts, files, firewall rules etc. used/disabled for testing and diagnostics.

3.10.11 Save the new configuration to a backup medium and/or version control server (if applicable).

3.10.12 Perform the administrative tasks required for assurance of system integrity, such as calculating and storing new hash values.

3.10.13 Document system changes in the System Inventory, Network Diagrams, and Data Flow Diagrams (if appropriate).

3.10.14 Record the change project.

4    OT Planning and System Design

Applies to: Vendors, Integrators, staff members tasked with OT planning and system design.

4.1        Exchanging Files

4.1.1       Before sharing files with others it must be ensured that no copyright rules are violated, appropriate security clearances or non-disclosure agreements exist, and appropriate classification marks are attached to media and accompanying documentation.

4.1.2       The use of shared network folders is not permitted for sharing files.

4.1.3       Files intended for sharing with systems residing in the office network or in remote networks are only transferred via the dedicated transfer route.

4.1.4       Staff members must use company media to pass documents to visitors in case such document transfer is required for the visitor to perform designated and authorized tasks.

4.2        Planning Design and Configuration Change Procedure

Planning new plants, plant extensions, retrofits etc. involves the following steps:

4.2.1       Determine if the new or updated design involves digital industrial automation and control systems, or involves digital systems that are supposed to interact with control systems or populate control networks. The following check points may help in the process: – presence of cyber-physical systems that are programmable, or support digital communication interfaces such as fieldbus, Ethernet, RS-232, or support digital media such as USB, EPROM, or floppy disks – presence of digital components that interact with ICS in a control network or in any other way have an effect on a physical process. If not, SCGP OT planning and configuration rules don’t apply.

4.2.2       Determine the rules of the SCGP Reference Architecture that apply for all systems or system groups that are involved in the new or updated design.

4.2.3       Use the appropriate rules in the specification of the new or updated design. If the rules cannot be used for whatever reason, check with the OT Support Center to resolve the conflict.

4.2.4       Make sure that the design specification document including all respective cyber security and robustness specifications is part of the Request For Proposal (RFP) and procurement contract (if applicable).

4.2.5       Make sure that the respective specifications are subject to acceptance tests.

4.2.6       Record the change project.

4.3        System Acquisition Procedure

Pre-acquisition

4.3.1       Communicate the System Procurement Guideline to vendors and integrators

4.3.2       Offer training for vendors for familiarization with the System Procurement Guideline

4.3.3       Have vendors check their product offerings for compliance in respect to ALL criteria and document conformity or non-conformity

Acquisition Process (for every system acquisition)

4.3.4       Produce a customized version of the Procurement Guideline for the tender at hand with must-have criteria (requirements)

4.3.5       Make the customized System Procurement Guideline part of the Request For Proposal (and later, a legal part of the contract)

4.3.6       Where appropriate, require that the newly acquired system will be conformant to the SCGP Reference Architecture module

4.3.7       Where appropriate, make sure that tests conducted during ↗FAT and ↗SAT are executed in an environment that is conformant with the SCGP Reference Architecture module

4.3.8       Check for conformance of the delivered product or solution with the System Procurement Guideline and, if appropriate, also for conformance with the SCGP Reference Architecture module, as part of the legally binding acceptance procedure

4.3.9       Inform the vendor about the results of the conformity check and try to resolve issues if needed

4.3.10    For any discrepancies with the Guidelines, have the OT Support Center and the issuing department determine if the product in question shall be commissioned anyway

Post-acquisition

4.3.11    Label the newly acquired system with device IDs (see SCGP System Inventory) for integration with the System Inventory

4.3.12    Document conformance or non-conformance

4.3.13    Update the site’s system documentation: System Inventory, Data Flow Diagrams, and Network Diagrams (if appropriate)

5    Visitors

This chapter lists policies and standard operating procedures for Non-Staff personnel not entitled to use or configure systems within control networks. Examples are sales engineers from vendors, consultants, and representatives of regulatory authorities.

5.1        Using Computer Systems and Networks

5.1.1       Visitors must not attach systems to control networks or to systems within control networks (e.g. via USB).

5.1.2       If system access is required for a visitor to perform a designated and authorized task, such access must occur under constant supervision by an authorized staff member.

5.2        Using the Internet and Email

5.2.1       If Internet or email access is required for a visitor to perform designated and authorized tasks, such access must only be accomplished via dedicated terminals not residing in a control network.

5.3        Exchanging Files

5.3.1       In the case visitors need to provide files to accomplish their designated and authorized tasks, such files are provided on a USB stick which is checked for known malware at a designated cleaning station.

5.3.2       Executable programs must only be addressed to the OT Support Center which will inspect such files before passing it to the respective end user.

5.3.3       Documents may be passed directly to the respective end user who must exclusively open such documents on a system not connected to a control network.

6    Using the OT-BASE Asset Management System for Policy Audits

6.1        Registration of Nomad Laptops

For many organizations, controlling nomad laptops has become a major problem. OT-BASE allows users to provide information on personal laptops they intend to use, and it allows asset owners to manage and authorize such laptops.

A user may register a nomad laptop that he or she wants to use in the personal settings that can be accessed in the top right corner of the OT-BASE windows.

Any laptop details can then be examined by the asset owner, who then may or may not authorize the laptop for use in the facility. This is done in the workforce management, where an authorization code and an expiration date can be set which can easily be inspected by auditors.

6.2        Monitoring Data Flow

The various provisions regarding limitations of system access via networks, especially for contractors, can be monitored easily if OT-BASE configuration collectors are used, since such collectors can also monitor and record data flow. Data flow is then automatically associated with networks and devices and allows for easy auditing.

6.2.1        The global data flow table

All potentially unauthorized data flow is stored in a table that can be accessed in Inventory/Networks in the tab “Unassigned detected data flow”. This table can conveniently be filtered for IP addresses, device names, protocols etc.

6.2.2        Data flow tables for individual networks

Potentially unauthorized traffic for individual networks can be inspected by launching the network profile of the network in question, which contains various data flow lists for intra-network traffic and cross-network traffic.

6.2.3        Data flow tables for individual devices

Unauthorized data flow for any device can be inspected easily by launching the device profile of such device and open the section “unassigned detected data flow” in the “Connectivity” area.

6.3        Auditing Software Configuration

The various provisions in SCGP that call for specific software configurations can be audited using baseline definitions, which can be accessed in Workflow/Audit. A baseline profile shows right away which of the systems that are subject to a given baseline are compliant and which are not.

6.4        Change Management Workflow

The provision that configuration changes must use a change management procedure which involves the approval of changes by authorized personnel is executed in OT-BASE by simply following the change management process that can be accessed in Workflow/Changes. For any configuration change, it can also be detected easily in the device profile of each device if the configuration change occurred inside or outside of a change case.