ICL Pathway
COMPANY IN CONFIDENCE
Security Functional
Ref: RS/FSP/oo1
Version: 4.0
Date: 12/05/99
Document Title:
Document Type:
Abstract:
Status:
Distribut
Author:
Comments to:
Specification
Security Functional Specification
This Security Functional Specification (SFS) defines the
security functionality that will be incorporated into the
operational ICL Pathway system.
ion:
Alan D'Alvarez
Martyn Bennett
Roy Birkinshaw
Graham Chatten
Vince Cochrane
Paul Curley
Peter Dreweatt
John Dicks
Stephen Doyle
Belinda Fairthorne
Bill Hillyard
Jan Holmes
Approved
Peter Jeram
Dave Jones
Graham King
Graham Lloyd
Dick Long
Tan Morrison
Mik Peach
Barry Procter
Martin Riddell
Peter Sewell
Chris Sundt
Chris Wannell
Alan Ward
Steve Warwick
Peter Wiles
John Wright
Pathway Library
DSS/POCL
Ian Stevenson
Colin Oudot
Ruth Holleran
Martin Urch
Horizon Library
Peter J Harrison and Tom Parker
Comments by:
Authors, copy to John Dicks
Printed:
[DATE \I]
COMPANY IN CONFIDENCE
Page 1 of 103
FUJ00088002
FUJ00088002
ICL Pathway
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Date: 12/05/99
(a) DOCUMENT CONTROL
O.4 Document history
Version Date Reason
ou 15/8/96 Initial Draft for internal review
0.2 16/8/96 Incorporates comments from internal review
03 20/9/96 Incorporates comments from CASA
0.4 24/9/96 Incorporates comments from internal review
0.5 10/10/96 Incorporates comments from PDA
1.0 23/10/96 Submitted for formal approval
Ll 4/11/96 Minor changes incorporated
2.0 11/11/96 Approved
2a 25/2/97 Incorporates Energis inter-site link, Data Warehouse,
virus protection, etc
2.2 19/6/97 Incorporates revisions to Security of Links, Message
Protection and Filestore Encryption.
2.3 15/7/97 Incorporates revisions to Audit and Alarms.
2.4 31/7/97 Incorporates revisions following review by PDA.
3.0 3/12/97 Approved
3a 31/7/98 Incorporates VPN changes and updates, mainly to
sections 8 and 9. (CP1248, CP 970, CCN 268)
3.2 5/8/98 Landis and Gyr changes added.
33 11/12/98 Incorporates comments and minor corrections, following
review of version 3.2. Siemens Metering text replaces
Landis and Gyr.
3.4 18/3/99 Incorporates comments from review of version 3.3,
including new sections on Solaris, SecurID and
ACE/Server.
4.0 12/05/99 Approved. Incorporates CP1898 (CCN438) related to
changes in section 5.4.1.4.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 2 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
0.2 Approved authoritiey
Name Position Signature Date
John Bennett
Tony Oppenheim
Terry Austin
Martyn Bennett
Managing Director
Director Commercial &
Finance
Director Development
Quality & Risk Director
John Dicks Customer Requirements
Director
0.3 Associated Documenty
Referenc I Identifier Vers. Date Title
e
SADD CR/FSP/o04 5.0 9/1/98 I System Architecture Design
Document
SECPOL __I RS/POL/oo2 4.0 30/4/99 I ICL Pathway Security Policy
STAT RS/FSP/o03 1 11/12/98 I Statements on Security Objectives
and Methods for the Protection of
Siemens Metering Code and Data
SECOBJ RS/REQ/oo1 1.0 29/10/96 _I ICL Pathway Security Objectives
ACCPOL _I RS/POL/003 3.0 18/12/98 _I ICL Pathway Access Control Policy
AUDPOL I RS/POL/oo05 0.8 19/11/97 __I ICL Pathway Audit Policy
AUDFS CR/FSP/006 24 19/5/97 _I Audit Trail Functional Specification
TED TD/ARC/oo1 43 17/12/98 _I Technical Environment Description
SECPRO __I RS/PRO/o028 0.2 28/9/98 I ICL Pathway Security Procedures
DBA Oracle - - Oracle Server DBA Guide
DYNIX Sequent - - Dynix Operating System - System
Administrator’s Reference Manual
WINNT Microsoft - - Microsoft Windows NT Resource
Guide
ITSEC ITSEC - 28/6/91 _I IT Security Evaluation Criteria
0.4 Abbreviationy
ACC Area Computer Centre
Printed [DATE \I] COMPANY IN CONFIDENCE Page 3 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seourity Functional Version: 4.0
Specificati
Date: 12/05/99
API Application Programming Interface
APS Automated Payment Service
BA Benefits Agency
BES Benefit Encashment Service
BPS Benefit Payment Service
CA Certification Authority
CAPS Customer Accounting and Payments Strategy
CAS CAPS Access Service
CESG Communications-Electronic Security Group
CLI Calling Line Indication
CMS Card Management System
CORBA Common Object Request Broker Architecture
COTS Commercial Off-the-Shelf
CRC Cyclic Redundancy Check
DBA Database Administrator
DLL Dynamic Link Libraries
DLR De La Rue
DSS Department of Social Security
EPOSS Electronic Point Of Sale Service
FRM Fraud Risk Management
GRK Global Roll-out Key
HAPS Host Automated Payments System
ID Identity
ISDN Integrated Services Digital Network
IT Information Technology
ITSEC IT Security Evaluation Criteria
KMS Key Management System
LAN Local Area Network
MIS Management Information Services
NAO National Audit Office
NDIS Network Device Interface Specification
NMS Network Management System
OBCS Order Book Control Service
OLAP On-line Analytical Processing
OLE Object Linking and Embedding
OMG Object Management Group
OPS Office Platform Service
PAS Payment Authorisation Service
PCHL Payment Card Helpline
PFI Private Finance Initiative
PIN Personal Identification Number
PK Public Key (for PK Certificate)
PO Post Office
Printed [DATE \l] COMPANY IN CONFIDENCE Page 4 of 103
ICL Pathway
FUJ00088002
FUJ00088002
Os
0.6
O DOCUMENT CONTROL
COMPANY IN CONFIDENCE
Ref: RS/FSP/oo1
Seourity Functional Version: 4.0
Specificati
Date: 12/05/99
POCL Post Office Counters Ltd
POM Post Office Manager
PPD Processes and Procedures Description
PSI POCL Service Infrastructure
PUN Pick Up Notice
RPC Remote Procedure Call
RCD Release Contents Description
SADD System Architecture Design Document
SFS Security Functional Specification
SHA Secure Hashing Algorithm
SIS Strategic Infrastructure Service
SM System Management’
SMS System Management Service
SNMP Simple Network Management Protocol
TACACS Terminal Access Controller Access Control System
SQL Structured Query Language
SSC System Support Centre
TFTP Trivial File Transfer Protocol
TIP Transaction Information Processing
TME Tivoli Management Environment
TMP Tivoli Management Platform
TMS Transaction Management Service
UDP. User Datagram Protocol
VME Virtual Machine Environment
VPN Virtual Private Network
Changes Forecast
The dedicated FRMS ISDN link is subject to a Change Proposal and will
be incorporated when this has been formally agreed.
Table Of Contenty
OL Document history...
0.2
O53
* To avoid confusion Siemens Metering is not abbreviated within this document.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 5 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
1.
12
1.2
1.3
1.4 ICL Pathway’y Security Policy...
Ls
24
22
23
2.4
25
2.6
2.7
2.8
2.9
2.10
3. SECURITY DOMAINS
BL Domain DFU OW rrrresssserssneesssene
3.2 The DSS Service Environment Domain...
3.3 The PAS/CMS Service Domain...
3.4 The POCL Central Services Domain...
3.5 The Office Platform Service Domain.
3.6 Dela Rue Card Services Domaiw....
3.7 POCL and POCL Clienty Domain...
3.8 System Management Service Domain.
Printed [DATE \1] COMPANY IN CONFIDENCE Page 6 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
3.9 ICL Pathway Corporate Servicey Domain
4. SECURITY COMPONENTS.
4.1 Security Enforcing Components...
4.2 Operating System Security Functionality
4.2.1 Windews NT Security Functionality
4.2.2 Dyniw Operating Systenn....
4.2.3 Solariy Operating System.......
4.3 Database Management Sytem
4.4 SeeurlD Tokens ano ACE/Server
4.5 Network Security,
4.5.14 Fiurewally,
4.5.2 Routers...
4.5.3
4.5.4
4.5.5
4.6
4.6.1
4.6.2
4.6.3
4.6.4
4.6.5
4.6.6
4.6.7
4.7.2 Threat of Virvy Infection,
4.7.2 Viruy Protect Measurey.
S. IDENTIFICATION AND AUTHENTICATION
SL Identification and Authentication Requirementy...
SLL User (Ante ficatromirrerrrrneee
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 7 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Specificati
Date: 12/05/99
S.1.2
S.4.3
SLA
S15 Use of Tokeny.....
5.2 Authentication of Windows NT Users.
S21 Authentication Method...
5.2.2 Standard Windows NT Logow
5.2.3 Logow at Post Office Locations.
SB Authentication of Oracle Useryinnn
5.4 Authentication of Help Desk Operatory.
SS Authentication of DSS/BA Staff...
5.6 Authentication of POCL Stoff.....
6. LOGICAL ACCESS CONTROL
6.1L Access Control Requirementsinnn
614
614.2
6.1.3
6.1.4
6.1.5
61.6 Control of Access to Filey andl Divectority.....
6.2 Control of Access to Databases...
6.2.14
62.2 Changing User’y Parameter sin
62.3 Proflles.nu..
62.4 Oracle Privileges and Rotey....
63 Access Controly Supported by Windows N
6.3.2 Windows NT Access Controt Lists...
63.3 Windows NT Tooly Used to Control Accey...
6.3.4 Windows NT File and Divectory Access...
Printed [DATE \1] COMPANY IN CONFIDENCE Page 8 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
6.3.5 Windows NT Privilegey and Rolesinn.
64 Access Controly Supported by Dynix.....
64.1 Configuration of Dynix...
64.2 Dyniw Accesy Controly...
64.3 Dyniy Tooly Used to Control Accessi.
64.4 Dyniy File and Directory Accessun
64.5 Dynip Privileges and Rolesinnn
65 Access Controly Supported by Solaris...
6.5.2 posse
65.3 Solariy Tooly Usedl to Control Access...
6.5.4 Solariy File andl Directory Access...
65.5 Solarty Privileges and Rote irene
6.6 Control of Accesy to Routers...
66.L Accesy Methods...
66.2 Privi
66.3 Accesy Lists.
6.7 Control of Access to Firewall.
G71 Access Methods.
6.7.2 Access Lists.
6.8 Control of Accesy to VPN Management Information,
AUDIT AND ALARMS
TL Audit and Alar Requirementynenn
7.2 Sources of Audit Eventy nnn:
7.3 Auditable Eventy...
7.4 Application Level Audliti.nn.
74.1 General Requirementy...
74.2 Audlitatthe CAPS Interfaclren
Printed [DATE \I] COMPANY IN CONFIDENCE Page 9 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
74.3 Audit Tracks within the Database.
7.4.4
TAS Logging in Fall-back Mode...
7.5 Application Level Audit Analyyws....
7.6 Protection of Audit TACKS vu
7.7 Audit of Systems Management Functionsin.
7.8 Windows NT AUdhitvrereeseennen
7.8.1 Selection of Auditable Eventy....
7.8.2 Audit of File ana Directory Actions.
7.8.3 Audit of Registry Actions.nuun
7.8.4
7.9 Alar COnMHOWecrssrieesserrrsereeesens
8. SECURITY OF LINKS
8.2 CAPS (and ESNCS) Lies inne
8.1.24
8.14.2
8.1.3
8.2 CMS Linky.
8.21 Protection.
8.2.2 Key Management.
8.3 POCL TIP (and Reference Data) Link...
BBL Poteet ereecrsessnssssensnersnsneerennes
8.3.2
B.A POCL HAPS LU kisrrnesssesseseseesees
5: oo 2, 6
8.4.2 Key Management...
8.5 POCL AP Client Links.
8.6 Post Office Linky.
8.6.12 Protection.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 10 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
8.6.2 Key Managementuerrsrnnersseernnessens
8.7 Post OfFiCO LAN Seressrsssssesesssesessecrsssnnnsnsens
5 6 2 6
8.7.2
8.8 RoW-out to Post Offices...
8.9 ICL Pathway Inter-campuy Links...
5: Be 02 6 ca
8.9.2
8.10
BiLOQ Protector ereecrsecssreesessnersnrveersnees
8.10.3 Key Management.
8.422 Links with ICL Pathway Headquarters...
BDLQ2 ProteHoirrerrsrerscessennnnnnnnnnnenen
8.11.5 Key Management,
8.12 Key Generation.
9. MESSAGE PROTECTION
UL
W22
9.3 BES Payment Authorisations....
DA Avetomated Pay ineintyirrerenrreeses
4.5 Software Distributed to- Post Offices.....
VSL i
VS.2
9.5.3 Protectiow of Non-desktop Software Resident ow Post Office PCs82
USA Protection for Siemens Metering Code andl Dati.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page u1 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
9.6 Other Message Types.
10. FILESTORE ENCRYPTION IN POST OFFICES
10.4
10.2
10.3
11. ADMINISTRATION OF SECURITY.
11.2 Management Roley and Responsibilities.
ALLL Operational Rol ines
11.4.2 Systemy Management Rolty......
ALLB Support ROU rrseirneenennen
11.2 Systemy Management Componenty.
LL QD TOW rrcssrsecrssessenseesssnessnneessenneees
11.3 Systemy Management Services...
11.3.1 Software Distribution,
11.3.2 Event Managementrresnene
11.3.3 Network Management.
11.3.4 Resource Monitoring
11.3.5 Inventory Management.
114
11.4.1 Administration of User Accounts
11.4.2 Administration of Accesy Control...
APPENDICES
Appendin A Windows NT Audit Eventy
Appendix B Mapping to Security Requirementy
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 12 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
1. INTRODUCTION
Lt Purpose
This Security Functional Specification (SFS) defines the security
functionality that will be incorporated into the ICL Pathway system. It is
primarily concerned with the technical features rather than the
surrounding management or operational controls (defined in
[SECPRO]).
1.2 Content
There are three broad categories of security controls, as illustrated in
Figure 1-1.
Management
Code of Practice for
I Security Policies Information Security
I Security Management Management
I Risk Management BS 7799
I Assurance
Operational
Technical
Personnel aspects
Contingency Planning
Incident handling
Awareness and education
Support and operations
Physical and environmental
Authentication
Access control
Audit
Cryptography
Figuret-2 Security Control Categories
This document focuses on the technical security controls that are
primarily concerned with authentication, access control, audit and the
use of cryptography (as illustrated above).
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 13 of 103
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
1.3
1.4
Ls
BS 7799, “A Code of Practice for Information Security Management’, is
primarily concerned with management and operational controls. It will
be used as the basis of ICL Pathway’s Security Procedures [SECPRO] to
define the controls used throughout ICL Pathway.
Scope
This Security Functional Specification (SFS) identifies the technical
controls that will be used to implement the security functionality within
the ICL Pathway system [SADD].
The (logical and physical) environment to be protected is defined in the
Technical Environment Description [TED].
Commercial off-the-shelf (COTS) components have been used as the
primary building blocks throughout ICL Pathway’s solution. This will
reduce the need for bespoke code and enable the suppliers’ standard
product documentation to be used.
An overview of the security functionality, provided by the security
components (identified in section 4), has been included in order to
define the security features and system options that will be used.
Control of access to ICL Pathway’s systems and data will be in
accordance with ICL Pathway’s Access Control Policy [ACCPOL].
ICL Pathwoy’y Security Policy
ICL Pathway’s Security Policy document [SECPOL] encompasses all of
the security requirements specified in ICL Pathway’s agreement with the
Authority. A summary of these security requirements is defined in the
document ICL Pathway Security Objectives [SECOBJ].
By implementing the agreed Security Policy, ICL Pathway will minimise
and control liabilities to itself and the Authorities. The Security Policy
also explains how ICL Pathway will comply with the controls defined in
BS7799.
This Functional Specification forms part of the IT security infrastructure
identified in the Security Policy.
Document Structure
Printed:
[DATE \I] COMPANY IN CONFIDENCE Page 14 of 103
FUJ00088002
FUJ00088002
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
This document specifies security functionality within a framework of
explanatory text. The response to each requirement, with any associated
continuation paragraphs, is numbered and indented. The numbering
scheme corresponds to fourth level headings so that responses, if
extracted, can be related back to their original context.
References to the associated documents, listed in section 0.2, are
indicated by the document reference name in square brackets (e.g.
[SADD]).
Cross-references, to the original BA/POCL Requirements, have been
included, wherever possible, In Appendix B.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 15 of 103
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
2.4
2.2
MANAGEMENT SUMMARY
About thiy Document
This Security Functional Specification (SFS) defines the security
functionality that will be incorporated into the ICL Pathway system. It is
primarily concerned with the technical features rather than the
surrounding management or operational controls.
Security Domeiny
The term “domain” has been used to describe distinct parts of the system
characterised by type(s) of service provided, components used (e.g. NT),
and/or area of responsibility (e.g. DSS/BA). The domains are:
e DSS Service Environment Domain,
e PAS/CMS Service Domain,
¢ POCL Central Systems Domain,
¢ Office Platform Service Domain,
e De La Rue Card Services Domain,
e POCL and POCL Clients Domain,
¢ System Management Service Domain, and
¢ ICL Pathway Corporate Services Domain.
The Benefit Payment Service (BPS) maps onto the DSS Service
Environment, PAS/CMS Service, POCL Central Systems, De La Rue Card
Services and Office Platform Service (OPS) domains.
The DSS Service Environment Domain encompasses all ICL Pathway
related equipment and services located at DSS/BA sites.
The PAS/CMS Service Domain encompases the Payment Authorisation
Service (PAS) and the Card Management System (CMS).
The Office Platform Service Domain encompases the Electronic Point Of
Sale Service (EPOSS), which supports all services, or products, provided
by the counter clerk to the customer. For BPS, EPOSS supports the
Benefit Encashment Service (BES) within the Post Offices.
Printed:
[DATE \I] COMPANY IN CONFIDENCE Page 16 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
2.3
2.4
The De La Rue Card Services Domain encompasses the production of
cards and Pick Up Notices (PUNs).
The POCL and POCL Clients Domain will contain a variety of hosts
associated with applications running in the OPS Domain.
The System Management Service (SMS) Domain will contain the central
elements of the System Management (SM) and Network Management
System (NMS) facilities.
The ICL Pathway Corporate Services domain will support ICL Pathway’s
own management processes. The domain encompasses the Data
Warehouse and ICL Pathway’s managed services.
Security Componenty
The security enforcing components within the ICL Pathway system are
Windows NT, Dynix operating system (on Sequent platforms), Oracle 7
database products, networking components (including firewalls and
routers) and encryption devices.
Firewalls will be used to protect the ICL Pathway system from
unauthorised access via external networks and other local networks
collocated at ICL sites. Protection will be provided by a combination of
packet filtering functionality within router components and application
level firewalls.
Riposte, which is security relevant, is also security enforcing whenever it
is configured to handle user authentication.
Virus protection facilities will be installed on selected workstations,
primarily within the SMS Domain.
Identification and authentication mechanisms are required to ensure
that all users are uniquely identified, with only authorised users being
granted any access to the system.
This SFS, therefore, defines overall requirements for user identification
and authentication followed by specific consideration of users of NT,
Oracle, Help Desk operators, DSS/BA and POCL staff.
Printed:
[DATE \1] COMPANY IN CONFIDENCE Page 17 of 103
FUJ00088002
FUJ00088002
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
25
2.6
2.7
Logical Access Control
This SFS considers the access rights that will need to be supported by
system components and the ability of the system to enforce access
rights.
To provide effective control of system resources, ICL Pathway will
produce a clearly defined Access Control Policy to identify all users who
are authorised to access any part of the system and the access rights that
are to be permitted.
The Access Control Policy will be expressed in terms of roles rather than
named individuals. Users will then be associated with one or more roles
so that all persons are individually accountable for their actions.
In addition to control of access to databases, use of the access controls
supported by Windows NT, Dynix, and Routers has been included.
Audit and Alerwy
The audit and alarm facilities provided by the ICL Pathway system will
be a combination of application level transaction logs and lower level
audit tracks.
The Riposte application provides an ideal basis for logging all
transactions to give a complete picture of actions within the Benefit
Encashment Service and Post Offices Infrastructure Service.
Patrol will be used to manage all Sequent systems and the Oracle
applications that run on Sequent platforms.
Wherever possible, application level auditing will be used. The
notification services provided by the systems management products
(notably Tivoli) will be used wherever appropriate. Low level Windows
NT audit tracks will also be used to provide additional facilities where
application level auditing of system management activities is not
supported.
Crypto Functionality
This SFS describes the cryptographic functionality, within the ICL
Pathway system, used to protect:
Printed:
[DATE \I] COMPANY IN CONFIDENCE Page 18 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
¢ data on individual communications links,
¢ individual messages from creation to use (end-to-end), and
e data stored on physically insecure Post Office filestore.
Key management and the special requirements of roll-out are also
covered.
Files transmitted to ICL Pathway over the “CAPS Links” from BA’s CAPS
system to ICL Pathway’s CAPS Access Service, will be integrity protected
using an encrypted trailer comprising fields from the original trailer
(including a set of totals for financial data), file header information (to
verify the file’s origin), and a CAPS generated Cyclic Redundancy Code
for the whole file. These are concatenated, checksummed and encrypted
using Red Pike, implemented in software. The values are
correspondingly verified at the ICL Pathway end of the link.
The “CMS links”, used to transfer card production data to the card
producer, will be protected using Red Pike. All data on these links will be
encrypted for confidentiality and integrity.
ICL Pathway’s inter-campus links, between the Data Centres,
are very high-speed (34Mbps) connections, which gives them a
significant level of inherent security. There is, currently, no suitable
encryption hardware capable of operating at this speed, so particularly
sensitive data will be protected using Red Pike.
DSA signatures will be used to protect the integrity of data on the “POCL
TIP link” in both directions. Verification will entail validation of the
incoming public key certificate against a CA public key. The same end-
to-end integrity protection will be used, where appropriate, to protect
other low volume data such as Post Office reconciliation totals.
The kilostream “POCL HAPS link”, to Farnborough, will be protected
using Rambutan based encryption hardware.
The Host Automated Payments System (HAPS) is an interim solution,
whereby all AP data will be sent to an existing POCL Tandem system
sited at Farnborough. In the future, the ICL Pathway system will
communicate directly with POCL customers (rather than indirectly via
HAPS) using the “POCL links”.
Printed:
[DATE \I] COMPANY IN CONFIDENCE Page 19 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
2.3
2.9
The “SM/SIS links” used, by ICL Outsourcing, for support and system
management, will be protected using Government approved point-to-
point encryption devices employing the Rambutan algorithm.
Links from the ICL Pathway headquarters site to the ICL Pathway
campuses will also use Government approved point-to-point encryption
devices.
The “Post Office links”, from the POCL Central Services Domain to the
Post Offices, will be protected by use of Virtual Private Networks (VPN),
with each member of the VPN community having a different key pair.
The roll-out and key management aspects, particularly for the Post
Office Integrated Services Digital Network (ISDN) links, will be given
very careful consideration to achieve optimum design.
Message Protection
All message protection will be performed using DSA with a 768 bit
modulus. Each DSA signature requires a cryptographically strong
random initialisation value, known as a K-value.
Standard public key technology will be used, with ICL Pathway’s “PK
certificates” based upon the X.509 standard. PK certificates will contain
the public key, the name of the possessor of the corresponding private
key and an expiry date.
BES payment authorisations will be digitally signed on leaving the
PAS/CMS machine. Signatures will be verified immediately prior to use
by the BES application in individual workstations at the Post Offices.
Automated Payments will be signed in the Post Office for verification by
a central harvester.
Fulestore Encryption Ww Post Officer
Red Pike, incorporated into the Team Crypto product, will be used to
protect information held on hard disks within Post Offices. The NT
workstations installed in Post Offices will not have operable floppy disk
drives (since, if fitted, they will be physically blanked off and disabled in
the BIOS).
Printed:
[DATE \I]} COMPANY IN CONFIDENCE Page 20 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Selected files on Post Office workstations and gateway machines will be
automatically encrypted at disk access level to preserve data
confidentiality in the event of the workstation being stolen.
The Post Office Manager (or authorised representative) will be the only
person on site who has the means of unlocking the key to the filestore
encryption.
2.10 Aduvinistrotion of Security
Roles have been broadly defined under three category headings, namely
Operational, Systems Management and Support. The ICL Pathway
Access Control Policy contains a detailed definition of roles and
responsibilities for all personnel who will have any kind of access to the
services provided by ICL Pathway.
Systems management services will be based upon three main products,
namely Tivoli, HP OpenView and Patrol. The services provided will
include:
¢ Software Distribution - using Tivoli Courier,
Event Management- using Tivoli Event Console,
Network Management - using HP OpenView,
¢ Resource Monitoring - using Tivoli Sentry, and
¢ Inventory Management - using Tivoli Inventory.
User management, which is primarily concerned with administration of
user accounts and access controls, will use Riposte and the standard
facilities provided for the Sequent and Windows NT platforms.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 21 of 103
ICL Pathway Ref:
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
RS/FSP/oo1
Seeurity Functional Version: 4.0
Date: 12/05/99
3.1
SECURITY DOMAINS
Domain Definition
Within this document the term “domain” has been used to describe
distinct parts of the system characterised by:
© type(s) of service provided,
¢ components used (e.g. VME, Oracle, Dynix, NT), and
¢ area of responsibility (e.g. ICL Pathway, BA, POCL).
The domains, which may be geographically distributed, will provide
services that are used within the domain and/or by other domains.
The services offered by several domains combine to provide the end-to-
end services, namely:
e Benefit Payment Service (BPS), and
e Post Offices Infrastructure Service(POIS).
These services are defined in the System Architecture Design Document
[SADD].
DSS Service
Environment Domain
Pathway
Corporate DeLa
Services I CAPS Rue
(and ESNCS) Card
Links
Domain
CMS I Services
Link I Domain
‘ PAS / CMS —_
‘ : Service Domain
x TIP
Link
‘System SM/SIS POCL Central POCL
Management I _ Links Services Domain <— ad
Service HAPS I POCL
Domain Link I Clients
x ISDN Link Domain
Office Platform AP Client
Service Domain Links
Printed:
[DATE \I] COMPANY IN CONFIDENCE Page 22 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
3.2
Figure 3-4 Communitationy Linky Betweew
Domainy
Figure 3-1 illustrates the primary communications links between the
domains. These links, which are the external connections to the ICL
Pathway central sites, will be protected to preserve the integrity and
confidentiality of information handled by the system.
Where domains encompass two or more geographic locations, the
external links between sites will be protected.
The authentication, access control and audit functionality, described in
sections 5, 6 and 7, will apply to all domains. The crypto functionality
and message protection mechanisms, specified in sections 8 and 9, have
been described for each type of link.
The DSS Service Environment Domaiw
The DSS Service Environment Domain is illustrated in figure 3-2.
caps ~I ICL Series 39
Interface VME EDS I Pathway
q Boundary
DSS} Pathway
Partition ‘Partition Firewall
I I ii
Router
Local LANs
DSS /BA Area Computer Centre (ACC) . a
To Pathway's Central Sites
Figure 3-2 DSS Service Environment Domoiw
The ICL Series 39 machines are used for the DSS Customer Accounting
and Payments Strategy (CAPS) system that handles payment
authorisations. The associated DSS Electronic Stop Notice Control
System (ESNCS) will handle Order books for benefits.
Printed:
[DATE \I] COMPANY IN CONFIDENCE Page 23 of 103,
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
The network configuration illustrated in figure 3-2 is simplified and the
ESNCS, which is at only one of the four ACC sites, is not shown.
CAPS will be partitioned such that information, generated for and
returned by ICL Pathway, has a clearly defined boundary. ICL Pathway’s
responsibility in this domain is to accept Benefit related data generated
by CAPS (or ESNCS) and return data to CAPS (or ESNCS).
EDS, who will manage CAPS within the DSS/BA sites, will maintain
firewalls to protect their mainframes from unauthorised access from the
external (including ICL Pathway) sites.
3.3 The PAS/CMS Service Domain
The PAS/CMS Service Domain will span two sites that are often referred
to as ICL Pathway’s Data Centres or campuses.
The logical components within this domain are illustrated in figure 3-3.
The CAPS Access Service (CAS) will support the file transfer to/from the
DSS/BA systems in the PAS/CMS Service Domain.
The PAS and CMS applications will use the same Oracle database that
runs on Sequent hardware with the Dynix operating system.
PAS Help Desks and CMS Help Desks will be based upon Windows NT
platforms with the Client applications used to access the Oracle
database.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 24 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
CAPS
' ‘
penne CAPS. wee. PAS/CMS
' Access Service ‘Service
H Domain
¥ ¥
Payment Card Card
Management Management Producer
R
: Help Desk '
TMS
Figures - 3 PAS/CMS Service Domaiw
3.4 The POCL Centrol Servicey Domaiw
The POCL Central Services Domain contains the ICL Pathway
application hosts at the central ICL Pathway sites. These hosts support
the Post Office APS, EPOSS and OBCS applications.
All applications will run on Sequent machines with Oracle databases.
The POCL Central Services Domain will interface with the PAS/CMS
Service Domain and the OPS Domain as illustrated in figure 3-4.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 25 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
mw i
cms aoe ' ESNCS caps I
nvironment Domain + i
t ,
joe e ee eee eee e eee : ' Help Desk
POCLand ! ' ' as
POCL Clients 1 POCL PocL I 1 I PAs/cMs I.. - '
I Clients TIP t t '
Domain ' ' ' "a
teAL H Lif Es
PAS / CMS
Service Domain
Ref. “PAS I
Hosts a
losts ApS JEPOSS] Data I OFS} ous I
t POCL Central
Services Domain
Agents
Distribution, ~
' Transaction Management k
™s ! WAN ' Riposte and
' ' Windows NT
1 D
Post ' Counter Infrastructure I Office Platform
Ofte ae aaa Service (OPS)
ee APS IEPOSS] OBCS I BES Domain
Counter
Figure 3 - 4 POCL Central Services and OPS Dowoiny
As can be seen, the POCL Central Services Domain contains agents for
each service provided at the Post Office counters. These agents provide
the interface between Riposte and host systems.
Transaction Management Service (TMS) Agents will assemble
information from these hosts for distribution. The Correspondence
Servers, which are the central part of the Riposte TMS, will distribute the
information to/from the Riposte journals at the Post Offices.
PAS Agents and CMS Agents access the database on the Sequent
platforms. This interface will contain Remote Procedure Call (RPC)
mechanisms used to interface Dynix with Windows NT.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 26 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
This domain includes the Key Management System used to generate and
distribute keys within the Central Services Domain and to Post Offices.
All PAS transactions will be “signed” by the PAS/CMS Agents, using the
message protection facilities specified in section 9.
The Central Service Domain spans two sites that are often referred to as
ICL Pathway’s Data Centres or campuses.
The transaction management facilities provided by Riposte, including
the Correspondence Servers and agents, will run on Windows NT
platforms.
The POCL Central Services Domain should not be confused with the
Transaction Management Service (TMS). The POCL Central Services
Domain is limited to the central ICL Pathway sites, whilst TMS is defined
to include the Riposte components that run on PCs within the Post
Offices.
The Order Book Control Service (OBCS) is, commercially, a POCL
service, but data is exchanged over the CAPS/ESNCS link to a DSS ACC.
This can be viewed as the DSS hosting a POCL service.
3.5 The Office Platform Service Doman
The OPS Domain encompasses all Post Office sites as illustrated in figure
3-4. The applications, that will run on Windows NT workstations,
support the:
e Electronic Point of Sale Service (EPOSS),
e Benefit Encashment Service (BES),
¢ Automated Payment Service (APS), and
e Order Book Control Service (OBCS)
BES will incorporate the security mechanisms used to verify the integrity
of messages that are “signed” by PAS, described in section 9.
Reference data, sourced mainly from DSS and POCL, will be distributed
to the target applications in the OPS domain. CRC based integrity checks
and validation procedures will be incorporated.
Cryptographic mechanisms will be used to protect hard disks within the
OPS Domain. Filestore encryption and the associated key management
facilities are described in section 10.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 27 of 103
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
3.6
3.7
3.8
De La Rue Card Services Domain
The De La Rue (DLR) Card Services Domain encompasses the facilities
used for the production of cards and Pick UP Notices (PUNs).
The links between the PAS/CMS Service Domain and the DLR Card
Services Domain will be protected as specified in section 8.
POCL and POCL Clients Domain
The POCL and POCL Clients Domain contains the ICL Pathway system
components that will provide the interface with POCL and POCL Clients
(except DSS).
ICL Pathway will provide the POCL Transaction Information Processing
(TIP) system with records of all transactions at Post Offices. The
associated POCL system, which will shares the TIP link, provides
reference data for the applications.
In the short term, the POCL Automated Payments (AP) system, which
processes payments on behalf of POCL Clients, will use the existing
POCL service (known as HAPS) that runs at the POCL site at
Farnborough. This system will be responsible for forwarding data to
POCL’s AP clients, until it is replaced by direct links from ICL Pathway
to each of the POCL Client systems.
Initially, the domain will contain the ICL Pathway PC(s) and associated
communications components, installed on the Farnborough site, used to
receive files sent from the ICL Pathway campus.
System Management Service Domain
The System Management Service (SMS) Domain will contain the central
elements of the System Management (SM) and Network Management
System (NMS) facilities.
By their very nature SM and NMS are potentially system wide since all
components of the system need to be managed. It is, however, consistent
to include an SMS Domain to identify the centre of control for SM and
NMS.
Printed:
[DATE \I]} COMPANY IN CONFIDENCE Page 28 of 103
FUJ00088002
FUJ00088002
ICL Pathway
COMPANY IN CONFIDENCE
Security Functional
FUJ00088002
FUJ00088002
Ref: RS/FSP/oo1
Version: 4.0
Date: 12/05/99
The Strategic Infrastructure Service (SIS) and System Management
Centre (SMC) Help Desks are within the SMS Domain.
3.9 ICL Pathway Corporate Servicey Domaiw
The ICL Pathway Corporate Services domain will support ICL Pathway’s
own management processes. The domain encompasses the Data
Warehouse and ICL Pathway’s managed services as illustrated in figure
35:
Inputs to the Data Warehouse, from the operational system, are
provided by TMS, PAS/CMS, SMC and SIS.
Pathway Corporate Services Domain
Inputs ' Outputs :
TMS I-—> TPS : Managed Services :
' Financials ‘
PAS / CMS H GUAPIARIPO '
aa] I
: Monitor H
Sorbus ' nd StCA :
Help Desk i be = ‘
1 Warehouse '
Corporate ' '
Reference Data : > '
Figures -S ICL Pathway Corporate Servicey Domaiw
ICL Pathway’s Managed Services, including reporting on the operational
system, accounting, monitoring service levels and fraud risk
management, will use the aggregated information stored within the Data
Warehouse.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 29 of 103
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Date: 12/05/99
41 Security Enforcing Componenty
The security enforcing components within the ICL Pathway system are:
¢ Windows NT Workstation and NT Server,
¢ Dynix operating system (on Sequent platforms),
e Solaris operating system (on Sun platforms),
¢ SecurID tokens and associated ACE/Agent and ACE/Server,
¢ Oracle 7 database products,
¢ Riposte (see below),
¢ networking components (including firewalls and routers),
© encryption devices, and
¢ virus protection products.
Riposte is a security enforcing component whenever it is configured to
handle user authentication [TED]. The overview of Riposte, in section
4.6, will highlight the security implications of Riposte components.
Login Security Account User Accounts
Process Manager Database
Security Policy } .
Database Riposte i
Subsystem J
(ts J
Log ] ™~ Authentication
Local security Win32
Authority Subsystem
a Md
Security Audit Kemel Mode
Policy Messages v
( 2
-xecutive Services
Security Local Virtual
vo Object Pr
anager I Manager I Reference I Manager I Erocedure I Memory
[Divers] Services
it Hardware Abstraction Layer (HAL)
rik 1
I Hardware I
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 30 of 103
FUJ00088002
FUJ00088002
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Figure 4-2 Windows NT Security Componenty
4.2 Operating System Security Functionality
Windows NT is used as the operating system for workstations and most
servers.
ICL Pathway also uses two proprietary operating systems based on
UNIX:
¢ Sequent’s Dynix operating system, and
¢ Sun Microsystems’s Solaris operating system.
4.24 Windows NT Security Functionality
Microsoft's Windows NT Workstation and Windows NT Server have
security functionality that can be described as ITSEC F-C2 [ITSEC].
Currently, only NT version 3.51, in a specific configuration, has been
formally evaluated and certified.
4.2.11 ICL Pathway will use current stable supported version(s) of
Microsoft's Windows NT products (rather than earlier evaluated
versions).
4.2.2 Dynix Operating Systew
Sequent’s DYNIX/PTX operating system is an enhanced version of UNIX
developed for the Symmetry series of multiprocessing systems.
Sequent Host Central Servers are used to run the principal business
applications and associated Oracle databases.
Sequent Data Warehouse Servers act as a repository for a large amount
of financial and service-related information, which is used principally for
ICL Pathway’s internal business purposes.
4.2.2.1 ICL Pathway will use the current version(s) of DYNIX/PTX.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 31 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
4.2.3 Solariy Operating Systew
Sun’s Solaris operating system is used on servers in each campus,
running HP OpenView and Cisco Works to manage the Routers, Hubs
and other network equipment.
4.2.34 ICL Pathway will use the current version(s) of Sun’s Solaris operating
system.
4.3 Datobase Management Systems
Oracle V7 is used to support the databases used by the host applications
running on Sequent servers. Oracle products used include the Oracle
Relational Database Management System and SQL*Net.
4.344 ICL Pathway will use current version(s) of Oracle products.
4.4 SeeurlD Tokeny and ACE/Server
SecurID tokens from Security Dynamics are used for identification/
authentication of privileged users, as specified in section 5.1.5.
Appropriate Windows NT workstations will include an ACE/Agent that
is automatically invoked during the authentication process to request a
password and Personal Identification Number (PIN) number from the
user. The PIN proves that the token belongs to the user.
Similar ACE/Agents will be located on Sequent Dynix servers and Sun
Solaris servers.
The ACE/Agent sends the password and PIN, suitably obfuscated, to an
ACE/Server process running within the Authentication Server at the
campus. This verifies the user’s credentials, and returns a yes/no
indication to the ACE/Agent.
45 Network Security
The ICL Pathway solution incorporates five main components for
enforcing network security:
¢ Firewalls (typically Firewall-1),
¢ Routers (Cisco products),
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 32 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
¢ Post Office link components (VPN and ISDN adapter),
¢ Encryption devices (incorporating Rambutan), and
¢ Cryptographic services incorporating the Red Pike algorithm.
4S Firewolly
Firewalls will be used to protect the ICL Pathway system from:
¢ unauthorised access via external networks, and
¢ other local networks collocated at ICL sites.
Protection will be provided by a combination of packet filtering
functionality within router components and application level firewalls.
Control of access to these components is specified in section 6.7.
4.5.2 Rowtery
The routers used will be standard Cisco products and Access Servers.
Control of access to these components is specified in section 6.6.
4.5.3 Post Office Link Componenty (VPN and ISDN Adapters)
This section considers Post Office links.
Specific security controls include:
e Virtual Private Networks (VPN), across all Post Office links - as
described in section 8.6, and
¢ Call screening for ISDN links - where a list of valid callers is
configured in the central Router and all other calls are rejected.
For call screening (on ISDN links) the list of valid caller information
will be subject to access controls and maintained using Tivoli.
An ISDN adapter will be installed in the gateway workstation at every
Post Office location that uses ISDN.
The interface between Windows NT and the adapter is provided by a
Network Device Interface Specification (NDIS) adapter that is supplied
by EICON. The NDIS adapter provides the following security enforcing
functionality:
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 33 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
¢ it will only call phone numbers that exist in the NDIS configuration
data,
¢ it only passes network traffic at the IP level, and
¢ it protects the NDIS configuration information.
All NDIS configuration data will be stored in the Windows NT Registry.
Windows NT access controls and the filestore encryption (described in
section 9) will protect the files used.
Use of VPN is specified in section 8.6.
4.5.4 Encryptiow Devicey
The encryption devices in ICL Pathway’s solution are types ED6ooRTS
and ED2048R3 supplied by Zergo.
These devices are Certified products (ITSEC) and provide cryptographic
protection using the CESG designed Rambutan crypto-kernel.
Encryption devices will be utilised on Kilostream and Megastream
circuits, where appropriate, to provide link-level encryption.
The use of encryption is specified, on a link by link basis, in section 8.
4.5.5 Red Pike
ICL Pathway will use a CESG approved implementation of Red Pike to
provide the protection of selected links, as described in section 8.
The key management facilities used with Red Pike will be implemented
and used in accordance with CESG policy.
The Team Crypto product, used to protect Post Office filestore, also
incorporates Red Pike, as described in section 10.
4.6 Riposte
Riposte (Retail Integrated Point of Sale Transaction Environment) is a
message oriented middleware product designed to support distributed
branch automation.
Riposte provides a 32-bit OLE based application development
environment for use with Windows NT.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 34 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
4.6.1 Riposte User Authentication
Within the OPS Domain, Riposte will be configured to provide user
authentication facilities in conjunction with the underlying Windows NT
logon mechanisms. This is particularly useful at Post Office counters
where it is desirable to present an easy to use user interface with
minimal logon overheads.
Riposte will be used to provide the Post Office user logon interface as
specified in section 5.2.3 and [TED].
4.6.2 Riposte Messages
Riposte messages are self-describing, have a unique identity and are
immutable. Message types include:
e transactions,
enquiries and responses,
¢ audit (and monitoring information),
¢ authorisations,
© session context,
¢ application reference data, and
e system configuration data.
Messages can contain as much data as is required to describe:
e Riposte,
e audit information,
© security properties,
© system management information,
¢ system administration information, and
¢ application information.
When messages are created, standard message attributes are added by
Riposte (including date, time, user and a cyclic redundancy check (CRC)
code). Only Riposte can create messages and the message store is
protected using Windows NT Access Control Lists.
Riposte Servers use Windows NT services for:
© configuration information - stored in the Windows NT Registry,
¢ error reporting via the Windows NT Event Log, and
¢ performance monitoring.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 35 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
4.6.3 Riposte Message Servery
A Riposte Message Server is, typically, a Windows NT workstation or NT
Server running the Riposte services.
A Riposte “group” is a domain in which messages are replicated to a set
of message servers, which are uniquely identified by their Node Ids. A
group normally consists of a set of units that are providing a common
service in the same physical location (e.g. a Post Office).
Riposte provides peer-to-peer message replication that increases the
resilience and reliability of the system. When a message is created, it is
first committed in the local message store and then broadcast to all of
the local neighbours. Other Riposte Message Servers, which receive
broadcast messages, store them in local message stores, then forward
them to other local neighbours who have not been sent the message. In
this way, messages are propagated to all members of the group.
Message synchronisation is achieved using “marker” messages that are
exchanged between Message Servers. This allows any messages, which
may be lost or missing from its local message store, to be requested. The
activity, which normally takes place across the LAN, is totally
transparent to Riposte applications.
If a message store is lost, all messages will be recovered from other
members of the group. For a single terminal outlet, a dual disk
configuration is used with fallback to the associated correspondence
servers at the central site to provide secondary backup.
4.6.4 Riposte Correspondence Servery
A Correspondence Server is a Riposte message server that is a member of
more than one group.
Correspondence Servers are used to provide:
© access to central systems,
¢ office backup and recovery, and
¢ distributed group extension.
4.6.5 Riposte Agenty
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 36 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Riposte Agents will provide a service to a Riposte application or group of
applications. They are also used to provide an interface between Riposte
messaging environments and external systems.
Examples of how the ICL Pathway system uses Riposte Agents include:
¢ provision of the interface with the PAS/CMS database applications,
¢ transaction harvesting, and
¢ Riposte related system management activities.
The Riposte Agents used with Windows NT are multi-threading and use
the NT event logging interfaces. They are configured to run as
background processes that either run on demand or automatically as
system services when the system is booted.
The type of each message defines the action to be taken by the Agent
upon message receipt. The action(s) taken may:
¢ interact with an external system,
¢ retrieve information from the message store,
¢ update internal (volatile) state,
¢ update persistent state in the message store, and
¢ write response message(s).
When Agents are restarted, they will co-ordinate recovery with external
systems and restore their state information. Restart is automated by the
System Management facilities (described in section 11.2). Recovery will
include processing messages that may have arrived when the Agent was
down.
The use of Riposte Agents with POCL Clients, AP host(s) and TIP host(s)
is illustrated in figure 3-4.
4.6.6 Riposte Communicationy
Riposte has a Remote Procedure Call (RPC) interface that may be called
from any DCE compliant RPC implementation. This enables applications
on other platforms (e.g. UNIX or Sequent’s Dynix) to be integrated.
Riposte communications are based on a connectionless, best-effort
messaging model.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 37 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
The User Datagram Protocol and Internet Protocol (UDP/IP) are used to
provide high performance communications. The Sockets
implementation of UDP/IP, provided by Windows NT, will be used.
4.6.7 Riposte Desktop
Each Riposte user application:
e runs (Desktop.EXE) on a Windows NT Workstation,
© contains and manages Riposte visual components,
¢ is integrated with RetailBroker, Peripheral, Validate, and TRState,
¢ provides session mobility (with stateless applications), and
e has a modular structure (using DLLs for each application).
The Riposte Desktop System incorporates several Dynamic Link
Libraries (DLL) that are used for:
© transactions and Riposte services (RetailBroker.DLL),
¢ session mobility and logon/logoff (TRState.DLL),
peripheral device handling (Peripheral.DLL), and
input validation (Validate.DLL).
4.7 Viruy Protectiow
This section considers the threat of virus infection and identifies the
components needed to provide an appropriate level of protection.
4.7.4 Threat of Virvy Infection
The threat of virus infection in most parts of the ICL Pathway system is
relatively low since:
¢ Windows NT is used throughout the Office Platform Service Domain,
¢ all PAS/CMS Help Desks use Windows NT platforms running
dedicated client software,
¢ floppy disk drives cannot be used within Post Offices,
e there are no E-mail connections to external systems,
e¢ MS Word documents (that could contain Word macro virus) are not
normally imported,
© operational files transmitted by file transfer contain data rather than
executable code, and
¢ the main processing platforms are Unix based.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 38 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
There is, however, a need to protect against the introduction of viruses
from the following external sources:
¢ executable files introduced for maintenance purposes, and
¢ HTML documents containing user Help information.
4.7.2 Viruy Protect Measurey
Virus protection will rely upon adherence to the security procedures
defined in [SECPRO] and the measures supported by the ICL Pathway
system.
4.7.21 All workstations running Windows 95 will have virus protection
software (e.g. Dr Solomon’s WinGuard) installed.
4.7.2.2 All workstations used to import executable code, destined for any
Windows platform, will have virus protection software installed.
The “import” of executable code will normally be from external
sources (e.g. floppy disk) into the System Management Service
Domain. This will enable virus checked software to be distributed
throughout the ICL Pathway system (e.g. to PCs located in Post
Offices) over the network without requiring the recipient PCs to run
further virus checks.
4.7.2.3 All executable code will be virus checked prior to being imported into
any part of the ICL Pathway system.
4.7.2.4 All files susceptible to macro or related viruses (including HTML
files), for which virus checks are feasible, will be checked for viruses
prior to being imported into any part of the ICL Pathway system, by
whatever route.
4.7.2.5 Anti-virus software will be maintained by installing current upgrades,
as they become available.
4.7.2.6 As an additional safeguard, ICL Pathway will ensure that the ICL
Pathway system has adequate facilities for recovery in the event of a
virus being detected.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 39 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Specificati
Date: 12/05/99
Ss. IDENTIFICATION AND
AUTHENTICATION
S51 Identification and Authentication Requirementy
Identification and authentication mechanisms are required to ensure
that all users are uniquely identified, with only authorised users being
granted any access to the system.
Reliable identification and authentication is essential in order to:
¢ provide the basis for access control decisions, and
¢ ensure that all users are individually accountable for their actions.
Authentication is based upon the information received, so the ICL
Pathway system will protect both:
e the collection of authentication data, and
¢ the transmission of authentication data.
Particular attention has been focused upon users situated in any remote
location because these can represent higher risks to the system.
S14 User Identification
Identification is the means by which the user provides their identity to
the system. This can be based upon a combination of what the user
knows (a User Id), what the user possesses (a smart card or other token)
or some biometrics characteristic of the user.
5. All users will be allocated an identifier (User Id) by which they will be
known to the system.
User Ids will be unique within the scope of that part of the system. For
example, the Post Office Manager would set up and maintain the User
Id information for each counter clerk within that Post Office, using
the Riposte application interfaces provided.
5.112 Wherever possible, a User id should be sufficient to trace the identity
of the particular individual who has been authenticated.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 40 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
In some cases, however, the same User id will be used for infrequent
access by users in particular roles. This will apply, for example, to
POCL Auditors who will be required to authenticate with the Help
Desk before getting a one-shot password.
5.113 The ICL Pathway system will not allow (normal) users to change their
User Id.
The aim is to ensure that “users” remain individually accountable. It
is, however, recognised that for very privileged users this might be
difficult (or unrealistic) for the system to enforce. Procedural rules
and auditing will be used to provide additional controls that support
this objective.
5.11.4 The format of User Ids will depend upon the platform(s) used and the
server used for authentication.
In all cases, the procedures used by ICL Pathway [SECPRO] will
provide guidelines to cover operational aspects, including:
e the allocation of User Ids to individuals,
¢ selective removal of User Ids from the system, and
¢ constraints on re-allocation of User Ids to other personnel.
5.115 The system will distinguish between identification information (User
Ids) and authentication data (including passwords).
5.11.6 The security of the system will not rely upon the secrecy of any User
Id information.
5.1.2 User Authentication
Authentication is concerned with establishing the validity of the user’s
claimed identity. It increases confidence that the claimed identity is the
right one for the user.
5.1.2.1 All users will be authenticated before any access is granted to the ICL
Pathway system.
Human users will, therefore, complete the logon sequence before they
will be able to invoke any other actions.
5.1.2.2 Users will be allowed a predetermined number of attempts to logon,
as specified in [ACCPOL]. After this number is exceeded the user’s
logon facility will be disabled.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 41 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Other action taken upon failure to logon will be configurable from the
following options:
© analarm message will be raised,
e logon failure will be recorded in the audit track, and
¢ an application level audit message will be generated.
In all cases the logon failure will be recorded.
5.1.2.3 Following logon failure, the user’s logon facility will be reset by:
© positive action by the system manager, or
© expiry of a timeout period.
The optional timeout facility will only be available within the Office
Platform Service Domain. The configuration of this facility, including
the time between retries, will be specified in [ACCPOL].
5.1.2.4 During logon, the responses provided by the system to the user will be
simple messages reporting success or failure. No reason will be given
in the event of logon failure.
5.1.2.5 On successful logon, the system will display the date and time of the
user’s last successful logon at Post Office outlets and for the PAS/CMS
Help Desk.
5.1.2.6 Within each Post Office, users will not be able to run more than one
counter PC with the same user identity.
A subsequent logon at a second PC will cause Riposte to terminate the
users previous session and transfer use to the new counter position.
5.1.3 Passwords
Human users and system/process users will use passwords. This section
defines the requirements for all passwords, whilst the additional
requirements specified in section 5.1.4 apply only to passwords used by
human users.
5.13.1 The ICL Pathway system is not required to provide automated
generation of passwords.
5.1.3.2 The format of passwords will depend upon the platform(s) used and
the server used for authentication.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 42 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
In all cases, the procedures used by ICL Pathway [SECPRO] will
provide guidelines on the use of passwords, including:
¢ the allocation of new passwords,
© appropriate choice of replacement passwords,
the need to avoid disclosure of passwords, and
the frequency and timing of password changes.
5.1.3.3 The system will use volatile memory for operations associated with
password checking. For ICL Pathway specific code, when the checking
is completed all “in clear” password information will be overwritten.
Ideally, all “in clear” password information should be overwritten after
use but the use of COTS products and standard applications may
dictate that this can not be achieved or verified.
5.1.3.4 Passwords will never be visibly displayed by the system.
5.1.3.5 Passwords will not be transmitted “in the clear” to or from any
location outside the central ICL Pathway sites unless they are one-
shot passwords.
5.1.3.6 Passwords will not be transmitted “in the clear” within ICL Pathway
sites unless the link used is entirely within a physically protected area
(e.g. Campus sites).
5.1.3.7 All Routers will be configured in the mode that ensures that password
information is stored in encrypted format.
5.1.3.8 An appropriate one-way algorithm will be used to encrypt passwords
on target systems.
5.1.4 Humaw User Passwords
The requirements specified in this section apply only to passwords used
by human users.
After an initial password has been issued, the choice of passwords will be
the responsibility of individuals.
5.1.4.1 An initial password will be made known to each individual. The
system will mark these initial passwords as expired.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 43 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
As this password is known by more than one person, the user is forced
to change the initial password before other options can be selected.
This mechanism will also apply to any passwords reset by a third
party.
5.1.4.2 An appropriate one-way algorithm will be used to encrypt password
information used by human users, before storage or transmission.
By definition, it will not be possible to derive passwords from their
one-way encrypted form (except by the use of massive computing
power over an extensive period).
5.1.4.3 All users will have the ability to change their own password (without
requiring intervention from a supervisor or Post Office Manager).
Password change interfaces are expected to depend upon platform
type (e.g. Dynix and Windows NT will differ) but in all cases the user
will complete the logon sequence before initiating a password change.
The change sequence will also require the old password to be correctly
quoted.
5.1.4.4 The OPS will provide facilities to enable the Post Office Manager to
establish new users and set an initial password for each user in their
Post Office.
5.1.4.5 Ifa user forgets their password the Post Office Manager will be able to
reset the password.
5.1.4.6 For situations where the sole user (e.g. Post Office Manager in a single
counter office) has forgotten his password, a secure backup procedure
will be used.
S15 Use of Tokeny
The ICL Pathway system will only use tokens when the protection
provided by passwords alone is not considered to be sufficient. In
general, token use will be limited to system management personnel and
management operations conducted from or on remote sites, as defined
in [ACCPOL].
5.15.1 Tokens will be allocated to named individuals for their sole use.
Printed [DATE \l] COMPANY IN CONFIDENCE Page 44 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
In certain circumstances (e.g. fourth line support,) a card may be
“assigned” to an individual for a limited period. In such cases, a full
audit trail of such cards will be retained.
5.15.2 The identity of users who have been issued with tokens will be made
known to the system and the authentication processes will enforce
their use.
5.1.5.3 The system will be capable of selectively revoking the validity of
tokens.
5.1.5.4 Smart tokens will be used in all cases where a password alone is not
considered to be sufficient. The user will be obliged to prove that
he/she posses the token at the time of logon.
Tokens that generate a one-time password, thereby protecting against
password replay, will be used.
5.15.5 Each token will have an associated Personal Identification Number
(PIN) that is used to activate the device, as defined in [ACCPOL].
5.1.5.6 Personnel who are authorised to access the ICL Pathway system from
remote locations will be required to identify themselves using hand
held tokens.
This group will comprise selected system administrators authorised to
use remote access for system management activities.
The Girobank Help Desks are physically treated as data centre
campuses and are not considered to be a remote location.
ICL Pathway Headquarters site (see section 8.10) is categorised as
being a “remote location”. ICL Pathway personnel who require access
to the operational system and/or Data Warehouse will be required to
use tokens.
5.1.5.7 Personnel who are authorised to access the ICL Pathway system using
UNIX root privilege will be required to identify themselves using hand
held tokens.
5.15.8 Personnel who are authorised to access the ICL Pathway system as a
database administrator (DBA) will be required to identify themselves
using hand held tokens.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 45 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
5.2 Authentication of Windows NT Usery
5.24 Authentication Methody
Windows NT [WINNT] will be used as the base operating system for:
e PAS/CMS Help Desk clients within the PAS/CMS Service Domain,
e platforms within the POCL Central Services Domain,
¢ workstations within the Office Platform Service Domain,
¢ servers within the De La Rue Card Services Domain, and
¢ servers within the POCL and POCL Clients Domain.
The standard Windows NT logon mechanisms (outlined in section 5.2.2)
will be used for users in all domains listed above, except the Office
Platform Service (OPS) Domain. Users in the OPS Domain, which
includes all Post Office staff, will used a simpler interface provided using
Riposte (as described in section 5.2.3).
In both cases:
5.2.1 Information used to authenticate users will be protected by the
authentication mechanisms used.
5.2.1.2 All users will be named individuals with their own password.
All account information associated with Guests will be disabled or,
where possible, removed entirely.
Removal of other generic Windows NT users (namely System and
Administrator) can result in installation problems. These users will,
therefore, be retained for System Management purposes but will be
subject to additional controls, as defined in [ACCPOL[.
5.2.13 The standard Windows NT password algorithms will be used.
5.2.2 Stonderd Windows NT Logow
The Windows NT logon process is illustrated in figure 5-1. For users in
domains (defined in 5.2.1) that use this form of logon:
5.2.2.1 The trusted logon process (as illustrated in figure 5-1) will be used to
authenticate users, based upon their User Id and password.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 46 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Date: 12/05/99
CTRLALT+OEL
WinLogon
Password [1]
Win32
Accous Subsystem
Token
Securty I~<—j Security
‘Subsystem
New
Process
>] Manager 9
3
4 ic Screen
for Initial
Security Application
Accounts
Database
Figure S - 12 Windows NT Logow Procesy
5.2.2.2 The logon process will be reliably initiated by the user invoking a
trusted communication path (from the user to the system).
Windows NT users will use the combination Ctrl+Alt+Del to invoke
this trusted path.
5.2.2.3 Windows NT will require each user to change their password
periodically. The initial change will be required the first time the user
logs on and subsequently as defined in [ACCPOL].
The exact interval will be configurable and will depend upon the
user's role and location.
5.2.2.4 The Windows NT Account Policy controls will be used to set
parameters, in accordance with [ACCPOL], including:
password expiry period,
minimum password length,
minimum password age (before change),
remember password history (number of passwords per user),
number of consecutive failed logon attempts before lockout, and
whether to reset logon count after a delay period (see 5.1.2.3).
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 47 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Date: 12/05/99
5.2.3 Logow at Post Office Locotiony
To reduce logon overheads and improve operational efficiency, the logon
user interface used throughout the OPS Domain will use Riposte desktop
facilities [TED] rather than the native Windows NT interface.
This does not imply that the Windows NT Registry is not used.
5.2.34 All authorised users will have individual User Ids (allocated by the
Post Office Manager) and passwords that will be held in the Windows
NT Registry for that Post Office.
Power up Windows NT Workstation
1
Auto Login (using default User Id) I <—
~~
Start Riposte Desktop Application
Postmaster “unlocks”
the encrypted filestore
oO
Activate using Login Form I <— Recent
T
Riposte authenticates User
using Windows NT Registry
Validate User Id
Invalid Validate Password
Valid
Enable Desktop
v
Desktop Operation
Exit from Desktop < cosour
eques'
Figure 5-2 Logow Sequence at Post Offices
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 48 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
The logon sequence used is illustrated in figure 5-2. For simplicity,
filestore encryption logic (described in section 10) associated with initial
power up is not shown.
When the Windows NT workstation is powered up, the Windows NT
facility for automatic logon is initiated instead of the normal manual NT
user logon sequence. This will enable a dummy user with username (u1)
and password (p1). The first security check is then forced by automatic
entry into a Post Office Manager’s (POM’s) authentication protocol,
which requires the POM to authenticate using his/her Memory Card and
associated PIN in order to continue the boot up sequence and unlock
encrypted filestore.
5.2.3.2 Facilities that enable the automatic logon to be bypassed, to give
access to a standard Windows NT logon, will be disabled.
In particular, use of the Shift key to escape whilst booting Windows
NT will not be enabled.
On completion of the automatic logon, the Desktop process is entered
automatically. Once the Desktop process has completed loading and
Initialisation, the Desktop will display a User logon form.
This Desktop user logon is integrated with Windows NT. A successful
logon requires the username and a one way hash of the password to be
valid within both Riposte and Windows NT.
Once the Desktop user logon has been completed successfully, the user
can execute applications within the Desktop.
It is important to note that the Desktop process runs within the security
context of user ui. However, the Desktop process does not access files
directly, but acts as a Client to the Riposte service that is running under
a privileged user u3. When the Desktop calls on the Riposte service to
perform a function (such as write a message to the Riposte message
store), the Riposte service will ‘impersonate’ username u2, the Desktop
username (provided by the real user).
Impersonate is an NT term defined in the Microsoft Developer Studio,
Visual C ++ version 4.2 as:
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 49 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
“Impersonation is the ability of a thread to execute in a security context
different from that of the process that owns the thread. Typically, a thread
in a server application impersonates a client. This allows the server thread
to act on behalf of that client to access objects or validate access to its
own objects.”
When the user logs off from the desktop, the desktop logon form is
displayed whilst the desktop remains active in the security context of
username ut. This allows the PO user to subsequently logon without
incurring the (typically 30 second) delay arising from loading the
desktop.
5.3 Authentication of Oracle Usery
Oracle DBMS products [ORACLE] support two methods for user
validation, namely:
¢ authentication by the associated Oracle database, and
¢ authentication by the operating system.
5.344 Oracle will be used to authenticate all database users (e.g. PAS/CMS
Help Desk) in the operational ICL Pathway system.
5.31.2 The Sequent Dynix operating system, which will provide the platform
for Oracle, will be used for authentication of all Operational Support
users (e.g. Security Manager) in the operational ICL Pathway system.
5.34.3 The Card Management Service (CMS) and Payment Authorisation
Service (PAS) will use a Client - Server architecture with the Oracle
DBMS server component running on the Sequent platform.
5.3.1.4 A single “Pathway” user on the corresponding Sequent platform will
own all tables associated with the CMS and PAS.
5.315 Database access from the POCL Central Services Domain is provided
by Riposte Agents running on Windows NT. Each agent will be
associated with a Port (or multiple Ports) on the Sequent machine.
The default TCP port for SQL*Net connects to Sequent. Normal
Oracle id/password/role authentication applies.
5.4 Authentication of Help Desk Operatory
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 50 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
5.4.11 Help Desks for CMS and PAS will be client applications running on
Windows NT. Groups of clients (typically 50 to 100) will be connected
to Windows NT based servers that provide the connection to the
Sequent machines.
5.4.1.2 All Help Desk users will be named individuals in a user group
associated with a Database Role.
The roles used (e.g. Manager, Supervisor and Advisor) will be defined
in [ACCPOL].
5.4.1.3 Each Help Desk user will be allocated a User Id and initial password.
This will enable them to connect to the database provided they have a
valid username defined in the database.
These users are permitted to access the database by running an
application (such as Oracle Forms).
5.4.1.4 No specific procedures are required for the Payment Card Help Desk
authenticating to the counter clerk. Authentication will rely on
counter clerk knowledge of correct Payment Card Helpline (PCHL)
behaviour in accordance with the PCHL Process and Procedures
documentation.
5.5 Authentication of DSS/BA Staff
DSS/BA telephone callers will be carefully authenticated prior to
accepting any instruction or advice.
The mechanisms needed to authenticate DSS/BA staff are described in
the respective Help Desk Processes and Procedures Description (PPD).
These PPD documents have been agreed by Horizon representatives.
5.6 Authentication of POCL Staff
Mechanisms will be provided to enable the Post Office Manager to verify
his/her identity when making requests to the appropriate Help Desks.
This will ensure that significant requests, including all changes to the
system, are only accepted from authorised personnel.
The mechanisms needed to authenticate POCL staff are described in the
respective Help Desk Processes and Procedures Description (PPD).
These PPD documents have been agreed by Horizon representatives.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 51 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 52 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
6. LOGICAL ACCESS CONTROL
6.1 Accesy Control Requirementy
There are three aspects to access control:
¢ Authorisation - determining which subjects are entitled to have access
to which objects,
e Access rights - determining the combination of access modes
permitted (e.g. read, write, execute and delete), and
¢ Enforcement - of the access rights.
This Security Functional Specification considers the access rights that
will be supported by system components and the ability of the system to
enforce access rights. The topic of authorisation and assignment of rights
to individuals is addressed in the Access Control Policy [ACCPOL].
6.4.4 Aceesy Control Policy
ICL Pathway’s Access Control Policy [ACCPOL] identifies all users who
are authorised to access any part of the system and the access rights
permitted.
For practical reasons, the Access Control Policy is expressed in terms of
roles rather than named individuals. All users will be associated with one
or more roles so that all persons will be individually accountable for
their actions.
6141 ICL Pathway’s Access Control Policy [ACCPOL] identifies all roles
associated with the system and define the access rights that are to be
granted to each user acting in that role.
6.1.2 Privileges and Roley
Users of the operational ICL Pathway system will carry out their duties in
a variety of roles, including system administrator, database
administrator, help desk advisor, Post Office counter clerk and
maintenance engineer.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 53 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Users will require certain privileges in order to perform their allotted
tasks, The privileges associated with each role will, therefore, be
sufficient to allow all tasks associated with that role to be performed
whilst not providing any additional capabilities.
6.1.2.1 ICL Pathway will apply the principle of least privilege when assigning
privileges to roles and users.
6.1.3 Separation of Duty Controly
Separation of duty controls will be based upon Roles as defined in
[ACCPOL].
There will also be administrative and procedural controls defined within
ICL Pathway’s operational procedures.
6.1.4 Two Persow Controly
Two person controls have been considered for system and database
management operations but are not proposed.
6.1.5 Use of Diseretionary Accesy Controly
Discretionary Access Controls (DAC) will be used to provide resource
owners with the ability to specify who can access their resources and the
type of access permitted.
6.1.6 Control of Accesy to Filey and Divectoriey
Access to each file or directory will be controlled by the owner of the
object who will be able to grant access rights to other users or groups of
users. The types of access supported will normally include Read, Write,
Execute and Delete.
6.2 Control of Access to Datobasey
The three main ways of controlling access to the Oracle database
facilities are by:
¢ being selective about the choice of potential users,
¢ ensuring that user authentication is effective, and
e defining profiles that limit the use of system resources.
6.24 Schemas and Usery
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 54 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Each Oracle database will have a list of schemas that define collections
of schema objects (including tables, views, clusters, and procedures).
Each Oracle database will also have a list of valid database users. These
users are permitted to access the database by running a database
application (such as Oracle Forms, SQL*Plus, a precompiler etc) and
connect to the database using a valid username defined in the database.
When a database user is created, a corresponding schema of the same
name is created for the user. This schema defines the objects that may be
accessed by the user, unless otherwise constrained.
Access rights of a user are determined by the security administrator who
will set up the user’s domain. These parameters will specify:
e whether user authentication information is maintained by the
database or the operating system (see section 5.3),
¢ resource limits, defined in a profile (see section 6.2.3), and
e the privileges and roles (see section6.2.4) that provide the user with
appropriate access to objects needed to perform database operations.
6.2.2 Changing User’y Parametery
A user's security domain can be altered using:
¢ Oracle’s Server Manager, and/or
e the SQL command ALTER USER.
Users are permitted to use these facilities to change their own password
but other operations, which require additional privilege, can only be
performed by the security administrator.
62.3 Profiles
The allocation of resource limits (e.g. CPU time) to individual database
users will be simplified by use of the default profiles. Limits found to be
necessary will be defined as the default wherever possible.
6.2.4 Oracle Privileges and Roles
The Oracle Database Administrator's Guide [ORACLE], which includes a
lengthy section on Privileges and Roles, describes:
¢ system and object privileges,
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 55 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
6.3
6.3.4
63.41
6.3.2
database roles,
how to grant and revoke privileges and roles,
e how to create, alter, and drop roles, and
¢ how role use can be controlled.
A privilege is a right to execute a particular type of SQL statement or
access to another user's object. It can be granted to users explicitly or
can be granted to a role (as a named group of privileges) that are then
granted to one or more users.
Within the ICL Pathway system all privileges will be associated with
roles rather than being explicitly assigned to individual users. This will
provide more effective management control of both system privileges
and object privileges.
Accesy Controly Supported by Windows NT
The following subsections identify the main access control facilities
provided by Windows NT. For a more detailed explanation, the reader
may refer to the standard Microsoft Windows NT documentation
[WINNT].
The security functionality provided by the base Windows NT products is
sufficient to meet the access control requirements on all NT
Workstations and NT Servers within the ICL Pathway system.
Configuration of Windows NT
Configuring Windows NT platforms to provide secure operation is quite
complex. The underlying mechanisms are sound but the products, as
supplied by Microsoft, have default settings that permit Guest users and
do not adequately constrain access to objects.
Configuring each platform, in accordance with [ACCPOL] (see section
6.1.1), is essential.
Windows NT based platforms will be configured strictly in accordance
with [ACCPOL] prior to roll-out.
Windows NT Accesy Control Listy
Windows NT [WINNT] supports Access Control Lists (ACLs) that
identify the resource access permissions granted to users and groups.
Printed:
[DATE \I]} COMPANY IN CONFIDENCE Page 56 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
6.3.2.1 Windows NT Access Control Lists will be used to define permitted
access to objects in accordance with [ACCPOL].
Wherever possible, ACLs will be defined in terms of roles rather than
individuals to simplify roll-out and system configuration.
6.3.3 Windows NT Tools Used to Control Accesy
Windows NT supports a number of tools that can be used to control
access to resources (e.g. File Manager and Print Manager).
63.3.1 The ability to access Windows NT tools will be removed on the basis
of roles, in accordance with [ACCPOL], prior to roll-out.
6.3.4 Windows NT File and Directory Accesy
The types of access associated with files and directories have been
outlined, in general terms, in section 6.1.6.
Appendix A explains how each type of access will be interpreted in terms
of Windows NT files and directories.
6.3.5 Windows NT Privileges and Roley
The use of Windows NT privileges and roles will be defined in
[ACCPOL].
6.4 Access Controly Supported by Dynix
Sequent’s DYNIX/PTX operating system is an enhanced version of UNIX
developed for the Symmetry series of multiprocessing systems.
6.4.4 Configuration of Dynin
The Dynix operating system components will be configured in
accordance with [ACCPOL].
6.4.2 Dynix Access Controly
6.4.2.1 The Sequent Dynix operating system, which will provide the platform
for Oracle, will be used to support the access controls associated with
the database (as described in section 6.2).
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 57 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
6.4.2.2 The Sequent Dynix operating system will be used to control access to
all input and output devices directly connected to Sequent platforms.
6.4.3 Dynix Tooly Used to Control Accesy
Access to Dynix tools, notably those capable of being used to configure
the access control mechanisms, will be controlled in accordance with
[ACCPOL].
6.4.4 Dynix File and Directory Accesy
The standard Dynix tools will be used to configure the access control
mechanisms provided by the operating system. These will be configured
in accordance with [ACCPOL].
64.5 Dynin Privileges and Roles
Dynix privileges and roles will be configured in accordance with
[ACCPOL].
6.5 Accesy Controls Supported by Solariy
Sun’s Solaris operating system is a version of UNIX developed for use on
Sun Servers.
6.5.1 Configuration of Solaris
The Solaris operating system components will be configured in
accordance with [ACCPOL].
6.5.2 Solarin Accesy Controly
6.5.21 The Sun Solaris operating system, which provides the platform for HP
OpenView and Cisco Works, will be used to support the access
controls associated with system and network management services.
6.5.2.2 The Sun Solaris operating system will be used to control management
access to Routers, Hubs and other network equipment.
6.5.3 Solariy Tools Used to Control Accesy
Access to Solaris tools, notably those capable of being used to configure
the access control mechanisms, will be controlled in accordance with
[ACCPOL].
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 58 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
6.5.4
6.5.5
6.6
6.6.4
6.6.11
6.6.1.2
6.6.1.3
6.6.1.4
6.6.2
Sotariy File and Directory Access
The standard Solaris tools will be used to configure the access control
mechanisms provided by the operating system. These will be configured
in accordance with [ACCPOL].
Soloriy Privilegey and Rolex
Solaris privileges and roles will be configured in accordance with
[ACCPOL].
Control of Access to Rovtery
Accesy Methods
Cisco provides four methods of access for controlling routers:
© Console access - using a terminal attached directly to the Router via a
“control port” on the back,
¢ Telnet access - using a Telnet, run over IP, to provide a remote login,
¢ Simple Network Management Protocol (SNMP) access - using the
SNMP protocol to configure the router and collect information, and
¢ Indirect - using the Trivial File Transfer Protocol (TFTP) to download
configuration files from a configuration server.
Console access mode will not be disabled by router configuration. In
normal running, however, the routers will not have consoles attached.
Telnet access will only be permitted in exceptional cases, where more
direct access to the routers is essential, as defined in [ACCPOL].
The Terminal Access Controller Access Control System (TACACS+)
will be used to authenticate all telnet users. Their actions will be
audited at the NMS.
SNMP access will be used for remote system management of routers
(as defined in section 1).
Use of TFTP will be controlled.
Privileged Mode Accesy
Provided Console or SNMP mode of access is used (as defined in section
6.6.1) the use of privileged mode access can be controlled, as follows:
Printed:
[DATE \I]} COMPANY IN CONFIDENCE Page 59 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
¢ Fora given user (or group of users), non-privileged and privileged
access can be permitted. Non-privileged access allows users to
monitor the Router but not configure the Router. Privileged mode
allows the user to fully configure the Router.
e The access mode is enabled for Console access by setting up two types
of password. The logon password allows non-privileged access to the
Router. The user enters privileged mode by use of the enable
command and an additional password.
¢ With SNMP access different community strings are used to
distinguish between non-privileged and privileged access modes.
Non-privileged access allows a host to send the Router SNMP
get_request and SNMP get_next_request messages. Privileged mode
allows the host to send the Router SNP set_request messages in order
to change the Router’s configuration and operational state.
6.6.2.1 Session Timeout values will be selected to limit the period of time
allowed for operation of a console in privileged mode.
6.6.3 Accesy Listy
The parameters to an Access List allow IP addresses to be specified along
with protocols (ip, udp, tcp and icmp) and port numbers.
6.6.3.1 Access lists will be used to define the actual traffic that will be
permitted or denied through a Router.
6.6.3.2 Only traffic associated with IP addresses that are explicitly defined in
Access Lists will be permitted.
6.6.3.3 Constraints associated with particular port numbers will be defined as
part of the network design.
6.6.3.4 Constraints associated with particular protocols will be defined as part
of the network design.
Access lists can be applied to specific interfaces and they can be used to
filter packets before or after routing decisions are made. The use of input
access lists can prevent specific address spoofing scenarios whereas use
of output access lists only does not.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 60 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
6.6.3.5 Input access lists will be used to ensure that filtering is enforced
before routing decisions are made. Outlet filtering will also be used to
ensure that valid ICL Pathway packets are not exposed (to say TIP etc)
when the same router is shared.
6.7 Control of Accesy to Firewolly
Firewalls will be used to protect the ICL Pathway system from
unauthorised access via external networks and other local networks
collocated at ICL sites.
6.7.4 Accesy Methods
ICL Pathway firewalls will be managed using Firewall Enterprise Centres,
one at each Data Centre, as described in [ACCPOL]. These reside on Sun
Solaris systems which will provide access controls as specified in section
6.5.2.
6.7.1.1 All access to the firewalls will be via the Enterprise Centre, except for
hardware maintenance.
6.7.1.2 As for routers, firewalls will not have consoles attached, except for
hardware maintenance purposes.
6.7.2 Accesy Listy
The parameters to an Access List allow IP addresses to be specified along
with protocols (ip, udp, tep and icmp).
6.7.2.1 Access lists will be used to define the actual traffic that will be
permitted or denied through a firewall.
6.7.2.2 Only traffic associated with IP addresses that are explicitly defined in
Access Lists will be permitted.
6.7.2.3 Constraints associated with particular protocols will be defined as part
of the network design.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 61 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Specificati
Date: 12/05/99
6.8 Control of Access te VPN Management
The VPN product includes a number of controls over the manipulation
of policy and other sensitive control information.
6.8.11 Access to VPN policy and other sensitive control information will be
confined to named users.
6.8.1.2 Access to sensitive operations will be confined to users with
administrator privilege.
6.8.13 Access to the VPN policy file will be limited, by the VPN product, to
the standard VPN policy editor.
6.8.1.4 Access to the VPN policy editor will be confined to nominated
privileged users.
6.8.1.5 All VPN access control features will be configured in accordance with
[ACCPOL].
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 62 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Date: 12/05/99
AUDIT AND ALARMS
74 Audit and Alarm Requirementy
The audit and alarm facilities provided by the ICL Pathway system must
satisfy the business level audit and security audit requirements of
“external” auditors (including DSS, POCL, NAO and the Authorities’
Auditors) and ICL Pathway’s “internal” monitoring (including Security
Audit and Fraud Risk Management).
The Audit Trail Functional Specification [AUDFS], which is primarily
concerned with addressing business level audit requirements, specifies
audit trails as three “tracks” (namely DSS, POCL and System
Management) that can be selectively viewed by the appropriate auditors.
7.2 Sources of Audit Eventy
Auditable events will be recorded in application level transaction logs
and lower level audit tracks*. Figure 7-1 illustrates the main sources of
system generated events.
PO Systems II Main NT Data II sequent Servers Other systems
Centre Systems
Applicati EPOSS Riposte utils, PAS, CMS, Cisco works,
plications Applications Agents DW, MIS ete Firewalls etc
Riposte, Oracle, FTF,
Middleware Riposte FTP ete Business Objects KMS
(System) Tivoli, Tivol Patrol, OpenView,
Management bootup s/w COS Manager ACE Server
NT Dynix UNIX, NT ete
Figure 7-2 Sources of Auditable Eventy
> An “audit track” is a record of activities made within a subsystem for one or more of
its interfaces (as defined in [AUDFS] ).
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 63 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Riposte provides an ideal basis for logging all transactions to give a
complete picture of actions within the Benefit Encashment Service and
Post Offices Infrastructure Service. It will be used within the POCL
Central Services and OPS Domains to provide a complete record of all
transactions.
Applications running on the Sequent servers generate logs of the
business transactions and file transfers. The Oracle databases, used for
CMS/ PAS, associated Help Desk applications, the Data Warehouse and
MIS, have the ability to audit security relevant events that are recorded
in tables.
Patrol will be used to monitor all Sequent systems and the Oracle
applications that run on Sequent platforms. The audit events and alarms
gathered by Patrol will be captured, for recording and analysis, via a
Patrol Tivoli event adapter (as outlined in section 11).
COS Manager will generate the main system level log on the Sequent
servers. All users logging onto Sequent at the operating system level (for
system administration, security management etc) will invoke COS
Manager, which will record their logon and subsequent actions selected
from its menus.
Windows NT can provide essentially the same audit capability for both
workstations and servers. These facilities are powerful but need to be
used with caution to avoid generating vast quantities of low level events,
which are difficult to analyse in a business context. Selective filtering will
be used to reduce the volume of events to be gathered, analysed and
stored.
Tivoli will be used to monitor selected Windows NT logs regularly and
picks up agreed event types for transmission to the Data Centre as Tivoli
events.
Wherever possible, application/middleware level auditing will be used.
Low level Windows NT audit tracks will, however, provide appropriate
facilities for auditing system management activity across the system.
7.3 Auditoble Eventy
7341 All events in the following categories will be capable of being audited:
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 64 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
¢ authentication actions (including logon, unsuccessful logon
attempts and logoff),
© exception conditions (detected by operating systems and at the
application level),
© system start-up and close down,
¢ change of user rights (including granting of additional privileges),
* write access to selected files,
© system management activities (including addition of new users and
reset of any user’s password).
7.31.2 Where there are multiple mechanisms capable of recording a
particular event, duplication will be avoided and the most appropriate
audit method will be used.
For example, within the OPS Domain, activities at Post Office
counters will be recorded in the TMS journal rather than the lower
level NT event logs. Similarly, within the POCL Central Services
Domain, Tivoli will be used to gather events for central analysis.
7.4 Application Level Audit
7.44 Generel Requirementy
7.441 The principal audit track associated with the DSS track will be the
TMS journal. This will be used to record data traversing between:
e PAS - TMS,
e CMS-TMS,
e BES - TMS, and
e Order Book Control Service (OBCS) - TMS.
7.4.1.2 The audit track will include the following:
¢ file receipt from/despatch to CAPS, including file sequence
numbers and record control totals,
¢ file receipt from/despatch to PAS/CMS, including file sequence
numbers and record control totals,
¢ control checkpoints and any restarts during file transfer operations
between CAPS and PAS/CMS,
e userid, date and time,
¢ all systems access, and
all exception conditions (e.g. file sequence or control total failures).
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 65 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
7.42 Audit ot the CAPS Interface
7.4.2.1 The audit track of transfers between CAPS and the File Reception
system will be held at the CAPS site of operation with a copy
transferred to ICL Pathway (at the site of PAS/CMS operation). All
other audit track data for BPS will be held at the PAS/CMS site.
7.4.2.2 For file based data transfers, the audit track will record:
* all transfers of files at entry and exit to BPS,
e all transfers between subsystems of the BPS, and
the processing of files.
7.4.2.3 Transactions recorded in the BPS audit track will identify the
auditable event itself, date and time, and the cause, effect and owning
organisation or individual, as appropriate.
7.4.2.4. The audit track will allow activities that utilise more than one of the
services to be traced from start to finish, or from an intermediate
point in any direction.
7.4.2.5 The audit track will provide information to allow the original
transaction to be recreated.
7.4.2.6 ICL Pathway will provide BA/POCL with access to the BPS audit trail
and facilities for its secure interrogation, in accordance with
[AUDPOL]. All accesses and retrievals will be conducted by ICL
Pathway at BA/POCL request.
It is anticipated that a suite of standard reports will emerge over a
period of time reflecting the retrieval requirements of BA/POCL
auditors.
TAB Audit Tracky within the Datohase
Audit information, directly related to actions upon the database, will be
held in a table within the Oracle database.
7.4.31 As payment authorisation data is transferred from PAS to TMS, the
transaction log database within PAS will be updated and new
authorisation records will be created within TMS.
7.4.3.2 When encashment or expiry transactions are transferred from TMS to
PAS, the PAS transaction log database will be updated.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 66 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
7-433 The scope of PAS and CMS extends to their respective help desks and
transactions handled in these sub-services will also be recorded in the
transaction log.
7.4.3.4 Within PAS each individual payment authorisation will be logged in
the database to support transaction level audit and reconciliation.
TA4 Riposte Transactiow Log
All transactions that pass through TMS will be recorded in the journal.
The journal will be maintained on magnetic media within TMS for a
period of (typically) 90 days. Following this, the journal data will be
archived to long term storage. The current or archived TMS journals can
be accessed to provide an audit track of all TMS transactions.
7441 For transactional-based data transfers, logging will be provided at the
message level.
7.4.4.2 All data captured at a Post Office counter, either as part of a counter
transaction (i.e. BA payment, Stamp sale) or as an administration
function (user log-on, teller balance), will form part of a unique
transaction that is given a unique reference number by Riposte.
7.4.4.3 The format of this journal entry will vary according to the transaction
type, [TED] but will typically contain:
© Post Office ID,
¢ Counter Position ID,
e Unique Transaction ID,
e Date,
e Time,
e User ID,
e Application, and
e Transaction Details.
7.4.4.4 Each counter PC will contain a journal and all journal entries will be
automatically replicated to all other members of the workgroup. This
will include remote Correspondence Servers that form part of the
TMS.
7.4.4.5 This Correspondence Server will in turn replicate all its transactions to
other Correspondence Servers located on different sites.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 67 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
7-4.4.6 A complete audit track of all transactions and other significant events
will be maintained for up to 90 days within the Post Office systems. It
can be extracted, when needed, for analysis.
7.4.4.7 All events that occur either in TMS or in OPS will be written to a
journal. The journal message content is identified in section 7.4.4.3.
TAS Logging iw Fall-back Mode
7.4.5.1 The audit track will be maintained during periods of fallback and
recovery.
7.4.5.2 The integrity of the audit track will be maintained during periods of
partial or complete service loss or failure. Starting and restarting
transactions will make appropriate audit track entries.
7.4.53 The distributed nature of the ICL Pathway TMS will enable an audit
track to be maintained and accessed during any recovery of a TMS
server.
7S Application Level Audit Analysiy
The tool set used to support audit analysis is expected to evolve as
experience is gained in analysis of the various logs. The basic tools will
include facilities to selectively read:
e TMS journals,
e Tivoli event data,
¢ Oracle database information (e.g. using Oracle forms),
¢ Windows NT event logs (for exceptional investigations), and
¢ any other sources of audit information.
The output generated by these tools will be a combination of standard
reports and ad hoc enquiries.
As the tools develop, the ease of use and format consistency of the
information reported is expected to improve.
7.5L Standard reports will include all exception events (e.g. sequence or
control total failures), plus daily/weekly/monthly control summaries.
7.5.1.2 PAS will produce a full set of operational and audit reports as specified
by the BPS MIS requirements [SADD].
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 68 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
7.513 PAS will provide secure access facilities to interrogate the status of all
payments from payment receipt to return of encashment or expiry
data to CAPS.
These enquiries will use the standard operational Help Desk facilities.
7.5.1.4 The PAS transaction log database and related MIS will be available for
access, subject to appropriate security clearance, by standard tools for
query, reporting and data analysis.
7.6 Protection of Audit Tracks
7-641 The audit track will have a level of security such that it cannot be
altered or deleted.
The journals will be written as append-only files, owned at the system
level and protected by the subsystem’s access control.
7.6.1.2 ICL Pathway will keep copies of vital files, including the audit track, at
the alternate central site or off site. The frequency of transferring
backup copies will be defined in [ACCPOL].
7.7 Audit of Systemy Management Functiony
The Systems Management function will provide the audit track with a
record of operational events, inventory, distribution and remote
operations.
7.7Ad The Systems Management Service will provide a repository for
recording all physical events affecting the platforms that support the
SIS, namely TMS and the OPS.
All these environments operate under Windows NT and will be
managed from the Tivoli SMS server. The Tivoli SMS will provide, in
conjunction with the native Windows NT and messaging middleware
services, a comprehensive facility for trapping, recording and
interrogating audit events relating to the operational status of the
hardware, software and applications running within the SIS.
7.742 The Tivoli notification features and Windows NT auditing will
support the recording of events such as which users access which
objects, what type of access in being attempted and whether or not
the attempt was successful.
Printed [DATE \1] COMPANY IN CONFIDENCE Page 69 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
7.713 Logging facilities supported by HP OpenView will be used provide a
record of network management actions.
An OpenView Tivoli event adapter will be used to map SNMP traps
into the central Tivoli Event server.
7.71.4 Administrative privilege will be required for controlling audit and
auditing policies within the Windows NT Registry.
VTLS Audit events will be viewed through the appropriate audit analysis
applications.
7.71.6 Replacement or modification of selected files containing security
critical code will be audited.
In particular, attempts to update or delete modules concerned with
integrity checking and crypto functionality will be monitored.
7.8 Windows NT Audit
This section provides an overview of the audit facilities provided by
Windows NT. It should be noted, however, that Tivoli will be used on all
NT platforms to provide central event management services derived
from the local mechanisms.
The local audit facility will collect audit records from several
components (including Riposte and local applications) in addition to
recording its own NT system events. Tivoli then picks up the NT logs
selecting the event to be collected according to the filtering criteria.
Girobank will not be using Tivoli directly but will use an alternative
which meets functional requirements.
7.8.4 Selection of Auditoble Eventy
For each audit category the selection criteria can include:
¢ audit successful events,
¢ audit failed events, and
¢ audit both successful and failed conditions.
The Windows NT Audit Policy dialogue box will be used to select from
the following auditable event categories:
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 70 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
¢ Logon and Logoff,
File and Object Access,
Use of User Rights,
User and Group Management,
¢ NT Security Policy Changes,
¢ Restart, Shutdown and System, and
¢ Process Tracking.
7.8.2 Audit of File and Directory Actiony
Appendix A lists the types of file and directory access that can be audited
and explains the meaning of each option.
7.8.3 Audit of Registry Actions
Appendix A lists the types of Registry access that can be audited and
explains the meaning of each option.
7.8.4 Audit of Printer Actions
The printer related actions that can be audited are defined in [WINNT].
7.4 Alorw Conditiony
Auditable events that require immediate investigation will be used to
trigger alarms in real time.
Events will be selected in accordance with ICL Pathway’s Security Policy
[SECPOL].
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 71 of 103
ICL Pathway
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Date: 12/05/99
This section describes the cryptographic functionality, within the ICL
Pathway system, used to protect:
e data on individual communications links, and
¢ individual messages from creation to use (end-to-end).
Key Management throughout will be performed as agreed with the
Contracting Authorities, based on advice from CESG. The special
requirements of roll-out are also covered.
Figure 8-1 illustrates the overall communications configuration to be
protected:
CAPS
t CAPS (and ESNCS) Link
. CAPS 4
' Access Service '
j : CMS Link
¥ v
Payment — I«---------------- Card Card
Management I----------------- >I Management Producer
nx aR
' ! PAS/CMS ! {Tiana
po Sere Help Desk ["77~ ‘Ref. Data POCL TIP
' ' Link
‘ t TIP and Reference Data
¥ ¥ HAPS
i Link
Central Services ‘inl POCL HAPS
t SM/SIS Links t ISDN Link t \ [AP Data (Into)
System sis Post Office POCL
Management Help Desk Counter PC(s) I apctientI AP Clients
vaneeawn Links
LAN connected when AP Data Fats)
than one PC
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 72 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Figure 8 - 4 Linky for Protection
The link protection mechanisms, described in the following subsections,
incorporate the changes needed as a result of moving to the Energis
ATM network.
For each client, ICL Pathway will implement link protection as each
client interface is agreed.
g.4 CAPS (and ESNCS) Linky
8.2.14 Overview
These are the links used to transfer files, containing mainly payment
authorisations, stop notices and customer personal details (including
instructions to bring customers onto the service), from BA’s CAPS
system to ICL Pathway’s CAPS Access Service (CAS). Information sent
back from ICL Pathway to CAPS will include benefit encashments and
expired payments.
8.11 The Electronic Stop Notice Control System (ESNCS) used by the
Order Book Control Service (OBCS) will use one of the CAPS links.
8.1.2 Protectiow
The protection on the CAPS link is aimed at reducing the financial risk
to ICL Pathway and the Contracting Authorities.
The purpose of this protection is integrity and origin authentication.
8.1.2.1 Cryptographic integrity protection will be provided on the link from
BA’s CAPS system to ICL Pathway’s CAPS Access Service.
8.1.2.2 ICL Pathway will verify that each file origin is an agreed BA location.
8.1.2.3 Protection will be provided by the production, at the CAPS end, of a
Red Pike encrypted trailer, the Red Pike algorithm being implemented
in software.
The encrypted trailer is constructed from:
e file header information identifying the file’s origin,
¢ fields of the normal trailer, including the sets of totals for financial
fields in the file,
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 73 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
¢ aCRC over the whole file, and
¢ a CRC over the fields above.
The encrypted trailer is sent with the file to the CAS components at
each ICL Pathway Campus where it is decrypted and the totals, header
information and CRCs verified to be correct. The Red Pike decryption
is also performed in software.
No protection is provided on files sent from ICL Pathway to BA
locations on the CAPS link.
8.1.2.4 Rambutan hardware capable of supporting ATM and Frame Relay
communications is not currently available. When such a solution
becomes technically and commercially viable, it will be implemented.
8.1.3 Key Management
8.13.4 The Key Custodian will load the key locally at the Series 39 (VME) end
of the CAPS link and remotely at the Sequent end of the CAPS link.
8.1.3.2 Keys will be stored in a file with file access restricted by use of the
operating system access controls. Read and modify access will be
permitted for the approved custodian with no access permitted for all
other users.
The cryptographic functions on each machine will run in privileged
mode.
8.1.3.3 Key changes will be performed at intervals agreed with the
Contracting Authorities, based on advice from CESG, for integrity
protection.
8.2 CMS Linky
These are the links used to transfer card production data and PUN
information to the card producer.
8.2.4 Protection
There is no explicit Contracting Authority requirement for protection of
CMS links. The protection defined here is solely aimed at reducing ICL
Pathway’s financial risk.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 74 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
8.2.41
8.2.1.2
8.2.1.3
8.2.1.4
8.22
8.2.2.1
8.2.2.2
8.2.2.3
8.3
All data on CMS links will be encrypted, for confidentiality and integrity,
using Red Pike. This enables ISDN lines to be used rather than dedicated
links.
Protection will be provided at application level using bespoke
development incorporating the Red Pike algorithm.
At the ICL Pathway end, the CMS file will be transferred to a Windows
NT platform where the entire file will be encrypted using Red Pike.
The file will be transmitted to the target CMS, where it will be
decrypted again at application level.
The use of Windows NT platforms at each end of the link allows reuse
of crypto functionality.
Decrypted files at the target CMS will be validated to ensure that only
integrity checked data is used for card and PUN production.
Data transferred from CMS to ICL Pathway will also be protected,
using Red Pike, and validated before use.
Key Management
The Red Pike keys will be installed into the ICL Pathway server and
DLR server.
The keys will be loaded locally by the Key Custodian.
The keys will be loaded locally from diskette at system start-up,
directly into memory. They will not be stored persistently in a disk
file.
The Windows NT platforms used will be located in physically
protected environments.
POCL TIP (and Reference Data) Link
These are the links used to transfer information to/from POCL. They
carry the entirety of POCL’s outlet transaction business and stock data,
plus reference data back to ICL Pathway. There is an explicit Contracting
Authority requirement for integrity protection of this link, in addition to
the end-to-end protection of AP records, as defined in section 9.4.
Printed:
[DATE \I] COMPANY IN CONFIDENCE Page 75 of 103,
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
8.3.1 Protectiow
8.3.44 DSA signatures will be used to protect the integrity of data transferred
on this link in both directions. This protection will also be provided
for traffic to and from the disaster recovery site.
8.3.1.2 Verification will be done by validating the incoming public key
certificate against a CA public key using a pre-installed key stock at
the receiving PC, then validating the file’s signature using the public
key in the certificate.
8.3.1.3 The same end-to-end integrity protection will be used, where
appropriate, to protect other low volume data such as Post Office
reconciliation totals.
8.3.2 Key Management
8.3.2.1 The private signing key will be managed in two parts that must be
combined before either part is of any value.
8.3.2.2 Key distribution is effected by transmitting one of the parts
electronically and the other by diskette. The part sent electronically is
held on filestore. At each system start-up, the diskette part is
introduced by the key custodian and combined with the filestore part
to create the key in memory.
8.3.2.3 The full key will not be stored persistently on a disk file.
8.3.2.4 Each end will have a different signing key.
8.3.2.5 The keys will be changed at intervals agreed with the Contracting
Authorities, based on advice from CESG.
8.4 POCL HAPS Link
The link between ICL Pathway and the Host Automated Payments
System (HAPS) is an interim solution, whereby all AP data will be sent to
an existing POCL Tandem system sited at Farnborough. This HAPS
system is then responsible for onward routing the data to their AP
clients.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 76 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
This file transfer product will run on a dedicated ICL Pathway Windows
NT platform at each campus and POCL’s Tandem AP Host. Windows NT
platforms will be used, rather than Sequent, to avoid adding complexity
to the Sequent systems.
8.4.2 Protection
8.4.44 Confidentiality and integrity protection is provided for this POCL
Farnborough link using Rambutan based encryption hardware.
8.4.2 Key Management
8.4.2.1 The standard key management facilities, provided by the bought-in
devices, will be used.
B.S POCL AP Client Linky
8.5.11 Files transferred on these links will be digitally signed by the
transmitting PC, providing authentication and integrity protection.
The signature will be DSA, done using a private key owned by the ICL
Pathway PC transmitting the file. The file will be accompanied or
preceded by the public key certificate needed to verify the signature.
The above includes both files sourced by ICL Pathway and files sent
out that were generated from data received from the POCL HAPS link
during the period of cut over from HAPS to direct client
communication.
8.5.1.2 Not all receiving clients will choose to validate the signatures, but for
those that do wish to do this, ICL Pathway will provide the CA public
key stock needed to validate the certificates.
8.6 Post Office Lurky
These are the links from the POCL Central Services Domain to the Post
Offices.
8.6.1 Protection
8.6.11 The protection will ensure the authenticity of the parties to every
communication session over the Post Office Links.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 77 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
8.6.1.2 Concealing data from eavesdroppers is not a primary objective of this
protection (unlike other forms of protection that may operate within a
communication session).
8.6.1.3 A specific Post Office will become a member of the VPN community
as a result of the initial key distribution prior to auto-configuration
phase of rollout. A commercial VPN product will be used to support
this,
8.6.1.4 Inbound ISDN calls (PO Outlet to Data Centre), will be validated at
the BT / Energis Interchange prior to onward transmission to the Data
Centres. CLI will not be validated outbound to the Post Office Outlet.
8.6.1.5 Where symmetric encryption is used, it will employ the Red Pike
algorithm.
8.6.1.6 Where asymmetric encryption is used, it will employ either the DSA
algorithm or, if embedded in a bought-in technology, RSA.
8.6.1.7 A Virtual Private Network (VPN) will be established to enable Post
Offices to communicate with the campuses. The VPN members will be
the Post Offices and a set of central VPN servers.
8.6.1.8 Communicating entities will be authenticated as valid members of the
VPN community by mutual cryptographic challenge and response
based on asymmetric keys.
8.6.1.9 As a result of successful mutual authentication, the parties will
establish a shared secret symmetric key for the duration of the
session.
8.6.1.10 Continued authentication will be achieved by using the session key to
encrypt all transmitted data. During a session, all data, both Riposte
and Network, travelling across the link will be encrypted as an added
value consequence of using VPN technology.
8.6.2 Key Management
8.6.2.1 At routine intervals, similar to those used for other key material, the
VPN keys at each Post Office will be replaced by new values.
8.6.2.2 The KMS will deliver replacement VPN keys to the Post Office under
the additional protection of a communication key established with the
help of Diffie-Hellman exchange. This protection is over and above
the incidental encryption afforded by the VPN.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 78 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
8.7 Post Office LANy
These are the LANs that connect multiple-workstations in the larger
Post Offices.
8.7.4 Protectiow
There is no link level protection on these LANs.
Key material that needs to be transferred between Post Office PCs will
be passed either using the Post Office Manager’s Memory Card or via
Riposte messages encrypted under a key carried on the Memory Card.
8.7.4.1 Payment Authorisation and AP messages will have the digital
signature applied on their respective source machine (hence they will
be integrity protected over the LAN).
8.7.2 Key Management
8.7.2.1 The Post Office Manager (or other individual authorised to access the
Memory Cards and the associated PIN) has to be present in order to
successfully start up a workstation at a Post Office, since the card is
the only repository at the Post Office for the filestore encryption key.
To authenticate, the Post Office Manager signs on presenting
credentials. These are held, protected by PIN (containing 64 bits of
entropy) ona read-write Memory Card.
8.7.2.2 Keys will be replaced at a Post Office, by a routine key refreshment
procedure, at intervals agreed with the Contracting Authorities, based
on advice from CESG.
This involves the KMS initiating the same protected Diffie-Hellman
exchange as was done at roll-out, to establish key values used to
protect the new key material. . When required, the POM is alerted to
insert his Memory Card into the Gateway PC to pick up the new key
material, and to move from PC to PC in the Post Office, propagating
the values to the other PCs, where the key material from the Riposte
key distribution messages is also decrypted and installed as
appropriate.
8.7.2.3 If the Post Office Manager forgets the PIN or the Memory Card is lost
or damaged, recovery will be achieved as follows:
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 79 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
e the Post Office Manager will verbally authenticate to the Help
Desk,
e the Help Desk will authorise the KMS to send a special recovery
key package to the Post Office. The package contents will be
similar to the key material issued during a routine key change,
but the keys will be the existing ones,
¢ the KMS will send recovery information to the Post Office using
the Post Office link as a (virtually) normal routine key
refreshment procedure, and
e the material will then be loaded onto a new Memory Card for
which a new PIN is dynamically generated.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 80 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Specificati
Date: 12/05/99
8.8 RoU-ouwt to Post Offices
8.8.1.1 Every PC will either be preloaded with the CA public keys it needs, to
verify any public key certificates and revocation lists transmitted to it,
or they will be transmitted to the PC during the roll-out process and
verified for their integrity prior to use. Other public key material will
be transmitted during the roll-out process.
8.8.1.2 With the exception of the CA keys, changes can be made if necessary
through a routine key refreshment procedure. The same procedure
will be used to verify that the CA public keys held at the Post Offices
have not been tampered with.
8.8.1.3 At roll-out, during auto-configuration, the KMS will form an
interactive connection with the Post Office in order to establish an
end-to-end communications key with the Post Office Gateway PC.
The Diffie-Hellman exchange used has been extended to protect
against man-in-the-middle attacks.
8.8.1.4 The communications key will be used to encrypt confidential key
material sent to the Post Office.
8.8.1.5 A specific Post Office will become a member of the VPN community
during the auto-configuration phase of the roll-out process, following
the initial boot server exchanges. A commercial VPN product will be
used to support this.
8.8.1.6 The presence of the global public key and certificate material in a key
package sent to the Post Office allows pre-KMS Post Office PCs to be
upgraded to the full solution design by transmitting the necessary key
material to them via this key package.
In a multi-workstation Post Office, relevant key material from the
package will be passed on, by the Post Office Manager (POM), to all
workstations. The mediums used to transfer keys will be the POM’s
Memory Card and message replication.
8.8.1.7 All keys issued to Post Offices will be generated by the KMS (using
cryptographic quality random numbers provided by a hardware
supported random number generator). Active keys will be changed at
intervals, as agreed with the Contracting Authorities, based on advice
from CESG.
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 81 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
8.4
8.9.4
8.9.14
8.9.2
8.9.2.1
ICL Pothway Inter-campuy Linky
These are the links between the two ICL Pathway campuses, illustrated
in figure 8-7.
DSSIBA Sites
{ Livingston} [Washington } { ‘Swindon I [ Norcross }
SS \
2Mbps 2Mbps,
2aNbps
2ahtops
24Mbps 34hops
Bootle Wigan
34Mops
3ANops
Energis
: 4 Network
aN
Mops SS 2Mops.
Pool TP and
Reteence Daa) POCL Sites
Figure 8 - 7 Inter-Campuy (and other Inter-site)
Linky
Protection
The physical characteristics of the high-speed connections between the
campuses give a significant level of inherent security. There is, currently,
no hardware available that could provide link level protection on these
links.
Any key material passed between the Key Management Systems on
the two campuses will be encrypted under Red Pike using a key
shared between the two KMSs.
Key Management
The KMS to KMS key will be established automatically using an
exchange protected by the DSA private keys owned by the KMSs.
Printed:
[DATE \I]} COMPANY IN CONFIDENCE Page 82 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
3.10
8.10.4
8.10.11
8.10.2
8.10.2.1
8.10.2.2
8.10.2.3
8.10.3
8.10.3.1
SIS Help Desk and System Management Linky
Overview
In addition to the ICL Pathway inter-campus links (described in section
8.9), there are a number of dedicated links into campuses that need to
be protected. The network configuration is illustrated in [TED].
All links from the ICL Outsourcing sites to the campuses will be
encrypted.
Protection
System modifications (e.g. fault reporting) will be done through SIS. SIS
authentication will, therefore, be strong and proofed against
eavesdropping.
All data will be encrypted for confidentiality and integrity using
bought-in Government approved point-to-point encryption devices
employing the Rambutan algorithm (see section 4.5.3).
System management functions, which could cause changes to security
sensitive data on campus machines forming a serious security threat,
will be protected.
The risks will be considerably reduced by permitting only the
activation of pre-authorised fixing scripts and pre-defined Oracle
Forms. The scripts used will be stored away from the management
workstation.
A combination of integrity protection and the use of one-time passwords
provides the basic mechanisms.
Key Management
The standard key management facilities, provided by the bought-in
devices, will be used.
Printed:
[DATE \I]} COMPANY IN CONFIDENCE Page 83 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
8.11
8.41.1
8.4.4
8.0.1.2
8.1.1.3
8.11.1.4
8.41.2
8.0.2.1
8.41.3
8.1.3.1
3.12
Links with ICL Pathway Headqueartery
Overview
There will be dedicated links into the campuses sites from the ICL
Pathway Headquarters.
All links from the ICL Pathway Headquarters site to the campuses will
be encrypted.
The System Support Centre (SSC) and Roll-out Database systems will
have controlled access.
The Fraud Risk Management (FRM) On-line Analytical Processing
(OLAP) and Oracle Financials connections will only provide client
access to the respective applications that run on the Management
Information System(MIS).
The SSC and Roll-out Database platforms will use a different LAN
segment from that used by the FRM, OLAP and Oracle Financials.
A router will be used to prevent access between the two LAN
segments. The network configuration is illustrated in [TED].
Links used by ICL Pathway to retrieve Track and Trace data from the
Royal Mail will not be protected. The ISDN dial-up, initiated by ICL
Pathway will be to a dedicated PC at the Royal Mail site at Chesterfield.
Protection
All data will be encrypted for confidentiality and integrity using
bought-in Government approved point-to-point encryption devices
employing the Rambutan algorithm (see section 4.5.4).
Key Management
The standard key management facilities, provided by the bought-in
devices, will be used.
Key Generation
Cryptographic keys will be generated in one of the following ways:
Printed:
[DATE \1] COMPANY IN CONFIDENCE Page 84 of 103
ICL Pathway
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
8.12.11
8.12.12
8.12.13
8.12.1.4
8.2.1.5,
Where government approved hardware devices are purchased, key
material will be provided in whatever standard approved way is
normally recommended for that product.
Keys generated in bulk for use by Layer 7 crypto routines will use
entropy sourced from an entropy generation product using hardware
generation. This product will perform its own randomness assurance
procedures. It is being evaluated by CESG for government approval. In
the meantime, ICL Pathway will provide independent software logic
that will spot check for continuing quality of output, independent of
the product’s own checks.
The entropy will either be directly used as a Red Pike key or will be
passed to approved Layer 7 routines to generate private/public key
pairs.
The variation of Diffie-Hellman that will be used is the Thames Bridge
key management algorithm, which is provided by the government
approved crypto infrastructure in use by ICL Pathway. At a Post office,
Thames Bridge generates its own entropy using approved algorithms.
Smaller quantities of keys for use with the Layer 7 crypto routines will
be generated using the approved Layer 7 key generation functions and
the entropy they supply.
Printed:
[DATE \I]} COMPANY IN CONFIDENCE Page 85 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
q. MESSAGE PROTECTION
ad Technology
Unless otherwise stated, all message protection will be performed using
DSA with a 768 bit modulus. Each DSA signature requires a
cryptographically strong random initialisation value, known as a K-value.
Entropy for K-values will be generated internally where they are needed
(in the Post Office PC, the KMS or in the Tivoli signing system).
V2 Key Management
9.24 Public Key Technology
Standard simple public key technology will be used, as outlined below.
Under public key technology, protected messages are digitally signed by
a private key and validated using the private key’s matching public key.
Working public keys are distributed either at roll-out or by a KMS in
public key certificates (“PK certificates”) signed by a private key from a
Certification Authority (CA).
The “CA private key” will have a corresponding public key called the “CA
public key”.
4.2.2 Public Key Certificates
ICL Pathway’s “PK certificates” will be based upon the X.509 standard.
9.2.2.1 PK certificates will contain the public key, the name of the possessor
of the corresponding private key, an expiry date and key and
certificate identifying information.
9.2.2.2 The CA private key will be held securely on a PC in a secure room not
connected to the ICL Pathway network.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 86 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
9.2.2.3 All digital signatures will be verified using public key certificates
either transmitted with the signed data to be validated or already
available to the verifier. Public key certificates will be checked to
ensure that they are not expired and that they have not been revoked.
Where relevant, the certificate owner will be checked against the
claimed origin of the data that is signed.
WB BES Payment Authorisationy
9.344 Payment authorisations will be digitally signed on leaving the
PAS/CMS machine. Signatures will be verified immediately prior to
use by the BES application in individual workstations at the Post
Offices.
9.4 Automated Paymenty
9.441 Transactions digitally signed at Post Offices will be signature verified
at the harvesting agent that takes the transaction from the
correspondence servers and transfers it to the AP host. The signature
will not be carried forward into the AP Host database since this would
more than double the size of the database. Direct protection of the
transactions resumes when files containing AP transaction records are
digitally signed prior to transmission over links to POCL AP clients
(see Section 8.5).
For new integrity-critical products, the same overall architecture will still
hold. It entails signing in the Post Office, verifying at the harvester, and
integrity protecting complete files of transactions for validation at the
client-end PC.
9.4.1.2 Post Office private AP signing keys will be replaced at intervals agreed
with the Contracting Authorities, based on advice from CESG, using
the routine key replacement mechanism.
ws Softwore Distributed to Post Officer
New software releases will be distributed to Post Offices over
communications links from the central campuses.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 87 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
9S Two
9.5.1.1 All messages initiated by the Tivoli management mechanism will be
digitally signed, for protection in transmission, using the Software
Issue Private Key (SIPR) and verified on receipt using the
corresponding Public Key (SIPU). The signature will use 768 bit DSA.
9.5.2 Riposte
9.5.24 All software used via the Riposte desktop will be digitally pre-signed
off-line using the RSA algorithm and validated by Riposte every time
the desktop is loaded. The key size will be 512 bits.
9.5.2.2 The private key used in the signature will be held in a high security
environment at an ICL Pathway central site.
This protection regime will use standard Microsoft cryptographic
interfaces.
9.5.2.3 The Riposte code (developed by Escher) allows digitally signed
applications to be produced either by Escher or by authorised
signatories.
ICL Pathway is an authorised signatory, hence ICL Pathway’s public
key will be acceptable in the Riposte verification logic.
9.5.3 Protection of Non-desktop Software Resident ow Post
Office PCy
9.5.3.1 This is provided indirectly by the absence of a means of introducing
software by other than over the communications link to ICL Pathway,
and by preventing modification through local interfaces by
disallowing those functions.
9.5.3.2 Software whose functionality is confidential can be nominated to be
protected while on filestore by including it in a library marked to be
encrypted.
4.5.4 Protection for Siemens Metering Code and Date
The statements below highlight the main features that provide
protection on the live system to the counter application code and data
from Siemens Metering at Post Offices and during delivery to Post
Offices.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 88 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
A full set of statements on security objectives and methods for the
protection of this Siemens Metering material is given in the contract
controlled document [STAT].
9.5.4.1 Siemens Metering software and data will be encrypted on receipt and
will stay encrypted until installed at a Post Office.
9.5.4.2 Installed Siemens Metering software will be held in encrypted
filestore.
9.5.4.3 The key needed to decrypt uninstalled Siemens Metering software and
data, and the key needed to activate the application, will be encrypted
prior to transmission to Post Offices along the communications links
from the ICL Pathway central campuses.
95:44 Updates and bug fixes to Siemens Metering software will be integrity
protected under a digital signature.
9.5.4.5 Updates and bug fixes to Siemens Metering software will be encrypted
over the link between the central campus and the Post Office.
9.5.4.6 Compromise of a Post Office Manager's Memory Card and PIN will
not by itself cause compromise of Siemens Metering key material.
9.5.4.7 No authorised means of locally introducing code to Post Office PCs
will be provided.
9.5.4.8 No authorised direct local access to NT operating system functions on
Post Office PCs will be provided.
9.5.4.9 ICL Pathway key values used to protect Siemens Metering code, data
and keys, will be changed at a frequency in accordance with HMG
recommendations.
9.6 Other Message Types
Key Package messages sent from the KMS will be protected under a
communications key dynamically established between the KMS and the
Post Office (as described in Section 8.6).
Printed [DATE \1] COMPANY IN CONFIDENCE Page 89 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
10.
10.1
10.2
FILESTORE ENCRYPTION IN POST
OFFICES
Date fs ential
Nominated files on Post Office workstations and gateway machines will
be automatically encrypted at disk access level to preserve data
confidentiality in the event of the workstation being stolen. The parts
that will be encrypted are:
e the Windows NT swap file,
e the Riposte journal and any related working files,
selected files containing the cryptographic keys held by the
workstation, unless they are protected as part of the key management
design,
e selected counter application code libraries, as required by the
application providers, and
e selected counter application data files as required by the application
providers.
The whole of the swap file will be encrypted prior to the loading of any
externally supplied key material. The key used will be internally
generated by the TeamCrypto product using its own entropy, and will be
different for each boot-up of the PC.
The algorithm used will be Red Pike.
Functi .
None of the NT workstations installed in Post Offices will have operable
floppy disk drives (since, if fitted, they will be physically blanked off and
disabled in the BIOS). The workstations will be rolled out to the sites
with the majority of the software, including the crypto software, pre-
configured in the factory.
The delivered configuration of a particular workstation type (e.g.
gateway or non-gateway) will be the same, whatever Post Office it is
being delivered to.
Printed:
[DATE \1] COMPANY IN CONFIDENCE Page 90 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Protection will be applied after delivery on site.
The Post Office Manager (or authorised representative) will be the only
person on site who has the means of unlocking the key to the filestore
encryption. He/she is not, however, required to be IT literate since the
procedures used will be straightforward and well documented.
In general each workstation will be used by a different counter clerk who
will use other authentication data to sign on to the workstation. Counter
clerks cannot unlock the filestore without assistance from the Post
Office Manager. Typically, a workstation may be left running all day but
counter clerks will sign on and off at more frequent intervals.
10.3 Security Considerations
Some basic security considerations of the solution are:
10.3.1.1 The KMS will be the source of the keys for all files except the swap file,
for which a new key will be dynamically established on each PC on
each boot-up.
10.3.1.2 The product used will be Team Crypto, for which CESG approval is
required.
10.3.1.3 The Post Office Manager sign-on will be used to unlock the filestore
(on power on) so that normal counter clerks can then sign-on to the
workstation.
It is inevitable that, across the large number of Post Offices involved,
some Post Office Managers will forget their password, lose or damage
the token needed to authenticate and unlock the filestore.
10.3.1.4 Means will be provided to enable the filestore to be unlocked securely
by a central authority.
More detail is given in Section 8.7.2.3.
10.3.1.5 It will be possible, at intervals agreed with the Contracting
Authorities, based on advice from CESG, to change the filestore
encryption key.
The Post Office Manager will also be able to change his/her
authentication information (e.g. password or token).
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 91 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
41.
41.4
41.4.4
ADMINISTRATION OF SECURITY
Administration of security is largely concerned with management and
operational controls but there are also supporting technical controls that
will be implemented.
System management facilities will preserve the integrity of the system
and contribute towards achieving high system availability. The software
distribution facilities, in particular, will incorporate mechanisms for
integrity protection of all files/modules distributed to end systems.
User management will be distributed because the bulk of the user
population will be managed as small groups local to each Post Office.
Management Roley and Responsibilitiey
ICL Pathway’s Security Policy [SECPOL] contains a definition of
responsibilities for security within ICL Pathway.
The ICL Pathway Access Control Policy [ACCPOL] will contain a
detailed definition of roles and responsibilities for all personnel who will
have any kind of access to the services provided by ICL Pathway.
The following subsections provide a simplistic overview of the
operational, system management and support roles, based upon the
initial pilot system(s).
Operational Roley
The operational roles will comprise the “users” of the system in its
operational state, as follows:
BA (ICL Series 39 system) operations (EDS),
PAS/CMS Help Desk Advisor (ICL Pathway/Girobank),
DLR CMS operations (De La Rue),
Post Office Manager (POCL), and
Post Office Counter Clerks (POCL).
A PAS/CMS Help Desk hierarchy of Manager, Supervisor and Advisor
will be used.
Printed:
[DATE \I]} COMPANY IN CONFIDENCE Page 92 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
The DLR CMS operations personnel, located on De La Rue premises, will
use the output from CMS for the production of cards and generation of
Pick-Up Notices (PUNs).
A distinction will be made between the Post Office Manager and Post
Office Counter Clerks.
11.1.2 Systemy Management Roley
The system management roles will be assigned to personnel who keep
the system running for the “users” in the operational roles. In simple
terms, these are the roles for which ICL Outsourcing will have main
responsibility, as follows:
¢ System Manager (ICL Outsourcing),
e System Operator (ICL Outsourcing),
¢ Database Administrator (ICL Outsourcing/Oracle),
e Network Manager (ICL Outsourcing), and
¢ Encryption Key Custodians (ICL Outsourcing, EDS and DLR).
Encryption key custodians will have responsibility for the use and
safekeeping of encryption keys. These keys will be used to enable the
Rambutan based encryption devices at each site. For simplicity, ICL
Outsourcing will manage all keys used in ICL Pathway’s central Data
Centre site. EDS are expected to manage the keys at the BA end of the
CAPS links and De La Rue will manage the keys used at their Card
Production sites.
11.1.3 Support Roley
The support roles will be primarily concerned with keeping all
equipment operational. These activities, which include monitoring and
exception handling, will be supported (primarily by ICL Outsourcing,) as
follows:
e Support Manager,
¢ Support Engineer,
e Support Help Desk, and
¢ Installation Engineer.
11.2 Systewy Management Componenty
Systems management services will be based upon three main products,
namely:
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 93 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
¢ Tivoli (with Courier, Event Console, Platform and Inventory),
e HP OpenView, and
¢ Patrol.
Tivoli will handle all services on NT systems, software distribution to
UNIX systems and central event management services.
HP OpenView (with Cisco Works) will provide network management
facilities and all services to the router community.
Patrol will be used to manage all Sequent systems and the Oracle
applications that run on Sequent platforms.
11.2.4 Twolt
The Tivoli Management Environment (TME) is a management
environment that will be used to provide application services and
applications for client/server systems management.
Within TME, Tivoli provides applications that support:
¢ deployment management - involving installation, configuration, and
control of all resources,
¢ availability management - involving local monitoring and local
automation, and
¢ centralised event-based operations management - that enables
system-wide monitoring, job scheduling, and system backup.
The foundation of TME is the Tivoli Management Platform (TMP) that
will provide all the common services and integration between TME
applications via an open API.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 94 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Specificati
Date: 12/05/99
UNIX ( Sequent) NT Server ( Intel)
~ Platform Platform
~ Courier - Courier
Patrol
I Inventory
‘
1
1
1
'
1
= Sentry t
Inventory 1
1
1
1
1
1
1
,
- NT Event adapter
Router
CENTRAL SITE
ISDN network
- Platform
- Repeater (configuration)
NT workstation lCourer
(intel) = Sent
plus ISDN card = = Inventory
- NT Event adapter
Platform
NT Workstation gg Sourier
(Intel) =!
Figure 14-1
Producty
Tivoli products will be deployed as illustrated in figure 11-1.
U.2.11 The System Management (SM) infrastructure, provided by the Tivoli
platform, will be Object Management Group (OMG) Common Object
Request Broker Architecture (CORBA) compliant.
A Tivoli event adapter will be used to map Simple Network Management
Protocol (SNMP) traps to the central Tivoli Event server. Similarly, a
Patrol Tivoli Event Adapter will map Patrol events to the Tivoli Event
server. Event management on Oracle will use Patrol.
11.2.2 HP OpenView”
HP OpenView will be used to provide the network management service.
11.2.3 Patrot
Patrol will be used to manage the Sequent platforms and the Oracle
applications that run on those platforms.
11.3 Systems Management Servicey
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 95 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
11.3.4
1.341
1.3.1.2
The services provided will include:
¢ Software Distribution - using Tivoli Courier,
¢ Event Management- using Tivoli Event Console and Patrol,
e Network Management - using HP OpenView,
¢ Resource Monitoring - using Tivoli Sentry, and
e Inventory Management - using Tivoli Inventory.
key
” Tivoli Managers
Events only
Events and
resource state
information
HP OpenView
Correspondence Oracle :
L_& Servers (Unix) Routers
' Software Distribution oounter.
' (Recipients) ommunity
Figure 11-2 Systems M
The three system management products (described in section 11.2) will
be combined as illustrated in figure 11-2.
Softwere Distribution
The task of managing a distributed, multi-platform system requires an
efficient method for distributing, installing and controlling software
throughout the network.
The Tivoli Courier management application will provide the means of
managing and distributing software across a multi-platform network
that includes Unix machines and Windows NT platforms.
The software distribution system will be used to manage end systems
in order to distribute, activate and delete software products.
Tivoli will run within the authentication and access controls specified
in earlier sections of this document.
Printed:
[DATE \1] COMPANY IN CONFIDENCE Page 96 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
1.3.1.3 Tivoli Courier will provide a full audit track of all distributions.
This will indicate whether distributions were successful and whether
any failures occurred. The time of successful distributions/failures will
also be included together with identification of the individual who
initiated the distribution.
Pre-requisites for software distribution, to maintain system integrity, are:
* anaming scheme for identifying the product(s) concerned,
e the ability to define a software product in terms of its constituent
files,
¢ scripts to perform the installation (and removal) of the product,
¢ criteria by which it can be asserted that a software product is
installed,
¢ aclear definition of the managed system(s), and
¢ identification of the managed network routes to the system(s).
This supporting infrastructure will also provide:
¢ ascheduling infrastructure enabling operations to be executed at a
defined time, and
© a reporting infrastructure to inform the central systems of the
outcome of operations.
The four stages in the release management process, which includes
package distribution, are illustrated in figure -3.
Printed: [DATE \I]} COMPANY IN CONFIDENCE Page 97 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Specificati
Date: 12/05/99
Package Package i,
Creation }4I Distribution Installation Commit
Specify files and Efficient, reliable File Package ‘Synchronized
directories to be distribution of fle installed commit of new
distributed packages release
Integration with Robust recovery Removal of old
Source Code from network and release of
Control tool system failures software
Scheduled
distributions
Multiple
distribution modes
Figure 14-3 Release Management
11.3.2
1.3.2.1
11,3.2.2
Process
Tivoli Courier will provide the ability to run programs:
¢ before or after distributing new software,
¢ immediately (when Commit is specified), or
¢ after removing old software.
These features will be used to provide efficient and reliable installation
of new software releases.
Event Management
Event Management is the ability to take events from one or more
sources, use defined rules to establish whether local actions need to be
taken and/or whether notification is to be forwarded to central event
servers. Sources of such events will include applications and the
operating systems.
Wherever possible, existing technology for handling events will be
used, with the events mapped into a normalised form for handling by
the central event manager.
The event logs used by Windows NT will be integrated with the
system management components.
Printed:
[DATE \1] COMPANY IN CONFIDENCE Page 98 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
1.3.2.3
11.3.3
11.3.4
1.3.4.1
11.3.4.2
Network components, which emit events as Simple Network
Management Protocol (SNMP) traps, will be integrated with the
system management components.
Network Management
Network management will be run from a central service providing
facilities for:
¢ reporting and diagnosing network events,
¢ consolidating and interrogating statistics, and
¢ controlling the configuration and parameter settings on network
devices.
The global system will be divided into three levels for network
management purposes:
1. The backbone network - comprising the LAN hubs and LAN
attachments at the ICL Pathway central sites, the links between the
ICL Pathway sites, links to DSS and POCL, with associated routers.
2. The branch ISDN network - terminated at the central routers and at
the gateway PC at each outlet.
3. The office LAN at each outlet - comprising the PC LAN attachments
and local Ethernet hub (present where three or more PCs are
installed).
Management of the underlying ISDN switched circuit network will be
provided by British Telecom. It is envisaged that the implementation of
Network Management will include interfacing to the Network service
supplier to obtain a structured data feed regarding the state of the whole
network including ISDN.
The network management facilities will be based primarily upon the use
of SNMP mechanisms, with additional facilities provided across the
ISDN network at platform level via the Microsoft NT event system and
associated middleware.
Resource Monitoring
The resource monitoring facilities will be used to establish criteria for
monitoring an individual resource.
When resource monitoring criteria are met, they will trigger pre-
defined local action and/or generate an event.
Printed:
[DATE \1] COMPANY IN CONFIDENCE Page 99 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Specificati
Date: 12/05/99
Typically, notification would be provided when available free disk
space has reached an appropriate threshold.
11.3.5 Inventory Management
1.3.5.1 The Tivoli Inventory application will be used to manage the software
and hardware inventory.
1.3.5.2 A central repository will hold persistent records identifying the
software products installed on each managed node.
1.3.5.3 The data recorded will be obtained by evaluating the software
signature for each software product on the managed nodes.
1.3.5.4 The central repository will hold persistent records identifying the
hardware associated with individual managed nodes and its attached
peripherals.
1.3.5.5 Where appropriate, asset numbers will be held for the individual
components.
11.4 User Management
The user management facilities provided by Riposte, and its associated
applications, will be used to manage all Post Office users within the OPS
Domain. For all other users, facilities provided by the standard COTS
products will be used for administration tasks.
41.4.4 Administration of User Accounty
The majority of users will be Post Office staff within the Office Platform
Service Domain.
Each Post Office Manager will manage the small group of Post Office
Counter Clerks within his Post Office as a local community. The
interface used will be provided by Riposte that will map to the
underlying Windows NT functions.
Within the central sites, ICL Pathway’s system administrators will be
responsible for managing user accounts on the Sequent (Dynix) and
Windows NT platforms using the standard facilities.
11.4.2 Administration of Access Controly
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 100 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
Access controls will be configured in accordance with [ACCPOL] using
the facilities outlined in section 6.
Printed: [DATE \1] COMPANY IN CONFIDENCE Page 101 of 103
ICL Pathway
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
Ref: RS/FSP/oo1
Seeurity Functional Version: 4.0
Date: 12/05/99
Appendix A
Windows NT Audit Eventy
Windows NT can provide essentially the same audit capability for both
workstations and servers. The audit and alarm events selected will,
however, depend upon the usage of platform.
Windows NT File and Directory Accesy
Table A-1explains how each type of access will be interpreted in terms of
Windows NT files and directories.
Type File Access Directory Access
Read Displays the file’s data Displays names of files in the directory
Displays the file attributes Displays directory attributes
Displays the file’s owner and
permissions
Write Changes the file Changes directory attributes
Changes sub-directories and files
Delete Deletes the file Deletes the directory
Change _I Changes the file’s permissions I Changes directory permissions
Permission
Take Changes the file’s ownership Changes directory ownership
Ownership
Execute Runs the file Displays the directory’s owner and
permissions
Toble A-1 Windows NT File and Directory Access
Windows NT Registry Audit
The Windows NT Registry Key Auditing dialogue box can be used to
select the auditable event categories defined in table A-2.
Registry Audit Option I Audit events that attempt to:
Query Value Open a key with Query Value access
Set value Open a key with Set Value access
Create Subkey Open a key with Create Value access
Enumerate Subkeys Open a key with Enumerate Subkeys access
(i.e. events that try to find the subkey of a key)
Notify Open a key with Notify access
Create Link Open a key with Create Link access
Delete Delete the key
Write DAC Determine who has access to a key
Printed: [DATE \I]
COMPANY IN CONFIDENCE Page 102 of 103
ICL Pathway
COMPANY IN CONFIDENCE
Security Functional
FUJ00088002
FUJ00088002
Ref: RS/FSP/oo1
Version: 4.0
Date: 12/05/99
Registry Audit Option
Audit events that attempt to:
Read Control
Find the owner of a key
Table A-2 Interpretotion of Windows NT Registry Audit
Options
Printed: [DATE \I]
COMPANY IN CONFIDENCE
Page 103 of 103
ICL Pathway
COMPANY IN CONFIDENCE
Security Functional
FUJ00088002
FUJ00088002
Ref: RS/FSP/oo1
Version: 4.0
Date: 12/05/99
Appendix B
Mapping to Security
Requirementy
This appendix contains a matrix indicating how the functions described
within the Security Functional Specification map to the security
requirements.
Security requirements, which ICL Pathway has documented in
[SECOBJ], have been extracted from several documents (including
Schedule B-o1).
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
4.218 Windows NT Security Al 2.1 CMS1/1
4.2.11 5.14 CMS7/2
4.2.28 Dynix Operating System A2 2.1 CMS1/1
4.2.2.1 5.14 CMS7/2
43& Database Management System I A3 2.1CMSi/1
4.3.41 5.14 CMS7/2
4.7.2.1 Virus Protection Aq - -
4.7.2.2. Virus Protection AS = =
4.7.2.3 Virus Protection A6 - -
4.7.2.4 Virus Protection AZ >
4.7.2.5 Virus Protection A8& : -
4.7.2.6 Virus Protection Ag - -
5.1 User Identification Bi 5.10 BPS7.1
9.2.3 PSR9.1.6
5.11 User identification Ba - -
5.1.2 User identification B3 - -
5.11.3 User identification Bg - -
511.4 User identification Bs - -
5.LL5 User identification Bsa - -
5.1.1.6 User identification Bsb - -
5.1.2 User Authentication B6 5.10 BPS7.1
9.2.3 PSR9.1.6
5.1.21 User authentication BZ - -
5.1.2.2 User authentication B8& - -
Printed: [DATE \l] COMPANY IN CONFIDENCE Page 104 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
5.1.2.3 User authentication Bg - -
5.1.2.4 User authentication Bio - -
5.1.2.5 User authentication Bu - -
5.1.2.6 User authentication Biz - -
5.1.3.1 Passwords Bi3 - -
5.1.3.2 Passwords Bis - -
5.1.3.3 Passwords Bi6 - -
5.1.3.4 Passwords Biz - -
5.1.3.5 Passwords Bi8 - -
5.1.3.6 Passwords Big - -
5.1.3.7 Passwords B21 - -
5.1.3.8 Passwords Baia - -
5.1.4.1 Human User Passwords Big
5.1.4.2 Human User Passwords B2o
5.1.4.3 Human User Passwords B22 - -
5.1.4.4 Human User Passwords B23 4.19 REQ473 B-o1 423
5.1.4.5 Human User Passwords B24 4.19 REQ473 B-o1 473
5.1.4.6 Human User Passwords B25, 4.19 REQ473 B-o1 473
5.5. Use of Tokens B26 - -
5.1.5.2 Use of Tokens B27 - -
5.1.5.3 Use of Tokens B28 - -
5.1.5.4 Use of Tokens B29 - -
5.1.5.5 Use of Tokens B30 - -
5.1.5.6 Use of Tokens B31 - -
5.1.5.7 Use of Tokens B32 - -
5.1.5.8 Use of Tokens B33 - -
5.2.1 Authentication of NT users B34 - -
5.2.1.2 Authentication of NT users B35 - -
5.2.1.3 Authentication of NT users B36 - -
5.2.2.1 Windows NT logon B37 = =
5.2.2.2 Windows NT logon B38 - -
5.2.2.3 Windows NT logon B39 - -
5.2.2.4 Windows NT logon B4o - -
5.2.3.4 Logon at PO locations Bai - -
5.2.3.2 Logon at PO locations Baia - =
53 Authentication of Oracle Users I B42 2.1CMSi/1
5.14 CMS7/2
5.311 Authentication of Oracle users I B43 - -
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 105 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
5.3.1.2 Authentication of Oracle users I B43a - -
5.3.13 Authentication of Oracle users _I B44 - -
5.3.1.4 Authentication of Oracle users I B45 - -
5.3.15 Authentication of Oracle users I B46 - -
5.411 Authentication of Help Desk B47 - -
users
5.4.1.2 Authentication of Help Desk B48 - -
users
5.4.1.3 Authentication of Help Desk B49 - -
users
5.4.1.4 Authentication of Help Desk Bs5o - -
users
5.5 Authentication of DSS/BA B51 5.6 PSR8.7 (3)
5.6 Authentication of POCL B52 5.1 PSR8.9.1
PSR8.9.2 (2)
5.12 CMS3/3
5.13 CMS34/1
5.14 CMS7/2
5.16 PSR8.9.2 (3)
5.17 PSR8.10.3
6 Logical Access Control a 4.19 REQ473
5.5 PSR8.9.3 (3)
5.10 BPS7.1
5.11 BPS7.1
6.17 PSR8.10.1(1)
9.2.3 PSR9.1.6
9.2.4 PSR9.1.7
6.1.11 Access Control Policy C2 - -
6.1.21 Privileges and Roles C3 = =
6.1.4 Two Person Controls C4 5.5 PSR8.9.3 (3)
6.2 Control of Access to Database _I C5 5.4 PSR8.9.3 (2)
63 Access Controls - NT C6
6.344 Configuration - Windows NT C7 - -
6.3.2.1 Windows NT ACLs c8 - -
6.3.34 Windows NT tools used for Co - -
access control
6.4 Access Controls - Dynix Cio 2.1CMSi1/1
5.14 CMS7/2
Printed: [DATE \l] COMPANY IN CONFIDENCE Page 106 of 103
COMPANY IN CONFIDENCE
ICL Pathway
Security Functional
FUJ00088002
FUJ00088002
Ref: RS/FSP/oo1
Version: 4.0
Specification
Date: 12/05/99
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
6.4.2.1 Dynix Access Controls Cu - -
6.4.2.2 Dynix Access Controls Ciz - -
6.5 Access Controls - Solaris - - -
6.5.2.4 Solaris Access Controls Ciza - -
6.5.2.2 _I Solaris Access Controls Cizb - :
6.6.1.1 Routers - access methods CB - -
6.6.1.2 Routers - access methods C14 - -
6.6.1.3 Routers - access methods C5 - -
6.6.1.4 Routers - access methods C6 - -
6.6.2.1 Routers - privilege mode access I C17 = -
6.6.3.1 Routers - access lists C8 = =
6.6.3.2 Routers - access lists Cig - -
6.6.3.3 Routers - access lists C20 - -
6.6.3.4 Routers - access lists C21 - -
6.6.3.5 Routers - access lists C22 - -
6.7.11 Firewalls - access methods C22a - -
6.7.11 Firewalls - access methods C22b - -
6.7.21 Firewalls - access lists C22 - :
6.7.2.2 Firewalls - access lists C22d - -
6.7.2.3 Firewalls - access lists C22ze - -
6.8 Control of Access to VPN
Management Information
6.8.44 VPN Management Information I C 22f : -
6.8.1.2 VPN Management Information I C 22g : -
6.8.13 VPN Management Information I C 22h - -
6.8.1.4 VPN Management Information I C 22i - -
7 Audit and Alarms C23 4.14 BPS8.2.1
4.15 BPS8.2.2
4.16 REQ472
5.12 CMS3/3
5.13 CMS34/1
9.10.1 BPS9.1.5
9.10.2 BPS9.2.5
9.10.4 BPS9.4.5
9.10.5 BPS9.5.5
9.10.6 BPS9.6.5
12.1 REQ699
7.311 Auditable events C24 B-o1 942
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 107 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
7.31.2 Auditable events C24a B-o1 942
7-411 Application level Audit C25 B-o1 942
741.2 Application level Audit C26 B-o1 699
7.4.24 Audit at CAPS interface C27 B-o1 699
7.4.2.2 I Audit at CAPS interface C28 B-o1 699
74.2.3 Audit at CAPS interface C29 B-o1 699
7.4.2.4 Audit at CAPS interface C30 B-o1 699
7.4.2.5 Audit at CAPS interface en B-o1 699
7.4.2.6 I Audit at CAPS interface C32 B-o1 699
7.5.34 Audit tracks within the C33 B-o1 699
database
7.4.3.2 Audit tracks within the C34 B-o1 699
database
7433 Audit tracks within the C35 B-o1 699
database
7.4.3.4 Audit tracks within the C36 B-o1 699
database
7-441 Riposte Transaction log C37 B-o1 699
7-4.4.2 Riposte Transaction log C38 4.18 REQ472 B-o1 472
7-443 Riposte Transaction log C39 4.18 REQ472 B-o1 472
7-4-4-4 Riposte Transaction log C40 4.18 REQ472 B-o1 472
74-45 Riposte Transaction log C41 4.18 REQ472 B-o1 472
7-4.4.6 Riposte Transaction log C42 4.18 REQ472 B-o1 472
74-47 Riposte Transaction log C43 B-o1 478
7-454 Logging in fall-back mode C44 B-o1 699
74.5.2 Logging in fall-back mode C45 B-o1 699
7-453 Logging in fall-back mode C46 B-o1 699
7-511 Application level audit analysis I C47 B-o1 699
7.5.1.2 Application level audit analysis I C48 B-o1 699
7-513 Application level audit analysis I C49 B-o1 699
7.51.4 Application level audit analysis _I C50 B-o1 699
7.6.1.1 Protection of audit tracks C51 B-o1 699
7-6.1.2 Protection of audit tracks C52 B-o1 699
V7ad Audit of SM functions C53 B-o1 699
7.1.2 Audit of SM functions C54 B-o1 699
7-713 Audit of SM functions C55 B-o1 699
7-714 Audit of SM functions C56 B-o1 699
VTLS Audit of SM functions C57 - -
Printed: [DATE \l] COMPANY IN CONFIDENCE Page 108 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Date: 12/05/99
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
7.71.6 Audit of SM functions C58 - -
8 Crypto Functionality Di 2.22 BPS6.3
8.1 Crypto - CAPS Links D2 2.1CMSi/1
8.441 Crypto - CAPS Links D3 - -
8.1.24 CAPS Link Protection D4 - :
8.1.2.2 CAPS Link Protection D4a - -
8.1.2.3 CAPS Link Protection D4b - -
8.1.2.4 CAPS Link Protection D4c - -
8.13. CAPS Link Key Management D5 - -
8.13.2 CAPS Link Key Management D6 : -
8.13.3 CAPS Link Key Management D7 - -
8.2 Crypto - CMS Links (to DLR) D8 2.1CMSi/1
8.2.41 CMS Link Protection Do - -
8.2.1.2 CMS Link Protection Dio - -
8.2.13 CMS Link Protection Du - -
8.2.1.4 CMS Link Protection Dua - -
8.2.21 CMS Link Key Management Di - -
8.2.2.2 CMS Link Key Management Di4 - =
8.2.2.3 CMS Link Key Management Dis - -
8.3 Crypto - POCL TIP Link Di6 9.7.6 BPS9.6.1
8.3.44 POCL TIP Link Protection Diz - -
8.3.1.2 POCL TIP Link Protection Di8 : =
8.3.13 POCL TIP Link Protection Di8a - -
8.3.24 POCL TIP Link - Key Di8b - -
Management
8.3.2.2 POCL TIP Link - Key Di8c - -
Management
8.3.2.3 POCL TIP Link - Key Di8d - -
Management
8.3.2.4 POCL TIP Link - Key Di8e - -
Management
8.444 POCL Farnborough Link - Di8f - -
Protection
8.4.2.1 POCL Farnborough Link - Key I Di8g - -
Management
8.5.11 AP Client Links Di8h - -
8.5.1.2 AP Client Links Di8i - -
8.6 Post Office Links D23 9.2 REQ467
Printed: [DATE \l] COMPANY IN CONFIDENCE Page 109 of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Seourity Functional Version: 4.0
Date: 12/05/99
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
8.6.11 PO Links - Protection D24 - -
8.6.1.2 PO Links - Protection Das, - -
8.6.1.3 PO Links - Protection Dasa - -
8.6.1.4 PO Links - Protection Da5b - -
8.6.1.5 PO Links - Protection D2sc = -
8.6.1.6 PO Links - Protection Dasd - -
8.6.1.7 PO Links - Protection Da5e - -
8.6.1.8 PO Links - Protection Dasf - -
8.6.1.9 PO Links - Protection Da5g - -
8.6.40 _I PO Links - Protection Dash - -
8.6.2 Key Management D27 9.2.8 PSR9.4
8.6.2.1 Key Management D28 : =
8.6.2.2 Key Management D28a - -
8.7.14 PO LAN Protection D29 - -
8.7.1.2 PO LAN Protection D30 - -
8.7.2.1 PO LAN Key Management D31 - -
8.7.2.2 PO LAN Key Management D32 - -
8.7.2.3 PO LAN Key Management D33 - -
8.8.1.1 Roll-out to Post Offices D33a - -
8.8.1.2 Roll-out to Post Offices D33b - -
8.8.1.3 Roll-out to Post Offices D33c - -
8.8.1.4 Roll-out to Post Offices D33d : -
8.8.1.5 Roll-out to Post Offices D33e - -
8.8.1.5 Roll-out to Post Offices D33f - -
8.8.1.6 Roll-out to Post Offices D338 - -
8.8.1.7 Roll-out to Post Offices D33h - -
8.9.4.1 Inter-campus Link Protection D34. - -
8.9.2.1 Inter-campus Key Management I D35 - -
8.10 Crypto - SIS Help Desk Links D36 5.5 PSR8.9.3 (3)
8.10.11 SIS/ Help Desk and SM Links D37 - -
8.10.2.1__I SIS/SM Link Protection D39 - -
8.10.2.2 _I SIS/SM Link Protection D4i - -
8.10.2.3 SIS/SM Link Protection D42 - -
8.10.3.1__ I SIS/SM Link Key Management _I D44 - -
8.1.41 Links with ICL Pathway HQ D45 - -
8.11.12 Links with ICL Pathway HQ D46 - -
8.1.1.3 Links with ICL Pathway HQ D47 - -
8.1.1.4 Links with ICL Pathway HQ D48 - -
Printed: [DATE \I] COMPANY IN CONFIDENCE Page no of 103
FUJ00088002
FUJ00088002
COMPANY IN CONFIDENCE
ICL Pathway Ref: RS/FSP/oo1
Security Functional Version: 4.0
Specificati
Date: 12/05/99
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
8.1.2.4 Links with ICL Pathway HQ - D49 - -
Protection
8.1.3.1 Links with ICL Pathway HQ - D50 - -
Key Management
8.12.11 Key Generation D5 - -
8.12.1.2 Key Generation D52 - -
8.12.1.3 Key Generation D53 - -
8.12.1.4 I Key Generation D54 - -
812.45 Key Generation Ds5 = =
9 Message Protection Ei 2.22 BPS6.3
3.5 PSR8.5.2
3.41 REQ799
9.2 REQ467
9.3 REQ934
9.4 REQ935/
BPS9.1
9.5 PAS3.3
9.71 BPS9.1.1
9.72 BPSg.2.1
9.73 BPS9.3.1
9.74 BPS9.4.1
9.75 BPS9.5.1
9.76 BPS9.6.1
9.8.3 BPS9.3.3
9.8.4 BPS9.4.3
9.8.5 BPS9.5.3
9 Message Protection (continued)
(continued) 9.11.1 9.8.6
BPSo9.6.3
9.11.1 BPS9.1.6
9.11.4 BPS9.4.6
9.11.5 BPS9.5.6/
PAS3.6
9.11.6 BPS9.6.6
9.2.1 PSR9.1.4
9.2.2 PSR9.1.5
9.2.5 PSRo.2.2
9.2 DSA - Key Management E2 9.2.8 PSR9.4
9.2.2.1 Public Key Certificates E3 = -
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 11 of 103,
COMPANY IN CONFIDENCE
ICL Pathway
Security Functional
FUJ00088002
FUJ00088002
Ref: RS/FSP/oo1
Version: 4.0
Specification
Date: 12/05/99
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
9.2.2.2 Public Key Certificates E4 - -
9.2.2.3 Public Key Certificates E5, - -
9.3.1.1 BES Payment Authorisations EZ - -
9.4.1.1 Automated Payments E9 - -
9.4.1.2 Automated Payments Ega - -
9.5 ed Distributed to POs - Tivoli Eu - -
9.5.2.1 Distributed to POs - Riposte E12 - -
9.5.2.2 Distributed to POs - Riposte E3 - -
9.5.2.3 Distributed to POs - Riposte E14 - -
9.5.34 Protection of Non-desktop E15 - -
Software on Post Office PCs
9.5.3.2 Protection of Non-desktop E16 - -
Software on Post Office PCs
9.5.4 Protection for Siemens - [STAT] - -
Metering Code and Data
9.5.4.1 Siemens Metering Code / Data_I E17 - -
9.5.4.2 Siemens Metering Code / Data_I E18 - -
9.5.4.3 Siemens Metering Code / Data_I E19 - -
9.5.4.4 _I Siemens Metering Code / Data_I E20 - -
9-5-4.5 Siemens Metering Code / Data_I E21 - -
9.5.4.6 Siemens Metering Code / Data_I E22 - -
9.5.4.7 Siemens Metering Code / Data_I E23 - -
9.5.4.8 Siemens Metering Code / Data_I E24 - -
9.5.4.8 Siemens Metering Code / Data_I E25, - -
10 Filestore encryption Fi 4.u PAS214
9.2.7 PSR9.3
10,1 Data Confidentiality F2 5. BPS7.1
10.3.1.1 Filestore encryption - Security _I F3 - -
10.3.1.2 Filestore encryption - Security I F4 - -
10.3.1.3 Filestore encryption - Security I F5 - -
10.3.1.4 Filestore encryption - Security _I F6 - -
10,3.1.5 Filestore encryption - Security _I F7 : =
Printed: [DATE \I] COMPANY IN CONFIDENCE Page 112 of 103
COMPANY IN CONFIDENCE
ICL Pathway
Security Functional
FUJ00088002
FUJ00088002
Ref: RS/FSP/oo1
Version: 4.0
Specification
Date: 12/05/99
SFS Subject Test I Objective Origin I Source
Section No. Reference Referen
ce
1.2 System Management Gi 9.16.1 BPS9.1.14
9.16.2 BPS9.2.14
9.16.3 BPS9.3.14
9.16.4 BPS9.4.14
9.16.5 BPS9.5.14
9.16.6 BPS9.6.14
10.15 PSRio
10.16 PSRuv
U.2.11 SM - Tivoli G2 - -
1.3.1.1 SM - software distribution G3 - -
1.3.1.2 SM - software distribution G4 - -
11.3.1.3 SM - software distribution G5 - -
11,3.2.1 SM - event management G6 - -
11,3.2.2 SM - event management G7 - -
1.3.2.3, SM - event management G8 - =
1.3.4.1 SM - resource monitoring Gog - -
11.3.4.2__I SM - resource monitoring Gio - -
11.3.5. SM - inventory monitoring Gu - -
11,3.5.2 SM - inventory monitoring Giz - -
11,3.5.3 SM - inventory monitoring G13, - -
1.3.5.4 SM - inventory monitoring G14 - -
1.3.5.5 SM - inventory monitoring G5 - -
Printed [DATE \1] COMPANY IN CONFIDENCE Page 113 of 103