...
All three D2000 instances run physically on three independent execution servers (virtualized Windows), 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.
...
The SCADA application runs on 3 redundant 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. All servers run Linux (RedHat).
The MES application runs on 2 redundant virtual servers located in the primary location. These servers (Linux RedHat) also host a PostgreSQL application database, which also contains the EDA database (energy database working with vectors). This database is running on Linux clusterware (Corosync + Pacemaker).
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 (Windows) located in a DMZ network.
...
There are 2 basic types of D2000 users. Administrators : 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:
...
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.
...
Password policy is configurable using system parameters. Currently, Though single sign-on is supported by D2000 (on Windows/Linux), currently it is not configured; all authentication is performed by the D2000. Currently, parameter 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.
...
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.
Scenario 1 - External backups by Windows Task Scheduler
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.
...
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.
Scenario 2 - Backups performed by the Sysprof Backup module, 2-node redundant D2000 application
Backups of Syscfg/Logfile/Archive databases (from both redundant D2000 servers) are performed by the Sysprof Backup module. In the Sysprof schemes, backup parameters (start time, periodicity, timeout, and other parameters) are configured. Backups are performed on the management server where SYSPROF.EVH is running.
Daily backups are stored to D:\_Backup\_LastNight, and also copied to D:\_Backup\_LastNight_1, 2, ... 7, so the last 7 daily backups are available.
...
Scenario 3 -
...
Backups performed by the Sysprof Backup module, an MES database on PostgreSQL
Backups of the MES database (PostgreSQL running on a Linux cluster) are performed daily by the Sysprof Backup module. They are stored to D:\_Backup\LastNight, and then copied to the NAS server, with a 7-day retention.
Scenario 4 -
...
Backups performed by the Sysprof Backup module, an MES database on Oracle, exp used
Backups of the MES database (Oracle RAC) are performed daily by the Sysprof Backup module. They are stored in D:\_Backup\LastNight, and then copied to the NAS server.
The Oracle "exp" utility is internally used to dump individual database schemes. The backups are then copied to the NAS server, with a 7-day retention (screenshot not included).
Scenario 5 - Backups performed by the Sysprof Backup module, an MES database on Oracle, rman used
Backups of the MES database (Oracle RAC) are performed daily by the Sysprof Backup module. They are stored in F:\oracle\oraback, and then copied to the NAS server.
The Oracle "rman" utility is internally used to back up the whole database. The backups are then copied to the NAS server, with a 7-day retention (screenshot not included).
