SOLUTION BRIEF

Motorola Operations and

Maintenance Products:
GSR9 Security Strategy Overview
Introduction
The issue of security and, in particular, minimizing vulnerability to security attacks is gaining importance
across the industry. High profile attacks taking advantage of Operating System vulnerabilities, and computer
viruses and worms, are gaining more and more media focus. These cause problems in organizations which
depend on computing, from inconvenience to large scale damage, and are causing these Operators to
increasingly scrutinize the security of all their platforms.

As a result, network service providers are putting more security functionality into their offerings. More dedi-
cated security products are available in the market place and most large organizations have or are developing
security policies for their computing equipment.

Motorola has been actively examining the security of our products and the security needs of our customers.
Our products have been audited for overall security and activities have been taken to determine appropriate
measures to reduce these threats.

This white paper focuses on the Motorola Operations and Maintenance products delivered by Networks and
Enterprise and introduces some key security concepts which apply to these products. Security measures as
outlined in the white paper apply to all the interfaces and infrastructure including those leased out from third
party service providers, i.e. deals with security on an end to end basis.

This Paper discusses the topic of product security and describes Motorola’s current thinking on the topic.
It also focuses on development in product security which will enhance future product offerings. Product
specific information is provided where that information exists and where it is considered to be useful to cus-
tomers. Customers are reminded that Motorola adheres to the M-Gates process and future product content
is not committed until it has passed through the appropriate planning gates.

The security enhancements discussed here are covered by two specific Feature Requests (FRs), which are
to be delivered in the GSR9 release:

• 27508: BSS User Security Management

• 25663: Implement Secure Services on Solaris based Operations and Maintenance Products

2 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Executive Overview
Security Concepts:

One of the key concepts in determining appropriate security functionality is that of the cost-function curve.
There is no such thing as a 100% secure system and at some point the cost of securing a system becomes
greater than the cost of security violations. The optimal investment point is the crossover point – that is a
company should aim to invest in the security of the system only up to the point where further investment
actually costs more than potential violations. The challenge for every company is in determining the cross-
over point or the point of optimal investment.

The method of determining the optimal investment is to examine protected assets, determine the threat
to those assets and perform a risk analysis on the assets. Threat analysis looks at the source of the threat
– from inside the company and external sources. Risk analysis considers not only the technical risks but
also the likelihood of an attack as well as the potential cost of recovery. From that point it is possible to
determine the priorities for protection of the Operators’ assets and the degree of investment to be made in
securing those same assets.

Each company will be different. Operators will have different threats, different risks and different priorities.
This in turn provides a challenge for vendors who need to take a similar approach to the cost-function curve
while meeting the different needs of their customers.

Although there are some differences, there are also common themes and some excellent references and
guides for suppliers and customers alike. References to further material appropriate to the Motorola Opera-
tions and Maintenance products and the Operations and Maintenance space are included in this Paper’s
bibliography.

Cost

Expected
total cost

Cost for security

enhancing mechanisms

Expected total
cost for violations
Security
level
100%
Optimal Level

3 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Executive Overview Continued
The Vendor – Customer Relationship:

Most large Operators develop and implement a Company wide security policy. Security policies tend
to vary in detail from company to company but most have common elements – these will deal with
organizational responsibilities, systems security architecture and design, user considerations, authenti-
cation, authorization and integrity, audit and monitoring.

Also most large Operators and telecom service providers consider security as a key strategic area
which requires long term planning leading to the selection of terms of distribution, setting product
roadmap, market entry and related issues. Adoption of implementation of a specific security policy
depends on considerable market research based on primary information (derived based on customer
visits, field trials, etc.) and also based on authentic secondary sources like newspaper reports, opinions
from leading IT security experts, IT and telecom regulatory authorities of different countries, security
magazine reports, featured articles from vendors of security and encryption products, etc. Market
research should primarily focus on diverse customer needs, competitors’ strategy, impact of regulatory
environment on the industry for secured telecom products and such issues. However the most impor-
tant issue in respect to selection of a specific security policy is consensus between the vendor and the
customers. Vendors should be ready with solutions that customers will accept and must consider the
best possible solution for the current state of technology.

An example that illustrates this point is the application of a single sign-on or company wide user
management solution. If the vendor supplies a solution it will only satisfy those customers who have
already selected that particular solution for their other applications. The ideal situation is for the vendor
to enable their products to work with various solutions in this space.

A particular challenge for Telecom providers is that although there are emerging internet security guide-
lines and standards, standards in the telecoms space are still in early development. This is particularly
true for Operations and Maintenance of telecom equipment.

In the absence of standards, the alternative for a vendor is to work closely with a number of separate
vendors, ideally with differing security needs, and determine the common themes across these ven-
dors. The vendor can then address common security issues across their customer base. Motorola has
taken this approach in the Operations and Maintenance space and has developed a security roadmap
for its Operations and Maintenance products in conjunction with a number of our customers across
different telecom technologies and markets.

Communication is Key:

Due to the complexity of the issues around security and the varying needs of each customer, one of
the key activities is communication. A clear definition of the vendor’s security capabilities and prod-
uct functionality, a mutual understanding of what the vendor undertakes and how this will impact the
customer’s security activities helps both the vendor and the customer to priorities investment in this
area.

Motorola has been working with a number of customers in the Telecom area, in different geographi-
cal regions across the globe and with diverse markets to come up with a list of key areas and product
improvements. Proposed functionality has been presented to customers and their feedback has been
valuable in helping to determine priority and timescales for delivery.

The Networks and Enterprise organization, within Motorola, has taken these inputs and developed a se-
curity roadmap for the Operations and Maintenance products. This roadmap determines future product
developments as well as priorities.

4 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Operations and Maintenance - Product Security Considerations
When addressing security for products, the profile of usage for that product, the threat of attack on the
product and the potential impacts of attack on that product must be taken into consideration.

BSS User Security Management:

One of the potential risks to security arises from the current paradigm of shared password access to
the radio access network infrastructure machines (Network Elements). There is no concept of user ac-
counts for accessing infrastructure equipment in the network – all the information required for access
is available in the public domain. In the course of time, there is a possibility of this information getting
leaked out to a number of people including subcontractors, third party service providers, etc. In the
case of Operations and Maintenance products, consideration is given to the threat of unauthorized
access both from inside and outside the company, protection of key data and traceability of user activi-
ties.

As a solution (under FR 27508), Motorola plans to incorporate a network wide user account for every
user who wants to access network elements. Motorola also proposes to have centralized control over
these network wide user accounts through Operations and Maintenance machines (OMC-Rs) which
will result in the consolidation of the following functionalities pertaining to the user accounts:

• Authentication
• Access Control
• Activity logging
• Data confidentiality
• Communication Security

To facilitate user management in the manner mentioned above, GSR9 will provide a framework to carry
user credentials in a secured manner from network elements to the OMC through the use of a sym-
metric key encryption algorithm.

Authentication:

Authentication requires that the system can guarantee identity of users, processes and other devices
accessing the system. Possible authentication security measures include password complexity check-
ing and symmetric key cryptography.

Motorola is proposing the introduction of UNIX style authentication at the OMC-R with necessary
support from LDAP and NIS or any other naming service, for all the users except the field engineering
users. Field engineer user accounts for network elements will be authenticated locally at the elements.

Access Control:

Access control defines the ability of the application or product to allow appropriate access by users to
various elements of the system. These include access to network elements, databases and applica-
tions.

Motorola’s products have always contained functionality to restrict access control and the introduc-
tion of the Geographic Command Partitioning feature in GSR6 serves to enhance this functionality and
moves the product towards a role based access control model (RBAC). However, GSR6 style RBAC as
mentioned above only provides access control for indirect access to the Network Elements as sug-
gested in the TMN framework which suggests elements should be controlled exclusively through the
element manager (OMC-R in this case). This does not provide for access control for direct access to the
element from its console, as is done traditionally in Motorola radio network through terminal emulators
and similar programs.

As part of the proposed GSR9 feature set, Motorola has introduced RBAC for the second type of direct
access which has been missing prior to GSR9. It in no way extends or refines the functionality of the
GSR6 geographic command partitioning feature, but has extended the full functionality to direct access
to the Network Elements.

The BSS User Security feature uses the concept of user profiles in the OMC-R to control the access of
users to the Network Elements. Each OMC-R user has access to a specified subset of Network Ele-
ments and will be denied access to other NEs. Also each user has access to a specified command set
based on their access level.

5 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Operations and Maintenance - Product Security Considerations CONT ...
Activity Logging:

The principle of activity logging is to provide accountability of activities that take place on the network
elements.

This involves maintaining a number of log types:

User activity logs for normal (non-privileged) users for direct access
User activity logs for field engineering users for direct access
User activity logs for normal users for indirect access
More advanced functionality provides for a central archive system for logs and a user interface to ac-
cess and search the logs.

The feature proposal for GSR9 includes the logging all user activity on the network elements. Log files
will be maintained on a per Network Element, per user basis.

Data Confidentiality:

Data confidentiality refers to the protection of data from unauthorized access or viewing, protection
of system information from unauthorized access or viewing and protection of application executables
from unauthorized access. Solutions to address issues of data confidentiality include use of access
control as previously described and encryption of key data.

Key Operations and Maintenance data identified for protection is the credentials of the network ele-
ment users (passwords) used for authentication for any radio equipment in the network. When pass-
words are stored, either in the database or in some temporary location, they are encrypted through a
robust symmetric key block encryption algorithm. This will protect the data against high profile diction-
ary attacks or brute force attacks.

Communication Security:

Communication security guarantees that secret data pertaining to the user authentication credentials
will not be leaked out to unauthorized users. This may happen in any of the ways mentioned as follows:

– temporary files with password information in it stored on NFS mounted file systems
– session replay
– session hi-jack
– man-in-the middle attack

A solution to address issues of communication security is to encrypt the secret credentials during
transfer over the interface. Encryption will be provided through the same symmetric key block encryp-
tion algorithm as used in the case of maintaining Data Confidentiality.

Secure Services:

The second area of potential threat to security is the use of non-secure remote access utilities on
Operations and Maintenance platforms, including rsh, rcp, ftp and telnet. These are used in a number
of scripts on OMC-R and adjunct platforms to execute remote commands without password authenti-
cation. These utilities are to be replaced (under FR 25663) with secure equivalents which make use of
key-based authentication.

6 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Motorola Operations and Maintenance - Product Security Improvements
Motorola has worked with a number of customers formally and informally to identify security improve-
ments. In particular for the GSM Operations and Maintenance Products we have taken audit feedback
on our products from customers, carried out internal security audits on the products, received docu-
ments from customers detailing their security requirements and met with customers to discuss their
security concerns and review our security roadmap.

These efforts have been of considerable benefit particularly in focusing our efforts in key areas and
prioritizing our activities in this space.

The previous section of the document gives a general overview of the topics under consideration. This
section gives specific detail on product changes that are being made as a result of our work in the area
of security.

Network wide account (FR 27508):

Motorola’s 2G OMC-R, as already mentioned, uses shared password access for all the users for the
purpose of accessing radio equipment and other elements in the network. The password access has
been mainly for accessing a higher command set at the elements rather than providing full fledged
security. So, prior to GSR9, usage of password verification at elements (BSS or RXCDR) has no concept
of authentication attached to it – it has been used merely as a mechanism of controlled access to the
MMI and EMON command set at the elements.

In GSR9 and in the roadmap for all the future releases, Motorola attempts to define the concept of a
network wide user account which can be used for authentication of user credentials. As per the solu-
tion, user credentials will be as defined by UNIX and user authentication will also happen at the UNIX
account. User credentials supplied by the user at the login prompt at the element will be presented to
the OMC-R, which will be authenticated through NetBSD compliant PAM open APIs. This allows the
OMC-R to get the credentials authenticated by UNIX in non interactive mode.

Command partitioning will be put in place to restrict the access of users to specific commands at the
NE. Users will be assigned one of 4 defined access levels, each of which allows access to a different
command set. The set of commands which are allowed under each access level is fixed, with level 1
allowing read-only commands and level 4 allowing full access to all commands.

Also provisions have been made for storage of account information, functionality of management and
control of the root account or field engineering account (fieldengX). Three field engineering accounts
(fieldeng2, fieldeng3 and fieldeng4) are defined. Access levels to the network element command set
for each of these field engineers are also defined, and as per the rule, fieldeng3 and fieldeng4 are
entitled to access a more privileged command set than fieldeng2. Similarly, fieldeng4 can access all the
commands and is considered to be more privileged compared to fieldeng2 and fieldeng3. The pass-
words for these accounts are to be stored centrally at the OMC-R and, when changed, will be propa-
gated across the entire network. Apart from this propagation which is initiated by the OMC-R operator,
elements will download this information if the OML link between the OMC-R and network elements
comes up after remaining down for a specified duration. This will ensure that the passwords are always
the same on both sides of the interface. fieldengX passwords stored at the elements will be used for
authentication of the root account.

7 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Motorola Operations and Maintenance - Product Security Improvements
CONT ...
Secure services (FR 25663):

FR25663 covers the replacement of the older insecure services such as rsh, rlogin, rcp, ftp and telnet
with secure services (secure shell) in the GSR9 OMC-R. The OMC-R shall disable all the insecure ser-
vices as part of this feature in GSR9. Therefore, all the areas that have remote system calls to OMC-R
will be impacted.

Secure Shell was designed as a replacement for the Berkeley r-protocols (also known as rexec ser-
vices). With the exception of key management, it can be used as a simple drop-in replacement. Secure
Shell is a replacement for the traditional rsh, rlogin, rcp, ftp and telnet commands. This integration
increases security within the system by assuring that interactive sessions with the Solaris OS are
encrypted and strongly authenticated.

The various .rhosts files are no longer used for authentication and will not be created on a clean in-
stalled system. The /etc/hosts.equiv file is still required for remote Informix access, but is not used for
any other purpose.

Automating actions with the Secure Shell client, ssh, is mostly a straightforward replacement of either
the rsh or rlogin commands. There are some key differences in how ssh performs compared to its
counterparts. Additionally, there are the matters of alternate authentication credentials and host keys.

rsh(1) versus ssh(1):

In basic usage, the ssh(1) command is a direct replacement for the rsh(1) command. The major differ-
ence between them is authentication. If an ssh(1) command is issued and a password or passphrase is
needed, it will be prompted for, then the command will be executed. In this case, the rsh(1) command
will fail with a permission denied error.

Before using the ssh, the passwordless login needs to be enabled between the two machines for
secure login.

Example: To execute “hostname” on omc3 machine from omc2 machine using remote operation.

Scenario with Remote Service omc1:omcadmin > ssh omc2 -l omcadmin

hostname
omc2:omcadmin > rsh omc3 -l omcad- omc2
min hostname
permission denied Since passwordless login is enabled between
omc1 and omc2, remote operation doesn’t
Scenario with Secure Service ask for the password.

Case 1: Passwordless login is NOT en-
abled between the two machines (omc2
& omc3)
omc2:omcadmin > ssh omc3 -l omcad-
min hostname
omcadmin@omc3’s password: <Enter
the password>
omc3
As passwordless login is not enabled
between omc2 and omc3, the password
for omcadmin needs to be provided
Case 2: Passwordless login IS enabled
between the two machines (omc1 &
omc2)
For background jobs, ssh(1) also supports the
-n option to set standard input to /dev/null.
Alternately, -f sets standard input to /dev/null
after password or passphrase requests, but
before command execution. If no remote
execution is required and only port forward-
ing requested, the -N option can be used
(Protocol 2 only).
Also, ssh will forward X11 traffic securely
back from the remote machine. The DISPLAY
variable will automatically be set by ssh to
accomplish this, and assuming the DISPLAY
variable is not reset manually, no xhost or
xauth command is required on the local sys-
tem to enable this.

8 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Motorola Operations and Maintenance - Product Security Improvements
CONT ...
rcp(1) versus scp(1):
The rcp(1) command has the same authentication problem as the rsh(1) command. As with ssh(1), the
scp(1) command will prompt for passphrases and passwords as needed. Unlike the rcp(1) command,
scp(1) displays a progress meter as it copies the file. This can be disabled with the -q option. The scp(1)
command can also optionally compress the data stream using the -C option.

Example:

Scenario with Remote Service

Trying to copy “wall.txt” from omc1 to omc2.

omc2:omcadmin > rcp omcadmin@omc1:/home/omcadmin/wall.txt .

permission denied

Scenario with Secure Service

Case 1: Passwordless login is NOT enabled between the two machines (omc1 & omc2)

omc2:omcadmin > scp omcadmin@omc1:/home/omcadmin/wall.txt .

omcadmin@omc1’s password: <Enter the password>
wall.txt 100% |*****************************| 260 00:00

Case 2: Passwordless login is enabled between the two machines (omc1 & omc2)

omc2:omcadmin > scp omcadmin@omc1:/home/omcadmin/wall.txt .

wall.txt 100% |*****************************| 260 00:00

telnet(1) versus ssh(1):

The telnet(1) command is occasionally used to automate connections to systems in situations in which
the rlogin(1) and rsh(1) commands cannot be used. Automating a telnet(1) connection requires the
script to pass the login, password, and command to the telnet(1) command to execute.

There are no occurrences of telnet in the OMC–R.

9 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Motorola Operations and Maintenance - Product Security Improvements
CONT ...
Support from OPERATING SYSTEM and service packs in GSR9:

For the BSS user security feature (27508), the OMC-R GSR9 machine will be configured with all the
NetBSD compliant PAM specific run time libraries to allow OMC-R applications to authenticate the user
from direct login at the element. This configuration will again be dependent on the naming service in
use at the OMC-R and the system will use the appropriate PAM libraries compliant with the naming
service.

Apart from runtime libraries, PAM specific configuration files also are installed at the time of cutover,
clean install or upgrade. These configuration files will also depend on the naming service (LDAP, NIS or
NIS+) in use at the OMC-R (see Appendix A for examples of PAM configuration files).

For Secure Services (25663), all of the secure access utilities will be installed on the Operations and
Maintenance platforms automatically as part of the OS installation or upgrade. The non-secure legacy
utilities will be disabled. Authentication keys will be automatically set up to allow passwordless access
between platforms.

Support for data confidentiality in storage and transfer between infrastructure machines:

To provide access control and authentication at the OMC-R, user credentials entered from the ele-
ments are to be carried over the interface from elements to the OMC-R. The interface may not be
100% under the control of Motorola infrastructures and may be in control of a third party service
provider depending on the agreement. This is a potential threat to the confidentiality of the information
carried over the interface which consists of user password and user id etc.

To circumvent the problem, data is encrypted using robust 128 bit symmetric key block cipher called Ri-
jndael algorithm implementing the AES standard called as “AES algorithm” in short. The algorithm may
be used with the three different key lengths indicated above, and therefore these different “flavors”
may be referred to as “AES-128”, “AES-192”, and “AES-256”. However AES-128 has finally been adopted
as the chosen standard to be implemented – this will provide reasonable degree of data confidentiality
at a low overhead.

There are some distinct advantages of AES-128. It is especially secure against low and medium profile
attacks. This is based on the research studies conducted by NIST (National Institute of Standards)
where it is observed that the algorithm provides enough security margin against these attacks based
on a study on the reduced round variants of this algorithm. In this the number of rounds in the stan-
dard algorithm is reduced from 10, 12 or 14 and an experimental attack is mounted under controlled
environment. Evaluation is done based on the study which, in effect, would ensure that attacks never
get worse over time.

Also, research findings by NIST suggest that AES will work well with different machine architectures
– 16, 32 and 64 bits. AES applications can be ported to different platforms irrespective of their underly-
ing architecture.

10 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

 Motorola Operations and Maintenance - Product Security Improvements
CONT ...
Legal support and export control formalities:

GSR9 offers the security feature on a non-purchasable basis – i.e. users of GSR9 OMC-R need to use
the functionality provided by the feature which cannot be disabled.

Because of the use of encryption functionality on the OMC-R, product personality will change to a se-
cured OMC-R. Encryption/Decryption functionality will be achieved by the use of AES algorithm which
comes under export control classification initiative undertaken by Dept. of Commerce, US. To satisfy
this requirement, two separate ECCNs has been allocated to OMC-R - The software (stand-alone)
would be in ECCN 5D992NR and the programmed hardware would be in ECCN 5A992NR.

One important point to be noted here is that these ECCN numbers are allocated to OMC-R irrespective
of that existing for the AES application. AES application may or may not come up as a separate reus-
able component and that may require a separate ECCN number for that component as well. However,
that is beyond the scope of the white paper.

Offline support through command line utilities:

Motorola proposes to render offline support to the user to verify correctness of the field engineering
passwords from the OMC-R splat exclusively by the OMC-R operator. This is achieved through two
command line utilities:

1. verify_field_pass - will require the field engineering account name i.e. fieldengX (X = 2,3,4)
and the password in plain text. From the command line, only the account name will be supplied.
Subsequently, the tool will enter in interactive mode where it will ask for the fieldengX password to be
entered. Password entered will not be echoed to the screen, but ‘*’ will appear.
2. .field_pass - will be able to display all the field engineering passwords in plain text. The utility
will have executed permission only for omcadmin and will be stored as hidden file.

A typical scenario where this may be used is in the event of a dispute arising regarding the correct-
ness of the root/field engineering passwords. As mentioned earlier, root (fieldengX) passwords are to
be stored at the OMC but authentication for these root users are done locally at the elements. In the
event of some authentication failure at the elements (BSS or RXCDR), operator at the OMC-R will be
left with 2 options – either to accept the allegation made by the field engineer (the one trying to enter
the element through the MMI by issuing “login” command) that encryption and authentication logic is
wrong as it fails to detect the correct password or the password entered is actually incorrect. To elimi-
nate the first possibility, the operator can avail of these offline tools and utilities.

Impact of terms of distribution, offerings:

Change in the product personality and use of encryption algorithm and also implementation of the se-
curity feature has brought the product under the regulations of US Dept of Commerce. Because of this,
Motorola may require to revisit terms of the distribution of the product (especially because it is offered
on a non-purchasable basis), existing agreements with the channel partners / agents in the countries
where this is offered on a need basis.

Offering of the product does not require a separate license as AES Rijndael is being offered by the
inventors free of charges (royalty and any charges associated with the Intellectual Property).

11 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

 OMC-R Impacts
BSS User Security (FR 27508):
The BSS User Security feature impacts the following OMC-R components:

• Load Management
• CMMIB
• Operations and Maintenance Utilities
• GUI
• Alarms
• Sysadmin

Updates to these components will be made to support the new field engineer user accounts and pass-
words, as well as the user access levels for normal OMC-R users and other new attributes. The OMC-R
will authenticate login requests from network elements from users logging in directly to the NE. A user
interface will be provided for managing and updating field engineer passwords and the banner text
which is displayed when a user logs in to the NE.

The field engineer passwords will support password aging, which will require the passwords to be
changed after a configurable time. If the passwords are not changed after this time, an alarm will be
generated by the OMC-R.

User activity log files will be uploaded to the OMC-R. The existing upload mechanism of the OMC-R
will be used for this. The OMC-R will store and maintain these log files for a configurable period.

The OMC-R clean install and upgrade will support the creation of field engineering accounts and pass-
words, and all of the new attributes for NEs and users required to support the feature.

Secure Services (FR25663):

All the existing OMC-R files (C, C++) and scripts (shell, tcl, dt) that involve insecure services are
replaced with the secure services. All the existing insecure services in GSR9 OMC-R will be disabled.
Therefore, all OMC-R components that use remote system calls are impacted.

The key-based authentication protocols within the systems are set up automatically by the install. Es-
tablishment of non-passworded secure connections within the systems that have the keys is also set
up by the install. The process of creating a new user will be updated to create ssh keys automatically
once the user is set up. The install will automatically start the ssh daemon.

The following OMC-R components are impacted by the GSR9 Secure Services feature (FR25663):

• Load Management
• Cell-X
• CMMIB
• Performance Management
• OPERATIONS AND MAINTENANCE Utilities
• GUI
• MIB
• Utilities
• Audit
• Licensing Audit
• Call Trace
• SysAdmin

These components will be modified transparently to use secure services in place of the existing ser-
vices.

12 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Customer Impacts
FR 27508 BSS User Security:
The BSS User Security feature is not an optional or purchasable feature and will be installed on all GSR9
systems. Upon installation or upgrade of the GSR9 release, all users configured on the OMC-R will
have direct access to the Network Elements using the user accounts and passwords used to access
the OMC-R. The command set which each user can access will be determined by that user’s access
level, which is initially set to a default value of 1 (the lowest level of access), with the exception of the
omcadmin account, which has an access level of 4. Access level for a user can only be modified by
omcadmin through the Access Control option on the OMC-R GUI.

When a normal NE user logs into the NE directly, they will be prompted for their password, which is
the same as the password used to access the OMC-R. When accessing the NE from the OMC-R using
remote login, no password is required.

The root level or field engineering accounts will also be created automatically. These accounts are only
intended for logging directly into the NE when the OML is out of service. Passwords for these ac-
counts are maintained at the OMC-R and can only be changed by omcadmin. Because these accounts
are to be used only for local access to the NE, they cannot be used to remote login via the OMC-R. Any
existing OMC-R users with the names fieldeng2, fieldeng3 or fieldeng4 will be disabled on upgrade to
the GSR9 release, and these usernames should not be used for new OMC-R users.

Because each user account is assigned a specific access level, the chg_level command will no longer
be supported to change from one access level to another on GSR9 NEs. Therefore any customer-cre-
ated scripts which run commands on NEs must be modified. If the NE on which the commands are
to be executed is GSR9 or later, the chg_level command should not be used. The chg_level command
must still be used for pre-GSR9 NEs. Scripts should be executed only by a user who has the required
permissions to execute any of the BSS commands required. For example, if a script requires a com-
mand to be executed which is only available by access level 4, then only users with this access level
will be able to execute it.

Any users who need to directly log in to network elements must have user accounts on the OMC-R. If
these accounts did not previously exist then they must be created on the OMC-R and the users given
the appropriate access levels before they can login to GSR9 NEs. Also any users of other OPERATIONS
AND MAINTENANCE platforms including NHA, NetCool and NMC which support Rlogin to the NEs
through the OMC-R must have user accounts on the OMC-R.

FR 25663 Secure Services:

Implementation of Secure Services will have a positive impact to the customer with respect to usabil-
ity; ssh automatically forwarding (optionally compressed) X11 traffic takes away much of the inconve-
nience regarding setting the DISPLAY and associated permissions. The feature should not have any
adverse impact on the performance of the system as a whole.

All Operations and Maintenance platforms will be automatically updated by the upgrade/clean install
procedure to set up the key-based authentication protocols within the systems. The key-based authenti-
cation protocols establish password-less secure connections within the systems that have the keys set
up. The platforms this applies to are OMC-R, GUI server, GUI client, DataGen, NHA, MARS, NBI server,
Q3 server and Web access server.

If any customer scripts/tools use telnet/ftp/rsh or rcp to communicate with the OMC-R, these will need
to be updated to use ssh/sftp and scp as appropriate. For this to be passwordless, the appropriate keys
will have to be distributed to the system on which the tool is running (if this is not the OMC-R or the
GUI server).

If any customer scripts use a remote Informix connection to the OMC, the /etc/hosts.equiv file will
need to be updated to add the system from which the connection is being attempted, even though rsh
is no longer in use.

13 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Customer Impacts

CORBA NBI Secure Services

NMC FC/CM/PM • Feature description
• This integration increases security within the system by en-
suring that interactive sessions with the Solaris OS are encrypted
and strongly authenticated.
• Applications and Benefits
• Allows for enhanced security through encryption of sensi-
tive sessions
• Allows for strong authentication of both the client and
3GPP R6 CORBA NBI
server machines
• Integrate Motorola OMC’s with service
providers NMC
• Allows integrated 2G/3G network manage-
ment, optimization and planning
• Fault Management
• Configuration Management
• Performance Management

BSS Security
• Feature description
• Each user will have their own user-
name, password and access level Link Outage Diagnosis
• All authentication /
Management of • Feature Description
passwords will be done by the OMC-R • A package of functionality added to
• All modify commands will be logged MSI/NIU/NIU2 devices to aid fault isolation
at the BSS with user, date and time stamp and recovery for BSC->BTS and BTS->BTS
link related issues
• Applications and Benefits
Improved security and access control on • Applications and Benefits
the network • Allows service provider to identify
Additional logging provided for full trace- problematic links before alarms reported
ability on network changes Reduce diagnosis time – tests executed at
the OMC-R
Much greater confidence on root cause
accuracy
Assists No Fault Found assessment

The diagram above shows the main elements of the Operations and Maintenance features in GSR 9.
Security enhancements play a major part of these, as described in the main body of this paper.

Changing environments and changing product capabilities have caused Motorola and it’s customers to
evaluate the security needs of the networks.

Motorola has reacted to the changing requirements and capabilities for security and will continue to
react. This paper provided an introduction to those security considerations which are most relevant to
Motorola’s Operations and Maintenance Product Suite and details of the product changes which will be
delivered in GSR 9.

Your feedback on this paper is welcome as we wish to engage customers in an ongoing dialog about
our product content and release prioritization as well as maintaining our focus on the area of product
security.

14 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Useful References
1. “Integrating the Secure Shell Software”: http://www.sun.com/blueprints/0503/817-2821.pdf
2. “Secure Remote Access with the Solaris 9 Operating Environment”: http://www.sun.com/software/
whitepapers/solaris9/secureaccess.pdf
3. Joan Daemen and Vincent Rijmen, “The Design of Rijndael: AES - The Advanced Encryption Stan-
dard.” Springer-Verlag, 2002. ISBN 3-540-42580-2.

Appendix: PAM Configuration Files

The following are sample PAM configuration files which control the authentication modules used in the
BSS user security feature. The pam.conf file contains a listing of services. Each service is paired with
a corresponding service module. When a service is requested, its associated module is invoked. There
are different services used by the NIS and LDAP naming services which are reflected in the differences
between the two files. Note that these files are examples only.

pam.conf_nis

#
#ident “@(#)pam.conf 1.28 04/04/21 SMI”
#
# Copyright 2004 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the “other” section.
#
# Modules are defined with relative pathnames, i.e., they are
# relative to /usr/lib/security/$ISA. Absolute path names, as
# present in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth required pam_unix_cred.so.1
rlogin auth required pam_unix_auth.so.1
#
# Kerberized rlogin service
#
krlogin auth required pam_unix_cred.so.1
krlogin auth binding pam_krb5.so.1
krlogin auth required pam_unix_auth.so.1
#

15 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

pam.conf_nis CONT ...

# rsh service (explicit because of pam_rhost_auth,

# and pam_unix_auth for meaningful pam_setcred)
#
rsh auth sufficient pam_rhosts_auth.so.1
rsh auth required pam_unix_cred.so.1
#
# Kerberized rsh service
#
krsh auth required pam_unix_cred.so.1
krsh auth binding pam_krb5.so.1
krsh auth required pam_unix_auth.so.1
#
# Kerberized telnet service
#
ktelnet auth required pam_unix_cred.so.1
ktelnet auth binding pam_krb5.so.1
ktelnet auth required pam_unix_auth.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp auth requisite pam_authtok_get.so.1
ppp auth required pam_dhkeys.so.1
ppp auth required pam_unix_cred.so.1
ppp auth required pam_unix_auth.so.1
ppp auth required pam_dial_auth.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd auth required pam_passwd_auth.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron account required pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
other session required pam_unix_session.so.1
#
# Default definition for Password management

16 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

pam.conf_nis CONT ...

# Used when service name is not explicitly mentioned for password management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
#
# Support for Kerberos V5 authentication and example configurations can
# be found in the pam_krb5(5) man page under the “EXAMPLES” section.
#

pam.conf_ldap

#
#ident “@(#)pam.conf 1.28 04/04/21 SMI”
#
# Copyright 2004 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the “other” section.
#
# Modules are defined with relative pathnames, i.e., they are
# relative to /usr/lib/security/$ISA. Absolute path names, as
# present in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
login auth binding pam_unix_auth.so.1 server_policy
login auth required pam_ldap.so.1

#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth required pam_unix_cred.so.1
rlogin auth required pam_unix_auth.so.1
rlogin auth binding pam_unix_auth.so.1 server_policy
rlogin auth required pam_ldap.so.1
#
# Kerberized rlogin service
#
krlogin auth required pam_unix_cred.so.1

17 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

pam.conf_ldap CONT ...

krlogin auth binding pam_krb5.so.1

krlogin auth required pam_unix_auth.so.1
krlogin auth binding pam_unix_auth.so.1 server_policy
krlogin auth required pam_ldap.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh auth sufficient pam_rhosts_auth.so.1
rsh auth required pam_unix_cred.so.1
rsh auth binding pam_unix_auth.so.1 server_policy
rsh auth required pam_ldap.so.1
#
# Kerberized rsh service
#
krsh auth required pam_unix_cred.so.1
krsh auth binding pam_krb5.so.1
krsh auth required pam_unix_auth.so.1
krsh auth binding pam_unix_auth.so.1 server_policy
krsh auth required pam_ldap.so.1
#
# Kerberized telnet service
#
ktelnet auth required pam_unix_cred.so.1
ktelnet auth binding pam_krb5.so.1
ktelnet auth required pam_unix_auth.so.1
ktelnet auth binding pam_unix_auth.so.1 server_policy
ppp auth required pam_ldap.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd auth binding pam_passwd_auth.so.1 server_policy
passwd auth required pam_ldap.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron account required pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1
other account binding pam_unix_account.so.1 server_policy
other account required pam_ldap.so.1

18 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

pam.conf_ldap CONT ...

#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
other session required pam_unix_session.so.1
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1 server_policy
#
# Support for Kerberos V5 authentication and example configurations can
# be found in the pam_krb5(5) man page under the “EXAMPLES” section.
#

19 SOLUTION BRIEF:GSR9 Secutiry Strategy Overview

Motorola, Inc. http://www.motorola.com/content.jsp?globalObjectId=2046-8216
The information presented herein is to the best of our knowledge true and accurate. No warranty or guarantee expressed or implied is made regarding the capacity,
performance or suitability of any product. MOTOROLA and the Stylized M Logo are registered in the U.S. Patent and Trademark Office. All other product or service
names are the property of their respective owners. © Motorola, Inc. 2007