POL00030029
POL00030029
Message
From: Parsons, Andrew
Sent: 21/11/2016
To: Prime, Amy I
Subject: FW: Branch Di ditional Questions
Please add this to the chrono
Andrew Parsons
Partner
nd Dickinson
www.bonddickinson.com
From: Hodgkinson, Sean (UK - Manchester) [mail
Sent: 15 May 2014 14:03
To: Westbrook, Mark (UK - Manchester)
Subject: FW: Branch Database and Change Management Additional Questions
Sean Hodgkinson
www.deloitte.co.uk
From: Davidson James [mailto
Sent: 15 May 2014 11:06
To: Westbrook, Mark (UK - Manchester); Hodgkinson, Sean (UK - Manchester); Julie George
Cc: Newsome Pete
Subject: Fwd: Branch Database and Change Management Additional Questions
Hi,
Please see below.
Sent from my iPhone
Begin forwarded message:
From: Simpkins John <.
Date: 15 May 2014 1
To: Davidson James
Subject: FW: Branch Database and Change Management Additional Questions
POL-0026511
POL00030029
POL00030029
James, we did not discuss timescales but I have just been asked by Leighton for some more details
before a 10:30 meeting today.
These are to the best of my knowledge:
Question 1 about the TXN_CORR_TOOL_JOURNAL table.
¢ How does this process operate and who has the ability to be able to perform this e.g. POL
and/or Fujitsu?; and
The normal support route is used to identify when a fix is required, either from a branch raised incident
or estate monitors that alert support staff.
ATES incident would be raised with evidence.
This would be transferred to the SSC as a Peak because they support the applications.
The SSC would investigate with evidence from the support branch database and then liaise 4" line
development {evidence and progress would be recorded on the Peak).
Ath line development would generate the required scripts using a test system to make the correction.
An MSC (or OCP/TFS} would be raised for permission to run the support tool on the live branch
database (BRDBX015).
The SSC would run the script using the support tool against the live estate.
© What monitoring is performed over the table TXN_CORR_TOOL_JOURNAL?
The Support tool is written to run under the SSC (read only role) role and connects internally as the
APPSUP role (write permission).
All changes are written to the AUDIT logs.
The output from the support tool is captured and recorded on the Peak.
I can find just one recorded use of this tool:
Date: 03/03/2010
TFS: 20156
Peak: PCO195561
OCP: 25882
Branch: 226542
Question 2 about JOURNAL_SEQ_DENSE_SET_CHECK_ENABLED setting.
e Can we see evidence to demonstrate that this parameter is currently set to “True”?; and
ran this query against the live BRDB (node 1) today at 09:47
1 select * from brdb_system_parameters
2* where parameter_name = JOURNAL SEQ _DENSE_SET_CHECK_ ENABLED"
These are the results:
PARAMETER_NAME:IOURNAL_SEQ_DENSE_SET_CHECK_ ENABLED
VERSION_NUMBER:1
INSERT_TIMESTAMP:05-OCT-09 04.06.30.0639 AM
START_DATE:05-OCT-09
PARAMETER_DESCRIPTION: Indicates whether sequence checking is required in BRDBCOO2
PARAMETER_TYPE:T
PARAMETER_NUMBER:
END_DATE:
PARAMETER_DATE:
POL-0026511
POL00030029
POL00030029
UPDATE_TIMESTAMP:
PARAMETER_TEXT:
This indicates that this parameter has not been changed since created on 05-Oct-2009
e@ Who has access to be able to amend this parameter and is any proactive monitoring performed
to ensure that it is not altered?
As this is in the database it would require write permission to update the parameter.
This would require access to the APPSUP role which may be granted to the SSC under MSC. Any change
to this role is audited.
{am unaware of any proactive monitoring of these values.
Regards
John
From: Davidson James
Sent: 14 May 2014 16:38
To: Simpkins John
Subject: FW: Branch Database and Change Management Additional Questions
James Davidson
Post Office
Fujitsu
bs]
Fujitsu is proud to partner with Shelter, the housing and homeless charity
Reshaping ICT, Reshaping Business in partnership with ET.com
need to print this email?
a Please consider the environment -
From: Hodgkinson, Sean (UK - Manchester) [mailto:
Sent: 14 May 2014 16:11
To: Davidson James
Cc: Dave M King; Jane E Smith; Rod Ismay
Subject: RE: Branch Database and Change Management Additional Questions
James,
{have been provided with your contact details by my colleague, Mark Westbrook, as somebody who
may be able to assist with technical queries we have in relation to the Branch Database.
Please could you review the email trail below, and advise whether this is something you can assist with?
Kind regards,
Sean
POL-0026511
POL00030029
POL00030029
Sean Hodgkinson
,-Reloitte LLP.
From: Dave M King [mailto! GRO i
Sent: 14 May 2014 11:49
To: Hodgkinson, Sean (UK - Manchester); Jane E Smith; Rod Ismay
Ce: Rodric Williams
Subject: RE: Branch Database and Change Management Additional Questions
Sean
V've had a chat with Jane and I believe the only way we will be able to resolve this is if you get
confirmation from Fujitsu of whether this has ever been done and what the process is (POL have no
direct access to the database). If corrections are needed, “we” insert a transaction to correct the
situation following a reconciliation process rather than make direct changes to any transaction in the
database.
lam ina similar position with the audit trail question
I believe you have a contact in Fujitsu who can confirm directly?
Thanks
Dave King I Senior Technical Security Assurance Manager
field, S49 [PF
From: Hodgkinson, Sean (UK - Manchester) [mailtof
Sent: 13 May 2014 19:27
To: Jane E Smith; Rod Ismay; Dave M King
Subject: Branch Database and Change Management Additional Questions
All,
Following review of the technical design document in relation to the Branch Database, I had a couple of
queries that I was hoping you may be able to help with. If not, please could you direct me toward
somebody who may be able to assist:
1) Balancing Transactions
Section 5.6.2 describes back end database amendment process which is included by design:
Inserting Balancing Transactions
There is a requirement that the SSC will have ability to insert balancing transactions into the persistent
objects of the Branch Database. There are reasons for SSC having to do so e.g. to rectify erroneous
accounting data that may have been logged as a result of a bug in the Counter / BAL.
POL-0026511
POL00030029
POL00030029
SSC will have privileges of only inserting balancing / correcting transactions to relevant tables in the
database. SSC will not have any privileges to update or delete records in the database.
Any writes by the SSC to BRDB must be audited. The mechanism for inserting a correction record must
ensure that the auditing of that action performed must be atomic. There also needs a level of
obfuscation to ensure that the audit mechanism is robust.
The above-mentioned requirements suggest that there is a need for a correction tool to be delivered
which performs the correction, audits it and saves both changes.
A simple low-cost solution for the tool is to provide a Linux shell based utility, which calls a PL/SQL
package to perform the changes. The package will allow inserts to the following transactional tables in
the Branch Database Live schema with the exception of the Message Journal. All inserts will be audited in
the table BRDB_TXN_CORR_TOOL_JOURNAL.
From the above we wish to clarify, with evidence where possible:
¢ How does this process operate and who has the ability to be able to perform this e.g. POL
and/or Fujitsu?; and
© What monitoring is performed over the table TXN_CORR_TOOL_JOURNAL?
2) Audit Store File Generation — Optional Parameter
Section 7.2.2.8 on page 122 describes how:
As records are being written to the audit files, the process must optionally be able to monitor if the set
of Journal-Sequence-Numbers for a node in a Branch is dense. The check should only be performed
when the value of mandatory System-Parameter ‘JOURNAL_SEQ_DENSE_SET_CHECK_ENABLED’ is
“TRUE”. When a missing journal entry is encountered, a message should be written on standard output
along the lines of “...records between sequence numbers M and N are missing...”. Once the list of
auditable messages for a node is completed, an Operational exception should be raised to indicate the
count of missing sequence numbers. Duplicate records are not possible due to the primary key on this
table.
e Can we see evidence to demonstrate that this parameter is currently set to “True”?; and
e Who has access to be able to amend this parameter and is any proactive monitoring performed
to ensure that it is not altered?
Jane - Per our conversation earlier this morning, have you been able to locate any of the documents to
support the ‘Client File Receiving Project’ 2012? As discussed we’d like to see evidence to demonstrate
that the correct plans, approval and testing was performed before the change was applied to live, so
would expect evidence such as:
e Business plans and requirements;
e Steering group minutes;
e¢ Approvals at each stage of development, testing and final go live;
e Evidence of any testing performed during the development life cycle; and
e Post go-live review to ensure business requirements were met and any residual risks were
adequately documented.
If any of you have any questions in relation to the queries raised, please feel free to give me a call.
Kind regards,
Sean
Sean Hodgkinson
Senior Consultant { Audit Advisory
Deloitte LLP
PO Box 500, 2 Hardman Street, Manchester, M60 2AT, United Kingdom
POL-0026511
POL00030029
POL00030029
“ UK ¥ 4
http:/Awww.deloitte.co.uk/ukfutures
IMPORTANT NOTICE
This communication is from Deloitte LLP, a limited liability partnership registered in England and Wales with registered number 0C303675. Its registered
office is 2, New Street Square, London EC4A 3BZ, United Kingdom. Deloitte LLP is the United Kingdom member firm of Deloitte Touche Tohmatsu Limited
(‘DTTL”), a UK private company limited by guarantee, whose member firms are legally separate and independent entities. Please see
www.deloitte.co.uk/about for a detailed description of the legal structure of OTL and its member firms.
This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you
are not the intended recipient(s), please (1) notify itsecurity.uk@deloitte.co.uk by forwarding this email and delete all copies from your system and (2)
note that disclosure, distribution, copying or use of this communication is strictly prohibited. Email communications cannot be guaranteed to be secure
or free from error or viruses. All emails sent to or from a Deloitte UK email account are securely archived and stored by an external supplier within the
European Union.
To the extent permitted by law, Deloitte LLP does not accept any liability for use of or reliance on the contents of this email by any person save by the
intended recipient(s) to the extent agreed in a Deloitte LLP engagement contract.
Opinions, conclusions and other information in this email which have not been delivered by way of the business of Deloitte LLP are neither given nor
endorsed by it.
This email and any attachments are confidential and intended for the addressee only. If you are not the
named recipient, you must not use, disclose, reproduce, copy or distribute the contents of this
communication. If you have received this in error, please contact the sender by reply email and then
delete this email from your system. Any views or opinions expressed within this email are solely those of
the sender, unless otherwise specifically stated.
POST OFFICE LIMITED is registered in England and Wales no 2154540. Registered Office: 148 OLD
STREET, LONDON EC1V 9HQ.
JOR IOSD IOI SODA OIA III IOS OID IOI AS IDI III III
Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or
from Fujitsu Telecommunications Europe Limited, together "Fujitsu".
This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may
be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-
free.
Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U
3BW.
Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U
3BW.
PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park
Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
POL-0026511
POL00030029
POL00030029
Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull
Parkway, Birmingham Business Park, Birmingham, B37 7YU.
POL-0026511