This document offers answers to the most common audit questions.

A brief introduction to D2000 and its architecture

See

Structure of D2000 systems in our factory

The answer to this question is very factory-specific, here we offer two possible configurations:

Scenario 1 - Three redundant D2000 systems

Currently, there are 3 independent (though interconnected) systems in <Our_company>, built using D2000 technology:

<System1>
<System2>
<System3>

All three D2000 instances run physically on three independent execution servers, which run the hypervisor for the virtual servers needed to run the D2000 system. Each D2000 instance has its own application server, which is redundant and runs physically on a different server, and individual users connect to these application servers. New installations and updates for D2000 are distributed to users via FTP updates from a special server. D2000 is a fully redundant system in terms of application, archive databases, and network optical connections.

Scenario 2 - A three-node SCADA and a two-node MES

Currently, there are 2 independent (though interconnected) systems in <Our_company>, built using D2000 technology:

SCADA
MES

The SCADA application runs on 3 physical servers (2 of them are in the primary location, the last one is in a disaster recovery location). The two servers are connected to 2 redundant networks, and the DR server is connected to a single network.

The MES application runs on 2 virtual servers located in the primary location. These servers (Linux) also host a PostgreSQL application database, which also contains the EDA database (energy database working with vectors).

Operators of the SCADA application are also connected to the redundant network, whereas users of MES are connected via redundant Security Access Proxy Servers running on virtual servers located in a DMZ network.

Please provide an export of all active directory accounts, including the last log-on date and status (enabled/disabled).

D2000 is part of the <Our_company> domain, and the domain is managed by the local IT department. We have read access to the active directory, where all the people from the control systems department are listed as local administrators (<list of names>). With these accounts, we can connect to the Windows servers with D2000. There is also a group for suppliers in the active directory, where every supplier who connects to the <Our_company> network has an account created. We can change these.
Our IT administrator provided a list of users with last logon in the attached file: AD_Lastlogon.xlsx.

Please provide the results of the most recent user access rights review performed (if applicable) for the D2000 system

We periodically check access rights every 12 months. If an employee terminates their employment, they cannot log in to the <Our_company> network and cannot connect to D2000. This is not systematically handled by HR, we do not know about the termination of an employee's employment. In the event of a change in position, access rights are assigned at the request of the employee's superior.

Provide a system-generated report (Excel is preferred) of users and their access levels/roles for the D2000 system. Please include user ID, user full name, account creation date, last modified/change date (if possible), and access level/roles within the listing.

Please provide an electronic copy of the query utilized or a screenshot showing how the listing was generated.

There are 2 basic types of D2000 users. Administrators and standard users. Administrators can edit D2000 objects using D2000 Cnf/GrEditor tools. Selected administrators can also edit/create other users. This is how to obtain the list of users in the D2000 Cnf tool:

The list can be configured (add/remove needed columns, e.g., Create time, Modify time), exported (Ctrl+C), and copied, e.g., to Excel.

Full list: see file ‘D2000 list of users.xlsx’

As for access roles, each user can be assigned to multiple Object groups for read/control/modify access. Each of the Object groups contains a list of D2000 objects to which these rights apply. For more info, see documentation - Users and Access Rights:

These access rights are a configuration that is created by the D2000 administrator by creating an Object group, for example, Quality, and assigning this object to certain users for reading/controlling or modifying, and then the software determines who is logged in and the level of their access rights to the given Quality group. All/selected users can be exported to XML, and their assigned groups and access rights viewed/extracted. However, this can be a large amount of data, and knowledge of what the specific group means is needed.

Also, the configuration of individual Object groups can be exported to XML, and D2000 objects assigned to this group can be viewed/extracted:

XML Export of all users, all groups of all D2000 applications is in file: XML_EXPORTS.zip

Provide a system-generated report or a screenshot showing the password settings for the D2000 system.

If the system is single sign-on, please show that the application is configured this way for all employees and which domain it references for log-on.
Please include the following, if applicable:

Password Length
Password History
Password Complexity
Account Lockout Attempts
Account Lockout Duration
Idle Time Lockout

Password policy is configurable using system parameters. Currently, single sign-on is not configured; all authentication is performed by D2000. Currently, parameter SecurityPolicy=0, which means the advanced security policy (password length, number of numbers/special characters, etc) applicable during password change is not enforced. Also, password expiration is not configured for any user. We do not use a domain name for login.

For explanation of individual parameters, see the documentation - Parameters for D2000 Server.

Provide a system-generated listing (Excel is preferred) of all application and data (if applicable) changes promoted to production since 1/1/2025 for the D2000 system.

Please provide an electronic copy of the query utilized or a screenshot showing how the listing was generated. If the listing is generated from the ticketing system, please provide a screenshot of the last modified date for the D2000 system in an effort to tie the two together.

There are 2 ways to handle this request:

In Cnf, you can go to the Object menu and select History. In the dialog window, set Modify time from/to appropriately and click Find. The list can be copied (Ctrl+C) as a CSV list.

Full list: see file ‘D2000 changes of objects in 2025.xlsx’
For each object, its default latest history is limited to the last 7 changes; this is configurable by a system parameter LogRecsLimit. So, currently, only the last 7 changes of all objects modified in 2025 can be obtained from the system. The reason is to keep the Configuration database within reasonable size limits.
For more info, see the documentation - Object modification history.
Using the Logging database. The default history depth of the Logging database is, however, only 7 days; this is configurable (so currently changes since 1/1/2025 are not stored). The reason is to keep the Logging database within reasonable size limits.

For more info, see the documentation - System Event Logging (D2000).

Also, “GIT object history” can be configured. In this mode, the D2000 system stores all changes (not only information about change, but XML export of changed objects| to an internal GIT repository, which can be viewed, used to compare individual versions, and, if needed, return to older versions.
For more info, see the documentation - GIT object history.

Provide a system-generated listing (Excel is preferred) of all users / IDs with the ability to modify production application code in the D2000 system, as well as those that can move code changes to the production environment (if applicable).

Please provide an electronic copy of the query utilized or a screenshot showing how the listing was generated. If the listing is generated from the ticketing system, please provide a screenshot of the last modified date for the D2000 system in an effort to tie the two together.

Only the administrators can modify the application code (ESL scripts), as well as other D2000 objects configurable in D2000 Cnf. „move code changes to the production environment” is applicable to D2000 technology (see XML Export/XML Import), but there is almost no test environment for any of the D2000 systems in <Our_company>. Still, only administrators can perform XLM import, so the list would be identical.

For major implementation changes, the changes are created at the supplier and gradually deployed into production using the XML Export/XML Import utility. Of course, a backup of the system database is performed before deploying the changes.
Administrators can be filtered in the ‘D2000 list of users.xlsx’ file.

Please provide a system-generated listing of those individuals with the ability to modify (add, change, & delete) the job schedules for the D2000 system, including the supporting operating systems and databases.

There are no external “job schedules”. There are scripts (internal D2000 objects, containing ESL code and/or Java code) triggered by a system event or periodically; again, only administrators can edit them. See the previous answer.

Please provide a system-generated log showing the history (since 1/1/2025) of D2000 system automated jobs, including the date, time, job name, and success/failure status.

Please provide an electronic copy of the query utilized or a screenshot showing how the listing was generated:

There are no “jobs” defined in the D2000 scripts. Only internal scripts (ESL/Java) can be run (periodically or on a defined trigger). The scripts can use the LOG action to log a text message into a Logging database, but there is no logging of scripts being run. Only exceptions that occur in scripts (script errors) are recorded in the Logging database:

Please provide system-generated evidence (a report or a screenshot) showing the backup schedule of the D2000 system. Please provide documentation supporting if the backups are Immutable and/or Air-Gapped.

Backups of Syscfg/Logfile databases are configured as Windows scheduled tasks on individual application servers. The configuration database and logging database (PostgreSQL) are backed up.

Backups of Syscfg/Logfile databases are created locally on application servers (D:\_Backups\_LastNight) and copied to \\ SrvBkp1v\_Backup\LastNight where the last 7 daily backups are preserved.

Backups of the MES database are configured as Windows scheduled tasks on the SrvDbs1v server. The MES database (Oracle application database) is backed up daily, using RMAN backup (to X:\Oracle\OraBack\MESDB) as well as the “exp” utility for export of individual schemes (to D:\_Backups\_LastNight). Exports are copied to \\SrvBkp1v\_Backup\LastNight\SRVDBS1 where the last backup is preserved.

Backups of archives (historical databases) of all applications are performed weekly on their respective servers.

Backups are created directly on \\SrvBkp1v\_Backup, not locally (due to their size).

Also, backup of virtual application servers, archiving server, and database server (SrvDbs1) are performed by Veeam (and kept on \\SrvBkp1v\_Backup).

We do air gap backups. We manually copy the data to a designated network storage location, where a job runs that transfers the data to a tape drive that is managed by local IT. We set the copy frequency to once a quarter. We have not yet tried to restore this data.

Strom stránky

Audit questions