FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/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.
Distribution: DSS
POCL
Pathway
Pathway library
Document Status: Approved
Document Predecessor: -
Associated Documents: See section 0.2
Author: Belinda Fairthorne
Approval Authority: Martyn Bennett
Director Quality and Risk Management
Signatures/Dates:
Comments To: Author, copy to Barry Procter
Comments By: -
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 0 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
0. CONTENT
0.1 Document History
Version Date Reason
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.0 24/2/98 For Approval
0.2 Associated Documents
Ref: Title Identifier Vers. Date
SADD Service Architecture Design Document CR/FSP/004 4 30/09/97
TED Technical Environment Description TD/ARC/00012.0 14/12/96
SPOL ICL Pathway Security Policy PS/POL/0002 3.0 8/10/96
SFS Security Functional Specification RS/FSP/0001 3 3/12/97
CHDM PAS/CMS Help Desk Call Enquiry Matrix CS/FSP/0003 2 13/10/97
HHDM Horizon System Help Desk Call Enquiry CS/FSP/0002 2 29/10/97
Matrix
AUDT Audit Trail Functional Specification CR/FSP/006 2.2 8/9/97
FRMS Fraud Risk Management Service Design RS/SPE/0001 2.1 10.3.97
APOL Pathway Audit Policy RS/POL/004 0.7 7/10/97
BS7799 A Code of Practice for Information Security —BS7799 1 15/2/95
Management
DSPOL DSS IT Security Policy (Departmental IT DITSG/ITSS/ 6.2 3/96
Security Standards) 0001.04
PPOL Post Office Counters Information System SRR
Security Policy Appendix 4-1
0.3 Abbreviations
ACP Access Control Policy
BA Benefits Agency
BES Benefit Encashment Service
BPS Benefit Payment Service
CA Certification Authority
CAPS Customer Accounting and Payments System
CAS CAPS Access Service
CESG Communications-Electronic Security Group
CFM Computer Facilities Management
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page I of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
CFM (NI) CFM (Northern Ireland)
CFM (DS) CFM (Distributed Systems Division)
CLI Calling Line Identification
CMS Card Management Service
cs Pathway Customer Services
DBA Database Administrator
DSA Digital Signature Algorithm
DSS Department of Social Security
EPOSS Electronic Point Of Sale Service
ESNS Electronic Stop Notice System
FRM Fraud and Risk Management
HAPS Host Automated Payment Service
ISDN Integrated Services Digital Network
IT Information Technology
KEK Key Encryption Key
KMS Key Management System
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
OAS OBCS Access 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
TIP Transaction Information Processing
TME Tivoli Management Environment
TMS Transaction Management Service
TPS Transaction Processing Service
VME Virtual Machine Environment
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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 2 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Some aspects of network access controls including firewalls
Cryptography/key management design for later releases
Use of security tokens for authentication
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
Split of responsibility, particularly at DSS sites
Telephone authentication procedures
This document assumes that DSS, POCL and NAO Auditors requiring access
to Data Centre system information will do this by asking the Pathway Auditor
to access the system for them. More direct access may be considered in future.
A DSS Help Desk is expected to be introduced which can make enquiries on
the PAS/CMS data via the CAPs on-line interface. This is currently not
expected to change the Access Control Policy.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 3 of 116
FU.
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
FUJ00087989
IJ00087989
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. INTRODUCTIO?
1.3 Scope..
1.4 Access Control Policy Review.
1.5 Document Structure.
2. SECURITY DOMAINS.
2.1 Domain Definition.
2.2 Specifying Access Control Policies.
2.3 Domains involved in Business Operations.
2.3.1 The DSS Service Environment Domaii
2.3.2 The POCL and POCL Clients Domain
2.3.3 The Central Services Domain.
2.3.4 The PAS/CMS Services Domain.
2.3.5 The Office Platform Service Doma
2.3.6 De La Rue Card Services Domain.
2.4 Other Domains and Related Services
2.4.1 Pathway Corporate Services Domain
2.4.2 System Management and Support 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 Functions.
3.2.2 Common System Management Functions...
3.2.3 Common Security Management Functions.
3.2.4 Common Support Function:
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.....
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 4 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
3.4.3 Controlling Traffic between System: 32
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 Procedure:
4, CENTRAL SERVICES DOMAIN.
4.1 Introduction... cccceeceecseeseeeeees
4.2 Sequent Systems with Oracle Databases.
4.2.1 Roles...
4.2.2 System Access Controls for Human Role:
4.2.3 Dynix and Oracle Access Controls... 43
4.2.4 Control of Connections to the System.. 43
4.3 Access Controls for Specific Host Applications. . 43
4.3.1 Reference Data Management Centre.
4.4 Windows NT Systems...........
4.4.1 Roles. seseeeee
4.4.2 System Access Controls for Human Roles...
4.4.3 System Set Up.
4.4.4 Control of Connections.......
4.5 Specific NT Servers (except security ones’
4.5.1 Roles...
4.5.2 Other Access Controls.
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 Other Central Services
5. PAS/CMS SERVICE DOMAIN...
5.1 Introduction.
5.2 PAS, CMS and CAPS Access Services.
5.2.1 Roles...
5.2.2 System Access Controls...
5.3 Payment Card Helpline.
5.3.1 Control of the Helpline Systems
5.3.2 Control of connections to the Helpline.
5.3.3 Roles...
5.3.4 System Access Control:
5.3.5 Other Access Controls.
6. OFFICE PLATFORM SERVICE DOMAIN
6.1 Introductior
6.2 Roles.
6.3 Control of Connections to the Systems
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 5 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
6.4 System Delivery...
6.5 System Installation/Reconfiguration.
6.6 Booting the System.
6.7 System Access Controls associated with Human Roles.
6.8 Other Access Controls...
7. INTERFACE DOMAINS.
7.1 DSS Service Environment Domain..
7.1.1 Roles........ 0
7.1.2 System Access Control :
7.1.3 Control of Traffic between VME and the Data Centres.
7.2 POCL and POCL Clients Domain...
7.2.1 Roles...
7.2.2 Control of Connections to the Pathway Data Centre
7.2.3 Control of Connections to POCL Systems
7.3 De La Rue Card Services Domain..
7.3.1 Roles and System Access Controls...
8. PATHWAY CORPORATE SERVICE DOMAIN...
8.1 Introduction..
8.2 Summary of Pathway Corporate Roles.....
3 Corporate Management Users.
8.4 Fraud Risk Management...
8.5 Auditing.
8.5.1 Overview of Audit Information Accessed.
8.6 Security Management..
8.6.1 Cryptographic Key Management...
8.6.2 Management of Security Tokens..
8.6.3 Data Protection Act Requests...
8.7 The Management Information Systems (MIS).
8.7.1 System Access Control:
8.7.2 Control of Connections...
9. SYSTEM MANAGEMENT AND SUPPORT SERVICES DOMAIN.......
9.1 Introduction..
9.2 Outline of System and Network Management
9.2.1 System Management Workstation Controls.
9.2.2 Procedures for getting in Support Staff...
9.3 System Management of NT Systems:
9.3.1 SMC and Roles at Tivoli Servers.
9.3.2 System Access Controls...
9.3.3 Controls on Connections...
9.4 Sequent and Oracle Management..
9.4.1 Roles and System Access Controls.
9.5 Network Management............0008
9.5.1 Introduction...
9.5.2 Roles at the Open View System...
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 6 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.5.3 Access Controls associated with Human roles...
9.5.4 Telnet Access to Routers.
9.5.5 Direct Access to Routers.
9.5.6 Access controls configured in Routers and Firewalls.
9.6 Software and Configuration Release and Distributio
9.6.1 Post Office Implementation.
9.6.2 Software Updates.........
9.6.3 Release and Distribution Roles. .
9.6.4 System Access Controls for Human Role:
9.6.5 System Set-up...
9.7 Application Suppor
9.7.1 Introduction...
9.7.2 Roles......
9.7.3 System Access Controls for these Role:
9.8 Specific Hardware Support...
9.9 Horizon System Help Desk:
9.9.1 Introduction
9.9.2 System Set-up.
9.9.3 Other Access Controls.
9.10 Network Access Controls.
9.10.1 Introduction.
9.10.2 Protecting Data in Transit
9.10.3 The Data Centre Network Access. Polic
9.10.4 Pathway Project Sites.
9.11 NT Domains..
APPENDIX A: SUMMARY OF ROLEG.......
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 7 of 116
ICL Pathway Ref:
FUJ00087989
FUJ00087989
RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
1.1
1.2
INTRODUCTION
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.
Context
This document fits into the structure of documents for Pathway security as
illustrated in figure 1-1 below.
Contract
& related —
documents
>} Pathway Security Policy
1
Access , Security \ Technical
Audit : ;
Control Polic Functional I Environment
Policy y Specification I Description
I [ [
[ I l
Physical Security
Personnel Security
Health and Safety
Contingency Planning
Operational procedures
for people accessing
Pathway services
Detailed specifications
including
detailed configuration
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 Audit Policy defines the policy for auditing activity in the Pathway system.
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: 25/02/98
CAOFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 8 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
1.3
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.
Scope
This Access Control Policy defines how access to information system resources
is controlled in the operational Pathway system. It includes:
© General access control policies for Pathway
¢ 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
¢ 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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 9 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/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. This section 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 9 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)
and
e The controls for the particular service/system
Appendix A gives a summary of all the roles with references to the sections
where they are described.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 10 of 116
ICL Pathway
Access Control Policy
Ref:
Version:
Date:
FUJ00087989
FUJ00087989
RS/POL/003
2.0
24/02/98
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
Pathway components at
POCL and POCL Client sites
DSS Service Environment Domain
Pathway components at
DSS sites
ESNS
System
Management
and
Support
Services
Domain
Vel
'
interfacing to CAPS,
at the Pathway
Data Centres
De La Rue
ICard ServicesI
Domain
Central Services Domain Pa
Operational systems
'
PAS/CMS
Services Domain
PAS/CMS and
associated Helpline
My
Figure 2-1...
Office Platform Service Domain
All services at the Post Offices
Pathway
Corporate
Services
Domain
Pathway
Management
processes
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.
The particular machines and network connections used, and the aspects of the
Access Control Policy associated with these, are covered in the more detailed
domain information in later chapters of this document, particularly the Systems
Management domain where the responsibility for Network Management lies.
2.2 Specifying Access Control Policies
For each domain, or set of domains, the Access Control Policy includes:
Printed: 25/02/98
C:AOFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 11 of 116
ICL Pathway
Access Control Policy
FUJ00087989
FUJ00087989
Ref: RS/POL/003
Version: 2.0
Date: 24/02/98
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 all people
with access to services in this domains. For each role, a description of the
main classes of functions performed and the access controls in the
information system. This includes where these users are located (the
workstation type as well as physical location), how they are authenticated
and what
resources they can access.
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
Domains 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.
DSS Service
DSS system with Environment Domain
Pathway Partition
PAS/CMS
Tepine [Services Domain
a. De La Rue
POCL and POCL Client ' J Card Services Domain
Domain ‘ IPAS/CMSI
‘ card
i production
bas
Ref. [
Hosts I APS I Tes I Det I oBcs IPASiCMs I
T T =
Distibution I_ <2 Aeents ————> Central Services Domain
Correspondence Servers
es
‘Transaction
WAN ‘Management
Service
é Office Platte
Post Office Counter Infrastructure Service (OPS).
Counter Domain
aps_I poss I oscs I Bes
Figure 2 - 2 Domains directly involved in Benefit Payments
Printed: 25/02/98
C:AOFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 12 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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
Pathway also provides links to POCL. The POCL TIP system receives records
of transactions at Post Offices. Another POCL system provides reference data
for the applications and shares the TIP link to Pathway. The POCL Automated
Payments system processes Automated Payments on behalf of POCL Clients.
This is expected to be replaced in future by direct links to 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.
2.3.3 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) except the PAS/CMS services, which merit a separate domain. All
these (and PAS/CMS) run on Sequent machines and use Oracle.
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.
2.3.4 The PAS/CMS Services Domain
Information is transferred to/from the DSS Service Environment Domain 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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 13 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
2.3.5
2.3.6
2.4
2.4.1
2.4.2
The Payment Card Helpline responds to DSS, POCL and general public queries
about benefit cards and payments. They use Windows NT workstations with
Oracle Forms applications to access the PAS/CMS database.
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).
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.
¢ The Pathway Corporate Services domain includes Pathway’s own
management processes including security ones.
e The System Management and SupportServices 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.
This domain includes a Data Warehouse which gathers information from the
operational system and a Financials System.
System Management and Support Services Domain
The System Management and Support 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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 14 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
2.4.3
2.5
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 both application and hardware support.
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.
Internal Pathway Services
A number of internal Pathway services interact with Pathway operational and
management services at the Pathway Data Centres. These include:
© The Powerhelp and PinICL systems used to 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.
¢ The Dispatch-1 system which holds hardware inventory information
Pathway Sites and Responsibilities
The main Pathway services run at the secure Pathway Data Centres at Wigan
and Bootle. This includes:
¢ 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
e The System and Network Management services and services supporting the
implementation of the Post Offices.
The main operational services can be run at either site, if needed. The Pathway
Management Information Systems are at Wigan only. Figure 2-3 shows the
sites with electronic links to the Pathway Data Centres. Note that some of
these links may not be directly to the Data Centres, but through secure
Pathway sites - see section 9.10.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 15 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
CAPS, ESNS, TIP etc
at DSS, POCL and POCL Client sites
De La Rue sites \ I Girobank sites
Card & token Payment Card Helpline
production Pathway Data ¥—> eee
———— Centres GEL
CEMIND TS = Pathway Management
) Operational and Support Sites
Operational applications
Management Pathway Management
Management
CED AS. Informa
CFMIDSD) sites “Sane Application support
System Implementation
Management Implementation i: —— YY
Horizon System services ¥— (Implementation supplier
Help Desk and other support sites
Post Offices Royal Mail
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.
¢ 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).
¢ ICL CFM (NI) 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.
CFM is also responsible for Network Management, which is done at the
Data Centres, though it manages routers on other sites also.
e¢ ICL CFM (DS) are also 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 CFM(DS) sites.
¢ 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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 16 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/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. Implementation suppliers access
authorised implementation systems from their own sites.
e 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
¢ Under exceptional circumstances, CFM 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:
¢ Sequent supports the Dynix operating system.
© Oracle provides 3rd line support for Oracle databases and applications.
e Cisco supports the routers.
© 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
¢ Girobank also perform Fraud Risk management functions.
This is at Bootle, but in a separate area from the Pathway Data Centre.
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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 17 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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 9 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.
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:
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 18 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
© 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.
¢ 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.
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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 19 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
3.2.1
3.2.2
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.
¢ 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)
¢ 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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 20 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
¢ 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 Resource 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.
¢ Riposte Administration. Management of Riposte message stores
and groups is largely done automatically.
¢ 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 9
for more about Tivoli.
e Application and Package 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:
¢ Network Management: managing the network which connects machines
and domains together.
¢ Implementation management: managing the roll out of the Pathway
solution to Post Offices. (The Access Control Policy is concerned with that
part of the roll out process which affects the operational system).
3.2.3 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:
¢ 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:
© 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
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 21 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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.
¢ Security Event Auditing: analysing and reporting on the audit logs in the
system. There may be local auditing functions in some areas as well as the
Pathway wide function.
¢ Cryptographic Key Maintenance: Keys are used to protect
communications links, digitally sign information and encrypt filestore. For
roles associated with this, see 3.2.5.
3.2.4 Common Support Functions
Support functions are primarily concerned with:
¢ Keeping applications operational
© Keeping all equipment operational, and
¢ Training staff to carry out their defined roles
On-line training is provided at Post Offices and Payment Card Helpline
systems.
Application support, including diagnosing application problems at the Post
office, is mainly done remotely.
Functions associated with keeping the equipment operational are:
e Running diagnostic applications to check for equipment faults (may be done
by the Post Office Manager, as well as engineers, at the Post Office)
e Installing new Post Offices; done Installation Engineers
¢ 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 a small number of roles have access to several of the domains. These
are:
¢ Pathway Business Support. This role supports the business operations.
For example, it handles financial reconciliation of payments.
¢ Pathway Fraud and Risk Manager (FRM). This is concerned with the
identification, monitoring and management of fraud particularly in benefit
payments.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 22 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
While much of this is done in the Pathway Corporate Services Domain,
FRM staff also have access to operational Pathway systems such as the
TMS journals and PAS/CMS data.
¢ Pathway Security Manager. This function includes the Pathway Security
Event Auditors who are responsible for auditing all use of the Pathway
systems. The Security Manager is also responsible for ensuring provision of
personal data in accordance with the Data Protection Act.
The Security Event Auditor will require access to most of the Pathway
systems under some circumstances. However, the TMS will provide
sufficient records at the Pathway central site for it to be unnecessary to
provide Pathway access to the Post Offices.
e Pathway Cryptographic Key Manager: Responsible for all cryptographic
keys used in Pathway, generating and distributing keys using the Key
Management System.
The Pathway Cryptographic Keys Manager will delegate some responsibility
for installing and updating keys to Pathway Cryptographic Key
Custodians and Cryptographic Key Handlers.
¢ 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 8 on the
Pathway Corporate Services Domain.
3.2.6 External Roles
In addition to the Pathway roles defined above, some access to the system is
required by people in POCL, DSS/BA and others. Some of these are indirect
users of the system, who contact direct users to perform actions on their behalf
e.g. customers receiving benefits from the Post Office. They are described with
the other roles for particular domains.
Also, some external users have access to the Pathway system. These are:
e¢ POCL Auditors, Investigators and Emergency Managers who can access
services at Post Offices as described in chapter 6. They also have access to
audit information at the Data Centres via Pathway Auditors - see 8.5.
¢ DSS and NAO Auditors have similar access to central audit information.
¢ Benefit Agency staff use the on-line CAPS interface, for example, to make
emergency payments or stop cards or payments.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 23 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
3.3
¢ DSS Help Desk staff are expected to use the on-line CAPS interface for
queries e.g. on authorised payments.
¢ DSS Fraud Investigation Team access the FRM database and a limited
amount of information in the Data Warehouse - see chapter 8.
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.
There may be other external roles in future.
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.
¢ Training information - special business style data used in training sessions
© On-line documentation e.g. Payment Card Helpline procedures, Post Office
procedures
© 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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 24 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
3.3.11 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.
3.3.1.2 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.
3.3.1.3 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].
3.3.1.4 Digital signatures should be used for integrity protection of business
information between services where required. For example, information about
authorised payments sent from Pathway to the Post Office is signed for
integrity. Automated Payments details are signed at the Post Office prior to
transmission via Pathway to POCL or POCL Clients.
3.3.1.5 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.
3.3.1.6 Business information in filestore at the Post Office PCs should be encrypted.
3.3.1.7 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.
3.3.1.8 System Management actions by Tivoli should be activated using pre-defined.
Tivoli tasks which have been 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.
3.3.1.9 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.
3.3.1.10 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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 25 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/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.)
¢ 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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 26 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/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 Ifa 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.)
For system management, a further separation is achieved using Tivoli regions
to separate management of Post Offices systems from management of the
central services.
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 9 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 PDA and be documented.
3.4.2.2 Workstations at the Post Office display sensitive business data (e.g. about
payments) at that Post Office 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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 27 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/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 are able to update the
operational or MIS systems (for example, to perform systems management
actions)
¢ They have access to the BA and/or POCL business data (except at the Post
Offices).
e They are authorised to update core system data which can affect the running
of the Pathway systems. This includes people who can use 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 Ifaccessing 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
¢ Users requiring token authentication are also registered with the appropriate
authentication service.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 28 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
(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.217 Access to shared resources such as filestore is controlled by:
© 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.
3.4.2.2] Interference between applications is prevented. For example, at any one
system, different applications will 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).
3.4.2.22 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.
3.4.2.23 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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 29 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
3.4.3
3.4.11
3.4.1.2
3.4.1.3
3.4.1.4
3.4.1.5
3.4.1.6
3.4.1.7
3.4.1.8
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 are as follows.
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 which originates 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.
Workstations which have access to sensitive data should generally be on
separate networks linked only into the Pathway secure network. Where such
workstations are in any way connected to other networks, the sensitive data is
protected from the other network by an authorised combination of routers and
firewalls configured to prevent any traffic between the network and these
workstations. All such cases must be documented in this Access Control
Policy.
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.
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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 30 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
3.5 Other Access Controls
In some cases, the information system cannot provide all the access controls
required. This is the case, for example, where a customer contacts Pathway by
phone and asks for data which should only be available to authorised people. If
this is the case, the caller will not be known to the IT system, so some other
form of authentication of the caller is required.
3.5.1 Customer Authentication
No general policies are specified for how to identify customers who are not
known to the system as these are different for different cases - authenticating
customers at a Post Office is different from authenticating them on calls to a
Help Desk. The methods used for authentication of customers are included in
the definition of the appropriate domain.
3.5.2 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.
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.
3.5.3 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 PDA. Visitors to Pathway sites are subject to Pathway vetting
procedures.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 31 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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.
3.6 Key Management
Cryptography is used widely in Pathway as described in the Security Functional
Specification [SFS]. For example, it is used for:
© Protecting information on links for confidentiality, integrity and origin
authentication in line with the requirements for that link.
¢ Digitally signing information such as benefit authorisations, automated
payments and software in transit across systems.
¢ Filestore encryption at the Post Office.
This Access Control Policy defines how the cryptographic keys required for
this 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. The Key Management Service at the Pathway Data Centres is included
in the Central Services domain.
3.6.1.1 CESG approved keys must be protected in line with CESG requirements.
3.6.1.2 Key material (symmetric keys, DSA private keys and DSA entropy) should be
held in clear only when in physically secure environments.
3.6.1.3 Public keys (except for the CA’s public key) should be held in certificates
signed by the Certification Authority.
3.6.1.4 Symmetric keys should only be stored where necessary, and be held securely.
3.6.1.5 Keys (or part keys) held in filestore must be in separate filestore accessible only
to authorised key custodians via authorised applications.
3.6.1.6 Keys used for protecting data should not be resident in filestore in clear.
3.6.1.7 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.
3.6.1.8 New KEKs should not be distributed solely under the protection of existing
KEKs.
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 32 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
3.6.1.9 Key material in transit electronically must be encrypted (except for CHAP keys
between the routers within the Pathway Data Centre LAN).
3.6.1.10 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.
3.6.1.11 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.
3.6.1.12 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.
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. It defines the controls required at
a sufficient level to show how the system is protected. However, as explained
in section 1.2, there are other documents covering, for example, 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,
© 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.
¢ 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:
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 33 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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.
© 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 ete
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.
© Operational management procedures (particularly CFM). These must detail,
for example, how remote access is properly authorised and the lines
configured to allow this when needed (see sections 4 and 9).
e System management procedures to authorise, for example, distribution of
software.
¢ Technical Help Desk procedures to ensure all relevant calls are logged with
the help desk systems system and properly monitored.
¢ 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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 34 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
4. CENTRAL SERVICES DOMAIN
41 Introduction
The Central Services Domain is illustrated in figure 4-1.
POCL or
POCL Clients TIP POCL ESNS CAPS
hb
Iquent
Hosts
[aps] [TPs ] RDMc] [oBcs] Pasicms
Management
& Support TNF Serves
users
TMy Agents Related
TIP I Ref Data] IOBCSI]} BES services
\
Harvester Agent Agents Agents eg. Data
t r t security, ‘archouse
Correspondence Servers (Riposte) time feeds
t
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 - APS, TPS, OBCS and the Reference Data Management
Centre. (PAS/CMS is in a separate domain - see 5).
The TMS agents act as the 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, cither to retrieve information to send to the Post office or
to update tables as the result of messages received from the Post office. The
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 archive them.
The main operational flows though the hosts, TMS Agents and TMS are
automated, (as is most System Management).
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 35 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/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. Interactions with Sequent systems are
illustrated in figure 4-2.
Data feeds to/from
DSS,POCL & Clients
Operational roles [— I System Management
(application specific) RMU ]
Auditors Access Service to DSS Operational Management
secunty & — [via PCs for other links)} [~ Sequent/Dynix, Oracle db,
other auditors job scheduling
Security Manager
user,etcadmin ~ I ~ a Base Installation
Applications
Support users and ——
application & = I Databases r— Engineers. :
hardware diagnosis/repair
system support
TMS Automatic feeds to/from TMS 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 9). 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. The main users are:
¢ Security managers who manage security information about users and their
privileges, groups ete.
© 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 only occurs as the result of incidents.
e Application support people diagnosing software faults and engineers
diagnosing and clearing hardware faults
¢ Security and other Auditors
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 36 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
4.2.1 Roles
People in the following roles have direct access to the Sequent machines.
Role (and Main classes of functions
organisation)
Computer Operator Physical operations e.g. media handling, but no on-line use of
(CFM) the system.
System Monitoring Monitoring the operational system using Patrol.
(CFM)
Operational Management of Dynix including any action needed concerned
management with replication between campuses and local archiving.
(CFM) Oracle database administrator for database structure - setting
up views, space allocation etc.
Operational monitoring/management using Patrol
workstations.
Job scheduling (Sequent & NT) using Maestro workstation.
Security Management I Administering UNIX user information, including group
(CFM) membership for all users of the Sequent system.
Administering Oracle database administrator (DBA) users and
associated roles and privileges.
Emergency operational I Operational management done by CFM staff on call. This is a
management (CFM) subset of the full operational management functions above. It
does not include security management or application support.
Dynix 3rd line support I Operational management of Dynix by Sequent staff when CFM
(Sequent) cannot cure problem.
Database 3rd line Operational management of Oracle when CFM cannot cure
support (Oracle) problem. This may sometimes require updating the database.
Application support Supporting Sequent/Oracle applications, including having
(SSC) access to the data in the database.
‘Application support Supporting Sequent/Oracle (MIS) applications and VME
(CFM) applications via Sonnet on Sequent.
Application 3rd line Supporting Oracle applications
support (Oracle)
Engineer Hardware diagnostics and repair
Base Installation and Initial installation and configuration the base system - Sequent
configuration (CFM) and Oracle databases. Later updates to these.
Auditors Auditing security related actions
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 will be covered in 9.8 below.
4.2.2 System Access Controls for Human Roles
As for all domains, system access controls conform to the policies in section 3.
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 will be done using specific functions on the
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 37 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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.
Database administration functions should use:
¢ Patrol for monitoring the database
¢ 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)
Note: Some of the operational and system management users have access to a
number of systems and are described more fully in section 9. Information in this
section is limited to their use of the Sequent system.
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.
Role Workstation type Authentication method & I Resources available
and Location where user defined
Computer No workstation; none, as No access none in system
Operator Pathway Data Centre
System X terminal (or UNIX with individual user I Resources as available
Monitoring emulator) at Data name & password via Patrol
Centre and Belfast
Operational NT Workstation (X UNIX plus token Functions as on menu.
Management I terminals or authentication (see note 3). I This can allow use of
emulators for Patrol Oracle user registered with I root and UNIX
& Maestro) associated role for dba commands and Oracle
CFM site (Belfast) functions dba functions.
Security NT workstation on UNIX and token (see note I User information in
Management I secure LAN 3). Oracle user registered I UNIX and Oracle
CEM site as above
Emergency NT Workstation on UNIX and token as Operational
Operational I secure LAN authentication (see notes 3, I Management above
Management_I CFM site (see note 4) I 4)
Dynix 3rd NT workstation. UNIX plus token UNIX, which can
line support Secure site (see notes I (see notes 5 and 6) include root access
6 and 7)
Oracle db 3rd_I NT workstation. UNIX plus token Read only access;
line support Secure site (see note I (see notes 5 and 6) Oracle dba, & limited
6) UNIX functions.
Application NT workstation. UNIX Read only access to
Support Pathway site event logs and other
(SSC) (Bracknell) relevant files
CFM Appl’n_ I NT workstation UNIX (and VME, for Read only access to
support CEM site VME support) relevant data
Oracle appl’n I NT workstation at UNIX plus token as above, read only
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 38 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
support secure site (note 6)
Engineer computer console. UNIX with engineer Access to diagnostics
Data Centre password (see notes 5 & 7) I and, if needed, data on
suspect hardware
Base computer console UNIX most
Installation Data Centre
Auditor NT w/s on secure UNIX and token Audit logs - platform,
LAN: Pathway site authentication COS/Manager,
(Feltham) database, application
Notes:
1.
1.
Wherever possible, responses to events are automated, to prevent the need
for human interaction.
Wherever possible, responses to events which require human interactions
are performed using pre-defined functions, rather than command line access
to the system.
Operational management staff always authenticate under their own names
to UNIX and perform functions wherever possible without root privilege
(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.
Emergency operational management is currently expected to be from the
CFM secure site at Belfast.
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.
Sequent and Oracle staff will provide 3rd line support. This is expected to
be from Sequent and Oracle sites. In this case, access is from a secure area
using a secure NT workstation on a secure LAN via encrypted links to the
Data Centre - see 9.2.1 and 9.10. Call in procedures as as in 9.2.2.
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,
Visiting engineers are subject to manual procedures as in 5 above.
4.2.3 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) will 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 are used to restrict the damage
possible due to failures during automated processes.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 39 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
4.2.4
4.3
Database administration should be split into roles and where possible use pre-
defined queries and scripts as defined above.
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:
¢ Telnet and X-terminal access to Dynix for operational management, 3rd line
support, job scheduling and Security Event Auditors
© OSI traffic to VME (FTF and MAC) to support file transfer to DSS systems
and management
© 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 to PCs for transfer of business data to/from POCL and De La
Rue
Access Controls for Specific Host Applications
The following applications are covered here (PAS/CMS is in section 5):
e The Automated Payment Service (APS)
¢ The Transaction Processing Service (TPS)
e The Reference Data Management Centre (RDMC)
e The Order Book Control Service (OBCS)
All these 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, OBCS includes an OBCS
Access Service to communicate 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.
Of these applications, only the RDMC requires human access (apart from the
management and support users defined in 4.2 above).
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 40 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
4.3.1 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 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 RDMC 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 is distributed to RDMC via Configuration
Management as for other software updates - see 9.6.2.
Application roles supported at the RDMC are:
Role( and organisation) Main Functions
Reference Data Change Kick off the transfer of validated reference data of
Manager (CS) classes 2 to S to TMS when all required
dependencies have been met.
Ref. data developer (Pathway Read/copy selected reference data needed for
development) testing of Pathway functions.
Access controls associated with these roles are shown in the following table.
Role Workstation I Authentication I Resources available
Method
Ref Data NT w/s in NT with token I Specific Oracle application only
CM. secure area + Oracle
Ref Data as above NT with token I Read only access to reference data.
developer + Oracle
Note: All these users access 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. Oracles roles control this access.
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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 41 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
44 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 I_- ~ resource management
(application specific) ~~] - event monitoring
[— System Administration
Security ManagementI —4
Applications
LNG and Base Installation
Security Event Auditor — Infrastructure I [> and Configuration
Application Support — t-— 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 9) and appropriate
remedial action is generally taken automatically. Security management (e.g.
administering users) is done using NT utilities.
¢ Software and configuration information is distributed to these systems via
Tivoli (see section 9).
¢ NT servers also have local consoles which can be used 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 4.4.1. Specific roles for
particular NT servers are included in section 4.5.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 42 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
4.41 Roles
People in the following roles have access to all NT systems in this domain.
Role (and Main functions
organisation)
Computer Operator Physical operations e.g. media handling, but no on-line use of
(CFM) the system.
Operational ‘Any residual management of NT (not done by SMC e.g. via
management Tivoli)
(CFM)
Security Manager Administering NT user information, including group
(CFM) membership.
Security Event Auditor I Management of, and access to, Audit logs.
(Pathway)
Application support Supporting applications on NT platforms.
(SSC)
Engineer Hardware diagnostics and repair
Base Installation and Initial installation and configuration the base system - NT etc
configuration (CFM) _I Later updates to this.
4.4.2 System Access Controls for Human Roles
Access controls associated with these roles is defined in the followed table.
Role Workstation type I Authentication method I Resources
and location & where user defined I Available
Computer Operator I no w/s; on site at none, as no access Media only
Data Centre
Operational NT w/s at secure NT with token Full administrator
Management Pathway site rights
Security Manager I NT workstation at I NT with token User administration,
secure Pathway site security policy
administration etc
Security Event NT workstation at I NT with token Read only access to
Auditor Feltham audit logs only
‘Application NT workstation at_ I NT with token Read only access to
Support SSC site event logs, registry
and relevant files
Engineer Pathway campus; I NT with controlled Administration
no remote access password/token
Base Installation Pathway campus NT with password Administration
Notes:
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.
4.4.3 System Set Up
System access controls must conform to the policies in 3.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 43 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
All NT servers are set up with a 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 the
domain. 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 9.11.
4.4.4 Control of Connections
The following traffic is generally permitted to NT systems at the Data Centre:
Telnet traffic for NT management, security auditor access etc
NT domain traffic
Maestro job scheduling (at Agents)
Tivoli traffic for event management, software distribution etc
However, the KMS system 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 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.)
¢ The Agents which transfer information 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 9)
¢ Related supporting services such as the Time Service, Archive Service.
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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 44 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
All these NT servers are subject to the controls described in 4.4 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.
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 4.4 above. There are the following specific roles at these NT servers.
Role (and Main Functions NT Servers
I organisation) where applicable
Riposte Residual Riposte management which is not I Correspondence
Management automated e.g. setting Riposte neighbours. I servers
(CFM) (Setting up Correspondence servers as
members of Riposte groups when new Post
Offices are added is done by the auto-
configuration application.)
Business Support I Access to TMS when needed to support Correspondence
(Pathway) reconciliation servers
Pathway FRM Access to TMS journals in exceptional Correspondence
(Pathway) circumstances, when needed to support servers (and their
investigations. archives)
Auditors Access to TMS journals when needed to Correspondence
(Pathway) when investigating security incidents servers (and their
archives)
Crypto Key Installation and update of keys and re- BES Agents, PC
Custodian & Key I installation when needed e.g. on machine for De La Rue
Handler (CFM) reboot. (These roles are defined in 8.6.1) link
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 I Authentication Resources
and location method available
Riposte NT at secure site NT Correspondence Appropriate
management_I (see 9.2) server user with token_I Riposte utilities
Business NT at secure NT Correspondence Controlled read
Support Pathway site server user with token_I only TMS access
Pathway NT at Pathway NT Correspondence Limited read only
FRM secure area server user with token I TMS access (see
note)
Security NT at Pathway NT Correspondence Audit logs and
Event secure area server user with token I limited read only
Auditor TMS access
Notes:
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 45 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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 8.6.1
45.2 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 KMS for distribution of some key material using key distribution
protocols which protect keys in transit
4.6 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 Service (KMS) 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 An Authentication Service to support token authentication.
¢ The cryptographic boxes used for link level encryption of some links.
(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.)
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 46 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
4.6.1 Key Management and Associated Services
Interactions with the Key Management Service and Certificate Authority are
illustrated in figure 4-9.
Cryptographic NT Security Servers vee
Key Manager _ I Key . . I___Support,
and other anagement {-] E*"oPy I Fertification! /~ Engineering
Key Handlers Service Servers Authority ate
y y
BES Agents BES
Crypto Servers ones
Post Offices ete “*®
Figure 4-4 Interactions with the Key Management Service
The Key Management System (KMS) 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 KMS also
uses the Entropy Servers to provides the entropy needed for DSA signatures.
An off-line Certification Authority (CA) 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 (and organisation) Main functions (system accessed)
Cryptographic Key Manager Generating keys and initiating distribution of
(Pathway Security Management) these (KMS)
Generating certificates to certify keys (CA)
Cryptographic Key Custodian and I Installing, updating and re-installing keys
Handlers - see 8.6.1 (CFM)
PO key recoverer (SMC) Initiating recovery of a Post Office key for a
(part of SMC Team Leader role) Post Office Manager who has lost his card or
PIN after authentication of the PO caller to the
Help Desk - see 9.3, 9.9.
Note: design in this area is not yet complete, and so is subject to change. Access controlsI
associated with these roles are not yet defined, though all the key users will accessI
the system from secure locations via secure routes
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 47 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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.
\Note. details of this Authentication Services have still to_be finalised.
The Authentication Service holds information about:
e Tokens, and when, and to whom, they are assigned; also the PINs
associated with these tokens
¢ Users of these tokens
¢ Clients who initiate authentication when users access the system. These
may be on NT and UNIX systems and on routers.
¢ 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:
¢ Management of the underlying operating system
¢ Installation and configuration of the Authentication Server
e Administration of tokens and users for all Pathway users who require
authentication via tokens.
e Security auditing, which may include real time monitoring as well as
selective reporting from the Authentication Service audit logs.
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 Other Central Services
The Central Services are not restricted to services on Sequent and NT
platforms. For example, there is a PAS/CMS training database on a Solaris
platform. 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. It is managed by
CFM as for other UNIX platforms, though does not use the same secure menu
system as on Sequent.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 48 of 116
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
5.1
5.2
PAS/CMS SERVICE DOMAIN
Introduction
The Payment Authorisation Service (PAS) and Card Management Service
(CMS) are the Pathway hosts supporting the Benefits Payment System. They
run on Sequent machines at both Pathway Data Centres and share one Oracle
database. Access controls for these are described in 5.2 below.
The Payment Card Helpline handle calls from customers, Post Offices and the
Benefit Agency enquiring about payment authorisations, cards and PUNs.
Helpline Advisors have access to the PAS/CMS system via Oracle Forms from
NT workstations. Access controls for these are described in 5.3 below.
PAS, CMS and CAPS Access Services
The interactions with PAS, CMS and the associated access service to CAPS
are illustrated in figure 5-1.
Figure 5-1 Interactions with the Sequent Systems
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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 49 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
5.2.1 Roles
General roles for the Sequent system including application support are defined
in section 4.2. Specific PAS/CMS roles are:
¢ 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 5.3 for Helpline roles.
¢ DSS staff doing on-line transactions via CAPS e.g. emergency payments.
¢ Business Support users accessing PAS/CMS when required to support
reconciliation (see 8.3) and generating contingency payment authorisations
when CAPS is down according to agreed procedures.
e Fraud Risk Management staff accessing PAS/CMS data when required
information is not available via the Data Warehouse or archives.
© Cryptographic Key Custodian installing/updating the encryption key needed
for the CAPS to PAS/CMS link.
5.2.2 System Access Controls
Access controls conform to the general policies in 3 and the Sequent controls
in 4.2 above.
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 8.6.1). All users in the table access PAS/CMS information via Oracle tools.
Role Workstation How authenticated I Resources ayailable
type and to PAS/CMS (&
location where user
defined)
Helpline NT Help Desk I Oracle username, Particular PAS & CMS tables as
Advisor workstation in I password required for the authorised Oracle
Girobank area at I (Oracle user Forms (with sufficient write access to
campus associated with allow cards to be stopped, update call
Oracle role) logging tables and change
password.)
Helpline as above as above As above, plus can handle data with
Advisor (NSD) a Nationally Sensitive 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 as
Manager user associated with I Helpline Advisors plus privilege to
Oracle role) create users and assign/re-assign
them to Helpline roles.
DSS/BA staff I DSS site Authenticated to Particular PAS and CMS tables as
DSS system, required for the authorised
identified to P’way I transactions from the Oracle client
by transaction id. __I applications on VME.
Business NT at secure NT user with token I Read only access to PAS/CMS for
Support Pathway site and Oracle user reconciliation; specific application
for contingency payments
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 50 of 116
FUJ00087989
FUJ00087989
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Fraud Risk NT secure sites I UNIX with Read only access main database in
Manager Girobank, P’way I password and token I exceptional circumstances
A separate username is required for the Cryptographic Key Custodian.
Filestore accessible only to that user holds the cryptographic key.
5.3 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
¢ 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
Interactions with the Helpline systems are illustrated in figure 5-2.
Figure 5-2 Interactions with the Payment Card Helpline
Helpline Advisors use the PAS/CMS database when responding to telephone
calls. They also have access to on-line documentation, such as the procedures
they must follow, from local Helpline NT servers.
Helpline Supervisors and Managers also have access to some local office
applications.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 51 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
5.3.1
The Helpline Security Manager is responsible for administering information
about Helpline users at both the local Helpline system and PAS/CMS.
The Helpline and its associated systems are run by Girobank, so are not
managed by CFM and are maintained by different engineers.
Control of the Helpline Systems
There are two Helpline sites, one at Bootle and one at Wigan, to provide
resilience. The Helpline network at cach site is illustrated in figure 5-3.
tl Network Management
I (HP Openview etc on UNIX)
= s#
ee ie
ay as
Helpline NT workstations
Bie
NT servers
Helpline
Routers etc Rockwell ACD
+ associated servers
PC for ry Pathway Data Centre router
monitoring = NX
ACD traffic
PAS/CMS & Other Payment Card
training db Helpline site
Figure 5-3 Helpline Site Configuration
The Pathway Access Control Policy is concerned with controlling the access
from the Helpline workstations to the Pathway systems. Controls at the
PAS/CMS Sequent system will restrict access to the required Oracle tables.
However, as write access is needed (to stop cards etc) control of the Oracle
Forms applications is needed in the Helpline environment to ensure Helpline
staff can only use authorised Oracle Forms menus and the associated
authorised set of Oracle Forms for the permitted role.
All Helpline staff use NT workstations. These workstations are used both for
PAS/CMS transactions (see 5.2 above) and local applications in the Helpline
network. All workstations used for access to PAS/CMS have their floppy
drives disabled (to prevent floppies being used to update the Oracle Forms
applications used to access the PAS/CMS system.).
In general, any of these workstations may be used for running any applications.
(as facilities available to a user depend on the user’s role as established at log
on to the local system - see 5.3.4.) except:
¢ The PC including the application to monitor telephony traffic (as that has a
link to the Rockwell ACD servers).
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 52 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
¢ There are two workstations on the Helpline network with a floppy drive
enabled (to allow restricted transfer of data to/from the NT servers), but
these have controlled access and cannot be used to access PAS/CMS.
Some applications and on-line documentation are held on the NT servers.
However, for performance reasons, Oracle Forms applications are held at the
workstations.
A set of dedicated workstations are used for training activities acessing the
training database at the Data Centre.
5.3.2 Control of connections to the Helpline
Most connections into the Helpline are telephones. These are independent of
the Helpline network except that information is fed from the Rockwell ACD to
a particular PC so that telephone traffic can be monitored. This PC should be
configured as a separate domain so the telephony data can be routed
automatically only to this PC. However, a Supervisor at a standard Helpline
workstation can run an application to view this telephony information.
The other link is the one to the rest of the Pathway network, particularly the
PAS/CMS system. This will only be used for:
¢ Oracle Forms (and therefore SQL*Net) for accessing the PAS/CMS
database - both by Advisors responding to telephone calls and by the
security manager for administering user information
e Information about calls (from Rockwell ACD) to the Data Warehouse.
¢ Traffic to the other Payment Card Helpline site
There are also telephony links.
This Access Control Policy document does not cover functions internal to the
Helpline network which do not affect the rest of the Pathway system e.g.
configuration and management of Helpline routers.
5.3.3 Roles
People in the following roles have direct access to the Helpline Network. All
are in the Girobank Helpline area of the campus and all use NT workstations.
All are Girobank personnel except the engineers.
Role Main functions
Helpline Advisor Authorised transactions on PAS/CMS in response to calls
Viewing of on-line documentation such as procedures,
bulletins
Helpline Advisor As above, but with access to NSI data
(NSD
Helpline Supervisor As Helpline advisors plus:
- extra transactions at PAS/CMS
- access to more local documentation.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 53 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
- access to local applications
- applications analysing Rockwell ACD data
Helpline Manager As Helpline Advisor, plus use of more local documents and
local office applications.
Helpline Security Maintain information about Helpline users locally and in
Manager PAS/CMS.
Auditor for local systems
System & Network Manages Helpline NT Network - installation and
Administrator operational management.
Base software installation and configuration. Distribution
of software (including Oracle Forms) from Helpline
Servers to workstations.
Management of local routers etc
Engineer Hardware diagnostic and repair
5.3.4 System Access Controls
The NT workstations and servers belong to an NT domain. The domain
controller is an NT server which has NT user groups and profiles representing
the defined roles. All users are registered individually at the local domain and
associated with the relevant group.
All users of the Helpline workstations must log onto the local NT domain with
an individual NT username and password. The profiles restrict what
applications, including what Oracle forms for accessing PAS/CMS, are
available to each user.
All users authorised to use PAS/CMS are also registered at the Oracle database
and set up as a member of the appropriate Oracle role which has the required
access to the agreed Oracle tables/views. Users must log onto Oracle with a
password, prior to using any of the Oracle Forms. Oracle controls for these
different roles are defined in 5.2.2 above.
Engineers are not individually registered at the NT system. They log onto the
NT system using a specially allocated username and password and are
supervised during their access to the system.
5.3.5 Other Access Controls
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 being discussed and are
not yet finalised.
Contacts with these people are shown in the following table.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 54 of 116
FUJ00087989
CAOFFICE\ACCP2.DOC
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Contact Function How authenticated
Customers I Queries and reports about I Response to a number of verification
cards, PUNs. e.g. card lost I questions asked by the Helpline Operator
or damaged. as specified in [SADD].
Members of I Reports such as found card I No caller individual authentication
the public normally (as the caller may not be
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 Correct responses to questions based on
Post Office I extended verification e.g. information held at the Helpline about
for foreign encashment. Post Offices - see section 3.5.2.
Reporting on failures &
anomalies
PO staff on I Queries and reports about I As above for verification of Post Office
behalf of cards ete staff plus customer verification
customer information.
DSS/BA _I Enquiries on cards, Correct responses to questions based on
payments. Request to stop I information held at the Helpline about
cards, payments etc DSS sites/people. / details tha -
expected to need extra verification if
Nationally Sensitive data]
BA for As customer queries and See above for verification of BA staff,
customers __I reports plus customer verification information
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
Page 55 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
6. OFFICE PLATFORM SERVICE DOMAIN
6.1 Introduction
The Office Platform Service Domain is illustrated in figure 6-1.
Correspondence servers
at Pathway central sites Remote
System
t Management
Aa
NT i
Counter
Infrastructure
(Riposte
journals etc)
Applications
APS,EPO SS
OBCS, BES
Customer
Payment Card J
: Post
Helpline Mir) Office
‘ staff
Horizon
System vir)
Help desk *
On-line
documentation
I —- Auditors and
Emergency Manager
[-— Support Engineer
Installation
Engineer
Figure 6 - I 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 and security managers 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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
CAOFFICE\ACCP2.DOC
Page 56 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
6.2
Post Office Systems are monitored and managed via the Pathway System
Management Services using Tivoli. This is 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 9.3 and 9.7.
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:
e 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.
¢ Counter clerks who run the APS, EPOSS, OBCS and BES applications.
¢ 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.
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 6.4)
[ Role I Main classes of functions I
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 57 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Manager 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 As Counter clerk functions with special training data
training mode (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 (Exel) _I Office personality.
Support Replacing peripherals etc and running diagnostics to check
engineer functioning correctly.
(CFM(DS)) 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.
6.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 6-2.
ISDN (or other) Link
rl St _
a at
NT workstations
Figure 6-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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 58 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Ina 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 made using the CHAP initial connection
authentication protocol as defined in [SFS].
The following table shows which services are permitted on this link.
Service Type of access
Auto-configuration on Post Transfer of auto-configuration information
Office roll-out e.g. from Boot server - see 9.6.
Key distribution from KMS Key management protocols protect keys in
transit as defined in [SFS]
Transfer of business Automated using Riposte TMS features
information to/from
correspondence servers
Distribution of help Via Riposte TMS
documentation and training
mode data
System management via Automatic using Tivoli. Scripts and software
Tivoli including software are signed for integrity protection.
distribution
Gathering diagnostic data for I Read access only to required data (NT event
application support logs) via Tivoli.
6.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.
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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 59 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
6.5
6.6
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 cach counter of the largest Post Office). There will also be a special
Set-up Manager user used during Post Office installation - see 6.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 9.6). It is not possible to log-on to NT or Riposte.
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 9.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.
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.
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.
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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 60 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
6.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.
¢ 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
e the password cannot be the same as the username.
e 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 workstations.
In NT and Riposte, there is no direct support for roles, so these are represented
by user groups - see 6.4. Users are maintained using Riposte, which causes
equivalent users to be maintained in NT.
Role Function Where users I Authentication Resource access
defined needed controls
Installation I Start up Post Not in system I Manual procedures I Auto-configurer
Engineer Office (see note 1) application only
Post Office Post Office Not in system I Manual procedures I Memory Card and
Manager installation set up application
only (see notes 2-
4)
Normal Riposte user; I Riposte username I Relevant Riposte
Manager in Manager and password (see I applications only
functions and I group note 5)
key changes
Emergency Riposte user I Riposte username I All Riposte
procedures in Support and one-time Manager
(see note 5) group password functions
Counter All functions Riposte user; I Riposte username I Relevant Riposte
clerks and member of and password applications only
Supervisors relevant
roup
training mode I Not no separate log-on I Relevant Riposte
separately from live applications with
defined application use training data
All Workstation Not in system I Memory Card and I Workstation start
permitted start up PIN (see notes 2-4) I up only
PO roles
Engineer running Riposte user I generic Engineer Relevant Riposte
diagnostics Riposte username I diagnostic
& one shot application only.
installing new password (see note I Auto-configurer
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 61 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
hardware 6) application
Auditors All functions Riposte user I generic Riposte Relevant Riposte
Auditor username I applications only.
with one time
password (see note
6)
Emergency I Workstation not in system I Memory card and I Start up
Manager start up PIN (see note 7) application only
other functions I Riposte One time password I Riposte
eneric user 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. Use of Memory Cards on installation and workstation startup is further
defined in [SFS]. More information about Roll-out in general is included in
section 9.6.
1. The Post Office Manager is expected to secure the Memory Card and PIN
for it in separate places.
1. Ifthe Manager looses his card or PIN, emergency recovery procedures
require the Manager to get an emergency recovery key from the Horizon
System Help Desk.
1. Ifthe Manager loses his password, he logs in using a Support username,
using a one-time password (see note 6), to reset his password on his normal
user name. In the absence of the Manager, this may also be used 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. Ifthe 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. Ifthe 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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 62 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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.
All Riposte transactions, including user administration, are logged in the
Riposte journals. On adding a new user, a full name must be supplied.
6.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 9.9 (for the Horizon System Help Desk).
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 63 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
7. INTERFACE DOMAINS
The ICL Pathway project interfaces to systems run by other organisations at
their sites as part of normal operation. These are:
e 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.
¢ 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 9.5)
and interface PCs are managed using Pathway System Management (see 9.3).
7.1 DSS Service Environment Domain
The DSS Service Environment Domain is illustrated in figure 7-1.
Pathway
Data ICL Series 39 EDS Pathway
Boundary VME ' Management
' rary
DSS Partition ™\ Pathw ay Partition I Boundary
DSS applications! Pathway Access ,
CAPS or ESNS! Service Firewall)
—L iL
Local LANs ' T Routers
'
'
'
DSS/BA site
y
To Pathway Data Centres
Figure 7-1 ccc . DSS Service Environment Domain
The DSS Service Environment Domain provides the interface between
Pathway and the Benefit Agency’s CAPS and ESNS systems at DSS sites.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 64 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
In both cases, applications in the Pathway partition of the VME machines (the
VME part of the CAPS Access Service (CAS) and the OBCS Access Service
(OAS) handle:
e 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 Access Services on VME
and the part of the Access Service at the Sequent operational system at the
Pathway Data Centres.
© On-line transactions from DSS/BA staff to PAS/CMS.
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.
This domain at DSS sites includes the following components:
¢ The software running in the Pathway partition of the VME platform, and
e The Pathway routers used to route traffic to/from the Pathway Data
Centres. These are managed by Pathway Network Management as described
in 9.5.
7.1.1 Roles
The DSS VME systems are run by EDS, so EDS are responsible for the main
systems administration on 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.
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. 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:
© Monitoring of the VME partition and supporting applications there. 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 9.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 65 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
¢ 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.
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 will also be 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.
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 the Pathway Data Centres and the DSS site
are:
¢ File transfer between the relevant VME service and PAS/CMS and OBCS
on Sequent.
© SQL*Net traffic supporting the CAPS on-line service
e Interactive (MAC) access for management, support and auditing
¢ Network management traffic to the routers.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 66 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
7.2 POCL and POCL Clients Domain
Pathway has links to POCL and POCL Client systems. These are:
¢ The POCL TIP system to which records of transactions at Post Offices are
sent
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:
¢ 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
POCL or
POCL Client }} I .
systems Pathway Router &
interface PCs firewall ,
4 I
Routers . Pathway Data Centre” _
POCL or POCL Client site other Data Centre
Figure7-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.
There are some differences between these sites as follows:
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
e The POCL Client links are expected to be ISDN ones with an ISDN card in
the Pathway interface PC, rather than a separate router.
Cryptographic protection of these links is summarised in 9.10 and defined in
[SFS].
7.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:
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 67 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Role Main function
7.2.2
7.2.3
7.3
Key Custodian (Pathway) I Installing new keys and changing keys (for
systems where file transfers are encrypted)
Key Handling (POCL or I Re-installing keys on re-booting PCs (for systems
POCL Client) where file transfers are encrypted)
Engineer Installing or replacing PC. The PC will not be
repaired when configured into the operational
system.
Control of Connections to the Pathway Data Centres
Only the following traffic is permitted between the Data Centres and these
sites:
e The file transfers between Pathway hosts (TPS, Reference Data and APS)
and the POCL/POCL Client systems
e System Management traffic to manage the PCs using Tivoli
¢ Network management traffic for router management
In all cases, traffic is controlled by routers and firewalls 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.
Control of Connections to POCL Systems
Access from the POCL systems uses FTF. 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.
De La Rue Card Services Domain
The De La Rue Card Services Domain is illustrated in figure 7-3.
De La Rue I Pathway ioe Sua"
boundary t
1
De La Rue Pathway Router & Interface I!
systems interface PCs firewall I PC !
SN “x Routers Pathway Data Centre I
Zip media
De La Rue site other Data Centre
Figure7-3 De La Rue Card Services Domain
Printed: 25/02/98
C:AOFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 68 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
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.
7.3.1 Roles and System Access Controls
Roles supported on the Pathway PCs are as in 7.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 7.2.2
above.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 69 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
8. PATHWAY CORPORATE SERVICE DOMAIN
8.1 Introduction
Pathway’s own processes include management ones such as accounting,
monitoring service level agreements and asset management. They also include
Auditing and Security processes such as Fraud and Risk Management and
Security Auditing.
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).
8.2 Summary of Pathway Corporate Roles
The following table lists the Pathway Corporate Roles.
Role Main Functions
Pathway Management I Access to management information such as finanicals,
staff service level agreement data.
(There are multiple roles depending on particular
management functions.)
Pathway Management I Managing the setup of the management information
support/ services (e.g. setting up Business Object Universes). Also,
providing the DSS/ POCL interface for management
information - including provision of management data
regularly and on request.
Pathway Business Handling financial reconciliation of payments (e.g. wrong
Support payments due to service breakdowns) and generating
contingency payments authorisations when CAPS is down.
Pathway Fraud Risk I Identifying and managing fraud - sce section 8.4
Management (FRM) (staff_are from Pathway project and Girobank)
DSS Fraud. Identifying and managing fraud - see section 8.4. (A DSS,
Investigation Team not Pathway, role. Included here as access is similar to
(DSS FIT) Pathway FRM)
Pathway Business Operational and commercial audit of Pathway - see section
Function Auditor 8.5.
Pathway Security Monitoring and investigating security events - see section
Event Auditor 8.5
Other Pathway Generation and distribution of cryptographic keys
Security Management I Installation and changing of cryptographic keys
roles Control of security tokens.
Responding to Data Protection Act requests
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 70 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
All the corporate users are located at the Pathway management site (Feltham).
Their workstation controls are shown in the following diagram.
Pathway Managem ent site management users I
4 4] Bc Corporate
workstatations wifh access Network ete
to other serv}ces
Security, Audit and FRM users +
management & business support users
Z v7] Zl firewall I
secure LAN
Fouter and
rypto box
Data Centre system(s)
Figure 8-1 Management user workstation controls
8.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.
8.2.1.2 All such users should authenticate using a token.
8.2.1.3 All workstations on the secure LAN are NT workstations set up to Pathway
standards. These restrict access to permitted functions for that user and have
floppy drives disabled for booting.
8.2.1.4 Management users with only read access to services such as the Service Level
Agreement Monitoring system (SLAM) may access these management services
at the Data Centre providing the firewalls and routers restrict them adequately
to the required services on the particular management machine.
8.2.1.5 DSS FIT staff may access the FRMS service from their own site. If so, remote
access should be from a secure DSS area, using controlled NT workstations,
via an encrypted link.
Sections 8.3 to 8.6 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 8.7 below gives the access controls associated with the Management
Information Systems.
8.3 Corporate Management Users
Most Management users use only the MIS systems described in 8.7 below.
Their access controls are therefore included in that section.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 71 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
The Business Support role requires access to information about customer
payment authorisations and Post Office transactions. Access will normally be to
copies of this data held in the Data Warehouse. However, access will
sometimes be required to the TMS journal on the Correspondence servers and
to PAS/CMS database. Relevant data may need to be downloaded at the
request of Business Support to the SSC reference system (see 9.7) and a flat
file of transaction adjustments generated there for forward transmission to the
Data Centre and back to CAPS by SSC. Business support also initiate
generation of emergency payments from PAS when CAPS is down.
8.4 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.
¢ Regular reports on aspects of the system which are relevant for fraud e.g.
weekly trend analyses and daily exception reports
e Ad hoc selective reports according to agreement
e Access to the Fraud case database, 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 summaries and the
Fraud Risk Management Service as described in 8.3 above. 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.
© The TMS journal of Post Office activity
¢ 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.
8.5 Auditing
Pathway activities are audited to ensure they are functioning correctly, for
example, that the controls in the system are working effectively. Some auditing
is of internal Pathway activities, while some is of interest to external (POCL,
DSS and NAO) auditors.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 72 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
The POCL and DSS 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.
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 Pathway Business Function Auditor also provides the interface to external
auditors for access to Pathway Data Centre systems, accessing these systems
on behalf of the external auditors to provide the information they need.
Note: design in this area for future releases is not yet complete, and so is subject to}
change.
8.5.1 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.
Pathway Security Event Auditors will access audit logs generated at many
Pathway machines as outlined in the following diagram.
PO systems fain NT DataI I Sequent Servers I I Other systems
‘entre SystemsI
EPOSS IRiposte utilsI PAS, CMS,
Applications I applications ‘Agents DW, MIS ete
. Riposte Riposte, Oracle, FTF KMS,
Middleware P fip etc Bus Objects, etd I I Firewalls ete]
(System) Tivoli, Tivoli Patrol Open View
Management I I bootup s/w COS Manager ACE svr etc
Operating NT ]J}{ NT JI{[ Dynix} PNIX, Nee}
system
Figure 8-2 Where audit records are generated
Audit logs include:
© 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)
¢ Logs recording system level activity at Pathway Data Centre systems such
as user logon and administration and other security relevant events
e Logs at relevant Pathway internal systems e.g. Configuration Management.
¢ Manual records associated with IT access.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 73 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Some events, including all those which should cause an alert to the Security
Event Auditor, are collected centrally using Tivoli (via Patrol and Openview
where needed). The technician monitoring the systems management
workstation will inform the Security Event Auditor of specified types of
significant events. However, some events records will remain in local audit
logs.
The Security Event Auditor will need to be able to access/extract audit data
from all these and their - see the following diagram.
Pathway System
—
software generating
audit records L
a
local audit facilities []
Ocal audit service
trails scchive
Tivoli Event Service
Selected audit data
I — Security
Auditor
System Management technician Manual records
monitoring events
Figure 8-3 Auditor access to audit information
Auditors can access logs at Pathway systems as described above. They are
registered at each system/domain accessed and can access only the audit logs
there. Note that the Security Event Auditor will not have direct IT access to:
¢ 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.
e The interface PCs at POCL and De La Rue sites: management of these will
be recorded in the Tivoli logs
\Note: More detail of audit access will be provided when the Audit design is available.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 74 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
8.6 Security Management
Pathway Security Management are responsible for Security Auditing of
Pathway (see 8.5 above) and also:
e Management of the cryptographic keys used in Pathway
¢ Management of the Security tokens used for authentication of some users
(see 3.4.2.5)
¢ Responding to requests under the Data Protection Act, providing the subject
information required.
8.6.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.
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 Manager I Generating or obtaining cryptographic keys
and organising their distribution.
Cryptographic Key Custodian I Initial installation of cryptographic keys
where this needs to be done manually.
Periodic update of these keys.
Cryptographic Key Handler I Handling part of a split cryptographic key
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 4.6.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 75 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
All Cryptographic Key Custodians and Key Handlers access the systems in a
similar way as defined in the following table.
Role Workstation type I Authentication I Resources available
& location method
Key console at the NT (or UNIX) I Functions to install and
Custodian platform with key _I with token change key
Key Handler I None None Media containing key during
re-installation of key.
Note: Some parts of the cryptographic design are not yet complete and are subject to
change.
8.6.2 Management of Security Tokens
Note: This section will be included in a future version of this document and is
expected to reference a related user registration process
8.6.3 Data Protection Act Requests
Note: This section will be written when it is agreed what data must be provided in
response to Data Protection Act subject requests.
8.7 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 8-4.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 76 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
TMS PAS/CMS Reference Call info from etc
journal Data data help desks
Dy ta lr ee f
MIS Services
Pathway (Sequent and NT) “os
Management Accounting, Asset ecu
Management
Pathway management etc
Man Suppor Fraud Risk
Pathway Management Service System and
Business Support i i Operational
IQuery/Reporting ServiceI }-——— Management
Pathway FRM
& Engineers
& DSS FIT =
SLAM cache (on NT)
Pathway - A Application
Auditors ———I Financials (not at Centre) Support
Figure 8-4 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:
Data from TMS journals about Post Office transactions (see 4.8).
Data from the Reference Data Management System (see 4.7)
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.
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 EIS/Financial service and to the Service Level Agreement
Monitoring service (SLAM cache) which is on an NT system at Wigan.
Printed: 25/02/98
C:AOFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 77 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
8.7.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 Computer operator,
Operational Management, Security Management, Oracle 3" line support, Dynix
3™ line support and Engineer roles are as defined in 4.2.
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.
Application support is similar to the applications on the operational systems i.e.
SSC provide 3" line support for all applications and the application supplier
provides 4" line support. In this cases, this is:
¢ Oracle for all Oracle applications
¢ CFM for Business Object applications used to support queries on the data
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.
The following table shows the access controls for the Management users of the
MIS systems.
MIS system Role Authentication method _I Resources available
Pathway management Depends on application I Read only access to relevant
(Sequent & NT) e.g. Oracle, Business data for specific service only.
Objects, SLAM
Pathway management Token plus application I Business objects (include
support (Sequent) authentication update); data download......
Business Support (DW) I Token plus app Customer, payment data
FRM (Sequent MIS & I Token plus Oracle/ FRMS service; database,
DW) Business Objects reports, queries etc
DSS FIT (Sequent Token plus Oracle/ FRMS service (Selected other
MIS) Business Objects data and reports off-line)
Pathway Business Token plus system Audit trails
Function Auditor (all authentication
systems)
Security Auditing (all _ I Token plus system Security Audit logs
systems) authentication
8.7.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 EIS/financials system.
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 78 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.1
9.2
SYSTEM MANAGEMENT AND SUPPORT
SERVICES DOMAIN
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)
e 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.
¢ 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 System.
e Software and Configuration information release and 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.
¢ 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.
¢ 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 cach 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.
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 9.6).
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 79 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
PO counters a ae
CEM Sie a jig — Engineers
etc —
Horizon System “ Sig 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
E BB
HP OPENview
system/ E E & Cisco Works
operational R Ss on Solaris
management Ss R
Maestro Routers
job scheduling
‘Sequent Machines [Paro] NT Systems NT
running Correspondence Post Office
PAS/CMS, MIS Servers ete counters
Figure 9 - 1 System Management Service Domain
In the figure,
¢ 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)
¢ 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 9.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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 80 of 116
ICL Pathway
FUJ00087989
FUJ00087989
Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.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:
For planned activities such as distribution of a new software version.
Where monitoring the events in the system shows action is needed.
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
In all cases, technical incidents are managed using the call management system -
see 9.9.
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 tool
used here is the Powerhelp system - an internal ICL one.
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:
Pathway Data Centr
System Management (or support) secure site
Lf] 4] 4] 4] + ICL Corporate
Network etc
4] secure LAN
‘outer and
crypto box
frouter and
Icryptp box
Data Centre system(s)
Figure 9-2. system management workstation/network controls
The technician often has two workstations connected to separate networks:
Printed: 25/02/98
CAOFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 81 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
¢ 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
call management system.
The system management technicians work in a physically secure area
In the rest of this section, only the controls associated with the NT
workstations which can access the Data centres are shown.
All system management users managing Data Centre systems authenticate
using a token.
9.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.
9.2.1.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.
9.2.1.2 All requests for support should be recorded in the call handling system (see
9.6) and their progress reported there, including who was called out and the
actions taken.
9.2.1.3 Routers will by default be configured to prevent access from support
organisations other than CFM(NI) from the standard Belfast site, CFM(DS)
from the standard SMC site and SSC from the standard SSC site. 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 dis-allow it
after use.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 82 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.3
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 9-2.
Counter clerks
DSS Sir) Horizon System Help Desk
Cz
SMC Technicians for PO
(incl SMC Help Desk) [erin for PO support
}___ System Admin
NT Workstations Engineers etc
Tivoli client
system management NT Systems
Security Services
exchanges
Tivoli System Management Servers I Auditors
at Pathway Data Centres
software for_,I e Application
distribution NT TMR servers Sun/NT servers ]}— Support
Software distribution} I Event management
auto-config en . I__ Operational
— :
information Tivoli users admin Hardware & software Managem ent
inventory
Engineers
Managed Systems
e.g. Post Offices, correspondence servers
Figure 9-3 Interactions for Tivoli System Management
SMC technicians perform system management activities because:
¢ System management actions have been planned, for example, the
distribution of software or the implementation of Post Offices.
* Monitoring of the system identifies some action is needed.
¢ The Horizon System Help Desk passes on a call about a technical problem
which requires resolution.
Software is sent to Tivoli from the Configuration Management system - see
9.6. Configuration information for implementation of Post Offices comes from
the Configuration Database ( see 9.6) and is used to generate Riposte/Gateway
relationships in the Correspondence Servers. In both cases, SMC technicians
control the onward distribution of the data.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 83 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/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 6.7.
9.3.1 SMC and Roles at Tivoli Servers
The SMC technical system management roles with access to the IT systems are
as follows:
Role Main Functions
SMC technician or I Monitoring the system - software distribution, the auto-
technical specialist configuration process and other system management events.
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 team I For software distribution, authorise targets for distribution,
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 6.7.
Assisting in Post Office key recovery - see 6.7 and 4.6.
SMC MSS technical I Handle receipt of software and auto-configuration
support information.
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 Manager User administration - adding SMC and other users to the
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.
© Only SMC Managers Can authorise creation of new Tivoli tasks.
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
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 84 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.3.2
In addition to the SMC technicians listed above, 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.
Pathway application support I Support of Post offices counter applications
(SSC) using events collected via Tivoli.
Residual operational mgt of I Installing and configuring base software when
Tivoli servers (CFM) this cannot be done by SMC c.f. 4.4
Engineers Hardware diagnosis and repair
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 9.2.1. These
workstations and the Tivoli NT servers form an NT domain with the Primary
Domain controller at one of the Data Centres. All SMC staff using these
workstations are authenticated to the 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 residual operational management of Tivoli servers is done by CFM as for
other servers at the Data Centre, as specified in section 4, so is not included in
the following table. Engineers are not included for the same reason.
Role Workst’n & I Where user defined; I Resources available
Location Authentic’n needed
SMC technician, I NT - SMC NT and Tivoli user; Tivoli/Oracle facilities
tech specialist, secure area I NT authentication for authorised functions.
and team leader with token (No NT/UNIX tools)
SMC team as above NT with token at PO recovery application
leader: PO key SMC; also user of at KMS
recovery KMS
SMC team Specific NT user at specific Specific application only
leader: one-shot I security system.
password auth. system
SMC MSS as above as SMC technician Tivoli/Oracle facilities
technical support above for authorised functions.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 85 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Authorised NT/ UNIX
tools.
SMC Security as above as SMC technician Tivoli and OS user and
management above role administration
Pathway Auditor-I NT at NT and Tivoli user; Read access to audit
see 8.5 Pathway NT authentication information - platform
corporate with token audit logs, Tivoli notices,
site Tivoli events collected
for auditing
SSC application I NT at P’way I NT and Tivoli user; Pre-authorised Tivoli
support - see 9.7 I secure site I NT authentication tasks to extract
(Bracknell) I with token diagnostic information
from the Post Office.
[Note: details of Auditor access to these servers has still to be agreed.
9.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 9.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.
9.4 Sequent and Oracle Management
The components involved in the management of the Sequent systems at the
Pathway Central sites are illustrated in figure 9-3.
Tivoli
Event Management ete
UNIX and
Qracle Events bb
Management scheduling
Segyent Machines
Security Management Patrol with Tivoli Maestro initiating
Engineers ~~I] Event Adapter I Ijob scheduling jobs at
etc I I Agents
PAS, CMS, MIS ete
on Oracle databases
Figure 9-4 Sequent, Oracle and VME management
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 86 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Patrol is used for system management of both Dynix and Oracle. (It is expected
to be used for all Oracle database administrator functions. The associated
workstation is used for monitoring the system and taking any action if needed.
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.
9.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 e.g. what
users need to be known there. Further roles associated with the Sequent
systems are also defined in 4.2 including Security Management and Engineers.
People carrying out these management functions from a remote site use secure
NT or Sun workstations via encrypted links, tokens etc as defined in 9.2.1.
Access for staff on call is according to the procedures in 9.2.2 above.
9.5 Network Management
9.5.1 Introduction
The Pathway network routers are managed using HP Open View with Cisco
Works as illustrated in figure 9-4 below.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 87 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Data feeds e.g. , ‘colt
PO addresses & Events to Tivoli Date ott
keys on rollout ] 8 8
Network Manager Sun, UNIX +——— Security Manager
- HP Open View
Network Technician System Administration
Cisco Works
Network Management
TACACS [-——— Engineer
Configurer
ty 2 e dl Ronee
ISDN Cisco Access WAN Routers
Routers Servers routers at DSS ete
{ {
ISDN Adapter] PSTN connected Girobank DSS, POCL
at Post Office Post Offices areas & De La Rue
ete systems
Figure 9-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, as are the CHAP keys required.
The main roles are:
e Network Manager responsible for configuration and management of the
routers
¢ Network Technician monitoring the routers
¢ Network Management Configurer responsible for the configuration of the
Network Management System itself, for example, Open View configuration.
This role is carried out by the Network Management team before live
running.
The configuration of the network management will be validated by more
than one CFM technician and signed off by a senior CFM person before use.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 88 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
¢ 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 9.5.4 below
Engineers may also require direct access to routers - see 9.5.5.
The network management staff are also responsible for configuration and
management of the firewalls.
Note.
more information about firewalls will be given in a future version of this
document.
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 9.8.
9.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) Functions
Network Technician I Monitoring the network
(CFM)
Network Manager Monitoring the network.
(CFM) Updating router configuration information when required e.
™@ - 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 9.5.5 below)
Network Management I Configuring Open Vi
Configurer (CFM) @ - what to display to wh
@ - actions to be taken on certain events
etc.
Configuring Tivoli Event Adapter
Security Manager Maintain user information for those users permitted to use
(CFM) this system - both UNIX users and Open View users.
Local auditing of network management activities at this
system
System Any administration/configuration which cannot be done
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 89 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Administration 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.
9.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 System. The following table shows how the users
defined above access the system and what is available to them.
Administration
Role Workstation Authenticat’n method I Resources available
type/location I & where user defined
Network console at OpenView userlogon I Specified Open View
Technician NMS and Cisco Works
functions only
Network as above UNIX & Open View I Open View and Cisco
Manager as individual user Works network
management
functions (no direct
UNIX access)
Network Manag’t I as above as above Open View configurer
Configurer functions
Security Manager I as above as above User information and
resource access
controls
System NT at Belfast I UNIX after NMS All UNIX facilities
configured to stop
managing the network
Engineer console at UNIX via special No UNIX/Cisco
NMS. password c.f. Sequent I works access
systems
Notes:
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.
9.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:
Printed: 25/02/98
C:AOFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 90 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
¢ 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 9.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).
9.5.5 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.
Ifa router has a fault, it will be configured out of the network and then a
console 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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 91 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
The password used for direct console access is changed via the NMS 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.
9.5.6 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.
[Note: controls for firewalls will be added in a later version of this document.
9.6 Software and Configuration Release and Distribution
Pathway releases software and/or configuration information in two cases:
e Implementation of new Post Offices. In this cases, the Post Office counters
are delivered with a standard configuration which needs to be personalised
and updated when installed. This roll-out process is mainly automated and
involves initial set up of IP addresses, routers and cryptographic keys. This
process may also be used for certain types of major changes to Post Offices.
¢ 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.
9.6.1 Post Office Implementation
This Access Control Policy is concerned only with those parts of the Roll-out
mechanisms which affect the operational system. These are illustrated in figure
9-6.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 92 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Pathway Roll-out Auto
Supplier Support Desk configuration
manager
POCLand__yJ_ Rollout database
other info 1
Configuration database
Dispatch-1
(for engineers) Signing Server
depot/Tivoli server
Other systems
including KMS
Generic
PO Boot server
Software PO} config info} & KMS exchanges
soflware updates
Post Of ¥ ¥
PC with y i
= software installed] Auto-configurer
*) ——_>
Factory
Intallation Engineer
Post Office Manager
Figure 9-6 Interactions on Roll-out
The information about roll-out of Post Offices is managed in the Roll-out
database which takes input from POCL and other sources. Pathway suppliers
can also update this database (via bulk transfers) and view it.
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. When the Post Office Manager takes
over and first boots up the Post office, the keys for standard running are
delivered from the KMS.
9.6.2 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 9-7,
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 93 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Configuration software &
librarians onfig changes:
Configuration Pathway ref. data
Management
Software
ra test rigs
\depot/ Tivoli server-—— Other systems
Tivoli exchanges
Post\ Office
Tivoli
Figure 9-7 Software Release
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 9.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
9.6.3
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.
Release and Distribution Roles
Roll-out is controlled by the Pathway Implementation Operations unit (IO);
Configuration by the Pathway Configuration Management unit (CM).
Role (Organisation)
[ Function.
Roll-out Support Desk
technician (IO)
Handle calls from Pathway Suppliers and Post Offices -
forwarded from Horizon System Help Desk).
Queries and updates on Roll-out database (e.g. change
PO installation date.)
Pathway Implementation
suppliers
Read access to parts of the Roll-out database.
Update access to specific data for particular supplier
Auto-configuration
Manager (IO)
Control the auto-configuration process. Note that
updates to different places may be done at different
times.
Configuration Librarians
Control versions of software at the Configuration
(CM) Management system
Software Distributer Initiates signing and distribution of software
(CM)
Key Custodian and Key
Handler
Install keys at Signing Server
(Note that these are the same key custodian and handler
roles as for other systems - see 8.6.1).
Printed: 25/02/98
CAOFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 94 of 116
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
In addition, operational management, security management, engineers and
Security Event Auditor roles etc supported for these systems (Roll-out
Database, Auto-configuration, Configuration Management, Signing Server and
Boot Server) as defined for other systems in Chapter 4.
FUJ00087989
FUJ00087989
9.6.4 System Access Controls for Human Roles
Role Workstation I Authentication Resources Available
type/ location I method
Help Desk NT with password I Roll-out database; read and
technician update
Pathway Various at NT with password I Roll-out database;
Implementation I suppliers’ site includes update access
suppliers
‘Auto-config NT with password I Configuration database
manager functions
Configuration NT with password I Configuration management
manager system functions
Signing server NT in secure I NT with token Signing server functions
area
(Feltham)
Key custodian & I console at see 8.6.1 see 8.6.1
key handler signing server
9.6.5 System Set-up
System access controls must conform to the policies in 3.
As for other NT systems (see 4.4), NT servers are set up with a template user
for each of the roles above relevant for that system/domain.
Implementation suppliers access the roll-out database via the controlled
routers/firewalls at Feltham - see 9.10.3. Software delivered electronically to
the Pathway Configuration Management system is also controlled via these
routers/firewalls.
9.7 Application Support
9.7.1 Introduction
The main interactions of people involved in application support are illustrated
in figure 9-8. Note: this does not cover support of network boxes such as
routers (see 9.5) or the symmetrix discs (see 9.8) or support of Dynix (see 9.4)
Printed: 25/02/98 RESTRICTED-COMMERCIAL,
C:A\OFFICE\ACCP2.DOC Page 95 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Pathwa secure site ICL Corporate
Network
SSC technician, 7]
£] secure LAN ‘Other support
. sources ¢.g.
1] #] Microsoft
if i
routers and I test rigs & I
crypto boxes reference sys
r
I Other secure sites (e.g. CFM, Oracle) I
‘ authorised secure LAN I L]
‘support staff GN
Pathway Data Centre
[
routers and
rypto boxeg
—
' DSS CAPS/ESNS site
; Pathway VME partition
algal: with CAS, OAS
software
Figure 9-8 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 read 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 9.6).
CFM provide first line support for most systems and application support for
some Sequent and all VME applications. Other units provid‘ 3rd and/o' 4th line
support for particular applications and packages.
In most cases, application support from units other than CFM and SSC is done
off-line from the operational systems, though Oracle 3rd/4th line application
support can be on-line.
All support staff (SSC, CFM and Oracle) access the Data Centre systems from
secure sites using NT workstations on secure LANs separate from any other
systems use (see also 9.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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 96 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.7.2
9.7.3
9.8
SSC also assist Pathway Business Support when doing financial reconcilations -
see 8.3. SSC, on request from Business Support, download to the reference
system and files of transaction adjustments may be 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 9.10).
Roles
Application support roles are included in the relevant sections of the ACP.
There is an SSC support role, and further roles for CFM and Oracle.
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.
System Access Controls for these Roles
All application support users access Data Centre systems via secure NT
workstations as described above. SSC, CFM and Oracle support staff access
the Data Centre from other sites and may need to see DSS data. Therefore all
these support users should authenticate using tokens.
All application support users have 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). Update access to correct errors is by re-issue of a new
version of the software via the Configuration management system.
No application support users have access to Post Office counter systems -
errors here are diagnosed using logs of events extracted via Tivoli.
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 laterI
version of the ACP.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 97 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.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:
¢ The Roll-out Support Desk which deals with the specific issues of installing
Post Offices. This is described in 9.6.
9.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 - see the call matrix in[HHDM]. (An associated internal Pathway SMC
Help Desk handles internal queries from Pathway systems management users
and takes action on these and queries passed on from the Horizon System Help
Desk. This uses a subset of the Horizon system help desk functionality, so is
not separately described.)
The Horizon System Help Desk is distributed between at least two sites, one of
which is at Stevenage.
The main interactions of Help Desk staff using the IT systems is illustrated in
figure 9-7
Counter clerks Workstations for Powerhelp, Dispatch-1 etc
DSS &, £]
CFM ete“ / J I I . ICL Corporate network
Horizon System NT workstation with Pathway applications
Help Desk (Help Desk versions)
1 1 1 L
Figure 9-9 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.
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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 98 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.9.2 System Set-up
Horizon system Help Desk technicians are in a secure SMC area as for other
SMC system management staff - see 9.2 and 9.3 above.
9.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
© POCL offices
© 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.
9.10 Network Access Controls
9.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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 99 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
DSS sites Pathway Data Centre y
(CAPS,ESNS) ° I_I cane
‘orporate
Mgtsite
POCL sites 7
(TIP, ref. data, AP) Sequent NT
operational I I operational Pathway
ems syste support
POCL Client sites I sevens sysems seen site
Payment Card] I I Cororate security
Management
Helpline services Pathway
systems I_I
system met
(Girobank FRM. sites
system & Rollout
network mgt °
De La Rue panei systems I_[ Other support
card production _ sites e.g. Sequent
Royal Mail routers, firewalls, erypto boxes BH other Data Centre
Post Offices
Figure 9-10. The Pathway network.
All links to the Data Centres are controlled by routers/firewalls.
9.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.
© The Payment Card Helplines and Girobank FRM systems are in Wigan and
Bootle, so data in transit to them does not need encrypting.
¢ 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 integrity protected and has strong
authentication. Payment authorisations and also software and configuration
updates distributed via Tivoli are digitally signed.
Other general policies for protection of links are:
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 100 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.10.2.1 All Pathway Corporate management, system management and support sites
have fixed links to the Data Centres.
9.10.2.2 External support sites with access to the main operational Pathway systems
also have fixed links to the Pathway Data Centres.
9.10.2.3 All such fixed links are protected using Zergo encryption devices using
Rambutan.
9.10.2.4 AILISDN links use CHAP authentication and CLI.
9.10.2.5 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).
9.10.2.6 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.
9.10.3 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.
Pathway Data Centre DSS sites
ey POCL TIP ete
NT Sequent WAN i other
operational I I operational Routers RT Data Centre
systems systems
Girobank
security Corporate Helpline
. Management
services systems
LAN y
itch
pep I Rollout I Iactwork met
systems 8 [_ Cisco
systems
POCL HAPS
[ i [
ISDN & other I ISDN Rous Routers & [}-— CPM
[Routers for POsI for other links typto boxes SMC
Pathway
Post Offices POCL De LaRue Royal Mail Other support
Client system sites
Figure 9-11 The Pathway Data Centre Network
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 101 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Note that the above diagram does not show:
e 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.
© Tthe actual network outside the Data Centres such as the Energis backbone,
or the ISDN network as these do not affect the access control policy.
¢ Some users where more information is needed e.g. DSS FIT
Traffic into and out of the Pathway Data Centres is mainly controlled by access
lists in the routers and firewalls. These are also used within the network, and
there are also controls on the use of ports at particular systems.
\Note. Configuration of the routers and positioning and configuration of the firewalls is
still being discussed and is subject to change.
The links into the Pathway Data Centre should be configured to achieve the
following.
9.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.
9.10.3.2 DSS and the POCL TIP/Reference Data link use a secure envornment provided
by the Energis ATM network. The closed user group restricts access to
Pathway only.
9.10.3.3 Links to other services such as POCL HAPS, De La Rue and Royal Mail are to
PCs at the Data Centre which should be on a LAN which is firewalled from the
main Data Centre Systems
9.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.
9.10.3.5 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).
9.10.3.6 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.
9.10.3.7 The Girobank Help Desk users should be restricted to only Oracle Forms
access to Sequent (see 5.3 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.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 102 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.10.3.8 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 6.3 i.e. the
Correspondence Servers, Tivoli management servers and KMS.
9.10.3.9 When implementing a new, or significantly changed, Post office made,
connection will initially be to the boot server which resides on a dedicated
isolated firewalled LAN.
9.10.3.10 The routers handling POCL, De La Rue and Royal Mail ISDN are separate
from those used for the Post Offices. Traffic permitted to/from these POCL,
De La Rue and Royal Mail links are file transfer, Tivoli management (see
section 7). 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.
9.10.3.11 Routers should be configured to deny access to external users (e.g. CISCO
support) until this access has been agreed - see 9.2.2. When permitted, the
appropriate router should be configured to restrict access to the Data Centre to
the particular system(s) needing support.
9.10.3.12 The routers used for internal Pathway site access only permit traffic from/to
these locations.
9.10.3.13 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
¢ 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.
9.10.3.14 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.
¢ Security services, such as the Key Management one, should be well
protected from unauthorised access from other systems.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 103 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.10.4 Pathway Project Sites
System management sites remote from the Data Centres which are run by
CFM(DS) and CFM(NI) are covered in sections 9.3, 9.4 and 9.9 above. All
such sites have direct links to the Data centres and conform to the controls in
9.2.1 above e.g. have a separate secure LAN for all workstations which can
link into the Data Centres.
The Pathway Corporate Management site at Feltham is the other Pathway
project site with 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 8
Pathway security and audit users - see section 8
Software distribution (see 9.6)
RDMC Change Managers and developers - see section 4.3.1
Implementation/roll-out users - see 9.6
The Feltham site also provides links for other Pathway project sites such as
SSC (see 9.7) which require Data Centre access as shown in the following
diagram.
Pathway Feltham site
ICL Corporate
Network “~~
Feltham Network
with management users
and other users
—
Routers/
Firewalls U
ISDN etc links}
7 CM sign &
Security etc users I Firewall I distribute
{I j I I Cj I
secure LANs Pathway
Router and secure site
crypto box e.g. SSC
Router and
crypto box ther
support
secure site
, . e.g. Oracle
To crypto box at Data Centre
Figure 9-12 Feltham Pathway Network
9.10.4.1 The secure LANs must be used by the following Feltham based users:
¢ of the operational systems at the Data Centre, including related services
such as the time server.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 104 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9.10.4.2
9.10.4.3
9.10.4.4
9.10.4.5
9.11
© of automated implementation servers at the Data Centres, such as the boot
server
© with access to sensitive data on MIS systems or with update access to them
© with access to secure services in Feltham such as the signing service
Note: this includes Security Management, Auditing and FRM users and some
management users - see section 8.
Signing and distribution of software should also be from a secure LAN.
All traffic in and out of the Feltham Pathway Network should go through one
of the routers/firewalls identified in diagram 9-12 i.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.
Traffic to/from the Pathway Feltham network and other networks (apart from
the encrypted links) is restricted to permitted traffic by the routers/firewalls at
the boundary to the Pathway network. The main types of permitted traffic are:
¢ Links to services required by Pathway developers, managers and related
staff. This includes email, Powerhelp and the MIS system in Belfast.
¢ Supply of software from other units, where this is done electronically.
e Access required by Implementation suppliers to the roll-out database.
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.
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: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 105 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
9ALAA
9111.2
91113
9.11.14
OALAS
9.11.1.6
9.1.1.7
9ALS
9.11.9
9.11.1.10
OAL
9.11.1.12
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 9.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 9.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.
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.
Set up of NT domains should assist separation of systems to reduce
interference between them.
Printed: 25/02/98 RESTRICTED-COMMERCIAL
C:A\OFFICE\ACCP2.DOC Page 106 of 116
ICL Pathway
Access Control Policy
Ref: RS/POL/003
Version: 2.0
Date: 24/02/98
APPENDIX A: SUMMARY OF ROLES
The following table is a summary of the roles in this document.
FUJ00087989
FUJ00087989
Role I Location of user I Services/Systems Accessed I Relevant ACP sections
Operational Roles for non Pathway staff
Post Office Manager Post Office Post Office counters 6
Post Office Supervisor Post Office PO counters 6
Post Office Clerk Post Office PO counters 6
Emergency Manager Post Office PO counters 6
POCL Auditor note 2 Post Office and Pathway site noi _I PO counters (other services indirectly) note 1 6
DSS Auditor Pathway site note 1 Audit services indirectly via Pathway Auditor note 1 6, 8.5
NAO Auditor Pathway site note 1 Audit services indirectly via Pathway Auditor note 1 6, 8.5
DSS FIT DSS site FRMS (Sequent MIS) 8.4 (+8.7)
DSS/BA clerks DSS/BA office PAS/CMS via CAPS 5.2, 7.1
DSS Help Desk DSS office PAS/CMS via CAPS 5.2, 7.1
Help Desk Roles (taking calls)
Payment Card Helpline Advisor Helpline site (Wigan/Bootle) PAS/CMS (+local system) 5.3 (45.2)
Payment Card Helpline Advisor as above PAS/CMS (+local system) 5.3 (+5.2)
(NSD
Payment Card Helpline Supervisor as above PAS/CMS (+local system) 5.3 (45.2)
Horizon system Help Desk SMC site (Stevenage +) local only 9.9
Technician
SMC Team Leader acting as SMC__I SMC site as above local including one-shot password system; KMS 9.3
Help Desk Technician
Roll-out Support Desk advisor Pathway site Roll-out database 9.6
Operational Roles - Pathway staff
Reference Data Change Manager Pathway corporate site RDMC (operational Sequent) 43.1
Reference Data developer as above as above 43.1
Pathway Management (multiple Pathway corporate site (Feltham) I Management systems (Data Warehouse and SLAM I 8.2 (+8.7)
roles) cache)
Printed: 25/02/98
C:\OFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 0 of 116
ICL Pathway
Access Control Policy
Ref: RS/POL/003
Version: 2.0
Date: 24/02/98
FUJ00087989
FUJ00087989
Pathway Management Support
Pathway corporate site (Feltham)
Management systems (Data Warehouse and SLAM
cache) ete
8.2 (+8.7)
Business Support (financial
reconciliations)
Pathway corporate site (Feltham)
DW, PAS/CMS, TMS
8.3 (48.7, 4.5, 5.2)
Pathway wide security roles
Pathway Business Function Auditor_I Pathway corporate site (Feltham) I mam 8.5 (+ lots)
Pathway Security Event Auditor Pathway corporate site (Feltham) I mam 8.5 (+ lots)
Pathway security management Pathway corporate site (Feltham) I ACE/server, PAS/CMS for Data Protection Act 8.6
requests
Cryptographic Key Manager Pathway corporate site (Feltham) I KMS 8.6
and Data Centre
Cryptographic Key Custodian
At system with key
Sequent, VME, Agents, CMS link PCs, Signing
service
8.6 (+ several)
Cryptographic Key Handler At system with key as above 8.6 (+
PO key recovery (subset of SMC SMC KMS 4.6, 9.3
Team leader role)
Pathway Fraud Risk management Pathway corporate site (Feltham) _I FRMS (MIS), Data Warehouse, TMS, PAS/CMS. 8.4 (+. 4.5, 5.2)
Girobank Fraud Risk Management Girobank secure site (Bootle) as above as above
Implementation and Software/Configuration Distribution Roles (apart from help desks above)
Auto-configuration Manager Pathway secure site roll-out, auto-confi; 96
Software Distributer Pathway corporate site (Feltham) I CM signing service 9.6
Pathway Implementation suppliers
(Peritas, Exel etc)
supplier site
roll-out
9.6 49.10)
Pathway systems management, administration for Sequent systems
Computer operator (on Sequent
Data Centre
Sequent (operational and MIS)
4.2 (referenced from
systems) 8.3)
System Monitoring (on Sequent) Sequent (operational and MIS) 42
Operational Management (on CFMU(NI) secure site - Belfast Sequent (operational and MIS) 4.2
Sequent)
Security Management (on Sequent) _I CFM(NI) secure site - Belfast Sequent (operational and MIS) 42
Emergency Operational CFMU(NJ) secure site - Belfast Sequent (operational and MIS) 42
Management (on Sequent)
Printed: 25/02/98
C:\OFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page I of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
Base Installation and configuration Data Centre Sequent (operational and MIS) 4.2
(on Sequent)
Pathway systems management, administration for NT Data Centre systems
Computer operator (NT Data Centre I Data Centre NT Data Centre systems 44
systems)
Operational management (NT Data I Data Centre/Belfast NT Data Centre systems 44
Centre systems)
Security Management (NT Data Belfast NT Data Centre systems 44
Centre systems)
Base Installation and configuration I Data Centre/Belfast NT Data Centre systems 44
(NT Data Centre systems)
Riposte Management Data Centre/Belfast Correspondence servers 4.5
Pathway systems management, administration for CFM (DS) systems
SMC technician SMC site (Stevenage +) Tivoli/Oracle system management services 9.3
SMC technical Team Leader SMC site (Stevenage +) Tivoli/Oracle system management services 9.3
SMC MSS technical support SMC site (Stevenage +) Tivoli/Oracle SMS plus SMS OS etc 9.3
SMC security manager SMC site (Stevenage +) Tivoli/Oracle SMS plus SMS OS etc 9.3
Pathway Network Management and management of Network systems
Network technician Data Centre OpenView on NMS 9.5
Network manager Data Centre OpenView and NMS (+ telnet to routers) 9.5
Network management configurer Data Centre NMS 9.5
NMS security manager Data Centre NMS 9.5
NMS system administrator Data Centre NMS. 9.5
Girobank systems management, administration for Payment Card Helpline systems
Payment Card Helpline Security Helpline areas PAS/CMS and local Helpline systems 5.3
Manager
Payment Card Helpline system and I Helpline areas PAS/CMS and local Helpline systems 53
network administrator
Support roles
Engineers (Sequent)
Data Centre
Sequent (operational and MIS)
4.2 (plus 8.3 by ref)
Engineers (NT Data Centres)
Data Centre
all NT servers at Data Centre
44
Printed: 25/02/98
C:\OFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 2 of 116
FUJ00087989
FUJ00087989
ICL Pathway Ref: RS/POL/003
Access Control Policy Version: 2.0
Date: 24/02/98
PO Installation Engineer Post Office PO counters 6
PO support engineer Post Office PO counters 6
CEM application support CFMU(NI) secure site - Belfast Sequent, VME 9.7 (+
SSC application support Pathway site (Bracknell) man 97 (+
‘Support Roles - non Pathway staff
Oracle application and db support Oracle secure site Sequent (operational and management systems) 4.2, 9.7
Sequent support Sequent secure site Sequent (operational and management systems) 42
Cisco router support Cisco site routers 9.5.4
Notes:
1. External Auditors only have direct on-line access to the Post offices. However, they have access to other Audit
information via Pathway Auditors.
1. POCL Investigators have the same rights as POCL Auditors, so are not distinguished from Auditors for access
controls.
Printed: 25/02/98
C:\OFFICE\ACCP2.DOC
RESTRICTED-COMMERCIAL
Page 3 of 116