Version 5.

Setting Up Security

Citect Pty Ltd

3 Fitzsimmons Lane
Gordon NSW 2072
Australia
www.citect.com
DISCLAIMER

Citect Pty. Limited makes no representations or warranties with respect to this manual and, to the
maximum extent permitted by law, expressly limits its liability for breach of any warranty that may be
implied to the replacement of this manual with another. Further, Citect Pty. Limited reserves the
right to revise this publication at any time without incurring an obligation to notify any person of the
revision.

COPYRIGHT

© Copyright 2003 Citect Pty Limited. All rights reserved.

TRADEMARKS

Citect Pty Limited has made every effort to supply trademark information about company names,
products and services mentioned in this manual. Trademarks shown below were derived from
various sources.

CitectSCADA, CitectHMI/SCADA, CitectFacilities and CitectSCADA Batch are regisitered

trademarks of Citect Pty. Limited.

IBM, IBM PC and IBM PC AT are registered trademerks of Internatrional Business Machine
Corporation.

MS-DOS, Windows, Windows 98, Windows 2000, Windows XP and Excel are trademarks of
Microsoft Corporation.

dBase is a trademark of Borland Inc.

General Notice:

Some product names used in this manual are used for identification purposes only and may be
trademarks of their respective companies.

October 2003 Edition for CitectSCADA Version 5.5

Manual Revision 1.0

Setting Up Security 2
Introduction to Security

For large applications, or applications where access to certain processes or machinery must be
restricted, you can build security into your system. You can then restrict access to commands that
should not be available to all your operators, for example, commands that operate specialised
machinery, acknowledge critical alarms, or print sensitive reports.

You can assign a separate password to each of your operators (or class of operators), that must be
entered before the operator can use the system.

Maintaining User Records

You can add login records for some (or all) users of your runtime system. User records enforce an
orderly login and restrict access to your system. Each operator for whom you add a user record
must enter their user name and password to gain access to your runtime system.

You can add a user record for each of your users when you configure your project, or add a single
record for each class (or type) of user (for example, Operators, Managers, Supervisors, etc.). When
your system is running, you can add new users (based on a defined class) as required. Each class
of users shares common attributes, such as privileges.

User Records and Project Restoration

If you restore a project from backup, or install a new project from a compiled offline master, then the
user records will be reset to match those originally configured in the project. If the runtime user
creation, password change ability, or password expiry functions are used, then the runtime details
may be thrown out of synchronisation with master offline projects.

In this situation, you must have procedures in place to use the current Users.dbf file (which is
running live in the plant) when any offline project compilations are performed. This will minimise the
likelihood of either losing users created at runtime or of having expired user records locked when a
new system is deployed and run up.

Note: Online changes arising from user creations and modifications are reflected only in the
local _Users.rdb and Users.dbf files. To ensure that user records remain synchronised
across a distributed network, the user administration should only be performed on a
central node. All other nodes will use the Copy= functionality in CitectHMI/SCADA or
custom engineered database replication.

To add a user record:

1. From the System menu select Users
2. Complete the Users form. Use the Help button for more information about the fields.
3. Press the Add button to append a record you have created, or the Replace button if you have
modified a record.

Setting Up Security 3
User Properties

Users have the following properties:

User Name (16 Chars.)

The user's name.
You can assign a user record for a single user, for example:

User Name J Smith

User Name John Smith

Each operator must enter the User Name and Password to use the system.

Full Name (32 Chars.)

The full name of the user or class of user. This name is used as a comment and for display in
alarm logs and command logs.

Password (16 Chars.)

The user's password. When you enter the password, an asterisk (*) will display for each
character entered. When you save the user record, the password will be encrypted before it is
saved to the Users.dbf.
Each operator must enter the User Name and Password to use the system.
Use the [General]PasswordExpiry parameter to specify when the password will expire.

Confirm Password (16 Chars.)

Re-enter the user's password to confirm the text entered in the Password field. If the contents
of the Password and Confirm Password fields are different when the record is saved, a
message will be displayed that indicates a mismatch and invites you to try again.

Global Privilege (8 Chars.)

The privilege classes assigned globally to the user.
As you configure your system, you can assign privileges to the various elements, such as
graphics objects, alarms, accumulators, commands, etc. For example, a user with a Global
Privilege of 3 will be able to issue any command that is assigned a privilege of 3, or action any
alarm with a privilege of 3, or click on any button that is assigned a privilege of 3, etc. Unless
you are using areas, if you do not specify a global privilege, the user cannot access any
command with a privilege assigned.
You can make your security more flexible by dividing your system into areas, and assigning
users privileges or view-only rights to specific areas (see below).
NOTE: Global privileges will override the Viewable Areas settings you have applied for a user.

Type (16 Chars.)

Setting Up Security 4
 The generic type of user, for example:

Type Operator

Type Supervisor

Type Manager
Only use this property to define a user class from which individual users (of that class) are to
be created at runtime with the UserCreate() function.

Comment (48 Chars.)

Any useful comment.

NOTE: The following fields are implemented with extended forms (press F2).

Viewable Areas (16 Chars.)

The areas the user is permitted to view. Remember, however, you must still assign privileges
to the elements in these areas, such as graphics objects, alarms, accumulators, commands,
etc. If you do not, the user will have full access to them. For example, if you do not assign a
privilege to, say, a command in one of these areas, the user will be able to issue it.
To make an element (such as a button on a graphics page) view only for a particular user,
assign it an area and a privilege. Add the area to the user's list of Viewable Areas, but don't
give the user the required privileges in that area (or the required global privilege).
Multiple areas can be defined using groups.
If you do not specify viewable areas, the user has access to the default area only (area 0).

Areas for Priv 1 . . . Priv 8 (16 Chars.)

The privileges (by area) assigned to the user. Using this combination of areas and privileges,
you can assign a user different privileges for different areas. For example, users with privilege
class 6 in areas 29 and 30 only have access to commands in those areas that require privilege
class 6. This does not affect the Global Privileges (see above) assigned to the user. A user
who has global privilege classes 1 and 2 can still access commands in all viewable areas that
have privilege classes 1 and 2.
If you do not specify areas with associated privileges, access is defined by Viewable Areas
and Global Privileges alone.
NOTE: The privileges entered in these fields will only apply if the relevant areas are listed in
the Viewable Areas field above.

Entry Command (64 Chars.)

A Cicode command that is executed when the user logs in. You can use any Cicode
command or function.

Exit Command (64 Chars.)

A Cicode command that is executed when the user logs out. You can use any Cicode
command or function.

NOTE: To login a user, you must use the Login() or LoginForm() Cicode functions.

Setting Up Security 5
Defining User Privileges

To restrict access to a particular system element (command, object, report, alarm, etc.), you assign
it a privilege requirement, then allocate that privilege to the users who will use it. CitectHMI/SCADA
provides eight privileges, numbered 1 to 8. You can, for example, allocate different privileges to
different types of operation, as in the following table:

Privilege Command

1 Operate the conveyors

2 Operate the ovens
3 Operate the canners
4 Acknowledge alarms
5 Print reports

To allow a user to operate the conveyors, you assign privilege 1 to the user's login record, for
example:

Global Privilege 1

To allow a user to acknowledge alarms, you assign privilege 4 to the user's login record, for
example:

Global Privilege 4

To allow a user to acknowledge alarms and operate the conveyors, you assign both privilege 1 and
privilege 4 to the user's login record:

Global Privilege 1, 4

Privilege classifications must be separated by commas (,).

To allow a user access to all commands in your system, allocate all privileges in the user record, for
example:

Global Privilege 1, 2, 3, 4, 5

After you have allocated privileges, you can define the privilege requirements of your system
elements (commands, reports, objects, alarms, etc.):

Command CONVEYOR = 1;
Privilege 1
Comment An Operator with Privilege
classification 1 can operate the
conveyor

Command Report("Shift");
Privilege 5
Comment An Operator with Privilege
classification 5 can print the report

Not all system elements need a privilege classification. At least one command must be issued by
all users - a command to log in to the system:

Setting Up Security 6
 Command LoginForm();
Privilege
Comment A blank Privilege (or Privilege 0)
means that the command has no
classification - it is available to all
users

Using Hierarchical Privilege

By default, privileges are non-hierarchical (i.e. users with privilege 3 only have access to commands
with classification 3). Non-hierarchical privileges add flexibility to your system - especially when
used with the area facility.

When privileges are set to hierarchical, privilege 1 is the lowest and 8 is the highest (i.e. users with
privilege 3 have access to commands with privilege classification 3, 2, and 1). To allocate all
privileges, you would only need to specify privilege 8.

Global Privilege 8

Using the privilege facility, you can easily develop a very secure CitectHMI/SCADA system. You
should, however, carefully plan your security method before you set up your system. You need to
decide which commands you can group into a class, the privilege for each class of commands, and
the privileges to assign to each operator.

NOTE: If your plant can be divided into several discrete sections (or areas), you can add an extra
level of system security by using the CitectHMI/SCADA area facility.

Setting Up Security 7
Defining Areas

When implementing CitectHMI/SCADA for a large application, you would usually visualise the plant
as a series of discrete sections or areas. You can define these areas geographically - especially
where parts of the plant are separated by vast distances (or physical barriers) - or logically (as
discrete processes or individual tasks).

NOTE: The area facility is implemented with extended properties.

By thinking about your plant in terms of areas, you can add flexibility to your system security.
Without areas, you can only assign global privileges to users. A user with a global privilege can
access any part of the system with a matching privilege. Areas, on the other hand, allow you to add
an extra level of control. Instead of assigning a global privilege, you can assign a user different
privileges for different areas. You can then assign each of your system elements (objects, alarms,
reports, accumulators, etc.) a privilege requirement, and allocate each to a specific area. This
means that a user has full control only when he or she has access to the required area and
possesses the required privileges for that area.

Some plants can be divided into just three areas - raw product arrives in the receivals area, is
transported to an area for processing, and is then transported to a packaging or despatch area.
RECEIVALS PROCESSING

DESPATCH

However, with larger or more complex plants you may need to define several areas - as in the
following figure.
RECEIVALS PROCESSING

1 5 6 DESPATCH
4
7

8 10
2 3

9
11 12

When defining an area, you would usually encompass a section of the plant that is controlled by one
operator (or controlled from one CitectHMI/SCADA Display Client).

You can also define smaller areas that are collectively controlled by an operator or Display Client.
This method can increase flexibility, but can introduce a higher level of complexity to your system.

Setting Up Security 8
 RECEIVALS PROCESSING

1 5 6
DESPATCH
4
7

8 10
2 3

9
11 12
This display node
controls area 9 This display node
controls the Despatch area
(areas 10,11 and 12)

You can define up to 255 separate areas. You can then refer to these areas by number (1 to 255)
or you can use a label to assign a meaningful name for the area (e.g. receivals, pre_process,
conveying, etc.).

Using Areas for Security

After you have defined your areas, you can configure the commands, objects, alarms, reports, etc.
your operators will use in those areas.

For example:

Command CONVEYOR = 1;
Area 10
Comment This command belongs to Area 10

In this example, an operator without access to Area 10 will not be able to issue the command.

Using Labels to Name Areas

It might be easier to remember an area by a meaningful label (name) rather than a number. For
example:

Label Name DespatchAccum

Expression 10
Comment Label Area 10 as "DespatchAccum"

In this case, "DespatchAccum" could be used whenever area 10 is referred to, for example:

Command CONVEYOR = 1;
Area DespatchAccum
Comment This command belongs to Area 10
(DespatchAccum)

NOTE: If you leave the Area field blank on a form, the command does not belong to any particular
area - it is assigned to all areas of the plant.

Setting Up Security 9
 To label an area:
1. From the System Menu, select Labels
2. Enter a name for the label
3. Enter an expression to be substituted for the label
4. Press the Add button to append a record you have created, or the Replace button if you have
modified a record.

Using Groups of Areas

You can group several areas and define a name for the group.

Group Name Despatch

Association 1 DespatchAccum
Association 2 11
Association 3 12
Comment Areas 10, 11, 12 = "Despatch"

In the above example, areas 10, 11, and 12 are associated with the name "Despatch". Any
command assigned to "Despatch" belongs to areas 10, 11, and 12.

Command CONVEYOR = 1;
Area Despatch
Comment This command belongs to Areas 10,
11 and 12

You can also define a group that includes other groups.

Group Name Plantwide

Association 1 Receivals
Association 2 Process
Association 3 Despatch
Comment Associate all areas with
"Plantwide"

In this example, the name "Plantwide" refers to all areas defined in the "Receivals", "Process", and
"Despatch" groups.

Setting Up Security 10
Using Areas With Privileges

By combining Area and Privilege restrictions, you can be selective about what control an operator
has within a specific area. You can still assign privileges to each of your operators without using
areas - to allow them access to the entire plant (global privileges), but by combining Areas and
Privileges, you add an extra level of flexibility.

User Name J Smith

Global Privilege 2, 3
Viewable Areas 9, 10, 11, 12
Areas for Priv 1 Despatch
Areas for Priv 2
Areas for Priv 3
Areas for Priv 4 DespatchAccum
Areas for Priv 5 DespatchAccum, 11
Areas for Priv 6
Areas for Priv 7
Areas for Priv 8
Comment Login for John

In this example, John Smith has global privileges 2 and 3. This means he can use commands with
privilege classification 2 or 3 in any viewable area of the plant. He has privilege 1 in the "Despatch"
areas (10, 11, and 12), privilege 4 in the "DespatchAccum" area (10) and privilege 5 in areas 10 and
11. This means he has control of system elements (alarms, reports, accumulators, objects, etc.):
located in area 9, with privilege requirement 2 or 3.
located in area 10, with privilege requirement 1, 2, 3, 4 or 5.
located in area 11, with privilege requirement 1, 2, 3 or 5.
located in area 12, with privilege requirement 1, 2 or 3.

Also, in this example, Groups and Labels have been used to make the security configuration
intuitive.

Specifying Security Requirements

Each of your system elements (objects, alarms, reports, accumulators, etc.) can be assigned a
privilege requirement and allocated to a specific area. For a user to be able to acknowledge an
alarm, for example, he or she must have access to the correct area, with the required privileges for
that area.

For example:

Command CONVEYOR = 1;
Privilege 1
Area 10
Comment This command belongs to Area 10,
and requires privilege 1

In this example, an operator without privilege 1 in Area 10 will not be able to issue the command.

Setting Up Security 11
 Privilege - Area Combinations
It is important to know how the various privilege - area combinations will affect your security.

Privilege Area Resulting Security

specified? specified?

Yes Yes operator must have the required privileges

for the area specified

Yes No security is determined by the user’s Global

Privileges alone

No Yes operators only need view-access to the area

specified

No No all operators have full control

Viewing Areas of the Plant

You might need to provide an operator with access to information from other areas of the plant -
without providing control of the process in those areas. For example, the processes in one area
may directly affect another area.

In the following example, John Smith has control of:

any system element with a privilege requirement of 2 or 3;
system elements located in Despatch, with a privilege requirement of 1; and
system elements located in DespatchAccum, with a privilege requirement of 4.
Everything else in the plant is View Only.

User Name J Smith

Global Privilege 2, 3
Viewable Areas Plantwide
Areas for Priv 1 Despatch
Areas for Priv 2
Areas for Priv 3
Areas for Priv 4 DespatchAccum
Areas for Priv 5
Areas for Priv 6
Areas for Priv 7
Areas for Priv 8
Comment Login for John

Alternatively, you could restrict an operator to a group of areas (e.g. "Receivals") or to a single area
(e.g. 12).

Setting Up Security 12
 To define a group of areas:
1. From the System menu select Groups
2. Complete the Groups form. Use the Help button for more information about the fields.
3. Press the Add button to append a record you have created, or the Replace button if you have
modified a record.

Groups Properties

Groups have the following properties:

Group Name (16 Chars.)

The name of the group. You can use this facility, for example, to define multiple areas or
multiple devices.
After you have defined a group, it can be used anywhere that an individual entity can be used.
You can also specify complex groups by defining a group of groups.

Association 1 . . . Association 10 (16 Chars.)

A list of the entities associated with the Group Name. An Association can be a number, a
name, or another group. You can also specify a range of numbers in the format <n1..n2> for
example:

Association 1 4..10
Specifies numbers 4,5,6,7,8,9,10.
You can also define a group of devices to be accessed with a single name, for example:

Association 1 AlarmPrint
Association 2 AlarmLog
Association 3 AlarmDBF
In this case, when the group name is used as a device, the information is sent to all three
devices - AlarmPrint, AlarmLog, and AlarmDBF.

Comment (48 Chars.)

Any useful comment.

Setting Up Security 13