WBONO001078
WBON0001078
From: "Gribben, Jonathan":
To: "Westbrook, Mark (UK - Manchester) I
Date: Thu, 11 May 2017 14:02:37 +0000
Importance: Normal
Inline-Images: image1c9dbd.JPG; imageba95e3.PNG; imagefd6aa4.PNG; image657bd5.PNG
Mark,
Further to the call earlier, which seemed to be constructive from my perspective, I think that the next steps are:-
produce a full description of what a Super-User would need to do in order to amend a branch's accounts in a way that
could would not leave behind a footprint of their activity (noting that they would never be able to completely cover their
tracks because the deletion of Super-User audit files would also leave a footprint);
scope the analytics that you could carry out in relation to Super-User activity on Horizon Online;
follow up with Torstein for: (1) his response to question 6 (the one that slipped his mind); and (2) the technical
documentation that Gareth said that Alan Holmes would be able to provide in relation to Riposte.
Do you agree?
It would also be useful if you/Lewis would summarise what Gareth said about it being more difficult to tamper with
Riposte.
Feel free to give me a call to discuss.
Thanks
Jonny
Jonathan Gribben
Managing Associate
Bond Dickinson LLP
Follow Bond Dickinson:
WBD_000948.000001
WBONO001078
WBON0001078
www.bonddickinson.com
@ ) ses Legal Adviser
&®D 01517
OVERALL BEST
LEGAL ADVISER
From: Keating, Lewis (UK - Leeds)
Sent: 11 May 2017
To: Russell.Normai ‘Torstein.O.Godesethi GRO pete.newsome! GRO i
Westbrook, Mark (' ; Gribben, Jonathan .
Subject: RE: Further Project Bramble discussion - Riposte
Hello all
Please find below a list of questions, as previously discussed, for the call @ 1pm.
Thanks
Lewis
Walkthrough of the Cryptographic Process
Step through the cryptographic process between Counter and BRDB onwards to Audit Store to refresh
understanding with a view to obtaining a view on the following specific questions:
Horizon Online
Is the segregation of duties breach between database administration and the key management server,
the only way in which a weakness could be exploited to overwrite transactional information in a way
where it cannot be traced and looks legitimate to the system?
Is 1am the following day stipulated as the date and time by which overwrite would need to be achieved
by due solely to the audit store, and if so are there not other more timely data feeds which would
highlight a discrepancy between actual ‘transactional reality’ and what is recorded in the Audit Store or
the BRDB?
For step 6 of the replacement routine, can you remind us the technical reasons for requiring access to
the BAL Private Key?
On step 9 on the super user audit log — how long can this log be edited by the super user? Same lam
window before transmission to the Audit Store? Also a reminder that it is the hardware protection
rather then the digital seal which is important on the Audit Store due to the usage of the cracked MDS
algorithm for sealing?
WBD_000948.000002
WBONO001078
WBON0001078
On the point on editing the log, if I’m reading correctly it would always be possible to see the last action
by the superuser, even if they deleted all else?
Can we provided further detail on how the attached would work - ‘In order to make the changes to the
Message Log described in section 2.2, the Super User would need Read access to the Key Store
database which runs on the NPS and Read / Write access to the BRDB. Note that should the rogue
application run on the BAL, then this isn’t necessary as the BAL's have access to the Key store based
on the IP address.”
5a. Could a superuser (theoretically) cover their tracks completely by removing log on / log off
activity from the audit log without leaving a trace? If not how feasibly is a comparison between all log
on/ log off activities of super-users’ and MSCs in order to detect un-authorised access?
‘Although the Database Audit tables are not regularly examined they were recently checked as part of
an external Audit of Horizon Online.’ - Could you provide further context on this audit? What was
checked and why?
How often would the individuals who contravene access SoD between the NPS and BRDB tend to logon
to the NPS? Also does the point raised on not needing to logon with access to the BAL broaden this
concern?
For step 2, how big is the average message log associated with any log on session. (i.e. is a log on
session generally all day and therefore the message log will hold thousands of transactions?)
For step 4, are there any barriers to uploading this application onto Fujitsu systems (if this would be
required). Presumably this would be required due to the volume of work required?
. For step 5, what is meant by ‘similar’?
. On step 8, is there a formal control operated by Fujitsu which can be referenced which would provide
evidence for ‘any instance of slow running on the system would be investigated by the support teams’.
If not can we articulate how obvious this would be to evidence it would be picked up in BAU activity?
. For step 9, can we expand on the relationships between data held in the message log and in branch
accounts (or database tables which feed counter reporting). We would like to be able to articulate the
degree of difficulty amending both sources concurrently would require. And we would like to state this
in terms of:
Timing issues
Complexity (would more programmes be needed)
If this was not done perfectly then would mis-matches be identified / flagged?
Riposte
‘The Riposte product managed the Message Store and it did not allow any message to be updated or
deleted. ‘ - Is there any further information available on this control?
‘Each message also had an associated CRC, this was basically a checksum that was included to ensure
that the message had not become accidently corrupted. Note that this was not a cryptographically
secure seal and it would be possible for a sufficiently technically skilled person to alter a message and
recalculate the CRC if they had access to the message outside the message store.’ - i.e. the level of
protection on Riposte was lower?
The Digital Seal for the Riposte Audit Store remained the same as for Horizon Online - i.e MD5? And
the hardware protection was applied the same as well?
‘Due to the size of the Post Office Network, Branches were split into 4 separate Clusters. Each Cluster
included 4 Correspondence Servers (2 in each Data Centre), thus ensuring that there were normally 4
WBD_000948.000003
WBONO001078
WBON0001078
copies of the data held in the Data Centres.’ - Does this mean you would need to duplicate corrupted
data across 4 servers?
In ‘Detecting Changes to the Audit Trail’ the following is stated, ‘However, if such data were injected at
the Correspondence Server, it would be clear that this had occurred since the Node Id associated with
the message would be that of the Correspondence Server at which the message had been injected and
not a normal Counter Node Id. This would be clearly visible in any audit extract.’ Could this not be
spoofed?
Consideration on the Implications for Fundamental Question Set Posed by POL being:
The key question is whether Horizon accurately and only records the transactions input or approved
by branch staff in a manner that either:-
cannot be added to, deleted or altered; or,
if they can be added to, deleted or altered, such changes will, in all circumstances, be either:
visible to postmasters; or at least
logged and identifiable by Post Office / Fujitsu / a third party expert.
Assuming the above is correct, it should be possible to either:-
prove that no such changes occurred in a particular branch; or
where changes have occurred, identify such changes and show what changed.
The specific outstanding questions are:-
What exact information is logged by the Super-User Audit Logs?
Would this logged information show that:-
a Super-User had done something that could change a branch's accounts in the real-world (e.g. that
the Super-User had amended or deleted a transaction in the Branch Database); and
what that Super-User had done (i.e. does it show the change in such a way that it could be identified
and either isolated or reversed out)?
If the Super-User Audit Logs would not reveal all actions by Super-Users that could affect branch
accounts, please provide a full description of ways in which a Super-User could amend a branch's
accounts in a way that could would not leave behind a footprint of their activity is required.
-----Original Appointment----- ees
From: Russell.Norman GRO
‘orstein.O.Godeseth! ~~ GRO. ] Newsome! GRO i
To: Russell.Norma I i
Keating, Lewis (UK - Leeds); Westbrook, Mark (UK - Manchester)
Subject: Further Project Bramble discussion - Riposte
When: 11 May 2017 13:00-14:00 (UTC+00:00) Dublin, Edinburgh, Lisbon, London.
Where: Skype Meeting
WBD_000948.000004
WBONO001078
WBON0001078
This meeting can move between 12-2 if necessary and will centre around riposte. I will not be attending the call
but will arrange it so please let me know if you would like to change the time.
Fujitsu are aiming to source Gareth Jenkins for this call.
Thanks,
Russell
> Join Skype Meeting
Join by phone
reland External) (UK&l) English (United Kingdom)
(UK & Ireland Internal) (UK&!) English (United Kingdom)
(UK External) (UK&) English (United Kingdom)
Find a local number
Forgot your dial-in PIN? I Help
For the optimal Skype for Business experience, logon to conferences with your PC and use some USB headphones.
If you do not have a set of USB headphones, please order some using the standard process.
Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No
96056); Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker
Street, London W1U 3BW; PFU (EMEA) Limited, (registered in England No 1578652) and Fujitsu
Laboratories of Europe Limited (registered in England No. 4153469) both with registered offices at: Hayes
Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE.
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.
WBD_000948.000005
WBONO001078
WBON0001078
IMPORTANT NOTICE,
This communication is from Deloitte LLP, a limited liability partnership registered in England and Wales with registered number 0C30367S. 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 DTTL 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 DeloitteBusinessSecurit) "} 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.
WBD_000948.000006