FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION _ Version: 4.0
Date: 22/09/97
Document Title:
Document Type:
Abstract:
Distribution:
Document Status:
Document Predecessor:
Associated Documents:
Author:
Signatories:
Martyn Bennett
Dick Long
John Dicks
Barrie Vaughan
Alan Ward
Barrie Davies
Martin Riddell
Paul Curley
Pathway Release Contents Description
Definition Document
This document defines the functional content of Release Ic
BPS, OBCS and EPOSS Services in relation to the
development baseline document Service Architecture Design
Documentation Version 2.0
PDA Members
Pathway Management Team
Pathway Library
Issued for Approval
None
Service Architecture Design Documentation Version 2.0
Security Functional Specification (SFS) version 2.0.
Steve Warwick
Printed: [ DATE \I]
COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 1
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE lc CONTENTS DESCRIPTION _ Ver: 4.0
Date: 22/09/97
Document Title: Pathway Release Contents Description
Document Type: Definition Document
Abstract: This document defines the functional content of Release Ic
BPS and OBCS Services in relation to the development
baseline document Service Architecture Design Documentation
Version 2.0
Distribution: PDA Members
Pathway Management Team
Pathway Library
Document Status: Issued for Approval
Document Predecessor: None
Associated Documents: Service Architecture Design Documentation Version 2.0
Security Functional Specification (SFS) version 2.0.
Author: Steve Warwick
Signatories:
For ICL Pathway Ltd:
For PDA:
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 1
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
1. DOCUMENT CONTROL
1.1 CONTENTS
1. DOCUMENT CONTROL .
1.1 CONTENTS ........05
1.2 DOCUMENT HISTORY ......
1.3 CHANGES FORECAST .......cccscseeseesesoes
1.4 ABBREVIATIONS USED........
1.5 CHANGES HISTORY ..........
2. INTRODUCTION
3. SCOPE... eee ececc cece eceeecececseeceeeeeeseeessenenensesesasacensesesesesisssessesesneisisesessnseseseeesetenes 6
4. RELEASE 1C CONTENTS.
4.1 INTRODUCTION
4.2 PFI SERVICE ARCHITECTURE...........
4.2.1 PFI SERVICE FUNCTIONALIT
4.3 CARD MANAGEMENT SERVICES..
4.3.1 CMS FUNCTIONALITY...
4.4 PAYMENT AUTHORISATION SERVICE
4.4.1 PAS FUNCTIONALITY...
4.5 COMMON CMS AND PAS SERVICE ELEMENTS ...
4.5.1 COMMON CMS AND PAS FUNCTIONALITY ..
4.6 BENEFIT ENCASHMENT SERVICE
4.6.1 BES FUNCTIONALITY
4.6.2 LIMITATIONS AGAINST FS VERSION 6.0 AND SADD:
4.6.3 EXTENDED VERIFICATION PROCEDURES .......
4.7 ELECTRONIC POINT OF SALE SERVICE...
4.7.1 EPOSS FUNCTIONALITY - INCLUSIVE LIST..
4.8 ORDER BOOK CONTROL SERVICE...
4.9 POCL SERVICES
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 2
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.10 SECURITY,
4.10.1 INTRODUCTIO:
4.10.2 SECURITY COMPONENTS ..
4.10.3 IDENTIFICATION AND AU nN
4.10.4 LOGICAL ACCESS CONTROL
4.10.5 AUDIT AND ALARMS.
4.10.6 ADDITIONAL NT FUNCTIONALITY NOT AVAILABLE
4.10.7 CRYPTOGRAPHIC FUNCTIONALITY
4.10.8 MESSAGE PROTECTION
4.10.9 FILESTORE ENCRYPTION IN POST OFFICES
4.10.10 ADMINISTRATION OF SECURITY
4.10.11 ACCESS CONTROL ISSUE:
4.11 FRAUD RISK MANAGEMENT AND BPS MIS.............. 2
4.11.1 FRAUD RISK MANAGEMENT AND BPS MIS - RELEASE
4.12 SCHEDULE B03..
4.13 BOUNDARY SERVICE PERFORMANCE LEVELS
ANNEX 1 CONTRACTUAL FUNCTIONAL BASELINE
ANNEX 2 RELEASE 1C TECHNICAL AND PHYSICAL ENVIRONMENT - ISSUE 4
(4/9/97)
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 3
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
1.2, DOCUMENT HISTORY
Version Date Reason
0.1 17/2/97 First Draft for Pathway and PDA discussion
02 18/2/97 Updated with comments received following initial review within
Pathway.
03 18/2/97 Updated following Pathway Review on 18/2/97
04 19/2/97 Updated following further review on 19/2/97, in particular
revisions to the FRM and BPS MIS section.
1.0 19/2/97 First formal issue following review within Pathway
11 23/4/97 Revised following comments from PDA and including agreed
statements on the implementation of Access Control features
12 2/5/97 Updated to include comments received from PDA Product
Management.
13 19/5/97 Updated for circulation to PDA and Pathway for comment,
changes principally in the area of access control
14 21/5/97 Updated following cross-checks with Releasele and Release 2
RCDs. Description associated with SADD reference 4.1.1.10
clarified, comment at SADD reference 3.1.3.11.1.1 removed.
LS 13/6/97 Updated following receipt of comments from PDA Product
Management and further internal comment from Pathway in the
areas of BPS and Security.
2.0 20/6/97 Updated following further comment from the PDA and issued
for authorisation
3.0 27/6/97 Minor change to include reference to ABED at the request of
PDA Product Management
40 22/9/97 Changes to incorporate the caveats expressed in the PDA
acceptance letter for version 3.0 (including the addition ofa
Technical Infrastructure Annex) plus clarification of the
Security Access controls as agreed in the document “Security
Exclusions from Release 1c” (RS/RES/002 V3.0 dated 5.9.97)
1.3 CHANGES FORECAST
None.
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 4
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
1.4 ABBREVIATIONS USED
The terms and abbreviations used in this document are those defined in the AUTHORITIES
Agreement (Schedule A01) and in the SADD (Version 2).
1.5 CHANGES HISTORY
Changes as documented in Document History, once baselined any changes will be maintained
using side bars.
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 5
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION __ Ver: 4.0
Date: 22/09/97
2. INTRODUCTION
In response to the request to consider a phased release of the Horizon system which would
include a release of the system which provides only the Benefit Payment Service (BPS) and
Order Book Control Service (OBCS), this document is intended to provide a definition of the
functional contents believed by ICL Pathway as necessary to support such a release.
In the course of examining the minimum functional requirements of this release it has been
found necessary to extend the functional scope beyond the BPS and OBCS services to include
that minimal element of the EPOSS service necessary to support the primary services. This is
necessary due to the integrated nature of the desktop components of the service and the
consequential interdependency between the products.
3. SCOPE
This document is limited to the functional services required to support a release of the system
which offers only the BPS and OBCS services at the counter, with the supporting
infrastructure necessary to receive and process the encashment of Payment Authorisations and
Control Notice files issued by the Benefits Agency (BA) and to return transaction files to the
BA and to POCL via the ABED interface.
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 6
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4. RELEASE 1C CONTENTS
4.1 INTRODUCTION
In order to achieve a rapid understanding of the functional content included in the release, the
tables in the following sections describe the functionality in two different ways. In the case of
the Service Infrastructure, POCL Services, Security, Audit, BPS and OBCS, the description is
represented as an exception list against the baseline functionality contained in the Services
Architecture and Design Document (SADD). For EPOSS functionality, due to the restricted
functions provided, the description is expressed as a positive statement of the functions from
the SADD which are to be included. The baseline is the SADD (version 2) and the SFS
Version 2.0; the section headings from these two documents have been used to structure the
Release 1c Content paragraphs which follow this introduction. It should be noted that this
approach introduces a degree of necessary duplication between the paragraph sections. The
references in the descriptions are to the SADD or the SFS.
The Related Agreements, the SADD and the SFS make reference to
documents which form a necessary part of the functional baseline. These
documents and their status at the time that the Release 1c Contents Definition
was produced are listed at Annex I to this document. Not all of the documents
have been agreed with the AUTHORITIES at the time that the document was
prepared and in some cases ICL Pathway has had to develop the system using
draft documents. It can not be assumed that when these documents are agreed
by the AUTHORITIES that the functionality so defined can be included within
Release Ic.
4.2. PFISERVICE ARCHITECTURE
Except where specified below, all the requirements of the PFI Service Architecture will be
met in Release Ic. It should be noted that at Release 1c only one of the Pathway Data Centres
will be operational and that this data centre will communicate to 2 BA ACCs - Livingstone
for the CAPS service and Washington for the OBCS service.
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 7
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.:
Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
4.2.1 PFISERVICE FUNCTIONALITY
(see also 3.1.2.5.5)
&2 These sections contain references to the
PEI Service POCL Inventory Management. Detailed
‘Architect requirements for this facility have been
enitecture withdrawn by the Authorities.
24.1 CAPS Contingency payments will be
Contingency available in Release Ic by generating
payments (the last authorised amount) for all
beneficiaries whose next payment due date
matches the required date. A file of
contingency payments will be sent to CAPS.
for reconciliation.
2.5 The Security Functional Specification is
- defined in Section 4.10
Security
2.5.2 The Fraud Risk Management Service Design
Fraud Risk Specification is defined in Section 4.11
Management
inted: I DATE \I]
COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 8
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.:
Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
4.3 CARD MANAGEMENT SERVICES
4.3.1 CMS FUNCTIONALITY
3.11
The automatic issue of a bilingual card based on the
card holder’s location is dependent on knowing the post
Maintain code of the cardholder. An algorithm has been
Cardholder . «. a
Details implemented for Release 1c giving a close
approximation of the card holder to England/Wales.
But a better solution requiring data cleansing with
DSS/CAPS is under discussion for Release 2.0
3.1.1.3.3 Recording of the Reason for Card Impounds is not
Maintain Card implemented at Release le
Status
3.1.1.5 On production of the second reminder PUN, a process
The PUN - needs to be defined to get the details sent to DSS via
the Horizon Customer Services Department.
3.1.1.6 Cards with an incorrectly calculated LUHN check digit
(as issued for use in IGL) will continue to be accepted
during Release Ic.
3.1.1.6.1 Extension of the period of card validity, as oppose to
a the period during which the card can be collected, is
“ustomer . . .
Unable to not supported at Release Ic since cards will not expire
Parean for at least three years.
3.1.1.6.2 For Release Ic, the card details which will advise the
clerk of the presence of the new card after the old card
Replacement of : . . : ey .
Aon has been swiped will not be available. This facility will
existing card on 4 "
c not be required until 1998.
card expiry-
3.11.71 The route by which CMS will report non-collection to
a DSS needs to be defined by DSS/POCL
Inhibit card on
failure to collect
3.1.1.8.4, When the National Sensitivity indicator is present on a
3.1.1.8.4.1 record, personal details are not displayed on the screen
unless the user has the appropriate level of access
privilege.
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 9
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.:
Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
1.8.4.7, The implementation of Temporary Token is awaiting
311848 CAPS interface support and agreement of the ICL
ae Pathway document “Temporary Token Overview and
Emergency Usage”.
Order of
Temporary
Tokens
3.1.1.8.5.2 A Card batch can be suspended, cancelled or re-
ordered even when booked in. These facilities are to
be restricted to Card batches in production or in
dispatch in Release 2.
3.1.1.9 The whole of this section refers to the implementation
of Temporary Tokens. This is awaiting CAPS interface
Temporary
Token support. All other references to Temporary tokens are
Production and
Issue
subject to the same limitation.
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 10
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.:
Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
4.4 PAYMENT AUTHORISATION SERVICE
44.1 PAS FUNCTIONALITY
3.1.2.4
Amendment to
Cardholders
Details.
3.1.2.10.4
Notification of
The automatic issue of a bilingual card based on
the card holder’s location is dependent on
knowing the post code of the cardholder. An
algorithm has been implemented for Release Ic
giving a close approximation of the card holder to
England/Wales. But a better solution requiring
data cleansing with DSS/CAPS is under
discussion for Release 2.0
Urgent payments
change of
address.
3.12.42 The Appointee role will not be supported in
Release Ic.
3.1.2.5.4 Urgent payment facility within PAS is not
included as it requires the CAPS on-link which is
currently not supported by CAPS. All urgent
payments at Release Ic will be via Green
Girocheque
The Appointee role will not be supported in
Release Ic.
CAPS Contingency payments will be available in
Release Ic by generating payments (the last
Contingency I authorised amount) for all beneficiaries whose
paym next payment due date matches the required date.
A file of contingency payments will be sent to
CAPS for reconciliation.
3.1.2.6.1 The Geographical Restriction Indicator (GRI) is
not implemented at Release Ic. At Release 1c
Encashment :
: potential infringements are prevented by the
Infringement
system but not reported.
3.1.2.9 The CAPS on-line interface is not currently
Enquiry on supported by CAPS.
Payment Details
3.1.2.113 When the National Sensitivity indicator is present
DSS Viewpoint ona record, personal details are not displayed on
the screen unless the user has the appropriate level
of access privilege.
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 11
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
3 1 The on-line interface is not supported by CAPS at
capsicaps _ I Release le
access Facility
not available
3.1.2.11.4.4 Change of Nominated Post Office via the Help
Desk is not supported at Release le
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 12
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.5 COMMON CMS AND PAS SERVICE ELEMENTS
4.5.1 COMMON CMS AND PAS FUNCTIONALITY
3 athway’s proposals for Release 1c and subsequent
ae releases are contained in “Post Office not available for
Maintain Post > Versi
Benefit Encashment” Version 6,
Office
references.
3.1.3.7.1 There is no facility to archive and delete entries that
Beneficiaries notify details of NINOs designated no longer of interest
afler 90 days. This facility will be incorporated into
Release 2.
3.1.3.8 DSS management Information is addressed in section
pss 4.11 below.
Management
Information
3.1.3.8.1.7 The Appointee role will not be supported in Release Ic.
3.13.91 The CAPS on-line interface is not currently supported
CAPS access I OY CAPS
system -
3.1.3.11.1.1 Card related reconciliations - the facility to
communicate these reports is not yet defined by
Cardelated I gs/POcl.
reconciliation
3.13.11.1.2 The implementation of Temporary Token is awaiting
Card-related CAPS interface support in a future CAPS Release.
reconciliation
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 13
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.:
Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
4.6 BENEFIT ENCASHMENT SERVICE
4.6.1 BES FUNCTIONALITY
SAD!
4.1 2
Steady State
Provision
At Release Ic, after the Card Activation the clerk will
have to swipe the card again to access Benefit
Encashment screen if payments are due
4.1.1.4.4
Collection of
At Release 1c Housebound PUN holders with no
alternate payee will contact the CMS Help Desk to
record their inability to collect their card.
Impoundment of
Card by Agent
Procedures will be put in place to allow benefit
collection via Green Girocheque.
4.1.1.5 Extended Verification Process for Release Ic is
Extended defined in Section 4.6.3 below.
Verification
Procedure
4.1.1.6 Recording of the reason for Impounding Temporary
Tokens is not implemented at Release Ic.
service provision-
card/Temporary
Token
4.11.63 The system will only generate the receipt for
impounded PUN or Card on request.
41.7.2 For Release Ic, the functionality of the screens that
remind the clerk of the location to which reports and
Steady state
associated items should be forwarded in connection
with impounded PUNs, cards and temporary tokens is
not available.
4.1.1.8.2
Steady state
service provision-
Payment Description code length awaiting resolution
by DSS of request of 22 character description for
printing on receipt.
The payment description code length will be defined
as 12 for Release lc.
Prompt to clerk does not include :~
“Pay customer, return and issue bottom copy of
receipt”
“Place receipt in drawer”
These have been omitted for performance reasons and.
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 14
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.:
Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
because there is no room on the screen. Help will be
provided instead.
4.1.1.9
Foreign
Encashment
Point of note :-
There is no support for the exclusion of Social Fund
Payments within the restrictions relating to Foreign
Encashments as in accordance of Requirement 770.
Social Fund Payments are not intended to be one of
the benefits payable at Release le
At Release Ic, if an attempt is made by a customer
with a Restricted Post Office to make a foreign
Steady State
Service provision
poe ante. I encashment a message will be displayed rather than a
. prompt to refer to nominated Post Office
“Steady State
Provision”
4.1.1.10 At Release 1 Casual Agent encashments are not
supported. Procedures will be put in place to allow
collection via Green Girocheque.
4.1.1.11.2 Requirements and detailed procedures are to be
agreed in connection with group permanent and
signing agents and will not be in Release Ic.
Steady State
Provision
4.1.1.14.2 At Release Ic, after Change of Nominated Post
Steady State Office the clerk will have to re-swipe the card to
ne access Payments Screen
Provision
4.1.1.14.2 At Release 1c, change of Nominated Post Office
screen will not contain “message for the clerk, if
applicable” as the source for additional messages has
not been defined.
The change of nominated Post Office does not take
effect until the message notifying the change has been
processed centrally and the payments associated with
the card have then been re-directed to the new
nominated office. In cases where the beneficiary
wishes to encash at the new office but cannot due to
having exceeded the allowable number of Foreign
Encashments, a payment may be authorised via the
Help Desk.
4.6.2, LIMITATIONS AGAINST FS VERSION 6.0 AND SADD2
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 15
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE lc CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.11.13 This section refers to the production of Duplicate
Receipts. This requirement has been withdrawn and is
currently not scheduled for any Release
Printed: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 16
ICL Pathway Ref.:
RELEASE Ic CONTENTS DESCRIPTION __ Ver:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
4.6.3 EXTENDED VERIFICATION PROCEDURES
Release 1c Functionality
The headings refer to the appropriate heading in the main body of the Extended Verification
Process Requirement document ref. RS/SPE/0003.
INFORMATION REQUIREMENT
The following information will be used in Release Ic:
e First Name
e Day of Birth
© Month of Birth
QUESTION GENERATION
Questions will be randomly generated from the following information:
¢ First Name
© Day of Birth
© Month of Birth
NUMBER OF QUESTIONS AVAILABLE FOR USE AT THE COUNTER
e Three questions will be available for use at the counter.
NUMBER OF QUESTIONS USED AT THE COUNTER
Three questions will be used at the counter incorporating the following information:
¢ First Name
e Day of Birth
¢ Month of Birth
ANSWER GENERATION
Alternative answers will be generated for the following:
¢ First Name
e Day of Birth
© Month of Birth
GENUINE ANSWERS
This will be implemented in Release Ic.
ALTERNATIVE ANSWERS
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 17
ICL Pathway
FUJ00119593
FUJ00119593
Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION __ Ver: 4.0
Date: 22/09/97
This will be implemented in Release Ic subject to the data used i.e. First Name, Day of Birth,
Month of Birth.
SEQUENCE OF QUESTION EVENTS
This will be implemented in Release Ic.
INFORMATION PROVIDED TO THE COUNTER CLERK.
This will be implemented in Release Ic.
SCREEN FORMAT OF EVP - MULTIPLE CHOICE
This will be implemented in Release Ic.
CIRCUMSTANCES UNDER WHICH EVP INVOKED
EVP will be invoked only in the following circumstances:
REPORTING
Card Issue
Keyed Input of Card/PUN Details
At the counter clerks discretion ( with the exception of casual agent
transactions and change of nominated Post Office)
Foreign Encashment
Change of Nominated Post Office in those instances where an outstanding
payment record is present.
Reports available at Release 1c will include the following details by Post Office and
Nationally:
Number of transactions subject to EVP
Number of transactions subject to EVP as a percentage of total transactions
Number of transactions failing EVP.
Number of transactions failing EVP as a percentage of total number of
transactions subject to EVP
CONTRACTING AUTHORITIES RESPONSIBILITY
No criteria selection/targeting facility will be available in Release Ic.
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 18
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.:
Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
4.7 ELECTRONIC POINT OF SALE SERVICE
The statements within this section identify only those elements of the EPOSS service which
will be delivered for Release Ic
4.7.1 EPOSS FUNCTIONALITY - INCLUSIVE LIST
Transaction
4.13 & This section relates to the implementation of
413.14 customer sessions. In the context of Release Ic,
customer sessions are supported for BES and OBCS
Customer transactions only. Transactions will appear on the
Sessions Desktop transaction ‘stack’. The stack is cleared by
selection of the ‘finish’ option.
4.13.17 The only desktop transactions to be provided will
be to support user administration (see 4.10.4
below), BPS and the OBCS services.
Access Control
selection
4.1.3.1.2 Settlement of transactions will be supported through
Settlement the use of the ‘Finish’ option on the desktop. In
Release Ic settlement will be assumed to be via
‘Cash’ and no options to select Method of Payment
will be supported
4.1.3.1.16 Committal of transactions will be supported.
. Transactions will only be committed following
Commit ‘ “Binich? arti
. selection of the ‘Finish’ option on the desktop
Transactions
4.13.1.17 Fully supported
Start a new
customer
session
4.1.3.2 Product reference data sufficient to support the
EPOSS Counter EPOSS product items used for BES. and Pension
Transactions and Allowance transactions will be required.
Reference data will also be required to support the
menu hierarchy, menu buttons and the token
definitions needed to support the BES payment
cards and the BES and OBCS bar-code structures.
4.1.3.3.3 The functions to support the creation of users,
creation of passwords, allocation of roles and the
maintenance of these items will be supported.
inted: I DATE \I]
C:\OFFICE\TMP\TO20\pastr006.doc Page 19
COMMERCIAL IN-CONFIDENCE
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.8 ORDER BOOK CONTROL SERVICE
With the exception of the item listed below, the functionality of OBCS for Release Ic will be
as required in SADD Version 2.0.
There is no functionality to check the status of order book
on re - direction. This is documented in the OBCS
Business Processing Rules and will not be implemented
(at any Release)
4.1.4.2.1 The functionality to provide an adhoc comparison of a
complete BA Control Notice file against the Pathway
Control Notice file, with discrepancies written to an
exception report, is not supported at Release Ic
4.1.4.2.3.1.1 No ‘Last Book’ option is provided to terminate the
‘Receipt’ session. This was agreed during the Joint
Working Team reviews of the product.
4.1.4.2.3.1.1 Reading of a valid Bar-code is indicated audibly.
Scanning of an invalid bar-code is not signified in any
4.1.4.23.2.1 * . . ry
way since the system has no definition against which it
4.1.4.2.3.3.1 can match the scanned code. This feature has been
reviewed and accepted during Joint Working.
4.1.6.2.1.3 This section of the SADD has not been implemented and
is the subject of further clarification of the sponsors
requirements. For Release Ic, a report facility is provided
to enable the outlet to print a copy of the local Control
Notice file. This printed list should be used to check for
control notices against order books when the system is
unavailable for use.
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 20
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.9 POCL SERVICES
With the exception of the item listed below, the POCL Services functionality for Release 1c
will be as required in SADD Version 2.0.
The counter hardware configuration supports the
use of Smart tokens at Release Ic but the APS
Standard rn we rae
Configuration Detail functionality to exploit this facility is not
onliguration Detal's I supported at Release 1c
4.1.5.4.2 These sections contain reference to Inventory
Inventor Management which is still to be defined by
ry DSS/POCL and will not be part of Release Ic.
Management
4.15.41 These sections describe the interface with TIP. No
Transaction interface with TIP is supported within Release Ic.
en Support for the IGL ABED interface will be
Information ss * °
A continued in Release Ic for BPS transactions.
Processing
4151.7 These sections refer to the use of mobile:
. configurations. The peripherals attached to these
Mobile = :
. systems are currently being specified. Mobile
Configurations .
configurations are not supported at Release Ic.
4.1.6.211.1& Where receipt of cards at the Post Office have not
41.62.1.12 been entered into the system (due to the Post
ues Office being out of commission) then the Help
Receipt of Batches of I desk cannot activate the card in order to access
Cards into Post payment details for payment authorisation.
Office Customers will have to contact DSS office for
payment via Green Girocheque
4.1.6.12.2.1 Mobile Office configurations will not be
supported at Release Ic.
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 21
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION __ Ver: 4.0
Date: 22/09/97
4.10 SECURITY
With the exception of the items listed in the tables below (section 4.6.2 to 4.6.9 below), the
Security functionality for Release Ic will be as required in SFS Version 2.0. The section
headings from the SFS have been used to identify the Release 1c content paragraphs which
have been excluded. Within the SFS extensive use is made of references to the Access
Control Policy. Version 1.0 of the Access Control Policy (ACP) has been approved.
Approval of this version of the ACP is caveated by the need to resolve a number of issues
associated with particular sections of the document. For clarification, the outstanding issues
relate to sections 3, 4, 5, 6 and 8 of the ACP..
4.10.1 INTRODUCTION
For the sake of clarity, the following is a list of the components included in the Release Ic
BPS and OBCS end-to-end systems.
e CAPS Access Service Software running in a secure user partition on
the BA VME environment at Livingstone ACC, protected by a
‘firewall’ system;
e CAPS Link protection utilising Red Pike encrypted secure hash
produced using SHA implemented in software at each end of the link;
© OBCS Access Service Software running in a secure user partition on
the BA VME environment at Washington ACC;
«© 2 Mbit communications connections between the Livingstone and
Washington ACCs and the Pathway Release Ic host system running at
the Wigan Data;
« PAS/CMS and OBCS Oracle Databases running on a Sequent
processor under the control of the Dynix operating system;
e Dynix and Oracle RDBMS standard access control facilities;
© central layer of the TMS message store (correspondence server)
running Riposte software under the Windows NT 4.0 operating system
and utilising the Riposte and NT 4.0 security and access control
functionality and the Riposte secure message replication facilities;
© entropy servers running under NT4.0 and utilising NT4.0 security and
access control functionality;
communications gateway PCs for access to the Card Management
facilities operated by De La Rue via Red-Pike encrypted ISDN links,
running under NT4.0 and utilising NT4.0 security and access control
functionality;
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 22
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION __ Ver: 4.0
Date: 22/09/97
e TMS ‘Agent’ software running on an NT 4.0 platform and utilising
NT4.0 security and access control functionality;
* ISDN communications links connecting the central TMS message store
with the local ‘gateway’ PC located at each Post Office outlet, utilising
CISCO routers configured using CISCO Works and implementing
Challenge Handshake Authentication Protocol (CHAP) and Call Line
Identity Protocol (CLIP);
e ISDN Terminal Adaptors at each Post Office Outlet ‘gateway’ PC,
utilising EICON software to implement CHAP and CLIP;
© Post Office outlet PCs (*gateway’ and non-’ gateway’) running Riposte
and NT4.0 and utilising the Riposte (including implementation of
‘roles’) and NT 4.0 security and access control functionality and the
Riposte secure message replication facilities;
e filestore encryption on the Post Office outlet PCs;
© smart token authentication of the PostMaster logon, including
authentication to ‘unlock’ the filestore encryption.
It is believed that the Contracting Authorities have some concerns that it may be possible for
some penetration of the security features to take place during the lifetime of Release 1b.
Whilst such an event is unlikely to pose any threat to the system during Release 1b, concern
exists that this may undermine the integrity of the later releases where the security facilities
would otherwise have prevented such events occurring. In recognition of the fact that the
Release 1b security functionality falls short of the full set of security components defined in
SFS Version 2.0 for the Steady State system, Pathway intend that the following steps be taken
in moving the system from Release 1b to Release 1c where the security is increased:
e the Release 1b Oracle tables containing the Control Notice data, the
central Customer Reference File and the Customer “Nominated Office’
File should be transferred to a new Oracle database at the Live Data
Centres;
e the Release 1b correspondence server layer of the TMS (located at
Feltham) should be archived;
© The Release 1b hardware platforms located in each outlet will be
teplaced by completely new Release 1c hardware delivered from the
Pathway distribution centre and configured with Release 1c software;
© the central and local message stores will be re-populated with OBCS
Control Notice data when Order Books are next presented at the
counter in any particular office;
Migration of the IGL system to the Release Ic environment is to be dealt with in a separate
migration document.
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 23
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.10.2 SECURITY COMPONENTS
The security components identified in Section 4 of the SFS will be provided at Release Ic.
4.10.3 IDENTIFICATION AND AUTHENTICATION
The identification and authentication components identified in Section 5 of the SFS which
will not be provided at Release Ic are identified below.
e Mitigation:
The administration and control of user accounts on both Dynix and NT platforms is
restricted to a single Security Manager role.
¢ This exclusion only applies in those domains where professional, vetted staff operate
the Pathway computer systems. Vetting is to Northern Ireland Civil Service
standards, and CFM staff are currently undergoing M.o.D, vetting.
¢ CFM operational documentation will be modified to state that it is forbidden for
users to change their User Id.
Management procedures will be put in place to ensure that relevant members of staff
are aware of the SFS requirement, and that disciplinary action is taken against any
offender.
© Any staff member guilty of deliberate contravention will be subject to severe
disciplinary action.
«All operational activity takes place in a physically secure environment. Physical
security components of the Data Centres and support sites in Bootle, Wigan and
Belfast will comply with agreed standards.
© Pathway will create a ‘Code of Practice’ to embody the additional processes
proposed for Release Ic. All affected members of staff will be required to sign an
appropriate undertaking to abide by the Code of Practice and copies will be retained
by the Pathway Security Manager.
Please see associated mitigations in SFS Reference 6.1.2.1.
wa
iv
i
No restriction on the number of Logon attempts will be imposed at Release 1c, for OPS.
iy
ie
Failed logon attempts will not require to be reset for Release 1c, for OPS
we
iv
a
Date and Time of User’s last successful logon will not be displayed at Release Ic, for all
NT domains
5.14 The use of tokens will not be introduced at Release 1c.
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 24
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
21.2
52.12 Mitigation
¢ SFS already updated to read “All account information associated with Guest will be
disabled, or where possible, removed entirely.”
© Configuration scripts already modified to flag the Guest account as disabled.
The CFM Security Manager will perform weekly independent checks to verify the
status of the account on the NT Domain Controller(s). A check list, and record of
this procedure, shall be maintained, and made available for inspection.
54.1.4 Authentication of Help Desk to Post Office counter staff. A manual process is to be
agreed between Pathway and PDA.
5.5 Authentication of DSS/BA staff making telephone calls
No sofiware based solution will be provided, however agreed manual procedures will
be put in place
5.6 Authentication of POCL staff making telephone calls
No software based solution will be provided, however agreed manual procedures will
be put in place
4.10.4 LOGICAL ACCESS CONTROL
The following logical access controls identified in SFS section 6 are not provided in Release
le.
The facilities described in the Access Control Policy document are not fully
implemented at Release Ic (see section 4.10 above)
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 25
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
212
6.1.2.1 and 6.4.1 Mitigation
* Inthe absence of COSManager, ICL Pathway will apply the principle of least
privilege within the constraints of the Dynix operating system.
¢ This exclusion only applies in the CFM Belfast Data Centre; no interactive Dynix or
NT accounts exist in Bootle or Wigan. Only monitoring accounts exist in Bootle &
Wigan. There are two types of engineering activity undertaken: ‘part swap’ and
“machine rebuild’, Part swap requires no access as diagnostics are run by CFM.
Machine rebuild occurs before Dynix is available. When Dynix becomes available,
CFM staff in Belfast manage the loading of configuration / authentication files
© All CFM staff providing operational support to the Pathway system are dedicated to
the project i.e. they are not involved in work on any other CFM business.
« The CFM Security Manager will allocate roles in accordance with the ACP, utilising
the user account facilities available in Dynix where appropriate.
¢ It is not possible to login directly as <root>. Dynix is configured to only allow
<root> access at the console (which is in Wigan). Belfast users must login with their
unique User Id and sw to <toot>. The su to <root> is logged, BMC Patrol will
monitor the su/og and cause a Tivoli event to be notified if it detects the use of su.
© Roles requiring access to the Dynix operating system will be divided into those with
a legitimate <root> access requirement, and those with no <root> access
requirements at all. In this way, <root> access will be restricted to the absolute
minimum number of users necessary to maintain efficient operation of the system.
For Release Ic that means two senior support staff plus the Security Manager.
© Operational procedures will be introduced in addition to existing physical and
personnel controls; these include but are not limited to:
« Two man working if <root> access is required during the operational day;
© <Root> access outside of the operational day is event driven and is only
available to two members of staff on a rota basis;
© A paper audit log of all such access and reasons.
© The Unix utility ‘BOMverify’ will be scheduled to run at each shifi change to
highlight any changes in file characteristics. Output will be reviewed by the CFM
Security Manager and exceptions escalated to the Pathway Security Manager for
investigation. The BOMverify program compares the Bill of Materials (BOM) of the
specified products to the actual status of each file listed in the BOM as it currently
exists on the system. The information listed in the BOM includes: the mode (read,
write, etc.), owner, group, size and checksum, and hard and symbolic link data.
BOMverify will be run with the ‘-I’ option. When this is specified, no attempts are
made to correct inconsistent files. Inconsistencies are reported with the expected and
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 26
ICL Pathway Ref.:
RELEASE Ic CONTENTS DESCRIPTION __ Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
actual file status.
of the system).
continued application of these mitigations.
in step with the staff rota.
verified.
proposed to ‘cross monitor’ the two bridge rooms between sites
Associated NT functionality not available;
PinICL 3774. User assigned extra privilege if PDC is down.
PinICL 5071. Various roles can shut down system.
PinICL 5316. NT directory structure not secure on all platforms.
PinICL 5317. NT administrator role permissions are not restricted.
PinICL 5294. Server manager can stop event logging.
PinICL 4906. Security Manager can change system time.
PinICL 4970. NFS log in returns error on PWYSEC and domain.
e The NT Admin privilege will be controlled in the same way as <root> (i.e. restricted
to the absolute minimum number of users necessary to maintain efficient operation
© The Pathway Security Manager will perform periodic physical audits to ensure the
e The CFM Security Manager will be responsible for the allocation of roles in
accordance with the ACP, utilising the NT privilege facilities where appropriate.
* Passwords associated with <root> and Admin will be administered by the CFM
Security Manager, whose responsibilities include changing the passwords regularly
© As part of the CFM Security Manager’s weekly independent review of NT defaults,
the presence of comprehensive event logs for the preceding seven days will be
e The secure ‘bridge’ area in Belfast is monitored by CCTV and video, as is the
machine room. At Bootle and Wigan CCTV is proposed only for the machine room
with monitoring in the ‘bridge’ area. Subject to budgetary approval, it is also
The card access system which provides an audit trail of entry and exit is mandated for all
Pathway Data Centre sites. Existing procedures instruct staff not to allow tailgating.
PinICL 4890., 5396. Selected roles can create and delete folders in TMS domain.
6.1.4 Two Person controls will not be implemented at Release Ic.
6.1.5 Discretionary Access controls will not be implemented at Release Ic.
Printed: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 27
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.10.4.1 PAS / CMS HELP DESK
Technical controls for the PAS/CMS Helpdesk in Bootle are at 2 levels:
1. Access to Windows NT on the individual workstation.
2. Access to the Oracle application on the Sequent
The following access controls will apply: » List of excluded passwords
> Users assigned unique ID > System displaying date and time of previous
» Authenticate using passwords successful logon
> Administrators are able to change account
policies
Enforced password change on first logon
Vv
Maximum Password age : 30 days
Vv
Minimum Password age : I day
v
Minimum password length : 6 characters
Vv
Not allowed to use previous 12 passwords
» Account lock out after 3 consecutive incorrect
password attempts
» After lock out, account enabled by administrator
intervention
The following events will be audited: » NT 3.51 does not audit incorrect logon
> Logon and Logoff attempts
> User and Group management
> Security Policy Changes
> Restart, Shutdown, and System
sa I _
The following access controls will apply: > Enforced password change on first logon
. . i - 572
>» Users assigned unique ID @inICL - 5729)
> System displaying date and time of previous
> Authenticate using passwords successful logon (5727)
> Maximum Password age : 30 days (5728)
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 28
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
> Minimum Password age : I day (5728)
> Minimum password length : 6 characters
(4118)
> More than two consecutive characters in
password (4118)
> Password same as user ID (5719)
» Account lock out after 3 consecutive incorrect
password attempts (4072)
» Afler lock out, account enabled by
administrator intervention (4072)
The following events will be audited:
>» Logon and logoff
> Failed logon attempts
> Application start up and shutdown
» System start up and shut down
4.10.5 AUDIT AND ALARMS
With the following exceptions Audit and alarm facilities identified in SFS section 7 are
provided at Release Ic.
14 Provisions at Rlc
The following audit events will be provided at Ric.
1. DSS Service Environment
1.1 VME CAPS and OBCS
Access to the VME system, from PAS/CMS host, is required to view files transferred at
the contractual boundary. This has been agreed with the DSS and appropriate security
controls are already in place: System access to the VME host is controlled by ACL’s.
Apart from file transfer verification, Pathway has no access to this machine
2. DSS Service Infrastructure
2.1 PAS/CMS Host
Security related auditable events on the PAS/CMS host system are given in the table
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 29
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.: PA/STR/0006
Version: 4.0
Date: 22/09/97
Action or Event
Successful System Log-on
Failed System Log-on
(Loginlog)
System Log-off
System Exceptions
Oracle Exceptions
are logged on)
File Transfer Success/Exceptions
Successful Oracle Log-on
System Start-up
System Shutdown,
Change of User Rights
Write Access to Files
in script system log. BOMVerify.
User Account Management
2.2 PAS/CMS Help Desk
User access to the PAS/CMS Oracle database is held as an audit trail within one or more
of its tables.
2.3 Horizon Help Desk
As 3.2.
3. TMS
3.1 OBCS Host
The script command will support system level auditing, as for PAS/CMS. Security
related auditable events on the OBCS host system are given in the table below.
Action or Event
Successful System Log-on
Failed System Log-on
System Log-off
File Transfer Success/Exceptions
Audit Data
Script system log
Dynix system log
Script system log
BMC Patrol (limited)
BMC Patrol (users who
FTF alert
Oracle audit table
Script system log
System log
System log.
Access to files recorded
Script system log
Audit Data
Script system log*
Script system log*
Script system log*
Control files
inted: I DATE \I]
C:\OFFICE\TMP\TO20\pastr006.doc
COMMERCIAL IN-CONFIDENCE
Page 30
FUJ00119593
FUJ00119593
ICL Pathway
Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
System Start-up Script system log*
System Shutdown Script system log*
Change of User Rights Script system log*
Write Access to Files Access to files recorded
in script system log, Write access to files not available
User Account Management Script system log*
* The script system log contains the output from the UNIX script utility (enabled to
capture keyboard activities and screen images).
3.2 Agents
Windows NT system and application level events will be forwarded, by a TME Agent,
to a central Tivoli system. Security related auditable events on agent systems and other
NT systems, are given in the table below.
Action or Event Audit Data
Successful System Log-on NT Event log
Failed System Log-on NT Event log
System Log-off NT Event log
Application Exceptions NT Event log
Successful System Start-up NT Event log
Failed System Start-up/Shutdown NT Event log
Successful User Account Management NT Event log
Failed User Account Management NT Event log
Successful Change of Security Policy NT Event log
Failed Change of security Policy NT Event log
Write Access to Files Write access to files not
available
HP Open View will detect any system inactivity on the network and forward such events
to a central Tivoli system.
Audits of failed start-up and shutdowns are dependent on the operability of the operating
system. Again, HP Open View will report any system inactivity.
3.3 Correspondence Servers
As 3.2
4. De La Rue Card Management
As 3.2
5.Post Office Counters
All security related activities are managed by Riposte software and recorded within the
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 31
FUJ00119593
FUJ00119593
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
TMS Journal as defined by the table below.
Action or Event Audit Data
Successful System Log-on TMS Journal
Failed System Log-on As in Ric RCD
System Log-off TMS Journal
Application Exceptions Local NT Event log
Successful Start of Session TMS Journal
Successful End of Session TMS Journal
Failed System Start-up/Shutdown, NT Event log
Successful User Account Management TMS Journal
Successful Change of User Rights TMS Journal
6. Systems Management
Solaris Event servers (front end to the Tivoli central system) will not be accessible to
users either locally or remotely other than for maintenance by system administrators.
Therefore there are no security issues for these systems.
NT servers, holding events and notices in Oracle databases, will follow 3.2 for remote
access. Local access will not be available other than for maintenance by system
administrators.
7. MIS
No system level auditing is planned for Release Ic or later. Access and changes to
sensitive data in CCS and Contract Administration, namely SLA and Invoicing, is
recorded. Authentication of users logging into the Oracle system is not recorded but
details of each user viewing or modifying information is audited in tables.
8. Associated NT functionality not available;
PinICL 5261, 5318. Not all NT events audited (system shutdown).
PinICL 4655, 3726. Specific nature of user account change not defined in audit log.
733 No audit logs are maintained within the OBCS Host System of actions on the Oracle
database since all OBCS processes are ‘batch’ and no data modification takes place
within the processes. The execution of all OBCS processes are logged in the Oracle
Process Audit Table.
TALL All security related activities are managed by Riposte software and recorded within the
TMS Journal. (see above).
TSAA Mitigation:
DYNIX
© The UNIX utility ‘BOMveri/y’ will be scheduled to run at each shift change to
highlight any changes in audit file characteristics. Output will be reviewed by the CFM
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 32
ICL Pathway Ref.:
RELEASE Ic CONTENTS DESCRIPTION __ Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
investigation.
notified ifit detects the use of sw
NT
Tivoli Event Server (TES) in the Wigan Data Centre.
amend fields within the event nor can they delete events.
GENERAL
the user account facilities available in Dynix where appropriate.
two senior support staff plus the Security Manager.
personnel controls; these include but are not limited to:
Security Manager and exceptions escalated to the Pathway Security Manager for
¢ The Dynix utility <script> is to be enabled for all interactive Dynix operational
users, This utility captures all keyboard activity and screen images. <Script> output will
be piped to a secured directory, modifiable only by <root>. It is not possible to login
directly as <root>. Users must login with their unique User Id and su to <root>. The su
to <root> is logged, BMC Patrol will monitor the su/og and cause a Tivoli event to be
« NT will generate messages in the NT Security log according to Audit Policy settings.
« The three event logs on all central NT servers (System, Application & Security) are
polled at 20 second intervals by a Tivoli NT Event Adapter. All events that have been
written to the event logs in the preceding 20 seconds are ‘harvested’ and written to a
e The TES is archived daily and archives are (currently) maintained for 18 months.
«© The TES is managed by dedicated CFM Systems Management Centre staff who can
only change the status of an event (¢.g. from OPEN to ACKNOWLEDGE). They cannot
The Pathway Security Manager will perform periodic physical audits to ensure the
continued application of these mitigations. Details of these audits will be made available
to PDA/FSG, and PDA/FSG will be able to conduct independent audits.
* AILCEM staff providing operational support to the Pathway system are dedicated to
the project i.e. they are not involved in work on any other CFM business.
e The CFM Security Manager will allocate roles in accordance with the ACP, utilising
© Roles requiring access to the Dynix operating system will be divided into those with
a legitimate <root> access requirement, and those with no <root> access requirements at
all. In this way, <root> access will be restricted to the absolute minimum number of
users necessary to maintain efficient operation of the system. For Release 1c that means
¢ Operational procedures will be introduced in addition to existing physical and
¢ Two man working if <root> access is required during the operational day:
e <Root> access outside of the operational day is event driven and is only available to
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 33
ICL Pathway
Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
two members of staff on a rota basis;
e A paper audit log of all such access.
e¢ The NT Admin privilege will be controlled in the same way as <root> (i.e. restricted
to the absolute minimum number of users necessary to maintain efficient operation of
the system).
© The Security Manager will be responsible for the allocation of roles in accordance
with the ACP, utilising the NT privilege facilities where appropriate.
e Passwords associated with <root> and Admin will be administered by the CFM.
Security Manager, whose responsibilities include changing the passwords regularly in
step with the staff rota.
76.1.6
Mitigation
« The Pathway Security Manager is responsible for the issue, control, verification and
modification of cryptographic key material, as described in the document ‘Pathway Key
Process Management for Release 1c’.
« Akey change is a combination of a physical process performed by the key custodian
and an automated Tivoli process to introduce the three elements necessary to satisfy
comprehensive integrity checks.
¢ In addition to the general controls described below, an independent audit of key
changes is maintained by the Pathway Security Manager.
¢ The UNIX utility *BOMverify’ will be run at each shift change to highlight any
changes in file characteristics. Output will be reviewed by the CFM Security
Manager and exceptions escalated to the Pathway Security Manager for
investigation,
© The Dynix utility <script is to be enabled for all interactive Dynix operational
users, This utility captures all keyboard activity and screen images. <Script> output
will be piped to a secured directory, modifiable only by <root>. It is not possible to
login directly as <root>. Users must login with their unique User Id and su to <root>.
The su to <root> is logged BMC Patrol will monitor the sulog and cause a Tivoli
event to be notified if it detects the use of sw.
GENERAL
The Pathway Security Manager will perform periodic physical security audits to
ensure the continued application of these mitigations.
AILCEM staff providing operational support to the Pathway system are dedicated to
the project i.e. they are not involved in work on any other CFM business,
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 34
FUJ00119593
FUJ00119593
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
© The CFM Security Manager will allocate roles in accordance with the ACP, utilising
the user account facilities available in Dynix where appropriate
e Roles requiring access to the Dynix operating system will be divided into those with
a legitimate <root> access requirement, and those with no <root> access
requirements at all. In this way, <root> access will be restricted to the absolute
minimum number of users necessary to maintain efficient operation of the system.
For Release Ic that means two senior support staff plus the Security Manager.
© Operational procedures will be introduced in addition to existing physical and
personnel controls; these include but are not limited to:
© Two man working if <root> access is required during the operational day:
© <Root> access outside of the operational day is event driven and is only available
to two members of staff on a rota basis:
A paper audit log of all such access.
77 Audit facilities for Windows NT systems at Release 1¢ will be provided through use of
the Tivoli Systems Management software.
4.10.6 ADDITIONAL NT FUNCTIONALITY NOT AVAILABLE
PinICL 3888, 4425, 4517, 5223. List of excluded passwords.
PinICL 5229. NT 3.51 (as used at Help Desk) does not default to force change of password on first log on.
Mitigation; manual process to ensure that administrator sets initial password to auto expire.
4.10.7 CRYPTOGRAPHIC FUNCTIONALITY
All cryptographic functionality identified in SFS section 8 is provided with the following
exclusions:
83 TIP Links will not be supported at Release Ic.
8.3.1 POCL TIP Link protection
Protection in later releases is deferred as described in the SFS
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 35
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
84 APS Links will not be supported at Release Ic.
8.6.2 Post Office ISDN/PSTN/GSM Links, Roll-out: The first real CHAP key and the Post
Office’s private key for use in signing automated payments are transferred from
KMS as part of the personalisation process
KMS will not be available, a simple algorithm will be used to determine the initial
CHAP key, and the AP signing key is not needed as AP signing is not provided in
Release Ic.
8.6.3 Post Office ISDN/PSTN/GSM Links, Key management: CHAP keys will be
replaced at regular intervals.
The CHAP key will not be replaced during the life of Release Ie.
4.10.8 MESSAGE PROTECTION
Message protection identified in SFS section 9 is provided in Release 1c with the following
exclusions:
9A, Key management: Working public keys are distributed by KMS
The life of public keys is long enough not to need to change during Release Ic and
before the next release
94 Automated Payments are signed in the Post Office and the signature will be verified
just prior to delivery of the AP data across the agreed delivery interface
Signing AP transactions is not in Release Ic due to implementation and KMS (Key
Management System) issues
4.10.9 FILESTORE ENCRYPTION IN POST OFFICES
Filestore encryption identified in SFS section 10 is provided in Release Ic.
4.10.10 ADMINISTRATION OF SECURITY
Management and operational controls identified in SFS section 11 are provided in Release Ic.
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 36
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
FUJ00119593
FUJ00119593
Ref.: PA/STR/0006
Version: 4.0
Date: 22/09/97
4.10.11 ACCESS CONTROL ISSUES
The following table identifies the remaining issues raised by the PDA in the area of Access
Control for which there is no agreed resolution at Release Ic..
1. Access differentiation is required at lower than the button
impulse. (e.g. allow a supervisor to create a supervisor but
disallow the creation of a manager.
Resolved by agreement with PDA
Security Management over restriction
of ‘Create User’ facilities to only the
most senior level of user.
1. Once created, the full name and teller ID must not be
accessible for modification by users.
Teller ID is an optional field which is
not used within the application.
1. There is a requirement to restrict password re-usage by
user (preference is password disallow attribute to be set to
3)
This facility is supported only for the
most recent password (i.c. the user
may not enter a new password which
is the same as the one previously
used). Full implementation of
password histories is not currently
supported by NT4 Application
Programming Interfaces (APIs).
Manual Procedure Required at
Release Ic.
4. There is a requirement for the password and user ID
formats to be restricted to a maximum size.
Maximum sizes are not supported by
NT4, Manual Procedure Required at
Release 1c.
1. There is a requirement for logon procedures to comply
with best practice as exemplified within BS 7799 / DITSS
e.g. Computer misuse warnings: unsuccessful logon
attempt warnings.
Computer misuse warnings will be
delivered as part of Release Ic.
Unsuccessful logon attempt warnings
cannot be delivered currently since
NT4.0 does not support the APIs
necessary to determine the status of
the previous logon attempt.
6. User groups which are not appropriate to within outlet use
should not be accessible of viewable from the outlet.
Only groups which are appropriate to
an outlet are displayed. In the event
that an authorised user assigns
multiple roles which include a
‘visitor’ role (e.g. Auditor), the
characteristics of the ‘visitor’ role
take precedence.
Printed: I DATE \1]
C:\OFFICE\TMP\TO20\pastr006.doc Page 37
COMMERCIAL IN-CONFIDENCE
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.11 FRAUD RISK MANAGEMENT AND BPS MIS
The requirements and contractual obligations have been taken from the following source
documents:
1. Benefit Payment System MIS Catalogue, Issued Version 4 dated 11 December 1996
2. Fraud Risk Management Service Design, next version following Version 2.0 dated 14 Th.
November 1996 (yet to be issued)
3. Schedule BO1, Requirement 895, Version inclusive of drop-down amendments.
4. Extended Verification Process Requirement, Draft Version 0.5 dated 11 October 1996
At Release Ic, some of the required reports will be passed to the CA clerically rather than
electronically. This will include details of real or suspected fraudulent transactions, sufficient
(as agreed with CA) to support case investigation.
Functionality at Release Ic is documented in “Fraud Risk Management and BPS MIS Release
1 Contents” ref. RS/SPE/0004, again to be updated following issue of new version of
FRMSD [2] above.
The following sections identify known limitations regarding the implementation of Fraud
Risk Management.
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 38
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.11.1 FRAUD RISK MANAGEMENT AND BPS MIS - RELEASE 2
All the following requirements have all been deferred to Release 2. This deferral assumes
that the DSS will have established a central Fraud Case system which is capable of
communicating electronically with Pathway’s Data Warehouse. If this interface is agreed by
dates to be defined by Pathway, then Pathway can develop and implement the required FRMS
database on the Data Warehouse for release 2.
—
oo
needs FRMS database
Total number and value of
fraudulent Permanent and Casual
agent transactions by region and as
a percentage of all fraudulent agent
transactions.
[23.4 252 Total number and value of needs FRMS database
fraudulent transactions by loss
category by region.
[2] 3.4 2. Total number and value of needs FRMS database
fraudulent transactions by region.
[213.4 2.5.2 Total number and value of all needs FRMS database
fraudulent transactions.
[2] 3.4 2.5.2 Average value of fraudulent needs FRMS database
transactions.
[2] 3.4 2.5.2 Total number and value of needs FRMS database
fraudulent transactions by benefit
type.
[2] 3.4 2.5.2 Average value of fraudulent needs FRMS database
transactions by benefit type
[2] 3.4 2.5.2 Total number and value of needs FRMS database
fraudulent transactions by customer
type (Beneficiary, Appointee,
Casual Agent, Permanent Agent).
[2] 3.4 2.5.2 Total number and value of fraud Not defined at this stage, but
losses by type of loss category expected to include Card: lost,
stolen, counterfeit.
Needs FRMS database
[2] 3.4 2.5.2 Total number and value of foreign I needs FRMS database
transactions by loss category.
(213.4 25.2 List of PUNs reported not received I New Help Desk Functionality
but card collected. Required
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 39
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
FUJ00119593
FUJ00119593
Ref.: PA/STR/0006
Version: 4.0
Date: 22/09/97
At the end of each quarter a report
incorporating the above quarterly
reports in an aggregated format
will be provided. The report will
also detail any identified trends
that fall outside of the above
reports. These will be compared
against previous reports in order to
monitor long term fraud control.
Use of Business Objects
vv
a
is)
At the end of each ICL Pathway
financial year a full report
incorporating the above in an
aggregated format will be
provided. ICL Pathway FRMS
will also report on the identified
trends occurring during the year.
These will be compared against
previous years in order to monitor
long term fraud control.
Use of Business Objects
v
ay
iy
Post Offices where the number of
individual frauds are > than X.
needs FRMS database
v
iw
i
Post Offices where levels of fraud
loss is > X.
needs FRMS database
nv
a
i
Post Offices where there is a higher
than X incidence of fraudulent
foreign and / or agent encashments.
This will most likely be
expressed as a percentage of total
office transactions.
Needs FRMS database
(2)35
nN
al
i)
Post Offices where fraud losses >
than X occur involving a particular
type of Identification Document
(where recorded) or extended
verification procedures.
needs FRMS database
v
iw
iv
Post Offices where more than X
fraudulent transactions are made by
Casual Agents.
needs FRMS database
N
“
is)
Post Offices where more than X
percentage of all transactions are
fraudulent
needs FRMS database
1
in
iv
Customers who have been issued
with a second reminder PUN.
Function issuing 2nd PUN
reminders to be enhanced to
produce a summary list of
customers. Awaiting CMS CP to
be raised & impacted.
(2135
Customers who have infringed
Additional functionality to CMS
Printed: I DATE \1]
C:\OFFICE\TMP\TO20\pastr006.doc
COMMERCIAL IN-CONFIDENCE
Page 40
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
7 a
I.
.
ee
2.5.2 Change of Nominated Post Office I required. Only relevant to those
rules. cases where Restricted Post
Office Indicator is set.
Allow transaction data identified as I needs FRMS database
representing real or suspected
fraud to be copied from the Data
Warehouse to the FRMS Database.
This will enable flags to be applied
to monitor the progress of
investigation.
Allow flags to be altered that are needs FRMS database
attached to transactions which have
been investigated for actual or
suspected fraud. This will allocate
the transaction and value to one of
a number of loss categories, and
will allow full accounting. fraud
analysis and assist in the
determination of liability.
Ensure that flagged data relating to I needs FRMS database
actual and suspected fraud is
retained within the FRM Database
for a period of time beyond that
used for normal transactions to
enable a full and detailed ICL
Pathway fraud history to be
compiled and used to determine
future fraud prevention measures
and as evidence.
R13
v
in
i
Analyse the database using rules to I All non-functional requirements
identify potential fraud incidents;
these rules require definition and
agreement by ICL Pathway and the
Contracting Authorities.
Be sufficiently flexible to
automatically produce reports
according to parameters set, and
allow ICL Pathway FRMS to
amend these overnight. This only
applies to the FRMS Database,
those reports being produced from
other parts of the system will
require a longer notice period.
Be accessed by dedicated PC
workstations.
Be fully auditable, password
to be addressed and met on the
introduction of the FRMS
database at release 2
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 41
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.:
Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
oe
_
_
.
_ non
protected and able to produce
activity logs for each operator
including terminal ID, log on/off
times and files/records accessed.
This system will be automatic
requiring no manual input by ICL
Pathway FRMS management
(2)32 25
iv
In order to carry out effective
Fraud Risk Management the
system will be able to access and
retrieve all information associated
with fraudulent or suspect
transactions. If all the information
required in the data capture list is
not available within the data
warehouse, the FRM system will
be able to retrieve it from other
Pathway databases such as PAS
and CMS.
needs FRMS database
R132 23.
iy
The placing of fraud flags on
particular transactions will instigate
automatic retrieval of associated
items of information, which may or
may not be held within the data
warehouse. ICL Pathway FRMS.
will only be able to place these
flags once the repudiated
transaction becomes known to the
FRMS. Therefore a mechanism for
passing this information from the
Contracting Authorities to ICL
Pathway FRMS is required. ICL
Pathway FRMS will inform the
Contracting Authorities of suspect
events through an exception
reporting process as ICL Pathway
becomes aware of such
occurrences.
Once a fraud has been confirmed
and a final category flag relating to
that event has been posted, the
event will be linked to any
appropriate previous reports. This
will allow a full fraud and
transaction history to be built up
within the FRMS Database and
hard copy reports to be produced
The ICL Pathway FRMS Database
needs FRMS database
Printed: I DATE \1]
C:\OFFICE\TMP\TO20\pastr006.doc
COMMERCIAL IN-CONFIDENCE
Page 42
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
will also allow information to be
recalled by using any of the
individual pieces of data as the
search field.
(214.6 25.
iv
All PCs will be subject to access All non-functional requirements
controls and located in a physically I to be addressed and met on the
controlled environment with a full I introduction of the FRMS.
audit trail enabling ICL Pathway database at release 2
FRMS management to trace what Needs FRMS database
information was accessed and by
whom.
A separate Data Protection entry in
the FRMS Database may also be
required and the production of full
operator activity sheets will allow
management to investigate any
alleged breaches of the Act. It will
be possible to show who requested
a report, when the request was
made, when the information was
made available and when it was
finally accessed and, where
appropriate, printed.
i
n
”
ie)
The system will also have access Definition required, introduce
control to indicate and prevent an with FRMS database at release 2
ICL Pathway FRMS operator of
the FRMS Database accessing data
relating to an account deemed to be
sensitive by the Contracting
Authorities i.e. a National
Sensitivity Indicator is set, unless
authorised to do so.
vv
a
iv
io
Bl Monthly reports of individual Need changes to reference data
instances of non encashment of a sourced through CAPS such that
means tested benefit for a period of I Payment Description carry 2 new
(four weeks) signals + new CMS report
Bl2 25.22 Monthly reports of individual Need changes to reference data
instances of non encashment of a sourced through CAPS such that
non means tested benefit, specified I Payment Description carry 2 new
according to benefit type (e.g. signals + new CMS report
incapacity benefit), for a period of
(six weeks)
BI3
Monthly reports of individual Cardholder record needs to
instances of change of nominated change to add last to POs + date
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 43
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
FUJ00119593
FUJ00119593
Ref.: PA/STR/0006
Version: 4.0
Date: 22/09/97
.
_
_
I.
.
post office, not reversed within (six
weeks), where there is both
encashment of any means tested or
specified non-means tested benefit,
whose date of first availability is
after the change of nominated post
office, and where there is no
notification of change of address
received within (six weeks).
change + last change of address
date, + new CMS report
BIS 252.2 Monthly reports of individual New CMS report from exception
instances of any encashment made I file - assume these are also
after a payment stop has been reported back through CAPS
received by Pathway
2.5.2.2 Daily reports of transactions at a CMS functionality required to
319 non-live post office i.e. one record office temporarily out of
reported to Pathway as temporarily I commission then to reinstate -
out of commission these records to be made
available to MIS
{iyi Number of Cards Issued Report is being produced at
release Ic by everything except
DSS Issuing Office. Assume
reference data mapping of Post
Office to DSS Issuing Office to
BA region is resolved at release
2.
[3&5 Number of Calls Received For calls received from BA Staff,
7 the release Ic function only
Average Length of Calls reports by BA Office. Assume
reference data mapping of Post
Office to DSS Issuing Office to
BA region is resolved at release
2.
{iy 12 Ongoing number of cards activated I The release Ic function does not
report by DSS Issuing Office.
Assume reference data mapping
of Post Office to DSS Issuing
Office to BA region is resolved at
release 2.
fiji See next Number of Temporary Tokens Awaiting introduction of
issue of issued temporary token functionality
SADD
[1] 14 See next Random Selection of encashment Awaiting production and impact
issue of records of CP on PMS
SADD
[4] 11 The usage of EVP by Benefit type I EVP functionality within BES to
Printed: I DATE \1]
C:\OFFICE\TMP\TO20\pastr006.doc
COMMERCIAL IN-CONFIDENCE
Page 44
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
TauceBCT I SADD RET] Rew ia
4 : :
be reviewed at release 2
[4] 11 ‘Number of the same question failed I EVP functionality within BES to
as a percentage of all same be reviewed at release 2
question e.g. Day of Birth, failed,
as a percentage of all Day of Birth
questions.
[4] 11 Breakdown by percentage of EVP functionality within BES to
successful to failed EVP be reviewed at release 2
transactions by Post Office and or
Benefit Type.
Printed: I DATE \1]
C:\OFFICE\TMP\TO20\pastr006.doc
COMMERCIAL IN-CONFIDENCE
Page 45
FUJ00119593
FUJ00119593
FUJ00119593
FUJ00119593
ICL Pathway Ref: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
4.12 SCHEDULE B03
Release Ic includes limited functionality to measure SLAs and to calculate Liquidated
Damages. Schedule B03 assumes that the target component times will be established during
Operational Trial, and that Actual System Component Times will be recorded by the system.
The exact mechanism had not been agreed at the time that the original Release] Contents
Definition was authorised: it remained the subject of discussions and CCNs which may have
had a material impact on measurement methods. Consequently, the way in which Release Ic
measures the SLAs may not correspond with what was ultimately agreed for Schedule BO3
and its replacement Schedules. Any such differences will be addressed in Release 2.
4.13 BOUNDARY SERVICE PERFORMANCE LEVELS
The mechanisms for monitoring and reporting internal boundary service performance levels
for TMS/CMS/PAS will not be available in Release lc.
Printed: [I DATE \!] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 46
ICL Pathway
RELEASE Ic CONTENTS DESCRIPTION
Ref.:
Version:
Date:
FUJ00119593
FUJ00119593
PA/STR/0006
40
22/09/97
ANNEX I :- CONTRACTUAL FUNCTIONAL BASELINE
Security Functional Specification RS/FSP/0001 2.0 Approved
Service Architecture Design Document I CR/FSP/0004 2.0 Approved
Fraud Risk Management Service Design I RS/POL/0002 2.0 Approved
Specification
CAPS Access Service High Level Design I SU/DES/0001 5.0 Approved
CAPS to PAS/CMS Data Interchange PTA/PR/0008 06 Approved
Definition
BPS MIS Requirements Catalogue BS/REQ/001 3.0 Approved
OBCS Business Process Rules BP/PRD/0002 2.0 Approved
DSS Client Interface Specification - OBCSINT ol Approved
OBCS
OBCS Interface High Level Design SU/DES/003 2.0 Approved
Printed: [ DATE \1] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 47
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
ANNEX 2 :- RELEASE 1C TECHNICAL AND PHYSICAL
ENVIRONMENT - ISSUE 4 (4/9/97)
Apart from the use of Bootle to hold a single correspondence server, the
Wigan site only is used at Release 1C. The Wigan site has comms connections
through to the CAPS ACC at Livingstone and the ESNCS system at
Washington
“4 Correspondence Servers in a single group (3 at Wigan and I at Bootle) are
deployed at Release 1C
inion ta he ee
3.1.3.9.2.1.2 I ‘Online CAPS operation is not provided at Release IC
“Single site only at Release 1C (Wigan) with 2 hardware mirrors of the
databases held on Symmetrix disks
[Access to a single ACC (Livingstone) is providedat
Release Ic start. During the lifetime of Release 1c a separate plan exists to
introduce new CAPS functionality
(tnulti service / Single ACC then multi service / multi ACC)
Transfers in the direction from CAPS to Pathway are integrity protected using
a Red-Pike encrypted checksum.
3232 Singie campus (Wigan) at Release 1C
At Release Ic, connection is made to the De La Rue site in Tewkesbury only
for card and PUN production.
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 48
FUJ00119593
FUJ00119593
ICL Pathway Ref.: PA/STR/0006
RELEASE Ic CONTENTS DESCRIPTION — Version: 4.0
Date: 22/09/97
No connection to Royal Mail is provided at Release 1c
4.1.3.3.5.1 The target “time service’ is not provided.
At Release Ic, for Pathway’s own operational purposes, counters and
correspondence servers are time synchronised using native Riposte facilities.
Central systems (including the correspondence servers) have their time set and
synchronised manually.
4.1.5.1 Mobile configurations are not provided at Release Ic.
415.12 Support for weigh scales is not required at Release Ie
“I "TMS will support approximately 5000 counter positions at Release Ic. The
release is expected to be installed at approximately 500 counter positions and
thus there is no constraint in practical terms.
415.16 Standard OPS configuration only
4.1.5.1.7 I Mobile configuration not supported at Release 1C
4.1.5.2.3.1
4.1.53.1 No connection to Huthwaite or Farnborough at Release 1c, As a temporary
expedient until the POCL TIP system becomes available, ‘ABED” reports will
be generated and transferred to Chesterfield via a modem connection.
inted: [DATE \I] COMMERCIAL IN-CONFIDENCE
C:\OFFICE\TMP\TO20\pastr006.doc Page 49