FUJ00219881
FUJ00219881
From: Defence Legal (Chris Jay)
Sent: Thur 08/02/2018 11:49:18 AM (UTC)
To: Seddon Dave (BRAO1}
Godeseth Torstein{.
Subject: RE: Project Bramble:
Communication
it corruption wrong format tag - Legally Privileged and Confidential
IMPORTANT - This email or attached documents contains legal advice (or relates to litigation or anticipated litigation) and is being provided in
circumstances for which Legal Privilege may be claimed. Do not copy or forward this document without permission.
Pete (N), Dave, all,
Thanks for your time yesterday and running with this.
Could I request strict compliance by you all with use of the above IMPORTANT banner in your internal
correspondence, [: the “Legally Privileged and Confidential Communication” wording in the “Subject” bar of
your email. Suggest you insert “Project Bramble” at the beginning too.
As a reminder, any area of self- criticism is best not put into written form( as it constitutes a legal “shooting ourselves
in the foot”) should this go to litigation and be discovered by the Plaintiffs lawyers in the course of the litigation
process..
This is because Litigation Legal Privilege (which is the reason for my giving legal advice and involvement and what the
banner is all about — to protect against such discovery ) is not a 100% guarantee of exemption from discovery by the
Plaintiffs lawyers, as a Court Order could be obtained waiving our legal privilege argument.
Hope this is clear.
Many thanks.
Best Regards
Christopher Jay, Senior Counsel
FUJITSU
mpshire, RG22 4BY
Web: http://uk.fujitsu.com
Goes
Fujitsu is proud to partner with Action for Children,
Reshaping ICT, Reshaping Business in partnership with ET.com
wv Please consider the environment - do you really need to print this email?
From: Seddon, Dave (BRAO:
Sent: 08 February 2018 1.
ansal Steve (BRAO1) Defence
Simpkins John
odeseth Torstei
it corruption wrong format tag - Legally Privileged and Confidential Communication
FUJ00219881
FUJ00219881
To answer “We need evidence on how many hard disk faults are occurring especially in the base unit in question
here”:
The office rolled stock unit SP1 from TP7 BP2 to TP7 BP3 on 30/8/2017 on counter 4. The same physical counter is still
in place so I've been able to pull back the windows system events from it. Fortunately the event log hasn't wrapped
yet so it is possible to see all the system events registered since the counter was installed at the office on 11/3/2017.
The following 'disk' events have been raised...
11/4/2017 00:13:05 The file system structure on the disk is corrupt and unusable. Please run the chkdsk
utility on the device with label "".
4/5/2017 00:33:26 The file system structure on the disk is corrupt and unusable. Please run the chkdsk
utility on the device with label "".
18/5/2017 14:58:34 The file system structure on the disk is corrupt and unusable. Please run the chkdsk
utility on the device with label "".
1/12/2017 10:31:22 The file system structure on the disk is corrupt and unusable. Please run the chkdsk
utility on the device with label "".
25/1/2018 13:27:26 The file system structure on the disk is corrupt and unusable. Please run the chkdsk
utility on the device with label "".
6/2/2018 07:33:29 The file system structure on the disk is corrupt and unusable. Please run the chkdsk
utility on the device with labe
..and although none were raised on 30/8/2017 their existence is indicative of the disk not being healthy.
There are also a number of 'bugcheck' events...
24/6/2017 05:18:38 The computer has rebooted from a bugcheck. The bugcheck was: 0x0000000a
(0x00000010, 0x00000002, 0x00000001, 0x8012a729). Microsoft Windows NT [v15.1381]. A full dump was not
saved.
4/7/2017 09:22:08 The computer has rebooted from a bugcheck. The bugcheck was: 0x00000050
(0xc76b5390, 0x00000000, 0x00000000, 0x00000000). Microsoft Windows NT [v15.1381]. A full dump was not
saved.
19/7/2017 18:14:26 The computer has rebooted from a bugcheck. The bugcheck was: Oxc000021a
(0xe133cc48, 0x00000000, 0x00000000, 0x00000000). Microsoft Windows NT [v15.1381]. A full dump was not saved.
14/10/2017 04:39:36 The computer has rebooted from a bugcheck. The bugcheck was: 0x0000000a
(0x0079b020, 0x00000002, 0x00000000, 0x80126d5e). Microsoft Windows NT [v15.1381]. A full dump was not
saved.
10/11/2017 06:03:59 The computer has rebooted from a bugcheck. The bugcheck was: 0x0000000a
(0x6851e059, 0x000000ff, 0x00000000, 0x8010882d). Microsoft Windows NT [v15.1381]. A full dump was not saved.
24/11/2017 11:33:53 The computer has rebooted from a bugcheck. The bugcheck was: Oxc000021a
(0xe1371be8, 0x00000000, 0x00000000, 0x00000000). Microsoft Windows NT [v15.1381]. A full dump was not
saved.
2/12/2017 06:30:17 The computer has rebooted from a bugcheck. The bugcheck was: Oxc000021a
(Oxe1326528, 0x00000000, 0x00000000, 0x00000000). Microsoft Windows NT [v15.1381]. A full dump was not
saved.
30/12/2017 14:13:50 The computer has rebooted from a bugcheck. The bugcheck was: O0x0000001e
(0xc0000005, 0x8011225a, 0x00000000, 0x00000008). Microsoft Windows NT [v15.1381]. A full dump was not
saved.
As far as I know these system events are not captured by Tivoli and are therefore not available in audit. You have to
look at the actual event log on the counter.
FUJ00219881
FUJ00219881
Regards,
Dave
From: Newsome, Pete
Sent: 08 February 2018 09:59
To: Bansal, Steve (BRAO1)
Defence Legal (Chris Jay,)
homas, Andrew
impkins, John
Godeseth, Torstein
Hulme, Jon
Porter, Steven
Seddon, Dave (BRAO:
GRO. vonnnnennennnd
Subject: RE: Bit corruption wrong format tag - Legally Privileged and Confidential Communication
Hi
As promised on the call last night my questions?
¢ Can we identify a method of checking the data extracted by Jason for this exact manifestation of the
hardware error
o E.g. Search for 0 opening balance and then investigate
¢ Can we document the previously known hardware error
¢ We need to show how these events showed up in the audit trail
e We need evidence on how many hard disk faults are occurring especially in the base unit in question here
I am sure there were other issues brought up by the team and I am happy to add these to the list.
Thanks
Pete
Pete Newsome
Account Manager
Post Office Account, Fujitsu UK&l
Web: http://uk.fujitsu.corr
Web: uk fujitsu.com
& Fujitsu named as
Responsible Business
of the Year
Fujitsu is proud to partner with Action for Children
[-CIO: Global Intelligence for the ClO. Fujitsu's online resource for ICT leaders
‘Sponsors of the 2015 Rugby World Cup
vA Please consider the environment - do you really need to print this email?
FUJ00219881
FUJ00219881
From: Bansal, Steve (BRAO1)
Sent: Tuesday, February 6, 2018 2:00 PM
To: Defence Legal (Chris Jay,)
lewsome, Pete I
Porter, Steven
Seddon, Dave (BRAO1)
mpkins, John}
Bansal, Steve (B
it corruption wrong format tag - Legally Privileged and Confidential Communication
Subject
IMPORTANT - This email or attached documents contains legal advice (or relates to litigation or anticipated litigation) and is being provided in
circumstances for which Legal Privilege may be claimed. Do not copy or forward this document without permission.
Please ensure that this email trail remains restricted to this resolver group and that our legal representative Chris is
copied into all conversations as well as the wording above.
Hi Gents
We need to discuss the following issue and better understand the circumstances, look at ways of identifying if there
have been any other similar occurrences that could result in a discrepancy. Discuss what safe guards are in place,
check bit etc. or could be added such as html tag checking at BAL layer.
Example : Balance C/Fwd in Balance Period (02) : 4124.12- is not appearing on the Next Balance Period (03) because
of wrong tag (OpefingBalance)
so, Balance B/Fwd in (03) is displaying as 0.00
66h = £ = 0110 110
6Eh = n = 0110 ff110
Otherwise f and n are identical. Note that the opening and closing tags are the same (have the same error) so the
corruption will have been in the java.lang.String char[] for the XML element name. That would explain why both
opening and closing tags are the same and wrong — the same java.lang.String is used (Strings are “intern’d” fairly
efficiently — although how efficient/automatic in JRE 1.4.2 I am not sure)
Description
The issue with accounting discrepancy at Upton Heath branch (FAD 312614) occurred on 30" August 2017. This was
not raised by the branch into the ATOS Service Desk at the time and no incident was passed to Fujitsu for
investigation. A POL representative, Shirley Hailstones, raised the issue into the Service Delivery Team during a
phone conversation in the beginning of September 2017.
On 21* September investigation was initiated by the Fujitsu POA SecOps and SSC Team. Peak PC0262558: FAD 312614
key strokes for Balance Period Investigation refers. It was explained the Upton Heath branch experienced an issue on
whereby an accounting error occurred upon rollover from Balance Period 2 to Balance Period 3. The Final Balance
Report was showing a 0.00 figure as a value for “Balance B/Fwd” incorrectly:
FAD 312614 (Upton Heath), node 4 - On 30th August, between 13:40 and 14:10, the balance period was rolled over
from TP7 BP2 to TP7 BP3. There was a C/Fwd balance of £4124.26 for BP2 but after the rollover, printout for BP3
shows a B/Fwd balance of zero.
POL requested an investigation into the keystrokes to show what happened.
After the evidence was generated and made available to POL, the initial Peak was closed on 26" September with a
comment Evidence sent to POL. Closing call.
FUJ00219881
FUJ00219881
The issue was re-opened on 24 November under Peak PC0264684: Incorrect Balance B/Fwd in Balance Report. The
Fujitsu SSC team noted here on 29" November that:
The initial call made no specific reference to the brought forward balance in the respective Final Balance reports from
30/8 & 4/9 which have now been presented as evidence.
Furthermore, given the amount of time elapsed since the initial query critical evidence has now been lost.
Further identifying the nature of the issue, missing from the previous Peak:
What we can see from the balance reports is that the balance carried forward from TP7/BP2 (£4124.12) does not
appear in the balance brought forward figure for TP7/BP3 on 4/9/17.
13:40 30/08/2017 TP: 07 BP: 02 SU: SP1
Final Balance - Office Copy
Balance C/Fwd 4124.12
12:18 04/09/2017 TP: 07 BP: 03 SU: SP1
Final Balance - Office Copy
Balance B/Fwd 0.00
(.)
The Peak PC0264684 also indicated the possible underlying cause of the issue as the lack of opening figures for stock
unit for TP7 BP3.
What we should see are opening figures for stock unit SP1 for TP7 BP3 but none exist (these should be present in the
BRDB_SU_OPENING_BALANCE table). This is the reason for the zero B/FWD balance.
Opening balance data for the other stock units at the branch did exist. It was also pointed out a detailed investigation
was not possible as the counter logs for the period (30/8 - 4/9) had already been unavailable for analysis, as kept for
30 days.
PC0264684 was closed on 9" January 2019, making reference to a new one raised on the same date: PC0265947 FAD:
312614 - Incorrect Balance B/Fwd in Balance Report. The evidence data was replicated under a new Peak reference.
On 10" January the Fujitsu SSC updated the Peak with a recommendation to seek advice from Service Management.
Seeing that an important diagnostics tool (counter logs) were house kept and not available, they were unable to
confirm exactly what happened at the branch.
Steve Bansal
Senior Service Delivery Manager
Business & Application Services
‘ost Office Account
Web: uk.fujitsu.com
Annual leave:
ea] £ I inIe/c-
= Please consider the environment - do you really need to print this email?