Information Security: DN9770704 Issue 14-0

Nokia
Information Security
DN9770704
Issue 14-0
The information in this document applies solely to the hardware/software product (“Product”) specified
herein, and only as specified herein. Reference to “Nokia” later in this document shall mean the respective
company within Nokia Group of Companies with whom you have entered into the Agreement (as defined
below).
This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the
purposes defined in the agreement between You and Nokia (“Agreement”) under which this document is
distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form
or means without the prior written permission of Nokia. If You have not entered into an Agreement
applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this
document in any manner and You are obliged to return it to Nokia and destroy or delete any copies thereof.
The document has been prepared to be used by professional and properly trained personnel, and You
assume full responsibility when using it. Nokia welcomes your comments as part of the process of
continuous development and improvement of the documentation.
This document and its contents are provided as a convenience to You. Any information or statements
concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on
an “as is” and “as available” basis in this document, and Nokia reserves the right to change any such
information and statements without notice. Nokia has made all reasonable efforts to ensure that the
content of this document is adequate and free of material errors and omissions, and Nokia will correct
errors that You identify in this document. Nokia's total liability for any errors in the document is strictly
limited to the correction of such error(s). Nokia does not warrant that the use of the software in the Product
will be uninterrupted or error-free.
NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY OF AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN RELATION TO THE
CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA BE LIABLE FOR ANY DAMAGES,
INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL
OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS
DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS
FROM THIS DOCUMENT OR ITS CONTENT.
This document is Nokia proprietary and confidential information, which may not be distributed or disclosed
to any third parties without the prior written consent of Nokia.
Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document
may be trademarks of their respective owners.
Copyright © 2016 Nokia. All rights reserved.
f Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle this
product and only after having carefully read the safety information applicable to this product.
The safety information is provided in the Safety Information section in the “Legal, Safety and
Environmental Information” part of this document or documentation set.
Nokia is continually striving to reduce the adverse environmental effects of its products and services. We
would like to encourage you as our customers and users to join us in working towards a cleaner, safer
environment. Please recycle product packaging and follow the recommendations for power use and proper
disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental services we
offer, please contact us at Nokia for any additional information.
2 © 2016 Nokia DN9770704 Issue: 14-0

Table of Contents
This document has 91 pages
Summary of changes .................................................................... 8
1 Information security........................................................................9
1.1 Authority management in the MMI system...................................10
1.1.1 Profile management..................................................................... 15
1.1.2 Security policy management........................................................ 16
1.2 Secure operation and maintenance connections......................... 24
1.3 User management in the MMI system......................................... 25
1.3.1 User IDs in the MMI system......................................................... 25
1.3.2 Service terminal usage in the MMI system.................................. 26
1.4 Audit trails.................................................................................... 26
1.4.1 MML command log.......................................................................27
1.4.2 FTP command log........................................................................27
1.4.3 SFTP command log..................................................................... 27
1.4.4 HTTP log files...............................................................................27
1.4.5 Security reporting......................................................................... 28
1.5 MMI disclaimer display................................................................. 28
2 MMI disclaimer............................................................................. 30
2.1 Creating the MMI disclaimer text and the confirmation question.....
30
2.2 Activating the MMI disclaimer display.......................................... 31
3 Managing local user profiles........................................................ 32

3.1 Managing local MMI user ID authority data..................................32
3.1.1 Displaying user ID authority in the MMI system........................... 32
3.1.2 Determining user ID authority in the MMI system........................ 33
3.1.3 Changing user ID authority in the MMI system............................ 34
3.1.4 Displaying the commands allowed in an MML session................35
3.2 Creating, modifying and deleting local MMI user profiles.............35
3.2.1 Creating and modifying an MMI user profile................................ 35
3.2.2 Deleting an MMI user profile........................................................ 38
3.3 Creating, modifying and deleting local HTTP users and user
groups.......................................................................................... 39
3.4 Configuring user account policy................................................... 39
3.4.1 Configuring login policy improvement.......................................... 40
3.5 Creating, modifying and deleting local Q3 or FTAM user profiles....
41
3.5.1 Creating a Q3 or FTAM user profile............................................. 41
3.5.2 Modifying a Q3 or FTAM user profile............................................42
3.5.3 Deleting a Q3 or FTAM user profile..............................................43
4 Managing local users in the MMI system..................................... 45
DN9770704 Issue: 14-0 © 2016 Nokia 3

4.1 Creating and deleting local MMI user IDs.................................... 45

4.1.1 Creating an MMI user ID.............................................................. 45
4.1.2 Deleting an MMI user ID.............................................................. 46
4.2 Changing a password in the MMI system.................................... 48
4.3 Configuring forced password change...........................................50
4.4 Configuring password policy........................................................ 51
4.5 Changing a password encryption key in the MMI system............ 52
4.6 Creating superusers and superterminals..................................... 54
4.6.1 Creating a superuser in the MMI system..................................... 54
4.6.2 Creating a superterminal in the MMI system................................54
5 Managing network element integrated IPSec.............................. 56

5.1 Introduction to network element integrated IPSec....................... 56
5.2 Configuring IPSec for management plane................................... 56
5.2.1 IPSec for OMU (O&M) with IKE pre-shared key based VPN
authentication...............................................................................57
5.2.2 IPSec for OMU (O&M) with PKI certificate based VPN
authentication...............................................................................60
5.3 Supported network elements and releases..................................68
6 Managing audit trails.................................................................... 69

6.1 Managing MML command log......................................................69
6.1.1 Accessing the MML command log............................................... 69
6.1.2 Accessing private and public commands in the MML command log
..................................................................................................... 70
6.1.3 Outputting data from the MML command log to a logical file....... 71
6.1.4 Displaying the MML command execution of a certain command
group............................................................................................ 72
6.1.5 Displaying the command execution of an MML command...........73
6.1.6 Making the MML command log close the current log file............. 74
6.1.7 Administering the MML command log..........................................74
6.2 Managing security reporting.........................................................75
6.2.1 Resetting the security counter......................................................75
6.2.2 Outputting a detailed security report............................................ 76
6.2.3 Directing a security counter report to an output device................78
6.2.4 Outputting a security counter report.............................................78
6.2.5 Changing the critical limits........................................................... 79
6.2.6 Checking the output parameters of the counter report.................80
6.2.7 Defining limits for security reporting............................................. 80
6.2.8 3445 SECURITY REPORTING DATA FILE CORRUPTED alarm...
82
6.3 Managing HTTP session log........................................................ 82
6.4 Reading access log and session log............................................83
7 Information security troubleshooting............................................ 84

7.1 A blocked command can be executed by an unauthorised user......
84
7.2 Command can be executed by an unauthorised user..................85
4 © 2016 Nokia DN9770704 Issue: 14-0

7.3 Command cannot be executed by an authorised user.................85

7.3.1 Command cannot be executed by operator................................. 85
7.3.2 Command cannot be executed by user ID administrator............. 86
7.4 The terminal authority has no effect on the user's authorities......87
7.5 All terminals have too low authorities...........................................87
7.6 A profile has too low authorities for command class I.................. 88
7.7 An unrequired profile cannot be deleted...................................... 89
7.8 Insufficient space for more profiles...............................................90
7.9 Insufficient space for more user IDs.............................................91
7.10 A network connection cannot be established via FTP................. 91
DN9770704 Issue: 14-0 © 2016 Nokia 5

List of Figures
Figure 1 Example of MML session authority.....................................................12
Figure 2 Example of a profile............................................................................16
Figure 3 Example of IPSec for management plane usage with IKE pre-shared
key based VPN authentication........................................................... 57
Figure 4 Example of IPSec for management plane usage with PKI certificate
based VPN authentication.................................................................. 61
6 © 2016 Nokia DN9770704 Issue: 14-0

List of Tables
Table 1 MML command authority requirement according to command status....
10
Table 2 Possible login situations..................................................................... 14
Table 3 Ensuring information security in the MMI system............................... 22
Table 4 Differences between SFTP and FTP.................................................. 25
Table 5 Application-field-specific user permission types................................. 41
DN9770704 Issue: 14-0 © 2016 Nokia 7

Summary of changes Information Security
Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
Changes made between issues 14–0 and 13–0
Chapter Managing centralised users in the MMI system has been removed.
The alarm information in parameters 009:0137 SEC_EVENT_LOAD_LIMIT and
009:0138 SEC_EVENT_UNSUC_LIMIT have been corrected.
Information security
MMI session policy feature has been added to user account policy.
Managing local users in the MMI system
Testing results of Configuring forced password change have been implemented.
Managing local user profiles
Testing results of Configuring login policy improvement have been implemented.
Managing network element integrated IPSec
This is a new chapter.
The document has been restructured to present the information in a more logical and
easily accessible way.
Information security
Login policy improvement has been added to user account policy.
Managing local users in the MMI system
Forced password change after next login feature has been added.
Managing local user profiles
Configuring login policy improvement has been added.
8 © 2016 Nokia DN9770704 Issue: 14-0

Information Security Information security
1 Information security
This document describes the methods employed to minimise information security risks.
The term information security applies mainly to the MMI system. However, some
information security issues related to TCP/IP connections are also included, as one way
of ensuring secure handling of data (concerning signalling, statistics, charging, and
database administration) are secure file transfer and secure O&M connections.
To secure the traffic and the flow of information in the network, attempts have been made
to minimise information risks in the system by using, for example, the authority system.
To avoid outside threat, only users who have been given a user ID and a password are
allowed to establish sessions in the MMI system. Inside threat has been minimised by
limiting the users' authorities to enter commands and by checking the users' access
rights. Also, the system is protected against dictionary attacks by implementing an
increasing delay between unsuccessful user authentication attempts so that it becomes
unfeasible to carry out a dictionary attack by using a program.
Information risks caused by external connections
Data communication monitoring from outside the network system is a considerable
information security risk to the system. Note that over the Common Management
Information Service Element (CMISE) connections, the user ID and password are not
encrypted. The ID is transferred in clear text, and the password in a concealed form, and
can be deciphered by monitoring the network traffic.
Over the file transfer, access, PAD, and Virtual Terminal (VTP) connections, user IDs and
passwords are transferred in clear text, that is, in an unencrypted form. To decrease the
risk, you must not define the authority for the profile of external connections (virtual
terminals) too high for the execution of MML commands. Virtual terminals have only one
common profile because you cannot choose which virtual connections a given VTP
device services. However, you have to define the authority requirement for the virtual
terminal profile according to the actual needs.
A common encrypting method is required at both ends to protect the data which is
transmitted on a data communication connection by using encryption. Unfortunately, no
encrypting algorithm has become standard enough to be found in all data communication
devices as a default setting. Therefore, separate encrypting devices have to be used at
both ends of the line.
Requirements for using security-related MMI system commands
The commands related to information security and authorities in the MMI system are
used to determine who can use the system and how. Therefore, most of the commands
described in this document require fairly extensive authorities.
The user in charge of information security who executes security-related commands
must have extensive authorities. The default authority requirement for the actual
execution commands is 250. The outputting and listing of commands can be executed
with lower authority.
DN9770704 Issue: 14-0 © 2016 Nokia 9

Information security Information Security
1.1 Authority management in the MMI system

Every MML command has a specific authority requirement, depending on how critical
the command is to the system; in other words, what kind of tasks can be carried out
using the command. The authority requirement determines the minimum authority which
the user must have during a given MML session to be able to enter the command.
The combined authority value of two profiles determines the authority of an MML
session. These include the profile of the user ID establishing the session and the profile
of the MML terminal. Each user ID is attached to a profile which determines which
commands the owner of the user ID can enter. Each MML terminal is also attached to a
profile which determines those commands that can be entered at that specific terminal.
When an MML command is entered, the system compares the command authority
requirement to the profiles of the user ID and terminal. If either of them prohibits the use
of the command, the command does not reach the execution phase.
User rights
In accordance with the principles of the MMI system, only authorised local or network
users are given access to the system. Users must know their user IDs and the
passwords connected to them in order to establish an MML session and enter MML
commands.
MML command authority
The authority requirement for an MML command defines how high the minimum authority
for an MML session must be in a given command class for you to be able to execute the
commands involved. The authority requirements are defined separately for each MML
command.
The default authority requirements of MML commands are defined when the software
build is generated. When the generation is complete, all commands must have one of
the following authority requirements: 50, 100, 150, 200, or 250. If necessary, you can
change the authority requirements, and give them any value between 1 and 250. The
values do not need to be multiples of fifty. The default authority requirements have been
defined on the basis of how critical the commands are; in other words, what kind of tasks
the commands are used for. The commands can be roughly divided into those that are
used to check the state of the system and to those that are used to change the state of
the system. To ensure security, those commands which you use to change the state of
the system should naturally have a higher authority requirement.
During SW build generation the commands are divided into the following groups:
Table 1 MML command authority requirement according to command status

Group number Command status Authority
requirement
Group 1 Very critical commands which you use 250

to significantly change the state of the
system, and commands which you use
to handle very sensitive data.
10 © 2016 Nokia DN9770704 Issue: 14-0

Table 1 MML command authority requirement according to command status (Cont.)

Group 2 Critical commands which you use to 200
change the state of the system to a
moderate extent, and commands
which you use to handle sensitive data.
Group 3 Commands which you use to change 150

the state of the system to some extent.
Group 4 Commands which you use to change 100

the state of the system very slightly,
and commands which you use to
check the state of the system.
Group 5 Commands which you use only to 50

check the state of the system.
You can check the authority requirement of MML commands by using the IAT
command.
User ID authority
Each user ID is attached to a profile which defines its authority. Several user IDs can
share a common profile and, accordingly, common authority data.
User ID authority is defined per command class in the profile. You are allowed to execute
all those commands in each command class whose authority requirement is not higher
than the authority defined in that profile to which your user ID is attached. Your authority
to enter commands also depends on the authority of the terminal which you use to enter
the commands.
For instructions, see Section Displaying user ID authority in the MMI system.
Network user authority
User profiles can be created also for network users.
The authority data of a network user is defined by the authority data defined for the user
ID in the local MMI system.
Network user authority data handling commands (IO command group) are used to create
new network users, to add or remove access rights, and to interrogate the network users
and their privileges.
MML terminal authority
Similarly to a user ID, every MML terminal is also provided with a profile which defines its
authority.
MML terminal authority is defined per command class in the profile, and it has to be
defined locally. A terminal allows users to execute those commands in each command
class whose authority requirement is not higher than the authority defined for the
terminal profile.
The MML terminal authority has an effect on the MML session authority. If the terminal
authority is lower than your user authority, the terminal limits your right to execute
commands. To increase security, you can choose terminal authority so that it prevents
local sessions on unmanned sites or on sites which are not guarded regularly.
DN9770704 Issue: 14-0 © 2016 Nokia 11

The maximum number of MML terminals is 16 (VDU0-VDU15). In addition, the command

calendar (CAL) and the virtual terminal (VTP) have been defined as terminals. All
terminals have a profile by default. There is no terminal without a profile.
g Note: All remote connections to MMI are routed through the VTP. If the VTP has
superterminal profile attached, all remotely connected users have superuser access
rights. If you need superterminal rights, attach it only to the VDUs.
For further instructions, see Section Displaying the authority of an MML terminal.
MML session authority
The user authority and the terminal authority together determine the MML session
authority. In each command class, either the user authority or the terminal authority,
whichever is lower, is valid during the session. Before a command is executed, the MMI
system calculates the authority combination; in other words, it checks the authority of the
user and the terminal. If the user authority is lower than the terminal authority, the
authority of the user who established the session is valid. On the other hand, if the
terminal authority is lower than the user authority, the terminal restricts the user's ability
to execute commands.
The figure below gives an example of how the MML session authority is created. The
solid line represents a user profile whose authorities are as follows:
• 250 in command class G

• 200 in command classes A, T, and Y
• 150 in all the other command classes
The broken line represents an MML terminal profile which has been defined to give the
following authority:
• 250 for command classes N, O, and Q

• 100 for all the other command classes
If you have the authority defined above and establish an MML session on the given
terminal, the figure shows that, in this session, you can only execute commands which
require authority 150 (or less) in command classes N, O, and Q; and commands which
require authority 100 (or less) in all the other command classes.
Figure 1 Example of MML session authority
250
200
150
100
50
A C D G I N O Q R T U W Y
profileofuserID
profileofMML terminal
authorityofMML session
12 © 2016 Nokia DN9770704 Issue: 14-0

However, special authority is an exception to this. If special authority has been defined
for a user, the terminal authority does not restrict the commands that this user can
execute during the session. Similarly, if special authority has been defined for a terminal,
the user authority does not restrict command execution for the user on this terminal.
For further instructions, see Section Displaying the commands allowed in an MML
session.
Special authority
The highest possible authority requirement for an MML command is 250. However, the
profile can be defined to have authority 251 in a given command class. This is known as
special authority, which can be attached to a user ID or a terminal. Special authority
enables a user to execute the commands in the defined command class without any
restrictions.
Superuser
A superuser is a user whose user ID profile has special authority (authority requirement
251) in one or several command classes. Thus the authority requirement of the MML
command and the authority restriction of the terminal do not apply to superusers.
Superusers can execute commands without restrictions in those command classes for
which they have special authority. Special authority also bypasses command blocking.
The person in charge has to know the superuser ID if the terminal profiles are
inadvertently updated to have a too low authority value, and subsequently no commands
can be executed, even with high authority. In such a case, commands can only be
executed with special authority.
For further instructions, see Section Creating a superuser in the MMI system.
Superterminal
A superterminal is an MML terminal whose profile has special authority in one or
several command classes. Thus, the authority requirement of the command and the
user's authority restriction do not apply to commands entered on the superterminal.
Blocked commands can also be executed on a superterminal.
g Note: Consider very carefully which terminal you define as a superterminal. If the
superterminal has special authority for all command classes, any user can execute any
command without restrictions. You must therefore plan the physical location of a
superterminal carefully, as physical location of the VTP cannot be done if IP connection
is used, only VDU connection can be secured physically in this case. All remote
connections to MMI are routed through the VTP. If the VTP has superterminal profile
attached, all remotely connected users have superuser access rights. If you need
superterminal rights attach it only to the VDUs.
For further instructions, see Section Creating a superterminal in the MMI system.
Service terminal authority and service terminal session authority
The authority system also applies to the service terminal. The service terminal has its
own centralised profile.
To open a service terminal session, the user's MMI user ID and password are requested.
If the MMI system cannot be reached from the service terminal, the fixed service terminal
username and its password are used to ensure service terminal usage in fault situations.
DN9770704 Issue: 14-0 © 2016 Nokia 13

Service terminal commands are intended to be primarily used for testing and fault
localisation, but they can also be used for other purposes.
The authority rights for service terminal use are bound to the user's authorities to
execute the DDS command, which starts a service terminal session from the MML
session. By using the DDS command you can use an ordinary MML terminal to start up a
service terminal session on any computer in the exchange. In this case, the service
terminal password is not requested. You can execute any service terminal commands on
an MML terminal by starting a session on the service terminal. You are therefore not
recommended to lower the default authority requirement (250) of the DD command group
to maintain high authority requirements.
It is recommended that you change the service terminal password of a fixed username
from time to time, using the IAF command. The command has no parameters. As this
command is for administrator use only, old passwords are not asked when being
changed.
When using a minidebugger with the old boot program memory (boot PROM), only a
fixed password is needed. With an upgraded boot PROM, both a fixed username and a
fixed password are needed. In some cases, if the minidebugger is started in an OMU
unit, a connection to the MMI system is established and the MMI username and
password can be used.
g Note: To prevent unauthorised use, the service terminal rights must only be given to
persons who cannot carry out their tasks without service terminal commands. In
addition, the service terminal should be used as little as possible, and its use should be
reserved for those tasks which cannot be performed by using MML commands.
The fixed username and its password are for administrator use, and can be used only in
error situations.
The following login situations may thus occur:
Table 2 Possible login situations
Situation Valid login method
MMI user authentication services are available MMI username and password
MMI user authentication services are not available Fixed username and its password (password can be
changed)
During the first 60 seconds after computer units start • Fixed username and its password (password can
up be changed)
• MMI username and password (if the MMI system
is already reachable)
Minidebugger with old boot PROM (Feature 30312: Fixed password (username is not used)
Service Terminal Usernames and Passwords is not
available)
Minidebugger with new boot PROM or debugger • Fixed username and fixed password
mode (Feature 30312: Service Terminal Usernames • MMI username and password (in some cases the
and Passwords is available) MMI system may be reachable)
14 © 2016 Nokia DN9770704 Issue: 14-0

Security reporting of service terminal sessions

A security report of service terminal users can be printed using the value Service
Terminal Sessions (SET) for the report type parameter of the IRO command. The report
displays all attempts to connect to the service terminal.
1.1.1 Profile management

MMI user profiles
By using profiling, you can flexibly divide the exchange personnel into different user
groups according to their operating tasks and expertise.
Within the system, you divide the O&M personnel into different user groups by attaching
each user ID to a profile. The profile specifies the authority which a user (or a terminal)
has in each command class (in the IA command class, for example). Note, however,
that the authority requirement is defined separately for each command (IAA, IAM, IAE,
and IAG, for example).
The terminal devices connected to the system, mainly MML terminals, can be grouped
according to the number of people who have access to the premises where the terminal
devices are located.
As you can define the same profile for several user IDs or terminals, all changes you
make in a particular profile affect all the users of that profile. This way, you can manage
and supervise the authority of the user IDs and terminals attached to the same profile.
The default maximum number of profiles in the system is 250. In practice, you determine
the number of profiles on the basis of how many user groups are needed among your
personnel.
The default profile (PROFILE) is defined for the system in the configuration phase of the
production process. All terminal devices, the command calendar and the default user ID
(SYSTEM) have been attached to this profile (PROFILE). The profile has a default
authority value of 250 in all command classes.
You can add a profile in the system by giving an individual authority value for each
command group (A-Y) or by providing all command classes with the same authority
value. The authority value can range between 1 and 251. The default value is 1. With the
UNIQUE parameter, you can define if the profile is for one user or terminal only, or a
normal shared profile. With the value YES, only one user ID or terminal can be attached
to the profile. With the value NO, the number of users or terminals attached to the profile
is unlimited.
g Note: You are recommended not to continue to use SYSTEM as the administrator user
ID for information security reasons. Use the default profile (PROFILE) or create a new
MMI user profile and user ID with high authorities for administrative purposes and
remove the authorities from the user ID SYSTEM.
As an example, the figure below shows a profile which grants the following rights to a
user ID or a terminal attached to it:
• the right to enter all commands in command class G

• the right to enter all those commands which require authority 200 (or lower) in
command classes A, T, and Y
• the right to enter those commands which require authority 150 (or lower) in all other
command classes
DN9770704 Issue: 14-0 © 2016 Nokia 15

Figure 2 Example of a profile
250
200
150
100
50
A C D G I N O Q R T U W Y
TCP/IP FTP and SFTP security with MMI user profiles
FTP and SFTP users are authenticated by using an MMI username and password. No
anonymous sessions are allowed. The MMI user needs an MMI profile where the access
right to the FTP or SFTP is defined. The rights are not given as default.
Every time a user logs in using FTP or SFTP, information on this can be seen in security
reporting.
With the MMI user profile it is possible to prevent unauthorised users from using the hard
disks of the network element through the FTP/SFTP file handling services. The users
must have a valid MMI user ID, a password, and access rights to the FTP/SFTP session
before the operations are permitted. However, the FTP and SFTP transmit user IDs and
passwords in clear text which is easy to intercept and decode.
There are the following types of FTP and SFTP access rights:
• none
• read
• write
Read and write access is to all files and directories. Access to the sessions is considered
as an administrator level right, because the user can read any file which is not protected
by encryption.
For instructions, see Section Creating and modifying an MMI user profile.
HTTP profiles
HTTP uses XML profile file. In a HTTP profile the access is given to a user group. The
authorisation object is the path to a command menu tree.
1.1.2 Security policy management

Passwords in the MMI system
A password attached to the user ID prevents users from accessing the MMI system by
using other than their own user ID. You can create a local user's password and user ID
with the IAH command. Note that a local user may have two separate (parallel)
passwords. The password validity time is defined by the profile to which the user ID is
attached. When you create or change a password, it is not displayed.
When creating a new profile or modifying an existing profile, you can also define a
validity time for a password. The validity time determines how long the password is valid.
When the validity time ends, the password expires and must be changed. The password
16 © 2016 Nokia DN9770704 Issue: 14-0

validity time (VTIME) can range between 1 and 250 days. The default value is 100 days.
Value zero (0) means that the password has to be changed after every login, and value
FOREVER means that the password is always valid and never expires. Remember,
however, that changing the user password of the MMI system at regular intervals
increases information security in the system.
You can also manually end the validity time of the password created for a certain profile.
The passwords of all the users attached to this profile expire then and need to be
changed.
1. First set the password validity time to zero (0) using the IAA command.
2. Change the validity time back to what it previously was using the IAA command
again.
3. The passwords of all users attached to this profile have now expired.
4. The system asks the users to change their passwords when they next log into the
system.
If Feature 31390: Password Policy has been activated, you can define a password policy
and attach it to a user profile. You can also determine how often the password can be
changed. The password policy is created with the IVK command of the User
Authentication Policy Handling MML, and attached to a user profile with the IAA
command of the MMI System Authority Handling MML (PWPOLICY parameter). The
minimum validity time of the password is also defined in the IAA command (MINVTIME
parameter). If Feature 31390: Password Policy has not been activated, the PWPOLICY
and MINVTIME parameters cannot be given.
For instructions, see Sections Creating and deleting local MMI user IDs, and Changing a
password in the MMI system.
Requirements, restrictions, and recommendations concerning passwords
g Note: The default password for the default user ID SYSTEM must be changed as soon
as possible. You are also recommended not to continue to use SYSTEM as the
administrator user ID for information security reasons.
• The length of a password is minimum 6 characters. The maximum length of a

password is 15 characters in Q3 and FTP interfaces, and 16 characters in all the
other interfaces. A password can consist of letters, digits, and most of the characters
which can be typed. ASCII characters HEX 21-HEX 7E can be used. The password
cannot be identical with the user ID.
• Passwords are case-sensitive. When defining (creating or modifying) a password,
note whether upper or lower case letters are given. For example, the password
SysTeM does not equal to SYSTEM. It is recommended that you make full use of
case-sensitivity because it drastically improves information security of the system. As
the number of characters that can be used is extremely large, password cracking is
very difficult.
• Do not disclose your password to anyone and do not write it down anywhere
someone else can read it. Try to select a password which cannot be guessed;
therefore, do not use information which can easily be connected to you (the name of
your spouse, for example). If you suspect that someone might know your password,
change it immediately. Passwords have to be changed at regular intervals.
Additionally, the users have to log out when stepping away from the screen.
DN9770704 Issue: 14-0 © 2016 Nokia 17

• A password should not have any linguistic meaning in any language. Remember also
that a compound word is not much harder to decipher than the same words taken
individually or two words separated by a digit. Do not select a word typed backwards,
or a word with an extra character added to the end or beginning. Do not use a
character combination which can easily be found on the keyboard (QWERTY, for
example).
• A password can, for instance, consist of the initial letters of the words in a sentence.
A good password consists of a mixture of letters and digits; for instance, you can
replace an O by a 0, an I by a 1, and so on. A password can also be a word which is
mistyped on purpose. However, it is a good idea to select a password which can be
typed quickly.
Local password policy
Password policy defines what kind of formal requirements a password must fulfil. The
purpose of the requirements is to make sure that the passwords used in the system are
not too simple and thereby easy to crack.
Optionally, you can also determine that the system checks the history of every new
password the user creates. This way, you can prevent the user from creating a password
that has been used in the network element before.
In the password policy, you can define
• when certain MML commands are given, the password policy is checked
• when certain MML commands are given, the password history is checked
• the minimum length of the password
• the minimum number of alphabetic characters in the password
• the minimum number of special characters in the password
• the minimum number of numeric digits in the password
• the maximum number of repeated characters in the password
• the maximum number of characters given in alphabetical order in the password
• the maximum number of digits in numerical order in the password
• whether the user ID, or the user ID in mirror writing can be used as a substring in the
password.
g Note: The password policy check is not case-sensitive. For example, if the password
policy defines that the password can only include four letters in alphabetical order, it
makes no difference whether the letters are typed in upper case or lower case.
Password Policy is an optional feature.

For instructions on how to define a password policy and how to enable the checking of
password history, see Section Configuring password policy.
Parallel passwords
Local users attached to a certain profile may have two (parallel) passwords, that is, in
addition to the MMI password, a user may have a separate password for establishing
remote sessions to network elements of an older system level. New passwords are
encrypted by using a new encryption method which older systems do not support.
However, if the user has two passwords, the system is able to recognise the validity of
both passwords. Therefore, the user does not need to re-enter the user ID and password
when opening a remote session to the system of an older system level.
18 © 2016 Nokia DN9770704 Issue: 14-0

You can specify whether the users attached to the profile have separate passwords
using the PARAPW parameter.
The new encryption method increases the overall level of information security in the MMI
system because it makes password cracking more difficult.
Parallel passwords are handled with the commands of the IA command group. When
creating a new profile, you can determine whether the user IDs attached to that profile
have two separate passwords. If the users have been defined as having two passwords,
the system asks you to give and verify both passwords when creating and modifying
user IDs. If the users have been defined as having only one password, a password of the
old type is not interrogated in the dialog.
A password of the old type is needed only when a remote session is established to a
system that does not support the new encryption method. If the user does not have two
passwords, the user ID and password are asked every time the user establishes a
remote session to a network element of an older system level.
Both passwords have their own validity times. If the password of the new type has
expired, the user can still start a local session but the only action the user is allowed to
perform is to change his own password. If the password of the old type has expired, this
affects remote sessions from network elements of an older system level to network
elements of a new system level. Such sessions can still be established but the password
of the old type must be changed before any other MML commands can be executed.
g Note: You cannot set the two passwords to be the same.
Information security is also ensured by the encryption method (encryption key)

management. It is not possible to use weak keys or to find out the currently used key.
With the IAK command you can change the encryption key index or display the currently
used key index. Note that you cannot select the used key yourself, it is generated by the
system. As the value for the ENCRYPTION KEY parameter of the IAK command, enter
a generating index for the new key. The index can be chosen from the range of 1 to 100.
If you enter the value LIST instead of determining a new index, the system outputs the
index that is currently used.
Password encryption key
The MMI system uses a one-way password encryption method. This means that it does
not need to know the actual password but only has to be able to differentiate valid
passwords from invalid ones.
Password encryption is based on the widely known International Data Encryption
Algorithm (IDEA). One-way implementation of it has been done by using the tandem
Davies-Meyer method. In practice, that kind of encryption makes cracking of password(s)
impossible. However, this method is not supported by older systems, therefore, it is
useful to define two parallel passwords so that remote sessions can be established to
older systems without re-entering the user ID and password.
A password file cannot be used in a network element which has a different C-number.
The encryption result is different from another network element.
MML session idle time limit
DN9770704 Issue: 14-0 © 2016 Nokia 19

The MML session idle time value can be changed by using MML commands. The
change takes immediate effect on your current session; other users must log in again
before the change is effective. The MML session is not ended due to an idle time limit
during interaction or during the execution of an MML command. The value range of the
MML session idle time limit is 1 to 60 minutes.
The MML session idle time limit can be changed with two MML commands, the IAX
command and the IAA command (using the TLIMIT parameter). The idle time limit of a
certain profile can be interrogated using the IAI command.
MMI session policy
The MMI session policy limits the amount of simultaneous sessions of a user. Session
policy value is set for user's profile, all users of the same profile use the same policy. The
default value can be set to one or all user IDs.
Concurrent MMI session limitation can be set with the IAW MML command using
TARGET_GROUP and SESSION_COUNT parameters
ZIAW:TARGET GROUP:SESSION COUNT;
For more information, see the IAW command of IA - MMI System Authority Handling
command group.
MMI session policy is an optional feature. It uses the same option as user account policy.
If user account policy is OFF, session policy feature is also OFF.
Delay between unsuccessful login attempts
An increasing delay between unsuccessful user authentication attempts is also
implemented. This makes it unfeasible for an attacker to carry out a dictionary attack by
using a program, that is, automatically generates user ID and password trials or mere
password trials if the attacker already knows the user ID. As the system is able to
recognise the line from which the login attempts originate, the delay keeps increasing
despite the user ID given for the username request. The attacker cannot thus completely
prevent actual users from logging in. Each Telnet connection is handled separately. After
20 separate caller IP addresses have logged in, all caller IP addresses have a short login
delay. Lines using PAD protocols are handled as one unidentifiable source; lines using
ISO VT protocols are all grouped as a second source.
After three consecutive unsuccessful login attempts from the same line, the user notices
a delay of 10 seconds by default before the next user ID inquiry and data are saved to
the security report. After this, each new unsuccessful trial from the same source causes
a doubling of the delay. When the delay reaches 24 hours by default, it does not increase
anymore. The system informs the security reporting system when the username entered
to start a session is different from the last one used in the same source. The attacker
cannot reset the delay by trying to attack several usernames concurrently; the first
successful login attempt on the line where there is an increasing delay causes resetting
of the delay and saving of the security report information. Security reports include the
caller address and the user ID entered during the current trial.
The system displays a text on the screen to inform the user of the current delay. If the
delay is less than one minute, the text contains the value of the delay. If the delay is
more than one minute, the message contains the end time of the delay.
Example:
'DELAY OF 40 SECONDS APPLIED. PLEASE WAIT.'
Example:
20 © 2016 Nokia DN9770704 Issue: 14-0

'DELAY APPLIED. PLEASE WAIT UNTIL 14:32.'
Data on delayed login attempts is saved to a detailed security report. This report can be
displayed using the IRO command with the value MDE (MML login delays) for the
parameter report type.
The MML login delay report displays the third unsuccessful login attempt from a source,
all unsuccessful login attempts where the username is different from the last one used in
the same source, and a successful login after the unsuccessful attempts. The report also
shows the callers' connection address, that is, the address of the line from where the
login attempt originated. For PAD and ISO VT connections, the address field contains
the string 'unidentified' and the name of the protocol.
You can reset the delay of all lines by using the IAQ command.
The first and maximum values of the delay are read from the
FIRST_MMI_LOGIN_DELAY and MAX_MMI_LOGIN_DELAY PRFILE parameters,
respectively).
If excessive login attempts originate from different Telnet lines, all consecutive Telnet
connections receive a delay. The value of the delay for table overflow is read from
PRFILE (OVERFLOW_MMI_LOGIN_DELAY parameter).
The PRFILE parameters are in parameter class 44 (MML session). You can modify the
value of the first MMI login delay using the FIRST_MMI_LOGIN_DELAY PRFILE
parameter, the value of the maximum MMI login delay using the
MAX_MMI_LOGIN_DELAY PRFILE parameter, and the value of the overflow MMI login
delay using the OVERFLOW_MMI_LOGIN_DELAY PRFILE parameter. Use the
commands in the WO command group to output and modify PRFILE parameter values.
Use the WOI command to interrogate the data of the parameters which are defined in
PRFILE, and output the data of the parameters. For example, to display the parameters
in parameter class 44 and their values, enter the following command:
ZWOI:44;
Use the WOC command to modify the parameter values. For example, to modify the value
of the first MMI login delay (parameter 1 in parameter class 44), enter the following
command:
ZWOC:44,1,<value>;
Example:Changing the value of the first MMI login delay
To change the value of the first MMI login delay to 15 minutes, enter the following
command:
ZWOC:44,1,D'15;
Planning information security for the MMI system
The first step to ensure information security is to change the default authority
requirements for the MML commands to those which you consider appropriate for your
personnel.
Divide the exchange personnel into as many user groups as necessary. The number of
groups depends on the number of users and on the tasks they perform. Form the user
groups in accordance with the expertise of the personnel and the tasks to be performed,
so as to provide all users with adequate authority to use the commands of those
command groups they need to carry out their work. Do not grant unnecessarily extensive
rights to other command groups. A user's authority to execute commands is determined
DN9770704 Issue: 14-0 © 2016 Nokia 21

according to the profile to which the user ID is attached. Create an adequate number of
profiles to choose from. Think also about suitable password validity times for each user
or user group.
Divide the MML terminals into groups according to the type of tasks performed by the
persons using them. Also define profiles for the MML terminals. The same profiles can
be used for both terminals and users, or you can define separate profiles for them. For
example, if the same terminal is used by different persons for different tasks at different
times, the profile of the terminal must be defined to have sufficient authority for all the
command groups involved. Further, by choosing the terminal authority right, you can
prevent local sessions on unmanned sites.
Create a user ID for each user and attach each user ID to an appropriate profile. The
user ID's authority to enter MML commands is determined on the basis of the profile to
which it is attached.
Also check whether network user profiles need to be created. The user IDs attached to
such a profile must first be local users (first use the IAH command to create local users,
then the IOA command to create a network user profile).
g Note: All new user ID and password owners should immediately change their
passwords to maintain security in the system.
Also, consider carefully which users have extensive authority to use the commands of
the IA command group. An authority to change the authority requirements of other
users or MML commands gives the user a possibility to make changes which this user
would otherwise not be allowed to do. Remember, however, that the authority
requirement of the IAG command should be low enough to enable users to change
their passwords themselves, which increases information security.
The table below suggests how information security as a whole can be ensured in the
MMI system.
Table 3 Ensuring information security in the MMI system

Action Command
1. Check command authority requirements. IAT
2. Create profiles. IAA/IOA
3. Define password policies for user profiles. IVK
4. Create user IDs with correct profiles. IAH
5. Attach terminals to correct profiles. IAE
6. Enable password history checking. IVH
7. Inform users of their user IDs and ask them to change their IAG
passwords.
User account policy

There are the following functionalities related to user account policy:
22 © 2016 Nokia DN9770704 Issue: 14-0

• Inactive user accounts are disabled; with the IAA MML command you can define the
maximum period of time after which a user account gets disabled if it is not used.
• The user account is locked when the specified amount of unsuccessful login
attempts is exceeded.
• Disabled user accounts can be listed and enabled.
• The last login date and time together with the number of unsuccessful attempts is
displayed during the login phase; you can also print out this information with the IVT
MML command.
• Local users with an open session can be listed.
• Profiles can be defined to be administrative profiles.
• An alarm is raised when users attached to an administrative profile log in.
These funcionalities affect only local users. Remote users and their accounts are stored
in the LDAP directory and are managed by NetAct.
Please note that Feature 31391: User Account Policy is an optional feature.
For instructions on how to manage user account policy, see Section Configuring user
account policy.
File transfer and O&M connection security
Information security issues have to be taken into account not only in the MMI system but
also in other operation areas such as statistics, charging, and signalling, as well as
database administration. Secure handling of such data is accomplished by ensuring
information security in the secure file transfer and secure O&M connections.
This section deals with information security issues concerning the TCP/IP protocol
stacks..
TCP/IP environment
The TCP/IP protocol suite consists of the basic TCP/IP protocol stack and TCP/IP
applications, FTP, and Telnet. Telnet enables you to log into the MMI system across the
network from a remote host over LAN. With the FTP, the disk files can be copied to and
from the network element, the remote host asking for the file transfer service.
TCP/IP is intended to be used in a trusted private intranet environment only. There are
not any security functions implemented as such (for example, encryption or strong
authentication). Data integrity cannot be quaranteed. After activation, all Telnet and FTP
connections originating from any IP address are accepted and, therefore, you have to be
familiar with TCP/IP security issues.
Telnet application security
User authentication is done by checking the user ID and password. However, Telnet
transmits user IDs and passwords in clear text which is easy to intercept. A Telnet user
has an MMI profile. The command log stores the command executions of the Telnet user.
The user's log can be seen in security reporting.
Firewall/VPN solution
The firewall/VPN solution is one example of a secure network. The router/firewall (R/FW)
is doubled to enable redundancy. Encrypted firewall-to-firewall tunnels are available.
These tunnels are useful for building protected Virtual Private Networks (VPN). All traffic
is encrypted, wrapped with another IP header, and then sent over an untrusted network.
The firewall at the remote site unwraps and decrypts the datagram to get the original IP
datagram. The firewall then forwards this datagram to its final destination.
DN9770704 Issue: 14-0 © 2016 Nokia 23

Internal security
You can use secure hubs to prevent the operating personnel from monitoring the
sessions. Secure hubs operate as normal hubs, but to ensure security they generate
nonsense in other ports when one port is used.
TCP/IP FTP security for users with different rights
An FTP user can have read or write access to all the files or no access to FTP at all. It is
not possible to give access rights for specific files.
1.2 Secure operation and maintenance connections

Secure Shell (SSH) Server
As an alternative for 'MML over Telnet', 'MML over SSH' can be used for operation and
maintenance connections in network elements.
The Secure Shell (SSH) is increasingly used to replace Telnet for terminal access
applications. The SSH Server provides a mechanism for the client-user to interactively
enter commands and receive output from a remote host while taking advantage of the
SSH transport's privacy and integrity features. SSH encrypts all traffic between server
and client (including usernames and passwords) to effectively eliminate eavesdropping,
connection hijacking, and other network-level attacks.
A cryptographic handshake is made between the SSH Server and the client. The SSH
Server and the client form a confidential (encrypted) channel between each other and
authenticate each other. Authentication of the SSH Server and client applications follow
pre-configured authentication policies, which in practice determine which exact servers
(corresponding RSA/DSA public keys) are found to be trusted (if not all of them) by the
client. The SSH Server authenticates the client by asking username and password.
Differences between SSH and Telnet
• The communication channel between the client and the server is encrypted and
authenticated. This means, for example, that in user authentication phase,
usernames and passwords are not transferred in plaintext format.
• Telnet clients do not authenticate the server.
When the SSH Server is used, Telnet can be disabled (and enabled) with MML
commands. The SSH Server is an optional feature. Optionality is handled with a FIFILE
parameter.
For instructions on how to manage SSH server, see Configuring SSH Server.
SFTP (SSH File Transfer Protocol) Server
As an alternative for FTP, SSH File Transfer Protocol (SFTP) can be used for file transfer
operations in network elements.
The SFTP Server can be used for secure file transfer operations. The SSH Server is
used for establishing a secure connection; SFTP itself is a normal protocol for file
transfer operations without any specific security methods.
The SFTP Server and the client use the SSH protocol for creating a secure
communication channel between each other, thereby increasing confidentiality, peer
authentication, and integrity protection. Using this secure channel, file transfer operations
24 © 2016 Nokia DN9770704 Issue: 14-0

can be executed securely over a non-trusted TCP/ IP network. When files are transferred
using the SFTP Server, there is no need to configure separate control and data
connections in firewall environments.
When the SFTP connection is opened, a cryptographic handshake is made between the
SSH Server and the client. The SSH Server and the client form a confidential (encrypted)
channel between each other, and this channel can be used for SFTP operations.
Authentication of the SSH Server and client applications follow pre-configured
authentication policies which, in practice, determine which exact remote hosts are
trusted (if not all of them) by the client. The SSH Server authenticates the client side by
requesting a username and password. The SSH Server also checks the user’s rights for
SFTP connections.
Differences between SFTP and FTP
From TCP/IP network security point of view, the conventional FTP is quite insecure.
Basically, the conventional FTP does not contain any built in security features, for
example:
Table 4 Differences between SFTP and FTP

FTP SFTP
no server authentication server authentication is possible
no encryption in connection and user connection and user authentication are

authentication encrypted
it can be handled with MML commands optional feature, it can be handled with FFILE
parameter
For instructions on how to manage SFTP server, see Configuring SFTP Server.
1.3 User management in the MMI system

1.3.1 User IDs in the MMI system
Each user must have a user identifier or, in other words, a user ID. A user ID consists of
six characters. A local user ID must begin with a capital letter, the rest of the characters
can be either digits or capital letters (A-Z). The user ID must be unique within the
network element.
When creating a local user account, you also give a password and attach the user ID to
a profile. A local user account is a user who opens the connection using a local terminal.
A local user must have an MMI user profile and can have a network user profile or a
HTTP profile. The profile defines the user's authority to execute MML commands.
For instructions on how to create local user IDs and how to change a local user's
password, see Sections Creating and deleting local MMI user IDs, and Changing a
password in the MMI system.
DN9770704 Issue: 14-0 © 2016 Nokia 25

1.3.2 Service terminal usage in the MMI system

The authority system also applies to the service terminal (that is, service terminal
authority and service terminal session authority). To open a service terminal session, the
user's MMI user ID and password are requested. If the MMI system cannot be reached
from the service terminal, the fixed service terminal username and its password are used
to ensure service terminal usage in fault situations.
The authority rights for service terminal usage are bound to the user's authorities to
session. Using the DDS command you can use an ordinary MML terminal to start up a
recommended to lower the default authority requirement (250) of the DD command
group, in order to maintain high authority requirements.
You are recommended to change the service terminal password of a fixed username
changed.
In a minidebugger case, only one password is in use. After upgrading the boot program
memory, both a fixed username and a fixed password are in use. The fixed password
cannot be changed.
g Note: To prevent unauthorised use, the service terminal password must only be given
to persons who cannot carry out their tasks without service terminal commands. In
reserved for those tasks which cannot be performed by using MML commands. The
fixed username and its password are for administrator use only.
As for the possible login situations, see Table Possible login situations in Section
Authority management in the MMI system.
1.4 Audit trails

There are the following command logs:
• MML command log

• FTP command log
• SFTP command log
• HTTP command log
26 © 2016 Nokia DN9770704 Issue: 14-0

1.4.1 MML command log

MML command executions and execution results are collected in an MML command log.
All MMI users share a common MML command log within one network element. The log
is stored within the network element in a group of disk files.
The starting and ending times of MML command executions are stored in a fixed format
in the MMLLOG permanent logical file, which you can connect to a suitable place.
You can output all or selected parts of the command log in the MML terminal or in a
logical file of your choice. The output can later be processed further outside the network
element or be used inside the network element as an executable command file.
The commands of the IG command group are the only allowed and supported way to
access the MML command log.
Alarms related to MML command log handling:
2683 ERROR IN MML COMMAND LOG ACCESS alarm is related to the MML command
log.
This alarm means that an error occurred when the LOMANA tried to read from or write to
the MML command log. For a detailed alarm description and recovery instructions, see
Failure Printouts (2000-3999).
1.4.2 FTP command log

All the connections together with the used commands are recorded in the FSRLOG.XML
FTP log file. The FTP server saves its log to the following file:
• DW0–/<packet dir>/ASWDIR/FSRLOG.XML
1.4.3 SFTP command log

All the connections together with the used commands are recorded in the SIKLOG.XML
SFTP log file. The SFTP server saves its log to the following file:
• DW0–/<packet dir>/ASWDIR/SIKLOG.XML
1.4.4 HTTP log files

All the operations together with the IP addresses and times are recorded in the log files
maintained by the Network Element Web Manager. HTTP logs collect information about
the used commands. The Web Manager user menu contains a list of the different logs
with HTML links to them. The logs are stored on network element disks.
When you select a HTTP log file, it opens automatically in the window. You can save the
log file on your local workstation in XML format. You can select more than one log file
and save them all in one file. In this case the HTTP log files are automatically
compressed into a ZIP file.
For more information on managing HTTP log files, see Section Managing HTTP session
log.
DN9770704 Issue: 14-0 © 2016 Nokia 27

1.4.5 Security reporting

Security reporting supervises information security by reporting attempts to violate the
security of the network element. You can use security reporting to identify problems
involving information security. Security reporting collects security-related data from
various sources, such as the MMI system and the alarm system.
Security reporting provides you with information on:
• service terminal sessions

• MML sessions
• network access
The facility collects security-related data to be reported on, prepares the reports, and
manages the reporting function.
Alarms related to security reporting
The following alarms are related to security reporting:
• 1569 CRITICAL LIMIT IN SECURITY REPORTING REACHED

This alarm means that the security counter has reached the critical limit. If this alarm
is set several times a day, the network element might be under security attack.
Always check the reason why the alarm is set.
• 1570 SECURITY LOG ALARM LIMIT REACHED
This alarm means that the number of events recorded in any security reporting log
files during a monitoring interval has reached the alarm limit. If this alarm is set
several times a day, there can be a configuration problem somewhere in the network.
Check the network's configuration.
To check the alarms, use the commands in the AH command group. For detailed alarm
descriptions and recovery instructions, see Disturbance Printouts (1000-1999).
1.5 MMI disclaimer display

You can define a text message to be displayed upon the start of an MML session, before
the user ID and password are asked. The contents of this message can be freely defined
by an administrator; the purpose of the text is to provide information for the users.
The system also offers the possibility of asking for confirmation (yes/no) from the user
before continuing to establish the MML session. The contents and format of the
confirmation question can also be freely defined by an administrator. If the user replies Y
(yes), establishing the session continues normally; otherwise the session is ended. If the
confirmation request has been activated, it appears on the screen after the MMI
disclaimer display text. When creating the confirmation question, note that the
confirmation must always be given in the format Y (yes) or N (no), regardless of the
language of the question.
Using the DISCLAIMER_TEXT PRFILE parameter, you can activate the MMI disclaimer
display, either with or without the confirmation request and deactivate it. This PRFILE
parameter is in the parameter class 44 (MML session). You can modify the values by
using the PRFILE parameter 5/44.
28 © 2016 Nokia DN9770704 Issue: 14-0

You can create and modify the disclaimer text and the confirmation question with the
system's disk file editor, which is started with the IEE command. Alternatively, they can
be created and modified with a text editor (not a word processor) outside the system.
The file is then transferred using FTP or a floppy disk.
For instructions on how to activate or deactivate the disclaimer text and to set the
confirmation request, see Section Activating the MMI disclaimer display.
g Note: The disclaimer text and the confirmation request are network-element-specific
and need to be defined for each network element separately.
If the disclaimer text and confirmation question have been activated but the text files
cannot be found in the system, the following text is output:
DISCLAIMER TEXT/QUESTION FILE CANNOT BE FOUND.
The establishing the MML session continues normally thereafter.
DN9770704 Issue: 14-0 © 2016 Nokia 29

MMI disclaimer Information Security
2 MMI disclaimer
2.1 Creating the MMI disclaimer text and the

confirmation question
Purpose
by an administrator; the purpose of the text is to provide information for the users.
The system also offers a possibility of asking for confirmation (yes/no) from the user
before continuing to establish the MML session. The contents and format of the
confirmation question can also be freely defined by an administrator.
You can create the disclaimer text and the confirmation question either by using the
system's screen editor or by using some other text editor outside the system.
Before you start

When creating the confirmation question, note that the confirmation must always be
given in the format Y (yes) or N (no), regardless of the language of the question.
To implement this step, choose one of the following alternatives:
If creating the text with the screen editor:
Procedure
1 Invoke the screen editor (IEE).

Invoke the screen editor using the IEE command.
2 Create a temporary file.

Create a file, write the disclaimer text or the confirmation question, and save the file
as DISCLAIM.TXT or QUESTION.TXT.
3 Copy the file to the ASWDIR directory.

Copy the file you created to the ASWDIR directory.
30 © 2016 Nokia DN9770704 Issue: 14-0

Information Security MMI disclaimer
If creating the text with a text editor outside the system:
Procedure
1 Create the file using a text editor outside the system and save it.
2 Transfer the file to the system using FTP or a floppy disk.
2.2 Activating the MMI disclaimer display

Purpose
by an administrator; the purpose of the text is to provide information for the users. For
further information on the disclaimer, see Section Creating the MMI disclaimer text and
the confirmation question.
Procedure
1 Interrogate PRFILE parameter values (WOI).

Use the commands in the WO command group to output and modify PRFILE
parameter values. Use the WOI command to interrogate the data of the parameters
which are defined in the PRFILE, and output the data of the parameters. For
example, to display the parameters in parameter class 44 and their values, enter the
following command:
ZWOI:44;
2 Modify the DISCLAIMER_TEXT PRFILE parameter (WOC).

Use the WOC command to modify the parameter values. To modify the value of the
MMI disclaimer display (parameter 5 in parameter class 44), enter the following
command:
ZWOC:44,5,<value>;
The values of the PRFILE parameter are as follows:
0H MMI disclaimer display is not activated.
1H MMI disclaimer display is activated without the

confirmation request.
2H MMI disclaimer display is activated with the confirmation

request.
DN9770704 Issue: 14-0 © 2016 Nokia 31

Managing local user profiles Information Security
3 Managing local user profiles
3.1 Managing local MMI user ID authority data

3.1.1 Displaying user ID authority in the MMI system
Purpose
Each user ID is attached to a profile which defines its authority. Several user IDs can
share a common profile and, accordingly, common authority data.
The authority data of a network user is defined not only by the network profile to which
the user ID is attached, but also by the authority data defined for the user ID in the local
MMI system.
You can check the authority of an individual user ID by listing the user ID data using the
IAI command for local users and using the IOI command for network users.
g Note: Remote users cannot be managed locally.
Procedure
1 Display authority of a user ID of an MMI user (IAI).

Display the authority of a certain user ID (for example, JSMITH):
ZIAI:USERID=JSMITH:COM;
Expected outcome
The execution printout shows that the JSMITH user ID has authority 250 in all
command classes:
USER ID: JSMITH

PROFILE NAME: HIGHRIGHTS
COMMAND CLASS AUTHORITIES:
A=250 B=250 C=250 D=250 E=250 F=250 G=250 H=250 I=250 J=250
K=250 L=250 M=250 N=250 O=250 P=250 Q=250 R=250 S=250 T=250
U=250 V=250 W=250 X=250 Y=250
PARALLEL PASSWORD EXISTENCE: YES
PASSWORD VALIDITY TIME LEFT: 21 DAY(S)
MML COMMAND LOG ACCESSIBILITY: LIMITED
UNIQUE PROFILE: NO
NETWORK USE ALLOWED: YES
32 © 2016 Nokia DN9770704 Issue: 14-0

Information Security Managing local user profiles
MML SESSION IDLE TIME LIMIT: 10 MIN(S)
FTP AND SFTP ACCESSIBILITY: NO
COMMAND EXECUTED
If the optional Feature 31390: Password Policy is activated in the network element,
the execution printout of the IAI command has two new fields: MINIMUM
PASSWORD VALIDITY TIME and PASSWORD POLICY NAME.
If the optional Feature 31391: User Account Policy is activated, the execution
printout of this command has the following new fields: ADMINISTRATIVE PROFILE
and DISABLE TIME.
3.1.2 Determining user ID authority in the MMI system

Purpose
The authority of a new user ID is determined on the basis of the profile. The profile for
the user ID must already exist. If it does not exist, you must create it before creating the
user ID.
You use the IAA command to create a new profile (with the appropriate authority), which
is needed for the user ID. An existing profile can also be used. You can check the name
of a suitable profile in the system by using the IAI command.
Once the desired profile exists, you can create a new user ID with the chosen profile.
Procedure
1 Create a new profile (IAA).

Create a new profile and define the appropriate authority value (for example, 150 in
all command classes):
ZIAA:<profile>:ALL=150;
2 Create a user ID and attach it to the profile (IAH).

Create a user ID and attach it to the profile previously created:
ZIAH:<user_id>:<profile>;
Further information
Example:Determining user authority by using a new profile
1. Create the LIMPROFILE profile with authority value 150 in all command classes:
ZIAA:LIMPROFILE:ALL=150;
2. Create the LJONES user ID and attach it to the LIMPROFILE profile:
ZIAH:LJONES:LIMPROFILE;
DN9770704 Issue: 14-0 © 2016 Nokia 33

Example: Determining user authority by using an existing profile
1. To select a suitable profile for the new user ID, display the complete data on all the
existing profiles:
ZIAI:PROFILE=ALL:COM;
2. Create the new LJONES user ID and attach it to the chosen profile (which in this
case is USRPROFILE):
ZIAH:LJONES:USRPROFILE;
3.1.3 Changing user ID authority in the MMI system

Purpose
There are three different ways to change the authority of an existing user ID:
1. You can use the IAA command to create a whole new profile with the desired
authority, and then attach an existing user ID to the new profile.
2. You can use the IAI command to search the existing profiles for a suitable one, and
then attach an existing user ID to that profile.
3. You can use the IAA command to change the authority of the user ID's current
profile. Note that if you do this, it has an effect on the authority of all the other
user IDs and terminals that have the same profile. When necessary, you can check
the current authority before updating it by using the IAI command.
Procedure
1 Create a new profile with the desired authority (IAA).

Create a new profile and define the appropriate authority value (for example, 150 in
all command classes) and FTP and SFTP accessibility (for example, W = read and
write access):
ZIAA:<profile>:ALL=150:::FTP=W;
2 Attach the existing user ID to the new profile (IAE).

Attach the existing user ID (for example, LJONES) to the new profile:
ZIAE:USERID=LJONES:<profile>;
Further information
Example:Changing user ID authority by creating a new profile
1. Create a new profile, NEWPROFILE, with authority value 150 in all command
classes:
ZIAA:NEWPROFILE:ALL=150;
2. Attach the existing LJONES user ID to the new profile:
ZIAE:USERID=LJONES:NEWPROFILE;
Example:Changing user ID authority by updating the current profile
1. Check the profile to which the LJONES user ID is attached and its authority data:
34 © 2016 Nokia DN9770704 Issue: 14-0

ZIAI:USERID=LJONES:COM;
2. Update the current TELEPROF profile to which the LJONES user ID is attached.
Define authority value 200 for command classes A and I:
ZIAA:TELEPROF:A=200,I=200;
3.1.4 Displaying the commands allowed in an MML session
Procedure
1 Display all commands allowed in your MML session (IAL).

Display all the commands you are allowed to use in your MML session:
ZIAL;
Expected outcome
The printout of this command is, for example, the following:
COMMANDS ALLOWED IN THIS DIALOGUE SESSION
CEC CEL CEP CET

CRC CRI CRL CRM
DCA DCC DCD DCS
IAG IAL
TMC TMD TME TMI TMM TMS
COMMAND EXECUTED
3.2 Creating, modifying and deleting local MMI user

profiles
Purpose
An MMI user profile specifies the authority which a user or a terminal has in each
command class.
You can define the same profile for several user IDs or terminals. The changes that you
make in a particular profile affect all the users of that profile.
g Note: Centralised user profiles cannot be managed locally.
3.2.1 Creating and modifying an MMI user profile

Purpose
You can create and modify a profile using the IAA command. The maximum length of a
profile name is 10 characters. The first character must be a capital letter (A-Z) and the
following ones either capital letters or digits.
DN9770704 Issue: 14-0 © 2016 Nokia 35

If the system does not find the profile which you have entered in the IAA command, the
MML program creates it by using the parameters you have given. If the profile already
exists in the system, the MML program modifies it by using the parameters you have
given. Before modifying an existing profile, the system indicates that this profile already
exists and asks you to confirm if you want to modify the profile or not (Y/N confirmation).
When creating a new profile, you can use an existing profile as a base profile (BASEP).
The system copies the authority data of the base profile and uses it as a basis for the
new profile. The new profile is then modified according to the values which you give as
parameters; the contents of the original profile used as a base are not affected in this
case.
In User Account Policy (UAP) feature ADMPROF and DABLETIME parameters can be
added to the profile. These parameters are optional and usable only if optional UAP
feature is enabled in the network element. For more information, see Section Configuring
user account policy.
Before you start

Before creating a new profile, check the existing profiles. To display all profiles created in
the system, use the IAI command. The LIM (limited display) value means that the
names of the profiles and the user IDs attached to them are displayed, while the COM
(complete display) value displays the contents and users of the profiles.
Procedure
1 Interrogate all profiles in the system (IAI).

Display all the existing profiles but not their contents:
ZIAI:PROFILE=ALL:LIM;
Expected outcome
When interrogating the existing profiles but NOT their contents, the printout might be
as follows:
PROFILE USED BY:
============================
PROFILE JANITOR, BATMAN, TARZAN, SUPMAN
VDU0 , VDU1 , VDU2 , VDU3 , VDU4 , VDU5 ,
VDU6 , VDU7 , VDU8 , VDU9 , VDU10, VDU11,
VDU12, VDU13, VDU14, VDU15, CAL0 , VTP
COMMAND EXECUTED
2 Create a profile (IAA).

Create a profile, for instance, NEWPROFILE, with the default values:
ZIAA:NEWPROFILE:::;
36 © 2016 Nokia DN9770704 Issue: 14-0

3 Display the data of the profile created (IAI).

Once the NEWPROFILE profile has been created, you can display its data by giving
its name as a parameter:
ZIAI:PROFILE=NEWPROFILE:COM;
Expected outcome
The profile receives the following default values:
PROFILE NAME: NEWPROFILE
COMMAND CLASS AUTHORITIES:
A=1 B=1 C=1 D=1 E=1 F=1 G=1 H=1 I=1 J=1
K=1 L=1 M=1 N=1 O=1 P=1 Q=1 R=1 S=1 T=1
U=1 V=1 W=1 X=1 Y=1
PARALLEL PASSWORD EXISTENCE: YES
PASSWORD VALIDITY TIME: 100 DAY(S)
MML COMMAND LOG ACCESSIBILITY: LIMITED
UNIQUE PROFILE: NO
PROFILE IS USED BY:
NETWORK USE ALLOWED: YES
MML SESSION IDLE TIME LIMIT: 10 MIN(S)
FTP AND SFTP ACCESSIBILITY: NO
Further information
Example:Creating a profile by giving a separate authority value to each command
class
Create the NEWPROFILE profile with a separate authority value for each command
class from A to Y and with medium access to the MML command log.
ZIAA
:NEWPROFILE:A=160,C=100,D=150,G=100,I=150,N=100,O=100,Q=160,
R=100,T=150,U=50,W=50,Y=180:ACCESS=MED;
Example:Creating a profile by giving the same authority value to all command
classes
Create the USRPROFILE profile with the same authority value (150) in all command
classes and with a password validity time of 50 days. Give the profile read access to
FTP.
ZIAA:USRPROFILE:ALL=150:VTIME=50::FTP=R;
Example:Creating a profile by using an existing profile
DN9770704 Issue: 14-0 © 2016 Nokia 37

Use the existing TELEPROF profile as a base profile to create the new NEWPROFILE
profile. Define the following authority values for the new profile: authority value 250 in
command class A, and authority value 50 in command class I.
ZIAA:NEWPROFILE:BASEP=TELEPROF,A=250,I=50;
Example:Attaching a password policy to a user profile
Use the existing ADPOLICY password policy, and attach it to the PWPROFILE user
profile. Define also that the password can be changed after seven days.
ZIAA
:PWPROFILE:ALL=150:VTIME=150,MINVTIME=7,PWPOLICY=ADPOLICY:::;
g Note: The PWPOLICY and MINVTIME parameters can be used only if Feature 31390:
Password Policy has been activated.
3.2.2 Deleting an MMI user profile

Purpose
You can delete a profile by using the IAR command. If the profile to be deleted exists in
the system, the MML program asks you to confirm whether you want to delete the profile
or not (Y/N confirmation).
Before you start

The deletion only succeeds if the profile has not been attached to any user ID or
terminal, otherwise the system outputs the user IDs and terminals using the profile. If you
definitely want to delete the profile, you must attach the terminals and user IDs to
another profile before the deletion of the profile can be completed.
Procedure
1 Delete a profile (IAR).

Delete a profile, for example, OLDPROF, which is not attached to any user IDs or
terminals:
ZIAR:OLDPROF;
2 Confirm profile deletion.

The MML program asks for confirmation:
YOU ARE DELETING A PROFILE: OLDPROF
CONFIRM COMMAND EXECUTION: Y/N? Y
Expected outcome
The MML program gives the following notice upon deletion:
PROFILE DELETED
COMMAND EXECUTED
38 © 2016 Nokia DN9770704 Issue: 14-0

3.3 Creating, modifying and deleting local HTTP users

and user groups
Purpose
g Note: A HTTP user uses an MMI user account with HTTP profile. A HTTP user group
is similar to a user profile: it contains user access right information.
You can create, modify and delete local HTTP users and user groups by editing the
LFILES/UGLIFYGX.XML configuration file.
Procedure
1 Open a HTTP session.
2 Click on the command menu object Administrator/Edit configuration files.
3 Select the LFILES/UGLIFYGX.XML configuration file from the file selection list
of the popup screen.
4 Edit the XML file.
5 Press the Activate button.
3.4 Configuring user account policy

Purpose
User account policy defines what kind of formal requirements a user account must fulfil.
For more information on user account policy, see Section User account policy.
g Note: You can define user account policy only for local users. Remote users' accounts
are defined and modified in the NetAct.
Before you start

Check that Feature 31391: User Account Policy has been activated.
DN9770704 Issue: 14-0 © 2016 Nokia 39

Procedure
1 Activate user account policy checking (IVU).

ZIVU:STATE=ON;
2 Activate last login information checking (IVT).

ZIVT:STATE=ON;
3 Create a profile that contains a disable time (IAA).

ZIAA:<profile>:[BASEP = <base profile> |
[[ <command class> = ALL def ] = [ <authority> | 1 def ] ] ... ] ...
:
[VTIME = [ <password validity time> | FOREVER | 100 def ],
MINVTIME = [ <minimum password validity time> | 0 def ],
ACCESS = [ COM | MED | LIM def ],
UNIQUE = [ YES | NO def ] ] ... ,
PWPOLICY = [ <password policy name> ],
ADMPROF = [ YES | NO def ],
DABLETIME = [ <disable time> | 0 def ] ]:
[TLIMIT = <MML_session_idle_time_limit>|15 def ]:
FTP = [ W | R | NO def ];
4 List disabled user accounts (IVL).

ZIVL;
5 Set user login information printing (IVT).

ZIVT:STATE=ON;
3.4.1 Configuring login policy improvement

Purpose
With login policy improvement feature the system can set the login retry counter limit.
When a user tries to log in the system with the same account with a wrong password
more than N-times, (where N=retry counter limit) the system locks this account. After
that, only another administrator account can unlock this account with the IVE MML
command.
For more information on user account policy, see Section User account policy.
Before you start

1. Activate user account policy feature.
ZWOA:58,1,A;
2. Set user account policy checking feature to ON.
40 © 2016 Nokia DN9770704 Issue: 14-0

ZIVU:STATE=ON;
Procedure
1 Set the USER_ACCOUNT_LOCK_LIMIT (058:0004) PRFILE parameter to the

required value N by the following command:
ZWOC:58,4,N;
2 Attempt unsuccessful logins more than X times in a row with a user that
belongs to non-administrator profile.
Expected outcome
After X attempts the user account is locked and the user gets the following printout:
(/*** USER ACCOUNT IS DISABLED ***/)
Further information
Users with administrator profiles do not get disabled when unsuccessful login count
exceeds the limit.
3.5 Creating, modifying and deleting local Q3 or FTAM

user profiles
Purpose
Profiles can also be created for users that need to be able to operate the system from
NetAct in remote sessions, that is, Q3 and FTAM users.
3.5.1 Creating a Q3 or FTAM user profile

Purpose
You can create a profile for a Q3 or FTAM user using the IOA command and modify a
profile using the IOM command. The user profile consists of the user identifier and
application fields.
Note that when creating the profile, you have to define the appropriate user rights for a
profile, that is, permission to read, write, or execute commands. Note that the permission
to read is included in the permission to write, and the permission to read and write is
included in the permission to execute.
The allowed values of the application field parameter are listed in the MMI terminal
guide. The user can be given access rights to only one of the application fields.
The possible types of permission are as follows:
Table 5 Application-field-specific user permission types

R read Only read permission
DN9770704 Issue: 14-0 © 2016 Nokia 41

Table 5 Application-field-specific user permission types (Cont.)

W write Read and write permissions (W=RW)
X execute Read, write, and execute permissions

(X=RWX)
Procedure
1 Create a local user ID (IAH).

If a local MMI user account does not exist, create the user account and attach a
profile to it. The user ID must not already exist in the system.
ZIAH:<user id>:<profile>;
Further information
Note that the maximum length of a password for a Q3 or FTAM user profile is 15
characters. A Q3 or FTAM user needs MMI user account to be able to log in to NE.
When creating a Q3 or FTAM user profile, make sure that the password defined for
the existing local user ID is not longer than 15 characters, although 16 are allowed.
2 Create a Q3 or FTAM user profile (IOA).

Create a Q3 or FTAM user profile and define the application-field-specific user
permission:
ZIOA:<user_id>:<application field>;
Further information
Example:
Create a network user, JSMITH, with the following access rights: performance
management with read permission and fault management with write permission:
ZIOA:JSMITH:APPL=PM-R&FM-W;
3.5.2 Modifying a Q3 or FTAM user profile

Purpose
You can modify, that is, add access rights for a Q3 or FTAM user profile using the IOM
command. Note that if the user already has access rights to any of the application fields,
those access rights remain intact and access rights to other application fields are added.
Before you start

If you want to change the access rights to a certain application field, you must first
remove the rights with the IOR command and only then add new access rights with the
IOM command.
42 © 2016 Nokia DN9770704 Issue: 14-0

Procedure
1 Remove existing rights from a Q3 or FTAM user (IOR).

Remove the access rights in a certain application field from a Q3 or FTAM user:
ZIOR:<user id>:<application field>;
2 Add new access rights for a Q3 or FTAM user (IOM).

Add the access rights for a certain application field for a Q3 or FTAM user:
ZIOM:<user id>:<application field>;
Example:
Add the access right for fault management with execution permission for the user
JSMITH:
ZIOM:JSMITH:APPL=FM-X;
Further information
Example: Changing the access rights of a certain application field
Change the read permission of the user JSMITH to write permission for performance
management:
1. Remove read permission for performance management from the user JSMITH:
ZIOR:JSMITH:APPL=PM;
2. Issue write permission to the user JSMITH for performance management:
ZIOM:JSMITH:APPL=PM-W;
3.5.3 Deleting a Q3 or FTAM user profile

Purpose
You can remove user access rights from a Q3 or FTAM user or remove the whole user
profile using the IOR command.
g Note: When deleting the entire user profile of a Q3 or FTAM user, the MMI user
account still remains in the system.
When local MMI user account is deleted, system also deletes its Q3 and FTAM profile
automatically.
Procedure
1 Remove the entire Q3 or FTAM user profile (IOR).

Remove the entire user profile of a certain Q3 or FTAM user:
ZIOR:<user profile>;
DN9770704 Issue: 14-0 © 2016 Nokia 43

Further information
Example: Removing the entire profile
Remove the entire user profile of the Q3 or FTAM user JSMITH:
ZIOR:JSMITH;
44 © 2016 Nokia DN9770704 Issue: 14-0

Information Security Managing local users in the MMI system
4 Managing local users in the MMI system
4.1 Creating and deleting local MMI user IDs

Purpose
A password attached to the user ID prevents users from accessing the MMI system by
using other than their own user ID. You create the password and the user ID using the
IAH command. Note that a user may have two separate passwords (see Section
Parallel passwords). The password validity time is defined by the profile to which the
user ID is attached. When you create or change a password, it is not displayed on the
VDU.
For more information on user IDs, see Section User IDs in the MMI system.
4.1.1 Creating an MMI user ID

Purpose
The length of a user ID is 6 characters. The first character of a user ID must be a capital
letter; the other characters can be either capital letters (A-Z) or digits.
You can create a user ID using the IAH command. You must create a user ID separately
in each of the network elements in the O&M network. When you create a user ID, it must
not already be in use in the system, and the profile to which you want to attach the
user ID must already exist in the system.
When you create a user ID, you also give it a password, or two passwords if the user
was defined as having two passwords in the user profile. In this case, the system asks
you to give and verify both passwords.
Before you start

Before creating a user ID, check the existing user IDs. You can display the data of an
existing user ID using the IAI command.
Procedure
1 Display all user IDs in the system (IAI).

Display all user IDs in the system but not their contents:
ZIAI:USERID=ALL:LIM;
2 Create a user ID (IAH).

Create a new user identity and attach a profile to it. Note that the user ID may not
exist already.
ZIAH:<user id>:<profile>;
Expected outcome
DN9770704 Issue: 14-0 © 2016 Nokia 45

Managing local users in the MMI system Information Security
When creating a new user ID, the printout is as follows:

/* IDENTIFY PASSWORD:
MINIMUM PASSWORD LENGTH IS 6
MAXIMUM PASSWORD LENGTH IS 16 */
NEW PASSWORD:*********
VERIFICATION:*********
COMMAND EXECUTED
OR if it has been defined in the profile that the user has two separate passwords:
NEW PASSWORD: *********
VERIFICATION: *********
/* IDENTIFY PASSWORD FOR OLDER SYSTEM LEVELS:

NEW PASSWORD:
VERIFICATION:
COMMAND EXECUTED
If you have Feature 31390: Password Policy turned ON, the system also outputs the
following information:
PASSWORD HAS TO BE COMPLIANT WITH PASSWORD POLICY */
NEW PASSWORD:********
VERIFICATION:********
4.1.2 Deleting an MMI user ID

Purpose
You must immediately delete a user ID from the system or the network when the owner
of that particular user ID no longer works for the company, or when unauthorised use is
suspected.
You can delete an existing user ID from the MMI system using the IAD command.
Before the deletion is completed, the MML program displays the user ID and asks you to
confirm whether you want to delete the user ID (Y/N confirmation). Network user profiles
are automatically deleted. After deleting users you are recommended to check the HTTP
users because they are not deleted automatically.
46 © 2016 Nokia DN9770704 Issue: 14-0

g Note: A HTTP user is an MMI user with HTTP profile. A HTTP user group is similar to a
user profile: it contains user access right information.
For more information on how to delete local HTTP users, see Section Creating,
modifying and deleting local HTTP users and user groups.
Note that the IAD command also deletes the deleted user ID's network rights from the
system. The network rights can be deleted manually using the IOR command.
If the user ID which you are deleting has an MML session in the system, the session is
interrupted.
Before you start

You can check the existing user profiles using the IAI command.
Procedure
1 Delete a user ID from the MMI system (IAD).

Delete a certain user ID from the system:
ZIAD:<user id>;
The program always asks for verification before it executes the command.
Expected outcome
When deleting a user ID, the printout is as follows:
EXECUTION STARTED
YOU ARE DELETING USER ID: <USERID>
CONFIRM COMMAND EXECUTION: Y/N ? Y
USER ID DELETED
COMMAND EXECUTED
Further information
Example: Deleting a user ID from the MMI system
Delete the JSMITH user ID from the MMI system:
ZIAD:JSMITH;
User IDs can be collectively deleted from the O&M network using the MML macro ID.
The macro is an optional feature. It is used to delete a user ID from all those systems in
which at least one O&M channel is working (in state WO-EX).
The user who starts up the macro must have sufficient authority both in the source and
target systems. If the user's rights are insufficient, the macro only deletes the user ID
from the system in which the user has sufficient rights.
Handling passwords of a username for a fixed service terminal
DN9770704 Issue: 14-0 © 2016 Nokia 47

The authority system also applies to the service terminal (that is, service terminal
authority and service terminal session authority). To open a service terminal session, the
user's MMI user ID and password are requested. If the MMI system cannot be reached
from the service terminal, the fixed service terminal username and its password are used
to ensure service terminal usage in fault situations.
The authority rights for service terminal usage are bound to the user's authorities to
session. Using the DDS command you can use an ordinary MML terminal to start up a
recommended to lower the default authority requirement (250) of the DD command group
in order to maintain high authority requirements.
You are recommended to change the service terminal password of a fixed username
changed.
In a minidebugger case, only one password is in use. After upgrading the boot program
memory, both a fixed username and a fixed password are in use. The fixed password
cannot be changed.
g Note: To prevent unauthorised use, the service terminal password must only be given
to persons who cannot carry out their tasks without service terminal commands. In
reserved for those tasks which cannot be performed by using MML commands. The
fixed username and its password are for administrator use only.
As for the possible login situations, see Table Possible login situations in Section
Authority management in the MMI system.
Security reporting of service terminal sessions
A security report of service terminal users can be printed using the SET (service terminal
sessions) value for the report type parameter of the IRO command. The report displays
all attempts to connect to the service terminal.
4.2 Changing a password in the MMI system

Purpose
A password should be changed immediately if illegal use is suspected. If the password
has expired, you cannot execute MML commands until it is changed.
You can change your own password using the IAG command. If you have two separate
passwords, you can change only one of them at a time. First, with the password type
parameter you must specify whether you want to change a password that is compatible
with the new encryption system (NEWPWT) or a password for remote systems of older
system levels that do not support the new encryption method (OLDPWT). Then the
system asks for the old password and compares it to the password which was last
48 © 2016 Nokia DN9770704 Issue: 14-0

attached to the user ID. If they match, the system asks for the new password twice to
eliminate typing errors. You must enter the password within one (1) minute after the
system has asked for it. If you do not enter the password within one (1) minute, the
system returns to the main menu. When the password is successfully changed, the new
password is valid for the time defined in the profile. The maximum length of a password
is 16 characters for the new system level and 15 for the older system levels.
A network user needs an MMI user account to be able to log in to NE. When creating a
network user profile, make sure that the password defined for the existing local user ID is
not longer than 15 characters, although 16 are allowed.
The password may not be the same as the user identifier.
If the user ID is attached to a profile in which it has been defined that the users have only
one password, the OLDPWT parameter is not output in the dialog.
To change someone else's password, use the IAS command. The IAS command must
therefore have a high authority requirement, and it can only be used by the person in
charge of information security.
Procedure
1 Change your own password (IAG).

ZIAG:NEWPWT;
Expected outcome
The system outputs the following information and guides the process:
OLD PASSWORD:
/* IDENTIFY NEW PASSWORD:
COMMAND EXECUTED
If you have Feature 31390: Password Policy turned ON, the system also outputs the
following information:
PASSWORD HAS TO BE COMPLIANT WITH PASSWORD POLICY */
Further information
Example: Changing your own password used for remote sessions (older system
level)
ZIAG:OLDPWT;
OLD PASSWORD:
/* IDENTIFY NEW PASSWORD:
NEW PASSWORD:
DN9770704 Issue: 14-0 © 2016 Nokia 49

VERIFICATION:
COMMAND EXECUTED
The password is changed correctly.
4.3 Configuring forced password change

Purpose
The operator can define if the user must change the password at the first login after the
password change. The password must also be changed after its validity time has
exceeded.
This function is possible with the help of FORCED PASSWORD CHANGE parameter of
IAH and IAS commands.
Before you start

This parameter is licence-based, you can install it with the W7L command, and activate
or deactivate it with the W7M command.
ZW7L:<licence file name>:;
If license is in use, the parameters of IAH (CREATE USER ID) and IAS (CHANGE
PASSWORD OF OTHER USER ID) commands are:
ZIAH: USER ID: PROFILE: FORCED PASSWORD CHANGE;
ZIAS: USER ID: PASSWORD TYPE: FORCED PASSWORD CHANGE;
Parameter FORCED PASSWORD CHANGE is optional and its default value is Y.
If license is not in use, parameters are used as before. Forced password change feature
is not in use.
ZIAH: USER ID: PROFILE;
ZIAS: USER ID: PASSWORD TYPE;
Further information
See also Section Requirements, restrictions and recommendations concerning
passwords.
Example: Configuring forced password change if license is in use
1. You can use an existing profile or create a new profile for testing.
ZIAA:PROFTEST;
2. Create new user and force him to change password immediately after first login:
ZIAH:USER10:PROFTEST,Y;
3. Give user temporary password which must be changed immediately after next login:
ZIAS:USER10:NEWPWT:Y;
where
USER username is which you have logged to MML with
50 © 2016 Nokia DN9770704 Issue: 14-0

Note that this command can only be used if the profile to which the user who is
executing the command belongs to has authority I=250.
Authority can be checked with the following command:
ZIAI:PROFILE=<profile name>;
Username SYSTEM belongs to profile PROFILE, which normally has authority
I=250.
Users can normally change their own password with IAG command and can change
another user's password with IAS command. But users can change their own
password with IAS as well.
4.4 Configuring password policy

Purpose
Password policy defines what kind of formal requirements a password must fulfil. The
purpose of the requirements is to make sure that the passwords used in the system are
not too simple and thereby easy to crack.
The following procedure shows how you can define a password policy and attach it to a
user profile. The requirements set in the password policy are activated when the user
next changes his password.
Optionally, you can also determine that the system checks the history of every new
password the user is creating. This way, you can prevent the user from creating a
password that has been used in the network element before. The length of the password
history is 20 passwords.
g Note: Password policy cannot be applied to older-system-level passwords.
Before you start

Check that Feature 31390: Password Policy has been activated.
Procedure
1 Activate password policy checking (IVS).

ZIVS:STATE=ON;
2 Activate password history checking (IVH).

ZIVH:STATE=ON;
3 Define the password policy (IVK).

ZIVK:<password policy name>:
[[PCMDS = [ IAH | IAS | IAG | IAF ]...] |
[HCMDS = [ IAS | IAG | IAF ]...] |
[LENGTH = <min password length>] |
[CHAR = <min characters in password>] |
DN9770704 Issue: 14-0 © 2016 Nokia 51

[DIGIT = <min digits in password>] |

[SPECIAL = <min special characters in password>] |
[REPEAT = <min repeating characters>] |
[ALPH = <max alphabetical order>] |
[NUMERIC = <max numerical order>] |
[USERID = [ YES | NO ]]]...;
4 Check that the password policy was configured correctly (IVI).

ZIVI:PWPOLICY=<password policy name>;
Expected outcome
You get the following printout:
INTERROGATING PASSWORD POLICIES:
PASSWORD POLICY: POLICY1
PASSWORD POLICY USED WITH COMMAND(S): IAH IAS
PASSWORD HISTORY USED WITH COMMAND(S): IAS IAG IAF
MIN PASSWORD LENGTH: ................. 10
MIN NUMBER OF CHARACTERS: ............ NOT DEFINED
MIN NUMBER OF DIGITS: ................ 3
MIN NUMBER OF SPECIAL CHARACTERS: .... 3
MAX REPEATING CHARACTERS: ............ NOT DEFINED
MAX ALPHAPETICAL ORDER: .............. 2
MAX NUMERICAL ORDER: ................. NOT DEFINED
USER ID ALLOWED IN PASSWORD: ......... NO
COMMAND EXECUTED
5 Attach the password policy to the user profile (IAA).

ZIAA:<profile>::PWPOLICY=<password policy name>:::;
6 Check that the password policy was attached to the given user profile (IAI).
ZIAI:PROFILE=<profile>:COM;
4.5 Changing a password encryption key in the MMI

system
Purpose
The encryption method (encryption key) can be changed or displayed using the IAK
command. You should, however, be cautious when doing this, as changing the
encryption key may affect the establishing of remote sessions, if the source and target
systems do not use the same keys. To ensure reliable establishing of remote sessions,
you are recommended to use the same encryption key in all network elements.
52 © 2016 Nokia DN9770704 Issue: 14-0

When changing the encryption key, the system also asks for verification and outputs a
notification that changing the encryption key may make it more difficult to establish
remote sessions.
When changing the encryption key, you cannot select the encryption key yourself but the
system generates it when you enter a generating index. As the value for the
ENCRYPTION KEY NUMBER parameter, enter the index which you can choose from the
range of 1 to 100.
Procedure
1 Display the currently used password encryption key (IAK).

Output the encryption key index that is currently in use:
ZIAK;
2 Change the password encryption key (IAK).

Define a new value for the password key index:
ZIAK:<encryption key number>;
Further information
Example: Displaying the currently used encryption key
Display the key index of the encryption key that is currently used:
ZIAK;
The execution printout is as follows:
CURRENTLY USED KEY IS : 27
COMMAND EXECUTED
Example: Changing the encryption key index

Change the encryption key index to 47:
ZIAK:47;
The printout is as follows:
/* THIS MODIFICATION MAY CAUSE FAILURE IN USER
AUTHENTICATION WHEN ESTABLISHING REMOTE SESSION
BECAUSE OF DIFFERENT ENCRYPTION KEYS */
CONFIRM COMMAND EXECUTION: Y/N ? Y
COMMAND EXECUTED
Note that the system prints a notification that changing the encryption key may affect the
establishing of remote sessions.
For information on changing a password, see Section Changing a password in the MMI
system.
DN9770704 Issue: 14-0 © 2016 Nokia 53

4.6 Creating superusers and superterminals

Purpose
The highest possible authority requirement for an MML command is 250. However, the
profile can be defined to have authority 251 in a given command class. This is known as
special authority, which can be attached to a user ID and to a terminal. Special authority
enables a user to execute the commands in the defined command class without any
restrictions.
g Note: Remote users cannot be managed locally.
4.6.1 Creating a superuser in the MMI system

Purpose
A superuser is a user whose user ID profile has special authority (authority requirement
251) in one or several command classes. Thus, the authority requirement of the MML
command and the authority restriction of the terminal do not apply to superusers.
A superuser can execute commands without restrictions in those command classes for
which he has special authority. Special authority also bypasses command blocking.
The person in charge should know the superuser ID in case the terminal profiles are
inadvertently updated to have too low an authority value, and subsequently no
commands can be executed, even with high authority. In such a case, commands can
only be executed with special authority.
Procedure
1 Create a profile with special authority 251 (IAA).

Create a profile with special authority requirement 251 (for example, SUPERPROF)
in all command classes (ALL) and with a password validity time of 30 days:
ZIAA:SUPERPROF:ALL=251:VTIME=30;
2 Create a user ID and attach it to the profile (IAH).

Create a user ID (for example, SUPUSR) and attach it to the SUPERPROF profile:
ZIAH:SUPUSR:SUPERPROF;
4.6.2 Creating a superterminal in the MMI system

Purpose
A superterminal is an MML terminal whose profile has special authority in one or
several command classes. Thus, the authority requirement of the command and the
user's authority restriction do not apply to commands entered on the superterminal. Also,
blocked commands can be executed on a superterminal.
54 © 2016 Nokia DN9770704 Issue: 14-0

Before you start

Consider very carefully which terminal you define as a superterminal. If the superterminal
has special authority for all command classes, any user can execute any command
without restrictions. You must therefore plan the physical location of a superterminal
carefully.
Procedure
1 Create a profile with special authority 251 (IAA).

Create a profile (for example, SUPERPROF) with special authority 251 in all
command classes:
ZIAA:SUPERPROF:ALL=251;
2 Attach a terminal to the profile (IAE).

Attach a terminal (for example, VDU1) to the SUPERPROF profile:
ZIAE:TERMINAL=VDU1:SUPERPROF;
DN9770704 Issue: 14-0 © 2016 Nokia 55

Managing network element integrated IPSec Information Security
5 Managing network element integrated IPSec
5.1 Introduction to network element integrated IPSec

Network element integrated IPSec functionalities provide possibility to extend IPSec
Virtual Private Networks (VPNs) all the way to same network element functional units
which also terminate the IP based connections.
Integrated IPSec is an optional feature with two sellable items:
• 'IPSec for management plane' sellable item (license) provides possibility to secure
network element management plane type traffic (O&M, OLCM, charging, statistics).
This is implemented by using IPSec VPN protection from network element
management plane type functional units (OMU, CHU, STU, EMU, EIRU, MCHU) to
VPN-GWs in network management (NetAct), charging, and so on sites. Note also
following:
– All the mentioned management plane type functional units do not appear in every
network element. For example, EMU and EIRU appear only in HLR element and
MCHU only in SGSN. See the network element / release specific details from
Section Supported network elements and releases.
– IPSec can also be used to secure the traffic between NEMU and OMU in such
network elements which contain NEMU unit (for example, MGW). For more
information on how IPSec is used in NEM, see Using IPSec in NEMU in Network
Element Management Unit (NEMU) document.
– VPN-GW entities (for example, in network management site) are not included to
'IPSec for management plane' sellable item. VPN-GWs are sellable items in
network management system product portfolio.
• 'IPSec for control plane' sellable item (license) provides possibility to secure control
plane over IP between the MGW and the MSC.
Figure 3: Example of IPSec for management plane usage with IKE pre-shared key based
VPN authentication presents an example of 'IPSec for management plane' usage.
For more information on system level details on using the Integrated IPSec
functionalities, see Security on Site in Site Connectivity Guidelines for CS Core Network
document.
5.2 Configuring IPSec for management plane

This section presents configuration examples on how to apply integrated IPSec for
management plane. The examples in this chapter are for traffic between network
element OMU unit and network management site (NMS), covering mainly O&M traffic.
However, the identical logic can be applied also for CHU (charging) and other
management plane type functional units (STU, EMU, EIRU and MCHU) in network
elements which contain also other management plane units than OMU. See the network
element / release specific details from Section Supported network elements and
releases.
56 © 2016 Nokia DN9770704 Issue: 14-0

Information Security Managing network element integrated IPSec
5.2.1 IPSec for OMU (O&M) with IKE pre-shared key based VPN
authentication
Figure 3: Example of IPSec for management plane usage with IKE pre-shared key based
VPN authentication shows a network topology example procedure which describes how
to configure IPSec protection for O&M traffic in network element A1. The procedure is
similar to other network elements (B1 and B2). In these procedures the IPSec VPN
authentication is based on Internet Key Exchange (IKE) pre-shared keys.
Figure 3 Example of IPSec for management plane usage with IKE pre-shared key
based VPN authentication
SiteA SiteB
M-planebackbone
(e.g.10.0.0.0/24)
NEA1 NEB1
OMUIPaddress OMUIPaddress
10.0.0.9/24 10.0.0.11/24
NEB2
OMUIPaddress
10.0.0.13/24
VPN-GWWANsideIPaddress
10.0.0.8/24
VPN-GW(cluster)
NMSSite
Trustednetwork
domain
192.168.8.0/24
Network
management
(NetAct)servers
Site B:
In remote sites IPSec VPNs are terminated to same network element functional unit
which also terminates the IP based connections.
NMS Site:
• IPSec VPNs are terminated to VPN GW cluster.
• No IPSec protection within NMS site, since NMS site internal network is considered
trusted.
Note that the configurations and commands are only examples. They present the
integrated IPSec configuration logic in principle, but the details can vary in different a
operator network environment. The exact parameters and IPSec policies can vary in
operator network environment depending on for example, the network topology and
VPN-GW type (for example, what ciphers, details VPN GW supports).
DN9770704 Issue: 14-0 © 2016 Nokia 57

Summary
You can secure the O&M in M-plane network between network management site (NMS)
and OMU by applying IPSec for all IPv4 or IPv6 traffic that is sent and received in OMU.
In this example, we assume M-plane network is IPv4 network, meaning OMU is not
connected to IPv6 networks. However, this example procedure can be applied also for
IPv6 network by changing the IPv4 addresses in commands to corresponding IPv6
addresses.
The traffic is secured with the following details:
IPSec VPN between OMU and network management site VPN-GW:
• The used encapsulation method is Encapsulating Security Payload (ESP) in tunnel

mode.
• The IPSec tunnel endpoint in network management site is located in IP address
10.0.0.8 (VPN-GW WAN side IP address in Figure Example of IPSec for
management plane usage with IKE pre-shared key based VPN authentication.
• The IPSec VPN (ISAKMP/IKE) authentication is based on Internet Key Exchange
(IKE) pre-shared keys.
• The Cipher and message authentication algorithms are: AES-256 and SHA1 for both
IKE and IPSec security associations (SAs).
• The value for both ISAKMP modp group and the PFS modp group is 2 (group
number 2).
IPSec VPN between network element OMU and NEMU (applied only in network
elements containing NEMU)

mode.
• In this example, A1 NEMU network element is assumed to be located in IP address
10.0.0.10.
• The Cipher and message authentication algorithms are: 3DES and SHA1 for both
number 2).
1. Install license containing IPSec for management plane (W7L)

ZW7L:<license file name>:;
2. Activate IPSec for management plane feature code 1057 (W7M):
ZW7M:FEA=1057:ON:;
3. Create IKE pre-shared key to be used in IPSec VPN authentication between OMU
and network management site VPN-GW (Q4A):
ZQ4A:PSKOM,S:K:A:;
In this case the key name is PSKOM. Enter the key value when you see following
notice.
ENTER KEY (MAX 32 CHARACTERS)
4. If network element contains NEMU unit, create IKE pre-shared key to be used in
IPSec VPN authentication between OMU and NEMU (Q4A):
ZQ4A:PSKNEMU,S:K:A:;
58 © 2016 Nokia DN9770704 Issue: 14-0

In this case the key name is PSKNEMU. Enter the key value when you see following
notice:
5. Create traffic handling rules (Q2C):
a) Create rule which passes all IPv4 traffic in plaintext.
ZQ2C:PASSV4,P,BOTH:,"0.0.0.0/0":"0.0.0.0/0":;
b) Create rule which passes IPSec signaling in plaintext. The IPSec signaling is
ISAKMP/IKE protocol traffic, that is, the UDP traffic from or to port 500.
ZQ2C
:PASSIKEV4,P,BOTH:UDP,"0.0.0.0/0",500:"0.0.0.0/0",500:;
c) Create a ‘host-to-network’ style IPSec VPN rule which applies ESP
encapsulation in tunnel mode for all IPv4 traffic between OMU (10.0.0.9) and IP
addresses in network management site (network 192.168.8.0/24).
ZQ2C
:ESPNMS,I,TN,”10.0.0.9”,"10.0.0.8":,"10.0.0.9":"192.168.8
.0/24":2,2,,1,1,,PSK,PSKOM:E:;
d) Create a ‘host-to-host’ style IPSec VPN rule which applies ESP encapsulation in
tunnel mode for all IPv4 traffic between OMU (10.0.0.9) and NEMU (10.0.0.10).
ZQ2C
:ESPNEMU,I,TN,”10.0.0.9”,”10.0.0.10”:,”10.0.0.9”:"10.0.0.
10":2,2,,1,5,,PSK,PSKNEMU:E,,,1,5:;
6. Activate IPSec feature for OMU (Q2K):
Give the following MML command. The rule PASSV4 is attached to OMU during
activation because the MML command Q2K should not cut off the possible MML over
Telnet connections which are carried via plaintext TCP.
ZQ2K:OMU:::::PASSV4:;
7. Attach the traffic handling rules to OMU (Q2A):
a) Attach rule PASSIKEV4 to OMU.
ZQ2A:OMU::PASSIKEV4:;
b) Attach rule ESPNMS to OMU.
ZQ2A:OMU::ESPNMS:;
c) Attach rule ESPNEMU to OMU (only if network element contains NEMU).
ZQ2A:OMU:ESPNEMU:;
8. Detach rule PASSV4 from OMU (Q2R):
ZQ2R:OMU::PASSV4:;
After rule PASSV4 is detached from OMU, it will accept only:
• IPSec VPN connections (ESP in tunnel mode), which are originated from network
192.168.8.0/24 and delivered through VPN-GW (IP address 10.0.0.8). The MMI
over Telnet, and so on, O&M traffic will be unavailable until the corresponding
ESP in transport mode policies are configured to network management site VPN-
GW.
• IPSec VPN connections (ESP in tunnel mode) between OMU and NEMU. The
network connections between NEMU and OMU will be unavailable until the
corresponding ESP in transport mode policies are configured to NEMU.
9. Interrogate the results (Q2L):

ZQ2L:OMU:;
DN9770704 Issue: 14-0 © 2016 Nokia 59

Expected outcome:
INTERROGATING IPSEC CONFIGURATIONS
COMPUTER UNIT: ........... OMU

CA DEFINITION SET: .....
PUBLIC KEY: ............
PRIVATE KEY: ...........
PUBLIC INTERFACE: ......
PRIVATE INTERFACE: .....
CERTIFICATE EXPIRE SET:.
RULES: ................. PASSIKEV4
ESPNMS
ESPNEMU
COMMAND EXECUTED
5.2.2 IPSec for OMU (O&M) with PKI certificate based VPN
authentication
Figure 4: Example of IPSec for management plane usage with PKI certificate based VPN
authentication shows a network topology example procedure, which describes how to
configure IPSec protection for O&M traffic in these network elements (B1 and B2). In
these procedures the IPSec VPN authentication is based on PKI certificates.
Note that the only difference between Figure 3: Example of IPSec for management plane
usage with IKE pre-shared key based VPN authentication and Figure 4: Example of
IPSec for management plane usage with PKI certificate based VPN authentication is that
the second network management site is equipped with PKI CA entity, which is a sellable
item in network management portfolio.
60 © 2016 Nokia DN9770704 Issue: 14-0

Figure 4 Example of IPSec for management plane usage with PKI certificate based
VPN authentication
SiteA SiteB
M-planebackbone
(e.g.10.0.0.0/24)
NEA1 NEB1
OMUIPaddress OMUIPaddress
10.0.0.9/24 10.0.0.11/24
NEB2
OMUIPaddress
10.0.0.13/24
VPN-GWWANsideIPaddress
10.0.0.8/24
VPN-GW(cluster)
NMSSite
Trustednetwork
domain
192.168.8.0/24
Network
management
(NetAct)servers
PKICAentity(InstaCertifier)
isalsolocatedinNMSsite:
-LDAPbased
certificatepublishing
-CMPbased
certificateenrollment
Site B:
In remote sites IPSec VPNs are terminated to same network element functional unit
which also terminates the IP based connections.
NMS Site:
• IPSec VPNs are terminated to VPN GW cluster.
• No IPSec protection within NMS site, since NMS site internal network is considered
trusted.
Note that the configurations and commands are only examples. They present the
integrated IPSec configuration logic in principle, but the details can vary in a different
operator network environment. The exact parameters and IPSec policies can vary in
operator network environment depending on, for example, the network topology and
VPN-GW type (for example, what ciphers, and so on, details, VPN GW supports).
Summary
You can secure the O&M in M-plane network between network management site (NMS)
and OMU by applying IPSec for all IPv4 or IPv6 traffic that is sent and received in OMU.
In this example, we assume M-plane network is IPv4 network, meaning OMU is not
DN9770704 Issue: 14-0 © 2016 Nokia 61

connected to IPv6 networks. However, this example procedure can be applied also for
IPv6 network by changing the IPv4 addresses in commands to corresponding IPv6
addresses.
The traffic is secured with the following details:
IPSec VPN between OMU and network management site VPN-GW:
• Two IPSec VPNs:

– One secures the traffic which relates to certificate management between OMU
and PKI CA portal. In this example, PKI CA portal is located in network
management site IP address 192.168.8.10
– Another one secures the rest of the O&M traffic between OMU and network
management site elements.

mode.
• The IPSec tunnel endpoint in network management site is located in IP address
10.0.0.8 (VPN-GW WAN side IP address in Figure Example of IPSec for
management plane usage with IKE pre-shared key based VPN authentication.
• Certificate management IPSec VPN is authenticated with IKE pre-shared keys. The
IPSec VPN which secures the rest of O&M traffic is authenticated with X.509v3 PKI
certificates.
• The Cipher and message authentication algorithms are: AES-256 and SHA1 for both
number 2).
IPSec VPN between network element OMU and NEMU (applied only in network
elements containing NEMU, such as MGW and RNC)

mode.
• In this example, network element A1 NEMU is assumed to be located in IP address
10.0.0.10.
• The Cipher and message authentication algorithms are: 3DES and SHA1 for both
number 2).
1. Install license containing IPSec for management plane (W7L):

ZW7L:<license file name>:;
2. Activate IPSec for management plane feature code 1057 (W7M):
ZW7M:FEA=1057:ON:;
3. Configure trusted CA certificate to network element:
Alternative A: Configure CA certificate from OMU file system to the element internal
key storage:
a) Download file containing trusted CA certificate (in BER-encoded ASN.1 binary
format) to network element OMU file system. In this example, the name of file in
OMU file system is W0-/CA1.CRT.
62 © 2016 Nokia DN9770704 Issue: 14-0

b) Configure CA certificate from OMU file system to network element internal key
storage with identification CA1CERT.
ZQ4A:CA1CERT,C:F,"W0-/CA1.CRT":;
c) Remove file W0-/CA1.CRT from OMU file system.
ZDDS;
ZLP:M,MAS
ZMD:W0-/CA1.CRT
ZE
d) Create the CA definition set (the identification is CA1), which is equipped with CA
certificate CA1CERT.
ZQ2T:CA1:CA1CERT:;
Alternative B: Configure the trusted CA certificate by fetching it from CA entity
LDAP server.
The network element integrated LDAP client functionalities are tested to interoperate
with Insta Certifier™ PKI CA entity.
In this example, it is assumed that network management site VPN-GW protects
access to the PKI CA entity with IKE pre-shared key authenticated IPSec VPN policy.
The idea in having IKE pre-shared key authenticated IPSec VPN between network
element and PKI CA entity is to protect PKI CA entity from potential flooding and
probing attempts originated from management plane network. IKE pre-shared key
authenticated IPSec VPN for PKI CA entity access is not mandatory needed if
flooding and probing attempts are not likely to occur in operator management plane
network. IPSec related LDAP and CMP operations itself do not contain any
confidential information. For example, CA entity LDAP database contains only
certificates (or just CA certificates), which itself are not confidential information. Also
CMP protocol has own build-in (reference number + CMP pre-shared key based)
methods to implement authentication between CMP server and clients.
However, since in this example we assume the tightest possible security policy, we
also assume that VPN-GW protects access to the PKI CA entity with IKE pre-shared
key authenticated IPSec VPN policy. It is also assumed that in beginning of this
procedure the OMU Ethernet interface is not connected to the IP core network, so
that the following MML commands are given through OMU VIMMLA service terminal
or through Telnet.
a) Create pre-shared key to be used in IPSec VPN authentication between OMU
and VPN-GW in network management site providing access to PKI CA entity
services (Q4A).
ZQ4A:PSKCA,S:K:A;
In this case the key name is PSKCA. Enter the key value when you see following
notice.
b) Create rule which passes all IPv4 traffic in plaintext (Q2C).
ZQ2C:PASSV4,P,BOTH:,"0.0.0.0/0":"0.0.0.0/0":;
c) Create rule which passes IPSec signaling in plaintext. The IPSec signaling is
ISAKMP/IKE protocol traffic, that is, the UDP traffic from or to port 500.
ZQ2C
d) Create rule which secures IPv4 traffic towards PKI CA entity (IP address
192.168.8.10) in network management site. The ESP encapsulation is in tunnel
mode.
DN9770704 Issue: 14-0 © 2016 Nokia 63

ZQ2C
:ESPCA,I,TN,”10.0.0.9”,"10.0.0.8":,"10.0.0.9":"192.168.8.
10":2,2,,1,1,,PSK,PSKCA:E:;
e) Create CA definition set (identification CA1) which contains information about CA
LDAP server.
ZQ2T:CA1::N,LDAP,"192.168.8.10";
f) Activate IPSec for OMU.
ZQ2K:OMU::CA1:::PASSV4;
Rule PASSV4 is attached to OMU during activation because Q2K command
should not cut off possible MML over Telnet connections which are carried
through plaintext TCP.
g) Attach rule PASSIKEV4 to OMU.
ZQ2A:OMU::PASSIKEV4,PASSV4:;
h) Attach rule ESPCA to OMU.
ZQ2A:OMU::ESPCA,PASSV4;
i) Interrogate the results.
ZQ2L:OMU:;

CA DEFINITION SET: ..... CA1
PUBLIC KEY: ............
PRIVATE KEY: ...........
RULES: ................. PASSIKEV4
ESPCA
PASSV4
COMMAND EXECUTED
j) Detach rule PASSV4 from OMU.
ZQ2R:OMU::PASSV4;
After rule PASSV4 is detached from OMU, it accepts only ESP encapsulated
traffic, which is originated from IP address 192.168.8.10 and encapsulated by
VPN GW (address 10.0.0.8). After this OMU Ethernet interface can be connected
to management plane network, so that OMU can obtain CA certificate from
network management site. The MMI over Telnet traffic from any IP address other
than 192.168.8.10 will be discarded. The user is able to give the following MML
commands locally through VIMMLA service terminal extension in OMU, or
remotely from network management site IP address 192.168.8.10.
k) Configure the trusted CA certificate to network element internal key storage by
fetching it from CA entity LDAP server.
In this example, CA certificate is stored to adapter internal key storage with name
'CA1CERT' identifier. It is also expected that LDAP object containing the CA
certificate is found from CA entity LDAP server using 'CN=CA1,O=Operator,C=FI'
LDAP Distinguished Name (DN) and attribute 'CaCertificate' in LDAP search:
ZQ2F:OMU,0:CA1CERT:C,"CN=CA1,O=Operator,C=FI":;
l) Add the CA certificate CA1CERT to the CA definition set CA1.
ZQ2Y:CA1:ADDCA:CA1CERT:;
4. Create certificate expire set watchdog to supervise certificate validity periods.
64 © 2016 Nokia DN9770704 Issue: 14-0

a) Create certificate expire set ‘ALARMEXP’, which raises alarm 60 days before
certificate supervised by it actually expires.
ZQ2G:ALARMEXP:A:60,0:;
CONFIGURED CERTIFICATE EXPIRE SET
CERTIFICATE EXPIRE SET ID: ... ALARMEXP

ACTION: ..................... RAISE ALARM
START IN DAYS: ............ 60
START IN HOURS: ........... 0
COMMAND EXECUTED
b) Attach certificate expire set ‘ALARMEXP’ to CA definition set ‘CA1’. After this
’ALARMEXP’ guards the validity of CA certificates included to ‘CA1’ CA definition
set.
ZQ2Y:CA1:ADDEXP:ALARMEXP:;
5. Create or configure network element own certificate to element internal key storage:
You can do this in either of the ways below.
Alternative A: Configure network element own certificate and private key related to
it from OMU unit file system:
a) Download file containing network element own X.509v3 PKI certificate (in BER-
encoded ASN.1 binary format) to OMU unit file system. The filename can be for
example W0-/OWN.CRT.
b) Download file containing private key related to network element own certificate
(in BER-encoded ASN.1 binary format) to OMU unit file system. The filename
can be for example W0-/OWN.PRV.
c) Configure network element own certificate and private key from OMU file system
to element internal key storage (identifications are respectively OWNCERT and
OWNPRIV).
ZQ4A:OWNCERT,C:F,"W0-/OWN.CRT":;
ZQ4A:OWNPRIV,P:F,"W0-/OWN.PRV":;
d) Remove files W0-/OWN.CRT and W0-/OWN.PRV from OMU unit file system.
ZDDS;
ZLP:M,MAS
ZMD:W0-/OWN.CRT
ZMD:W0-/OWN.PRV
ZE
Alternative B: Generate the network element own private key directly in OMU unit
and generate network element own (CA signed) certificate by executing CMP
enrollment from network management site PKI CA entity.
The network element integrated CMP client functionalities are tested to interoperate
with Insta Certifier™ PKI CA entity.
It is assumed that network connection to PKI CA entity (192.168.8.10) is already
protected with IKE pre-shared key based IPSec VPN policy as configured in
preceding Step 1, Alternative B. It is also assumed that OMU contains a CA
definition set ‘CA1’ equipped with valid CA certificate (see preceding Step 1,
Alternative B).
a) Create pre-shared key for CMP enrolment. CMP service provider defines the
value of this key.
ZQ4A:CA1CMPKEY,S:K:A:;
DN9770704 Issue: 14-0 © 2016 Nokia 65

In this case the key name is CA1CMPKEY. Enter the key value when you see
following notice:
b) Add certificate enrolment point definition to CA definition set CA1.
ZQ2Y
:CA1:ADDCEP:CMP,CA1CMPKEY,"http://192.168.8.10:8080/pkix/
",1234;
Parameter 'http://192.168.8.10:8080/pkix/' is an URL to CA entity CMP enrolment
service. Parameter 1234 is a reference number, which together with CMP pre-
shared key authenticates the network element CMP client to CMP service
provider.
c) Enroll certificate to network element. The following command generates 2048 bit
RSA public/private key-pair for element and sends certificate request to PKI CA
entity CMP server. The result of successful enrolment element's own certificate
and private key related to it are generated directly to network element internal
secure key storage with identifications ‘OWNCERT’ and ‘OWNPRIV’.
ZQ2E:OMU,0:OWNCERT,OWNPRIV:"C=FI,O=Operator,CN=NE
A1":RSA,2048:;
6. If the network element contains NEMU unit, create IKE pre-shared key to be used in
IPSec VPN authentication between OMU and NEMU (Q4A):
ZQ4A:PSKNEMU,S:K:A:;
In this case the key name is PSKNEMU. Enter the key value when you see following
notice:
7. Create traffic handling rules (Q2C):
a) If not already done in previous steps, create rule which passes all IPv4 traffic in
plaintext.
ZQ2C:PASSV4,P,BOTH:,"0.0.0.0/0":"0.0.0.0/0":;
b) If not already done in previous steps, create rule which passes IPSec signaling in
plaintext. The IPSec signaling is ISAKMP/IKE protocol traffic, that is, the UDP
traffic from or to port 500.
ZQ2C
c) Create a ‘host-to-network’ style IPSec VPN rule which applies ESP
encapsulation in tunnel mode for all IPv4 traffic between OMU (10.0.0.9) and IP
addresses in network management site (network 192.168.8.0/24).
ZQ2C
:ESPNMS,I,TN,”10.0.0.9”,"10.0.0.8":,"10.0.0.9":"192.168.8
.0/24":2,2,,1,1,,RSS:E:;
d) Create a ‘host-to-host’ style IPSec VPN rule which applies ESP encapsulation in
tunnel mode for all IPv4 traffic between OMU (10.0.0.9) and NEMU (10.0.0.10).
ZQ2C
:ESPNEMU,I,TN,”10.0.0.9”,”10.0.0.10”:,”10.0.0.9”:"10.0.0.
10":2,2,,1,5,,PSK,PSKNEMU:E,,,1,5:;
8. Attach traffic handling rules to OMU (Q2A):
a) ) If not already done in previous steps, activate IPSec for OMU. Note that rule
’PASSV4’ is attached to OMU during activation, since otherwise Q2K command
would cut off the possible so far plaintext MML over telnet connections:
ZQ2K:OMU:CA1:::PASSV4;
66 © 2016 Nokia DN9770704 Issue: 14-0

b) Assign its own certificate and private key for OMU:

ZQ2Q:OMU::ADDKEY,OWNCERT,OWNPRIV:;
c) If not already done in previous steps, attach rule ’PASSIKEV4’ to OMU:
ZQ2A:OMU::PASSIKEV4,:;
d) Attach rule ’ESPNMS’ to OMU:
ZQ2A:OMU::ESPNMS,:;
e) Attach rule ’ESPNEMU’ to OMU:
ZQ2A:OMU::ESPNEMU,:;
f) Interrogate the results:
ZQ2L:OMU;

CA DEFINITION SET: ..... CA1
PUBLIC KEY: ............ OWNCERT
PRIVATE KEY: ........... OWNPRIV
RULES: ..................(PASSV4)
PASSIKEV4
(ESPCA)
ESPNMS
ESPNEMU
COMMAND EXECUTED
g) If not already done in previous steps, detach rule PASSV4 from OMU:
ZQ2R:OMU::PASSV4:;
After rule PASSV4 is detached from OMU, it will accept only:
• IPSec VPN connections (ESP in tunnel mode), which are originated from
network 192.168.8.0/24 and delivered through VPN-GW (IP address
10.0.0.8). The MMI over Telnet, and so on, O&M traffic will be unavailable
until the corresponding ESP in transport mode policies are configured to
network management site VPN-GW.
• IPSec VPN connections (ESP in tunnel mode) between OMU and NEMU.
The network connections between NEMU and OMU will be unavailable until
the corresponding ESP in transport mode policies are configured to NEMU.
9. Create watchdog to supervise the validity of network element own certificate:

If network element own certificate was generated using CA CMP interface, you have
a possibility to configure network element automatically renew own certificate via
same CMP protocol interface when system detects own certificate to expire in near
future. In this case we need to create new certificate expire set (identification here
‘ENROLLEXP’), and include it to OMU unit. The ‘ENROLLEXP’ will execute
automatic certificate renew operation 30 days before certificate expiration and raises
alarm if renew operation fails:
ZQ2G:ENROLLEXP:E:30,0:OMU,0:;
CONFIGURED CERTIFICATE EXPIRE SET
CERTIFICATE EXPIRE SET ID: ... ENROLLEXP

ACTION: ..................... AUTOMATIC CERTIFICATE ENROLLMENT
START IN DAYS: ............ 60
DN9770704 Issue: 14-0 © 2016 Nokia 67

START IN HOURS: ........... 0
COMMAND EXECUTED
ZQ2Q:OMU::ADDEXP,ENROLLEXP:;
Alternatively, network element can be configured to raise alarm when detecting
certificate to expire in the near future. In this case you can use the same certificate
expire set (‘ALARMEXP’) which was created to guard the CA certificate:
ZQ2Q:OMU::ADDEXP,ALARMEXP:;
10. Add or remove CA certificates to a list of trusted CA certificates:
The maximum number of certificate issuers (CA certificates) that OMU can trust
simultaneously is five.
See the following instructions if you need to configure OMU unit to trust more than
one certificate issuers (CA signatures):
In this example, a new CA certificate CA2CERT is added to CA definition set CA1.
ZQ2Y:CA1:ADDCA:CA2CERT:;
See the following instructions if you need to modify the list of trusted CA certificates:
In this example, CA certificate CA2CERT is removed from the list of the trusted ones
in CA definition set CA1.
ZQ2Y:CA1:REMCA:CA2CERT:;
5.3 Supported network elements and releases

Network element integrated IPSec implementation is available in following releases /
network elements:
68 © 2016 Nokia DN9770704 Issue: 14-0

Information Security Managing audit trails
6 Managing audit trails
6.1 Managing MML command log

Purpose
MML command executions and execution results as well as the successful
establishment and ending of MML sessions are collected in an MML command log. All
MMI users share a common MML command log within one network element. The log is
stored within the network element in a group of disk files.
6.1.1 Accessing the MML command log

Purpose
When you create a user profile by using the IAA command, you also give the profile
rights to access the MML command log. Use the same command to change the existing
access rights. You define the access rights using the ACCESS parameter of the IAA
command. This parameter can have the following values:
LIM The owners of this profile can read only their own MML
command log records. This is the default value.
MED The owners of this profile can read their own MML
command log records and all other users' public MML
command log records.
COM The owners of this profile have complete access to the

MML command log. Every user ID that is attached to this
kind of profile can read all MML command log records.
g Note: To minimise security risks, access rights to command logs should be granted to
as limited a group of users as possible.
The following example shows how to increase the access rights of a profile.
Procedure
1 Modify a profile to allow complete access to the MML command log (IAA).
Modify a profile to have complete access (COM) to the MML command log:
ZIAA:<profile>::ACCESS=COM;
Further information
Example:
DN9770704 Issue: 14-0 © 2016 Nokia 69

Managing audit trails Information Security
A certain user ID is attached to the UNLIMITED profile in the MMI system. This profile
has medium access (MED) to the MML command log. The owner of the user ID needs to
have higher access rights to the MML command log. Modify the UNLIMITED profile to
have a complete access (COM) to the MML command log:
ZIAA:UNLIMITED::ACCESS=COM;
6.1.2 Accessing private and public commands in the MML

command log
Purpose
Every MML command in the system has a visibility attribute (VISIB). It determines
whether you are allowed to output a command from the MML command log. You define
the visibility of a command using the ACCESS parameter of the IAM command. The
possible visibility values for each command are public (PUBLIC) or private (PRIVATE).
If you set the visibility of a command to be public, it means that all users who have
medium or complete access rights to the MML command log are able to output this
command from the MML command log. Furthermore, if you set the visibility of a
command to be private, only users with complete access rights to the MML command log
are able to output this command from the MML command log. There is, however, one
exception: users with limited access rights to the MML command log are able to view all
commands which they have executed themselves, even if the visibility of these
commands is set to be private.
The visibility attribute of a command is set to public by default, and you should modify it
according to actual needs. Remember, however, that setting the visibility of critical MML
commands to private increases security only if a limited number of users has complete
access rights to the MML command log.
Procedure
1 Define MML command visibility (IAM).

Set the visibility of a certain MML command to be private:
ZIAM:<command>:VISIB=PRIVATE;
Further information
Example:
Set the visibility of the IAG command to be private:
ZIAM:IAG:VISIB=PRIVATE;
70 © 2016 Nokia DN9770704 Issue: 14-0

6.1.3 Outputting data from the MML command log to a logical

file
Purpose
You can output and, at the same time, filter the information from the MML command log
to the extent that your profile's access rights permit. You can choose the information from
the MML command log to be output on the MML terminal or to be saved in an existing
logical file. The default value is that the MML command log is output on the MML
terminal.
Before you start

If you have already created a logical file for the output of the MML command log, start
from Step 2. If you need to create a logical file for this purpose, start from Step 1 below.
Procedure
1 Create a temporary logical file (IIF).

Create a temporary logical file (for example, MMLLOGOUT) which is connected to
the system disk:
ZIIF::MMLLOGOUT,T:DEV=WDU-S;
2 Create a subdirectory (IWL).

If the logical file is connected to a file, the file has to be placed in the
MMDIRE/MLOGS directory. Create the MLOGS subdirectory:
ZIWL::WS:MMDIRE:MLOGS,100,2,QA;
3 Create a file (for example, MMLOUT.TXT) in the MMDIRE/MLOGS directory

(IWC).
ZIWC::WS:MMDIRE,MLOGS:MMLOUT,TXT,100000,QA;
4 Empty the file, if needed (IWE).

If the file already exists, but it needs to be emptied, enter the following:
ZIWE::WS:MMDIRE,MLOGS:MMLOUT,TXT;
5 Connect the logical file to the physical file (III).

Connect the MMLLOGOUT logical file to the MMLOUT.TXT physical file:
ZIII::MMLLOGOUT:,MMDIRE,MLOGS:MMLOUT,TXT;
DN9770704 Issue: 14-0 © 2016 Nokia 71

6 Output data (IGO).

Output from the MML command log the data on a user ID (for example, MSFORD).
Output only, for example, the data of the current day from 9 a.m. to 1 p.m., and save
the data to the MMLLOGOUT logical file.
ZIGO:,9–00,,13–00:USERID=MSFORD::OUTPUT=MMLLOGOUT;
6.1.4 Displaying the MML command execution of a certain

command group
Procedure
1 Display the commands that have been executed (IGO).

Display the MML command log to see which user IDs have executed the commands
in a certain command group during, for example, the past month.
ZIGO:2001-04-15,,2001–05–15:USERID=ALL:CMD=<commands>;
Further information
Example:Displaying the command execution of a certain command group
In this example the following information is given:
• The current day is 15th May 2001.

• The storage period of the MML command log was set to be 30 days at least 30 days
ago.
• Your user ID is attached to the UNLIMITED profile, which has complete access to the
MML command log.
1. Display the MML command log to see which user IDs have executed the commands
of the IA command group during the past month.
ZIGO:2001-04-15,,2001–05–15:USERID=ALL:CMD=IA;
The output of the example is the following:
IAI:PROFILE=ALL::;
/* 3 SESSION=02004 USERID=JSMITH 2001-05-14 10:08:13 */
/* 4 IAI:PROFILE=ALL::; */
/* 4c COMMAND EXECUTED */
/* 4c SESSION=02004 USERID=JSMITH 2001-05-14 10:08:16 */
IAT:IA:;
/* 4 IAT:IA:; */
IAM:IAM:VISIB=PRIVATE,:;
/* 4 IAM:IAM:VISIB=PRIVATE,:; */
72 © 2016 Nokia DN9770704 Issue: 14-0


IAI:USERID=JSMITH:COM:;
/* 4 IAI:USERID=JSMITH:COM:; */
IAA:PROFILE::ACCESS=COM,:;
/* 4 IAA:PROFILE::ACCESS=COM,:; */
IAI:USERID=JSMITH:COM:;
/* 4 IAI:USERID=JSMITH:COM:; */
The printout shows that during the past 30 days the JSMITH user ID has executed
the IAI, IAT, IAM, IAI (twice), and IAA commands. These commands were all
executed on 14th May 2001, and the execution of all commands was successful.
6.1.5 Displaying the command execution of an MML command
Procedure
1 Display the user IDs of the users that have used the command (IGO).
Display the user IDs of the users who have used a certain MML command:
ZIGO::USERID=ALL:CMD=<commands>;
Further information
Example:Displaying the command execution of a command
In this example your user ID is attached to the UNLIMITED profile, which gives you
complete access to the MML command log. Display, among other information, the
user IDs of the users who have used the IAS command today:
ZIGO::USERID=ALL:CMD=IAS;
Example:Displaying the command execution of a command
In this example your user ID is attached to the UNLIMITED profile, which gives you
complete access to the MML command log.
1. Display the user IDs of the users who have used the IAM command on 16th March
2001:
ZIGO:2001–03–16:USERID=ALL:CMD=IAM;
Example:Displaying the command execution of commands which a user is not

authorised to execute
In this example the following information is given:
• The current day is 16th March 2001.
DN9770704 Issue: 14-0 © 2016 Nokia 73

• Your user ID is attached to the UNLIMITED profile, which has complete access to the
MML command log.
1. Display the commands the HACKER user ID has tried to execute, and which he is
not authorised to use. Limit the search to today (=default) and yesterday, and direct
the output to the EXPORT logical file with the CSV (comma separated values) output
type.
ZIGO
:2001–03–14:USERID=HACKER:RESULT=N:FORMAT=CSV,OUTPUT=EXPORT
;
6.1.6 Making the MML command log close the current log file
Purpose
The MML command log takes care of changing the storing from one file to another.
However, you can control the MML command log by forcing it to close the current file and
continue storing in a new file. To do this, use the IGK command.
Procedure
1 Close the current MML command log file (IGK).

ZIGK;
6.1.7 Administering the MML command log

Purpose
If you intend to supervise or administer the use of certain commands, especially private
commands, or a certain user's execution of commands, your user ID has to be attached
to a profile with a complete access to the MML command log.
The MML command log has five (5) user-configurable parameters in the PRFILE
parameter file:
• WRITE_CACHE_TIMEOUT
• MAX_FILE_COUNT
• ADMINISTRATION_HOUR
• ADMINISTRATION_MINUTES
• STORAGE_LENGTH (1)
The STORAGE_LENGTH (1) parameter is in the MML_COMMAND_LOG (38)

parameter class. This parameter restricts the maximum time of storing the MML
command log files on disks. The minimum value is 3 days and the maximum value is 30
days. The default value is 3 days. You can change the value of this parameter using the
WOC command.
74 © 2016 Nokia DN9770704 Issue: 14-0

Procedure
1 Display the MML command log parameters and their values in the PRFILE
(WOI).
Display the MML command log parameters in, for example, PRFILE class 38 and
their values:
ZWOI:38;
Further information
Example:Changing the value of a PRFILE parameter
1. Lengthen the time the MML command log stores the records to 15 days. In other
words, change the value of the STORAGE_LENGTH PRFILE parameter. Enter the
value 15 days as a decimal value (D'15).
ZWOC:38,1,D'15;
6.2 Managing security reporting

Purpose
Security reporting supervises information security by reporting attempts to violate the
security of the network element. You can use security reporting to identify problems
involving information security. Security reporting collects security-related data from
various sources, such as the MMI system and the alarm system.
6.2.1 Resetting the security counter

Purpose
The security counters can be divided into two types: periodical counters and long-term
counters.
A periodical counter indicates the number of events collected since the previous output
of the periodic security counter report. The periodical counters are reset automatically
once the periodic security counter report is output.
A long-term counter contains the number of events collected since the previous reset of
the long-term counters. Long-term counters help you to define reasonable critical limits
for security counters. Furthermore, they help you to see if the situation shown by
periodical counters has suddenly changed a lot compared to the situation shown by long-
term counters. Unlike periodical counters, long-term counters are not reset when the
periodic security counter report is output. To set them to zero (0), use the IRR command.
DN9770704 Issue: 14-0 © 2016 Nokia 75

Procedure
1 Reset the long-term counter (IRR).

ZIRR;
6.2.2 Outputting a detailed security report

Purpose
The security counters actively and continually monitor security-related events. You can
output a detailed report on those events that you want to monitor. The event types you
can output are as follows:
• service terminal sessions

• MML sessions
• MML commands
• MML log writing failures
• network access
• SSH sessions
Outputting a detailed report is important at least when a critical limit has been reached.
The detailed report enables you to find out the reason for the excessive number of
events.
g Note: Remote and local users cannot be separated in the report.
Some commands are monitored automatically, others you can set to be monitored
manually. Monitoring means that security reporting is informed every time the command
is used. If you want the use of a single MML command to be monitored, use the IAM
command to define the command which is to be monitored.
Procedure
1 Activate monitoring of the MML command included in the report (IAM).

ZIAM:<command>:SECN=YES;
2 Activate MML command to be monitored.

Enter the command to be monitored (for example, USU):
ZUSU;
3 Output a detailed security report (IRO).

Output a detailed security report on the events associated with the MML commands
on the current day (default) from 7:00:
76 © 2016 Nokia DN9770704 Issue: 14-0

ZIRO:TYPE=MCO:TIME=07-00;
The MML command monitored (USU) is now shown in the security report:
Expected outcome
DETAILED SECURITY REPORT: MML COMMANDS
COMMAND USERNAME TERMINAL DATE TIME
USU USER01 HLR-MANCHES/VDU0 2003-04-30 08:05:24
STATUS: SUCCESS
IAM USER01 HLR-MANCHES/VDU0 2003-04-30 08:59:45

STATUS: SUCCESS
IOR USER02 OMC-BRISTOL/VDU1 2003-04-30 09:20:44

STATUS: SUCCESS
USS USER03 HLR-MANCHES/CAL 2003-04-30 13:21:11

STATUS: SUCCESS
USU USER03 HLR-MANCHES/CAL 2003-04-30 13:38:01

STATUS: TIME-OUT ERROR IN I/O SYSTEM
COMMAND EXECUTED
4 Output service terminal report (IRO).

If you want to display the service terminal report containing all events, give the
following command:
IRO:TYPE=SET;
In the execution printout, the DEBUG! identifier means that logon to the Network
Element (NE) has been done with a fixed username for the service terminal.
Expected outcome
DETAILED SECURITY REPORT: SERVICE TERMINAL SESSIONS
USERNAME TERMINAL ACTION DATE TIME
USER01 OMU-0 /REMOTE START 2003–04–30 14:35:01
STATUS: SUCCESS
USER01 OMU-0 /REMOTE STOP 2003–04–30 14:36:00

STATUS: SUCCESS
USER02 OMU-0 /REMOTE START 2003–04–30 14:37:07

STATUS: ILLEGAL PASSWORD
USER02: OMU-0 /REMOTE STOP 2003–04–30 14:37:07

STATUS: SUCCESS
USER03 CM-1 /REMOTE START 2003–04–30 14:37:07

STATUS: NO RIGHTS TO SERVICE TERMINAL SESSION
USER03 CM-1 /REMOTE STOP 2003–04–30 14:37:07
DN9770704 Issue: 14-0 © 2016 Nokia 77

STATUS: SUCCESS
COMMAND EXECUTED
6.2.3 Directing a security counter report to an output device

Purpose
Security counter reports are output on the devices to which the SECCOUNTA and
SECCOUNTB logical files are connected. As SECCOUNTA outputs the reports in ASCII
format, it can be connected to a printer. The binary report output of SECCOUNTB is by
default directed to a magnetic tape, but you can choose it to be directed to other I/O
devices as well. To interrogate and change the connections of logical files, use the IID
and IIS commands. For more information on output devices and logical files, see I/O
System Administration.
Procedure
1 Interrogate the connection of a logical file (IID).

Check which output device the logical file (for example, SECCOUNTA) is connected
to:
ZIID::SECCOUNTA;
2 Change the connection of the logical file (IIS).

If SECCOUNTA is connected to LPT-1, connect it, for example, to LPT-0 instead:
ZIIS:,:SECCOUNTA:DEV=LPT-1:DEV=LPT-0;
6.2.4 Outputting a security counter report

Purpose
To output a security counter report, use the IRP command. In addition to this, a periodic
report is output automatically according to the output interval and output time (which you
have defined using the IRT command), and also when one or more critical limits are
reached. To display the parameters used in the output of the security counter reports,
use the IRI command.
Procedure
1 Print a security counter report (IRP).

Print the security counter report:
ZIRP;
78 © 2016 Nokia DN9770704 Issue: 14-0

2 Set the output time for a security counter report (IRT).

Set the security counter report to be output at regular intervals (for example, at four-
day intervals at 7 a.m.; the value for the output time parameter must be entered
in the form hh-mm):
ZIRT:INT=4,TIME=07-00;
6.2.5 Changing the critical limits

Purpose
Critical limits are defined for:
• unauthorised attempts to connect to the service terminal

• unauthorised attempts to access the network with an invalid username or password
• unauthorised attempts to access the network with inadequate access rights
• attempts to establish an MML session by using an incorrect user ID or password
• attempts to enter an MML command with insufficient authority
• unsuccessful attempts to write the MML command log on disk
• checksum errors of commands in the MML Command Authority File
• SSH unauthorised attempts
g Note: It is important that you carefully consider the reasonable critical limits in the
network in question. Define the critical limits so that reaching a critical limit is not a
normal case but a possible sign of an attempt to violate information security.
Once a critical limit or its multiple is reached, security reporting sets the alarm 1569
CRITICAL LIMIT IN SECURITY REPORTING REACHED and outputs the security
counter report. The critical limits and the security counter parameters can be seen in the
security counter report, but you can also display them using the IRI command. To
change the limits, use the IRM command.
For example, assume that the critical limit is set to 10, and 8 events are counted. If you
now give the critical limit a new value, for example 6, which is lower than the number of
events counted, the alarm 1569 CRITICAL LIMIT IN SECURITY REPORTING
REACHED is set, and the security counter report is output.
Note also the relationship between the critical limits and the output interval. For example,
assume that the critical limit is set to 4 and the output interval is 3. It means that the
critical limit of the set output interval is scaled as 12 and the alarm is set off and the
report is output according to 12 and its multiples. The dynamic help of the IRM command
shows the parameter value 4, while the output report (with the IRP command) shows the
scaled value 12. The IRI command shows both the parameter value 4 and the scaled
value 12.
DN9770704 Issue: 14-0 © 2016 Nokia 79

Procedure
1 Change the critical limits (IRM).

Change the critical limits by defining new limits as needed:
ZIRM:<modified critical limits>;
6.2.6 Checking the output parameters of the counter report
Procedure
1 Check the output parameters of the counter report (IRI).

Check the parameters associated with the counter report output:
ZIRI;
6.2.7 Defining limits for security reporting

Purpose
The General Parameter File (PRFILE) contains those parameters which define certain
values that have an effect on the state of the system. There are two parameters which
control the filling up of any security reporting log files. These are as follows:
009:0028 The alarm limit for the filling up of any security reporting
SEC_EVENT_ALARM_LI log files. The default value is 70%.
MIT
009:0029 The monitoring interval for the number of security events.
SEC_EVENT_MON_PERI The default value is 7 days. This parameter determines the
OD time during which the alarm limit set in the 009:0029
SEC_EVENT_ALARM_LIMIT parameter is monitored.
For example, if you use the default values for these two parameters, an alarm is set if the
filling ratio of any security reporting log files exceeds 70% in a monitoring interval of
seven (7) days.
These parameters define when the 1570 SECURITY LOG ALARM LIMIT REACHED
alarm about the filling of any security reporting log files is set.
Note that if the file fills up only after the given monitoring interval, no alarm is set. The
alarm is set only when the SEC_EVENT_ALARM_LIMIT is exceeded in an interval
defined by SEC_EVENT_MON_PERIOD.
There are also two parameters which control alarm limits for raising alarms about
security reporting load.
80 © 2016 Nokia DN9770704 Issue: 14-0

009:0137 This parameter defines the limit for normal load by events
SEC_EVENT_LOAD_LIM per second. If the limit is exceeded, 3319 NORMAL LOAD
IT OF SECURITY EVENTS EXCEEDED alarm is raised. The
default value is 10 events per second.
3319 NORMAL LOAD OF SECURITY EVENTS
EXCEEDED alarm means that load of incoming security
events is over limit, which normally is caused by
misconfiguration or fault situation. The alarm is raised,
when load is over 009:0137
SEC_EVENT_LOAD_LIMIT (default 10) events in second
over half minute period. This alarm is of one-star type and
it is not cancelled manually.
009:0138 This parameter defines the limit for unsuccessful events in

SEC_EVENT_UNSUC_LI a half minute period. If the limit is exceeded, 3320 HIGH
MIT LOAD OF UNSUCCESSFUL SECURITY EVENTS alarm is
raised. The default value is 50 events per half a minute.
3320 HIGH LOAD OF UNSUCCESSFUL SECURITY
EVENTS alarm means that the amount of incoming
unsuccessful security events are exceptionally big. This
basically means that there is fault situation or security
attack. The alarm is raised, when the sum of unsuccessful
events in every type is above 009:0138
SEC_EVENT_UNSUC_LIMIT (default 50) in half a minute.
This alarm is of two-star type and it is not cancelled
manually, but it is cancelled automatically when the load of
unsuccessful events is under the limit.
To handle the values of the parameters, use the commands in the WO command group.
You can display the parameters in a given class and their values by using the WOI
command. To change the values of the parameters, use the WOC command.
Procedure
1 Display PRFILE parameters and their values (WOI).

Display the parameters, for example, in PRFILE class 9 and their values:
ZWOI:9;
2 Change the values of PRFILE parameters (WOC).

Lower the alarm limit for the filling up of the security reporting files, for example, to
60%. Since the PARAMETER VALUE parameter of the WOC command is a
hexadecimal, the decimal value 60 can be entered as D'60.
ZWOC:9,28,D'60;
DN9770704 Issue: 14-0 © 2016 Nokia 81

6.2.8 3445 SECURITY REPORTING DATA FILE CORRUPTED

alarm
Purpose
3445 SECURITY REPORTING DATA FILE CORRUPTED alarm indicates that
unauthorized modification of the security log file has been detected. The file was
modified by O&M user or there has been an I/O error.
Procedure
1 Check other audit trail logs, for example, session logs of FTP and command
log of MMI session.
If the log files does not contain anything suspicious, the reason might be an I/O error.
The alarm is of one star, and the alarm is cancelled manually.
6.3 Managing HTTP session log

Purpose
You can modify the HTTP Server Parameter File by editing the DW0–
LFILES/HPAFILGX.TXT configuration file.
For more information on HTTP logs, see Section HTTP log files.
Procedure
1 Click the /Administrator/Logs/Session log file/ command.
2 Select the LFILES/HPAFILGX.TXT file from the File path and name drop-down
list and click Open.
3 Read the file.

See the example below:
# Access log-file path and filename
AccessLogFile DW0–WEBFIL/ACCESS.XML
# Session log-file path and filename
SessionLogFile DW0–WEBFIL/SESSION.XML
82 © 2016 Nokia DN9770704 Issue: 14-0

6.4 Reading access log and session log

Purpose
You can easily read access and session logs.
Procedure
1 Click /Administrator/Logs/Access log file/ if you want to read access log, or

click /Administrator/Logs/Session log file/ if you want to read session log.
2 Read the file.
DN9770704 Issue: 14-0 © 2016 Nokia 83

Information security troubleshooting Information Security
7 Information security troubleshooting

Purpose
Here are some information-security-related problems that may occur when using or
configuring the network. For problems with configuring IP Security, see IP Security
configuration fails. For detailed information on individual alarms, see the alarm reference
manuals (Disturbance Printouts, Failure Printouts and Diagnosis Reports.
7.1 A blocked command can be executed by an

unauthorised user
Procedure
1 Check the user rights (IAI).

Check if the user has special authority (authority value 251) in the command class in
question. A superuser is allowed to execute also blocked commands. If the user has
special authority, see Step 3. If the user does not have special authority, see Step 2.
Check also the FTP accessibility of a user profile. To output the user profile of a
certain user identity and the contents of the profile, give the following command:
ZIAI:USERID=<user id>:COM;
2 Check the terminal's authority rights (IAI).

Check if the terminal has special authority (authority value 251) in the command
class in question. Blocked commands can be executed from a superterminal. If the
terminal has special authority, go to the next step. If the terminal does not have
special authority, go to Step 4. To output the profile names and contents of a certain
terminal, give the following command:
ZIAI:TERMINAL=<terminal>:COM;
3 Change the user or authority rights to block a command (IAA).

If you want to block the execution of the command altogether, change the authority of
the user or the terminal to 250 at the most. To define new authority requirements for
a profile, give the following command:
ZIAA:<profile>:<command_class>=<authority>;
4 Report the trouble if necessary.

If everything else fails, report the trouble according to the fault reporting practice.
84 © 2016 Nokia DN9770704 Issue: 14-0

Information Security Information security troubleshooting
7.2 Command can be executed by an unauthorised

user
Procedure
1 Check the terminal's authority rights (IAI).

Check if the terminal has special authority (authority value 251). On a superterminal,
any user can execute commands that belong to the classes to which the terminal has
special authority. If the terminal has special authority, go to the next step. If the
terminal does not have special authority, go to Step 3. To output the user profiles of
all user identities and the contents of the profiles, give the following command:
ZIAI:USERID=ALL:COM;
2 Change the terminal's authority rights (IAA).

Change the authority of the terminal to 250 at the most. After that the terminal is no
longer a superterminal, and the MML session authority is defined by the user
authority. To define new authority requirements for a profile, give the following
command:
ZIAA:<profile>:command class>=<authority>;

Report the trouble according to the fault reporting practice.
7.3 Command cannot be executed by an authorised

user
7.3.1 Command cannot be executed by operator
Procedure
1 Check your authority (IAI).

Check if your authority is the same or higher than the authority requirement of the
command in question. If yes, check if the terminal authority of the command class in
question is lower than the authority requirement of the command in question. If it is,
go to the next step. To output the user profile of a certain user identity and the
contents of the profile, give the following command:
DN9770704 Issue: 14-0 © 2016 Nokia 85

2 Change the terminal authority if necessary (IAA).

If you want to execute commands according to the authorities in your profile, change
the terminal authority to be at least as high as your own. To define new authority
requirements for a profile, give the following command:
3 Change your password if necessary (IAG).

The problem may be due to the fact that your password has expired. Try to change
your password, and go back to Step 1. If you cannot change your password, go to
the next step.
ZIAG;
4 Contact the user ID administrator.

Contact the user ID administrator. The user ID administrator must follow the
instructions in Section Command cannot be executed by user ID administrator.
7.3.2 Command cannot be executed by user ID administrator
Procedure
1 User ID administrator: Check if the user's password is valid (IAI).

Make sure that the user's password has not expired. If the password has expired, go
to the next step. If the password is still valid, go to Step 3. To output the user profiles
of all user identities and the contents of the profiles, give the following command:
2 User ID administrator: Change the user's password if necessary (IAS).

Change the user's password. If you cannot change the password, go to Step 4.
ZIAS:<user id>;
3 User ID administrator: Check the alarms (AHO).

Check if any of the alarms are set, and follow the recovery instructions given in the
alarm reference manuals. If there are no active alarms, go to the next step.
ZAHO;
4 User ID administrator: Report the trouble if necessary.

If all else fails, report the trouble according to the fault reporting practice.
86 © 2016 Nokia DN9770704 Issue: 14-0

7.4 The terminal authority has no effect on the user's

authorities
Procedure
1 Check the user rights (IAI).

Check if the user has special authority (authority value 251). A superuser can
execute commands that belong to the classes to which the user has special
authority. If the user has special authority, go to the next step. If the user does not
have special authority, go to Step 3. To output the user profile, give the following
command:
2 Change the user rights (IAA).

Change the authority of the user to 250 at the most. After that the user is no longer a
superuser. To define new authority requirements for a profile, give the following
command:

Report the trouble according to the fault reporting practice.
7.5 All terminals have too low authorities

Procedure
1 Restart the session if necessary.

If all terminals have too low authorities, the MML session must be started by a
superuser or on a superterminal. If there are no superuser IDs or superterminals in
the system, go to the next step. Otherwise, go to Step 3.
2 Restore UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG (IWY).

Restore UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG from a backup by
using either the IWY or the ICB MML command. If you cannot use the MML
commands, use the service terminal commands.
DN9770704 Issue: 14-0 © 2016 Nokia 87

3 Perform OMU restart after all the files have been restored.
OMU restart is needed to make the changes in the previous step take effect.
4 Check the terminal profiles (IAI).

Check the terminal profiles. If you need to modify them, go to the next step. Output
the profile names and the contents of all the terminals:
ZIAI:TERMINAL=ALL:COM;
5 Modify terminal profiles if necessary (IAA, IAE).

Increase terminal authorities by modifying the existing profile, or by attaching the
terminals to another profile that has enough authority, or by creating a new profile
with suitable authorities and attaching the terminals to that profile.
For example, to update the authority requirements of an existing profile, give the
following command:
ZIAA:<profile>:<command class>=<authority>;

7.6 A profile has too low authorities for command

class I
Procedure
1 Restart the session if necessary.

In this case, the MML session must be started by a superuser or on a superterminal.
If there are no superuser IDs or superterminals in the system, go to the next step.
Otherwise, go to Step 3.
2 Restore UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG (IWY).

Restore UPFILEGX.IMG, TAUTHOGX.IMG, and PAUTHOGX.IMG from a backup by
using either the IWY or the IBC MML command. If you cannot use the MML
commands, use service terminal commands.
88 © 2016 Nokia DN9770704 Issue: 14-0

3 Check the terminal profiles and the user profiles (IAI).

Check the terminal profiles and the user profiles. If you need to modify them, go to
the next step. Output the profile names and the contents of all the terminals:
ZIAI:TERMINAL=ALL:COM;
4 Modify the terminal profiles and the user profiles if necessary (IAA, IAE).
Increase the authorities by modifying the existing profile, or by attaching the terminal
or user ID to another existing profile with enough authority, or by creating a new
profile with suitable authorities and attaching the terminal or user ID to this profile.
For example, to update the authority requirement of an existing profile, give the
following command:
ZIAA:<profile>:<command class>=<authority>;

7.7 An unrequired profile cannot be deleted

Procedure
1 Check whether there are user IDs or terminals attached to the profile (IAI).
You cannot delete a profile as long as it is attached to any user ID or terminal.
Interrogate which user IDs or terminals are attached to the profile which you want to
delete. If there are terminals attached to the profile in question, go to the next step. If
there are user IDs attached to the profile, go to Step 3.
2 Attach the non-equipped terminals to the common profile (IAA, IAE).

There are always 16 terminals defined in the MMI system, and some of them may
not be equipped. It is recommended that you define one common profile for the
terminals that are not equipped. Attach all the non-equipped terminals to the
common profile and go to Step 4.
To create a new common profile with default values, give the following command:
ZIAA:<profile>;
To attach a terminal to the common profile, give the following command:
ZIAE:TERMINAL=<terminal>:<profile>;
DN9770704 Issue: 14-0 © 2016 Nokia 89

3 Attach the user IDs to another profile (IAE).

Attach the user IDs to another profile, and go to the next step. To attach a profile to a
user identity, give the following command:
ZIAE:USERID=<user id>:<profile>;
4 Delete all unnecessary profiles (IAR).

Delete all profiles that are not needed.
ZIAR:<profile>;

If all else fails, report the trouble according to the fault reporting practice.
7.8 Insufficient space for more profiles

Procedure
1 Interrogate unused profiles (IAI).

Interrogate all the profiles in the system to check if there are any profiles that are not
used by any user ID or terminal. If all profiles are in use, go to Step 3. If there are
profiles which are not in use, go to the next step.
ZIAI:PROFILE=ALL:COM;
2 Delete unused profiles (IAR).

Delete the profiles that are not in use.
ZIAR:<profile>;
3 Contact if necessary.
Contact Customer Service Center for help if you cannot make room for more profiles.
90 © 2016 Nokia DN9770704 Issue: 14-0

7.9 Insufficient space for more user IDs

Procedure
1 Interrogate all user IDs (IAI).

Interrogate all the user IDs in the system to check if there are user IDs that are not
needed any more. If all user IDs are in use, go to Step 3. If there are user IDs which
are no longer in use, go to the next step.
2 Delete unnecessary user IDs (IAD).

Delete the unnecessary user IDs to make room for new IDs. If you do not succeed,
go to the next step.
ZIAD:<user id>;
3 Contact if necessary.
Contact Customer Service Center for help if you cannot make room for more user
IDs.
7.10 A network connection cannot be established via

FTP
Procedure
1 Check that FTP access rights have been defined in the user profile.
Check that the user has a user profile with FTP access rights.
2 Check the length of the username.

If the username consists of more than 6 characters, an FTP session cannot be
started.
DN9770704 Issue: 14-0 © 2016 Nokia 91

Information Security: DN9770704 Issue 14-0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Security: DN9770704 Issue 14-0

Uploaded by

Copyright:

Available Formats

Nokia

Copyright © 2016 Nokia. All rights reserved.

f Important Notice on Product Safety

2 © 2016 Nokia DN9770704 Issue: 14-0

Summary of changes .................................................................... 8

3 Managing local user profiles........................................................ 32

4 Managing local users in the MMI system..................................... 45

DN9770704 Issue: 14-0 © 2016 Nokia 3

4.1 Creating and deleting local MMI user IDs.................................... 45

5 Managing network element integrated IPSec.............................. 56

6 Managing audit trails.................................................................... 69

7 Information security troubleshooting............................................ 84

4 © 2016 Nokia DN9770704 Issue: 14-0

7.3 Command cannot be executed by an authorised user.................85

DN9770704 Issue: 14-0 © 2016 Nokia 5

6 © 2016 Nokia DN9770704 Issue: 14-0

DN9770704 Issue: 14-0 © 2016 Nokia 7

8 © 2016 Nokia DN9770704 Issue: 14-0

DN9770704 Issue: 14-0 © 2016 Nokia 9

1.1 Authority management in the MMI system

Table 1 MML command authority requirement according to command status

Group 1 Very critical commands which you use 250

10 © 2016 Nokia DN9770704 Issue: 14-0

Table 1 MML command authority requirement according to command status (Cont.)

Group 3 Commands which you use to change 150

Group 4 Commands which you use to change 100

Group 5 Commands which you use only to 50

DN9770704 Issue: 14-0 © 2016 Nokia 11

The maximum number of MML terminals is 16 (VDU0-VDU15). In addition, the command

• 250 in command class G

• 250 for command classes N, O, and Q

Figure 1 Example of MML session authority

12 © 2016 Nokia DN9770704 Issue: 14-0

DN9770704 Issue: 14-0 © 2016 Nokia 13

The following login situations may thus occur:

Table 2 Possible login situations

Situation Valid login method

14 © 2016 Nokia DN9770704 Issue: 14-0

Security reporting of service terminal sessions

1.1.1 Profile management

• the right to enter all commands in command class G

DN9770704 Issue: 14-0 © 2016 Nokia 15

Figure 2 Example of a profile

1.1.2 Security policy management

16 © 2016 Nokia DN9770704 Issue: 14-0

• The length of a password is minimum 6 characters. The maximum length of a

DN9770704 Issue: 14-0 © 2016 Nokia 17

Password Policy is an optional feature.

18 © 2016 Nokia DN9770704 Issue: 14-0

g Note: You cannot set the two passwords to be the same.

Information security is also ensured by the encryption method (encryption key)

DN9770704 Issue: 14-0 © 2016 Nokia 19

20 © 2016 Nokia DN9770704 Issue: 14-0

'DELAY APPLIED. PLEASE WAIT UNTIL 14:32.'

DN9770704 Issue: 14-0 © 2016 Nokia 21

Table 3 Ensuring information security in the MMI system

1. Check command authority requirements. IAT

2. Create profiles. IAA/IOA

3. Define password policies for user profiles. IVK

4. Create user IDs with correct profiles. IAH

5. Attach terminals to correct profiles. IAE

6. Enable password history checking. IVH