ICL Pathway
FUJ00117497
FUJ00117497
Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Document Title:
Document Type:
Abstract:
Distribution:
Document Status:
Document Predecessor:
Associated Documents:
Author:
Approval Authority:
Signatures/Dates:
Comments To:
Comments By:
Access Control Policy
Policy Document
This Access Control Policy (ACP) defines the policy
for controlling access to resources in the operational
Pathway system.
DSS
POCL
Pathway
Pathway library
Issued subject to internal Pathway baselining
See section 0.2
Belinda Fairthorne
Martyn Bennett
Director Quality and Risk Management
Author, copy to Martyn Bennett and Barry Procter
Printed: [ DATE \l]
C:\My Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 1 of 105
ICL Pathway
FUJ00117497
FUJ00117497
Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
0. CONTENT
0.4 Document History
Version I Date Reason
0.1.0.2 I 28/10/96 _I Initial drafts for review by security team
0.3 T/AN/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 I Terminology changes including Horizon System Help
Desk instead of SIS Help Desk, SSC instead of EDSC,
updated names for roles at Post Offices.
Major items which have not yet been agreed have been
moved to changes forecast and related incomplete text
removed from the body of the document. This includes
external auditors to access Data tre Servi
Major updates to the Post Office section have been
made.
An outline proposal for telephone authentication has
been added.
Numerous minor changes have been made.
0.2 Associated Documents
Ref: Title Identifier Vers. IDate
SADD IService Architecture Design CR/FSP/004 [2 27/9/96
Document
TED ‘Technical Environment Description I{D/ARC/0001 I2.0 [14/12/96
SPOL _IICL Pathway Security Polic PS/POL/0002 [3.0 {8/10/96
SFS Security Functional Specification RS/FSP/0001 [2 11/11/96
HDM __ IHelp Desk Call Enquiry Matrix CS/FSP/O001 [2.0 {16/9/96
AUDT {Audit Trail CR/FSP/006 [1.1 _ {8/10/96
FRMS_ {Fraud Risk Management Service RS/SPE/0001 I1.2 — I20/9/96
Design
APOL _ [Pathway Audit Policy RS/POL/004 [0.4 14/3/97
BS7799 IA Code of Practice for Information IBS7799 1 15/2/95
Security Management
DSPOL IDSS IT Security Policy DITSG/ITSS/0 [6.2 I3/96
(Departmental IT Security 001.04
Standards)
PPOL {Post Office Counters Information SRR Appendix
System Security Policy 4-1
CONT [Pathway Contingency Invocation 26/11/96
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc
Page 2 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
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
CLI Calling Line Identification
CMS Card Management Service
DBA Database Administrator
DSA Digital Signature Algorithm
DSD Distributed System Division (ex Sorbus, now CFM)
DSS Department of Social Security
EPOSS Electronic Point Of Sale Service
ESNS Electronic Stop Notice System
FRM Fraud and Risk Management
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
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
VME Virtual Machine Environment
Printed: [ DATE \l]
C:\My Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 3 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
0.4 Changes Forecast
In some areas of Pathway, design is not yet finalised. While this
document states the policy in these areas, details are subject to change as
indicated in the relevant section. The main such areas are:
Telephone authentication procedures (section 3.6.2 and elsewhere)
Firewalls and associated network controls
Use of a secure menu system on Sequent
Use of security tokens for authentication of selected users
Some aspects of Pathway system auditing
Split of responsibility, particularly at DSS sites
Some additions are expected in future versions of this document. Several
of these are dependent on requirements, and the way of satisfying them,
being agreed. These are:
¢ Access to PAS/CMS and TMS archives.
e Access by POCL, DSS/BA and NAO auditors to central Pathway
systems such as Correspondence Servers, PAS/CMS and System
Management information.
e Other DSS access to Pathway systems for information associated with
BPS. Several types of access are under discussion, but details have still
to be agreed for some of these. DSS access to Pathway is expected to
include:
¢ Benefits agencies on-line access via CAPS to PAS/CMS.
Transactions here include updates e.g. for urgent payments.
e DSS Help De: to PAS/CMS.
e Fraud Investigation Team access.
¢ NT failsafe startup may be added at Post Offices to allow regression to
an earlier version on NT or Tivoli if the latest one downloaded to the
Post Office fails to boot correctly. If so, this will affect the boot
sequence described in 8.6.
sk read only acc
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 4 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
0.5 Table Of Contents
0.1 Document History .....
0.2 Associated Documents .
0.3 Abbreviations
0.4 Changes Forecast
0.5 Table Of Contents.
1. INTRODUCTION...
1.1 Purpose
1.2 Context
1.3 Scope ..
1.4 Access Control Policy Review.
1.5 Document Structure
2. SECURITY DOMAINS.
2.1 Domain Definition
2.2 Specifying Domain Access Control Policies
2.3 Domains Directly involved in Benefits Payments.
2.3.1 The DSS Service Environment Domain
2.3.2 The POCL and POCL Clients Domain
2.3.3 The POCL Central Services Domain
2.3.4 The PAS/CMS Services Domain .....
2.3.5 The Office Platform Service Domain
2.3.6 De La Rue Card Services Domain
2.4 Other Domains.
2.4.1 System Management Service Domain
2.4.2 Pathway Corporate Services Domain .
2.5 Post Office Roll-out
2.6 Internal Pathway Services
2.7 Sites linked to Pathway Data Centre Campuses .
3. PATHWAY WIDE ACCESS CONTROL POLICY ..
3.1 Objectives.
3.2 Pathway Responsibil
3.3 Pathway Roles
3.3.1 Common Operational Function:
3.3.2 Common System Management Functions .
3.3.3 Common Security Management Functions
3.3.4 Common Support Functions...
3.3.5 Pathway Wide Functions ..
3.3.6 External Roles.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 5 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.4 Types of Information and its Use.
3.5 Information System Controls ..
3.5.1 Implementing Role Based Access Controls
3.5.2 Access Controls at Pathway Platforms ...
3.5.3 Controlling Traffic between Systems
3.6 Other Access Controls
3.6.1 Customer Authentication ......
3.6.2 Other Telephone Authentication to Help Desks
3.6.3 Authentication of Visitors .
3.7 Key Management
3.8 Effect on other Pathway Standards and Procedures.
4, THE DSS SERVICE ENVIRONMENT DOMAIN. ....ssscssssssssessssesesseeensssssassnsnnensnees OD
4.1 Introduction
4,2 Roles...
4.3 System Access Controls for Human Users
4.4 System Access Controls
4.5 Control of Traffic between VME and the Data Centres
5, POCL AND POCL CLIENTS DOMAIN...
5.1 Introduction
5.2 Roles...
5.3 Control of Connections to the Pathway Data Centres
5.4 Control of Connections to POCL Systems
6. POCL CENTRAL SERVICES DOMAIN.........:s:sssssssseesetsseesseneeeeseeestensneneetseeenetenee 45
6.1 Introduction
6.2 Sequent Systems with Oracle Databases
6.2.4 Roles
6.2.2 System Access Controls for Human Roles .
6.2.3 Dynix and Oracle Access Controls ..
6.2.4 Control of Connections to the System
6.3 Windows NT Systems.
6.3.1 Roles
6.3.2 System Access Controls for Human Roles .
6.3.3 System Set Up ...
6.3.4 Control of Connections .
6.4 Correspondence Servers...
6.4.1 Roles
6.4.2 System Access Controls for Human Roles .
6.4.3 System Set Up ......
6.4.4 Control of Connections .
6.5 BES Agents
6.6 Specific OBCS Related Services
6.7 Reference Data Management Centre
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 6 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
6.8 Specific TIP Related Services .
6.9 Security Services
6.9.1 Key Management and Associated Services...
6.9.2 Authentication Service for Authentication using Tokens .
6.9.3 Key Custodian Role.......
6.10 PCs Handling External Links .
6.11 Other Data Centre Services
7. PAS/CMS SERVICE DOMAIN
7.1 Introduction
7.2 PAS, CMS and CAPS Access Services .
7.2.1 Roles..
7.2.2 System Access Controls for Human Roles .
7.2.3 Base System Access Controls and Control of Connections
7.3 PAS/CMS Help Desks
7.3.1 Roles.
7.3.2 Local Network Configuration .
7.3.3 Control of connections to the Help Desk.
7.3.4 System Access Controls for Girobank Role:
7.3.5 Other Access Controls ..
8. OFFICE PLATFORM SERVICE DOMAIN
8.1 Introduction
8.2 Roles
8.3 Control of Connections to the Systems.
8.4 System Delivery ..
8.5 System Installation.
8.6 Booting the System
8.7 System Access Controls associated with Human Roles
8.8 Other Access Controls
9. DE LA RUE CARD SERVICES DOMAIN ......sssscscssssesesessesessessseassesneesassesenanenenens 78
9.1 Introduction
9.2 Roles ...
9.3 Control of Connections to the Pathway Data Centres
9.4 Control of Connections to De La Rue Systems
10, SYSTEM MANAGEMENT SERVICE DOMAIN .
10.14 Introduction
10.2 Technical Help Desks and System Management ..
10.2.1 Horizon System Help Desk, SMC and Related Roles
10.2.2 System Access Controls for these Roles .
10.2.3 Controls on Connections
10.2.4 Other Access Controls
10.3 Sequent and Oracle Management ....
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 7 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.3.1 Roles...
10.3.2 System Access Controls for these Roles .
10.3.3 Control on Connections .
10.3.4 Other Access Controls
10.4 Network Management
10.4.4 Introduction .....
10.4.2 Roles at the Open View System
10.4.3 Access Controls associated with Human roles
10.4.4 Access to Routers
10.4.5 Access controls configured in Routers
10.5 Network Access Controls.
10.5.1 Introduction a
10.5.2 High Speed WAN links.
10.5.3 Post Office Connections.
10.5.4 Other ISDN Connections
10.5.5 Links from ICL Pathway related Sites
10.5.6 Network Access Controls within the Data Centres
10.6 Roll-out
11.4 Introduction oa
14.2 The Management Information Systems (MIS)
11.2.1 Roles
11.2.2 System Access Controls.
14.2.3 Control of Connections
11.3 Pathway Fraud Risk Management
11.4 Security Management and Auditing.
11.4.4 Security Management Roles
11.4.2 System Access Controls.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 8 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
1. INTRODUCTION
1.4 Purpose
This Access Control Policy (ACP) defines the policy for controlling access
to resources in the operational ICL Pathway 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 how the security
functionality described in the Security Functional Specification (SFS) will
be used to enforce the required controls in the Pathway environment
defined in the Technical Environment Description (TED).
1.2 Context
This document fits into the structure of documents for Pathway security
as illustrated in figure 1-1 below.
Pathway Security Policy
'
Access . Security Technical
Audit . -
Control Polic Functional Environment
Policy y Specification Description
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
Printed: [ DATE \l]
C:\My Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 9 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
The Access Control Policy defines how access will be controlled
throughout the Pathway system in compliance with the Pathway Security
Policy. This uses security functionality in the Pathway environment.
The Audit Policy defines the policy for auditing activity on the
operational Pathway system.
The Security Functional Specification describes how the security
functionality will be implemented.
The Technical Environment Description describes the technical
environment for the Pathway solution.
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, any 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 spe tions defining how the various Pathway
components are configured to meet this policy. These will define, for
example, which functions in which applications are available to people in
particular roles and the database views available to each role.
1.3 Scope
This Access Control Policy defines how access to information system
resources (such as files, databases, fields, objects) will be controlled in the
operational Pathway system.
The document includes:
e The principles of how the access controls should be configured -
which roles should be set up with what responsibilities and what
categories of functions people in those roles should be permitted to do
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 10 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
1.4
1.5
e How the security functionality defined in the [SFS] will be used to
achieve that. For example, how people in different roles are
authenticated, how access to the permitted functions will be 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.
e How the system will be set up on installation to protect the main
applications which are triggered automatically.
Separate Pathway documents as described in 1.2 above define related
standards and procedures.
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.
This policy is for the operational Pathway system and the associated
management systems at the Pathway Data Centre. Separate internal
Pathway documents cover the controls associated with system
development, integration and other activities prior to the handing over
of the software for use in the operational system.
Access Control Policy Review
Once approved, this document will be formally reviewed at least
annually. It will also be reviewed where relevant after a significant attack
or occurrence of fraud, 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.
Document Structure
This document includes general policies and controls for controlling
access in the Pathway IT systems and then the more specific controls for
particular parts of the system. To assists this, the Pathway system is split
into a number of security domains.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 11 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Section 2 identifies the Security Domains of the Pathway system and
outlines the main functions in each domain. The domains include both
the main operational processes and the management ones. This section
also identifies the internal Pathway systems which have access to the
Pathway Data Centres, for example, for feeding new software into the
system. In addition, it identifies the sites which access the Data Centres
both for management and support of the operational Pathway system
and to support the feeds in and out of the system.
Section 3 specifies the Pathway wide access control policy. It outlines the
main responsibilities of the Pathway organisations who have direct access
to the IT system. It defines the generic roles which will be supported at
most of the Pathway systems (though specific roles may have different
details at different nodes). It also gives the general policies and controls
which apply to all Pathway systems. Detailed configuration of any
Pathway node should conform to this section and to the more specific
controls in the appropriate later section.
Sections 4 to 11 specify the access control policy for each Domain in
turn. For each domain (and sometimes for sub-domains) it gives a general
description of the services in the domain to identify to what the access
controls apply. It then identifies the roles and the access controls for that
domain.
For each domain, the roles defined cover operational, management and
support roles. Note that some roles are system wide (particularly system
management and Pathway corporate ones) so will be referred to in each
domain in which they occur (as the systems there must be configured to
support them) but the full definition of these roles is in either the System
Management or Pathway 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
domain.
So the access controls for a particular system are:
e The general controls in section 3 (those which apply to that type of
system)
¢ The specific controls associated with the particular system (as defined
in the appropriate later section)
e The controls referred to from that section as applicable to it.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 12 of 105
ICL Pathway
Access Control Policy
FUJ00117497
FUJ00117497
Ref: RS/POL/0003
Version: 1.0
Date: 17/4/97
2.1
SECURITY DOMAINS
The Pathway system can be viewed as a number of “domains” which
together provide the Pathway solution.
Domain Definition
A “domain” is a distinct part of the system characterised by:
e the services it provides,
e the components it uses to provide those services (such as VME, Dynix,
NT, Oracle, Tivoli), and
e the organisation(s) responsible for providing the services (e.g. ICL
Pathway, Girobank, ICL DSD).
Domains may be geographically distributed.
The services offered by several domains combine to provide the end-to-
end services defined in the ICL Pathway Functional Specification, 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
interfacing to CAPS, ESNS
; ; De La Rue
(Card ServicesI
POCL Central Services Domain Domain
Host systems for Pathway Services
and Pathway
Interfaces to OPS PAS/ICMS . Corporate
System Services Domain Services
ManagementI PAS/CMS host system Domain
Services and Help Desk P. .
. athway
Domain
Management
Ma processes
Office Platform Service Domain
All services at the Post Offices
Figure 2-1 Pathway Domains
Figure 2-1 illustrates the domains and the primary links between them,
except for links with the Pathway Corporate Services.
Printed: [ DATE \l]
C:\My Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 13 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
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 Domain Access Control Policies
These domains represent major areas of responsibility for services within
Pathway. Each has different characteristics which affect the type of access
controls needed in that domain. The Access Control Policy, therefore,
specifies the access controls needed in each of these domains in turn.
For each domain, the Access Control Policy includes:
e An introduction to the main services provided by the domain -
including the information processed and the interfaces with other
domains. This outlines the software and hardware components used to
provide these services.
e An outline of the operational, management and support roles of all
people with access to services in this domains and what services are
provided without human involvement.
e For each role, a description of the main classes of functions and the
organisation to which people with this role belong.
e The access controls in the information system for people in each role.
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.
Some aspects of the Access Control Policy apply to all domains and these
are described in section 3, before the domain specific controls.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 14 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
2.3
2.3.1
Domains Directly involved in Benefits Payments
The main operational flow of the Benefit Payments Service involves the
domains illustrated in figure 2-2. These domains, and the others are
described in the following sub-sections.
DSS Service
DSS system with Environment Domain
Pathway Partition
PAS/CMS
Te Desk I Services Domain
oo ee g,’ De La Rue
POCL and POCL Client I 2 Card Services Domain
Domain ' IPAS/cmsI
card
production
TIP/ I Ref. f
Hosts APS I epogs I Data I OBCS I PASICMS I
T L 1
<1 rhents -—_> POCL Central Services Domain
Distribution
Correspondence Servers I
‘
i
l Transaction
I WAN Management
I Service
I
I
a Ae Counter Infrastructure E Sance (OPS).
APS I EPOSS I OBCS I BES Pomain
Figure 2 - 2 Domains directly involved in Benefit Payments
The DSS Service Environment Domain
The DSS Service Environment Domain is illustrated in the first box of
figure 2.2. It consists of the Pathway components at the DSS/BA sites.
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 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 15 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
2.3.2
2.3.3
2.3.4
The POCL and POCL Clients Domain
Pathway also provides links to POCL and POCL Clients systems (other
than the DSS ones above). The POCL TIP system receives records of all
transactions at Post Offices and the associated 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 will be replaced in future by direct links
to POCL Client systems.
The Pathway Acc
the interface to thes
Control Policy is concerned only with that part of
systems which is the responsibility of Pathway.
The POCL 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 run on Sequent machines and use Oracle databases.
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, ran on Windows NT platforms.
This domain includes the Key Management System used to generate and
distribute keys within the Central Services Domain and to Post Offices.
Interfaces with other domains are shown in the third box in figure 2-2.
The Central Service Domain spans two sites (Bootle and Wigan) which
are often referred to as Pathway’s Data Centres or campuses.
The PAS/CMS Services Domain
Files are transferred to/from the DSS Service Environment Domain to the
Payment Authorisation Service (PAS) and Card Management Service
(CMS). These process the payment authorisations and customer
information for forward transmission to the Post Office or Card
Producer as required. PAS and CMS share the same Oracle database
running on Sequent hardware with the Dynix operating system.
The PAS and CMS Help Desks use Windows NT workstations with
Oracle Forms applications to access the PAS/CMS database.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 16 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
2.3.5
2.3.6
2.4
2.4.1
2.4.2
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 and Pick UP Notices (PUNs).
Other Domains
System Management Service Domain
The System Management Service Domain contains the central elements
of the System and Network Management facilities for managing
components in the other domains. It therefore covers:
¢ Software Distribution and associated software inventory management
e Event management
e Resource management
.
°
Network management
Hardware inventory management supporting software distribution
and Network management
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.
The Horizon System Help Desk provides technical assistance on
hardware, software and network problems, calling on others when
needed.
Pathway Corporate Services Domain
The Pathway Corporate Services domain supports Pathway’s own
management proc 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 17 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
2.5 Post Office Roll-out
Rolling out new Post Office systems affects several domains. The Access
Control Policy is concerned with those aspects where access is required
to the operational Pathway System. The Roll-out and auto-configurer
systems generate information for the Data Centres and Post Offices to
configure the systems for new Post Offices. Rollout is described in the
section on the System Management Domain.
2.6 Internal Pathway Services
A number of internal Pathway services interact with Pathway operational
and management services at the Pathway Data Centres. These include:
e The Configuration Management system controlling information about
software components for Pathway products prior to their distribution
e The Rollout database containing information about Post Offices to be
rolled out
e The Powerhelp system used to record and maintain information about
calls to the technical Help Desks and their progress
e The Dispatch-1 system which holds hardware inventory information
2.7 Sites linked to Pathway Data Centre Campuses
Figure 2-3 shows the sites which have electronic links with the Pathway
Data Centre campuses.
CAPS, ESNCS, TIP ete
at DSS, POCL and POCL Client sites
\1Z
De La Rue sites “Pahwan Dai
aihway Data
Card production Centre Campus
ICL Pathway
Support Sites
— Operational
CFM sites applications
Operational Help Desk Application support
Management
Data Hardware and
Warehouse etc Software details
DSD sites
System Correspondence
servers etc
=
Pathway Management
Management
- J iN
Post Offices Royal Mail
Figure 2-3 Sites with links to the Pathway Data Centres
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 18 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
The Pathway Data Centres are secure sites at Bootle and Wigan housing
the main operational systems. The PAS/CMS Help Desks are in a
separate area at each Pathway campus. The Pathway Management
Information Systems are at Wigan.
All electronic interactions with DSS, POCL and POCL Client sites are via
file transfers (at least initially - DSS interactive access is expected in
future). Interactions with De La Rue sites are also by file transfers.
Interactions with the Post Office include the main data transferred via
the Riposte TMS, System management interactions (software
distribution, Tivoli scripts, events) and key management interactions.
CFM provide operational management of all the systems at the Pathway
campus except the Girobank Help Desk Systems. This includes
operational management of the Sequent systems and so requires
privileged access to these systems. While some CFM staff will be at the
campus, much of this management is done remotely (from Belfast).
DSD staff responsible for System Management and the Horizon System
Help Desks are located at Stevenage, Footscray and Lytham St Annes.
SMC are responsible for system management - software distribution,
event handling, resources monitoring via Tivoli. DSD also provide the
Powerhelp call handling system and Dispatch-1 hardware inventory.
ICL Pathway support and management sites also have access to the
Pathway campus. These provide, for example, the link with the Pathway
Configuration and Rollout systems from which software and Post office
information is distributed. It is also used for some application support
and Pathway management access. There are links from Feltham and the
Oracle Bracknell site. Some application support is also done from other
sites such as the CFM ones.
All links to De La Rue, CFM, DSD and other ICL Pathway sites are
encrypted for integrity and confidentiality.
In addition to these electronic links, some contact with Pathway sites are
made by telephone e.g. Counter Clerks phoning a Help Desk.
Later sections give define the permitted accesses between these sites.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 19 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
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 11 deal with the procedures and controls in different
Pathway domains.
3.4 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.
2. 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.
3. 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.
4. 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 20 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.2 Pathway Responsibilities for Services
ICL Pathway has overall responsibility for the design, implementation,
roll-out and operation of the service throughout the contract period.
This document is concerned with the responsibilities for accessing
Pathway services during the (roll-out and) operation of the system.
Specific activities will be subcontracted to appropriate organisations both
within the ICL group of companies and to other organisations. Figure 3-
1 illustrates the responsibilities of these organisations in the operational
use of the system.
BA POCL
Pathway
PAS and CMS SIS/SMC On-line
Help Desk (J I_I Help Desks Sofiware
Girobank & System Support
Management
Card and PUN I I Pathway eee itil
Manufacture Ce I_I” Engineers
and Distribution I 4 de ICL DSD ete Oracle
De La Rue Managment
Systems Network and 5
Corporate Operational CFM
Management I I [I management
Services ICL CFM. we
Pathw ay project :
Post Offices
Figure 3-1 Pathway Responsibilities
The Pathway Access Control Policy covers control of access to resources
in the Pathway operational systems by all these people.
The policy also covers access to Pathway services by other organisations -
particularly Post Offi ff accessing the Post Office systems. Other
external access is also expected, for example, by POCL auditors.
The organisations involved in the operation of Pathway, and their
responsibilities are described below.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 21 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
¢ Girobank will run the PAS and CMS Help Desk.
e De La Rue will manufacture cards and distribute cards and Pick up
Notices (PUNs).
e The ICL Pathway project will run the Corporate Management
services, providing access to BA and/or POCL according to
agreements. Pathway Management, including Auditing and Fraud and
Risk Management, uses information from many Pathway systems.
e ICL DSD (ex Sorbus, now CFM) will run the Horizon System Help
Desk and also be responsible for the overall System Management of
the Pathway information systems. This includes software distribution,
event and resource monitoring.
e ICL DSD provide engineers for maintenance of the central Pathway
services and for maintenance of equipment at Post Offices. Engineers
for other places such as the Girobank Help Desk are from other
organisations.
e ICL CEM will be responsible for the operational management of the
Sequent systems at the Pathway campuses. Their responsibility
includes the Dynix operating system and Oracle databases. CFM is
also responsible for Network Management.
e Under exceptional circumstances, DSD and CFM will need on-line
support from other organisations for software in the Pathway system.
This will be provided as follows:
e SSC, the Pathway System Support Centre, will provide 2nd line
support for most applications and packages including Riposte.
¢ Sequent will support the Dynix operating system. Any on-line
access will be at the Pathway Data Centre.
¢ Oracle will support Oracle databases and provide 3rd line
support for the PAS/CMS applications.
e¢ CEM will support applications in the Pathway partition on
VME CAPS and ESNS machines and Business Objects
applications at the Data Warehouse. (Enterprise systems also
support applications on VME)
No other organisations will have on-line access to the system. For
example, there will be no on-line access by Microsoft for NT
support or by Escher for Riposte support.
e EDS runs the DSS CAPS system and the firewall between it and the
Pathway systems
e Exel will provide Engineers for Post Office rollout.
e Girobank also perform Fraud Risk management functions
e EMC provide the Symmetrix discs and may be called in to support
these.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 22 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.3
Pathway Roles
Responsibility for performing functions within the Pathway system is
allocated on the basis of roles. This document identifies the following
types of roles:
¢ Operational roles of the users of the system during normal running.
These include, for example, the PAS/CMS Help Desk Advisors and the
Post Office Counter Clerks.
e System and Security Management roles. These are the people who are
responsible for maintaining and monitoring the system, including
adding new software and users.
e Support roles such as engineers
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 will be available in
one role to simplify administration where separation of these duties is
not required. This is defined in the more detailed sections of this
document about the individual domains. Several domains have specific
requirements which require use of particular roles.
A limited number of roles are “pathway wide” and so recognised in most
Pathway domains. These are the Pathway management roles which allow
auditing and investigation of all Pathway systems.
The Access Control Policy includes all roles for users who have direct
access to the Pathway operational systems and the related systems at the
Data Centres. In addition, this document includes a limited number of
roles of users who cause others to use the system on their behalf, for
example in response to a phone call.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 23 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.3.1
3.3.2
Common Operational Functions
Much of the operation of Pathway applications is automated at DSS/BA,
POCL and Pathway campuses, including the transfer of data to/from 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. The operational roles at the Post Office are 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.
The only operational function common to all domains is the computer
operator. However, 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 the system management
roles.
Control of access to resources for automated processes results from the
way the system was installed and configured.
Common System Management Functions
System management functions are required in all domains. However
some system management functions are done at the separate System
Management Domain and are often 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: setting up the base and application software on the
system.
e System Installation: configuring the system for live running. This may
be done as part of system set-up. Installation of some systems will
include installing the cryptographic keys needed - see security
management roles.
e Software Update: updating the software and reconfiguring it. Most
updates to software are done automatically. However, some base
software updates need to be done manually on site.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 24 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
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: keeping the system running - responding to
incidents, keeping it correctly configured. This is mainly concerned
with operating system management, but may also involve some
database administration
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 is separated into:
- database structure set up and maintenance (with no access to
application data)
- full facilities (which include allowing access to all data)
NB user management and defining which data is available to
which roles in Pathway is a separate security management
function - see later.
¢ Riposte Administration. Management of Riposte message stores
and groups is largely done automatically. Some residual
administration may be required
¢ 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
10 for more about Tivoli.
e Application and Package Management and Support: Managing the
running of the applications themselves including handling application
errors.
Note that some of these functions are carried out in the System
Management Domain. Further management functions there are:
e Network Management: managing the network which connects
machines and domains together.
e 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).
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 25 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.3.3
3.3.4
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, will be 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
¢ individual user management, including removing the rights of
users when who have changed jobs or left the organisation
© periodic checks for, and removal of, redundant users
e Resource access control: administering who can access which
resources in the operating system, database or applications. Unless
otherwise stated, human user access to resources is based on role
rather than individual user identity.
¢ Security 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.
e Cryptographic Key Handling: Keys are used to protect
communications links, digitally sign information and encrypt filestore.
There will be:
« A Pathway Cryptographic Keys 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 to:
e A Pathway Cryptographic Key Custodian: Responsible for
installation and later update of such keys at Pathway and linked
systems, except where this is done automatically.
Common Support Functions
Support functions are primarily concerned with:
e Keeping all equipment operational, and
e Training staff to carry out their defined roles
On-line training is provided at Post Offices and PAS/CMS Help Desks.
Functions associated with keeping the equipment operational are:
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C
y Documents\ACPV.1.doc Page 26 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.3.5
3.3.6
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
e Replacing and reconfiguring hardware; done by Support Engineers
¢ Technical Help Desks for reporting, and getting advice on, problems
Pathway Wide Functions
People in a small number of roles have access to several of the domains.
These are:
e Pathway Fraud and Risk Manager (FRM). This is concerned with the
identification, monitoring and management of fraud particularly in
benefit payments.
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.
e Pathway Security Manager. This function includes the Pathway
Security 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 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.
These Pathway Management roles are described further in section 11 on
the Pathway Corporate Services Domain.
External Roles
In addition to the Pathway roles defined above, some access to the
system is required by people in POCL and DSS/BA. For example, a local
Benefits Office may authorise use of a temporary token for a claimant to
obtain benefits. Post Office customers receive benefits. These roles
represent indirect users of the system, who contact direct users to
perform actions on their behalf. They are operational roles and are
therefore described with the other operational roles for particular
domains.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 27 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.4
Also, some external users are expected to have direct access to the
Pathway system. The only external roles included by this version of the
Access Control Policy are POCL Auditors. POCL Auditors can access
services at Post Offices and are also expected to have limited access to
information in other domains such as PAS/CMS archives and TMS
journals. Details of this access have still to be agreed, so are subject to
change.
The Audit Trail functional requirements specification [AUDT] identifies
Auditors in DSS and possibly the National Audit Office (as well as
POCL) who may require access to Pathway systems, but the type of
access needed for these is not yet clear enough yet to include here.
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.
e Training information - sp tyle data used in training
sessions
¢ On-line documentation e.g. PAS/CMS Help Desk procedures, Post
Office procedures
¢ Operational systems data such as the software, configuration
information, Tivoli scripts, system management event logs etc.
e Security information about users, keys, security audit logs etc
I busine:
Most processing of the business information, except at the Post Office,
will be automated and therefore not subject to human access. Most
processing of system data is also automated.
All information will be protected in conformance to the Security
Functional Specification and Pathway Security Policy.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 28 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3411
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
3.4.1.9
3.4.1.10
All business data will be classified as RESTRICTED according to the UK
government cla cations. Access to data with a National Sensitivity
Indicator will be further limited to authorised staff.
Where human access to this information is needed, for example by Help
Desks and for system management, the information will only be
accessible to those with a need to see it according to their role.
Information in transit between systems is encrypted for confidentiality
and/or integrity according to the needs of the particular link as defined in
the Security Functional Specification [SFS].
Digital signatures are 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.
System data is also integrity protected when required. Digital signatures
are used for integrity protection of software and Tivoli scripts distributed
to the Post Offices. Appropriate key distribution protocols as defined in
[SFS] are used to protect all cryptographic keys.
Business information in filestore at the Post Office PCs is encrypted.
Information in Oracle databases is accessible only via authorised Oracle
Forms except where there is a proven need for lower level access.
Information accessed via Oracle facilities such as Oracle Forms will be
subject to Oracle role based access controls.
Lower level access will only be granted for agreed operational
management functions.
System Management actions by Tivoli will be activated using pre-defined
Tivoli scripts which have been authorised for use by SMC and the
Pathway configuration management and software distribution process.
Information on discs and other media (including printed output) will not
be accessible for unauthorised use. For example, archives will be stored
securely and information on discs removed for repair will not be
accessible.
Information will be appropriately separated in filestore, database tables
etc. Each data set will be accessible only to those with a need for that
access.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 29 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.5
3.5.4
Information System Controls
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:
¢ 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 will be automatically associated with a user
when the user logs on. At other locations, the user will be given
limited privileges on log-on and will have to ask for others, though
will still be restricted to privileges for which he has been authorised.
(This particularly applies to some management functions. For
example, no users will be allowed to log onto UNIX with root access.)
e Administering ac ontrol 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 will be permitted to take more than one
“role”, but this will not be done where it might undermine security.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 30 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.5.2
3.5.2.2
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:
Each user will be given the least privilege required for the job.
Duties of different users will be separated to minimise the damage that
any one user can do to the system or the information in it.
If a role at a particular location is allocated to a single person, there
should generally be at least one other person who can deputise for that
person. (At small Post Offices where no deputy is available, if the Post
Office Manager is unavailable, the Post Office will not open until
emergency procedures have been invoked.)
For system management users, a further separation of duties will be
achieved using Tivoli regions to control which Tivoli region of Post
Offices a particular individual manages for functions within his role.
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 Pathway
systems will be 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 Pathway nodes
will be 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
11 below. No other variants are permitted.
Workstations from which operational systems can be updated will have
floppy drives disabled. Servers should should have floppy drives disabled
unless there is a agreed need for them.
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 will be in physically
secure areas.
All system will have the required roles, groups and other privileges set up
on installation. It should rarely be necessary to update these. “Guest”
users will not be included in the installed systems. Other generic users
will not be accessible for user logon except in exceptional circumstances
explicitly defined in the appropriate section below.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 31 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.5.2.5
3.5.2.6
After a workstation is booted up, a log-in screen will be displayed which
cannot be by-passed.
People accessing Pathway systems will be required to identify themselves
using hand held tokens if:
e They are at remote sites and are able to update the operational system
(for example, to perform systems management actions)
e 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 main operational systems. This includes people with
UNIX root privilege, NT users belonging to the administrators group
and database administrators.
Where such tokens are used for authentication, the associated PIN must
be at least 6 characters long.
Where passwords are used for authentication, the user is forced to
change the initial password before any other access to the system is
permitted.
Passwords will expire in one month unle:
section on the appropriate domain).
otherwise stated (in the
3.5.2.9 Re-use of the same password will not be permitted for either a specified
time or until at least 3 other passwords have been used.
3.5.2.10 The minimum password length will be 6 characters.
3.5.2.11 After 3 consecutive unsuccessful attempts to log-on, the user will be
locked out unless otherwise stated.
3.5.2.12 People are identified to the Pathway system as individuals. Users with
direct access to the system will be registered as follows.
e If accessing the system via a package such as Oracle or Tivoli, they will
be registered with that package.
e Users who require direct access to the operating system are registered
with that operating system
e Users requiring token authentication are also registered with the
appropriate authentication service.
(The only exceptions allowed to this are the specific cases identified in
later sections of this document. In these limited exceptional cases, the
user, for example, an engineer, is identified as an individual using manual
means prior to using the system in a way specially set up for this, and
where the use of the system is suitably monitored.)
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 32 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
BS2NF 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. Any change to use another
username will be controlled (as specified in that section) and audited in a
way which will always be recorded.
35.214 The filestore will be structured to prevent interference between users and
between applications.
SS2ASF Access to shared resources such as filestore will be controlled by:
e Access to that filestore being restricted to a specific product which is
available only to authorised users. (Most access is controlled this way
as most use of the system is automated), or
© Ac to those resources being restricted to users in specified role:
(Group ids may be used to represent roles. Access control lists using
these will ensure that only authorised people can access the resource).
FS216 Access to Tivoli and Oracle resources will use role based access controls.
3.5.2.17 Security audit logs will be protected from everyone except those
permitted to take specified security 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.
3S.218 Interference between applications will be 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.5.2.19 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 PAS/CMS Help Desk users to Oracle
Forms.
3.5.2.20 Audit records will be 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.
3.5.3 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. General policies are as follows.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 33 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3I31 All accesses in and out of the Pathway Data Centres will be restricted to
the required traffic from/to specified sources. Once within the Pathway
system, traffic will be routed only to specified ports at systems which
require that traffic. Both these will be done using routers, and if
necessary, other application gateways/firewalls.
F.S3.2 Routing of traffic within the Pathway Data Centres will also be restricted
to ensure traffic is only routed between systems which need to
communicate. This will be done using access controls at the appropriate
routers.
3.5.3.3 Each node at the Pathway Data Centre will be set up to restrict the traffic
allowed at its ports to the permitted traffic there (except where routers,
firewalls or other systems ensure that no other traffic is possible).
Workstations which have access to sensitive data will 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 will be 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 will be
documented in this Access Control Policy and are confined to the
Pathway management site (Feltham).
Where workstations and servers require access to both the Pathway Data
Centres and other systems, an authorised combination of routers and
firewalls will be configured to restrict the traffic to that permitted. All
such cases will be documented in this Access Control Policy and are
confined to the Pathway management site (Feltham).
Accesses to/from the Pathway campuses such as CAPS, TIP and SMC
will have well defined, controlled links with cryptographic protection
where needed as specified in the [SFS].
3.5.3.7 No other ace in and out of Pathway will be permitted.
3.6 Other Access Controls
In some cases, the information system cannot provide all the access
controls required. This will be 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 34 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.6.1
3.6.2
3.6.3
Customer Authentication
No general policies are specified for how to identify customers who are
not known to the system as these will be 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.
Other Telephone Authentication to Help Desks
Apart from customers, Help Desk 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 PAS/CMS Help Desk and the Horizon System Help Desk will
maintain information on the Post Office and other relevant sites and
offices. Where possible, CLI will be used to check the source of the call is
from a permitted site. Where this is not possible, or the particular action
requested requires further authentication of the user, the caller will be
asked for further information which the Help Desk can verify. The
information known about such offices and sites will include the office
code, the name of the manager/contact, the telephone number and the
address.
For certain cases, different (normally extended) authentication is
required. For example, verification of a telephone number may include
calling back on the known number. In some cases, more information
will be available to support the extended verification. The methods used
for authentication in the s are included in the definition of the
appropriate domain.
[Note
this procedure is still under discussion and may change I
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 without prior
notice to the Post Office Manager.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 35 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Pathway visitors to Post Offices will be subject to Pathway vetting
procedures and approval by PDA. Visitors to Pathway sites are subject to
Pathway vetting procedures.
At the Post Office, visitors such as engineers and auditors are not known
individually to the system. However, they are known to the Horizon
System Help Desk, and authentication includes use of a one-time
password which requires calling the Help Desk. In these cases, the
telephone authentication procedure described in 3.6.2 is used to identify
the site, and is supplemented by verification of the particular visitor,
generally including their pass number.
3.7 Key Management
Cryptography is used widely in Pathway as described in the Security
Functional Specification [SFS]. For example, it is used for:
¢ Confidentiality and integrity protection of some or all data on
particular links e.g. CMS to De La Rue, CAPs to PAS/CMS, system
management workstations to the Pathway Central sites.
e CHAP authentication between Post Offices and Pathway Data Centres
¢ Digitally signing information such as benefit authorisations in transit
to Post offices, automated payment records from Post offices and
software distributed via Tivoli.
e Filestore encryption at the Post Office.
Use of cryptography requires use of cryptographic keys. This Access
Control Policy defines how the cryptographic keys are protected when in
the information systems. As different keys are protected in different
ways, this is generally defined with the other controls at the appropriate
domain. The Key Management Service at the Pathway campus is
included in the POCL Central Services domain.
Keys are protected in line with CESG requirements.
3.7.1.1 Key material (symmetric keys, DSA private keys and DSA entropy) is
held in clear only when in physically secure environments.
3.7.1.2 Keys are changed periodically according to CESG policy. Different
periods are expected to apply to:
e Symmetric keys used for encrypting data
e Key Encryption Keys (KEKs) used to encrypt other keys
© Certification Authority keys.
3.7.1.3 New KEKs are not distributed using existing KEKs.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 36 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
3.8
3.8.1.1
3.8.1.2
3.8.1.3
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:
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 acces
required.
s
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.
e users in these roles must be controlled through a formal registration
process. Each user must be authorised to take that role by the
appropriate authority before being added to the IT system. Records of
all persons registered to use the system must be kept, though the way
this is done may be role or service dependent.
This Access Control Policy depends on Pathway procedures in some
places. The key ones are:
e Pathway (and associated) staff visiting other sites must have a identity
pass with photograph and signature. This must be from a relevant
organisation which gives such passes to suitably vetted staff only.
¢ Post Office procedures which must include how to add users to
Riposte, how to physically protect tokens and passwords, procedures
for telephone authentication to Help Desks etc
e Girobank procedures associated with the PAS/CMS Help Desk. These
include procedures for telephone authentication and action to be
taken on different types of calls. It also includes Girobank procedures
need to cover user and system administration in line with this policy.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 37 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
¢ 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 6 and 10).
e System management procedures to authorise, for example,
distribution of software.
e Technical Help Desk procedures to ensure all relevant calls are logged
with the SMC Powerhelp 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: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 38 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
4. THE DSS SERVICE ENVIRONMENT DOMAIN
4.14 Introduction
The DSS Service Environment Domain is illustrated in figure 4-1.
Pathway
pata ; ~“ ICL Series 39 EDS Pathway
oundary [we Management
lary
DSS Partition™: Pathway Partition Boundary
DSS applications I Pathway Access
CAPS or ESNS Service
—L > Let
Local LANs
Firewall
Routers
DSS/BA site
To Pathway Data Centres
Figure 4-1 DSS Service Environment Domain
The DSS Service Environment Domain provides the interface between
Pathway and the Benefit Agency’s systems at DSS sites. These are the
CAPS and ESNS systems.
In both cases, applications in the Pathway partition of the VME machine
handle transfer of information to/from the DSS partitions and to/from
the Pathway Services at the Pathway Data Centres. The VME part of the
CAPS Access Service (CAS) and the OBCS Access Service (OAS) transfer
the information to/from the part of the Access Service at the Sequent
system at the Pathway Data Centre, for transfer to the appropriate
Pathway service (PAS/CMS or OBCS).
Transfer of this information is automated, and does not require human
intervention.
This domain includes the following components:
e The software running in the Pathway partition of the VME platform,
and
e The Pathway routers used to route traffic to the Pathway Data
Centres.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 39 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
4.2 Roles
The Pathway routers are managed as part of the Pathway Network
Management as described in 10.4.
There are two types of roles with access to the Pathway partition on the
VME CAPS/ESNS machines. These are:
e Roles for managing and supporting the Pathway partition and the
applications in it.
¢ Roles for managing and supporting the VME system of which the
Pathway partition is part. These include the EDS staff managing the
VME system (including its split into partitions and resources allocated
to these partitions) and the engineers analysing/repairing hardware or
base software errors which involve the Pathway partition.
This Access Control Policy covers the roles for managing and supporting
the Pathway partition. It does not define the roles of the EDS staff and
Engineers who handle the VME platform as a whole.
Pathway System Management staff monitor the progress of the Pathway
VME partitions using Patrol c.f. monitoring the Sequent systems at the
Data Centre. All failures and warnings in CAS and OAS are raised as
Patrol alerts. System Management via Patrol is described further in 10.3.
The following table lists the roles for the Pathway partition.
Note: The split of responsibility for these roles has not yet been agreed, so the organisation
responsible for the people in this role is not given. When responsibilities clarify, the
definition of these roles will be reviewed.
Role Main Functions
System monitoring I Monitoring events in the Pathway partition.
Operational Operational management within the Pathway
management partition, including daily housekeeping.
Security Manager I Administering users of the Pathway VME
partition.
Cryptographic Key I Installation of the Red Pike cryptographic key
Custodian (CAPS, I which is used to protect the transfers of
but not ESNS sites) I information from CAPS to the Pathway Data
Centres (at least the trailer record giving the file
totals and the checksum).
Application Supporting applications in the Pathway partition,
support particularly CAS and OAS.
Pathway Security Auditing security events relevant to Pathway.
Auditor
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 40 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
4.3 System Access Controls for Human Users
The following table specifies for each Pathway partition role what access
users of that role have to the system. In all cases, the user is individually
identified. The user will be authenticated using the VME Enhanced
Security Option. Where access to VME is from a remote site, these users
will also have been authenticated individually to others systems - see
sections 10 and 11.
Role Access route Resources Available
System Interactive (MAC) Read only access to
monitoring access from remote Pathway partition files
site via Sonnet on except those holding
Sequent. cryptographic keys.
(Can also use Patrol)
Operational MAC access Update access to partition
Management files including software,
but not cryptographic keys.
Security Manager I MAC access User admin functions only.
Cryptographic Local MAC access Key installation software
Key Custodian and files only.
Application MAC access Relevant applications and
Support associated data (e.g. trailers
in main data files).
Pathway Security I MAC access from Audit logs only (including
Auditor remote site user administration
records).
4.4 System Access Controls
The Pathway VME partition has its own filestore separate from other
partitions. This filestore will be 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 41 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
4.5 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.
e Patrol management using ADI
e MAC interactive access for management, support and auditing
e Network management traffic to the routers.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 42 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
5. POCL AND POCL CLIENTS DOMAIN
5.1 Introduction
Pathway has links to POCL and POCL Client systems. These are:
e The POCL TIP system to which records of all 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 Automated Payments system which proc
payments on behalf of POCL Clients. This will be repl
by direct links to POCL Client systems.
s Automated
ced in future
At each POCL site, there are Pathway PCs and routers connected to the
POCL systems as shown in the following diagram.
POCL Systems
POCL Firewall
POCL
Pathway boundary
Pathway PC Pathway PC
file transfer file transfer
& firewall & firewall
POCL site Router Router
To Pathway Data Centres
Figure 5-1 Pathway components at POCL Sites
The Pathway PCs at the POCL sites handle file transfer to and from the
Pathway Data Centres. These PCs also contain firewall software to
protect Pathway from the POCL systems.
[Nove: this has not yet been formally agreed. I
The PCs are expected to be managed using Tivoli System Management
from the Data Centres. The routers are managed using network
Management from the Data Centres as described in 10.4.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 43 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
There are some differences between these POCL sites as follows:
e Automated payments are signed and transferred over ISDN links;
e The TIP/Reference data link will be encrypted (post release 1)
5.2 Roles
The PCs and routers at the POCL sites will not normally have any
human access - the only role supported is for engineering access. This
will not be done while the PCs are configured into the operational
system.
There may also be a Key Custodian role (post release 1).
POCL Auditors are not users of the Pathway components at POCL sites,
so are not listed here.
5.3 Control of Connections to the Pathway Data Centres
Only the following traffic will be permitted between the Pathway Data
Centres and POCL sites:
e The file transfers between Pathway hosts (TIP/EPOSS, Reference Data
and AP) and the POCL systems
e System Management traffic to manage the PCs using Tivoli [to be
confirmed.]
e Network management traffic for router management
The WAN (and in the case of the AP system, the ISDN) routers at the
Data Centre will not permit other traffic to POCL sites. The Pathway
router at the POCL sites accepts only this traffic.
5.4 Control of Connections to POCL Systems
Access from the POCL systems uses FTF. A firewall software product on
the PCs at POCL systems is expected to restrict traffic as required (and
provide address translation to Pathway IP addresses.)
[Note: to be confirmed. ]
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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 44 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
6.1 Introduction
The POCL Central Services Domain is illustrated in figure 6-1.
POCL or
POCL Clients TIP POCL ESNS CAPS
Sdquent
Hosts
TIP/ Ref. PAS/
APS! lepossI [Data] [OBS] cms
Management
& Support
users NY Servers
TMY Agents \
F Crypto
TP Ref 1 ogcs}I Bes I] Iserver: Data
Harvester Data Agents} IAgentsI & Kev arehouse
Agent I {2 si & Key feeds
T T T T Manag’
t 7 ; ; System
Correspondence Servers (Riposte)
I
Post Offices
Figure 6-1 Interactions in the POCL Central Services Domain
The hosts at the POCL Central Services Domain are on Sequent
machines running Oracle applications - APS, TIP/EPOSS, OBCS and the
Reference Data Management Centre. (The PAS/CMS host and associated
Help Desk is complex enough to be considered a separate domain).
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, either to retrieve
information to send to the Post office or to update tables as the result of
messages received from the Post office. (Currently, all host applications
store data in Oracle databases).
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 45 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
One set of TMS agents (TIP Harvesters) extract all transactions from the
correspondence service (via the Riposte API) for forward transmission to
TIP. These also pass on transactions to application based agents for APS
(and thence to POCL) and TIP/EPOS and to the Data Warehouse. The
BES and OBCS Agents are separate.
The Correspondence servers are the part of the Transaction Management
Service at Pathway campuses. They record all transactions at the Post
Office Counters and archive these.
The main operational flows though the hosts, TMS Agents and TMS are
automated, as is most System Management. (System Management is
described in section 10).
6.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 6-2.
Data feeds to/from
DSS,POCL & Clients
Operational roles Y yystem Management
Pera CS me Sequent/Dynix I. “event and inventory
(application specific) oe
monitoring
Access \
Security Management Service Operational Management
- user management of Sequent/Dynix,
- resource controls [Oracle database,
- security auditing job scheduling
Applications
Engineers and .
- hardware diagnostic... Databases Base Installation
and Configuration
and repair
TMS
Automatic feeds
Figure 6-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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 46 of 105
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Similarly, most of the system management is done automatically (see
section 10). As the results of monitoring the system, the need to take
some remedial action will be recognised, and this action will generally be
taken automatically. Only in exceptional circumstances is human
intervention required. Active users on the operational system (apart from
Tivoli system management) are defined in 6.2.1. The main users are:
e Security management who manage security information about users,
access controls on resources such as files and database views etc.
e Operational Management people responsible for the management of
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 Auditors
6.2.1 Roles
People in the following roles have direct access to the Sequent machines.
Role (and Main classes of functions
organisation)
‘Computer Operator _ I Physical operations e.g. media handling, but no on-line use
(CEM) of the system.
System Monitoring Monitoring the operational system using Patrol.
(CEM)
Operational Management of Dynix including any action needed
management concerned with replication between campuses and local
(CEM) archiving.
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
(CEM) membership for all users of the Sequent system.
Administering Oracle database administrator (DBA) users
and associated roles and privileges.
Emergency Operational management done by CFM staff on call. This is
operational a subset of the full operational management functions above.
management (CFM) It does not include security management or application
support.
Dynix 3rd line Operational management of Dynix by Sequent staff when
support (Sequent) CFM cannot cure problem.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 47 of 105
FUJ00117497
FUJ00117497
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Role (and Main classes of functions
organisation)
Database 3rd line Operational management of Oracle when CFM cannot cure
support (Oracle) problem. This may sometimes require updating the
database.
Application support I Supporting Sequent/Oracle applications, including having
(SSC) access to the data in the database, not just its structure.
Application 3rd line I Supporting Oracle applications
support (Oracle)
Engineer Hardware diagnostics and repair including disc support
Base Installation and Initial installation and configuration the base system -
configuration (CFM) _I Sequent and Oracle databases. Later updates to these.
Security Auditor Auditing security related actions
6.2.2 System Access Controls for Human Roles
As for all domains, system access controls conform to the policies in
section 3.5.2. Specialisations of the policies for this domain are:
¢ Certain operational management roles on Sequent allow a change of
username (see 3.5.2.12). This is restricted to use within the secure
menu system described below.
Access controls are the Sequent system are enforced using Dynix facilities
with some additions. In particular, all operational management users will
access the system using a secure menu system. This constrains the
functions called depending on the user’s role. It also audits all functions
performed by that user. Most management activities will be done using
specific functions on the menu. Where the function requires a change of
username, that will be done automatically by 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.
Note: Some of the operational and system management users have access
to a number of systems and are described more fully in section 10.
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, where the
users taking this role are defined and what resources are available to
people with this role.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 48 of 105
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Role Workstation type Location Authentication method Where user defined Resources available
Computer None Pathway campus none, as no access - none in system
Operator
System X terminal (or Pathway campus UNIX with individual UNIX Resources as available via
Monitoring emulator) and Belfast user name & password Patrol
Operational NT Workstation (X CFM secure site UNIX with password and I UNIX with associated Functions as on menu. This
Management terminals or emulators token authentication (see I group; Oracle user with can allow use of root and
for Patrol & Maestro) note 3) associated role for dba UNIX commands and Oracle
& Oracle password functions dba functions.
Security NT workstation on CFM secure site UNIX and token (see as above User information in UNIX
Management secure LAN note 3) and Oracle
Emergency NT Workstation on CFM site (see note} UNIX and token as Operational as Operational Management
Operational secure LAN 4) authentication (see notes. I Management above above
Management 3,4)
Dynix 3rd line NT workstation Secure site (see UNIX plus token as above UNIX, which can include
support note 6) (see notes 5 and 6) root access
Oracle 3rd line NTworkstation Secure site (see UNIX plus token as above Oracle dba functions, and
support note 6) (see notes 5 and 6) limited UNIX as needed for
db support
Application
Support
NT workstation
Pathway secure site
UNIX
Associated UNIX and
Oracle usernames
Relevant application and
associated data onl
Application 3rd__ I NT workstation Secure site (see UNIX plus token as above as above
line support note 6)
Engineer computer console Pathway campus; I UNIX with engineer UNIX Access to relevant diagnostics
password (see notes 5 &
7)
and, when needed, data on
suspect hardware
Base Installation _I computer console Pathway campus __I UNIX UNIX user and group most
Security auditor I NT workstation on Feltham UNIX and token UNIX Audit logs
secure LAN authentication
Printed: [ DATE \l ] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc
Page 49 of 105
FUJ00117497
FUJ00117497
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
6.2.3
Notes:
1. Wherever possible, responses to events are automated, to prevent the
need for human interaction.
2. Wherever possible, responses to events which require human
interactions are performed using pre-defined functions, rather than
command line access to the system.
3. Operational management staff always authenticate under their own
names to UNIX and perform functions wherever possible without
root privilege. 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.
4, Emergency operational management by CFM staff on call. This is
currently expected to be from the CFM secure site at Belfast.
5. All visiting staff will be 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.6.3.
6. Sequent and Oracle staff will provide 3rd line support. This may be
from the Data Centre. Where visiting Sequent or Oracle support staff
are not known to the Sequent system individually, but are authorised
by the manual mechanisms, a special UNIX user and password will be
set up to allow them to use the system for this session under
supervision.
Access from Sequent and Oracle sites is being considered. If so, this
will always be done from a secure LAN ina secure area via an
encrypted link to the campus.
7. Visiting engineers are subject to manual procedures as in 5 above.
Dynix and Oracle Access Controls
The Dynix operating system should be set-up according to the acc
control policy in 3.5.2 above. For example, Security Audit Logs (both
Dynix and Oracle ones) will only be accessible to Security 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 will be done by
automated processes. Interface tables used for this will generally be
defined in separate database views to restrict the damage possible due to
failures during automated processes.
Database administration will be split into roles as defined above,
separating database administrative functions concerned with the structure
of the data and the resources used from user management and from
access to the data in the database.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 50 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
6.2.4
6.3
Control of Connections to the System
All links to the Sequent systems are controlled by routers and by controls
on the use of Sequent ports. These restrict access to the Sequent system
from other services at the Pathway Data Centres and elsewhere. There
will be a separate port for each application and type of link to that
application. The following traffic will be permitted:
e Telnet and X-terminal access to Dynix for operational management,
3rd line support, job scheduling and security auditors
¢ OSI traffic to VME (FTF, ADI and MAC) to support file transfer and
management
e¢ SQL*Net access to Oracle databases from Girobank Help Desks and
agents extracting data from the databases for transfer to the Post
offices, to the Data Warchouse, to archives and exceptionally for
Fraud Risk Management
e File transfer to PCs for transfer of business data to/from POCL and De
La Rue
Note that the links from remote management sites, including the CFM
sites, are encrypted.
Windows NT Systems
There are several NT systems in this domain. TMS Agents are generally
on separate NT servers from those used for the Correspondence Servers.
The Cryptographic Servers and Key Management System are also on
separate NT servers. Further NT systems in this domain, for example are
the PCs providing the interfaces to transfer files to De La Rue, POCL and
the server supporting the Time Service.
Users of the NT servers are illustrated in figure 6-3.
Operational Data feeds
'
Operational roles NT System Management
(application specific) ~~ I - software distribution
- resource management
Security Management - event monitoring
- user & resource admin I_I Applications
- security auditing and [—~ System Administration
Infrastructure
Base Installation
and Configuration
Engineers _
Figure 6-3 Users of NT systems
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 51 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
As for the Sequent systems, most of the use of the NT systems is
automated so human intervention is an exception. Different NT servers
are used to 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 10) and
appropriate remedial action is generally taken automatically. User
administration is done using NT uti
¢ Software and configuration information is distributed to these systems
via Tivoli (see section 10).
¢ 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 6.3.1. However,
extra roles are used at some NT systems. For example, Riposte
administration is required at the Correspondence servers and there will
be a person responsible for keys at the Key Management System. Such
specific roles are included in the particular sub-section about that system.
6.3.1 Roles
People in the following roles have access to all NT systems in this
domain.
Role (and Main functions
organisation)
Computer Operator sical operations ¢.g. media handling, but no on-line use
(CFM) system.
Operational on site I Any residual management of NT (not done by system
management management) which requires on site access.
(CFM)
Security Management I Administering NT user information, including group
(SMC) membership.
Engineer (DSD) Hardware diagnostics and repair
Base Installation and Initial installation and configuration the base system - NT
configuration (CFM) etc Later updates to this.
Security Auditor Management of, and access to, Audit logs.
(Pathway)
6.3.2 System Access Controls for Human Roles
ociated with these roles is defined in the followed
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 52 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Role Where defined Workstation type Authentication
and location method
Computer Operator I - no wis; on site at none, as no access
Pathway campus
Operational on-site I NT with associated I campus NT with password
Management group;
Security as above NT workstation at I NT with password
Management secure Pathway plus token
(SMC) site
Engineer NT user Pathway campus; I NT with password
no remote access
Base Installation NT user and group __I Pathway campus NT with password
Security Auditor NT user NT workstation at I NT with token
Feltham
6.3.3 System Set Up
System access controls will conform to the policies in 3.5.2.
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 will 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.
6.3.4 Control of Connections
The following traffic is generally permitted to NT systems at the Data
Centre:
e Telnet traffic for NT management, security auditor access etc
¢ NT domain traffic
¢ Maestro job scheduling
e 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C y Documents\ACPV.1.doc Page 53 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
6.4
6.4.1
Correspondence Servers
The Correspondence servers and their interactions with other services
are illustrated in figure 6-4.
Hosts on Sequent
I
System Management
Security management
System Admin =~
Engineers Bipas APL Al . I
ICorrespondence Servers
I__ Riposte Managem ent
TMS Agents
: Pathway Fraud
Risk Management
(Riposte)
aN archives
Riposte journals :
at Post Offices
Figure 6-4 Correspondence Servers and their Interactions
The Correspondence servers, together with the Riposte infrastructure at
the Post Office handling the Riposte journals there form the Transaction
Management Service. TMS handles all application traffic between the
Pathway campuses and the Post Offices. Note that there is other traffic
between the Pathway campus and the Post Offices for System
Management traffic and Key Distribution.
Roles
Operational use of Correspondence Servers is automated, so does not
require human intervention. This includes transferring data to the Post
Offices and transactions back from them and archiving these
transactions.
People in the following roles have direct access to Correspondence
Servers (in addition to System Management, Operational Management,
Security Management and Engincer roles described in 6.3):
Role Main Functions
Riposte Management (SMC) I Setting up and maintaining Riposte message
stores and archives. Any configuring of
correspondence servers which is not
automated. (Setting up Correspondence
servers as members of Riposte groups when
new Post Offices are added will be done by
the auto-configuration application.)
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 54 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Role Main Functions
Pathway Fraud Risk Limited access to the TMS transaction log
Management (see note)
‘Application support (SSO) Supporting Riposte and other applications
Note: FRM access to the Correspondence servers may be allowed in
exceptional circumstances for limited amounts of data (as otherwise, the
performance of the system could be impaired).
6.4.2 System Access Controls for Human Roles
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 SMC NT Correspondence I Appropriate
management I secure site (see server user with Riposte utilities
10.2) token
Security NT at Feltham NT Correspondence I Audit logs and
auditor secure area server user with limited read only
token TMS access
Pathway NT at Feltham NT Correspondence I Limited read
FRM secure area server user with only TMS access
token (see note)
Riposte NT at Feltham NT Correspondence I Read only
application server user and Riposte access
support password
Note: Details of this access have still to be agreed. If no specialised query
tool is available, relevant Riposte utilities will be used e.g. Message
Query and Message Spy.
6.4.3 System Set Up
For the Correspondence servers, the initial system set up will include the
initial configuration of Riposte. Different Riposte utilities are available to
different types of user. For example, Auditors and Fraud Management
staff will be restricted to utilities with read only access to TMS.
6.4.4 Control of Connections
Connections permitted in and out of the correspondence servers are the
general NT ones listed in 6.3.4 plus:
e data transfers to/from agents using Riposte RPC
e data transfer to/from Post Office via TMS
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 55 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
6.5
BES Agents
The interactions with the BES agents are illustrated in figure 6-5.
PAS/CMS KMS, Entropy Servers
Vy
NT server Security Managem ent
Key Custodian System Management
BES System Admin
Engineers
Agent
'
Correspondence Servers
Figure 6-5 Interactions with BES Agents
BES Agent signs payment authorisations before they are transmitted to
the Post Office. The BES Agent calls on an Entropy Server on a separate
PC to obtain the entropy needed for signing using DSA.
The main difference for Access Control purposes between the BES and
other NT servers in this domain is that it requires secure installation of
keys (the Pathway DSA private key for protecting payment authorisations
and associated public key certificate etc) and protection of these keys and
the associated entropy within the NT system.
So roles at the BES Agents are the Cryptographic Key Custodian
responsible for the required keys and certificates (as defined in 6.9.3) and
the Management, Engineer and Security Auditor roles as for other
Campus NT systems as defined in 6.2.
Connections permitted to other systems are:
¢ SQL*Net links to PAS/CMS for payment authorisation and card
information etc
e Links via the Riposte API u: RPC for distribution to/from TMS.
e Links to the Entropy Servers to obtains DSA entropy.
e Links to KMS for distribution of some key material using key
distribution protocols which protect keys in transit.
e System Management links to Tivoli servers at the Campus.
Routers will be configured to allow only these links.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 56 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
6.6 Specific OBCS Related Services
Figure 6-6 illustrates the flow through the OBCS applications. Note that
this is very similar to the flow through the Benefits Payment Service as
described in 2.3 except that there are no links to card production, no
associated help desks and the agents are simpler.
DSS ESNS system
I
OBCS Access Service
Sequent
Security Management
‘em Management
tem Admin
OBCS Agent Engineers etc
NT
Correspondence servers !
1
Post O ffice
Figure 6-6
The OBCS Related Services are similar to the hosts and agents for other
applications and have no special access control requirements. Access
controls for the Sequent based applications as defined in 6.2 above and
those on NT as defined in 6.3 above.
Connections to other systems are as illustrated in figure 6-6. (The
Sequent connections are included in the table in 6.2.4.)
6.7 Reference Data Management Centre
Reference data is mainly the data associated with particular applications
such as the price of stamps for EPOSS and the meaning of reason codes
in BPS. However, it also includes other data such as the telephone
number and the name of the Post Office Manager for a Post Office and
the meaning of Help desk Codes used by the Horizon System Help Desk.
Interactions with the Reference Data Management Centre on Sequent are
illustrated in figure 6-7.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 57 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
POCL POCL Clients and others
(Via PC)
Sequenny v v Y —
RDMC System
ed ~~ Management
Management Reference Data Managment Centre etc
Y X
RDMC Agent Data Warehouse
v
TMS
Figure 6-7 Interactions with Reference Data Management Centre
Data is fed into the Reference Data Management Centre (RDMC) from
POCL and in future also other sources including POCL Clients. Data
coming in is classified according to whether it should be used to update
the RDMC 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.
Application reference data for EPOSS, OBCS etc is distributed via the
TMS system to the Post Offices.
Reference data is also fed to the Data Warehouse, for example, to define
transaction codes and the shape of the records to assist in the analysis of
transactions.
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 must be available and shown to work with it.
The RDMC is on the Sequent system, so subject to the controls in 6.2.
The RDMC manager kicks off the transfer of validated reference data of
classes 2 to 5 to TMS when all required dependencies have been met.
RDMC users have read access to the RDMC to assist in satisfying the
dependencies. Oracles roles control this access. The RDMC Manager and
Users are based at Feltham and access the RDMC from NT workstations
there via the encrypted links.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 58 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Note that the security management role in 6.2 includes user management
of the core users of the system, including the RDMC users.
6.8 Specific TIP Related Services
The Interactions with the TIP services are illustrated in figure 6-8.
TIP
A
PC forPOCL file transfer
A System Management
t x
; System Admin
Sequent I TIP/EPOSS Engineers
k
i
NT server ITIP HarvesterI——®™ Data Warehouse
Correspondence Servers
Figure 6-8 Interactions with the TIP services
The TIP Harvester handles all transactions from the Post Offices and
forwards transactions via the TIP/EPOSS host to the POCL TIP system. It
also supplies data automatically to the Data Warehouse.
The TIP/EPOSS host has access controls as for any other Sequent based
host, so roles and system set up are as defined in 6.2 above.
The TMS Agent has access to all business transactions from Riposte, as
all these need to be passed onto the TIP system and Data Warchouse
(whereas other Agents should only have access to the transaction types
they need to handle). Apart from this, the TIP Harvester Agent is
controlled as for any other TMS Agent running on an NT system as
defined in 6.3 above.
6.9 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 servic
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 59 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
e A Key Management Service (KMS) which (generates and) stores
cryptographic keys for distribution to other Pathway services and the
Post Offices.
Associated with this is a Certificate Authority (CA) to generate public
key certificates and Entropy servers which generate DSA entropy for
digital signatures.
An Authentication Service to support token authentication.
The security services supporting encryption of links to other sites.
6.9.1 Key Management and Associated Services
Interactions with the Key Management Service and Certificate Authority
are illustrated in figure 6-9.
. NT Security Servers
Cryptographic Management,
Key Custodian y . 7
¥ ann vent I_I Entropy ertificationI ~ Engineering
ger Servers Authority ete
Help Desk —- Service
pS Agents BES
typto Servers A sonts
Post Offices
Routers
Figure 6-9 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.
A Certification Authority (CA) is used to generate public key certificates
used when verifying digital signatures. This CA may be co-located with
the KMS, though all CA functions are off-line.
(Private/public DSA key pairs are used to sign payment authorisations
and also to sign software and Tivoli scripts before distributing them to
the Post Office. Digital signatures are also used at the Post Office to sign
automated payments.).
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 60 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
6.9.2
6.9.3
The Pathway Cryptographic Keys Manager will be responsible for
generating keys at the KMS and providing the recovery key for a Post
Office Manager who has lost his card or PIN, so needs one.
Apart from this, these NT systems will be set up with the roles and access
controls as described in 6.3 above.
[Note
control of connections for the KMS and CA have still to be defined. I
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.
details of this Authentication Services have still to be finalised. I
The Authentication Service holds information about:
e Tokens, and when, and to whom, they are assigned; also the PINs
associated with these tokens
e Users of these tokens
e 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
e Configuration options such as the type and size of PINs permitted,
Client retry interval, master/slave information
The main roles at this system are:
e¢ Management of the underlying UNIX system
e 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.
Key Custodian Role
Several of the systems at the Data Centre require a cryptographic key to
be installed and periodically changed. These keys are used to
encrypt/decrypt data in transit between sites.
Such keys are installed manually on the following systems:
e The BES agents. These have the private key for signing payment
authorisation for transmission to the Post Offices.
e The Sequent system (Red Pike key for protecting the link to CAPS)
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 61 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
6.10
6.11
e The PCs handling the De La Rue links. Keys are needed at PCs on
both the Pathway and De La Rue sites.
e The Zergo boxes used to encrypt certain links e.g. Pathway Data
Centres to Pathway sites such as Feltham and Stevenage.
e In future, the TIP link.
The private key for signing software will be installed at the Configuration
Management system at Feltham.
Where keys are installed manually, the same Cryptographic Key
Custodian is responsible for all systems. In all cases, this role is set up so
that the user must be a local one. The Key Custodian authenticates using
a token. The Sequent or NT box used for this must therefore support a
SecurID client. Also, the filestore used to hold the key must be accessible
only to the Key Custodian.
PCs Handling External Links
File transfers between the Pathway Data Centres and POCL, De La Rue,
and in future, POCL Clients are handled by PCs at either side of the link.
(File transfer to/from CAPS is directly to the Sequent machines.)
These PCs will be set up to limit the functions possible there to a
minimum. The PCs at the POCL and De La Rue sites are controlled as
described in sections 5 and 9. In general, these, and the PCs at the Data
Centres will be managed as for other NT systems as described in 6.3.
Note that at least the De La Rue PC supports a Key Custodian role as
defined in 6.9.3.
Other Data Centre Services
There are a number of other services at the Data Centres such as:
e The Automated Payments Service on Sequent which takes payments
extracted from the TMS journal by the TIP Harvester and feeds data
to the APS PC at the Data centre and from there to POCL (and in
future, POCL Clients).
e The OBCS Service on Sequent
¢ The Time Service on NT
These services have no special access control requirements. On Sequent
access control is as specified in 6.2 above and if on NT, as in 6.3 above.
System Management Servers are covered in section 10 below.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 62 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
7. PAS/CMS SERVICE DOMAIN
7.4 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 campuses and share one
Oracle database. Access controls for these are described in 7.2 below.
The PAS/CMS Help Desk supports customers, Post Offices and the
Benefit Agency enquiring about payment authorisations, cards and PUNs.
Help Desk Advisors have access to the PAS/CMS system via Oracle
Forms from NT workstations. The Help Desk is managed by Girobank.
Access controls for these are described in 7.3 below.
7.2 PAS, CMS and CAPS Access Services
The interactions with PAS, CMS and the associated access service to
CAPS are illustrated in figure 7-1.
CAPS
Automatic feeds
PAS/CMS Help Desk Sequeny/Dynix Pathway Fraud
- PAS/CMS access CAPs Access Service Risk Management
- Help Desk user mgn’t Pathway campus part
System and
Security Management Operational
7 i PAS and CMS fo = Management
- user management Applications ig
- resource controls P and
- key custodian and Database Wa Engineers
TMS Card production Data Archives
via gateway PC — Warehouse
Automatic feeds
Figure 7-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
Producer to generate cards and PUNs. Information is returned from both
these sources, processed and returned to the CAPS system. The main
ng is done automatically without human intervention.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 63 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
7.2.1 Roles
General roles for the Sequent system are defined in section 6.2. Specific
PAS/CMS roles are:
e PAS/CMS Help Desk Advisors using Oracle Forms applications to
PAS/CMS queries in response to calls and Help Desk Security
Managers maintaining information about Help Desk Users at the
PAS/CMS database. These users are further described in 7.3 below.
e Application Management generating payment authorisations when
CAPS is down.
e Cryptographic Key Custodian installing/updating the encryption key
needed for the CAPS to PAS/CMS link.
e Fraud Risk Management staff accessing PAS/CMS data when required
information is not available via the Data Warehouse or archives.
7.2.2 System Access Controls for Human Roles
Access controls associated with these roles will conform to the policies in
3.5.2. The following table shows the system access controls associated
with these roles. Apart form the Cryptographic Key Custodian, all these
users access PAS/CMS information via Oracle tools.
Role Workstation How authenticated I Resources available
type and to PAS/CMS (&
location where user defined)
Help Desk [NT Help Desk I Oracle username, lar database views of PAS
Advisor workstation in I password S tables required for the
Girobank area at I (Oracle user authorised Oracle Forms (with
campus associated with sufficient write access to allow
Oracle role) cards to be stopped, update call
logging tables and change
password.)
Help Desk [as above as above ‘As above, plus the ability to
Supervisor handle NSI calls (see note) and
other more restricted dialogues.
Help Desk as above Oracle username, Oracle user and role tables via
Security password (Oracle I authorised Oracle Forms; access
Manager user associated with I as Help Desk Advisors plus
Oracle role) privilege to create users and
assign/re-assign them to Help
Desk roles.
Cryptographic [local machine [UNIX with Special file containing key
key custodian I console password and token
Fraud Risk Girobank FRM I UNIX with Read only access main database
Manager arca and Feltham I password and token Iin exceptional circumstances
Note: A separate role may be defined for Help Desk Advisors who can handle data with a
National Sensitive Indicator.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C y Documents\ACPV.1.doc Page 64 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
7.2.3 Base System Access Controls and Control of Connections
In addition to the general Sequent controls in 6.2.3 above, for PAS/CMS,
a separate username is required for the Cryptographic Key Custodian.
Filestore accessible only to that user holds the cryptographic key.
All connections to the Sequent system are covered in section 6.2.4.
7.3 PAS/CMS Help Desks
The PAS/CMS Help Desks are run by Girobank at the central Pathway
sites. They handle the following types of calls:
¢ Calls from Post Office counter clerks about payment authorisations
and cards. Some of these can initiate changes to the 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
The Help Desks use NT workstations with shared NT servers. The
workstations are linked via routers to the PAS/CMS system for queries
on the PAS/CMS database.
Interactions with the Help Desk systems are illustrated in figure 7-2.
Post Office
Counter Help Desk NT Network Help Desk
Clerks Sng Oracle Forms Manager
supporting
\ PAS/CMS access
gs.” Help Desk
Customers Ping ~~ g Pa-line documentation System &
¢ je.g.Procedures used by M 5
Help Desk Help Desk Advisors anagement
Advisors,
~ Supervisors Local office
DSS/BA and Managers applications [> Engineers
PAS/CMS Data Warehouse
Figure 7-2 Interactions with the PAS/CMS Help Desks
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 65 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
7.3.1
Help Desk 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 Girobank NT servers.
Help Desk Supervisors also have access to some local office applications.
Help Desk Managers rarely use the information systems, but if they do,
have the same access to PAS/CMS as other Help Desk Users. They may
use different local applications.
The Help Desk Security Manager is responsible for administering
information about Help Desk users at both the local Girobank system
and PAS/CMS.
Help Desks and their associated systems are run by Girobank, so are not
managed by CFM and are maintained by different engineers.
Roles
People in the following roles have direct access to the Help Desk
Network. All are in the Girobank Help Desk area of the campus and all
use NT workstations. All are Girobank personnel except the engineers.
Role Main functions
Help Desk Advisor Use Oracle Forms to access PAS/CMS queries is
response to calls - see 7.2.
Help Desk Manager As Help Desk Advisor, plus use of local
Girobank office applications
Help Desk Supervisor I As Help Desk advisors plus:
- extra transactions at PAS/CMS
- local applications
- applications analysing Rockwell ACD data
Help Desk Advisor in
training mode
Use standard Advisor Oracle Forms to access
training version of PAS/CMS database
Help Desk Security
Manager
Maintains information about Help Desk users
locally and in PAS/CMS.
Auditor for local systems
System & Network
Administrator
Manages Help Desk NT Network - installation
and operational management.
Base software installation and configuration.
Distribution of software (including Oracle
Forms) from Help Desk Servers to workstations.
Management of Girobank routers etc
Engineer
Hardware diagnostic and repair
In addition to these roles with direct ¢
to the system, operational use
of the system also requires some indirect users as shown in figure 6-3. i.c.
Post Office counter clerks, Benefits Agency staff and Customers.
Printed: [ DATE \l]
C:\My Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 66 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
7.3.2 Local Network Configuration
The Girobank Help Desk network is illustrated in figure 7-3.
@) Network Management
/ (HP Openview etc on UNIX)
» « @
ne = <= Girobank NT servers
Help Desk NT workstations Routers
PC with a WAN router at Data Centre
Rockwell — I
ACD link PASS
Figure 7-3 Help Desk Configuration
The Pathway Access Control Policy is concerned with controlling the
access from the Help Desk to the Pathway systems. Controls at the
PAS/CMS Sequent system will restrict access to defined Oracle views.
However, as write access is needed (to stop cards etc) control of the
Oracle Forms applications is needed in the Help Desk environment to
ensure Help Desk staff can only use authorised Oracle Forms menus and
the associated authorised set of Oracle Forms for the permitted role.
All Help Desk staff use NT workstations. All these workstations can be
used for:
e Running PAS/CMS transactions on PAS/CMS via Oracle Forms
e Viewing on-line documentation. Some documentation will be available
to all Help Desk Advisors. Other documentation is restricted to Help
Desk Managers and/or Supervisors.
e Running local office applications, including the application to monitor
telephony traffic. (Any workstation can be used for training activities,
even though special workstations may be allocated for formal training
cours
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.) There will be at least
one workstation on the Help Desk network with a floppy drive, but this
will have controlled access and cannot be used to access PAS/CMS. (This
is to allow supervisors to produce documents at Help Desk workstations
and transfer them to laptops and other systems.)
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 67 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Some applications and on-line documentation are held on the NT
servers. Read only access is provided to all Help Desk Advisors,
supervisors etc. For performance reasons, Oracle Forms applications are
held at the workstation.
Girobank System and Network Administrators set up and administer the
NT systems, including distribution of software within the network and
administration of the Girobank routers.
7.3.3 Control of connections to the Help Desk
Most connections into the Help Desk are telephones. These are
independent of the Help Desk network except that information is fed
from the Rockwell ACD to a particular PC so that telephone traffic can
be monitored. This PC will be configured as a separate domain so the
telephony data can be routed automatically only to this PC. However, a
Supervisor at a standard Help Desk 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:
e Oracle Forms for using the PAS/CMS database - both in response to
telephone calls and by the security manager for administering user
information
e Feed of information about calls (from Rockwell ACD) to Data
Warchouse system.
This Access Control Policy document does not cover functions internal
to the Girobank network which do not affect the rest of the Pathway
system e.g. configuration and management of Girobank routers.
7.3.4 System Access Controls for Girobank Roles
The following Help Desk roles are covered in this Access Control Policy.
Roles Where defined Authentication Resource access controls
needed
Help Desk IIn local NT system I NT password log- I NT logon gives access to
Advisor (with user profile) I on initially: on-line documentation
and at PAS/CMS Oracle password I Oracle role gives access to
system as Oracle log-on for access to_ I specified data view
Forms user PAS/CMS
Help Desk As Help Desk As Help Desk NT group gives access to
Supervisor I Advisor Advisor further local facilities
and Manager
Help Desk [In local NT system I As Help Desk NT user information
Security AtPAS/CMS, Oracle I Advisor, but using _ I Oracle user information
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 68 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Roles Where defined Authentication Resource access controls
needed
Manager Forms user with different Oracle for Help Desk Roles only
privilege to add users I username and
password.
NT System I NT system only NT password log- _ I Access to most NT
Administrator on information
Engineers Not known in system I NT password logon I Access to most NT
under supervision _I information
7.3.5 Other Access Controls
Contact is made with the Help Desk Advisors from Counter clerks, the
Benefit Agency and customers by phone as detailed in the Help Desk Call
Enquiry Matrix [HDM]. 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.
Contact
Customers
Function How authenticated
Queries and reports
about cards, PUNs. e.g.
card lost or damaged.
Response to a number of verification
questions asked by the Help Desk
Operator as specified in [SADD].
Members I Reports such as found No caller individual authentication
of the card normally (as the caller may not be
public known to the system). However, the
caller may be asked further
verification questions depending on
the type of call.
Staff at Get payment details and I See section 3.6.2.
Post Office I extended verification e.g.
for foreign encashment.
Reporting on failures &
anomalies
PO staff on
behalf of
See section 3.6.2 for verification of
Post Office staff plus customer
Queries and reports
about cards etc
customer verification information.
DSS/BA Enquiries on cards, See section 3.6.2. plus extra
payments. Request to verification; details dependent on if
stop cards, payments etc _ I Nationally Sensitive /ebs/
BA for As customer queries and I See above for verification of BA staff,
customers_I reports plus customer verification info
Printed: [ DATE \l]
C
y Documents\ACPV.1.doc
RESTRICTED-COMMERCIAL
Page 69 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
8. OFFICE PLATFORM SERVICE DOMAIN
8.4 Introduction
The Office Platform Service Domain is illustrated in figure 8-1.
Correspondence servers
at Pathway central sites Remote
System
t Management
Counter I. Auditors and
— Infrastructure Emergency Manager
Customer (Riposte
journals etc)
P l f--~ Support Engineer
PAS/CMS @, Ofte Applications
Help desk ce APS,EPOSS
staff OBCS, BES Installation
Hori Engineer
orizon % On-line
System OR documentation
Help desk
Figure 8 - 1 Interactions in the Office Platform Service Domain
Information about BA payments and cards and also about APS, EPOSS
and OBCS is distributed using the Riposte Transaction Management
System which includes the Riposte journals at the Post Office.
Customers pick up Benefits cards and use these to prove their identity
when receive payments or use the existing style of Order Books and
Girocheques to get payments. They may also use other Post Office
services such as Automated Payments and purchase many types of items.
Counter clerks handle these transactions using the applications at the
counter. In exceptional circumstances, they may ring up the PAS/CMS
Help Desk, 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: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 70 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
8.2
Post Office Systems are monitored and managed via the Pathway System
Management Services using Tivoli. This is used to distribute software and
also Tivoli 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.
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 subpostmaster 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.
e Supervisors who can perform all Counter Clerk functions and may
also do other functions such as view stocks.
The Post Office Manager acts as the Security Manager at the Post Office
(rather than this being a separate role as in other domains); in many Post
Offices, there are insufficient people to justify a separation role for this.
Customers are also recognised at the Post Office, though they do not
access the system directly, so do not have a role in the system.
POCL Auditors have access to Post Office services. The normal POCL
Auditor will have read only access to the system. One of the Auditors
may take the role of an Emergency Manager who may take over from the
Manager after suspected fraud or when a Post Office is closed down or
transferred to a different Manager.
Pathway staff such as Security 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 71 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Role Main classes of functions
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 I 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 PAS/CMS Help Desk 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 I (counter clerk also uses special training benefits/APS
cards so does not need a customer present)
Installation Rollout of new Post Offices including setting up Post
engineer (Exel) I Office personality.
Support Replacing peripherals etc and running diagnostics to
engineer check functioning correctly.
(DSD) 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
Manager functions including user administration.
8.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 8-2.
ISDN (or other) Link
a om a
= i a
NT workstations
Figure 8-2 Post Office Configuration
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 72 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
In some cases, the ISDN link is replaced by a different form of link, but
this does not affect the Access Control Policy.
In a single counter Post Office, the link is to the only workstation, which
may be at the Post Office site or may be portable. In a multi-counter Post
Office, not all workstations need have all the same peripherals, so some
transactions can only be done at certain counters.
The link to the Pathway campus will be 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 I By installation engineer using auto-
Office rollout configurer application on rollout (using
Tivoli and Riposte).
Key distribution from KMS I 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
Tivoli including software protocols. Scripts and software are signed
distribution for integrity protection.
8.4 System Delivery
As the result of Factory installation, Post Office workstations have NT,
Riposte, applications and file encryption software installed. However,
there is no specific information or code for a particular Post office.
Personalisation information will be 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 role 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: [ DATE \l] RESTRICTED-COMMERCIAL
C y Documents\ACPV.1.doc Page 73 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
8.5
8.6
Usernames will be set up in Riposte and NT for an Engineer, an
Emergency Manager, a Support user and for a number of Auditors
(enough to allow an auditor at each counter of the largest Post Office).
There will also be a special Set-up Manager user used during Post Office
installation - see 8.6. These users will be 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-configurer one (see 10.6). It is not possible to log-on to NT or
Riposte at this stage.
System Installation
The Auto-configurer application is run by the installation engineer on the
gateway workstation. It 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 normally
printed) 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 ai 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 74 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
8.7 System Access Controls associated with Human Roles
As for all domains, system access controls conform to the policies in
section 3.5.2. The following specialisations of the general policies apply
at this domain.
e Passwords will expire in 6 months, rather than 1 month (see 3.5.2.8).
e A password cannot be re-used for 18 months.
e The password is checked to conform to quality standards as follows:
© passwords cannot contain spaces
e 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 will be 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 8.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. I Not in Manual ‘Auto-configurer
Engineer I Office system procedures (see _I application only
note 1)
Post Office I Post Office Not in Manual Memory Card
Manager installation system procedures and set up
application only
(see notes 2-4)
Normal Riposte user; I Riposte username I Relevant Riposte
Manager in Manager I and password (see I applications only
functions and I group note 5)
key changes
Emergency I Riposte user I Riposte username I All Riposte
procedures I in Support I and one-time Manager
(see note 5) group password functions
Counter ‘All functions I Riposte user; I Riposte username I Relevant Riposte
clerks and member of — I and password applications only
Supervisors relevant
group
training mode I Not no separate log-on I Relevant Riposte
separately from live applications with
defined application use__I training data
All Workstation _I Not in Memory Card Workstation start
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
Cc
Ay Documents\ACPV. 1.doc Page 75 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Role Function Where users} Authentication Resource access
defined needed controls
permitted I start up system and PIN (see up only
PO roles notes 2-4)
Engineer I running Riposte user I generic Engineer _ I Relevant Riposte
diagnostics Riposte username I diagnostic
& one shot application only.
installing new password (see Auto-configurer
hardware note 6) application
Auditors All functions I Riposte user I generic Riposte Relevant Riposte
Auditor username I applications only
with one time
password (see
note 6)
Emergency I Workstation I not in system I Memory card and I Start up
Manager _I start up PIN (see note 7) __I application only
other Riposte One time Riposte
functions generic user__I password applications only
Notes:
1. The installation engineer will have an Id card with a photograph and
signature and the Post Office will have been informed of his visit.
2. 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 10.6
3. The Post Office Manager is expected to lock away the Memory Card
and PIN for it in separate places.
4. If the Manager looses his card or PIN, emergency recovery
procedures require the Manager to get an emergency recovery key
from the Horizon System Help Desk.
5. If the 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.
6. 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 lo;
7. 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.
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 cal] any other applications or NT or Windows functions.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 76 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
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.]
All Riposte transactions, including user administration, are logged in the
Riposte journals. On adding a new user, a full name must be supplied.
8.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 also be contacted by the Horizon System Help Desk
or Implementation Help Desk about technical or logistics issues. In this
case, but no verification is needed in this
Post Office staff may contact Pathway Help Desks and will need to
authenticate to them as defined in the section 7.3.5 (for the PAS/CMS
Help Desk) and in 10.2.4 (for the Horizon System Help Desk).
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 77 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
9.4 Introduction
The De La Rue Card Services Domain is illustrated in figure 9-1.
De La Rue , Pathway
I boundary
' Pathway PC
De La Rue Systems ' decrypting files
1 transferred
I , I I
De La Rue Netware Lan
ISDN Router}
De la Rue site
: fr the
' ISDN Router) 07"
I I Data
PC for Dela Rue link I ©"
: encrypting files
\
t
‘Pathway Data Centre
'
CMS
Figure 9-1 De La Rue Card Services Domain
Files of data for magnetic card 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 the Security Functional Specification. They are made
available to the De La Rue system using NetWare file access. Information
is returned to Pathway in the same way.
The PC is expected to be managed using Tivoli system management from
the Data Centres. The router is managed using Network Management
from the Data Centres as described in 10.4.
De La Rue operations take place in a secure site. De La Rue information
system controls and staff procedures protect the information on the De
La Rue systems.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 78 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
9.2 Roles
The only Pathway roles supported at the PC
e The Key Custodian installing and maintaining the Red Pike keys. For
details of access controls associated with this role, see 6.9.3.
e An engineer installing or replacing the PC. This PC is not re-
configured when linked to the Data Centres.
er
9.3 Control of Connections to the Pathway Data Centres
Only the following traffic will be permitted to/from the Pathway Data
Centres:
Service Type of Access Controls at Data Centre
CMS Automatic file transfer via the I At PC: file transfer from
PC at Pathway Data Centre CMS only permitted
At router: IP traffic for
file transfer from DC PC
System Tivoli actions for the PC at the I At router: Tivoli IP traffic
Management I De La Rue site from event management
(Tivoli) System management events and software distribution
reported from this PC to Tivoli I servers permitted
Network actions for the router from At router: IP traffic for
Management I Open View at the Data Centre I network management
(Open View) from Open View server
permitted
The ISDN router at the Data Centre allows no other traffic to the De La
Rue sites from the Data Centre. The Pathway router at the De La Rue
site only accepts the above traffic from the Data Centre ISDN routers.
The PC at the De La Rue site will also restrict traffic to this.
9.4 Control of Connections to De La Rue Systems
All traffic from the De La Rue LAN is IPX - no IP traffic from this LAN
will be permitted. Access will be permitted only from know IPX
addresses on the De La Rue LAN.
Controls at the PC will ensure only read access from De La Rue via
NetWare to incoming files from Pathway and ensure filestore separation
from files for output back to Pathway.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 79 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
SYSTEM MANAGEMENT SERVICE DOMAIN
Introduction
10.
10.1
The System Management Service Domain is illustrated in figure 10-1.
Horizon System
PO counters Help Desk 7 ie Engineers
CFM &— & ae gineers
ete af
“ ie System Management Centre
1 - most software & operational problems
¢$ SMC—> s8C ete
Tivoli (mainly NT)
Software Distribution
Software Inventory
Event Management
Resource Management
Config’n Management
network
management
system/
E eB
HP OPENview
5 E E & Cisco Works
operational R Ss on Solaris
management S R
Maestro Routers
job scheduling
Sequent Machin NT Systems NT
running Correspondence Post Office
PAS/CMS, MIS ete Servers ete counters
Figure 10 - 1 System Management Service Domain
In the figure,
e E- shows event management - Tivoli manages events either directly
(as with the Correspondence servers and Post Office counters) or
indirectly (via Patrol at the UNIX systems)
¢ R - shows resource management such as performance and capacity
monitoring (for Sequent, inventory management)
¢ § - shows software distribution
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 80 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
The Tivoli Management Environment (TME) is used to provide 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 all other NT boxes at the
Pathway Campus, including Entropy Servers and Key management
Service. 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.
Management actions may be initiated by:
e System management software detecting threshold conditions and
automatically taking remedial action:
e SMC System Management staff initiating software distribution or
other action via Tivoli scripts.
e Technical Help Desks receiving all technical calls and fronting and
managing the handling of these calls
e CFM Staff doing operational management via Patrol (for
event/resource management), Maestro (for job scheduling), Oracle
Database Administrator functions for Oracle database problems,
UNIX or NT directly where needed.
The Technical Help Desks are supported by an existing Sorbus system
(Powerhelp) for recording calls and later monitoring them.
This System Management section covers the following:
¢ Access control at the Horizon System Help Desk and in the Tivoli
System Management system including at SMC management
workstations.
e Access control for management associated with the Sequent machines
using Patrol and Maestro consoles
e Access control in network management - both at the HP Open View
workstation and routers.
Rollout of Post Offices affects several other domains so is also included
in this section to the extent that it affects the operational Pathway
systems.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 81 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.2 Technical Help Desks and System Management
The main interactions of people involved in system management using
Tivoli are shown in illustration 10-2.
.. NT workstation
with Pathway applications
(Help Desk versions)
Counter clerks Horizon System
DSS El Desk
CFM ete Workstations for Powerhelp
“~~ & other support systems
(not connected to Data Centres)
SMC ae Desk
NT Workstations with
campus access System Admin
Tivoli client [Engineers
system management etc
SMC on
Tivoli NX Correspondence
system management & other NT servers
exchanges
Tivoli System Management Servers Tivoli
at Pathway Central Sites security
NTTMR servers] [~Sun/NT servers and other
sofiware for ; . . , . admin
distribution Software Event management System
distribution Hardware [~~ Management
Admin of Tivoli & software
users. inventory Engineers
fi
Managed Systems
e.g. Post Offices, correspondence servers
Figure 10-2 Interactions for Tivoli System Management
The Horizon System and SMC Help D. are co-located and distributed
between at least two sites, one of which is at Stevenage. There is also an
SMC unit at Lytham St Annes for Tivoli software support.
These Help Desk staff respond to calls from a variety of sources. 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 82 of 105
ICL Pathway
Access Control Policy
Ref: RS/POL/0003
Version: 1.0
Date: 17/4/97
SMC technicians handle calls passed to them via Powerhelp but also have
acct
s to Pathway operational systems via a second workstation. They
monitor and manage Pathway systems using Tivoli and also administer
Riposte at the Correspondence servers.
The Tivoli System Management servers are at the Pathway Campus.
10.2.4
Horizon System Help Desk, SMC and Related Roles
This Access Control Policy is concerned with access to Pathway
operational and management systems. So the following are not covered
by this document as they require no access to operational systems:
e Use of the Windows 95 workstations by Horizon System Help Desk
staff and SMC for access to Powerhelp, Dispatch-1 etc.
¢ Use by the Help Desk staff of the Pathway applications on the NT
workstations (and associated servers) in support of customer querics.
The following table lists SMC and related roles which are covered by the
Access Control Policy.
Role Functions
Horizon Help Desk Contact on all technical calls, registering
technician them, responding in some cases, and
passing the rest on.
SMC Technician
- Pathway management
(multiple roles)
(SMC)
Monitoring & Management of Pathway
resources under Tivoli control. Sub-roles
separate management functions and
regions to be managed (see 10.2.1.1).
SMC Technician
- Riposte management
Administration of Riposte in any c:
covered by auto-configuration
snot
SMC Technician - Tivoli
Management - multiple
roles (SMC)
Configuring Tivoli including controlling
data import/export, maintaining inventory
of managed systems etc. (see 10.2.1.2)
Tivoli support (SMC,
Lytham)
3rd line support of the Tivoli software
SMC Security Management
Maintenance of user information
- SMC technicians at SMC NT
workstations
- Tivoli users at the Pathway campus
- NT users at NT systems supported by
SMC at the Pathway campus
Pathway Security Auditor
Access to Tivoli notices
Operational management
of Tivoli servers (CFM)
Installing and configuring base software
when this cannot be done by Tivoli.
Printed: [ DATE \l]
C y Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 83 of 105
FUJ00117497
FUJ00117497
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.2.1.1
10.2.1.2
10.2.2
Pathway System Management using Tivoli is split between different
people with responsibility for different functions, and in some cases, for
these functions only in particular Tivoli regions. This division
responsibility should be in line with the Access Control Policy to provide
separation of duties etc as defined in section 3.
The number of roles which can activate unplanned changes to the system
should be very limited. Such actions should very rarely be needed and
require some separate authorisation. Expected roles include:
e System monitoring of events resources with no update rights.
e System monitoring and confirming action suggested by the system.
e Distributing authorised software, Tivoli scripts etc in line with the
planned schedule for activation at a planned time.
e Taking unprompted and unplanned actions as the result of serious
problems. In all cases, this should only use authorised Tivoli scripts.
In most cases, there should be authorised scripts to handle expected
emergencies. Where this is not the case, any new script produced must
be authorised according to SMC procedures prior to distribution and
use.
e Authorising a new Tivoli script or software patch for release. This will
only be done by a senior SMC technician.
Management of Tivoli will control:
e The inventory of managed systems
e Configuration information about thresholds to activate alerts, what
audit information to generate etc
¢ Configuration of bulletin boards of notices and who can access them
¢ Source of data to update Tivoli server information about hardware,
software, auto-configuration of Post Offices etc
System Access Controls for these Roles
All these Help Desk and SMC staff are authenticated to the local NT
system using a password. Those with access to the Data Centres also use
a token. This results in display of a desktop which contains only those
applications available to this user.
SMC technicians also authenticate to the appropriate Pathway
Operational system.
The residual operational management of Tivoli servers is done by CFM
as for other servers at the Data Centre, as specified in section 6, so is not
included in the following table.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 84 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Role Workstation Where user defined I Resources
type and and Authentication I available
location needed
Horizon Help W95 and NI Local systems only I Call monitoring
Desk Technician I in DSD area etc on W9S;
Pathway related
services on NT
SMC technician - I NT - SMC Local NT system, resources
Pathway secure area Tivoli user with required for that
management (Stevenage or I appropriate role, role and region
(multiple roles Footscray) regions, ACE server
see 10.2.1.1) at Data Centre for
token
authentication.
SMC technician - I as above Local NT user, NT I Appropriate
Riposte Data Centre user _I Riposte
management and ACE server for I management
token utilities
Tivoli as above as SMG technician I Appropriate
management for Pathway ‘Tivoli functions
management above
Tivoli support I NI as SMC technician I All Tivoli
workstation, above functions
Lytham St
Annes
SMC Security NT at SMC as SMC technician I Tivoli user
management secure site above admin
Pathway Security I NT Tivoli, NT user at I Access to audit
Auditor workstation, other management I logs
secure area, system.
Feltham
Note: Use of token authentication have still to be agreed - see 6.9.2.
Note: Procedures for Help Desk handling of one-time passwords in response to calls from the
Post office are being defined, as are those for key recovery
Tivoli roles, management regions and policy regions are used to split
system management functions as described in 10.2.1.1 above.
Tivoli roles will also be used to control who can manage/configure
which Tivoli functions and resources (see 10.2.1.2). A separate role
should be used for the Auditor who can set the amount of auditing and
analyse and manage the audit log/bulletin boards.
Printed: [ DATE \l]
C:\My Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 85 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.2.3 Controls on Connections
The NT workstations which are used by SMC technicians for managing
the operational Pathway system will be on a separate LAN from other
workstations at the SMC sites and only these will have access to the
Pathway Data Centres.
The links between the SMC sites and the Pathway Campuses are
encrypted, so all traffic is confidentiality and integrity protected. (Tivoli
integrity features will also be used).
All software, Tivoli scripts, configuration files etc sent by Tivoli to the
Post Offices will be signed for integrity.
10.2.4 Other Access Controls
The Horizon System Help Desk receives calls on technical issues from:
e Post Office staff with a technical problem
e DSS via the ITSA Service Help Desk
e POCL offices
e Other Pathway sites
In many cases, some form of authentication is needed, as described in
section 3.6.2 above.
In outline, authentication of these contacts is as follows:
Contact Function How authenticated
Post Office staff Reporting technical as section 3.6.2 to
problems identify the outlet
Post Office
Key recovery, resetting
as above, plus
Manager at Post
Offices
log-on; emergency key
recovery
Manager Manager’s password identification of Manager
Engineer, Auditor, I Use of one-time As 3.6.2 plus at least pass
Emergency password as part of number checked
(see note 2)
problems e.g. with
CAPS, CAS
Other Pathway Reporting technical As 3.6.2
sites problems
POCL other sites _I Reporting incidents As 3.6.2
DSS Reporting software As 3.6.2
Notes:
1. CLI is used where possible
2. The Help Desk has a record of pass numbers of engineers and POCL
auditors, including those who can be Emergency Managers
Printed: [ DATE \l]
C:\My Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 86 of 105
ICL Pathway
Access Control Policy
Ref:
Version:
Date:
FUJ00117497
FUJ00117497
RS/POL/0003
1.0
17/4/97
10.3
Sequent and Oracle Management
The components involved in the management of the Sequent systems at
the Pathway Central sites are illustrated in figure 10-3.
UNIX and
Oracle
Tivoli
Event Management ete
Events
Management aw
Security Management
Engineers
etc
Seayfent Machines
Patrol with Tivol
Event Adapter
Maestro
job scheduling
Job
scheduling
initiating
jobs at
Agents
10.3.1
I I
PAS, CMS, MIS ete
on Oracle databases
Figure 10-3
Patrol is used for system management of both Dynix and Oracle. (It is
expected to be used for all Oracle database administrator functions.) A
Patrol knowledge module in the Pathway partition on DSS VME
machines adds VME system management events allowing them to be
monitored via the same Patrol workstation. Patrol passes on relevant
events to Tivoli. 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 6.2 above is
used only when the automated management and Patrol cannot cope.
Maestro is used for job scheduling 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.
Roles
System management related functions are:
¢ Sequent system/operational management including use of Patrol
e Sequent system monitoring via Patrol
Printed: [ DATE \l]
C:\My Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 87 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
¢ Emergency operational management
e Job scheduling via Maestro
e Job monitoring via Maestro
These roles are all defined in 6.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 6.2 including
Security Management of Dynix and Oracle and Engineers.)
10.3.2 System Access Controls for these Roles
Section 6.2 above defined the controls within the Sequent system.
People carrying out management functions which may update Pathway
systems from the remote will need to be authenticated by token.
If CFM management staff working at home is permitted, the PC will be
configured in a secure environment to ensure it contains only the
required software and to link to ISDN routers which will cause token
authentication. Floppy drives will be disabled.
The links between the and Pathway campus will be encrypted.
10.3.3 Control on Connections
The NT workstations used for this access are on a secure LAN at a secure
CFM site. The links to the Data Centres are encrypted.
10.3.4 Other Access Controls
Call out of CFM staff is done according to CFM procedures which
ensure that the call comes from the required source, so should be acted
on. Associated procedures ensure the ISDN port is enabled to allow the
authorised access to the system. This utilises Powerhelp.
10.4 Network Management
10.4.4 Introduction
The Pathway network routers are managed using HP Open View with
Cisco Works as illustrated in figure 10-4 below.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 88 of 105
ICL Pathway
Access Control Policy
FUJ00117497
FUJ00117497
Ref: RS/POL/0003
Version: 1.0
Date: 17/4/97
Data feeds e.g.
PO addresses &
keys on rollout
Events to Tivoli
Lay
Data outputs
e.g. audit logs
Network Sun, UNIX Application
Manager Support
Network HP Open View Security Manager
Technician ~~
System
Network Cisco Works Administration
Management ..... a
Configurer Engineer
Mafaged Routrsys
ISDN Cisco Access WAN Routers
Routers Servers routers at DSS ete
ISDN Adapter] PSTN connected Girobank DSS, POCL
at Post Office} Post Offices Help Desks & De La Rue
ete systems
Figure 10-4 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
actions at the routers.
for monitoring - Tivoli is not used to cause management
Audit logs are generated during normal running and provided to the
audit service.
On new Post Office rollout, 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:
Printed: [ DATE \l]
C:\My Documents\ACPV. 1.doc
RESTRICTED-COMMERCIAL
Page 89 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
e Network Manager responsible for configuration and management of
the routers
e Network Technician monitoring the routers
e 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.
There is a single Network Management station at each Pathway Data
Centre. At any one time, the Network Manager role is available at only
one of these, with the other being used by a Network Technician for
monitoring.
10.4.2 Roles at the Open View System
The following table lists the roles of people with direct access to the
system.
Role (Organisation) I Functions
Network Manager I Monitoring the network.
(CFM) Updating router configuration information when
required e.g.
- Post Office information e.g. ISDN addresses
-A Lists of permitted addresses, protocols, ports.
Updating information about routers available when
needed (including confirming bringing a mended one
back on line - see 10.4.4 below)
Network Monitoring the network
Technician (CFM)
Network Configuring Open View
Management - what to display to whom
Configurer (CFM) - actions to be taken on certain events
ete.
Configuring Tivoli Event Adapter
Security Manager Maintain user information for those users permitted to
(CFM) use 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
Administration using the Open View, or Cisco Works
(CFM) This is expected to include operating system set up,
changes; software updates.
Engineers (DSD) Diagnosing, repairing hardware faults
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 90 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.4.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. There are no remote users allowed on
this system. The following table shows how the users defined above
access the system and what is available to them.
Role Authentication Resources available
method & where
user defined
Network UNIX & Open Open View and Cisco Works
Manager View as individual network management functions
user (no direct UNIX access)
Network as above Specified Open View and Cisco
Technician Works functions onl:
Network as above Open View configurer functions
Management
Configurer
Security Manager _I as above User information and audit trails
System UNIX after system I All UNIX facilities
Administration taken out of
network
Engineer UNIX via special UNIX facilities and data required
sword c.f, to diagnose fault
Sequent 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.
2. All users (except possibly engineers) are individually identified to the
system and logon under individual user names.
3. Engineers identify themselves at the secure site and have supervised
accessed to the system - see 3.6.3.
10.4.4 Access to Routers
Pathway routers are controlled from the Network Management Service
described above. No other remote management of the routers will be
done.
The routers will not normally have consoles, though console access will
be enabled for cases where a router fault is detected. Any attempt to use
console access will be flagged via Open View.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C y Documents\ACPV.1.doc Page 91 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
If a router has a fault, it will be configured out of the network and then a
console will be physically taken to the router and plugged in. The router
engineer can then log onto the router to diagnose and repair the fault.
The router is then connected back into the system. The configuration of
the router is checked and the Network Manager asked to confirm
acceptance before the router is configured for normal use as part of the
operational system.
The password used for direct console access is changed via Open View
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.
10.4.5 Access controls configured in Routers
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.
10.5 Network Access Controls
10.5.4 Introduction
The following diagram is a simplification of the network at a Pathway
Data Centre showing the links into and out of it.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 92 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
“DSS Sites
Pathway Data Centre
I I POCL
Sequent Systems wan E-—~I (TIP ete)
4 ° LJ Routers -——Lother
a Data Centre
t F F F t F [+ Girobank
PCs for I com] TMS II [Security] I [tivor] I] Ppen er I Help Desk
SDN ’kqJ IServersL] I Agents LI fe.g. KMSLI IServersL} } I Servers
LAN
switch CFM
i r I i
SMC
Routers] I IISDN Routers ISDN Routers Routers & [pr~
for PSTNU forPOs 1 Ifor other links} crypto boxesPRNW. Pathway
(Feltham)
ISDN Support (when via ISDN)
Post Offices /
POCL AP system DeLaRue Royal Mail
Figure 8-5 The Pathway Data Centre Network
Note that the above diagram does not show the Energis backbone, or the
duplication of connections within the Data Centre for resilience as these
do not affect the access control policy.
There are the following connections into a Data Centre:
e High speed WAN links, e.g. from CAPS, coming into the router
which is linked to the Sequent machine (Bootle) or machines (Wigan)
¢ Post Offices connected via ISDN to ISDN Routers or via PSTN to
other routers
e Other ISDN connections such as to the POCL system at Farnborough
which handles Automated Payments coming into other ISDN routers
e = The links from Pathway sites used to manage and support the
operational and management systems.
Traffic into and out of the Pathway Data Centres is mainly controlled by
access lists in the routers. 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.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C y Documents\ACPV.1.doc Page 93 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.5.2 High Speed WAN links
The following systems connect into the Pathway Data Centres by high
speed WAN links:
¢ The DSS CAPS and ESNS sites
e The POCL TIP and Reference Data systems
e The Girobank Help Desks at the campus
¢ The other Data Centre
All these links come into a pair of routers which do not accept traffic
from any other source outside the Data Centre.
At the Bootle site, where there is no Data Warehouse or MIS machine,
all traffic to and from these connections goes to the one operational
Sequent system.
The type of traffic permitted to/from the DSS and POCL systems are
controlled by firewalls at the DSS and POCL sites (see sections 4 and 5).
The Girobank Help Desk uses only Oracle Forms a s to Sequent (se
7 above). The Help Desk workstations are set up to use only this access
to the Data Centres and the Sequent systems to accept only this.
10.5.3 Post Office Connections
Post Office are normally connected via ISDN, though some are
connected via PSTN or GSM.
A set of routers handle all ISDN traffic from Post Offices and accept
traffic from outside the Data Centres only from those. Further routers
are configured to handle traffic from PSTN connected Post Offices.
The routers handling Post Office traffic also restrict where traffic can be
routed to/from within the Data Centre. Permitted addresses are for those
services listed in 8.3 i.e. the Correspondence Servers, Tivoli management
servers and KMS.
10.5.4 Other ISDN Connections
AIl ISDN access to the Data Centres is protected by routers which only
permit traffic to/from agreed sources. Apart from the Post Offices, ISDN
connections are permitted with the following systems:
e The POCL site at Farnborough handling automated payments (and in
future other POCL clients)
¢ De La Rue sites
¢ The Royal Mail (Wigan only, post release 1)
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 94 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.5.5
e In some circumstances, certain support organisations such as Sequent
and Oracle
The POCL, De La Rue and Royal Mail ISDN links go to a different set of
ISDN routers than those used for the Post Offices. These only permit
traffic from outside the Data Centres from these addresses. Each of these
links have associated PCs at the Data Centre to handle traffic on that
link. The routers restrict traffic from these links to the appropriate PCs.
Traffic is restricted to file transfer and Tivoli management - see sections
Sand 9.
As for the DSS and other POCL sites, the type of traffic permitted
to/from the POCL, De La Rue and Royal Mail systems are controlled by
firewalls at the remote site (see sections 4 and S$).
In exceptional circumstances, support of Dynix and Oracle on Sequent
machines may be required from Sequent and Oracle. Remote access will
only be permitted after a call from the Operational Management of that
machine confirms the need for access and tells the Network Management
staff to configure the appropriate router to permit that ac In this
case, the router will be configured to restrict access to the Data Centre to
the particular Sequent system needing supporting.
All traffic over these ISDN links is protected at the application level as
defined in the Security Functional Specification.
Links from ICL Pathway related Sites
A number of ICL sites need access to the Data Centres as follows:
e The CFM sites at Belfast and Stevenage
e SMC sites at Stevenage, Footscray and Lytham.
e The Pathway management site at Feltham which is also used for
Configuration Management, rollout, some support and FRM.
All these links are low speed ones and encrypted (using cryptographic
boxes) and linked into a particular set of routers.
These routers only permit traffic from/to these locations. At CFM and
SMC sites, the workstations used are not connected to any external
network so do not need firewalls. Traffic to/from these sites is as
described in 6.2, 10.2 and 10.3 above.
The Feltham site has links to a number of sites as it accepts some
software and rollout information from other parts of ICL and other
organisations. The network is shown in the following diagram.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 95 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
ICL Corporate
Network > Feltham Network
Firewalls with management users, rollout db,
{I _—} P SSC support and other users,
ISDN etc links 7]
Firewall
Security/Audit & FRM users
{I II
Configuration
Management
Router
Crypto box
Pathway Feltham site
To crypto box at Data Centre
Figure 10-6 Feltham Network
The connections between Feltham and the Data Centres are:
e Pathway Fraud Risk Management staff and Security Auditors from a
secure LAN in a physically secure area
e Distribution of signed software and Tivoli scripts from the
Configuration Management system
e Supporting rollout including transfer of Post Office information
between the rollout database and Data Centre
¢ Management users accessing management data
e SSC application support
The Feltham router will permit traffic from the FRM users and CM
system and also the firewall to the Data Centre.
The main Feltham network is protected from the ICL Corporate network
and ISDN lines from which rollout information is received by firewalls.
A further firewall protects the Data Centre from the Feltham network
(and translates the IP addresses to Pathway addresses). This firewall
restricts traffic to the Data Centre to only those workstations and servers
with a need to access it and restricts the type of traffic to that permitted.
However, this does not control where at the Data Centres this traffic can
go this is done by routers at the Data Centres.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 96 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.5.6 Network Access Controls within the Data Centres
Other sections of this document identify what connections are allowed at
the various systems in the Pathway Network to allow both the automated
processing of the business applications and also management and other
Some of these controls are enforced by the routers, some by
controls at the particular systems.
acces
The routers controlling the links from CFM, SMC and Pathway project
staff at Feltham will be configured to have the following controls
e CFM from Belfast can only access the systems they manage
e SMC can access Tivoli servers and NT boxes managed by them (see
6.3)
e SSC application support users at Feltham are restricted to the systems
they support
e Management users are restricted to the Data Warehouse and MIS
systems at Wigan
e Configuration management traffi
appropriate Tivoli server
is only permitted to the
Controls of use of ports at particular systems are generally specified as
part of the particular system. In outline:
¢ Correspondence server access is limited to the TMS agents, and
routers handling traffic from the Post Offices (apart from
management and support acc $s).
e TMS Agents only allow traffic to/from Correspondence servers and
the appropriate Sequent system(s), except the BES agents which also
have links with the Entropy servers (apart from management and
support access).
e Security servers control connections to restrict access to the minimum
required, though note that this will include routers linking to the Post
Offices.
e PCs handling links with outside systems will restrict traffic to only
those types of applications permitted on the specific ports from the
specified addresses.
e Tivoli servers allow different connections depending on the function
¢ Open View servers allow no outside access and permit links only to
the routers.
e The Sequent operational system permits only those connections listed
in sections 6 and 7 e.g. CAPS, ESNS, TMS agents, PAS/CMS Help
Desk, operational management.
e The Sequent Data Warehouse and MIS systems permit access to
management users, but only FRM staff (and in exceptional
circumstances application support staff) are permitted to access the
Fraud Management Service.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 97 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.6 Roll-out
This Access Policy is concerned only with those parts of the Rollout
mechanisms which affect the operational system. This is illustrated in
figure 10-7.
Horizon System
Help Desk ENG
Implementation Auto
Help Desk & — ¢ configurer
manager
I I
POand Fo j
other info ——: Rollout database ' Correspondence
en Po Servers
Autoconfiguration db and I .
Configuration Management > Open View
a I for Routers
Tivoli S
PO config info & installed
software updates config KMS exchanges
PC with Post Wffice v
PO Sotare sell Sit I__ K
— isi i Auto-configurer
Factory Intallation Engineer
Post Office Manager
Figure 10-7 Interactions on Roll-out
The information needed to implement roll-out of Post Offices is
managed in the Roll-out database which takes input from POCL and
other sources.
Information about Post Offices to be installed soon is transferred to the
Pathway Auto-configuration database. A member of the Implementation
Operations Unit in Pathway initiates the Auto configurer 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 signed by the Configuration
Management system and sent to Tivoli to distribute as for all Tivoli
script and software updates to the Post offices.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 98 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
10.6.4
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, any changes needed to the
software are sent to the Post Office and the details of the installed
configuration returned to Tivoli. When the Post Office Manager takes
over and first boots up the Post office, the keys for standard running are
delivered from the KMS.
Roles
There are two Implementation Operations Unit roles to support Rollout:
e Implementation Help Desk technician
e Auto-configuration Manager
The Horizon System Help Desk forwards relevant calls to the
Implementation Help Desk. The technicians there will handle the call,
communicating with Pathway suppliers. The Rollout database may be
used both to respond to queries for information and to update it, for
example, if an installation date must be changed
The Auto-configuration Manager controls the auto-configuration
process. This may be split, so updates to Correspondence servers and
routers etc are done at different times from generating the Post Office
configuration file.
As the Rollout database and Configuration Management system are
internal Pathway Services at Feltham, this Access Control Policy does not
define the access controls for these roles.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 99 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
11.
114.4
11.2
PATHWAY CORPORATE SERVICE DOMAIN
Introduction
The Pathway Corporate Services Domain supports:
e Management processes using Management Information Systems.
e Security processes including Fraud and Risk Management and
Security Auditing.
The Management Information Systems (MIS)
There are two Sequent platforms at the Data Centre at Wigan supporting
Management Information Services. The Data Warehouse is the main
information repository for all Pathway corporate systems. A second MIS
platform supports an EIS and Financials service utilising information
from the Data Warehouse. Both systems are managed in the same way,
so have similar access controls.
These MIS and Fraud Risk Management services are illustrated in figure
11-1.
TMS PASICMS Reference Call info from
journal Data data help desks
MIS Services
on Sequent
ete
I nnn Security
Accounting System A
Pathway 8 SY: Management
Management
Asset management
System and
Operational
Management
& Engineers
Pathway Ad Hoc Queries
Fraud Risk coool
Management
Fraud Risk
Management Service
Application
Pathway Support
Auditors EIS/Financials
service
Figure 11-1 MIS Systems at Wigan
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 100 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
11.2.1
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
e Business development applications providing aggregates and
summaries to identify sales trends and customer habits
e Accounting and Asset management
Data is fed automatically from other Pathway systems to the Data
Warchouse including:
Data from TMS journals about Post Office transactions (see 6.8).
Data from the Reference Data Management System (see 6.7)
PAS/CMS data (see 7.2)
Information on calls to the PAS/CMS Help Desk. This consists of
Rockwell ACD data (see 7.3) and Mercury data
e Information on calls to the Horizon System Help Desk. This consists
of Mitel ACD and BT data
Much of the output of this system is from the particular services. These
provide the management information required by Pathway and the
outputs required by DSS and POCL. There are automatic feeds from
Data Warehouse Services to the ElS/Financial service.
All business access to the EIS/Financials service it is by Pathway
Management users in Feltham using SQL*Net.
Roles
The roles specific to these MIS systems are:
e Pathway Management staff at Feltham running the various
management services.
Some of the data these people handle is commercially sensitive for
Pathway (e.g. financial information). Other data may be sensitive for
DSS and/or POCL.
e Pathway Security Auditors
e Pathway Fraud Risk Management staff responsible for identifying and
managing fraud (Data Warehouse only)
Both systems are managed in a similar way to the other Sequent systems
at the Pathway Data Centres. Therefore people in the following roles
defined in 6.2 are also supported here.
e Computer operator (CFM)
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc
Page 101 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Operational Management (CFM)
Security Management (CFM)
Oracle 3rd line support (Oracle)
Dynix 3rd line support (Sequent)
Engineers (Sorbus)
For a definition of these roles and how they access the system, see 6.2.
Application support is similar to the applications on the operational
Sequent systems i.e. SSC provide 2nd line support for all applications
and the application supplier provides 3rd line support. In this cases, this
is:
e Oracle for all Oracle applications
e CFM for Business Object applications used to support queries on the
data
11.2.2 System Access Controls
System access controls will conform to the policies in 3.5.2. For example,
all users are individually authenticated and their access to the system is
limited on a need-to-know bas
Database roles with appropriate database views will be used to separate
what data is available for what use. Information available to people doing
ad-hoc queries will be further constrained using the Business Object
“universes” to provide restricted views of the Data Warehouse.
These controls will be used to separate data available to different
Pathway management roles.
Fraud Risk Management will have access to individual customer
information relating to fraud as well as benefit related transactions and
data. Because of this, Fraud Risk Management staff will be located in
physically secure areas.
Data Warehouse I Workstation & I Where users Resources
or MIS specific location defined & available
Role authentication
Pathway NT or Windows I Oracle Data relevant for
management (ICL I ‘95 in Feltham specific service
Pathway) (see note 1) only.
FRM (Girobank) I NT at secure Oracle plus FRM database
area in Bootle token
FRM (ICL NT at secure Oracle plus FRM Database
Pathway) area in Feltham _I token
Security Auditing [NT at secure I Dynix + token _I Audit logs
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 102 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
[UCL Pathway) [area in Feltham I I
The Data Centre is protected from these terminals as described in section
10.5 above.
11.2.3 Control of Connections
All access to the Data Warehouse from outside the campuses is by
encrypted links.
Access to the system is constrained to the agreed data feeds, management
applications and output to the EIS/financials system.
11.3 Pathway Fraud Risk Management
Fraud Risk Management is concerned with identification, monitoring
and management of fraud associated with/relevant to the ICL Pathway
system. This is generally done using the Fraud Risk Management Service
described in [FRMS].
There are two groups of Pathway people involved in Fraud Risk
Management:
e Girobank Fraud Risk Management (FRM) staff at Bootle
e ICL Pathway FRM staff at Feltham
Both are small groups and have access to the same information.
Most FRM access to Pathway is to the Fraud Risk Management Service
as described in 11.2 above. In exceptional circumstances, FRM staff may
require access to other Pathway systems in order to investigate a
potential fraud. Access is currently expected to be needed to:
e The PAS and CMS data
e The TMS journal of Post Office activity
e Data transfer logs
Access to PAS, CMS and TMS data is expected to be mainly to the
archives, not the operational system except in exceptional circumstances.
More detail of this access is given in the sections about the systems being
accessed.
FRM staff at Feltham access systems at the Pathway Data Centres from a
secure area via an encrypted link. They authenticate themselves using
tokens.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 103 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
11.4 Security Management and Auditing
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.
Pathway Security Management are responsible for:
e Security Auditing of Pathway
¢ Cryptographic keys used in Pathway
e Responding to requests under the Data Protection Act.
Security Auditing is concerned with auditing all access to the Pathway
systems, including that by Pathway operations and management staff.
Because of this, Pathway Security Auditors will be separate from other
Pathway management roles. The main activity will be a monitoring one,
though on occasions, more active investigations are expected.
Pathway Security Auditors will access audit logs generated at many
Pathway machines. This includes:
e Operational application logs such as the Riposte journal which
records events at Post Offices and the PAS and CMS logs (including
records of PAS/CMS Help Desk transactions)
e Management logs, normally at the Data Warehouse
e System Management audit logs
e Logs recording system level activity such as user logon and
administration (when done by at system level) and other security
relevant events
e Logs at some of Pathway’s internal systems such as Configuration
Management.
However, the Security Auditor will not have access to:
e Post Office systems as all Post Office transactions (including user
administration and authentication as well as business transactions) are
recorded in the TMS journal, or
e The PAS/CMS Help Des s all interactions of the Help Desk
users with the Pathway systems will be recorded in the Oracle logs at
the Sequent machines.
[Note: More detail of audit access will be provided when the Audit design is available. ]
11.4.4 Security Management Roles
People in the following roles are all part of the Pathway Security
Management organisation.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C:\My Documents\ACPV. 1.doc Page 104 of 105
FUJ00117497
FUJ00117497
ICL Pathway Ref: RS/POL/0003
Access Control Policy Version: 1.0
Date: 17/4/97
Role Main Functions
Pathway Security Auditor I Using the audit logs in most Pathway
systems to monitor and analyse use of the
system.
Pathway Security Manager I Responsible for cryptographic keys
(though installing keys is done by the Post
Office Manager at Post offices and by the
cryptographic key Custodian at other
platforms.)
Obtaining the required information in
response to requests for subject
information under the Data Protection
Act.
11.4.2 System Access Controls
The Security Manager and Auditors (and FRM staff) at Feltham access
systems at the Pathway Data Centres from NT workstation in a secure
area on a secure LAN via an encrypted link. They authenticate
themselves using tokens.
Security Auditors can access logs at most Pathway systems as described in
11.4 above and are registered at each system accessed. More information
on their access is given in the appropriate section about the systems being
accessed.
At each system, the Auditor has access only to the audit logs there. Logs
are separated from other information using the facilities of the software
generating/accessing them. For example, operating system logs are in
separate files/directories, Oracle logs are available via separate views.
Printed: [ DATE \l] RESTRICTED-COMMERCIAL
C
y Documents\ACPV.1.doc Page 105 of 105