FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Document Title: Access Control Policy
Document Type: Policy Document
Abstract: This Access Control Policy (ACP) defines the policy
for controlling access to resources in the operational
Pathway system.
lan Bowen Mik Peach
Distribution: Gerry Boyce Barry Procter
Alan D’Alvarez Martin Riddell
John Dicks Glenn Stephens
Peter Dreweatt Chris Sundt
Mark Fisk Chris Wannell
Peter Harrison Frank Womack
Dave Jones Horizon
Graham Lloyd Pathway Management
Tom Parker Pathway library
Document Status: Approved
Document Predecessor: -
Associated Documents: See section 0.2
Author: Belinda Fairthorne
Approval Authority: John Dicks
Comments To: Author, copy to John Dicks
Comments By: -
0.CONTENT
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page I of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
0.1 Document History
Versio Date Reason
n
0.1,0.2 28/10/96 _ Initial drafts for review by security team
0.3 7/11/96 Initial Draft for internal Pathway review
0.5 6/12/96 Response to comments; Addition of new information
including Pathway Corporate Services domain, Network
Management
0.6 4/3/97 Further clarifications in many areas including network,
Sequent access, Post Offices
1.0 16/4/97 Terminology changes.
Major updates to the Post Office section have been made.
Numerous minor changes have been made.
1.1/3 See separate note
2 23/2/98 Draft version of 1.3.
2.1, 2.2 sep/oct See separate note Approval responsibility passed to John
98 Dicks
3.0 18/12/98 Minor updates, see separate note. For approval
0.2 Approval Authorities
Name Position Signature Date
John Dicks Customer
Requirements
Director
0.3 Associated Documents
Ref: Title Identifier Vers Date
SADD Service Architecture Design Document CR/FSP/004 54 23/7/98
TED Technical Environment Description TD/ARC/000 4.2 13/10/98
1
SPOL ICL Pathway Security Policy RS/POL/000 3.3. 23/2/98
2
SFS Security Functional Specification RS/FSP/000 3.2 5/8/98
1
CHDM PAS/CMS Help Desk Call Enquiry Matrix CS/FSP/000 2.5 13/10/97
3
AUDT Audit Trail Functional Specification CR/FSP/006 2.2 8/9/97
BS779 A Code of Practice for Information BS7799 1 15/2/95
9 Security Management
DSPO DSS IT Security Policy (Departmental IT DITSG/ITSS/ 6.2 3/96
L Security Standards) 0001.04
PPOL Post Office Counters Information System SRR
Security Policy Appendix 4-1
Printed: 22/12/98 RESTRICTED-COMMERCIAL.
CAWINNT\Profiles\crosslab\Desktop\RSPOL003.doc Page 2 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
0.3 Abbreviations
ACP Access Control Policy
BA Benefits Agency
BES Benefit Encashment Service
BPS Benefit Payment Service
CAPS Customer Accounting and Payments System
CAW Certification Authority Workstation
CESG Communications-Electronic Security Group
CFM ICL Outsourcing (Client Services Ireland)
CLI Calling Line Identification
CMS Card Management Service
cs Pathway Customer Services
DBA Database Administrator
DSA Digital Signature Algorithm
DSS Department of Social Security
ECCO Electronic Cash Registers at Counters
EPOSS Electronic Point Of Sale Service
ESNS Electronic Stop Notice System
FCMS Fraud Case Management Service
FRM Fraud and Risk Management
FTMS File Transfer Management Service
HAPS Host Automated Payment Service
HFSO Horizon Field Support Officer
ISDN Integrated Services Digital Network
IT Information Technology
KEK Key Encryption Key
KMA Key Management Application
LAN Local Area Network
MIS Management Information Services
NAO National Audit Office
NMS Network Management Station
NSI National Sensitive Indicator
NT New Technology (Microsoft's operating system)
OBCS Order Book Control Service
PAS Payment Authorisation Service
POCL Post Office Counters Ltd
PUN Pick Up Notice
RDMC Reference Data Management Centre
RPC Remote Procedure Call
SMC System Management Centre
SNMP Simple Network Management Protocol
SQL Structured Query Language
SSC System Support Centre
TACACS+ Terminal Access Controller Access Control System +
TIP Transaction Information Processing
TME Tivoli Management Environment
TMS Transaction Management Service
Printed: 22/12/98
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
RESTRICTED-COMMERCIAL
Page 3 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
TPS Transaction Processing Service
VME Virtual Machine Environment
VPN Virtual Private Network
0.4 Changes Forecast
In some areas of Pathway, design for future releases is not yet
finalised or changes or additions to the Pathway solution are being
considered. While this document normally states the policy in these
areas, details are subject to change as indicated in the relevant
section. The main such areas are listed below.
Changes as the results of new services added or extensions to
existing ones
Some aspects of network access controls
Cryptography/key management design for later releases
Some details of support from remote sites
Some aspects of Pathway system auditing; archives and access to
them
Some aspects of future software distribution and auto-configuration
Telephone authentication procedures
Printed: 22/12/98
RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 4 of 117
FU.
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
FUJ00087993
IJ00087993
0.5 Table Of Contents
0. CONTENT.
0.1 Document History.
0.2 Associated Documents.
0.3 Abbreviations...
0.4 Changes Forecas'
0.5 Table Of Contents...
1. INTRODUCTION
1.1 Purpose.
1.2 Context
1.3 Scop
1.4 Access Control Policy Review.
1.5 Document Structure.
2. SECURITY DOMAINS.
2.1 Domain Definition. 13
2.2 Specifying Access Control Policie: 13
2.3 Services involved in Business Operations.. 14
2.3.1 The DSS Service Environment Domain. 14
2.3.2 The POCL and POCL Clients Domain
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 5 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
2.3.3 The Central Services Domain. 15
2.3.4 The Office Platform Service Domain 15
2.3.5 De La Rue Card Services Domain
2.4 Other Domains and Related Services...
2.4.1 Pathway Corporate Services Domaii
2.4.2 System Management Services Domain.
2.4.3 Internal Pathway Services..
2.5 Pathway Sites and Responsibilities...
3. PATHWAY WIDE ACCESS CONTROL POLICY...
3.1 Objectives..
3.2 Pathway Roles.
3.2.1 Operational Function:
3.2.2 Common System Management Function:
3.2.3 Common Security Management Functions..
3.2.4 Common Support Functions...
3.2.5 Pathway Wide Roles.
3.2.6 External Roles....
3.3 Types of Information and its Use.
3.4 Information System Controls...
3.4.1 Implementing Role Based Access Controls.
3.4.2 Access Controls at Pathway Platforms.
3.4.3 Non Human Users...
3.4.4 Engineering Access..
3.4.5 Workstation Related Access ‘Control
3.4.6 Controlling Traffic between Systems.
3.5 Other Access Controls...
3.5.1 Customer Authentication...
3.5.2 Other Telephone Authentication to! Help Desks.
3.5.3 Authentication of Visitors.
3.6 Key Management...
3.7 Effect on other Pathway Standards and Procedures...
4. CENTRAL SERVICES DOMAIN
4.1 Introduction...
4.2 Sequent Systems with Oracle Database:
4.2.1 Roles... :
4.2.2 System “Access Controls for ‘Human Roles.
4.2.3 Dynix and Oracle Access Controls...
4.2.4 Control of Connections to the System..
4.3 Access Controls for Specific Host Applications.
4.3.1 PAS and CMS...
4.3.2 Reference Data Management Centr
4.4 Windows NT System:
4.4.1 Roles.
4.4.2 System Access Controls for Human Roles.
4.4.3 System Set Up.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 6 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
49
50
- 50
52
52
.52
54
54
4.4.4 Control of Connections.
4.5 Specific NT Servers (except security ones:
4.5.1 Roles.
4.5.2 Other Access Control:
4.6 Security Services.
4.6.1 Key Management and Associated Services...
4.6.2 Authentication Service for Authentication using Tokens.
4.6.3 Cryptographic Boxes.
4.7 Solaris Systems. 54
5. OFFICE PLATFORM SERVICE DOMAIN. 55
5.1 Introduction 56
5.2 Roles. 57
5.3 Control of Connections to the Systems. 58
5.4 System Delivery.. 59
5.5 System installation/Reconfiguration.. 60
5.6 Booting the System.. 60
5.7 System Access Controls associated with Human Roles. 61
5.8 Other Access Controls. 63
6. INTERFACE DOMAINS. 64
6.1 DSS Service Environment Domain 64
. 65
66
6.1.1 Roles...
6.1.2 System ‘Access Control oe
6.1.3 Control of Traffic between VME and the Data Centres. 66
6.2 POCL and POCL Clients Domain........... 66
6.2.1 Roles... . 67
6.2.2 Control of Connections to the Pathway Data Centre: 67
6.2.3 Control of Connections to POCL Systems. . 68
6.3 De La Rue Card Services Domain 68
6.3.1 Roles and System Access Controls. .. 68
7. PATHWAY CORPORATE SERVICE DOMAIN 70
7.1 Introduction... 70
7.2 Workstation Controls. 70
7.3 Fraud Risk Management. 72
7.4 Payment Card Helpline. 73
7.4.1 Roles and Associated Control: 73
7.4.2 Other Access Controls...... 74
7.4.3 Authentication of Callers. 74
7.5 Business Suppott..... 75
7.6 Auditing 76
7.6.1 Overview of Audit Information Accessed. . 76
7.6.2 System Access Control: 77
7.7 Security Management.. 78
7.7.1 Cryptographic Key Management. 78
7.7.2 Management of Security Tokens. .79
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 7 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
7.8 Other Management Users..
7.9 The Management Information Systems (us
7.9.1 System Access Controls.
7.9.2 Control of Connections.
8. SYSTEM MANAGEMENT SERVICES DOMAIN
8.1 Introduction...
8.2 Outline of System and Network Management.
8.2.1 System Management Workstation Controls...
8.2.2 Procedures for getting in Support Staff.
8.3 System Management of NT Systems...
8.3.1 SMC and Roles at Tivoli Servers.
8.3.2 System Access Control:
8.3.3 Controls on Connection:
8.4 Sequent and Oracle Management.
8.4.1 Roles and System Access Control:
8.5 Network Managemen’
8.5.1 Introduction.....
8.5.2 Roles at the Open View System..........
8.5.3 Access Controls associated with Human role:
8.5.4 Telnet Access to Routers.
8.5.5 Direct Access to Routers.
8.5.6 Firewall Management.
8.5.7 Access controls configured in Routers and Firewall:
8.6 Software/Configuration Distribution and Implementation.
8.6.1 Post Office Implementation.
8.6.2 Software Updates.
8.7 Application Support.
8.7.1 Introduction...
8.7.2 Roles.
8.7.3 System Access Controls for these Roles.
8.8 Specific Hardware Support...
8.9 Horizon System Help Desks.
8.9.1 Introduction..
8.9.2 System Set-up.
8.9.3 Other Access Controls..
8.10 Network Access Controls.
8.10.1 Introduction...
8.10.2 Protecting Data in Transit.
8.10.3 The Data Centre Network Access Polic
8.10.4 Pathway Project Sites.
8.11 NT Domains...
APPENDIX A: SUMMARY OF ROLES.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 8 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 9 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
INTRODUCTION
1.1 Purpose
This Access Control Policy (ACP) defines the policy for controlling
access to resources in the ICL Pathway IT system.
Effective control depends on having a clear definition of the roles and
responsibilities of all personnel who need some form of access to the
system. This document defines the operational, management and
support roles required in the Pathway system, and the main functions
which people in those roles carry out. It then defines the policies for
controlling the access to the Pathway services - both by these people
and by other system users.
1.2 Context
This document fits into the structure of documents for Pathway security
as illustrated in figure 1-1 below.
Contract
& related >} Pathway Security Policy
documents
: —_—!— —— !
Access Security I Technical \
Control Functional ' Environment I
Policy Specification I Description I
I I f
[ [ I
Physical Security Operational procedures Detailed specifications
Personnel Security for people accessing including
Health and Safety Pathway services detailed configuration
Contingency Planning of components
Figure 1 - 1 Pathway’s Security Documents
The Access Control Policy defines how access is controlled throughout
the Pathway system in compliance with the Pathway Security Policy.
The Security Functional Specification defines the security functionality
that will be incorporated into the ICL Pathway system.
The Technical Environment Description describes the architecture and
technical environment for the Pathway solution, including the security
architecture.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 10 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Other security processes define, for example, the physical security of
information and machines and personnel security including storage of
workstation keys and tokens. Personnel procedures include staff
vetting. There are also plans for business continuity after a major
incident.
There are also procedures for people using Pathway services. For
example, there are procedures associated with entering a site, using
the system, safeguarding of manual records and handling security
incidents. These will be checked for compliance with the Pathway
security policies and specifications by the Pathway Security Manager.
Section 3.8 outlines the implications of the Access Control Policy on
these procedures and identifies the key ones.
There are also specifications defining how the various Pathway
components are configured to meet this policy. These will define, for
example, which functions in which applications are available to people
in particular roles and the database views available to each role.
1.3 Scope
This Access Control Policy defines how access to information system
resources is controlled in the operational Pathway system. It includes:
e General access control policies for Pathway
e The principles of how the access controls should be configured -
which roles should be set up with what responsibilities and what
categories of functions people in those roles should be permitted to
do
e How the security functionality defined in the [SFS] is used to
achieve that. For example, how people in different roles are
authenticated, how access to the permitted functions is achieved.
This covers functions performed in the information system as the
result of direct user action, and those cases where the user of the
system is carrying out a function on behalf of someone else, often
as the result of a telephone call requesting use of the system.
This document is concerned with what can be accessed by whom and
how within the Pathway information systems rather than the detailed
procedures for configuring and running these systems. Separate
Pathway documents as described in 1.2 above define these related
standards and procedures.
This policy covers the Pathway operational and management systems
at the Pathway Data Centres plus closely associated systems.
Separate internal Pathway documents cover system development and
test systems and other activities prior to the handing over of the
software for operational use.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 11 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
1.4 Access Control Policy Review
This document will be formally reviewed at least annually. It will also
be reviewed where relevant after a significant security incident, as part
of a more general security policy review, and updated whenever
necessary.
Responsibilities for approval, review and issue of this document will
conform to the review procedure for Pathway policy and standards
defined in the Pathway Security Policy.
1.5 Document Structure
Section 2 of this document identifies the Security Domains of the
Pathway system and outlines the main functions in each. It also
identifies related internal Pathway systems and other sites which
access the Data Centres.
Section 3 specifies the Pathway wide access control policies. It defines
the generic roles which should be supported at most of the Pathway
systems and the general policies and controls which apply to them all.
Configuration of any Pathway platform should conform to this section
as well as to the more specific controls in the appropriate later section.
Sections 4 to 8 specify the access control policy for each Domain/sub-
domain in turn. For each, it defines the roles with access to services
there. Note that some roles are system wide (particularly system
management and Pathway corporate ones) so are referred to in each
domain where they require access (as the systems there must be
configured to support them) but the full definition of these roles is in
either the System Management or Corporate Services Domain.
In some cases, the same roles and controls apply to a number of
domains. For example, the same Sequent system supports both the
PAS/CMS services and other Pathway application hosts so most of the
management and support roles are in common for these. In these
cases, the roles and access controls are defined once and other
sections refer to this definition, though may also have extra roles
specific to the particular service or domain.
So the access controls for a particular system are:
e The general controls in section 3 (which apply to all systems)
e The generic controls for that type of system, where relevant (e.g.
specific controls associated with Sequent or NT at the Data Centres -
see section 4)
e The controls for the particular service/system
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 12 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Appendix A gives a summary of all the roles with references to the
sections where they are described.
2. SECURITY DOMAINS
The Pathway system can be viewed as a number of “domains” which
together provide the Pathway solution.
2.1 Domain Definition
A “domain” is a distinct part of the system characterised by the IT
services it provides and the components it uses to provide those
services. The services offered by several domains combine to provide
the end-to-end services, such as the Pathway Benefit Payment Service
(BPS).
POCL and POCL Client Domain DSS Service Environment Domain
Pathway services at Pathway services at DSS sites
POCL and POCL Client sites interfacing to CAPS, ESNS
‘\ Pl De La Rue
(Card Services}
Central Services Domain >I Domain
System "I :
Management Operational services Pathway
Services at the Pathway Data Centres Corporate
Domain Services
Technical Domain
Management Pathway
and support Office Platform Service Domain Management
All services at the Post Offices pane’ Susiness
support
Figure 2-1 Pathway Domains
Figure 2-1 illustrates the domains and the primary links between them,
except for links with the Pathway Corporate Services. Note that the
System Management Domain also has links with all other domains.
2.2 Specifying Access Control Policies
For each domain, or set of domains, the Access Control Policy
includes:
e An introduction to the main services provided by the domain - both
automated and human initiated ones.
e An outline of the operational, management and support roles of
people with access to services in this domain. For each role, there
is a description of the main classes of functions performed and the
access controls in the information system.
Printed: 22/12/98 RESTRICTED-COMMERCIAL.
CAWINNT\Profiles\crosslab\Desktop\RSPOL003.doc Page 13 of 117
ICL Pathway
Access Control Policy
FUJ00087993
FUJ00087993
Ref: RS/POL/0003
Version: 3.0
Date: 18/12/98
e The access controls resulting from the way the system is configured,
for example, providing the base level of controls against general
unauthorised access and restricting traffic to that permitted.
2.3
Services involved in Business Operations
The main operational flows of the Benefit Payments Service and other
Post Office operations involve the domains illustrated in figure 2-2.
These domains are described in the following sub-sections.
POCL and POCL Client Domain
Automated
payment
systems
POCL
TIP &
ref data
DSS benefit system
with Pathway Partition
DSS Service Environment Domain
DeLa Rue
Card Services Domain
Central Services Domain
card
production
APS
Hosts
Ref.
TPS Data
oBcs I PASICMS
Distribution
<1— ahents >
Correspondence Servers \
a n
I
Office Platform Service Domain
Post Office .
Counter
>
Counter Infrastructure
‘APS I EPOSS [ o8cs I BES
Vv vo ea
Payment Card Helpline
& Business support
(part of corporate domain)
Transaction
Management
Service
Figure 2 - 2 Domains directly involved in business operations e.g. benefit payments
2.3.1
The DSS Service Environment Domain
The DSS Customer Accounting and Payments System (CAPS) handles
benefit payment authorisations. The DSS Electronic Stop Notice
System (ESNS) handles Order books for benefits.
Pathway’s responsibility in this domain is to accept Benefit related data
generated by CAPS (or ESNS) and return data to CAPS (or ESNS) via
Pathway software in a partition of the VME system and routers.
2.3.2
The POCL and POCL Clients Domain
The POCL TIP system receives records of transactions at Post Offices.
Another POCL system provides reference data for applications such as
EPOSS.
Printed: 22/12/98
RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 14 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
2.3.3
2.3.4
The POCL Automated Payments system (or later, POCL Client
Systems) process Automated Payments on behalf of POCL Clients.
The Pathway Access Control Policy is concerned only with that part of
the interface to these systems which is the responsibility of Pathway.
The Central Services Domain
The Central Services Domain provides the Pathway application hosts
at the central Pathway sites to support all the Post Office applications
(APS, EPOSS, OBCS). All these run on Sequent machines and use
Oracle.
For benefit payments, information is transferred to/from the DSS
Services to the Pathway Payment Authorisation Service(PAS) and
Card Management Service (CMS). PAS/CMS process the payment
authorisations and customer information for forward transmission to
the Post Office or Card or Temporary Token Producer as required, and
return information on transactions to CAPS.
TMS Agents assemble information from these hosts for distribution to
the Post Offices. The Correspondence Servers are the central part of
the Riposte Transaction Management Service and distribute
information to/from the Riposte journals at the Post Offices. The
Correspondence Servers and their associated agents, run on Windows
NT platforms.
This domain also includes related services such as the Key
Management Service used to generate and distribute keys within the
Central Services Domain and to Post Offices.
The Central Service Domain spans two sites (Bootle and Wigan) which
are often referred to as the Pathway Data Centres.
The Office Platform Service Domain
The Office Platform Service Domain encompasses all Post Office sites
as illustrated in the fourth box in figure 2-2. All services run on
Windows NT workstations. The main services supported are:
e The Electronic Point of Sale Service (EPOSS),
e The Benefit Encashment Service (BES),
e The Automated Payment Service (APS), and
e The Order Book Control Service (OBCS).
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 15 of 117
ICL Pathway Ref: RS/POL/0003
FUJ00087993
FUJ00087993
Access Control Policy Version: 3.0
Date: 18/12/98
2.3.5
2.4
2.4.1
2.4.2
De La Rue Card Services Domain
The De La Rue Card Services Domain encompasses the facilities used
for the production of cards, Pick UP Notices (PUNs) and temporary
tokens.
Other Domains and Related Services
There are two other domains which are concerned with the
management of Pathway. Both interact with the services in the
operational domains.
e The Pathway Corporate Services domain includes Pathway’s own
management and business support processes including security
ones.
e The System Management and Support Services domain manages
the hardware and software systems which make up Pathway.
Some internal ICL systems are also used in support of Pathway
operations.
Pathway Corporate Services Domain
The Pathway Corporate Services domain supports Pathway’s own
management processes such as reporting, accounting, monitoring
service levels and Pathway’s fraud risk management and auditing
processes. It also contains business support processes:
¢ The Payment Card Helpline, which responds to DSS, POCL and
general public queries about benefit cards and payments.
e Pathway Business Support which handles financial reconciliations,
for example, of benefit payments after a Post Office problem
This domain includes a Data Warehouse which gathers information
from the operational system and a Financials System.
System Management Services Domain
The System Management Services Domain contains the services
required to manage and support the Pathway services in the other
domains - both during operational running and roll-out of new Post
Offices.
System Management facilities include Software Distribution, Event
Management, Resource management, Inventory Management and
Network Management.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 16 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
The Tivoli Management Environment (TME) provides the Central
System Management co-ordinating input from other management
software such as Patrol, which is used to provide event and resource
management of the Pathway Sequent systems, and HP Open View
(with Cisco Works) which is used for management of the routers.
Roll-out of new Post Offices is controlled by a Roll-out database and
associated facilities for auto-configuration of the Post Offices.
Support facilities include technical support of applications and
hardware.
The Horizon System Help Desk provides technical assistance on
hardware, software and network problems, calling on others when
needed. The Roll-out Support Desk supports the roll-out process.
2.4.3 Internal Pathway Services
A number of internal Pathway services interact with Pathway
operational and management services at the Pathway Data Centres.
These include:
e The Powerhelp and PinICL systems which record and maintain
information about calls to the technical Help Desks and their
progress. Associated systems are used in support of lost keys and
passwords at Post Offices
e The Dispatch-1 system which holds hardware inventory information
2.5 Pathway Sites and Responsibilities
The main Pathway services run at the secure Pathway Data Centres at
Wigan and Bootle. This includes:
e The operational systems of the Central Services Domain including
application hosts, agents and Correspondence servers
e The Management Information Services of the Pathway Corporate
Services Domain
¢ The System and Network Management services and services
supporting the implementation of the Post Offices.
The main operational and management services can be run at either
site, if needed, though there is a prime site for each. Figure 2-3 shows
the sites with electronic links to the Pathway Data Centres.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 17 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
CAPS, ESNS, TIP ete
at DSS, POCL and POCL Client sites
ears eaemasreN =i
De La Rue sites \ I / Girobank sites
Card &token (7 Payment Card Helpline!
production (Pathway Data ~—»I E P
SEE Centres a
CEMIND sits —— Pathway Management
: Operational and Support Sites
Operational applications
Management Pathway Management
Ee Management
as Information Application support
ot Systems =
System) Implementation
Management Implementation
Torizon System services > [Implementation supplier
Help Desk and other support sites
Post Offices
Figure 2-3 Sites with links to the Pathway Data Centres
ICL Pathway has overall responsibility for the design, development,
test, implementation and operation of the Pathway services. Specific
activities are subcontracted to appropriate organisations as identified
below.
e De La Rue/Thomas De La Rue manufacture cards, Pick up Notices
(PUNs) and temporary tokens, which are subsequently distributed
by Royal Mail. De La Rue are located on De La Rue sites (e.g.
Tewkesbury).
e ICL Outsourcing (Client Services Ireland) is responsible for the
operational management of the Sequent and other systems at the
Pathway Data Centres. They are also responsible for application
support of some applications on Sequent and VME. They are
located mainly at Belfast.
They are also responsible for Network Management, which is done
at the Data Centres, though it manages routers on other sites also.
e ICL Outsourcing (Distributed Services Division) is responsible
for the overall System Management of the Pathway information
systems, including software distribution, event and resource
monitoring. They are located at Stevenage, Lytham St Annes and
one other site.
The Horizon System Help Desks and associated call handling
system and hardware inventory systems are also at ICL Outsourcing
sites.
e Girobank run the Payment Card Helpline. These are at the Wigan
and Bootle sites, but in separate areas from the Pathway Data
Centres. Help Desk advisors have interactive access to the
PAS/CMS database.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 18 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e The ICL Pathway project runs Corporate Services including
Management, Auditing and Fraud and Risk Management. It also
manages implementation of the Horizon system at the Post Offices
supported by Implementation suppliers from other organisations
such as Peritas for training, Workplace Technologies for site
preparation and Exel for shipping and installation.
Pathway project users are mainly at Feltham, though there are also
secure sites at Bracknell and Kidsgrove. The Pathway
Implementation unit also has Regional offices. Implementation
suppliers access authorised implementation systems from their own
sites.
¢ The Pathway System Support Centre - SSC, provides 3rd line
support for most applications and packages including Riposte. They
are located at a secure Pathway site (Bracknell).
¢ On site hardware support at the Data Centre is provided the
appropriate organisations. For example, Sorbus support the NT
systems and Sun the Solaris systems. These roles generally do not
require on-line access.
e Under exceptional circumstances, ICL Outsourcing or SSC need 3
or 4" line support from other organisations for software in the
Pathway system. For the following support organisations, controlled
on-line access from their own sites is being considered:
e Sequent supports the Dynix operating system.
¢ Oracle provides 3rd line support for Oracle databases and
applications.
e Cisco supports the routers.
e EMC supports the Symmetrix discs.
¢ General Signals provides support for the Symmetrix/Energis
link.
No other organisations will have on-line access to the system. For
example, there is no on-line access by Microsoft for NT support or
by Escher for Riposte support.
¢ Sorbus/Exel will provide Engineers for Post Office roll-out.
e EDS runs the DSS CAPS system and the firewall between it and the
Pathway systems
e Girobank also perform Fraud Risk management functions.
This is at Bootle, but in a separate area from the Pathway Data
Centre.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 19 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
The Pathway Access Control Policy covers control of access to
resources in the Pathway operational systems by all these
organisations. It also covers access to Pathway services by other
organisations - particularly Post Office staff accessing the Post Office
systems. Other external access includes, for example, by POCL
auditors and the DSS Fraud Investigation Team.
Later sections define the permitted accesses between these sites.
3. PATHWAY WIDE ACCESS CONTROL
POLICY
This identifies the overall policy and associated procedures and
controls which apply across the whole of the operational Pathway
system.
Sections 4 to 8 deal with the procedures and controls in different
Pathway domains.
3.1 Objectives
The Pathway Security Policy specifies the following IT security
objectives for Pathway. This Access Control Policy defines how
controls of access to resources are used in achieving the following
objectives.
1. Security measures in Pathway’s IT systems will ensure appropriate
confidentiality, integrity and availability of data, whether in storage
or in transit. Maintaining the integrity of the services and software
components is also essential.
1. Physical and logical access to the system will be controlled, with
access granted selectively and permitted only where there is a
specific need. Access will be limited to persons with appropriate
authorisation and a “need to know” requirement.
1. Authentication, whereby a user’s claimed identity is verified, is
essential before any access is granted to the system. Authentication
mechanisms are also required to ensure that trust relationships can
be established between communicating components within, and
external to, the system.
1. All users of Pathway’s services will be individually accountable for
their actions. Accountability for information assets will be
maintained by assigning owners, who will be responsible for
defining who is authorised to access the information. If
responsibilities are delegated then accountability will remain with
the nominated owner of the asset.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 20 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
The Pathway Security Policy also specifies objectives for auditing,
alarms and monitoring of the system. These are only of concern to this
Access Control Policy in as much as they are part of the functionality
of the system for which access must be controlled.
3.2 Pathway Roles
Responsibility for performing functions within the Pathway system is
allocated on the basis of roles. This document identifies the following
types of human roles
e Operational roles of the users of the system during normal running.
These include, for example, the Payment Card Helpline Advisors
and the Post Office Counter Clerks.
e System and Security Management roles. These are the people
who are responsible for maintaining and monitoring the system,
including adding new software and users.
e Support roles such as engineers and application support
People in specified roles are permitted to carry out defined functions,
normally by controls within the Pathway information systems. In a few
cases, manual procedures are used to supplement these.
Pathway controls which people can carry out which roles, and
therefore perform which functions. However, users are individually
identified so that they can be made accountable for their actions.
Roles are defined to support the functions in each of the Pathway
domains defined above. Where practical, the same or similar roles are
defined for several domains to reduce complexity and make it easier to
check compliance with the overall security policy. The following
subsections identify roles and major functions used in most Pathway
domains. In some domains, several of these functions are available in
one role to simplify administration where separation of these duties is
not required. This is defined in the more detailed sections of this
document about the individual domains. Several domains have specific
requirements which require use of particular roles.
A limited number of roles are “pathway wide” and so recognised in
most Pathway domains. These are the Pathway management roles
which allow auditing and investigation of all Pathway systems.
The Access Control Policy includes all roles for users who have direct
access to the Pathway operational systems and the related systems at
the Data Centres. In addition, this document includes a limited number
of roles of users who cause others to use the system on their behalf,
for example in response to a phone call.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 21 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.2.1
3.2.2
Note that as many of Pathway’s operations are automated, access by
systems entities, for example, particular applications, must be
controlled as for human access to the system. This Access Control
Policy covers access by such system entities, but does not define roles
for them.
Operational Functions
It is Pathway policy to automate the operation of Pathway applications
where practical, thus reducing the need for human intervention and
associated access controls. Operational applications are automated at
the DSS/BA, POCL and Pathway Data Centres, as are transfers of
data to/from them and the Post Offices. Processes are initiated as the
result of some event such as the receipt of data. In these central
domains, no human intervention is required unless some exception
condition occurs or a query is received at the Help Desk. Control of
access to resources for automated processes results from the way the
system is installed and configured.
The operational roles are different in each domain. For example, there
are Pathway management functions at the Corporate services domain.
At the Post Office, operational roles are the Post Office Manager,
Supervisor and Counter Clerk. These should be taken as also referring
to the equivalent staff in franchises and Sub Post Offices including Sub
Postmasters and their staff.
Common System Management Functions
Functions to manage and administer systems are required in all
domains. Note that many such system management functions are done
remotely from the systems being managed.
The main management functions for a system in any of the domains
(for example, a Sequent machine supporting the PAS/CMS Services or
a Post Office set of counters and LAN etc) are as follows:
e System set-up and installation: setting up the base and
application software on the system and configuring it for live
running. On installation of some systems, cryptographic keys will
also need to be installed- see security management roles.
e Software Update: updating the software and reconfiguring it. Most
updates to software are done automatically by system management.
However, some base software updates need to be done manually
on site.
e System Management: monitoring events and resources in the
operational system and taking appropriate action to rectify
problems. Also, distributing software (complete new packages or
patches).
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 22 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.2.3
e Operational Management (sometimes called System
Administration): keeping the system running - responding to
incidents, keeping it correctly configured (where this is not done by
system management). This is mainly concerned with operating
system management, but may also involve some database
administration.
e¢ Computer operator: in most domains, this is a minimal role
involving switching on the machine, loading media and similar
operations. (Most management of the system is done as part of
other management roles.)
e Package Administration: Pathway uses a number of packages to
handle resources. The key packages and functions associated with
them are:
« Oracle Database Administration. This includes
administering the database structure set up and
maintenance.
Access to databases is often controlled by packages such as
Discoverer and Business Objects which also require
administration.
e Riposte Administration. Management of Riposte message
stores and groups is largely done automatically.
e Tivoli Administration. This is used to configure what Tivoli
manages and set thresholds etc. (Specifying the Tivoli roles
and regions etc is also a security management function). See
section 8 for more about Tivoli.
e Application Management: Managing the running of the
applications themselves where human intervention is needed.
Note that some of these functions are carried out in the System
Management Domain. Further management functions there are:
e Network Management: managing the network, including routers
and firewalls, which connects machines and domains together.
e Implementation management: managing the roll out of the
Pathway solution to Post Offices.
Common Security Management Functions
There are a number of management functions particularly concerned
with security. In practice, these will often be performed by people in
other management roles, but in that case, are defined as part of the
responsibilities for that role. Security management functions are:
e User administration: administering user security information such
as their authentication information, the roles they can perform and
the groups they belong to. It may involve operating systems (e.g.
Dynix, NT) and packages (Oracle, Riposte, Tivoli) etc. It may be
split into:
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 23 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e initial set up of roles/groups and key users
e individual user management, including removing the rights of
users who have changed jobs or left the organisation
« periodic checks for, and removal of, redundant users
e Resource access control: administering who can access which
resources in the operating system, database or applications. Unless
otherwise stated, human user access to resources is based on role
rather than individual user identity. This is generally done as part of
the management or administration of the particular system, package
or application.
In addition, there are Pathway wide roles for Security Event Auditing
and Cryptographic Key Management (see 3.2.5). There may be local
auditing functions in some areas as well as the Pathway wide function.
3.2.4 Common Support Functions
Support functions are primarily concerned with:
e Keeping applications operational
Application support, including diagnosing application problems at
the Post office, is mainly done remotely.
e Training staff to carry out their defined roles.
On-line training is provided at Post Offices and Payment Card
Helpline.
e Keeping all equipment operational. This includes:
e Running diagnostic applications to check for equipment faults (at
the Post Office, done by the Post Office Manager, as well as
engineers, )
e Installing new Post Offices; done by Installation Engineers
e Replacing and reconfiguring hardware; done by Support
Engineers. This includes network boxes as well as NT and
UNIX systems.
e Technical Help Desks for reporting, and getting advice on,
problems
3.2.5 Pathway Wide Roles
People in the following roles have access to several of the domains:
e Pathway Business Support. This role supports the business
operations. For example, it handles financial reconciliation of
payments.
e Pathway Fraud and Risk Manager (FRM). Concerned with
identifying, monitoring and managing fraud, particularly in benefit
payments.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 24 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
While much of this is done using MIS systems, FRM staff also
access operational Pathway systems such as the TMS journals and
PAS/CMS data.
e Pathway Security Manager: Responsible for managing security
tokens for all Pathway users authenticating using tokens, and also
other functions.
e Pathway Cryptographic Key Manager: Responsible for generating
and distributing keys all cryptographic keys used in Pathway to
protect communications links, digitally sign information and encrypt
filestore.
The Key Manager will delegate some responsibility for installing
and updating keys to Pathway Cryptographic Key Custodians and
Cryptographic Key Handlers.
e Pathway Security Event Auditor: Responsible for auditing all use
of the Pathway systems, so requiring access to most of the Pathway
systems. (Access to the Post Offices is not required, as TMS
provides sufficient records of Post Office activity at the Pathway
central site.)
e Pathway Business Function Auditor: Responsible for general
auditing of the Pathway system focusing on business, rather than
security, auditing. Note that the Pathway Security Event Auditor and
the Pathway Business Function Auditor access much of the same
information (though look at it differently). Therefore the term
Auditor (meaning both these auditors) is used where both have the
same access to systems.
These Pathway Management roles are described further in section 7
on the Pathway Corporate Services Domain.
3.2.6 External Roles
In addition to the Pathway roles defined above, POCL customers use
the system indirectly at the Post Office (see section 5).
Some people in POCL, DSS/BA and others also access the system.
These are:
e POCL Auditors, Investigators and Emergency Managers who can
access services at Post Offices as described in chapter 5. They also
have access to audit information at the Data Centres via Pathway
Auditors - see 7.6.
¢ DSS and NAO Auditors have similar access to central audit
information.
e Benefit Agency staff use the on-line CAPS interface, for example,
to make emergency payments or stop cards or payments.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 25 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e DSS Help Desk staff are expected to use the on-line CAPS
interface for queries e.g. on authorised payments.
e DSS Fraud Investigation Team access the FRM database and a
limited amount of information in the Data Warehouse - see chapter
7.
POCL, DSS and NAO Auditors also have access to audit information
at the Data Centres. Initially this will be provided via Pathway Auditors,
rather than by these auditors having direct access to the Pathway
systems. Note that in this document, POCL, DSS and NAO Auditors
are often referred to collectively as External Auditors and are shown as
being subject to the same access controls. However, there are some
differences in data available to different External Auditors in line with
[AUDT]. For example, DSS staff cannot access POCL specific data.
3.3 Types of Information and its Use
The Pathway Access Control policy protects information in all Pathway
systems. For example, benefits information is protected from its receipt
from DSS/BA through its processing in Pathway and at the Post offices
to the return of transaction information to BA/POCL. This includes
protection of information during fault investigations and correction and
information retained for auditing and fraud investigation.
Information in the Pathway system includes:
e The business data such as the payment authorisation data to
support the PAS system, the reference data to support EPOSS and
the transaction data resulting from Post Office counter activities.
This is stored at the main operation systems and also in archives.
Some data is also available for management services at the Data
Warehouse.
e Training information - special business style data used in training
sessions
e On-line documentation e.g. Payment Card Helpline procedures,
Post Office procedures
e Operational systems data such as the software, configuration
information, Tivoli scripts, system management event logs etc.
¢ Security information about users, keys, security audit logs etc
Most processing of the business information, except at the Post Office,
is automated and therefore not subject to human access. Most
processing of system data is also automated.
All information is protected in conformance to the Security Functional
Specification and Pathway Security Policy.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 26 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.3.1.1
3.3.1.2
3.3.1.3
3.3.1.4
3.3.1.5
3.3.1.6
3.3.1.7
3.3.1.8
3.3.1.9
3.3.1.10
DSS and related business data is classified as RESTRICTED
according to the UK government classifications and must be protected
accordingly. Access to data with a National Sensitivity Indicator is
further limited to authorised staff.
Where human access to this information is needed, for example by
Help Desks and for system management, the information should only
be accessible to those with a need to see it according to their role.
Information in transit between systems should be encrypted for
confidentiality and/or integrity according to the needs of the particular
link as defined in the Security Functional Specification [SFS].
Digital signatures should be used for integrity of business information
between the Post Offices and other services where required. For
example, payment authorisations sent from Pathway are signed;
Automated Payments are signed at the Post Office prior to
transmission via Pathway to POCL or POCL Clients.
System data should also be integrity protected when required. Digital
signatures are used for integrity protection of software and scripts
distributed to the Post Offices and elsewhere. Appropriate key
distribution protocols as defined in [SFS] are used to protect all
cryptographic keys.
Business information in filestore at the Post Office PCs should be
encrypted.
Information in relational databases should be accessible only via
authorised client “applications” (such as Oracle Forms, Discoverer,
Business Objects, Tivoli database interfaces) except where there is a
proven need for lower level access. Lower level access will only be
granted for agreed operational management and support functions.
System Management actions by Tivoli should be activated using pre-
defined Tivoli tasks, authorised for use by SMC and the Pathway
configuration management and software distribution process. This
includes collection of diagnostic information from the Post Office for
application support.
RESTRICTED data on discs and other media (including printed output)
should not be accessible for unauthorised use. For example, archives
should be stored securely; information on faulty discs removed from
service should be inaccessible.
Information should be appropriately separated in filestore, database
tables etc. Each data set should be accessible only to those with a
need for that access.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 27 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.4 Information System Controls
3.4.1 Implementing Role Based Access Controls
Human user access to the functions of the system is controlled
according to the user's role. Authentication procedures prove the
user's identity. Authorisation procedures check the user’s right to carry
out the role. Access controls functions associated with resources will
check that the user with this role is permitted to access the resource.
The way roles and the associated access controls are implemented in
the information systems depends on the products used. For example,
Oracle and Tivoli support roles, so can use roles directly in access
control lists (rather than identity). Other products such as Riposte,
UNIX and Windows NT support groups which can be used to represent
roles.
Implementing role based access control involves:
e Administering information about users including role/group (as well
as identity), authentication information (such as passwords) and
other security relevant information associated with users in this role
such as operating system privileges, database views.
e Authenticating users via the appropriate method for someone in that
role at that location. At some locations, such as the Post offices,
permitted roles/groups are automatically associated with a user
when the user logs on. At other locations, the users are given
limited privileges on log-on and have to ask for others, though will
still be restricted to authorised privileges. (This particularly applies
to some management functions. For example, no user is allowed to
log onto UNIX with root access, though may be permitted a
controlled change to root access later - see 3.4.2.15.)
e Administering access control information associated with resources
e.g. which users in which roles with which privileges can access
which resources (files, data and other objects) in which ways.
Roles will normally be associated with major functions. Defining
separate roles allows different functions to be allocated to different
individuals. However, the actual allocation of roles to individuals is
done by administrative action. Some users can be permitted to carry
out more than one major function, so are permitted to take more than
one “role”, but this will not be done where it might undermine security.
The way individuals are allocated to roles depends on the products
used in the different Pathway domains and is defined further in the
later sections of this document. Some general principles apply:
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 28 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.4.1.1 The principle of “least privilege” should apply to restrict the access
rights of users.
3.4.1.2 Duties of different users should be separated to minimise the damage
that any one user can do to the system or the information in it.
3.4.1.3 If a role at a particular location is allocated to a single person, there
should generally be at least one other person who can deputise for
that person. (At small Post Offices where no deputy is available, if the
Post Office Manager is unavailable, the Post Office will not open until
emergency procedures have been invoked.)
3.4.2 Access Controls at Pathway Platforms
Much of the operational Pathway system is automated and does not
require human intervention except at the Post Office. The main human
users of the central systems are the system management and support
users. The Pathway systems are configured to reduce the risks of
human users interfering with the automated applications and of these
applications interfering with each other.
This section gives the policy for how access controls at all Pathway
platforms are configured. It gives the standard policy which applies to
all domains and identifies where variants are permitted. In these
cases, the variant is defined for the domain in which it is allowed in
sections 4 to 8 below. No other variants are permitted.
3.4.2.1 Workstations from which operational systems can be updated should
have floppy drives disabled. Servers should have floppy drives
disabled at boot time. Booting from CDROM should also be disabled
once a system has been configured. In all cases, exceptions to this
rule must be agreed with Pathway Security Management and Horizon
and be documented.
3.4.2.2 Workstations at the Post Office display sensitive business data (e.g.
about payments) as part of normal operation. All other workstations
which can display sensitive information should be in physically secure
areas.
3.4.2.3 All systems should have the required roles, groups and other
privileges set up on installation. It should rarely be necessary to
update these. “Guest” users must not be enabled in the installed
systems, and where possible, should not be included. Other generic
users should not be accessible for user logon except in exceptional
circumstances explicitly defined in the appropriate section below.
3.4.2.4 After a workstation is booted up, a log-in screen should be displayed
which cannot be by-passed.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 29 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.4.2.5 People accessing Pathway systems are required to identify themselves
using hand held tokens if:
¢ They are at sites remote from the Data Centre and can update
operational or MIS systems (for example, to perform systems
management actions)
e They can access BA and/or POCL business data (except at Post
Offices).
e They are authorised to update system data which can affect the
running of the Pathway systems. This includes people who have
UNIX root privilege, NT users belonging to the administrators group
and database administrators.
3.4.2.6 Where such tokens are used for authentication, the associated PIN
must be at least 6 characters long.
3.4.2.7 If a user who authenticates with a token to one system/domain needs
to perform an additional authentication to another system, the second
authentication should also be a token based one, using the same
token. Agreed exceptions to this must be documented.
3.4.2.8 Each user will have an individually allocated token except in
emergencies, for example, when a token is lost. In such cases, specific
authentication will be agreed.
3.4.2.9 Where passwords are used for authentication, the user is forced to
change the initial password before any other access to the system is
permitted.
3.4.2.10 Passwords will expire in 30 days unless otherwise stated (in the
section on the appropriate domain).
3.4.2.11 Re-use of the same password is not permitted for either a specified
time or until at least 3 other passwords have been used.
3.4.2.12 The minimum password length is 6 characters.
3.4.2.13 After 3 consecutive unsuccessful attempts to log-on, the user is locked
out unless otherwise stated.
3.4.2.14 People are identified to the Pathway system as individuals. Users with
direct access to the system are registered as follows.
e If accessing the system via a package such as Oracle or Tivoli, they
are registered with that package.
e Users who require direct access to the operating system are
registered with that operating system
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 30 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e Users requiring token authentication are also registered with the
appropriate authentication service.
(The only exceptions allowed to this are the specific cases identified
in later sections of this document. In these limited exceptional cases,
the user, for example, an engineer, is identified as an individual using
manual means prior to using the system in a way specially set up for
this, and where the use of the system is suitably monitored.)
3.4.2.15 Users are authenticated with their individual usernames on first
accessing the system. A change to use another username, will only be
permitted to certain authorised management roles in exceptional
circumstances as specified in the appropriate later section (for
example, for Sequent systems in 4.2.2). Any change to use another
username is controlled (as specified in that section) and audited in a
way which will always be recorded.
3.4.2.16 The filestore is structured to prevent interference between users and
between applications.
3.4.2.17 Access to shared resources such as filestore is controlled by:
e Access to that filestore being restricted to a specific product which is
available only to authorised users. (Most access is controlled this
way as most use of the system is automated), or
e Access to those resources being restricted to users in specified
roles. (Group ids may be used to represent roles. Access control
lists using these will ensure that only authorised people can access
the resource).
3.4.2.18 Access to Tivoli and Oracle resources will use role based access
controls.
3.4.2.19 Security audit logs are protected from everyone except those permitted
to take specified Security Event Auditor roles. Unless otherwise
specified for a particular domain (such as the Post offices) , the
security auditing role is separate from other roles at that domain.
3.4.2.20 Passwords are stored in encrypted form separately from application
data and executable code, except for the specific cases listed in
3.4.3.1.
3.4.2.21 Interference between applications is prevented. For example, at any
system, different applications run in their own user names or that of the
user calling them (or at the Post Office, in the Riposte username
impersonating the user).
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 31 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.4.2.22
3.4.2.23
3.4.2.24
3.4.3
3.4.3.1
3.4.3.2
3.4.4
Packages (such as Oracle and Tivoli) and applications above the
operating system must also conform to the Access Control Policy. For
example, Oracle should restrict Payment Card Helpline users to the
authorised tables and views.
Audit records are generated at the server for client-server applications
(such as Oracle Forms applications using PAS/CMS) so audit logs do
not rely on input from workstations.
Where a product is delivered with pre-defined usernames for human
users, these should be deleted (or if this is not possible, disabled)
once the initial individual usernames for administering the system have
been set-up. Usernames should be disabled by changing to a
password which is extremely difficult to guess, then storing this
password in a safe.
Non Human Users
As much of the operational Pathway system is automated, some users
are system, not human users, so there are usernames and passwords
for both types of users. In general, system users should be subject to
the controls specified above (e.g. for password protection), as such
usernames generally cannot be confined to human users only, so
human users can potentially access usernames intended for system
users. However, some differences are permitted.
The username and password used to automate the log-in may be held
in clear if it is only accessible to authorised operational management
staff for that system and the potential damage from mis-use of that
username is minimised.
The password may expire less frequently than the 30 days for human
users where suitably obscure passwords are used, and the risk of
external access to such accounts is very low.
Engineering Access
Where possible, engineering access to the machines, for example, for
hardware diagnosis and repair, is subject to the controls specified
above. However, in some limited circumstances, for example, when the
operating system cannot be booted, special access is needed, by-
passing the normal controls. In such cases, any visiting engineer must
be subject to the “authentication of visitors” procedures (see 3.5.3) and
two people must be present during such access.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 32 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.4.5 Workstation Related Access Controls
The Access Control Policy covers the security of the workstations used
by humans to access the Pathway services where this affects the
security of the system. The security required depends on the type of
access the user has to the system and the security of the route to the
system accessed. The following policies are in addition to those in
3.4.2 above.
3.4.5.1 Users with interactive access to Pathway systems should use
controlled, NT workstations where the workstation set-up, including
services available at that workstation, is controlled by Pathway.
3.4.5.2 Use of other workstations are only permitted when access is
constrained to a single system (via network controls), this system does
not store sensitive BA or POCL business data and access is limited to
agreed types. All such exceptions to the “controlled NT” workstation
policy must be authorised and documented in the ACP.
3.4.5.3 Workstations which have access to sensitive data should be on
separate networks linked only into the Pathway secure network. Any
exceptions to this must be documented in this Access Control Policy.
Documentation on exceptions must explain how the sensitive data is
protected from other networks accessible from the workstation,
including use of routers and firewalls and how these are configured to
prevent undesirable traffic.
3.4.5.4 Where workstations and servers require access to both the Pathway
Data Centres and other systems, an authorised combination of routers
and firewalls should be configured to restrict the traffic to that
permitted. All such cases must be documented in this Access Control
Policy and are confined to the Pathway Corporate Services sites.
3.4.6 Controlling Traffic between Systems
Pathway controls should restrict who can access what services so
there is no unnecessary access to services. This covers all traffic in
and out of, as well as within, the Pathway campus. Controls are
enforced using a combination of access lists at routers, platform
controls on use of ports and other application gateway/firewall controls
where needed.
General policies in addition to the workstation related ones in 3.4.5 are
given below. More specific policies are in 8.10.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 33 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.4.6.1
3.4.6.2
3.4.6.3
3.4.6.4
3.4.6.5
3.4.6.6
3.5
3.5.1
3.5.2
All accesses in and out of the Pathway Data Centres should be
restricted to the required traffic from/to authorised sources using
routers and firewalls. Such traffic should be routed only to the ports at
systems which require that traffic.
Traffic originating within the Pathway Data Centres is generally
initiated by controlled applications. These applications (and the way
they are configured in the system) should restrict traffic between
systems to that needed.
Where there are specific systems subject to higher risks or
vulnerabilities in the Data Centre network, additional network controls
should be used. All such special cases should be documented in the
ACP.
Accesses to/from the Pathway Data Centres such as CAPS, TIP and
SMC will have well defined, controlled links with cryptographic
protection where needed as specified in the [SFS].
External support users of Pathway systems should be permitted
access to the Pathway Data Centres only from approved remote sites,
only when authorised to carry out a specific support activity and only
via controlled routes as specified in this Access Control Policy.
No other accesses in and out of Pathway should be permitted.
Other Access Controls
In some cases, the information system cannot provide all the access
controls required. For example, telephone contacts cannot use normal
IT authentication procedures. In these cases, some other form of
authentication is required.
Customer Authentication
Customers authenticate themselves at Post offices using PUN, card
and responses to questions - see [SADD] and section 5.
Customers may also need to provide some proof of identity to the
Payment Card Helpline, depending on the type of call - see 5.3.5.
Other Telephone Authentication to Help Desks
Apart from customers, Help Desks may receive calls from at least Post
Offices, POCL offices, DSS offices and Pathway sites. Many of these
calls come from offices and sites known to the Help Desks. In many
cases, the request will not be actioned unless the source of the call
has been authenticated.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 34 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.5.3
3.6
Both the Payment Card Helpline and the Horizon System Help Desk
will maintain information on the Post Office and other relevant sites
and offices. The caller is asked for information to authenticate the
location, and if required, the individual which the Help Desk can verify.
The information known about such offices and sites includes the office
code, possibly the telephone number, the address and for some sites,
the name of the contact.
For certain cases, different (normally extended) authentication is
required supported by further information. The methods used for
authentication in these cases are included in the definition of the
appropriate domain.
Authentication of Visitors
Some visitors to both Pathway and Post Office sites need access to
the IT system. Such visitors will have a company identity card which
includes their photograph, signature and pass number. Unless
otherwise stated, for all such visits, the pass number of the visitor must
be notified in advance to the relevant manager; access will not be
permitted if this has not been done. However, Auditors will visit Post
Offices and other sites without prior notice to the Post Office Manager.
Pathway visitors to Post Offices are subject to Pathway vetting
procedures and approval by Horizon. Visitors to Pathway sites are
subject to Pathway vetting procedures.
At the Post Office, visitors such as engineers and auditors are not
known individually to the system. However, they are known to the
Horizon System Help Desk, and authentication includes use of a one-
time password which requires calling the Help Desk. In these cases,
the telephone authentication procedure described in 3.6.2 is used to
identify the site, and is supplemented by verification of the particular
visitor, generally including their pass number.
Key Management
Cryptography is used widely in Pathway as described in the Security
Functional Specification [SFS]. For example, it is used for:
e Protecting information on links for confidentiality, integrity and origin
authentication in line with the requirements for that link.
e Digitally signing information such as benefit authorisations,
automated payments and software in transit across systems.
e Filestore encryption at the Post Office.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 35 of 117
ICL Pathway Ref: RS/POL/0003
FUJ00087993
FUJ00087993
Access Control Policy Version: 3.0
Date: 18/12/98
3.6.1.1
3.6.1.2
3.6.1.3
3.6.1.4
3.6.1.5
3.6.1.6
3.6.1.7
3.6.1.8
3.6.1.9
3.6.1.10
3.6.1.11
3.6.1.12
This Access Control Policy defines how the required cryptographic
keys are protected when in the information systems. As different keys
are protected in different ways, general policies are given here, with
specific controls defined with the other controls at the appropriate
system where needed.
CESG approved keys must be protected in line with CESG
requirements.
Key material (symmetric keys, DSA private keys and DSA entropy)
should be held in clear only when in physically secure environments.
Public keys (except for the CA’s public key) should be held in
certificates signed by the Certification Authority.
Symmetric keys should only be stored where necessary, and be held
securely.
Keys (or part keys) held in filestore must be in separate filestore
accessible only to authorised key custodians via authorised
applications.
Keys used for protecting data should not be resident in filestore in
clear.
Keys should be changed periodically according to CESG policy.
Different periods may apply to Symmetric Keys used for encrypting
data, Key Encryption Keys (KEKs) used to encrypt other keys and
Certification Authority keys.
New KEKs should not be distributed solely under the protection of
existing KEKs.
Key material in transit electronically must be encrypted (except for
CHAP keys between the routers within the Pathway Data Centre LAN).
Cryptographic keys and Key Encryption Keys are either installed
locally at the machine where they are to be used, or are distributed
electronically using an approved protocol which protects these keys in
transit.
Where a key is delivered in two parts (e.g. a red key and a black key),
the parts should be delivered by different routes.
The key (or part key) to be handled manually must be held in a locked
safe when not in use. Access to this must be authorised and recorded
in conformance with Pathway procedures.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 36 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
3.7 Effect on other Pathway Standards and Procedures
This Access Control Policy defines the policy for controlling access to
resources in the operational Pathway system. As explained in section
1.2, there are other documents covering detailed configuration of
Pathway systems, physical security standards and procedures used
when operating the system. The effect of the Access Control Policy on
these other documents is:
3.7.1.1 The detailed configurations documents covering the different Pathway
systems define how this Access Control Policy is achieved. For
example, they should say how the roles defined here are set up to
restrict access as required.
3.7.1.2 The roles defined in this document should be used in other security
standards and procedures, not just information system controls. For
example,
e procedures for controlling access to secure areas must take into
account the roles of people and the organisations to which they
belong
e where a role requires access to sensitive data, this should be
reflected in the level of vetting required for staff in that role.
e users in these roles must be controlled through a formal registration
process. Each user must be authorised to take that role by the
appropriate authority before being added to the IT system. Records
of
all persons registered to use the system must be kept, though the
way this is done may be role or service dependent.
3.7.1.3 This Access Control Policy depends on Pathway procedures in some
places. The key ones are:
e Pathway (and associated) staff visiting other sites must have a
identity pass with photograph and signature. This must be from a
relevant organisation which gives such passes to suitably vetted
staff only.
e Post Office procedures which must include how to add users to
Riposte, how to physically protect tokens and passwords,
procedures for telephone authentication to Help Desks etc
e Girobank procedures associated with the Payment Card Helpline.
These include procedures for telephone authentication and action to
be taken on different types of calls. It also includes Girobank
procedures need to cover user and system administration in line
with this policy.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 37 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e Operational management and application support procedures
(particularly CFM and SSC). These must detail, for example, how
remote access is properly authorised and the lines configured to
allow this when needed (see sections 4 and 8).
e System management procedures to authorise, for example,
distribution of software.
e Technical Help Desk procedures to ensure all relevant calls are
logged with the help desk systems system and properly monitored.
e General procedures for all users of the system. This will include, for
example, procedures on password use and incident reporting. For
users authenticating using security tokens it will also cover
precautions for protecting the tokens and associated PINs.
e Internal Pathway procedures, for example, for authorising software
for inclusion in the live system.
The Pathway Security Manager will satisfy himself that the procedures
at the various sites are in compliance with the Pathway security
policies and specifications.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 38 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
CENTRAL SERVICES DOMAIN
4.1 Introduction
The Central Services Domain is illustrated in figure 4-1.
POCLHAPS’ POCL POCL DSS DSS
POCL Clients TIP refdata ESNS CAPS
Sdquent
Hosts card
[aps] [ TPs ] RDMc] [oBcs] fpasicmsI I_I prod’n
Management
& Support NT Servers Data
users —I arehouse
TMy Agents Related feeds
TIP I Ref Datal [OBCS] I BES ]} Iservices
[Harvester] I Agent I IAgents] IAgents eg.
t t t t security,
Correspondence Servers (Riposte) time
Post Offices
Figure 4-1 Interactions in the Central Services Domain
The hosts at the Central Services Domain are on Sequent machines
running Oracle applications. (New hosts, and host ancillary systems
may be added.)
The TMS agents interface between the application hosts and the
Transaction Management Service (TMS), extracting data from the host
and formatting it for transmission to the Post Offices as Riposte
messages and vice versa. The agents use SQL*Net to access specific
Oracle tables set up for such transfer at the hosts, either to retrieve
information to send to the Post office or to update tables as the result
of messages received from the Post office. TIP Harvester Agents
extract all transactions from the correspondence servers (via the
Riposte API) for forward transmission to TIP and elsewhere.
Riposte at the Correspondence servers and Post Offices provide the
Transaction Management Service which records all transactions at the
Post Office Counters and archives them.
The main operational flows though the hosts, TMS Agents and TMS
are automated (as is most System Management).
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 39 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
4.2 Sequent Systems with Oracle Databases
All the host systems in this domain run on the Dynix operating system
on Sequent and use Oracle databases, though the Access Services,
which feed information to and from the applications, in some cases
hold data in flat files. Interactions with Sequent systems are illustrated
in figure 4-2.
Data feeds to/from
DSS,POCL & Clients
Application specific systel e)
ipplic holes specific I Sequen\/Dynix I___ System ee
Auditors Access Services Operational Management
security & II to other systems I —Sequent/Dynix, Oracle db,
other auditors via PCs forother links)I job scheduling
Security Manager
user etc admin
Base Installation
Applications
Support users and : .
application & — Databases t— Engineers
hardware diagnosis/repair
system support T
Automatic feeds card/tokenfeeds
to/from TMS — (CMS/De La Rue)
Data Warehouse feeds
Figure 4-2 Interactions with Sequent systems
Processing on the Sequent systems is normally initiated automatically
as the result of files being received or at a particular time. So the main
processing is controlled purely as the result of the way the system is
set up, not by controlling human access to the system. Similarly, where
practical, system management is done automatically (see section 8).
As the results of monitoring the system, the need to take some
remedial action may be recognised. Only where this action cannot be
taken automatically is human intervention required.
Direct users of the Sequent system are defined in 4.2.1. The main
users are:
e Security managers who manage security information about users
and their privileges, groups etc.
¢ Operational Managers/System Administrators managing the Dynix
operating system and Oracle databases. The normal role here is
monitoring the system. More active use of the system occurs as the
result of incidents.
e Application support people diagnosing software faults and
engineers diagnosing and clearing hardware faults
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 40 of 117
ICL Pathway
FU.
Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
FUJ00087993
IJ00087993
e Security and other Auditors
e Application specific roles as detailed in 4.3 below.
4.2.1 Roles
People in the following roles have direct access to the Sequent
machines.
Role Main classes of functions
Computer Operator
Physical operations e.g. media handling, and the ability to
fun pre-defined jobs, such as back-ups.
System Monitoring
Monitoring the operational system using Patrol.
Database monitor
Monitoring Oracle databases
Operational
management/
System Administrator
Management of Dynix including any action needed
concerned with replication between campuses and local
archiving.
Operational monitoring/management using Patrol
workstations.
Job scheduling (Sequent & NT) using Maestro
workstation.
Code updates when required quickly (prior to update via
configuration management) and authorised
Operational manag't/
Database
administrator
Oracle database administrator for database structure -
setting up views, space allocation etc.
Secure menu
administrator
Configuration of the secure menu system, including
addition of new functions
Security Administering UNIX user information, including group
Management membership for all users of the Sequent system.
Administering Oracle database administrator (DBA) users
and associated roles and privileges.
Administering users rights in the Secure menu system
Security monitoring
Dynix 3rd line Operational management of Dynix by Sequent staff when
support CFM cannot cure problem.
Database 3rd line Operational management of Oracle when CFM cannot
support cure problem. This may sometimes require updating the
database.
Application support
Supporting applications on Sequent - both Oracle
user applications and Access services.
Application support Supporting applications as above, plus correcting data
manager when required and authorised.
Application support -
VME applications
Using Sonnet on Sequent to access the Pathway partition
on DSS VME systems for application support
Application 3rd line
Supporting Oracle applications
support
Engineer Hardware diagnostics and repair
Base Installation and I Initial installation and configuration the base system -
configuration Sequent and Oracle databases. Later updates to these.
(Business Function
and Security Event)
Auditor
Access to audit trails, when these are not available
elsewhere
Printed: 22/12/98
RESTRICTED-COMMERCIAL
CAWINNT\Profiles\crosslab\Desktop\RSPOL003.doc Page 41 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
4.2.2
4.2.2.1
4.2.2.2
The Sequent operational system uses symmetrix discs. These are
linked across Data Centres via the Energis network. The roles and
associated access controls for supporting the symmetrix disc controller
and the network box which connects these discs to the Energis
network are covered in 8.8 below.
System Access Controls for Human Roles
As for all domains, system access controls conform to the policies in
section 3.
Users access the system at the operating system and/or Oracle level -
many of the roles above require both levels of use.
Note that users of specific host applications only (see 4.3) should be
Oracle users, not operating system users.
System Level Access Controls
System level access controls at the Sequent system are enforced
using Dynix facilities with some additions. All users requiring UNIX
level access to the system will access it using a Secure Menu System.
This constrains the functions called depending on the user's role and
audits all functions performed by that user. Most management
activities should be done using specific functions on the menu. Where
the function requires a change of username, that will be done
automatically by the menu system and audited. Changes to username
will also cause a Patrol event. For emergency use, the menu will
include an item which provides root access and use of UNIX
commands.
Engineering access when the operating system cannot be fully booted,
is via “single user mode” under controlled conditions (see 3.4.4).
Single user mode should only be used when more controlled methods
are not possible.
Oracle Application Access Controls
Oracle users can access Oracle applications and databases in several
ways:
e Oracle applications or other tools on the user’s workstation,
accessing the database via SQL*Net.
¢ SQL*Plus and other facilities on the Sequent system, called via the
secure menu system above. (SQL*Plus should not be used in client-
server mode.)
e System management tools using system management protocols
Database administration functions should use:
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 42 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e Patrol for monitoring the database
e Pre-defined Discover queries to examine the state of the database.
(Discoverer should be configured to restrict access to the tables and
views needed for the task and audit actions.)
e Pre-defined, authorised SQL*Plus for database updates (which
should include auditing)
Application support should use:
e Discover queries to examine the data
e Pre-defined forms for correcting standard types of data problem
e Pre-authorised SQL*Plus scripts for correcting other data problems
Pre-defined forms and pre-authorised scripts should audit the
correction made.
Note that application support users also need system level access, for
example, for access to code.
Human users of an Oracle database or application, are registered with
the particular Oracle database server as users of specific Oracle roles.
The following Oracle roles should be defined for all Oracle
applications. (This section includes only those roles which are
supported for all Oracle databases - specific roles for specific
applications are defined in 5 for PAS/CMS and 4.3 for other
applications). Note that in some cases, people with different human
roles may have the same access to the same Oracle role.
Oracle role Functions, and roles
MONITOR Read only access to application data in this database
- used by Auditors, FRM, application support etc
AUDITOR As MONITOR plus access to audit information
- used by auditors
CFM_DBA Full dba privileges
SSC As for MONITOR, plus limited updates, implemented by
pre-defined, authorised forms
Note that there are also roles for non-human users such as system
management tools and TMS agents.
4.2.2.3 Table of Access Controls by Role
The following table specifies for each role how users access the
system (workstation type and location), how they are authenticated
and where defined and what resources are available to people with
this role. Note that some of the operational and system management
users have access to a number of systems and are described more
fully in section 8. Information in this section is limited to their use of the
Sequent system.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 43 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Role Workstation type I Authentication method I Resources
and Location & where user defined available
Computer console UNIX/secure menu with I Predefined jobs in
Operator token secure menu system
only
System X terminal (or token authentication Resources as
Monitoring emulator) at Data available via Patrol
Centre and CFM
site
Database NT workstation at UNIX/secure menu with I Read only use of
monitor secure CFM site token SQL*Plus, svrmgr
Operational I NT Workstation (X I UNIX/secure menu plus I Functions as on
Managemen I terminals or token authentication menu. This can
vu emulators for Patrol I (see note 3). allow use of root and
System & Maestro) UNIX commands
administrato I CFM secure site and Oracle dba
is functions.
Database NT workstation at UNIX/secure menu Functions as on
administrato I secure CFM site using token menu - this can
r authentication; allow Oracle dba
Oracle user registered functions for
with associated role for specified
dba functions applications
(CFM_DBA role)
Secure NT workstation at UNIX/secure menu Defined functions for
menu secure CFM site using token menu admin
administrato authentication;
La
Security NT workstation on UNIX/secure menu and User information in
Managemen I secure LAN token (see note 3). UNIX, secure menu
t CFM site Oracle user registered system and Oracle
as above
Dynix 3rd NT workstation. UNIX/secure menu plus I UNIX, which can
line support I Secure site (see token include root access
notes 6 and 7) (see notes 5 and 6)
Oracle db NT workstation. UNIX/secure menu plus_ I Read only access;
3rd line Secure site (see token Oracle dba, &
support note 6) (see notes 5 and 6) limited UNIX
functions.
Application NT workstation at UNIX/secure menu plus I Read only access to
Support secure Pathway token; Registered event logs and other
user site Oracle user relevant files and
databases; Oracle
MONITOR role
Application NT workstation at UNIX/secure menu plus_ I As above, plus
support secure Pathway token; Registered controlled write
manager site Oracle user access to
application data -
Oracle SSC role
(see note 9)
VME NT workstation at UNIX/secure menu at Sonnet, for VME
application secure site Sequent (also VME access
support user)
Application NT workstation at UNIX/secure Read only access to
3" line secure site (note 6) I menu/Oracle application I application; Oracle
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 44 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
support plus token MONITOR role
Engineer computer console. UNIX with engineer Access to
Data Centre password (see notes 5 & I diagnostics and, if
7) needed, data on
suspect hardware
Base computer console UNIX most
Installation Data Centre
Auditor NT w/s on secure UNIX/secure Audit logs -
LAN; Pathway site menu/Oracle and token platform, secure
(Feltham) authentication menu, database,
application;
includes Oracle
AUDITOR role
Notes:
1. Wherever possible, responses to events are automated, to prevent
the need for human interaction.
1. Wherever possible, responses to events which require human
interactions are performed using pre-defined functions, rather than
command line access to the system.
1. Operational management staff always authenticate under their own
names to UNIX and perform functions wherever possible without
superuser/root privileges (see 3.4.2.15). If root is needed, the
appropriate menu item on the secure menu system will be used to
switch users. This will be audited and an alert sent to Patrol so a
record remains available even if the audit log at the UNIX machine
is subsequently corrupted.
1. Emergency operational management is currently expected to be
from the CFM secure site at Belfast.
1. All visiting staff are subject to manual procedures on entering the
secure Pathway site to authenticate who they are and authorise
their access to the computer room - see 3.5.3.
1. Where Sequent and Oracle staff provide 3rd line support, this may
be from Sequent and Oracle sites. In this case, access is froma
secure area using a secure NT workstation on a secure LAN via
encrypted links to the Data Centre - see 8.2.1 and 8.10. Call in
procedures are as in 8.2.2.
1. As Sequent require root access, an independent monitoring system
will be used where all key strokes on the Sequent workstation are
captured and echoed on a CFM workstation.
1. Visiting engineers are subject to manual procedures as in note 5
above.
RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 45 of 117
FU.
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
FUJ00087993
IJ00087993
4.2.3
4.2.4
1. Application support managers can correct application data subject
to authorisation procedures - see 8.7. For Oracle applications, this
should, where-ever possible, be via functions available to Oracle
SSC role. In exceptional circumstances, use of SQL*Plus scripts will
be authorised after checking. For Access and other services, this
may involve updates to flat files. In all cases, corrections to the data
are audited.
Dynix and Oracle Access Controls
The Dynix operating system should be set-up according to the access
control policy in 3 above. For example, Security Audit Logs (both Dynix
and Oracle ones) should only be accessible to Security Event
Auditors, for Oracle, where there is more than one database on the
same machine (e.g. OBCS, APS, PAS/CMS), these will run under
separate user names.
All loading/unloading of data to/from Oracle databases should be done
by automated processes. Separate interface tables should be used to
restrict the damage possible due to failures during automated
processes.
The set-up of the system should be regularly monitored, for example,
to check for dormant accounts and to review any changes made to
important system files.
Control of Connections to the System
Links to the Sequent systems are controlled by routers and by
configuration of applications and the use of Sequent ports. These
restrict access to the Sequent system from other services at the
Pathway Data Centres and elsewhere. These should permit the traffic
required to support the roles above and the Pathway application traffic,
for example:
e Telnet, X-terminal and token authentication traffic for operational
management, 3rd line support, job scheduling and Security Event
Auditors
e OSI traffic to VME (FTF and MAC) to support file transfer to DSS
systems and management
e SQL*Net access to Oracle databases from Girobank Help Desks
and agents extracting data from the databases for transfer to the
Post offices, to the Data Warehouse, to archives and exceptionally
for Fraud Risk Management
¢ File transfer of business data to PCs en route to/from POCL and De
La Rue
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 46 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
4.3 Access Controls for Specific Host Applications
All host application are Sequent/Oracle ones, and are therefore
subject to the controls defined in 4.2 above. Each has some
differences in the automated feeds into/out of the application. For
example, PAS/CMS has feeds about payment authorisations with
CAPS and about cards with the De La Rue services. OBCS
communicates with the DSS ESNS e.g. to find what Order books have
been stopped. The RDMC service accepts feeds of reference data
from POCL (and potentially elsewhere). The TPS feeds Post Office
transaction information to the POCL TIP system. Access controls for all
applications conform to the general policies in 3.
All these applications support the standard Oracle roles (CFM_DBA,
AUDITOR, SSC and MONITOR) for database administration, auditors,
application support managers and people with only read access to the
database (application support users, system monitoring) - see 4.2
above.
In addition, there is a BSU role (for Business Support) for some
applications, including PAS/CMS - see below.
The MONITOR role is also used by the other human roles for read only
access - both Pathway and Girobank Fraud Risk Managers have this
role in PAS/CMS, APS, OBCS and TPS.
In addition, PAS/CMS and RDMC have further application specific
roles.
4.3.1 PAS and CMS
Information comes from the CAPS system, is processed by PAS/CMS
and sent either to the TMS for forwarding to the Post Offices or to the
Card or Temporary Token Producer to generate cards and PUNs.
Information is returned from both these sources, processed and
returned to the CAPS system. The main processing is done
automatically without human intervention. Track and Trace information
is also received from the Royal Mail.
Specific PAS/CMS roles are:
e Payment Card Helpline Advisors using Oracle Forms applications to
access PAS/CMS and Helpline Security Managers maintaining user
information about them at the PAS/CMS database. See also 7.4 for
Helpline roles.
e DSS/BA benefit staff doing on-line transactions via CAPS e.g.
emergency payments and DSS Help Desk staff enquiring on
PAS/CMS data, also via the CAPS on-line interface.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 47 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e Business Support users accessing PAS/CMS when required for
financial reconciliation (see 7.5)
e Fraud Risk Management staff accessing PAS/CMS data when
required information is not available via the Data Warehouse or
archives.
¢ The Cryptographic Key Custodian installing/updating the encryption
key needed for the CAPS to PAS/CMS link.
Note that the operational management role includes generating
contingency payment authorisations when CAPS is down according to
agreed procedures.
The following table shows the system access controls associated with
the PAS/CMS roles (apart from the Cryptographic Key roles which are
as defined in 7.7.1). All users in the table access PAS/CMS
information via Oracle tools.
Role Workstation IHow authenticated I Resources available
type and to PAS/CMS (&
location where user
defined)
Helpline NT Help DeskI Oracle username, Particular PAS & CMS tables as
Advisor workstation in I password required for the authorised Oracle
Girobank (Oracle user Forms (with sufficient write access
area at associated with to allow cards to be stopped,
campus Oracle role) update call logging tables and
change password.)
Helpline as above as above As above, plus can handle data
Advisor with a Nationally Sensitive
(NSI) Indicator.
Helpline as above as above As a Help Desk Advisor, plus the
Supervisor ability to handle NSI data and
other more restricted dialogues.
Helpline as above Oracle username, Oracle user and role tables via
Security password (Oracle authorised Oracle Forms; access
Manager user associated with Ias Helpline Advisors plus privilege
Oracle role) to create users and assign/re-
assign them to Helpline roles.
DSS/BA staff I DSS/BA Authenticated to Particular PAS tables as required
terminal and IDSS system, for the authorised transactions
site identified to P’'way byI from the Oracle client applications
transaction id. on VME. (The Oracle POLI
system username.)
Business NT at secure INT user with token I Read only access via pre-defined
Support Pathway site Iand Oracle user forms to PAS/CMS for
(BSU role) reconciliation
Fraud Risk INT secure NT user with token I Read only access main database
Manager sites G’bank, Iand Oracle, UNIX? __Iin exceptional circumstances
P'way user
There is a separate username for the Cryptographic Key Custodian.
Filestore accessible only to that user holds the cryptographic key.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 48 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
4.3.2 Reference Data Management Centre
Reference data can be associated with particular applications (e.g. the
price of stamps in EPOSS) or be more generic (e.g. Post office
details). It may come from POCL, POCL Clients and Pathway. Data fed
into the RDMC is classified according to whether it should be used to
update the RDMC and Post Office counters automatically (class 1) or
whether some human intervention is needed. For the main feed from
POCL, new reference data and its class is agreed in advance of the
data being fed to the RDMC.
All reference data fed to RDMC is validated. If validation fails, the data
is returned automatically to POCL without human intervention.
Reference data for counter applications is distributed via the
associated RDDS and the TMS system to the Post Offices. Reference
data is also fed to the Data Warehouse.
For reference data of class 2 and above, the data is held at the RDDS
until the dependencies for its use have been satisfied. For example,
the software needed to process it must be available and shown to work
with it. Some reference data comes from the Pathway project and
supplied to RDMC via Configuration Management as for other software
updates - see 8.6.2.
Application roles supported at the RDMC are:
Role Main Functions
Reference Data Kick off the transfer of validated reference data of
Change Manager classes 2 to 5 to TMS when all required
dependencies have been met. (Oracle role:
user_change_control)
RDMC Loader Manually initiated load of reference data files to
RDMC (Oracle role: user_loader)
RDMC user Query and report on reference data, so read only
access (Oracle role: user_reports)
RDMC access Sets up users and assigns them their roles (Oracle
administrator role: user_administrator)
All these users access the RDMC from a controlled NT workstation on
a secure LAN from a secure Pathway site via encrypted links.
Authentication to NT uses a token allocated to the individual, they also
authenticate to the Oracle application. Oracles roles control this
access. There are no human roles at the RDDS.
Note that the security management role in 4.2 includes user
management of the core users of the system, including the RDMC
users. Application support in 4.2 includes support of the RDMC.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 49 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
44
4.4.1
Windows NT Systems
There are several different types of NT systems in this domain. For
example, the TMS Agents are generally on separate NT servers from
those used for the Correspondence Servers and there are also NT
servers supporting security services, the time service, the PCs
providing the interfaces to transfer files to De La Rue, POCL etc.
All of these NT servers have common management and support users
and may have specific operational users as illustrated in figure 4-3.
Operational Data feeds
System Management
- software distribution
Operational roles NT ~ resource managemI ent
(application specific). —] - event monitoring
Applications System Administration
and
Infrastructure I >-—
Security Management
Base Installation
and Configuration
Security Event Auditor
Application Support Engineers
Figure 4-3 Users of NT systems
As for the Sequent systems, most of the use of the NT systems is
automated so human intervention is an exception - mainly for system
management and support. Different NT servers support different
applications, so there are some differences in the access controls
required at different servers. However, management of all NT servers
in this domain is done in the same way.
e The NT servers are managed using Tivoli and NT administration.
Events and resources are monitored via Tivoli (see section 8) and
appropriate remedial action is generally taken automatically.
Security management (e.g. administering users) is done using NT
utilities.
e Software and configuration information is distributed to these
systems via Tivoli (see section 8).
e NT servers also have local consoles for use by engineers when
diagnosing and repairing faults and for any other management
action required locally.
The common roles for all NT servers are described in 0. Specific roles
for particular NT servers are included in section 4.5.
Roles
People in the following roles have access to all NT systems in this
domain.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 50 of 117
FUJ00087993
IJ00087993
FU.
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Role Main functions
Computer Operator
Physical operations e.g. media handling, but no on-line
use of the system. This includes the Legato tapes used for
archiving
Operational
management
Any residual management of NT (not done by SMC e.g.
via Tivoli).
Security Manager
Administering NT user information, including group
membership.
Security Event
Auditor
Use of audit logs in monitoring security and tracing
incidents
Application support
user
Supporting applications on NT platforms.
Application support
As above, but also able to correct some data
manager
Engineer Hardware diagnostics and repair
Base Installation and _I Initial installation and configuration the base system - NT
configuration etc Later updates to this.
Note that relational databases are not supported at most NT systems,
so NT database administrator roles are defined only at relevant NT
systems (e.g. the roll-out/auto-configuration system - see 8.6.)
4.4.2 System Access Controls for Human Roles
Access controls associated with these roles are defined in the followed
table.
Role Workstation Authentication Resources
type and method & where Available
location user defined
Computer no w/s; on site at I none, as no access Media only
Operator Data Centre
Operational NT w/s at secure I NT with token (defined I Administrator
Management Pathway site at appropriate rights
domain)
Security Manager I NT workstation at I NT with token (defined I User
secure Pathway at appropriate administration,
site domain) security policy
administration etc
Security Event NT workstation at I NT with token (defined I Read only access
Auditor secure P’way site I at appropriate to audit logs only
domain)
Application NT workstation at I NT with token (defined I Read only access
Support user secure P’way site I at appropriate to event logs,
domain) registry and
relevant files.
Application NT workstation at I NT with token (defined I As above plus
Support Manager I secure P’way site I at appropriate some data
domain) correction
Engineer Pathway campus; I NT with controlled Administration
no remote access I password/token
Base Installation _I Pathway campus _I NT with password Administration
Notes:
Printed: 22/12/98
RESTRICTED-COMMERCIAL
CAWINNT\Profiles\crosslab\Desktop\RSPOL003.doc Page 51 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
1. Engineers have controlled access c.f. Sequent. They are
accompanied by CFM staff when using the system
1. There is a specific variant of the administration role for
administration of the Primary Domain Controller of an NT domain.
1. Application support managers correcting data are subject to the
same controls as on Sequent and elsewhere (see 8.7) - all updates
must be pre-authorised, and the update method used must audit the
correction.
1. Apart from event logs etc which are relevant to all NT systems,
application support users should access application databases via
relevant tools, rather than just operating system facilities.
4.4.3 System Set Up
System access controls must conform to the policies in 3.
All NT servers are set up with a group and template user for each of
the roles above (plus any other defined for the particular NT system).
These templates are used when a user is assigned to a role to set up
that user with the required user profile providing access to only those
tools needed to carry out the role.
NT systems belong to domains with a primary domain controller and
backup domain controllers so users only need to be administered at
one place for access to all systems at that domain. Users in most roles
can logon once to all NT Pathway domains with trust relationships
constraining resources available between domains. However, some
roles (Engineer and Key Custodian) will always be defined as requiring
the user to be local at the machine. Policies for the structure of NT
domains are in 8.11.
4.4.4 Control of Connections
The following traffic is generally permitted to NT systems at the Data
Centre:
e Telnet and token authentication traffic for NT management, security
auditor access etc
¢ NT domain traffic
e Maestro job scheduling (at Agents)
e Tivoli traffic for event management, software distribution etc
e File transfer traffic using FTMS
e Client access to applications. Different types of access are used for
different applications
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 52 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
However, the NT server supporting the KMA has more restricted
access (for example, no Maestro scheduling). Also, many of the NT
systems have application specific traffic such as SQL*Net access to
access Oracle database tables, Riposte RPC traffic to link to
Correspondence Servers.
4.5 Specific NT Servers (except security ones)
NT servers are used to support many of the Data Centre business
services used during normal operation. These include:
e The Correspondence Servers where Riposte, together with the
Riposte infrastructure at the Post Office, form the Transaction
Management Service which handles all the operational traffic to and
from the Post Offices. (Note that there is other traffic between the
Pathway Data Centres and the Post Offices for System
Management traffic and Key Distribution.)
e The Agents which transfer data between the hosts and the
Correspondence servers. There are different agents which handle
traffic for different links.
e The PCs which handle file transfers between the Pathway Data
Centres and POCL, De La Rue, and potentially other POCL clients
sites in future. (The PCs at the POCL and De la Rue sites are
controlled as described in sections 5 and 8)
e Related supporting services such as the Time Service, Archive
Service, Host Ancillary services.
e Security services such as the Entropy Servers used in signing
benefit payments, the Key Management Service used to generate
and distribute keys and the Authentication Service used for token
authentication.
All these NT servers are subject to the controls described in _ above.
In addition, there are also service specific access controls on some of
these systems. This section describes these controls for all these NT
servers except the Security Services ones which are described in the
next section.
There are also a number of NT systems used for system management,
software distribution and Post Office implementation. These are
covered in section 8.
4.5.1 Roles
Operational use of these services is automated, so does not normally
require any human intervention apart from the management and
support roles defined in 0 above. There are the following specific roles
at these NT servers.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 53 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Role Main Functions NT Servers
where
applicable
Riposte Residual Riposte management which I Correspondenc
Management is not automated e.g. setting Riposte e servers
neighbours. (Setting up
Correspondence servers as members
of Riposte groups when new Post
Offices are added is done by the auto-
configuration application.)
Business Access to TMS when needed to Correspondenc
Support support reconciliation e servers
Pathway FRM _I Access to TMS journals in exceptional I Correspondenc
circumstances, when needed to e servers (and
support investigations. their archives)
Auditors Access to TMS journals when needed _ I Correspondenc
to when investigating security e servers (and
incidents their archives)
Legato Managing the audit archives Archive server
Adminstration
Crypto Key Installation and update of keys and re- I BES Agents,
Custodian & installation when needed e.g. on PC for De La
Key Handler machine reboot. (These roles are Rue link
defined in 7.7.1)
Notes:
1. The BES Agent requires installation of a DSA private key for
protecting payment authorisations. (and associated public key
certificates etc).
1. The De La Rue link PC requires installation of a Red Pike key.
Access controls for these roles are as defined in the following table.
Role Workstation type Authentication Resources
and location method available
Riposte NT at secure site NT domain user I Appropriate
management _I (see 8.2) with token Riposte utilities
Business NT at secure NT domain user I Controlled read
Support Pathway site with token only TMS
access
Pathway FRM I NT at Pathway NT domain user I Limited read
secure area with token only TMS
access (see
note)
Security NT at Pathway NT domain user I Audit logs and
Event Auditor I secure area with token limited read
only TMS
access
Legato NT at Pathway NT domain user I Legato
Administratio I secure area with token archivies via
n Legato client
Printed: 22/12/98
RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 54 of 117
ICL Pathway Ref: RS/POL/0003
FUJ00087993
FUJ00087993
Access Control Policy Version: 3.0
Date: 18/12/98
4.5.2
4.6
Notes:
1. Business Support, FRM and Auditor access to the operational
Correspondence servers is allowed in exceptional circumstances for
limited amounts of data (as otherwise, the performance of the
system could be impaired). In all cases, access is controlled, and
limited to use of a specific Riposte Query tool.
1. Access controls associated with cryptographic keys are covered in
7.74
Other Access Controls
The network and platform set up should restrict the traffic to that
required to operate and manage the system. At all platforms, the
required system management traffic is permitted. In addition, the traffic
needed to support the operational and MIS process must be permitted.
For example:
e At Correspondence servers: data transfers to/from Agents using
Riposte RPC and to/from Post Offices using TMS via specific
routers
e At Agents in general: SQL*Net links to the appropriate host
application on Sequent (PAS/CMS, OBCS, APS, TPS or RDMC)
and links via the Riposte API using RPC for distribution to/from
TMS. Note that the TIP harvester acts as the Agent for both APS
and TPS and also supplies the TMS journal information to the Data
Warehouse.
e At BES Agents: links to an Entropy Server on a separate NT server
to obtain the entropy needed for signing payment authorisations
using DSA and to the KMA for distribution of some key material
using key distribution protocols which protect keys in transit
Security Services
Pathway uses cryptography for integrity and sometimes confidentiality
protection of all or selected data on certain links and sometimes
filestore. To support this, Pathway has the following security services:
e A Key Management Application (KMA) which (generates and)
distributes cryptographic keys to Pathway services and the Post
Offices. An associated Certification Authority (CA) generates
public key certificates and Entropy servers which generate DSA
entropy for digital signatures.
e The VPN servers used for protection of the traffic to Post Offices
e An Authentication Service to support token authentication.
e The cryptographic boxes used for link level encryption of some
links.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 55 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
(This is in addition to the software security services to protect data in
transit on particular links. For example, encryption on the CAPS and
De la Rue links, digital signatures for payment authorisations send to
the Post Office. Also, there are signing servers to sign software and
auto-configuration information sent to the Post office - see 8.6.)
4.6.1 Key Management and Associated Services
Interactions with the Key Management Application (KMA) and
Certification Authority Workstation (CAW) are illustrated in figure 4-9.
Cryptographic NT Security Dervices Management,
Key Manager _ I Key Certification] I___Support,
and other anagement [~] Entropy Authority Engineering
Key Handlers Application Servers orkstation etc
y y
BES Agents BES
Crypto Servers Agents
Post Offices ete
Figure 4-4 Interactions with the Key Management Service
The Key Management Application (KMA) is used to (generate and)
store cryptographic keys and is also used when distributing initial and
updated keys to the Post Offices, routers etc. Keys handled include the
CHAP keys for Post Office authentication and Post office filestore
encryption key. The KMA also uses the Entropy Servers to provides
the entropy needed for DSA signatures.
An off-line Certification Authority - the Certification Authority
Workstation (CAW) is used to generate public key certificates used
when verifying digital signatures.
People in the following roles have access to these services (in addition
to the NT operational management and support roles defined in 4.4).
Role Main functions (system accessed)
Cryptographic Key Manager Generating keys and initiating distribution
of these; viewing current situation re keys
(KMA)
Generating certificates to certify keys
(CAW)
KMA Data Manager Maintain validity of data within KMA
database e.g. specify new client where key
to be sent (but no key management roles)
Cryptographic Key Custodian I Installing, updating and re-installing keys.
and Handlers - see 7.7.1
PO key recoverer Initiating recovery of a Post Office key for
(part of SMC Team Leader a Post Office Manager who has lost his
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 56 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
role) card or PIN after authentication of the PO
caller to the Help Desk - see 8.3, 8.9.
Notes:
1. Access controls for the Key Custodians and Handlers are defined in
7.74
1. Access controls for the PO key recover are defined in 8.3.
1. The Key Manager and KMA Data Manager roles are Oracle users,
so log-on to Oracle (after NT workstation, token logon). This gives
access to specific functions only
1. There are also Database administrator and security manager roles
for the underlying database c.f. Oracle roles for host applications.
4.6.2 Authentication Service for Authentication using Tokens
Authentication using tokens will be supported by an Authentication
Service at each Data Centre. The Authentication Server at one Data
Centre will be the master, generally used for all authentication, with the
other acting as a slave to provide resilience.
The Authentication Service holds information about:
e Tokens, and when, and to whom, they are assigned; also the PINs
associated with these tokens
e Users of these tokens
¢ Clients who initiate authentication when users access the system.
These may be on NT and UNIX systems and on routers.
e Audit logs of authentication and administrative activities
¢ Configuration options such as the type and size of PINs permitted,
Client retry interval, master/slave information
The main roles at this system are:
e Installation and configuration of the Authentication Service - part of
the operational management role of the Solaris system on which the
service is installed - see 4.7.
e Administration of tokens and users for all Pathway users who
require authentication via tokens - see 7.7.2.
¢ Auditors - the Authentication Service has real time monitoring tools
for this (as well as providing audit trails to the Audit Service).
All these users access the system from controlled NT workstations on
a secure LAN in a secure area linked to the Data Centre over an
encrypted link. After initial installation of the service, they authenticate
using tokens.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 57 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
4.6.3 Cryptographic Boxes
Zergo boxes are used to provide link level encryption on a number of
links. These are government approved point-to-point encryption
devices using Rambutan and access controls are as specified by the
manufacturer.
4.7 Solaris Systems
Solaris systems are used for a number of services at the Data Centres
including:
e A Solaris system supporting the PAS/CMS training database. This is
used by the Payment Card Helpline for staff training and supports
the same Oracle Forms applications as used for the operational
system, but with training (and therefore not sensitive) data.
e The Network Management Station at each Data Centre- see 8.5
¢ The Solaris system at each Data Centre supporting Security token
management (see 4.6 above) and the Firewall Enterprise Centre
(see 8.5)
All of these Solaris servers have common management roles as
follows:
Role (and organisation) Main functions
Computer Operator (CFM) Physical operations
Operational management c.f. Sequent operational management
Security Management (CFM) Administering user information
Security Event Auditor Access to audit logs
(Pathway)
Engineer Hardware diagnostic and repair
Access controls associated with these roles are defined in the
following table:
Role Workstation type I Authentication Resources
and location method available
Computer no w/s; on site at none, as no media only
Operator Data Centre access
Operational ? (is this NT, UNIX with token UNIX
management _I Belfast) administration
Security see above UNIX with token user/security
management administration
Security NT workstation; UNIX with token read only access
Event Auditor I Feltham to logs, relevant
files
Engineer Pathway campus, I UNIX with required UNIX
no direct access _I controlled facilities
password/token
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 58 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Note: this section is not yet complete, as roles have still to be discussed andI
agreed.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 59 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
OFFICE PLATFORM SERVICE DOMAIN
5.1 Introduction
The Office Platform Service Domain is illustrated in figure 5-1.
Correspondence servers
at Pathway central sites Remote
System
Management
Customer (Riposte
journals etc) I}I— Support Engineer
NT
Counter I__—- Auditors and
—_—_ K Infrastructure Emergency Manager
Payment & ard
Post —
Helpline @ i) Office Applications Installation
staff APS,EPOSS I -— Engineer
OBCS, BES
Horizon Fi Horizon Field
On-line IS
System Mir) documentation Support Officer
Help desk
Figure 5 - 1 Interactions in the Office Platform Service Domain
Information about BA payments and cards and also about APS,
EPOSS and OBCS is distributed using the Riposte Transaction
Management System which includes the Riposte journals at the Post
Office.
Customers pick up Benefits cards and use these to prove their identity
when receive payments or use the existing style of Order Books and
Girocheques to get payments. They may also use other Post Office
services such as Automated Payments and purchase many types of
items.
Counter clerks handle these transactions using the applications at the
counter. In exceptional circumstances, they may ring up the Payment
Card Helpline, for example, to confirm whether a payment should be
made or the Horizon System Help Desk for advice on other
applications. Post Office Managers act as local system manager and
report faults via the Horizon System Help Desk.
Engineers install the Pathway service to Post Offices, provide updates
and handle faults in the system by replacing components of it. The
Horizon System Field Officers (HFSOs) handle migration of existing
Post Office data.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 60 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Post Office Systems are monitored and managed via System
Management Services using Tivoli. These are used to distribute
software and scripts to initiate management actions to Post Offices.
Software distribution can include updates to the Tivoli Agent and to
Riposte and NT as well as applications. Tivoli tasks are also used to
extract diagnostic information from the Post Office counter systems for
use in application support - see 8.3 and 8.7.
5.2 Roles
All direct users of the NT Workstations at the Post Office are local.
Although there are potentially several separate functions which in a
larger organisation would be allocated to separate people, only the
following roles are identified for Post Office staff:
¢ The Post Office Manager who is responsible for all the
management of the Post Office system including setting up
workstations, introducing users, doing accounts.
“Manager” is a generic term here - meaning the person in charge of
the Post Office. The person taking the role may be a sub-postmaster
or agent.
Post Office Managers may allow other staff to deputise for them,
and so take this role.
e Counter clerks who run the APS, EPOSS, OBCS and BES
applications.
e Supervisors who can perform all Counter Clerk functions and may
also do other functions such as view stocks.
The Post Office Manager acts as the Security Manager at the Post
Office (rather than this being a separate role as in other domains); in
many Post Offices, there are insufficient people to justify a separation
role for this.
Customers are also recognised at the Post Office, though they do not
access the system directly, so do not have a role in the system.
POCL Auditors have access to Post Office services. The normal
POCL Auditor will have read only access to the system. One of the
Auditors may take the role of an Emergency Manager who may take
over from the Manager after suspected fraud or when a Post Office is
closed down or transferred to a different Manager. POCL Investigators
have the same access rights as normal POCL Auditors and are not
distinguished from them in the IT system.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 61 of 117
ICL Pathway
FUJ00087993
FUJ00087993
Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Horizon Field Support Officers (HFSOs) handle the migration of Post
Office data to Horizon - either manual records on from ECCO equipped
Post Offices. Other Pathway staff such as Security Event Auditors do
not have access to the Post Office system.
The following table shows the main classes of functions of people in
the identified roles. (There is also a Support group used in
emergencies - see 5.4)
Role
Manager
Main classes of functions
Key (and memory card) custodian - installing, changing
and recovering keys.
User management (of local post office staff).
Stock unit management (including allocation to clerks)
Specific management applications, for example,
balancing Post Office accounts.
Run diagnostics to check system and peripherals are
functioning correctly.
All counter clerk functions.
Counter Clerk
System boot-up using the memory card. (At some Post
offices, this may be restricted to more senior staff.)
Run applications BES, EPOSS, APS, OBCS.
Contact the Payment Card Helpline when required.
Stock unit balancing etc.
Supervisor
As Counter Clerk plus viewing stock, users.
Clerk using
training mode
As Counter clerk functions with special training data
(counter clerk also uses special training benefits/APS
cards so does not need a customer present)
Installation Roll-out of new Post Offices including setting up Post
engineer Office personality.
HFSO Migration of data, particularly stock units from existing
Post Office systems onto Horizon
Support Replacing peripherals etc and running diagnostics to
engineer check functioning correctly.
Adding new workstations, peripherals.
Auditor Production of reports as done by Post Office manager
and viewing and/or printing selected log of events.
Emergency As normal auditor plus all Post office Manager functions
Manager including user administration.
5.3 Control of Connections to the Systems
A multi-counter Post Office has a network of NT workstations, one of
which is the gateway with a link to the Pathway Data Centres as
illustrated in figure 5-2.
Printed: 22/12/98
RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 62 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
oo ISDN (or other) Link
NT workstations
Figure 5-2 Post Office Configuration
In some cases, the ISDN link is replaced by a different form of link, but
this does not affect the Access Control Policy.
In a single counter Post Office, the link is to the only workstation,
which may be at the Post Office site or may be portable. In a multi-
counter Post Office, not all workstations need have all the same
peripherals, so some transactions can only be done at certain
counters.
The link to the Pathway campus is protected using VPN as defined in
[SFS].
The following table shows which services are permitted on this link.
Service Type of access
Auto-configuration on Post
Office roll-out
Transfer of auto-configuration information
e.g. from Boot server - see 8.6.
Key distribution from KMS
Key management protocols protect keys in
transit as defined in [SFS]
Transfer of business
information to/from
correspondence servers
Automated using Riposte TMS features
Distribution of help
documentation and training
mode data
Via Riposte TMS
System management via
Tivoli including software
distribution
Automatic using Tivoli. Scripts and software
are signed for integrity protection.
Gathering diagnostic data
for application support
Read access only to required data (NT
event logs) via Tivoli.
5.4 System Delivery
As the result of Factory installation, Post Office workstations have NT,
Riposte, applications and file encryption software installed. There is
also a “failsafe” version of NT included in the installation which will not
be updated by changes distributed via Tivoli. However, there is no
specific information or code for a particular Post office. Personalisation
information is added during installation.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 63 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
At this stage, the filestore is not encrypted, though the directories are
set up correctly for standard running.
The Riposte user groups are set up. The Manager, Supervisor, Clerk,
Engineer and Auditor groups are used by people in those roles. The
AuditorE group is used by Emergency Managers. The Support group is
used for emergency procedures such as the Manager forgetting his
password. The Engineer, Auditor, AuditorE and Support groups are set
up to require one-time password authentication.
Usernames are set up in Riposte and NT for an Engineer, an
Emergency Manager, a Support user and for a number of Auditors
(enough to allow an auditor at each counter of the largest Post Office).
There will also be a special Set-up Manager user used during Post
Office installation - see 5.6. These users are associated with the
relevant Riposte groups. (The Post Office Manager will introduce
further users later.)
Some standard keys are included in this installation as defined in
[SFS].
When leaving the factory, the only application which can be run is the
Auto-configuration one (see 8.6). It is not possible to log-on to NT or
Riposte.
5.5 System Installation/Reconfiguration
The Auto-configuration application at the counter is run by the
installation engineer on the gateway workstation when the counters
are first installed and after major configuration changes. It (together
with the auto-configuration facilities at the Data Centre - see 8.6) sets
up the link with the Pathway Central Services and installs the Post
Office personality, and registers this Post Office with the Central
Services.
When this has been done, the workstation is rebooted and the Post
Office Manager takes charge.
5.6 Booting the System
When the system is rebooted after installation, the Manager puts a
blank Memory Card in the reader and a PIN is generated for it (and
printed unless there is a fault) and key material put on the card. The
security initialisation process establishes the keys to protect the link
and encrypt the filestore. The Manager then starts up each workstation
for normal running.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 64 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
From this point on, whenever any Post Office workstation is rebooted,
the Memory Card is used for starting up the workstations securely as
described in [SFS]. The start up process completes in the display of
the Riposte log-on screen. No direct access to NT or Windows is
possible at any time, even for engineers.
On first installation of the Post Office, the Manager logs in under the
Set-up Manager username to create his individual username as a
Manager for future use. On first installation, existing stock units need
to be migrated to the Pathway system. This is done one of two ways:
e For Post Offices with manual records, the HFSO uses the MiMAN
(Riposte) application under the PO Manager control. The PO
Manager checks the bona fides of the HFSO and creates a
migration user, including the HFSO’s name in it, and with the role
MIGRATION which only has access to the MiMAN application. The
HFSO will logon (using a shared HFSO password) and input the
required stock unit information. After migration, the Post Office
Manager and HFSO check the name details are correct and the
Post office manager deletes the migration account.
e For Post Offices migrating from ECCO equipment, the HFSO uses a
laptop to read ECCO disks, and create Riposte attribute grammar
records from them. These are then fed to the Correspondence
server records for the Post Office via the Post office gateway and
the Migration server at the Data Centre - see 8.6. As for manual
migration, this is under Post Office Manager control. After migration,
the ECCO disk is invalidated, so it can no longer be used and the
Migration server will not accept another attempt at migration from
this Post office.
If there is a failure on booting the counter systems after installation of a
new package, the Manager, supported by the Horizon System Help
Desk, reverts to the Failsafe version of NT.
5.7 System Access Controls associated with Human Roles
As for all domains, system access controls conform to the policies in
section 3. The following specialisations of the general policies apply at
this domain.
e A password cannot be re-used for 18 months.
e The password is checked to conform to quality standards as follows:
passwords cannot contain spaces
« there cannot be more than two consecutive identical
characters
« the password cannot be the same as the username
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 65 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e the password cannot be one of an agreed “excluded
passwords” list.
¢ The PIN used for the Post Office Manager’s memory card is a 15
character alphanumeric value
e After a period of inactivity at a Post Office counter, the session will
time out, but can be resumed on entry of the password. After a
longer period of inactivity, the user is forcibly logged out.
The following table shows how access controls associated with human
roles are enforced at the Post Office counters after installation and
migration.
In NT and Riposte, there is no direct support for roles, so these are
represented by user groups - see 5.4. Users are maintained using
Riposte, which causes equivalent users to be maintained in NT.
Role Function Where Authentication Resource
users needed access controls
defined
Installatio I Start up Post I Not in Manual Auto-configurer
n Office system procedures (see application only
Engineer note 1)
Post Post Office Not in Manual Memory Card
Office installation system procedures and set up
Manager application only
(see notes 2-4)
Normal Riposte Riposte Relevant Riposte
functions and I user; in username and applications only
key changes I Manager password (see
group note 5)
Emergency Riposte user I Riposte All Riposte
procedures in Support username and Manager
(see note 5) group one-time functions
password
Counter All functions Riposte user I Riposte Relevant Riposte
clerks and in relevant username and applications only
Superviso group password
is
training mode I Not no separate log- I Relevant Riposte
separately on from live applications with
defined application use training data
All Workstation Not in Memory Card Workstation start
permitted I start up system and PIN (see up only
PO roles notes 2-4)
Support running Riposte user I generic Engineer I Relevant Riposte
Engineer diagnostics Riposte diagnostic
username & one I application only.
installing new shot password Auto-configurer
hardware (see note 6) application
Auditors All functions Riposte user I generic Riposte Relevant Riposte
Auditor username I applications only.
with one time
password (note 6)
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 66 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Emergenc I Workstation not in Memory card and I Start up
y Manager I start up system PIN (see note 7) I application only
other Riposte One time Riposte
functions generic user _I password applications only
Notes:
1. The installation engineer will have an Id card with a photograph and
signature and the Post Office will have been informed of his visit.
1. Memory Card use on installation and workstation startup is further
defined in [SFS]. More information about Roll-out is included in
section 8.6.
1. The Post Office Manager is expected to secure the Memory Card
and PIN for it in separate places.
1. If the Manager looses his card or PIN, procedures require the
Manager to get an emergency recovery key from the Horizon
System Help Desk.
1. If the Manager loses his password, he logs in under a Support
username, using a one-time password (see note 6), to reset his
password on his normal user name. In the Manager’s absence, this
function may also be performed by an authorised deputy.
1. For authentication by one-time password, the Post Office System
generates a value. The user then phones the Horizon System Help
Desk with this, which provides a check value (after authenticating
the user’s identity). The check value is typed in to provide access to
this username. For Engineers and Auditors, the pass number will
also be typed in, so individual users can be identified in the log.
1. If the POCL Emergency Manager takes over a Post Office when the
Manager is unavailable or unco-operative, he may need to use the
Manager emergency recovery procedure to boot up the Post Office
PCs - see note 4.
1. If the Post Office counter fails to boot, the Manager needs to revert
to the failsafe version of NT. This is controlled by a one-time
password, with the Horizon System Help Desk providing the check
value as for Auditor authentication (see note 6).
After a user has logged on using Riposte, the Riposte desk top allows
access to only those items available to people in the user’s role. The
user cannot call any other applications or NT or Windows functions.
The application called from the desk top runs in the Riposte user name
but has limited privileges. It accesses filestore and other resources by
calling the Riposte API to the privileged Riposte Service - it cannot
access the files itself. The Riposte Service “impersonates” the user to
access any user related resources. [Some access to print spoolers do
not use Riposte, but are available to relevant applications.] The
Riposte account (used for the desktop and message service) does not
have administrator privilege.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 67 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
All Riposte transactions, including user administration, are logged in
the Riposte journals. On adding a new user, a full name must be
supplied.
5.8 Other Access Controls
The Customer is an indirect user of the system who needs to be
authenticated as defined in [SADD] for example:
e The customer brings a Pick-up Notice (PUN) with a bar-code as
identification when collecting a Benefits card (or brings an existing
card due to expire to collect a new card)
e The customer brings the benefit card as identification when picking
up a payment. Extended verification is used on transactions
particularly at risk of fraud such as foreign encashments.
Post Office staff may contact Pathway Help Desks and will need to
authenticate to them as defined in the section 5.3.5 (for the Payment
Card Helpline) and in 8.9 (for the Horizon System Help Desk).
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 68 of 117
ICL Pathway Ref: RS/POL/0003
FUJ00087993
FUJ00087993
Access Control Policy Version: 3.0
Date: 18/12/98
6.1
INTERFACE DOMAINS
The ICL Pathway project interfaces to systems run by other
organisations at their sites as part of normal operation. These are:
¢ The DSS Service Environment Domain, where Pathway components
at DSS sites interface to the DSS CAPS Service for payment
authorisations and to the DSS ESNS Service for stopping order
books.
e The POCL and POCL Clients Domain, where Pathway components
at POCL sites interface to POCL services for handling reference
data feeds to Pathway, Post Office transaction data to POCL and to
support Automated Payments (which in future, could interface
directly to POCL Clients).
e The De la Rue Card Services Domain, where Pathway components
at De La Rue sites interface to the De La Rue services for card,
temporary token and PUN production.
In all cases, the Pathway components are concerned with providing
the interface between the Pathway Central Services and the other
organisation’s services. They do not provide significant independent
application functionality.
In all cases, routers are managed by Pathway Network Management
(see 8.5) and interface PCs are managed using Pathway System
Management (see 8.3).
DSS Service Environment Domain
The DSS Service Environment Domain is illustrated in figure 6-1.
Pathway
Boundary
—, EDS I Pathway
ICL Series 39 System
DSS Partition ™: Pathw ay Partition Boundary
DSS applications! Pathway Access -
CAPS or ESNS Service Firewall
—r I~T1_
Local LANs Routers
[To Pathway
DSS/BA site
Figure 6-1 DSS Service Environment Domain
Data Centres
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 69 of 117
FU.
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
FUJ00087993
IJ00087993
The DSS Service Environment Domain provides the interface between
Pathway and the Benefit Agency's CAPS and ESNS systems at DSS
sites.
In both cases, applications in the Pathway partition of the VME
machines (the VME part of the CAPS and OBCS Access Services)
handle:
¢ The transfer of information to/from the DSS partitions. An exchange
of information about the files transferred (or on-line transaction)
across the interface is used to check that the data sent is what is
received.
e The transfer of information between the Pathway Services on VME
and the Service at the Sequent operational system at the Pathway
Data Centres.
¢ On-line transactions from DSS/BA staff to PAS.
These interactions are automated, so do not require human
intervention in the Pathway partition of the VME machine. For on-line
transactions from CAPS, the CAPS transaction is passed to an Oracle
client in the Pathway partition which in turns calls PAS/CMS on
Sequent in the Pathway Data Centre.
As well as the Pathway partition of the VME platform, this domain
includes the Pathway routers used to route traffic to/from the Pathway
Data Centres. These are managed by Pathway Network Management
as described in _.
Roles
The DSS VME systems are run by EDS, so EDS are responsible for
the main systems administration of them (including their split into
partitions and resources allocated to these partitions) and the
engineers analysing/repairing hardware or base software errors
including those which involve the Pathway partition. This is not a
Pathway responsibility, so is not covered by this Access Control
Policy.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 70 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
DSS BA and DSS Help Desk staff are indirect users of the Pathway
VME partition. The CAPS on-line transactions pass through to
PAS/CMS, though have no access to facilities at the Pathway VME
partition. These users are authenticated to the DSS systems; Pathway
accepts and carries out these transactions without further
authentication of these users. (Pathway trusts any on-line transaction
from DSS via the agreed interface. The DSS system will have
performed the required access controls for these users, for example, to
ensure DSS Help Desk staff are restricted to enquiry only access.) At
the interface, the DSS/BA member of staff is identified by a transaction
id which is used for Pathway auditing.
Pathway roles at the VME partition are:
e Operational management and application support roles for the VME
partition, including monitoring. This is carried out from a secure
Pathway site using interactive (MAC) access via Sonnet on
Sequent. The users will have been authenticated individually to
others systems - see section 8.
e The Key Custodian who installs and updates the Red Pike
cryptographic keys used to protect the transfers of information from
CAPS to the Pathway Data Centres (at least the trailer record giving
the file totals and the checksum). This role is done by EDS at the
local DSS site.
All users of the VME Pathway partitions will individually identified and
authenticated using the VME Enhanced Security Option.
6.1.2 System Access Controls
The Pathway VME partition has its own filestore separate from other
partitions. This filestore is set up to separate data with different access
requirements and profiles are also used to restrict access as needed to
conform to the policies in section 3. Transfer of data between the
Pathway partition and CAPS/ESNS is restricted to transferring files
to/from the special transfer usernames using the XPERT product.
6.1.3 Control of Traffic between VME and the Data Centres
All traffic between VME and the Pathway routers is OSI based so the
routers handle bridged OSI traffic. The router LAN interface should be
configured with Access Lists at two levels. The first should provide a
MAC filter, so that only the Ethernet address of the EDS firewall router
and the other router are allowed as source addresses. The second
should provide an IP filter, so only the IP address of the other router is
allowed as a source (for network management traffic).
Permitted connections between Pathway Data Centres and the DSS
site are:
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 71 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
¢ File transfer between the relevant VME service and PAS/CMS and
OBCS on Sequent.
e¢ SQL*Net traffic supporting the CAPS on-line service
e Interactive (MAC) access for management, support and auditing
e Network management traffic to the routers.
6.2 POCL and POCL Clients Domain
Pathway has links to POCL and POCL Client systems. These are:
e The POCL TIP system to which records of transactions at Post
Offices are sent. This link is also used for Royal Mail traffic
e The associated POCL system which provides reference data about
Post Offices and for EPOSS applications and shares the TIP link.
e The POCL Host Automated Payments Service (HAPS) which
processes Automated payments on behalf of POCL Clients. This will
be replaced in future by:
e Links to POCL Client systems for automated payments.
At each site, there are Pathway PCs and routers connected to the
POCL or POCL Client systems there as shown in the following
diagram.
POCL or I Pathway
POCL Client I boundary
\ Host system
POCL or 1 t
IPOCL Client ' ‘Router (&
systems \ Pathway sometimes:_Interface
interface PCs I firewall) I PC I
firewall LL,
I [Routers I Pathway Data Centre
outers
POCL or POCL Client site
other Data Centre
Figure6-2 Pathway components at POCL Sites
The Pathway PCs at the POCL and POCL Client sites handle file
transfer to and from the Pathway Data Centres. Differences between
these sites are:
e The TIP/Reference data link is via the Energis network
e the HAPS link is a leased line with protection provided by encryption
boxes
¢ The POCL Client links are expected to be ISDN ones with an ISDN
card in the Pathway interface PC, rather than a separate router.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 72 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Cryptographic protection of the links is outlined in 8.10 and defined in
[SFS].
6.2.1 Roles
Once configured, the PCs and routers at these sites will not normally
have any human access as applications are automated and the PCs
are managed remotely using Tivoli. Pathway roles supported are:
Role Main function
Key Custodian Installing new keys and changing keys (for
(Pathway) systems where file transfers are encrypted)
Key Handling (POCL Re-installing keys on re-booting PCs (for systems
or POCL Client) where file transfers are encrypted)
Operational Limited, local system administration functions
management
Engineer Installing or replacing PC. The PC will not be
repaired when configured into the operational
system.
6.2.2 Control of Connections to the Pathway Data Centres
Traffic is permitted between the Data Centres and these sites is:
¢ The file transfers between Pathway hosts (TPS, Reference Data
and APS) and the POCL/POCL Client systems
¢ System Management traffic to manage the PCs using Tivoli
e Network management traffic for router management
In all cases, traffic is controlled by routers (and firewalls for ISDN links)
at entry to the Data Centre which will restrict the traffic to that
permitted. The Pathway router at the POCL sites accepts only this
traffic.
6.2.3 Control of Connections to POCL Systems
Access from the POCL systems is by file transfer. Controls at the PC
will ensure separation of incoming and out going files so that all files
supplied by Pathway are read only for POCL access. In addition, files
for different systems (e.g. TIP, Royal Mail and Reference Data) are
separated.
6.3 De La Rue Card Services Domain
The De La Rue Card Services Domain is illustrated in figure 6-3.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 73 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
De La Rue I Pathway Host system
boundary ' t
firewall —7 PC
De La Rue : Pathway
systems interface PCs f .
N Wa ‘SDN lin I Pathway Data Centre
other Data Centre
'
1
Router & I_I Interface I '
1
1
Zip media
De La Rue site
Figure 6-3 De La Rue Card Services Domain
Files of data for card, PUN and temporary token production are
transferred from CMS on the Sequent machine at the Pathway campus
to a PC at the campus. They are then encrypted and transferred via
ISDN to the Pathway PC at the De La Rue sites where they are
decrypted as described in [SFS]. Information is transferred between
the Pathway PCs and De La Rue systems by being written to/read from
Zip drives to provide a secure air gap between the systems.
De La Rue operations take place using secure systems in a secure
site. De La Rue information system controls and procedures protect
the information there.
6.3.1 Roles and System Access Controls
Roles supported on the Pathway PCs are as in 6.2.1 above (plus the
operator who physically moves the tapes). De la Rue perform the Key
Handler role.
Control of traffic between the De La Rue site and the Data Centre is as
in 6.2.2 above.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 74 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
PATHWAY CORPORATE SERVICE DOMAIN
7.41 Introduction
This domain contains Pathway’s own processes for managing and
supporting the business. These include:
e Fraud Risk management (FRM) - both Pathway and DSS
e The Payment Card Helpline which supports users, POCL, DSS and
customers, by handling calls about cards and payments
¢ The Business Support services which handle financial
reconcilations
e Business Function and Security Event Auditors
e Security Management
e Other management processes such as accounting, monitoring
service level agreements and asset management.
Management Information Systems support many of these management
processes. However, some of these Pathway Corporate users also
require access to other systems. This section covers, therefore both
the Pathway Corporate users (and their access controls) and the
Management systems which support them (and how they are
controlled).
7.2 Workstation Controls
Most business management and support users are located at a
Pathway management site (such as Feltham), except for some FRM
staff, the Payment Card Helpline and key custodians and handlers.
Workstation controls at management sites are shown in the following
diagram.
\ Pathway Management site limited management users
ICL Corporate
Network etc
Security, Audit and FRM users +
management & business support users
LHL
secure LAN
outer and
kecure serversI
crypto box
Data Centre system(s)
Figure 7-1 Management user workstation controls
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 75 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
7.2.1.1 All users who have access to sensitive data at the Data Centre or
update any information there (e.g. Management support users
updating Business Object Universes) must access the system from the
secure LAN which is in a physically secure area restricted to permitted
users.
7.2.1.2 All such users should authenticate using a token.
7.2.1.3 All workstations on the secure LAN at the Pathway management site
are controlled NT workstations set up to Pathway standards. These
restrict access to permitted functions for that user and have floppy/CD
drives disabled for booting, except where exceptions are agreed.
The current agreed exceptions for management and support users is
that some of these users have write access to CDs to allow information
to be put on CD for transfer to DSS and/or POCL. This is permitted for
the Management support role (see 7.8) for providing agreed
warehouse data, for the FRM supervisor (for providing information to
DSS FIT) and for the Business Function Auditor (for providing
information to external auditors)? [In future, some transfers of data,
e.g. to DSS FIT, may be via an encrypted link, not CD.]
7.2.14 Limited (read only) access by some management users is permitted
from the main Pathway network at the management site to
management services, such as the Service Level Agreement
Monitoring system (SLAM), at the Data Centre. This is subject to
controls at the Feltham network (see 8.x) and is restricted to where the
services at the Data Centre are not on the main operational or
warehouse machines and the firewalls and routers restrict this access
to the required services on the particular management machine.
7.2.1.5 Where users (particularly the Payment Card Helpline and Girobank
FRM) are located at the Pathway Data Centre sites, the links to the
Data Centres do not need to be encrypted, as the users are not
remote.
7.2.16 DSS FIT staff may access the FRMS service from their own site.
Remote access should be from a secure DSS area, using controlled
NT workstations, via an encrypted link.
7.2.1.7 Servers at the management site which require strong security, such as
the CM signing server and reconciliation database, should be on the
secure LAN
Sections 7.3 to 7.8 outline the access controls for Pathway Corporate
roles which involve systems other than MIS ones. Note, however, that
controls for a user at a particular service or system are defined in the
section for that service. Section 7.9 below gives the access controls
associated with the Management Information Systems.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 76 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
7.3
Fraud Risk Management
Fraud Risk Management is concerned with identification, monitoring
and management of fraud associated with/relevant to the ICL Pathway
system. Both the Girobank Fraud Risk Management (FRM) staff at
Bootle and the ICL Pathway FRM staff at Feltham use the same
services i.e.
e Regular reports on aspects of the system which are relevant for
fraud e.g. weekly trend analyses and daily exception reports and ad
hoc selective reports according to agreement.
e Access to the Fraud Case Management System (FCMS), both to
create and maintain cases originated by Pathway and to read case
data about cases originated by DSS Fraud Investigation Team (DSS
FIT)
Most FRM access to Pathway is to the Data Warehouse and the
FCMS applications. In exceptional circumstances, FRM staff may
require access to other Pathway systems in order to investigate a
potential fraud. These are currently expected to be:
e The PAS and CMS data. This is expected to be mainly to the
archives, not the operational system, except in exceptional
circumstances.
e The TMS journal of Post Office activity
e Data transfer logs
DSS FIT staff can create and maintain their own cases in the Fraud
case database and have read access to cases originated by Pathway
FRM staff. Any other information they require is obtained by the
Pathway FRM staff - both regular reports and specifically requested
information.
The following table lists the FRM Roles.
Role Functions
Pathway FRM Investigating fraud cases using FCMS, Data
Manager Warehouse information, and where needed,
operational systems including TMS and PAS/CMS.
Supervisor of FCMS and also FRM Business Object
universes, so create/expire users in FCMS
Setting flags for transactions in FCMS (code user).
FRM Analyst Investigating fraud cases as FRM manager
(an ICL Pathway (including access to Data Warehouse, TMS etc)
role) FRM supervisor functions as FRM manager
FRM users Handling fraud case information in FCMS
(ICL and Girobank _I Read only access to Data Warehouse information in
FRM staff) support of investigations.
DSS Fraud Read and update access to cases initiated by DSS
Investigation Team I FIT; Read only access to cases initiated by Pathway
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 77 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
(DSS FIT) FRM staff.
Access to extracts of Data Warehouse information
(extracted by Pathway FRM staff.); no direct DW
access
Access controls at the various data centre systems are in the
appropriate section - 7.9 below, and also parts of section 4, when they
have access to central services. All these users access the system
from controlled workstations on protected links - see 7.2. In some
cases, FRM Manager and Analyst may use facilities similar to the
Business Function Auditor.
Fraud investigations will also include collection of evidence. Some
evidence will be collected by requesting information from other users,
rather than direct FRM staff access.
7.4 Payment Card Helpline
The Payment Card Helpline is run by Girobank at the central Pathway
sites. It handles the following types of calls:
¢ Calls from Post Office counter clerks about payment authorisations
and cards. Some of these can initiate changes to the PAS/CMS
database, for example, to stop a card, encash a payment (under the
responsibility of the Post Office clerk)
¢ Calls from customers about card problems (some of which could
result in stopping cards), and more general queries
e Calls from DSS/BA, some of which can result in stopped payments,
stopped cards
¢ General calls from the public, for example, reporting finding a card
Helpline Advisors use the PAS/CMS database when responding to
telephone calls. (They also have access to local on-line
documentation, such as the procedures they must follow, from local
Helpline NT servers.)
7.4.1 Roles and Associated Controls
People in the following roles have access to PAS/CMS:
e Helpline Advisors using authorised transactions in response to calls
¢ Helpline Advisors (NSI) who can handle data with a National
Sensitivity Indicator
e Helpline Supervisors who can act as advisors, but also perform
extra transactions (and have extra local functions)
e Helpline Manager who can perform the same role, but has further
local functions
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 78 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e Helpline Security Manager who maintains information about the
Helpline users both at PAS/CMS and at the local system
In all cases, Helpline users with access to PAS/CMS use controlled NT
workstations with floppies disabled. They log onto the local Helpline
controlled NT domain with an individual username and password and
local profiles control what local functions they can do according to role.
This controls which Helpline staff can use which Oracle Forms
applications for accessing PAS/CMS. These workstations also provide
access to some local functions (e.g. viewing on-line documentation),
but not to external services.
Access to PAS/CMS is also controlled by the PAS/CMS servers (see
4.3.1) which require the users to log-on to Oracle and then restrict
what tables Helpdesk users can access. Note, however, that as
Helpline users have update access to some PAS/CMS data, the
controls on the Oracle Forms applications at the workstations are
needed to prevent update access to other data in those tables.
A set of dedicated workstations are used for training activities
accessing the training database at the Data Centre.
7.4.2 Other Access Controls
The Helpline system is a controlled network with routers controlling all
access in and out. This is limited to:
e the Pathway Data Centres - for PAS/CMS access and information
about telephone calls to the Data Warehouse
e between Helpline sites and
e to the Rockwell ACD and associated servers. (Information is fed
from the Rockwell ACD to a specific PC on the helpline network so
that telephone traffic may be monitored.).
7.4.3 Authentication of Callers
Contact is made with the Helpline Advisors from Counter clerks, the
Benefit Agency and customers by phone as detailed in the call matrix
in [CHDM]. There will generally be a need for the caller to provide
some level of authentication that they are who they claim to be.
Note: the procedures for handling telephone authentication are not yet finalised in allI
cases.
Contacts with these people are shown in the following table.
Contact I Function How authenticated
Customers I Queries and reports Response to a number of
about cards, PUNs. e.g. I verification questions asked by the
Printed: 22/12/98 RESTRICTED-COMMERCIAL.
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 79 of 117
FUJ00087993
IJ00087993
FU.
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
card lost or damaged. Helpline Operator as specified in
[SADD].
Members I Reports such as found __I No caller individual authentication
of the card normally (as the caller may not be
public known to the system). However, the
caller may be asked further
verification questions depending on
the type of call.
Staff at Get payment details and I Correct responses to questions
Post extended verification based on information held at the
Office e.g. for foreign Helpline about Post Offices - see
encashment. section 3.5.2.
Reporting on failures &
anomalies
PO staff I Queries and reports As above for verification of Post
on behalf I about cards etc Office staff plus customer
of verification information.
customer
DSS/BA Enquiries on cards, Correct responses to questions
payments. Request to based on information held at the
stop cards, payments Helpline about DSS sites/people.
etc
BA for As customer queries and I See above for verification of BA
customers I reports staff, plus customer verification
information
7.5 Business Support
Pathway Business Support staff handle financial reconciliation when
there is a Pathway problem, for example a service breakdown. There
are two types:
e Reconciliation incidents for DSS benefit payments.
This role requires access to information about customer payment
authorisations and Post Office transactions at operational services.
(Where larger volumes are concerned, relevant data may need to
be downloaded at the request of Business Support to the SSC.
reference system (see 8.7) and a flat file of transaction adjustments
generated there for forward transmission to the Data Centre and
back to CAPS by SSC.)
e Reconciliation incidents for in the Automated Payments Service for
other POCL clients.
The same BSU staff handle both sorts of reconciliation incidents.
Roles are:
Role Functions and resources accessed
Business Support Investigating incidents, and inserting or adjusting
Analyst payment records (but not finally authorising them.)
Analysts therefore have access to PAS/CMS, TPS
etc and also to the reconciliation (RED) database - a
Printed: 22/12/98
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
RESTRICTED-COMMERCIAL
Page 80 of 117
FU.
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
FUJ00087993
IJ00087993
7.6
7.6.1
secure server at the management site.
Business Support Inserting or adjusting payments and authorising
Manager them, subject to agreed procedures.
The BSU Manager has access to all the systems
available to the Analyst
Notes:
1. BSU staff are located at a Pathway management site and access
the Data Centre systems via secure workstations using tokens - see
7.2. All update access is via specific Oracle forms applications.
1. These same controlled workstations should also be used for access
to the RED database, as this holds DSS Restricted data
1. Services accessed for DSS payment reconciliation include
PAS/CMS and OBCS, and TMS
1. Services accessed for APS reconciliation are APS and TPS
Auditing
Pathway activities are audited to ensure they are functioning correctly,
for example, that the controls in the system are working effectively.
Within the Pathway project, two types of Auditors are distinguished:
e the Pathway Business Function Auditor responsible for overall
auditing of the system
e the Pathway Security Event Auditor
The external (POCL, DSS and NAO) Auditors are mainly concerned
with auditing the business transaction of the system such as the
processing of payment authorisations and customer information and
the transactions at the Post Office. The Pathway Business Function
Auditor provides the interface to external auditors for access to
Pathway Data Centre systems, accessing these systems on their
behalf to provide the information they need.
Overview of Audit Information Accessed
Auditors requires access to information in the audit tracks defined in
[AUDT]. Security Event Auditing is concerned with auditing all access
to the Pathway systems, including that by Pathway operations and
management staff. The main activity is monitoring, though on
occasions, more active investigations are expected. Business Function
Auditors also have access to audit logs, though they will be looking at
different information in them.
Audit logs include:
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 81 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e Operational and management logs of business transactions such as
the Riposte journal which records events at Post Offices and the
PAS and CMS logs (including records of Payment Card Helpline
transactions)
e Logs recording system level activity at Pathway Data Centre
systems such as user logon and administration and other security
relevant events including system, network and firewall management.
e Logs at relevant Pathway internal systems.
e Archives of these at the archive server retrieved from the Legato
tapes there
e Manual records associated with IT access.
Many events are collected centrally using Tivoli (via Patrol and
Openview where needed). The technician monitoring the systems
management workstation will alert the Security Event Auditor of
specified types of significant events. However, some event records will
remain in local audit logs.
The Security Event Auditor will need to be able to access/extract audit
data from all these - see the following diagram.
I
Pathway System oO
yy Sy extracted ys By
data data
Business Function
[ Auditor
software generating ert,
audit records trails archive &— >
T service audit
v archives
Tivoli Event Service
Selected audit data a
G oO alert noti Security
ltr Event Auditor
Manual records
System Management technician
monitoring events
Figure 7-2 Auditor access to audit information
The Business Function Auditor mainly uses information to the archive
server and to information extracted from other systems, though has
limited access to other systems
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 82 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
7.6.2 System Access Controls
Auditors can access the logs at Pathway systems described above by
tools/clients at the audit workstation. The auditors are registered at
each system/domain accessed and can access only the audit logs
there as included in the relevant sections. Note that Auditors will not
have direct IT access to:
e Post Office systems: however, all Post Office transactions (including
user authentication) are recorded in the TMS journal and other
relevant system events are picked up by the Tivoli Event system or
¢ The Payment Card Helpline systems: all interactions of the Help
Desk users with the Pathway systems are recorded in the Oracle
logs on Sequent.
¢ The interface PCs at POCL and De La Rue sites: management of
these will be recorded in the Tivoli logs
Both Business Function Auditors and Security Event Auditors access
the Data Centre systems via controlled workstations on the secure
LAN in Feltham (see 7.2 above) or a similar workstation at the Data
Centre.
7.7 Security Management
Pathway Security Management are responsible for Security Event
Auditing of Pathway (see 7.5 above) and also:
e¢ Management of the cryptographic keys used in Pathway
e Management of the Security tokens used for authentication of some
users (see 3.4.2.5)
and other security matters.
7.7.1 Cryptographic Key Management
Several of the Pathway systems require a cryptographic key to be
installed and periodically changed. These keys are used to
encrypt/decrypt or sign/verify data in transit between sites. Some keys
are generated by the Pathway Key Management Service (see 4.6).
Others are obtained from CESG.
Keys may be distributed electronically (for example, to Post Offices).
However, at some systems, the cryptographic key (or part of it) must
be installed manually. This is the case, for example, on the following
systems:
e The BES agents. These have the private key for signing payment
authorisation for transmission to the Post Offices.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 83 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e Systems using Red Pike encryption of data on links e.g. the
Sequent system for the link to CAPs and the PCs handling the links
to De La Rue.
e The Zergo boxes used to encrypt certain links such as the Data
Centres to Pathway sites such as Feltham and Stevenage.
All keys are managed in accordance with the policies in 3.6.
The cryptographic key management roles are as follows:
Role Main functions
Cryptographic Key Generating or obtaining cryptographic
Manager keys and organising their distribution.
Cryptographic Key Initial installation of cryptographic keys
Custodian where this needs to be done manually.
Periodic update of these keys.
Cryptographic Key Handling part of a split cryptographic key
Handler when this needs to be re-installed e.g.
when a system is rebooted.
PO key recoverer Initiating recovery of a Post Office key
from the Help Desk after it has been lost.
The Cryptographic Key Manager and PO key recoverer roles access
the IT system at the central security services only, so their access
controls are described in 8.3.
All Cryptographic Key Custodians and Key Handlers access the
systems in a similar way as defined in the following table.
Role Workstation Authenticatio I Resources available
type & location I n method
Key console at the NT (or UNIX) Functions to install and
Custodian _I platform with key I with token change key
Key None None Media containing key
Handler during re-installation of
key.
7.7.2 Management of Security Tokens
There is a single role here - the Pathway Security Manager (PSM)
who maintains the records of tokens, PINs and users.
The PSM uses a controlled NT workstation on the secure LAN at the
Pathway management site (see 7.2) and has access to the Token
Authentication Service at the Data Centre (see 4.6.2). Functions
available to the PSM are:
e maintaining information about tokens and their associated PINs, and
whether, and to whom, they have been allocated
e maintaining information about users who have tokens
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 84 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
The PSM is also responsible for the procedures to handle tokens
which have been lost, stolen or withdrawn from use, and procedures
for the security of handling PINs, so these do not allow unauthorised
access to the system.
7.8 Other Management Users
The following Pathway general management users have access to MIS
systems (see 7.9), and no other, Data Centre systems. Their access
controls at those systems are therefore included in that section. (Their
workstation controls are in 7.2 above).
Role Main Functions
Pathway Management I Managing the set-up of the management
support information services (e.g. setting up Business
Object Universes and associated controls).
Providing information to other Pathway
Management users on request
Also, providing the POCL and the DSS/BA
interfaces for management information - including
provision of management data regularly and on
request.
7.9
Pathway Financial
Use of finanical management information in the
Management Common Charging System (CCS) and elsewhere
Pathway Contract Use of contract management information in the
Management Contract Management system (CON)
Pathway Reference
Data Management
Use of reference data in the Data Warehouse
Pathway Customer
Access to the SLAM cache on NT
Support (CS)
Managers
Pathway Business Use of selected Data Warehouse information in
Development development of the business
All users except CS managers use controlled NT workstations on the
secure LAN at the Pathway management site - see 7.2. Pathway
Management Support users have writable CDs for generating
information for POCL and DSS.
The Management Information Systems (MIS)
There are two Sequent platforms at the Data Centre supporting
Management Information Services; one is the Data Warehouse - the
main information repository for Pathway corporate services. There is
also an associated NT server. These MIS and Fraud Risk
Management services are illustrated in figure 7-3.
Printed: 22/12/98
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
RESTRICTED-COMMERCIAL
Page 85 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
TMS __PASICMS Refe Call info from ete
journal Data data help desks
QeeeI! cof a
MIS Services (Sequent and NT)
Pathway
Management Query/Reporting Services Security
(several roles)
Pathway
via Business Objects
——
2
Mgt Support
Pathway
Business Support
‘Accounting, Asset management
Fraud Case Management System
Management
System and
Operational
Contract management (CON)
Management
& Engineers
Fraud Risk
Management = 7
SLAM cache (on NT) Application
Pat hw ay ——— Suppor
Auditors ——I Financials (not at Centre) HHO
Figure 7-3 MIS Systems
The Pathway Management Services include generating invoices for
the Contracting Authorities (using information derived from the
operational system), monitoring Service Level Agreements on the
performance of the Pathway solution, business development
applications (providing aggregates and summaries to identify sales
trends and customer habits) and Accounting and Asset management.
Data is fed automatically from other Pathway systems to the Data
Warehouse including:
e Data from TMS journals about Post Office transactions (see 4.8).
e Data from the Reference Data Management System (see 4.7)
e PAS/CMS data (see 5.2)
¢ Information on calls to the Payment Card Helpline. This consists of
Rockwell ACD data (see 5.3) and Mercury data.
e Information on calls to the Horizon System Help Desk. This consists
of Mitel ACD and BT data.
Much of the output of this system is by using the particular services.
These provide the management information required by Pathway and
the outputs required by DSS and POCL. There are automatic feeds
from Data Warehouse Services to the ElS/Financial service and to the
Service Level Agreement Monitoring service (SLAM cache) which is on
an NT system at Wigan.
Printed: 22/12/98
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
RESTRICTED-COMMERCIAL
Page 86 of 117
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
7.9.1 System Access Controls
Both Sequent MIS systems are managed in the same way as the other
Sequent systems at the Data Centres, though there is some
differences in support due to the different applications run on the MIS
systems. So the roles defined in 4.2. above (operational management,
database support, application support, auditors etc) are also used
here, except for the VME related roles in 4.2. Note that some of these
include application/database roles, for example, for Auditors.
The NT server is managed as other NT servers at the Data Centre (so
supports the roles defined in 4.4) except for management specific roles
and data flows.
Database roles with appropriate database views/tables are used to
separate what data is available for what use. Information available to
people doing ad-hoc queries is further constrained using the Business
Object “universes” to provide restricted views of the Data Warehouse
and other MIS Oracle applications.
The following table shows the application specific roles for the MIS
systems. In all cases, users have authenticated to their local NT
systems prior to access to the MIS system.
Role (and section I Authentication I Resources available
where defined) method at MIS
FRM Manager Oracle/Busine I Access to all FCMS case
(7.3) ss Objects information; create/expire users
(FCMS supervisor), setting FCMS.
codes (FCMS code user).
Access to Data Warehouse
information, both predefined and ad-
hoc queries. Administration of FRM
Business Object universes (see 7.3)
FRM Analyst (7.3) I As above Full access to FCMS except code
user.
Access to Data Warehouse
information as for FRM Manager
FRM User (7.3) As above Access to FCMS case information;
Read only access to Data
Warehouse information
DSS FIT (7.3) As above Access to case information (but not
Pathway specific information)
Access to extracts of Data
Warehouse information (extracted
by Pathway FRM staff, and made
available to DSS FIT) - no direct
Data Warehouse access.
Pathway Token plus Business Object Universes
Management application (including supervisor functions);
Support (7.8) authentication I Read and update access to agreed
Printed: 22/12/98 RESTRICTED-COMMERCIAL.
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 87 of 117
FUJ00087993
FUJ00087993
ICL Pathway
Access Control Policy
FU.
Ref: RS/POL/0003
Version: 3.0
Date: 18/12/98
FUJ00087993
IJ00087993
MIS data including CON, SLAM,
BPS;
Data required for download to
workstations for reports (pathway,
POCL, BA)
Development (7.8)
Pathway Financial I As above Access to Common Charging
Management (7.8) System (CCS) and other financial
information
Pathway Contract I As above Access to CON service
Management (7.8)
Pathway Ref. As above Access to DW reference data
Data Management
(7.8)
Pathway CS Read only access to SLAM cache on
Managers (7.8) NT only
Business As above DW: read only access to Post Office
information
7.9.2
Control of Connections
All access to the MIS systems at Wigan from outside the campuses is
by encrypted links.
Access to the system is constrained to the agreed data feeds,
management and audit use and output to the ElS/financials system.
Printed: 22/12/98
RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 88 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
SYSTEM MANAGEMENT SERVICES
DOMAIN
8.1 Introduction
This Domain includes services for:
e Management of the systems in all Pathway domains. There are two
main types of system management:
e Managing the Post Office systems and related Data Centre
NT systems (mainly using Tivoli products)
« Managing the Sequent Data Centre systems (and the
Pathway VME partition). While this mainly uses Patrol and
other tools, events can still be reported into the Tivoli
management system.
e Network Management - managing the routers and firewalls which
control traffic into, out of and within the Pathway network. Routers
are managed using Open View at the Network Management Station
and firewalls managed by the Enterprise Centre.
e Software and Configuration information distribution, both for roll-out
and auto-configuration of new Post Offices and release of software
updates from the Pathway Configuration Management system to all
systems including Post office and Data Centre ones.
e Application support for services in all domains (though access
controls for particular services and systems are given with the
controls for that system).
e Support of specific hardware not covered by other sections such as
symmetrix discs.
e The Technical Help desks which support this - the Horizon System
Help Desk which is the main technical Help Desk and the Roll-out
Support Desk supporting the Implementation process.
Access controls associated with each of these are covered in the
following subsections. The last subsection describes the network
access controls which the system/network management achieves. It
outlines the network and the positioning of controls in it, and then the
access control policies for it.
8.2 Outline of System and Network Management
The following diagram illustrates the main components of system
management during operational use of the system. (Roll-out is covered
in section _).
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 89 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
PO counters @, oe
Crt 7 rm Engineers
ete ig NX &
Horizon System “0 = System Management Centre
Help Desk - most software & operational problems
SMC—> SSC ete
Tivoli (mainly NT)
Software Distribution
Software Inventory
Event Management
Resouree Management network
Config’n Management management
system/ an,
operational E
management E
R s
Maestro s R HP OPENview I Enterprise
job scheduling J& Cisco Works I I Centre
on Solaris _I Ion Solaris
Sequent Maehine coi 7 NF Systems NT l I
running ICorrespondence I I Post Office Saee can
PAS/CMS, MIS bel Servers ete counters :
Figure 8 - 1 System Management Service Domain
In the figure,
e E- shows event management - Tivoli manages events either directly
(as with the Correspondence servers and Post Office counters) or
indirectly (via Patrol at the Sequent systems)
e R-shows resource management such as performance and capacity
monitoring (for Sequent, inventory management)
e S-shows software distribution from the Tivoli server. (Distribution of
software from the Pathway Configuration Management system is in
8.6.)
The Tivoli Management Environment (TME) provides Event
Management, Resource Management and Software Distribution. In
some cases, this is done directly by Tivoli at the Pathway Operational
systems. This is the case for the Correspondence servers, for all Tivoli
servers (some of which are on UNIX systems) and other NT boxes at
the Pathway Data Centres. However, for the Sequent machines (both
operational and management ones), most management is done using
Patrol with events selectively being passed onto the Tivoli Event
Management System. Similarly, Open View and Cisco works are used
to monitor and manage the routers, but send events selectively to
Tivoli.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 90 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.2.1
Management actions may be initiated automatically by System
Management software detecting threshold conditions and automatically
taking remedial actions. System management staff initiate actions as
follows:
e For planned activities such as distribution of a new software version.
e Where monitoring the events in the system shows action is needed.
e When a Technical Help Desks receives a call from external people
(e.g. Post Office staff) or Pathway staff (e.g. CFM operational
management staff) requiring action
System Management Workstation Controls
System management technicians have access to the Pathway Data
Centre systems in order to manage them. In doing this, some will have
the capability to update the systems (and potentially disrupt the
Pathway services). Some technicians will also have access to DSS
data where this is needed to investigate a problem.
Many of these technicians also need to use the call recording and
management systems used to record to process of technical incidents
from initial call to the Help Desk, through calling in the required experts
to investigate the problem to the final completion of any remedial
action to rectify the problem. The key tools used here are the
Powerhelp and PinICL systems.
Thus these users normally need access to both the Data Centres and
internal ICL systems. In this case, their access to the systems is as
shown in the following diagram:
System Management (or support) secure site
ICL Corporate
7] 4 4 4 \ AWNetwork ete
M7] secure LAN
‘outer and
crypto boxF
Pathway Data Centre
router and
crypto box
Data Centre system(s)
Figure 8-2 system management workstation/network controls
The technician often has two workstations connected to separate
networks:
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 91 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e an NT workstation configured to Pathway standards and connected
to a separate secure LAN. Apart from other management
workstations for other technicians, this LAN is connected only to the
Data Centres via routers and cryptography boxes. All traffic between
the secure LAN and the Data Centres is encrypted. The NT
workstations have floppy drives disabled.
e if needed, a workstation connected to other systems such as the
Powerhelp and PinIlCL systems used for tracking technical
incidents.
Where the incident tracking systems use networks outside the
Pathway controlled area, for example, the ICL corporate network,
information recorded on it associated with an incident may refer to
a particular record of DSS customer data, but will not include such
DSS data, unless adequately protected, for example, by encryption.
System management and support technicians work in physically
secure areas.
In the rest of this section, only the controls associated with the NT
workstations which can access the Data centres are included.
All system management users managing Data Centre systems
authenticate using a token.
8.2.2 Procedures for getting in Support Staff
A number of problems can lead to staff being required to support the
system. This could be CFM or SSC staff coming in to support the
system from their normal support sites. However, it could also require
support staff from other organisations such as Oracle or Cisco. CFM is
generally responsible for the call out procedures.
8.2.2.1 All requests for technical support should be made to the Horizon
System Help Desk. The identity of the caller requesting support (if by
telephone) should be verified to ensure the call comes from an
appropriate source, so should be acted on. The Help Desk will pass on
the call to the appropriate unit in line with Help Desk Procedures using
the call handling system.
8.2.2.2 All support calls should be recorded in the call handling system and
their progress reported there, including who was called out and the
actions taken.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 92 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.2.2.3 Routers will by default be configured to prevent access from support
8.3
organisations other than the standard ICL Outsourcing sites supporting
Pathway. When support is required from another authorised site (e.g.
Oracle or Cisco), a router should be configured to allow this access,
and then re-configured to disallow it after use.
System Management of NT Systems
System Management of NT systems is done using Tivoli. This includes
managing the Post Office counters, NT servers at the Data Centres
and interface PCs in interface domains. Support is also provided for
special Post Office cases such as lost passwords. Other Pathway
people such as auditors and application support also access Tivoli for
information. The main interactions of the people involved are
illustrated in figure 8-2.
Counter clerks
DSS &,
CFM etc
Horizon System
Help Desk
4 Tivoli client
)I bystem management
System Admin
NT Workstations —}——. Engineers etc
NT Systems
Security Services
for PO support
SMC Technician
(incl SMC Help Desk)
Tivoli
exchanges
Tivoli System Management Servers I Auditors
software for_,I
distribution
auto-cont ig
information
at Pathway Data Centres
Application
NT TMR servers
\Sofiware distribution
Tivoli users admin
Sun/NT servers
Event management
Hardware & software
inventory
Support
I_ Operational
Management
stant Systems
e.g. Post Offices, correspondence servers
Engineers
Figure
8-3 Interactions for Tivoli System Management
SMC technicians perform system management activities because:
e System management actions have been planned, for example, the
distribution of software or the implementation of Post Offices.
e Monitoring of the system identifies some action is needed.
e The Horizon System Help Desk passes on a call about a technical
problem wi
hich requires resolution.
Software is sent to Tivoli from the Configuration Management system;
Post Office configuration data comes from the Auto-configuration
database (see 8.6). In both cases, SMC technicians control onward
distribution o'
f the data.
Printed: 22/12/98
RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 93 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
SMC technicians have two workstations - one with access to the call
handling systems including Powerhelp and a second which provides
access to Pathway system management services.
SMC Team Leaders also handle calls from the Horizon System Help
Desk to authenticate users at the Post Office using one-shot
passwords and to assist in key recovery as described in 5.7.
8.3.1 SMC and Roles at Tivoli Servers
The SMC system management roles with access to the IT systems are:
Role Main Functions
SMC Monitoring the system - software distribution, the auto-
technician or configuration process and other system management
technical events.
specialist For software distribution, select targets for distribution
from those authorised and report of progress.
Run pre-defined, pre-allocated tasks.
Raise alarms on pre-defined conditions
SMC technical I For software distribution, authorise targets for distribution,
team leader change priorities or cancel distribution and report on
progress.
Other system management tasks as SMC technician.
Authenticating users at the Post Office using one-shot
passwords as described in 5.7.
Assisting in Post Office key recovery - see 5.7 and 4.6.
SMC MSS Handle receipt of software and auto-configuration
technical information.
support Configure Tivoli event management - configure the view of
events by others and task event relationships and add
new Sentry monitors.
Create Tivoli tasks and allocate to SMC technicians.
System administration of the SMC workstations and Tivoli
servers (NT and UNIX systems) including
backup/recovery.
Security User administration - adding SMC and other users to the
Manager SMC domain and to Tivoli. Allocating users’ rights e.g.
roles, groups.
Pre-defined Tivoli tasks can be used for a variety of system
management tasks including Riposte administration at the
Correspondence servers.
There are associated manual processes to authorise some of the
actions above and to liaise with other Pathway units involved in
software distribution and auto-configuration. For example:
e Team Leaders and SMC Managers can authorise software
distribution.
e Only SMC Managers Can authorise creation of new Tivoli tasks.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 94 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.3.2
e All changes distributed via Tivoli first go through the standard
Configuration Management system with its associated processes for
change control, testing and authorises release
In addition to the SMC technicians listed above (and operational
management and engineer roles), other users have access to the
Tivoli servers as follows:
Role Functions
Pathway Auditor Monitoring the Pathway systems; Security Event
Auditors tracing security incidents in Tivoli or reported
via the Tivoli event system using the Tivoli event
archive database.
Pathway Support of Post offices counter applications using
application events collected via Tivoli.
support (SSC)
System Access Controls
The SMC workstations with Data Centre connections are in a secure
area on a secure LAN with floppy and CDROM drives disabled - see
8.2.1. All SMC staff using these workstations are authenticated to the
SMC NT domain and use a token. Authentication results in display of a
desktop which contains only those applications available to this user.
SMC technicians using Tivoli also authenticate to Tivoli (though this
results in use of NT authentication).
Other users of Tivoli servers such as Auditors and SSC application
support staff use workstations in different NT domains.
All users of Tivoli are registered at the Tivoli server and associated
with the appropriate roles, groups (and regions) to restrict their access
to facilities which they are permitted to access.
The operational management and engineering roles are as for other
servers at the Data Centre (see section 4), so is not included in the
following table.
Role Workst’n I Where user Resources available
& Location I defined;
Authentic’n
needed
SMC NT-SMC_ I NT and Tivoli user; I Tivoli/Oracle facilities
technician, secure NT authentication I for authorised
tech specialist, I area with token functions. (No
and team NT/UNIX tools)
leader
SMC team as above NT with token at PO recovery
leader: PO key SMC; also user of I application at KMS
recovery KMA
SMC team Specific NT user at specific I Specific application
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 95 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
leader: one- security system. only
shot password I system
auth.
SMC MSS as above as SMC technician I Tivoli/Oracle facilities
technical above for authorised
support functions. Authorised
NT/ UNIX tools.
SMC Security I as above as SMC technician I Tivoli and OS user
management above and role
administration
Pathway NT at NT and Tivoli user; I Read access to audit
Auditor- see Pathway NT authentication information via web
76 corporate with token interface- platform
site audit logs, Tivoli
notices, Tivoli events
collected for auditing
SSC NT at NT and Tivoli user; I Pre-authorised Tivoli
application P’way NT authentication I tasks to extract
support - see secure site I with token diagnostic information
8.7 (Bracknell) from the Post Office.
8.3.3 Controls on Connections
The NT workstations and networks which are used by SMC technicians
for managing the operational Pathway system are controlled as in
8.2.1. (Tivoli integrity features will also be used to protect Tivoli traffic
on the link).
All software, Tivoli scripts, configuration files etc sent by Tivoli to the
Post Offices are signed for integrity.
8.4 Sequent and Oracle Management
The components involved in the management of the Sequent systems
at the Pathway Central sites are illustrated in figure 8-3.
UNIX and
Oracle
Management
Security Management
Engineers
ele
a
Tivoli
Event Management etc
Even’ “/
bb
ps scheduling
Seqgent Machines
Patrol with TivoliI Maestro initiating
Event Adapter I Ijob scheduling jobs at
T [ Agents
PAS, CMS, MIS ete
on Oracle databases
Figure 8-4 Sequent, Oracle and VME management
Printed: 22/12/98
RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 96 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Patrol is used for system management of both Dynix and Oracle. Most
management is automated and so does not require human
intervention.
More “hands-on” operational management of the Sequent machines
(including direct UNIX and Oracle access) as introduced in 4.2 above
is used only when the automated management and Patrol cannot cope.
Maestro schedules jobs on both the Sequent machines and the TMS
Agents (when these are not scheduled as the result of data received).
The associated Maestro workstation is used for monitoring this and
taking action if needed. Most job scheduling is automated and so does
not require human intervention.
8.4.1 Roles and System Access Controls
System management related functions are system monitoring and
management using Patrol, Sequent system/operational management
and job scheduling and monitoring via Maestro. All these roles, and
associated access controls, are defined in 4.2 as they affect
management of the Sequent systems.
People carrying out these management functions from a remote site
use secure NT or Sun workstations via encrypted links, tokens etc as
defined in 8.2.1.
Access for staff on call is according to the procedures in 8.2.2 above.
8.5 Network Management
8.5.1 Introduction
The Pathway network routers are managed using HP Open View with
Cisco Works as illustrated in figure 8-4 below.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 97 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Data feeds e.g. , “ali
PO addresses & Events to Tivoli Date ott
keys on rollout ] 8 8
Network Manager Sun, UNIX t———__ Security Manager
- HP Open View
Network Technician System Administration
Cisco Works
Network Management
TACACS > Engineer
Configurer
Ged Ronee
Cisco Access WAN Routers
Servers routers at DSS ete
ISDN Adapter] PSTN connected Girobank DSS, POCL
at Post Office Post Offices areas & De La Rue
ete systems
ISDN
Routers
Figure 8-5 Network Management
All routers illustrated are managed using HP Open View. The solid
lines show the managed routers, rather than physical connections
(dotted lines show how routers outside the Data Centre are connected
to it).
Some events are automatically passed on to Tivoli so that the SMC
system management knows about the current state of the network.
However, this is for monitoring - Tivoli is not used to cause
management actions at the routers.
Audit logs are generated during normal running and provided to the
audit service.
On new Post Office roll-out, the (ISDN) addresses of the Post Office to
be rolled out soon are fed to the routers.
The main roles are:
e Network Manager responsible for configuration and management of
the routers
e Network Technician monitoring the routers
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 98 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e Network Management Configurer responsible for the configuration
of the Network Management Station itself, such as Open View
configuration. This role is carried out by the Network Management
team before live running.
The configuration will be validated by more than one CFM
technician and signed off by a senior CFM person before use.
e Cisco router support.
There are no on-line application support roles. Support of Open View,
Cisco Works etc is done off-line.
There is a single Network Management Station (NMS) at each
Pathway Data Centre.
In exceptional circumstances, network staff can use router facilities
directly via telnet, not going through Open View, and therefore not
subject to its controls. In this case, the user is authenticated using
TACACS on the NMS and auditing will still be carried out on the NMS -
see 8.5.4 below.
Engineers may also require direct access to routers - see 8.5.5.
There are also firewall management staff - see 8.5.6 below.
Zergo encryption boxes for protecting data on links are covered in 4.6.
Hardware and other support of the General Signals system to connect
the Symmetrix discs to the Energis network is given in section 8.8.
8.5.2 Roles at the Open View System
The following table lists the roles of people with direct access to the
Network Management Station.
Role (Organisation) I Functions
Network Monitoring the network
Technician (CFM)
Network Manager Monitoring the network.
(CFM) Updating router configuration information e.g.
- Post Office information e.g. ISDN address
- Access Lists of permitted addresses, protocols,
ports.
Updating information about routers available when
needed (including confirming bringing a mended one
back on line - see 8.5.5 below)
Network Configuring Open View e.g.
Management - what to display to whom
Configurer (CFM) - actions to be taken on certain events
Configuring Tivoli Event Adapter
Security Manager I Maintain user information for those users permitted to
(CFM) use this system - both UNIX users and Open View
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 99 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
users.
Local auditing of network management activities at
this system
System Any administration/configuration which cannot be
Administration done using the Open View, or Cisco Works
(CFM) This is expected to include operating system set up,
changes; software updates.
Engineers Diagnosing, repairing hardware faults
Note: Pathway auditors access audit information from the NMS via
audit records sent through to Tivoli and extracted audit logs.
8.5.3 Access Controls associated with Human roles
People in all these roles use the console at the machine for all access
to the Network Management Station. The following table shows how
the users defined above access the system and what is available to
them.
Role Workstation I Authenticat'n Resources
type/location I method & where available
user defined
Network console at OpenView Specified Open
Technician NMS userlogon View and Cisco
Works functions
only
Network as above UNIX & Open View I Open View and
Manager as individual user Cisco Works
network
management
functions (no direct
UNIX access)
Network as above as above Open View
Manag't configurer
Configurer functions
Security as above as above User information
Manager and resource
access controls
System NT at Belfast I UNIX after NUS All UNIX facilities
Administration configured to stop
managing the
network
Engineer console at UNIX via special No UNIX/Cisco
NMS password c.f. works access
Sequent systems
Notes:
Printed: 22/12/98
RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 100 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
1. The Network Management workstations run 24 hours a day.
However, at the end of the shift, the existing user logs out and the
new user logs on to give individual accountability. Other users of the
system must also authenticate themselves e.g. prior to doing
configurer or security management functions.
1. All users (except possibly engineers) are individually identified to
the system and logon under individual user names.
1. Engineers identify themselves at the secure site and have
supervised accessed to the system - see 3.6.3.
8.5.4 Telnet Access to Routers
Pathway routers are normally controlled from the Network
Management Station as described above. There are exceptional cases
where more direct access to the routers is permitted using telnet. The
only cases permitted are:
e CFM senior network management staff accessing the routers in
exceptional circumstances (for example, for fault resolution
requiring use of the debug facility, in times of excessive network
workload or during fault conditions)
¢ CISCO staff supporting the routers from a remote CISCO site
No Telnet access to routers is permitted without authorisation by a
member of the Telnet authorisation list. Manual records are kept of this
authorisation each time Telnet access is used.
All users of Telnet access to routers authenticate using TACACS+. All
Telnet access is audited at the NMS. The audit trail contains the
TACACS+ authentication entries and configuration etc changes
resulting from the Telnet access.
Authorised CFM Network Managers use Telnet access to routers from
a specific dedicated NT system on the Operational Bridge area of the
Network Centres.
Cisco staff access the router needing support via a separate gateway
router dedicated for Cisco use. This gateway router will be configured
to permit Cisco access only when Cisco support is needed - see 8.2.2.
A different TACACS username and password will be used on each
occasion and these will only be valid for the particular session. The
standard Cisco engineers will have read only access to the routers.
Named and authorised senior CISCO staff (NSA Engineers) may have
“enable” mode, as that is needed for reviewing configuration files and
debugging. CISCO are not permitted to make changes to the routers (a
manual, not IT control).
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 101 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.5.5
8.5.6
Direct Access to Routers
The only direct access permitted to routers is for engineers
investigating hardware problems. In this case, access will always be
done locally at the router using a console.
In normal running, the routers will not have consoles attached, though
console access is enabled. Any attempt to use console access will be
flagged at the NMS.
If a router has a fault, it will be configured out of the network and then
aconsole physically taken to the router and plugged in. The router
engineer can then log onto the router to diagnose and repair the fault.
The router is then connected back into the system. The configuration
of the router is checked and the Network Manager asked to confirm
acceptance before the router is configured for normal use as part of
the operational system.
The password used for direct console access is changed via the NUS
every 28 days and also immediately when an engineer requires
access. (There is a two level password system for console access.)
Engineers are not individually known to all routers and need to ask the
Network Manager for today’s password. (The engineers will have
identified themselves manually on entry to the secure site.)
Further details of these procedures will be in the CFM Pathway
procedures manual.
Firewall Management
Pathway firewalls are managed using Firewall Enterprise Centres, one
at each Data Centre. These reside on Solaris systems (shared with
Security token management), which conform to the set-up, operating
system roles and access described in 4.7.
Events to Tivoli
“
Firewall Manager —~_I Sun, UNIX
t
Enterprise Centre
Firewall Monitor t— Standard Solaris roles
Other Services
__ Engineer
Firewalls
Figure 8-6 Firewall Management
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 102 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
All access to the firewalls is via the Enterprise Centre, except for
hardware maintenance. As for routers, in normal running, firewalls do
not have consoles attached - they are only attached for hardware
maintenance after the firewalls has been configured out of the system.
Firewall audit logs are sent to the Enterprise Centre.
All configuration changes are made via the Enterprise Centre and
logged via Tivoli. There are no on-line application support roles.
People with the following roles have access to the Enterprise Centre:
Role Main Functions
Firewall Maintains the firewall configuration and policy data
Manager
Firewall Monitor I Read access to alerts, logs and the rule base
Access controls associated with these roles are defined in the
following table:
Role Workstation type I Authentication method & Resourc
and location where user defined es
available
Firewall I Either: Controlled Defined as UNIX & Enterprise I See
Manage I NT workstation at I centre user; Authenticated above
r secure site, or with token (to NT, and/or
Local UNIX UNIX, depending on
console workstation)
Firewall I As above As above See
Monitor above
8.5.7 Access controls configured in Routers and Firewalls
Access Lists in the routers define the traffic to be permitted or denied
by that router specifying IP addresses and associated IP protocols (ip,
udp, tcp, icmp) and port numbers. Only traffic associated with IP
addresses that are explicitly defined in Access Lists will be permitted.
Firewalls control the use of other application protocols also, though
controls are different for different firewalls, depending on traffic
permitted - see policies in 8.10 below.
8.6 Software/Configuration Distribution and Implementation
Pathway releases software and/or configuration information in two
cases:
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 103 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.6.1
e Implementation of new Post Offices, including migration of in-office
data. The Post Office counters are delivered with a standard
configuration which needs to be personalised and updated when
installed. This process is mainly automated and involves initial set
up of IP addresses, routers and cryptographic keys. This
implementation process may also be used for certain types of major
changes to Post Offices.
e Release software and other configuration updates to existing Post
Offices (and related systems). This covers software release to the
Post Offices and to systems in other domains.
In both cases, the process includes authorising the release, digitally
signing the information, distributing it, and, at the receiving system,
using the digital signature to check the information is correct and from
the right place.
Post Office Implementation
This Access Control Policy is concerned only with those parts of the
implementation mechanisms which affect the operational system.
These are illustrated in figure 8-6.
FAQ; Pathway staff
Pathway Implementation aw managing implementation
Supplier Su
Pathway Data Centre
POCL and Rollout database
other info
I
Auto-Contiguration
database
- - Signing Server [—
JECCO migration
. server
Generic depot/Tivoli server Other systems
PO
including KMS
Software Boot server A
PO conf}g info &I KMS exchanges
sofiward updatesI
Post, 7 fice ¥
PC with
software installed,
iis
Horizon Field Support
(migration)
I. I Auto-configurer
Installation Engineer
Post Office Manager
Figur
e 8-7 Interactions on Post Office Implementation
The information about implementation of Post Offices is managed in
the Roll-out database which takes input from POCL and other sources.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 104 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Pathway suppliers can also access this database (via bulk transfers) -
both to view and update information.
Information about Post Offices to be installed soon is transferred to the
Pathway Auto-configuration database. The Auto-configuration initiates
the Auto-configuration process which sends information to the Central
Pathway services as required to handle the new Post Offices.
Configuration information for each Post Office/counter is also
generated. This is digitally signed by the Signing Server and sent to
Tivoli to distribute.
The PCs are delivered from the factory with software, including an
Auto-configurer application, installed. The installation engineer uses
this to configure the PCs. During this process, changes needed to the
delivered software and configuration are sent to the Post Office. For
ECCO equipped Post Offices, a Horizon Field Support Officer (HFSO)
handles migration of data from ECCO to the Horizon system using a
laptop at the Post Office linked to a migration server at the centre.
(Manual migration is also handled by HFSOs, but at the Post office
only.)
When the Post Office Manager takes over and first boots up the Post
Office, the keys for standard running are delivered from the KMS.
8.6.1.1 Implementation Roles
Application roles are:
Role Functions
Roll-out/RODB users Implementation staff viewing information in
the roll-out database (RODB)
RODB data administrators Implementation staff as above, but also able
to update RODB data, for example, change
the date for a Post office installation.
Roll-out support/help desk Handle calls from Pathway suppliers and
advisors Post Offices - forwarded from Horizon
system help desk. Queries and limited
updates to RODB depending on call
Auto-configuration user Implementation staff managing the data
going through the auto-configuration
database (ACDB). This includes some
update access.
ACDB data administrator Administering the central services site
information in the ACDB
Horizon Field Support Handling migration - two roles for manual
Officer and ECCO migration
Application support manager I Supporting applications
and user
In addition, there are:
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 105 of 117
ICL Pathway
Access Control Policy
FUJ00087993
FUJ00087993
Ref: RS/POL/0003
Version: 3.0
Date: 18/12/98
¢ The standard NT roles defined in 4.4. These include the standard
operational management roles, and auditor roles. It also includes a
dba role for each application
e Key custodian and key handler roles at the signing server - see
771
System access controls for people in these roles are:
Role Workstation Authentication Resource available
type/ method
location
RODB user NT workstation Token Read only access
at Pathway site I authentication to to RODB
or regional office I firewall, then
(see note 1) password to SQL
server
RODB data_ I NT workstation As above Query and update
administratio I at Pathway site access permitted
n by RODB/client
Roll-out NT workstation As above Query and update
advisors at Pathway site access as allowed
by RODB client
Auto-config I Controlled NT Token to NT Query access plus
user workstation at workstation, and via I update as allowed
Pathway site domain trust, to by ACDB/client
Data Centre
ACDB data NT workstation As above Query access plus
administratio I at Pathway site update as allowed
n by ACDB/client
HSFO - Laptop linked to I NT log at lap top; Job to transfer
ECCO Post Office then NT logon to ECCO data to
migration system migration server TMS journal
domain, both using
password
Application Secure NT Token Access to required
support support authentication at NT I files, databases
workstation - workstation
see 8.7
Notes:
1. RODB users at regional offices dial-in, with routers at the office
connecting to the Data Centre firewalls
1. ACDB users have controlled workstations, not on the Pathway LAN,
and linked by ISDN to the Data Centres
1. Once initial roll-out is complete, management of implementation of
new Post Offices will switch to CFM, so workstation types and
authentication methods for those roles will change to the standard
CFM ones - see 8.2.1
Printed: 22/12/98
RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 106 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.6.1.2
8.6.2
1. The NT logon to the migration server for ECCO migration is to
establish the laptop access to this server. The HSFO uses
applications at the laptop only, so is not a direct interactive user of
the migration server
1. Manual migration is a Post Office only role, so covered in 5
Other Access Controls
The RODB takes traffic from external locations, which do not conform
to the standard secure controlled systems used for most Data Centre
access. The NT server supporting the RODB is therefore firewalled
from such external access, with controls at the firewall restricting traffic
ie.
e Implementation staff in regional centres connecting to the RODB via
modems will be restricted to read only SQL access to the RODB.
e Implementation suppliers will be restricted to (FTMS controlled) file
transfers between a Pathway PC at the suppliers site at the RODB.
e ECCO migration laptops can only connent to the migration server at
the Data Centre
The RODB server is also separated by firewalls from the main Data
Centre systems.
Software Updates
This Access Control Policy is concerned with software updates (new
software and fixes) after the software is available in the Configuration
Management system and has been authorised for release by the CS
Release Manager. This is illustrated in figure 8-7.
Pathway Management & Support Centres software &
Configuration ae changes:
librarians J Configuration Pathway ref. data
Management
Software
Distributer & al SigninI [sever test rigs
Pathway Data Centres
ldepot/ Tivoli server —» Other systems
Tivoli exchanges
PosfOffice
Tivoli
Figure 8-8 Software Release
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 107 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
When authorised by the Release Manager, the CM Software
Distributer initiates signing and distribution of the software. It is first
made available for testing, for example, at the test rigs in SSC (see
8.7). Once testing is complete, and all other checks made, the Release
Manager authorises distribution of the software. The Software
Distributer then initiates transfer of the software to the depot in the
Data Centre for distribution to the operational system.
From the depot, the software is distributed via the appropriate route to
the target system e.g. Tivoli distributes software to the Post Office.
Software distribution to the Data Centre is done by the Pathway
Configuration Management unit (CM). Onward distribution from the
depot/Tivoli is controlled by CFM - see other sub-sections above.
In exceptional circumstances, where this is not fast enough, authorised
code fixes may be done directly by CFM.
All human users of the configuration management system log into it as
NT users with passwords.
The usual key custodian and key handler roles are supported at the
signing server. As this is part of the secure Feltham LAN, any
authentication at that system is token based.
8.7 Application Support
8.7.1 Introduction
The main interactions of people involved in application support are
illustrated in figure 8-8. Note: this does not cover support of network
boxes such as routers (see 8.5) or the symmetrix discs (see 8.8) or
support of Dynix (see 8.4)
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 108 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
cure site ICL Corporate
Network
SSC technician, ra
____ secure LAN Other support
I sources ¢.g.
Microsoft
c—
routers and test rigs &
crypto boxes reference sys
I Other secure sites (e.g. CFM, Oracle)
I authorised secure LAN
I support staff
Pathway Data Centre '
routers and I I I
typto boxesH I
TL
Pathway VME partitionI I
with CAS, OAS 1
software '
Figure 8-9 SSC and other support sites
Data Centre systems
with applications,
middleware
SSC is the main application and package support unit supporting
applications and packages on Sequent and NT systems at the Data
Centre, and applications at the Post Offices. This support requires
access to the relevant Data Centre systems to diagnose the problem.
SSC also use test rigs to re-create problems and try out updates,
before updates are included in the operational systems via the
standard Configuration Management system (see 8.6).
CFM provide first line support for most systems and application
support for some Sequent and all VME applications. Other units
provide 3rd and/or 4th line support for particular applications and
packages, though this is often off-line from the operational systems.
All application support staff with access to the Data Centre systems do
so from secure sites using NT workstations on secure LANs separate
from any other systems use (see also 8.2.1). All secure sites conform
to Pathway requirements for physical, network and staff security.
Limited data may be downloaded from the Data Centres to the SSC
test rigs for testing new software and to assist in diagnosing
application problems.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 109 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
SSC also assist Pathway Business Support when doing financial
reconciliations - see 7.5. SSC, on request from Business Support. This
also may sometimes require download to the reference system, with
files of transaction adjustments sent back to the Data Centre for
forwarding to CAPS.
A firewall restricts traffic between the test rigs/reference systems and
the secure LAN. Permitted traffic is the file transfers described above
and access from the SSC and Oracle secure LANs as required for
supporting the applications.
The SSC site is connected via encrypted links to the Pathway Data
Centres (indirectly via another secure site - see section ?).
8.7.2 Roles
Application support roles are included in the relevant sections of the
ACP. There are two main application support roles (for SSC and CFM):
e Application support users diagnose problems and have read only
access to the main Pathway systems
e Application support managers can also correct data under
controlled conditions - see 8.7.3
3° line application support roles (by other units) are always read only.
In addition, there are users of the test rigs. These do not have access
to the Data Centre systems and so their system access is not covered
further in the Access Control Policy. Note that as they have some
access to DSS data, the test rigs, and access to them, are in a secure
area on a secure LAN and staff are vetted to Pathway standards.
8.7.3 System Access Controls for these Roles
All application support users access Data Centre systems via secure
NT workstations as described above. Some may need to see DSS
data. Therefore all these support users should authenticate using
tokens.
Much application support requires read only access to the relevant
Data Centre and VME systems/package. (VME access is via Sonnet
on the Sequent systems at the Data Centre). However, in some cases,
update access is required.
Where update access is to code, and time permits, correction of errors
is by re-issue of a new version of the software via the Configuration
management system. When faster fixing is required, software updates
may be made by CFM (operational management role) directly after a
request by SSC, subject to agreed Pathway authorisation procedures.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 110 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
In certain agreed circumstances, there is a need to correct data which
has been corrupted by faulty code. Such corrections are made only by
the application support manager, and are subject to agreed
authorisation procedures. Where the data to be corrected is DSS data
which is UK RESTRICTED, authorisation procedures include the
Pathway Business Support Unit and DSS.
In all cases, updates to code or data by application support staff
require two staff to be present when the change is made and all such
changes to be audited, identifying what has been changed (before and
after values) and the individual who made the change.
No application support users have access to Post Office counter
systems - errors here are diagnosed using logs of events extracted via
Tivoli.
8.8 Specific Hardware Support
Earlier sections of the ACP cover support of the main Pathway
platforms - the NT and various UNIX systems and the routers. In
addition to these, there are a number of other hardware boxes at the
Data Centre. While most support will be on-site, remote support for
some hardware is being considered.
Information about access controls for permitted support cases will be added in a later}
version of the ACP.
8.9 Horizon System Help Desks
There are two technical Help Desks:
e The Horizon system Help Desk described in this section. This is the
main technical help desk. It is run by CFM and handles technical
queries during normal running of the operational system. It forwards
relevant queries to:
e The Roll-out Support Desk which deals with the specific issues of
installing Post Offices. This is described in 0.
8.9.1 Introduction
The Horizon System Help Desk handles technical queries from Post
Offices, the Payment Card Helpline and from DSS and POCL as well
as Pathway queries.
The main interactions of Help Desk staff using the IT systems is
illustrated in figure 8-7
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 111 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
DSS
&
CFM ete J p> ICL Corporate network
Horizon System NT workstation with Pathway applications
Help Desk £ (Help Desk versions)
1 1 1
Counter clerks yi Workstations for Powerhelp, Dispatch-1 ete
Figure 8-10 Horizon System help Desk
These Help Desk staff answer calls from a variety of sources and are
responsible for registering calls, responding to them in some cases
and passing other calls onto the appropriate unit. One workstation
gives access to call handling systems such as Powerhelp, Dispatch-1
and Remote-1. Additionally, reference machines are available to Help
Desk staff with a special version of Pathway applications (without live
data) for use when responding to Counter Clerk queries. Note that
calls from Post Office Managers about key recovery are forwarded to
SMC to handle - see 8.3.
Horizon System Help Desk users do not have direct access to Pathway
Operational or Management Information Systems, so details of Help
Desk roles and associated access controls are not included in this
ACP.
8.9.2 System Set-up
Horizon system Help Desk technicians are in a secure SMC area as
for other SMC system management staff - see 0 and 0 above.
8.9.3 Other Access Controls
The Horizon System Help Desk receives calls on technical issues
from:
¢ Post Office staff with a technical problem
e DSS via the ITSA Service Help Desk
e POCL offices
e Other Pathway sites
In many cases, some form of authentication is needed, as described in
section 3.5.2 above.
Details of telephone authentication will be added in a future version of this document.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 112 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.10 Network Access Controls
8.10.1 Introduction
Pathway’s main systems are at the Data Centres, but there are several
other sites linking into these and providing supporting services as
outlined in 2.5. This section looks at the network access control
policies within and between these sites, depending on the security
requirements for each type of link.
The following diagram shows the network in outline.
Later sections look at particular parts of the network, and the specific
controls needed there.
Pathway Data Centre Pathway
Corporate
Mat site(s)
POCL sites -
(TIP, ref. data, AP) Sequent NT
operational I I operational Pathway
clin aie systems systems support
POCL Client sites eerie
Corporate
Payment Card] I [ManagementI } Surly
une ¥ [—] I system met
jirobank FRM system & sites
Roll-out
network mgt "
systems systems I_[ Other support
De La Rue sites e.g. Sequent
lcard production
ters, firewalls, erypto boxes I_____ gs
routers, firewalls, erypto boxes Other Data Centre
Post Offices
Figure 8-11 The Pathway network.
All links to the Data Centres are controlled by routers/firewalls.
8.10.2 Protecting Data in Transit
Business data is protected in transit in accordance with [SFS]. In
summary:
¢ Business data in transit from CAPS has integrity protection and data
origin authentication. On-line transactions are also encrypted.
(Other traffic on this link is not protected)
¢ Data in transit on the POCL TIP/reference data link is integrity
protected (using digital signatures).
¢ Data on the POCL HAPS link has confidentiality protection and also
the data will be signed.
Printed: 22/12/98 RESTRICTED-COMMERCIAL.
CAWINNT\Profiles\crosslab\Desktop\RSPOL003.doc Page 113 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.10.2.1
8.10.2.2
8.10.2.3
8.10.2.4
8.10.2.5
8.10.2.6
8.10.3
e The Payment Card Helplines and Girobank FRM systems are in
Wigan and Bootle, so data in transit to them does not need
encrypting.
e Details of customers for card production on route to the De La Rue
card production system are integrity and confidentiality protected.
¢ Traffic to the Post Offices is protected using a VPN to provide
authentication and encryption. Payment authorisations and also
software and configuration updates distributed via Tivoli are digitally
signed.
Other general policies for protection of links are:
All Pathway Corporate management, system management and support
sites with access to the main operational systems have fixed links to
the Data Centres
External sites with access to the main operational Pathway systems
also have fixed links to the Pathway Data Centres.
All such fixed links are protected using Zergo encryption devices using
Rambutan.
All ISDN links use VPN protection or CHAP authentication and CLI.
The Feltham site also acts as a gateway for some other sites
accessing Pathway services. Where these are fixed links (as for the
SSC site) the link between these sites will also be encrypted. (Note the
SSC site also has a further encrypted link allowing an alternative
connection to the Data Centres in the case of a failure at the Feltham
site).
Where external support users, implementation suppliers etc access
Pathway systems, Pathway firewalls control that access. Any
exceptions to this must be agreed by the Pathway Security Manager
and documented in the ACP.
The Data Centre Network Access Policy
The following diagram is a simplification of the network at a Pathway
Data Centre showing the links into and out of it.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 114 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Pathway Data Centre DSS sites
NT Sequent cL POCL TIP ete
operational I I operational WAN [£7 other
systems systems Routers Rr Data Centre
LAN security II ComPorate Girobank
switches services Management Helpline
systems
router Cisco
firewall system &
network mgt
Rollout systems Firewalls, ] #~ POCL HAPS
systems Routers & IW External support
firewall rypto boxeg e.g. Sequent
i T
ISDN & other l ISDN Routers
[Routers for POsI for other links
i
Routers & Hy CEM
typto boxege~
I
[> smc
Pathway mgt ete
Post Offices De LaRue Implement’n Pathway
sites suppliers regional centres
Figure 8-12 The Pathway Data Centre Network
Note that the above diagram does not show:
¢ The actual network within the Data Centres or the firewalls which
protect specific links and systems. Rather this document gives the
access policies which the network should achieve.
¢ The actual network outside the Data Centres such as the Energis
backbone, or the ISDN network as these do not affect the access
control policy.
e Some users where more information is needed e.g. DSS FIT
Traffic into and out of the Pathway Data Centres is mainly controlled
by the routers and firewalls. These are also used within the network,
and there are also controls on the use of ports at particular systems.
The links into the Pathway Data Centre should be configured to
achieve the following.
8.10.3.1 Routers and firewalls on the links should be configured to restrict
traffic as required by this policy - see 3.4.3. They should restrict traffic
to the agreed external sources.
8.10.3.2 DSS and the POCL TIP/Reference Data link use a secure environment
provided by the Energis ATM network. The closed user group restricts
access to Pathway only.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 115 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.10.3.3 Firewalls should protect the Data Centre systems from links to other
services such as POCL HAPS, De La Rue and Implementation
Suppliers.
8.10.3.4 Access to the Data Centre by external organisations for support or
other access should also be firewalled. Any exception to this must be
agreed with the Pathway Security Manager and documented in the
ACP.
8.10.3.5 Roll-out systems which can be accessed from outside sites not
conforming to the Pathway standards for a secure site should be
firewalled from other Data Centre systems.
8.10.3.6 Traffic to/from DSS systems should be restricted to the authorised
business traffic to/from the Sequent operational system (apart from
network management traffic between the routers and the NMS).
8.10.3.7 Traffic to/from the POCL, POCL Client and De La Rue systems should
be restricted to the authorised business traffic to the PCs handling that
link (apart from network management traffic between the routers and
NMS and system management traffic between the PCs and Tivoli
Management Centre.
8.10.3.8 The Girobank Help Desk users should be restricted to only Oracle
Forms access to Sequent (see 4.3.1 above). The Help Desk
workstations should be set up to use only this access to the Data
Centres and the Sequent systems to accept only this.
8.10.3.9 A set of routers should handle all traffic to/from operational Post
Offices and accept traffic from outside the Data Centres only from Post
Offices. No operational Post Office traffic should be accepted via other
routes. These routers should also restrict where traffic can be routed
to/from within the Data Centre. Permitted addresses are just for those
services listed in 5.3 i.e. the Correspondence Servers, Tivoli
management servers and KMS.
8.10.3.10 When implementing a new, or significantly changed, Post Office,
connection will initially be to the boot server which is separated by
firewalls from both external access and the main Pathway Data Centre
LAN.
8.10.3.11 The routers handling POCL and De La Rue ISDN links are separate
from those used for the Post Offices. Traffic permitted to and from
them are file transfer, network and Tivoli management (see section 6).
The routers/firewalls should restrict file transfer traffic to the PCs
allocated to handle this traffic from this site and restrict Tivoli traffic to
the Tivoli server.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 116 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.10.3.12 Routers should be configured to deny access to external users (e.g.
CISCO support) until this access has been agreed - see 8.2.2. When
permitted, the appropriate router should be configured to restrict
access to the Data Centre to the particular system(s) needing support.
8.10.3.13 The routers used for internal Pathway site access only permit traffic
from/to these locations.
8.10.3.14 I The combination of routers and firewalls at Feltham should restrict
traffic from there (and linked sites) to what is permitted. For example,
e SSC application support users are restricted to the systems they
support
e Management users are restricted to the Data Warehouse and MIS
systems at Wigan
¢ Configuration management traffic is only permitted to the
appropriate software depot/Tivoli server.
8.10.3.15 Controls in the Data Centre should reduce the possibility of
interference between systems by separating independent parts of the
system, particularly where these which have different security
requirements. (This may be by a combination of network set-up, router
controls, controls at ports of specific systems and NT domain
structure.) For example,
e Systems concerned with roll-out of Post Offices should be separate
from those used for operational running.
e Security services, such as the Key Management one, should be well
protected from unauthorised access from other systems.
8.10.4 Pathway Project Sites
System management sites remote from the Data Centres which are run
by ICL Outsourcing are covered in sections 8.3, 8.4 and 8.8 above.
The SSC application support site is covered in 8.7 above.
Other sites are used by Pathway management and the Pathway
Implementation Unit. These include:
e The main Pathway management sites at Feltham and Bracknell
e The Implementation unit main site at Kidsgrove
e Regional offices used by the Pathway Implementation Unit.
The Pathway Corporate Management site at Feltham has a permanent
direct link into the Data Centres. Users of Data Centre systems from
this site are:
e Pathway management users accessing the Data Warehouse, MIS
and SLAM systems - see section 7
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 117 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
e Pathway Business Support users - see 7.5
e Pathway Customer Services using the RDMC - see section 4.3.2
e Pathway Security, Audit and FRM users - see section 7
e Software distribution (see 8.6)
e Implementation/roll-out users - see 8.6
The Feltham site also provides links for other Pathway project sites
such as SSC (see 8.7) which require Data Centre access as shown in
the following diagram.
Pathway Feltham site
ICL Corporate Feltham Network
Network and Router with management users
other links and other users
7 CM sign &
Security etc users I Firewall I distribute
{I j I I Cj I Pathway
secure LANs secure site
Router and e.g. SSC
crypto box
Router and Other
crypto box support
secure site
v e.g. Oracle
To crypto box at Data Centre
Figure 8-13 Feltham Pathway Network
The Kidsgrove site and Regional centres have simpler networks with
routers and ISDN connections to the Data Centre. In the case of
regional offices, access to the Data Centre is via a laptop dialling in
(via local routers and then Data Centre routers and firewalls).
8.10.4.1 Workstations on a secure LAN, or individual secure workstations must
be used for access to the following Data Centre services:
e Operational systems at the Data Centre, including related services
such as the time server.
e Services with access to sensitive data (on MIS or other systems) or
with update access to them
e Secure services on a Pathway project site such as the signing
service
Note: this includes Security Management, Auditing and FRM users and
some management users - see section 7.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 118 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.10.4.2 Signing and distribution of software should also be from a secure LAN.
8.10.4.3 All traffic in and out of the Feltham Pathway Network should go
through one of the routers/firewalls identified in diagram 8-12 i.e.
e be encrypted traffic to/from the Data Centres
e be encrypted traffic to/from another authorised secure site, or
e go through the routers/firewalls protecting the pathway network from
the ICL Corporate network and external links
No access to the Feltham network by-passing these controls is
permitted.
8.10.4.4 Traffic between the Pathway Feltham network and other networks
(apart from the encrypted links) should be restricted to permitted traffic
by the routers/firewalls at the boundary to the Pathway network. The
main types of permitted traffic are:
e Links to services required by Pathway developers, managers and
related staff. This includes email, Powerhelp and the financial
system.
e Supply of software from other units, where this is done
electronically.
e Access required by Implementation suppliers to the roll-out
database.
8.10.4.5 All access to the Data Centres from the main Feltham network (rather
than secure LANS), is restricted to the required application protocols to
the permitted particular Data Centre services for this user. This applies
to users with workstations on that network and external users such as
implementation suppliers (see above). This is controlled by the
configuration of the firewall between the network and the Data Centre
link and associated routers.
8.11 NT Domains
Windows NT domains are used in Pathway to control which NT
servers can share NT resources and which users have access to those
resources. They are also used to simplify user authentication - a user
need only logon once to a domain, or once to a set of domains which
have an established trust relationship which includes trust in the users
of the domains.
NT domains should conform to the following policies:
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 119 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.11.1.1
8.11.1.2
8.11.1.3
8.11.1.4
8.11.1.5
8.11.1.6
8.11.1.7
8.11.1.8
8.11.1.9
8.11.1.10
NT domains should generally have at least one Backup Domain
Controller. This should be on a separate site from the Primary Domain
Controller. Exceptions to this must be agreed and are expected to be
small domains with few users.
Where a set of related NT systems is run by a different authority from
other NT systems, this should be set up as a separate domain.
Where such a domain does not share users or resources with other
domains, it should be a separate domain with no trust relationship with
other domains. For example, the Payment Card Helpline systems are
such a domain.
NT domains should be set up to conform to the policies in this ACP
including the general ones in section 3, the NT specific ones in 4.4 (for
Data Centre NT servers) and the need to reduce interference between
systems in 8.10.
Domains may span sites where all NT workstations and servers in the
domain are run by the same authority and are subject to the same
physical and network security. (For example, the SMC system
management domain spans the SMC workstations attached to a
secure LAN on the secure SMC sites and the Tivoli NT servers at the
Data Centre).
A domain must be confined within an area of the network which is
subject to the same security policies and controls. For example, it must
not include NT systems on different sides of a firewall.
Where sharing of resources, but not users, is required between
domains, then the trust between domains should be restricted to
sharing the agreed resources/files across the domain boundary. The
resource sharing must be restricted to the minimum required for the
agreed functions.
Where sharing of files is required between domains on different sides
of a firewall, this should be subject to special authorisation procedures
as well as the policy in 8.11.1.7.
A domain should not establish trust in users registered in a domain in
a less trusted part of the network.
Users should only have access to the NT systems to which they are
permitted access. The domain set up should prevent them accessing
any other NT systems.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 120 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
8.11.1.11 Users should not be registered as NT users at domains where their
only access is at the application level, for example, via a remote client
via an application protocol to a particular application which has its own
logon.
8.11.1.12 Set up of NT domains should assist separation of systems to reduce
interference between them.
0.1.1.1
Printed: 22/12/98 RESTRICTED-COMMERCIAL
CAWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 121 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
APPENDIX A: SUMMARY OF ROLES
The following table is a summary of the roles in this document. Services accessed are listed under:
e Sequent (operational) for the main Sequent systems which support the application hosts
e NT (operational) for the main NT systems which support the main business applications on NT such as
TMS and its agents and the PCs linking the Data Centres to other business sites (DSS, POCL, De la Rue
etc)
e The Management systems including Data Warehouse and other MIS systems, including SLAM, FRMS.
Note that this includes Sequent and NT systems
¢ Other systems - mainly those concerned with Post Office implementation, system and network
management and security management. Note that this includes different system types including NT and
Solaris ones
Role Services/Systems Accessed ACP
sections
Post office I Sequent NT MIS Others
(operational) (operational)
POCL steady state Post Office Roles
Post Office Manager Post Office 5
counters
Post Office Supervisor I PO 5
counters
Post Office Clerk PO 5
counters
Emergency Manager I PO 5
counters
POCL Auditor notes1a2 I PO 5 (7.5)
counters
Benefit Payment Support Roles
DSS/BA clerks I LPAS/CMS via CAPS I [6.1 (4.3.1)
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc Page I of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
DSS Help Desk PAS/CMS via CAPS 6.1 (4.3.1)
Payment Card PAS/CMS 7.4 (4.3.1)
Helpline Advisor
Payment Card PAS/CMS 7.4 (4.3.1)
Helpline Advisor (NSI)
Payment Card PAS/CMS 7.4 (4.3.1)
Helpline Supervisor
Other Support roles used by customers
Horizon System Help local only 8.9
Desk Technician
SMC Team Leader local including one- 8.3
acting as SMC Help shot password
Desk Technician system; KMA
Roll-out Support Desk RODB (NT) 8.6
advisor
Business Operational Roles - Pathway staff
Reference Data RDMC 4.3.2
Change Manager
RDMC Loader RDMC 4.3.2
RDMC User RDMC 4.3.2
RDMC access RDMC. 4.3.2
administrator
Business Support PAS/CMS, TPS, TMS? reconciliation db (NT) I 7.5 (+7.9,
Manager APS, OBCS 4.5, 4.3.1)
Business Support as above as above as above 7.5 etc as
Analyst above
Fraud Risk Management, Audit and Security Roles
FRM Manager PAS/CMS TS FCMS, DW For evidence 7.3 (+ 7.9,
(Sequent) gathering, others as_ I 4.3.1, 4.5)
Business Function
Auditor
FRM Analyst as above as above as above as above as above
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 2 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
FRM User FCMS, DW 7.3 (7.9)
DSS FIT FCMS 7.3 (7.9)
Pathway Business Main host systems Main operational I DW and others Auditor workstation 7.6 (+ lots)
Function Auditor systems
Pathway Security All systems All systems All systems Most systems, 7.6 (+ lots)
Event Auditor including Tivoli
events
Pathway security Token Authentication I 7.7 (4.6)
management Service (Solaris)
Cryptographic Key KMA, CAW 7.7 (4.6)
Manager
Cryptographic Key key mgt application I key mgt on VME, Signing 7.7 (+
Custodian Agents, CMS service (NT) several)
link PCs
Cryptographic Key as above as above as above 7.7 (+
Handler several)
PO key recovery KMA 8.3 (4.6,
(subset of SMC Team 7.7)
leader role)
Other Pathway Management roles
Pathway Management DW (Sequent) - 7.8 (+7.9)
Support Business Objects
and several apps,
SLAM (NT)
Pathway Financial CCS application 7.8 (+7.9)
mgt
Pathway Contract mgt CON application 7.8 (+7.9)
P’way Ref. Data mgt DW. 7.8 (+7.9)
Pathway CS SLAM on NT 7.8 (+7.9)
Managers
Pathway Business DW 7.8 (+7.9)
Dev.
Printed: 22/12/98 RESTRICTED-COMMERCIAL
C:AWINNTProfiles\crosslab\Desktop\RSPOL003.doc Page 3 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Implementation and Software/Configuration Distribution Roles (apart from help desks above)
Auto-configuration ACDB 8.6
user
ACDB data ACDB 8.6
adminstrator
Roll-out/RODB user RODB 8.6
RODB data RODB 8.6
administrator
HFSO - ECCO laptop at Migration server 5, 8.6
migration PO
HFSO - manual PO counter 5
migration
Software Distributer CM signing service 8.6
Pathway operational management/ administration
Computer operator UNIX/secure menu I NT All systems All systems 4.2,4.4,4.7
(on Sequent systems) (+ others)
Senior operator UNIX/secure menu UNIX/secure 4.2
menu
System Monitoring Patrol Patrol on 4.2
Sequent; NT
Database monitoring UNIX/secure menu UNIX/secure 42
menu
Operational mgt/ UNIX/secure menu I NT UNIX/secure All systems (NT, 4.2,4.4,4.7
system administration menu Solaris etc) (+ others)
Operational mgt/ UNIX/secure menu; UNIX/secure RODB, ACDB (SQL _ I 4.2, 8.6
database Oracle applications menu server)
administration
Secure menu UNIX/secure menu UNIX/secure 4.2
administrator menu
Security Management UNIX/secure menu I NT UNIX/secure All systems 4.2,4.4,4.7
menu (+ others)
Legato Administration Archive server 4.5.1
Printed: 22/12/98
RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 4 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Payment Card PAS/CMS 74
Helpline Security
Manager
Base Installation and UNIX NT UNIX All systems 42
configuration
Riposte Management Correspondence 4.5
servers
KMA Data Manager KMA 46
Pathway systems management, administration for CFM (DS) systems
SMC technician Tivoli/Oracle system I 8.3
management
services
SMC technical Team Tivoli/Oracle system I 8.3
Leader management
services
SMC MSS technical Tivoli/Oracle SMS 8.3
support plus SMS OS etc
SMC security Tivoli/Oracle SMS 8.3
manager plus SMS OS etc
Pathway Network and Firewall Management and management of Network systems
Network technician OpenView on NMS 8.5
Network manager OpenView and NMS I 8.5
(+ telnet to routers)
Network management NMS 8.5
configurer
NMS security NMS 8.5
manager
NMS system NMS 8.5
administrator
Firewall Manager Enterprise Centre 8.5.6
Firewall Monitor Enterpise Centre 8.5.6
Support roles
Printed: 22/12/98
C:\WINNT\Profiles\crosslab\
RESTRICTED-COMMERCIAL
Desktop\RSPOL003.doc Page 5 of 117
FUJ00087993
FUJ00087993
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 3.0
Date: 18/12/98
Engineers UNIX NT UNIX, NT NT, Solaris 4.2, 4,4, 4,7
PO Installation PO 5
Engineer counters
PO support engineer I PO 5
counters
Dynix 3rd line support UNIX/secure menu UNIX/secure 4.2
menu
Oracle db 3rd line UNIX/secure menu UNIX/secure 42
support menu
Oracle application 3rd UNIX/secure menu; 4.2
line support Oracle application
Application support UNIX/secure menu; I NT UNIX, NT many 8.7 (+4.2,
manger applications 4.4...
Application support UNIX/secure menu; I NT UNIX, NT many
user applications
VME application UNIX/secure menu
support + VME
Support Roles - non Pathway staff
Oracle application and UNIX/secure menu UNIX/secure 4.2,8.7
db support + Oracle menu + Oracle
Sequent support UNIX/secure menu UNIX/secure 4.2
menu
Cisco router support routers 8.5.4
Notes:
e External Auditors only have direct on-line access to the Post offices. They have indirect access to other
Audit information via Pathway Auditors - see 7.6. The table above only covers direct users of the system,
so indirect access from DSS, POCL and NAO auditors is not shown.
e POCL Investigators have the same rights as POCL Auditors, so are not distinguished from Auditors for
access controls.
Printed: 22/12/98
RESTRICTED-COMMERCIAL
C:\WINNTProfiles\crosslab\Desktop\RSPOL003.doc
Page 6 of 117