Security model and IEC 62443-3-3

This page describes the security model of YTCC and compares it with the system requirements (SR) of IEC 62443-3-3 that matter most for a SCADA system. It is a help for the security assessment of a plant, not a certification.

Security model

• One identity authority per project. The projects server holds the users, profiles and policies of each project and signs the session tokens. The gateway, the alarm service and the configuration service ask it to confirm every session; permissions are read from the current configuration, not from the token, so a changed profile applies within 10 seconds.
• Commands and changes are checked on the server. Commands, alarm acknowledgements, configuration changes and user administration are allowed or refused by the server, whatever the screen shows.
• Fail closed. If the server cannot read the authentication configuration or cannot reach the identity authority, requests are refused rather than allowed. The same holds for interlocks and responsibility zones.
• Sessions. A session token lasts 15 minutes; the browser renews it in the background while the session is open. The interface ends a session with no activity after 30 minutes, with a warning one minute before. Signing out revokes the session.

With authentication turned off, which is the state of a new project, everyone is anonymous and every action is open. Turn authentication on before a project is used on site; see Turn on authentication.

Requirements met

Requirement	How YTCC meets it
SR 1.1 Human user identification and authentication	Personal user accounts per project; every command, acknowledgement and change is tied to the signed-in user
SR 1.3 Account management	Users and profiles are managed per project by root, the system administrator; project users only operate. Changes are in the user audit log
SR 1.7 Strength of password-based authentication	Password policy: minimum length (8 by default), upper-case letter and digit, history of 5, not equal to the user name; stored as bcrypt hashes
SR 1.11 Unsuccessful login attempts	Five failed sign-ins lock the account for 15 minutes
SR 1.12 System use notification	An optional sign-in notice; when acknowledgement is required, the password is checked only after the notice is acknowledged
SR 2.1 Authorization enforcement	Permissions per profile; commands, acknowledgements, configuration changes and user administration are checked on the server for every request; responsibility zones for control
SR 2.5 Session lock	The interface ends a session after the idle time
SR 2.8 Auditable events	User audit log, configuration audit, event list and command log; see Audit logs
Dual approval	Critical commands with a second user's approval; interlock overrides with a reason and, by default, a second user

What the operator of a plant adds

Topic	What to do
Default accounts	Turning authentication on in the configuration editor creates nine accounts whose password is the user name (for example admin / admin). Create personal accounts and disable the default accounts before the plant goes into operation. Disable them rather than delete them: turning authentication off and on again creates a deleted default account again, with its user name as password
Access to the stations	Limit network access to the operator stations
Accounts of several projects	Accounts exist per project; keep the account lists of the projects consistent
Communication	Keep the server and its clients in a protected network, or put an encrypting reverse proxy in front of YTCC
Audit information	Restrict access to the server and keep the logs in a protected place
Restriction by station	Use network rules per station; the live data server can also accept only listed client addresses on its own port, and the web interface only the networks in its allow list (see Security hardening)
Confidential screens	Do not use page access for confidential information; see Page access

For the network side, see Security hardening.