FUJ00237007
FUJ00237007
FUJITSU ES
Description of Fujitsu’s System
of IT Infrastructure Services
supporting Post Office Limited’s
POLSAP and HNG-X
applications
Throughout the Period 1 April 2012
to 31 December 2012
With the independent service auditor's assurance report including tests performed and
results thereof
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Table of Contents
1. I MANAGEMENT ASSERTION...
2. REPORT OF INDEPENDENT SERVICE AUDITOR...
3. DESCRIPTION OF SYSTEM
3.1. Overview of Fujitsu
3.1.1 History of Fujitsu .....
3.1.2 Major Markets and Human Capital 1
3.1.3. Organisational Structure, including Business Units . 1
3.1.4 Geographical Spread ... 12
4.
OVERALL CONTROL COMPONENTS .
4.1 Control Environment
4.2 Integrity and Ethical V:
4.3 Structure for Serving Post Office Ltd.
4.3.1 Service Lines and Functions
4.4 Control Activities...
44.1 Governance and Oversight of Control Act
4.4.2 Human Resources...
4.5 Information and Communication.
46 Monitoring ....
4.7 Risk Assessment
4.7.1 Risk Policy and Implementation .
4.7.2 Fujitsu's Risk Process.
4.8 Services provided .
4.8.1 Physical and Environmental Controls
4.9 IT Operations
4.9.1 Backup ..
49.2 Job Scheduling
49.3 Availability and Capacity inline
49.4 Incident Management
4.9.5 Major Incident Process .
4.9.6 Security Incident Process
4.9.7 Network Incident Management
4.9.8 Networks ......
4.9.9 Change Management
4.9.10 Security...
5. NOTUSED..
6. COMPLEMENTARY USER ENTITY CONTROLS
7. DESCRIPTION OF CONTROL OBJECTIVES, CONTROLS, TESTS AND RESULTS OF
TESTS... 67
7.1 Testing Performed and Results of Tests of Entity-Level Control. 67
7.2 Control Objectives, Control Activities, Testing Procedures and Results of Testin: 67
7.2.1 Control Objective 1 . 68
7.2.2 Control Objective 2 71
7.2.3 Control Objective 3 72
7.24 Control Objective 4 73
7.2.5 Control Objective 5 74
7.2. Control Objective 6 76
7.2.7 Control Objective 7 78
7.2.8 Control Objective 8 80
7.2.9 Control Objective 9 81
7.2.10 Control Objective 10. 83
7.2.11 Control Objective 11. 85
7.2.12 Control Objective 12 87
7.2.13 Control Objective 13 . 88
Table of Contents i
FUJ00237007
FUJ00237007
1. Management Assertion
FUJ00237007
FUJ00237007
FUJITSU
Fujitsu Services Limited’s Management Assertion
12" February 2013
Fujitsu Services Limited (“Fuji , “we”, “Company”) has prepared the
accompanying Description of F system of IT infrastructure services supporting Post
Office Limited's POLSAP and HNG-X applications throughout the period 1 April 2012 to 31
December 2012 (“Description”).
This has been prepared for:
1. Post Office Limited (“POL”) as users of the system during some or all of the period 1
April 2012 to 31 December 2012; and
2. the independent auditors of POL.
POL and its independent auditors are assumed to have a sufficient understanding to consider
the Description, along with other information, including information about controls
implemented by POL itself, when assessing the risks of material misstatements of POL’s
financial statements,
The Company confirms, to the best of its knowledge and belief, that:
a, The Description fairly presents the IT support processes and controls used by and on
behalf of Fujitsu to support the POLSAP and HNG-X applications (“System”) made
available to POL during the period I April 2012 to 31 December 2012 for providing
IT support to the HNG-X and POL SAP applications. ‘The criteria we used in making
this assertion were that the Description:
(1) Presents how the System made available to POL was designed and implemented,
including:
© the types of services provided;
© the procedures, within both automated and manual systems, by which those
services are provided;
© the related supporting information; this includes the correction of incorrect
information and how information is transferred to the reports prepared for
POL;
¢ how the System captures and addres:
ignificant events and conditions;
© the process used to prepare reports or other information provided to POL as the
user of the System;
© specified control objectives and controls designed to achieve those objectives;
© controls that, in designing the System, the Company contemplated would be
implemented by POL. in order to achieve the specified control objectives
(Complementary User Entity Controls); and
© other aspects of the Company’s control environment, risk assessment process,
Fujtsu Services Limited, Registered in England no 96088, Registered Office 22 Baker Street, London, W1U 38W
‘continuation page 2
Signed:
information and communication systems (including the related business
processes), control activities, and monitoring controls that are relevant to the
services provided.
(2) does not omit or distort information relevant to the scope of the System
The Description includes relevant details of changes to the System during the period
from 1 April 2012 to 31 December 2012.
The controls related to the control objectives stated in the Description which together
with the complementary user entity controls referred to above, were suitably designed
and operated effectively throughout the period I April 2012 to 31 December 2012 to
achieve those control objectives stated in the Description. The criteria we used in
making this assertion were that:
(1) the risks that threaten the achievement of the control objectives stated in the
Description have been identified by Fujitsu;
(2) the controls identified in the Description would, if operating as described, provide
reasonable assurance that those risks would not prevent the control objectives
stated in the Description from being achieved; and
(3) the controls were consistently applied as designed, including whether manual
controls were applied by individuals who have the appropriate competence and
authority.
James [
GRO
Davidson
Post Office Account Delivery Executive
Faqtau Sovics Lins, Regateres 9 Engend ns SEOSS. Reagulered fice 26 Prtuey Sauare, London ECZA 181
FUJ00237007
FUJ00237007
FUJ00237007
FUJ00237007
2. Report of Independent Service Auditor
FUJ00237007
FUJ00237007
a
Ernst & Young LLP
1 More London Place
London SE1 2AF
wnt meeerercune
Tel:{
Fax:{
Fujitsu Services Limited
Lovelace Road
Bracknell
RG12 8SN
Scope
We have been engaged to report on Fujitsu Services Limited (“Fujitsu")’s accompanying Description of
Fujitsu's system of IT infrastructure services supporting Post Office Limited's POLSAP and HNG-X
applications throughout the period 1 April 2012 to 31 December 2012 of its system for providing IT
services to Post Office Limited (“POL”) in support of the HNG-X and POLSAP applications throughout
the period 1 April 2012 to 31 December 2012 (Description) and the suitability of the design and
operating effectiveness of controls to achieve the related control objectives stated in the Description.
The Description indicates that certain control objectives specified in the Description can be achieved
only if complementary user entity controls contemplated in the design of POL's controls are suitably
designed and operating effectively, along with related controls at the service organisation. We have not
evaluated the suitability of the design or operating effectiveness of such complementary user entity
controls.
Fujitsu uses a range of network providers to provide Wide Area Network (WAN) services to POL. The
Description includes only the controls and related control objectives of Fujitsu and excludes the control
objectives, and related controls of these network providers. Our examination did not extend to
controls of network providers.
Fujitsu's responsibilities
Fujitsu has provided the accompanying assertion titled, Management Assertion (Assertion) about the
fairness of the presentation of the Description and suitability of the design and operating effectiveness
of the controls to achieve the related control objectives stated in the Description. Fujitsu is responsible
for preparing the Description and the Assertion, including the completeness, accuracy and method of
presentation of the Description and the Assertion and stating the control objectives in the Description.
Fujitsu is also responsible for providing the services covered by the Description, specifying the control
objectives, identifying the risks that threaten the achievement of the control objectives, selecting the
criteria stated in the Assertion and designing, implementing and documenting controls to achieve the
related control objectives stated in the Description.
Service Auditor's responsibilities
Our responsibility is to express an opinion on the fairness of the presentation of the Description and on
the suitability of the design and operating effectiveness of the controls to achieve the related control
objectives stated in the Description, based on our examination. We conducted our engagement in
accordance with International Standard on Assurance Engagements 3402 Assurance Reports on
Controls at a Service Organization, issued by the International Auditing and Assurance Standards
Board. That standard requires that we comply with ethical requirements and plan and perform our
procedures to obtain reasonable assurance about whether, in all material respects, the description is
fairly presented and the controls were suitably designed and operating effectively to achieve the
related control objectives stated in the Description throughout the period 1 April 2012 to 31 December
2012.
FUJ00237007
FUJ00237007
An assurance engagement to report on a description of a service organisation's system and the
suitability of the design and operating effectiveness of the service organisation’s controls to achieve
the related control objectives stated in the description involves performing procedures to obtain
evidence about the fairness of the presentation of the description and the suitability of the design and
operating effectiveness of those controls to achieve the related control objectives stated in the
description. Our procedures included assessing the risks that the Description is not fairly presented
and that the controls were not suitably designed or operating effectively to achieve the related control
objectives stated in the Description. Our procedures also included testing the operating effectiveness
of those controls that we consider necessary to provide reasonable assurance that the related control
objectives stated in the Description were achieved. A reasonable assurance engagement of this type
also includes evaluating the overall presentation of the Description, the suitability of the control
objectives stated therein and the suitability of the criteria specified by the service organisation and
described in the Assertion. We believe that the evidence we obtained is sufficient and appropriate to
provide a basis for our opinion.
Inherent limitations
The Description is prepared to meet the needs of POL and its auditors and may not, therefore, include
every aspect of the system that POL may consider important in its own particular environment.
Because of their nature, controls at a service organisation may not prevent or detect and correct, all
errors or omissions in processing or reporting transactions. Also, the projection to the future of any
evaluation of the fairness of the presentation of the Description or conclusions about the suitability of
the design or operating effectiveness of the controls to achieve the related control objectives, is
subject to the risk that controls at a service organisation may become inadequate or fail.
Opinion
Our opinion has been formed on the basis of the matters outlined in this report. The criteria we used in
forming our opinion are those described in the Assertion. In our opinion, in all material respects:
a. the Description fairly presents the IT support processes and controls used by and on behalf of
Fujitsu to support the HNG-X and POLSAP applications that were designed and implemented
throughout the period 1 April 2012 to 31 December 2012.
b. the controls related to the control objectives stated in the Description were suitably designed
throughout the period 1 April 2012 to 31 December 2012 and if POL applied the
complementary user entity controls contemplated in the design of Fujitsu's controls and
subservice organisations applied the controls contemplated in the design of Fujitsu's controls
throughout the period 1 April 2012 to 31 December 2012.
c. the controls tested, which, together with the complementary user entity controls referred to in
the scope paragraph of this report if operating effectively, were those necessary to provide
reasonable assurance that the control objectives stated in the Description were achieved,
operated effectively throughout the period 1 April 2012 to 31 December 2012.
Description of tests of controls
The specific controls tested and the nature, timing, and results of those tests are listed in the
accompanying Description of Control! Objectives, Controls, Tests and Results of Tests (Description of
Tests and Results).
FUJ00237007
FUJ00237007
I! ERNST & YOUNG
"0"
Intended use
This report, including the description of tests of controls and results thereof in the Description of Tests
and Results, is intended solely for the information and use of Fujitsu, POL as the user of the IT support
processes and controls used by and on behalf of Fujitsu to support the HNG-X and POLSAP applications
during some or all of the period 1 April 2012 to 31 December 2012 and the independent auditors of
POL, who have a sufficient understanding to consider it, along with other information including
information about controls implemented by user entities themselves, when assessing the risks of
material misstatements of user entities’ financial statements. This report is not intended to be and
should not be used by anyone other than these specified parties.
Ernst + Mong LLP
15 February 2013
London
United Kingdom
FUJ00237007
FUJ00237007
Fe)
FUJITSU
3. Description of System
3.1 Overview of Fujitsu
3.1.1 Histor y of Fujitsu
Fujitsu has evolved through a process of acquisition and organic dev elopment to create a broad-based
technology and serv ices organisation, with a strong record of _innov ation and lean serv ice deliv ery.
Fujitsu has a long and successtul history which has links going back more than 40 years.
2003
Gicbsl Business Group Rett ofa shares in
Operaions usted under ——— > Fugteu Slamens Computers
fee Vansaatonairrooet
904 I aor
Firstrmult-piayer game to 4 wack first 2eo
be played over anetwor: aes, SC Seer
1982
Warke's first 21° fab «I e— ine auction
Dynamic
bifawucurs,
Jv Somers
Ntehert
chou plasma screen —— ore
Colour plasma scree eos
rast
Nokia Dota
secusiton ae
1900 ~
1980
1373 4
mae a asemiears
Auocgitean, Tost
mmogen I factory
ir Earope, opened
tore
span Cooperstionwih
Jbpar's first suomaed
dectrone comguter the FACCM 180
Figure 1. Fujitsu’s Growth in Services through Acquisition Organic Development
The recent history of the com pany in Europe began in 1968 as International Com puters Limited (ICL),
formed through the m erger of English Electric Computers (EEC) and International Computers and
Tabulators (ICT), in response to the increasing m_ arket dominance of the large Am erican corporations.
The company was listed on the stock m arket until it was acquired by Standard Telephones and Cables
(STC plc) in 1984.
In 1990, the Japanese IT Serv ices Company, Fujitsu Ltd, acquired an initial 80% stake f or £740million.
Further acquisitions were made by Fujitsu in 1993 and 1996 from STC, (then owned by Nortel), with the
remaining interest in the company being acquired in 1998.
In April 2002, ICL fully re-branded to Fujitsu Services Limited (FSL), and later as Fujitsu, as it looked to
exploit the Fujitsu Group's ex pertise and technology, including its extensiv e R&D spend. FSL (Fujitsu)
now operates as the UK and Ireland IT Services-based arm of the global Fujitsu Group.
Description of Fujitsu's System 10
FUJ00237007
FUJ00237007
Re)
FUJITSU
In 2009, we integrated Fujitsu Siem ens Computers (FSC) into the organisation, representing an ex citing
step in Fujitsu’s strategy for growth, and forming the new Technology Solutions Division (TSD). This new
division has a portfolio that encompasses Infrastructure Products and Solutions, Managed Services and
Infrastructure as a Service.
Following the creation of the new Technology Solutions Division, Fujitsu announced the formation of the
Global Business Group which inv olved an operating m odel based on the creation of 8 regions anda
number of global support functions.
The UK and Ireland (UK&l) region was formed, merging the ex pertise previously delivered by Fujitsu
Services and the product know-how from Fujitsu Siemens. Operating under the name of Fujitsu (UK and
Ireland) the company provides integrated technology offerings and business solutions.
3.1.2 Major Markets andH —uman Capital
Fujitsu UK and Ireland is a leading IT systems, services and products company employing 11,400 people
with an annual revenue of £1.7 billion. Its business is in enabling its custom ers to realise their objectives
by exploiting information technology through its integrated product and serv _ ice portfolio. This includes
consulting, applications, systems integration, managed services and product for customers in the private
and public sectors including retail, financial services, telecoms, and government, defence and consumer
sectors.
3.1.3 Organisational Structure, including Business Units
Pay
Leadon sales and
demand generation,
By
ServiceLines —
alignedte how our
customers buyIT
x)
Functions!
shared services
teams
Figure 2. Fujitsu UK and I Organisation
Description of Fujitsu's System 11
FUJ00237007
FUJ00237007
Fe)
FUJITSU
3.1.4 Geographical Spr ead
Fujitsu operates in the following Regions:
© Af rica.
¢ Central Am erica and Caribbean.
¢ North Am erica.
© South Am erica.
° Asia.
Australasia.
« Europe.
Middle East.
Description of Fujitsu's System 12
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4. Overall Control Components
This section provides information about the five interrelated components of internal control at Fujitsu:
e Control Environment - sets the tone of an organisation, influencing the control consciousness
of its people. It is the f oundation for all other components of internal control, providing discipline
and structure.
e Control Activities — are the policies and procedures that help m ake sure that m anagement's
directives are carried out.
e Information and Communication — are systems, both automated and manual, that support the
identification, capture and exchange of information in a form and time frame that enable people
to carry out their responsibilities.
« Monitoring — is a process that assesses the quality of internal control perbrmance over time.
e Risk Assessment - is the entity's identification and analysis of relev ant risks to the
achievement of its objectives, forming a basis for determining how the risks can be managed.
Fujitsu internal control components include controls that may have a pervasive effect on the organisation,
an effect on specific processes, account balances, disdosures, classes of transactions or applications, or
both. Some of the components of internal control include controls that have more of an effect at the entity
level, while other com ponents include controls that are prim _arily related to specif ic processes or
applications. W hen assessing internal control, we consider the interrelationships am ong the fiv e
components.
4.1 Control Environment
Management has established and m aintains an internal control structure that m onitors compliance with
established standards, policies, and procedures. The remainder of this subsection discusses the tone at
the top as set by Leadership and Managem ent, the integrity, ethical v alues and competence of Fujitsu
employees, the standards, policies and procedures, the risk m anagement process and m onitoring and
the roles of significant control groups. The internal control structure is established and ref reshed based
on Fujitsu's assessment of risk facing the organisation.
4.2 Integrity and Ethical Values
Fujitsu recognize their responsibility to foster a strong ethical environment to determine that its business
affairs are conducted with integrity, and in accordance with high standards of _ personal and corporate
conduct. This responsibility is characterized and reflected in the Fujitsu W ay Code of Conduct, which is
understood by allem _ployees of the organisation. Allem ployees are required to maintain ongoing
compliance. Compliance checks are undertaken to help ensure that em ployees understand and comply
with the Fujitsu Way Code of Conduct.
Description of Fujitsu's System 13
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.3 Structure for Serving Post Office Ltd.
4.3.1 Service Lines and Functions
During the past 12 m onths Fujitsu UK and Ireland has re-organised its structure into Serv ice Lines and
Functions. The Service Lines and Functions that prov ide services, or support the deliv ery of service to
PO Limited (POL) are as follows:
Business and Applications Services (BAS) (Direct to POL).
« End User Serv ices Group.
e Hosting and Network Serv ices Group.
* Technology Product Group.
« Business Operations & Business Ex cellence.
«Comm ercial and Legal Assurance.
e Finance and Strategy.
«Hum an Resources.
« Sales and Marketing.
The purpose of these Service Lines and Functions is to enable, organise and facilitate the requirements
placed on the Fujitsu Post Office Account (POA) by POL.
The management of the above Service Lines and Functions establish their own f rameworks within their
areas for the continuous formal support of POA and enforce this through their own policies, procedures
and standards, and registers, including where applicable internal and external audits. The procedures to
support POA are set out in each area’s own implementation of the Fujitsu Business Management System
(BMS). The controls in place in each of these Services Lines and Functions help ensure that the areas
have overall objectives, terms of reference, job descriptions and senior management roles. Each of these
functions has its own lev els of management, staff, directors and stakeholders all of which im pact the
service that POA is able to prov ide to POL. Each of _ these Serv ice Lines and Functions is also
responsible for ensuring that their staff are appropriately trained and f ollow Fujitsu Corporate processes
to achieve this.
Each of the Serv ice Lines and Functions is also controlled through its own serv ice descriptions,
organisational controls, v ision, mission and value statem ents, gov ernance and control frameworks,
monitoring and review controls and performance measures.
4.4 Control Activities
4.4.1 Governance and Over sight of Control Activities
Fujitsu’s has established the Corporate Governance Committee (CGC) and Audit Committee responsible
to the Fujitsu UK and Ireland Board to oversee the companies’ approach to governance and control.
The directors are committed to maintaining a strong control environment throughout the organisation and
recognise that the control environment provides the foundation for all other components of internal control
providing discipline and structure.
The Board of Directors (The Board) is responsible for monitoring performance of the Company on behalf
of its shareholders and ensuring that Fujitsu satisfies all regulatory and statutory requirem ents related to
its operations.
Description of Fujitsu's System 14
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Authority for all action and ex penditure within Fujitsu Serv ice flows from the Board and the Board has
established that the necessary control sy stems are in place to ensure that business is undertaken in a
responsible manner. Fujitsu's policies, operations and strategy are controlled by the Board.
The Board meets as required and its two key sub-committees the CGC and the Audit Committee m eet
quarterly.
In addition Fujitsu has a system atic approach to policy and process with a set of Master Policies
approved by the CGC and sub-policies and processes determined by the relev _ant regional f unctions
underneath. The framework, known as the Business Managerrent System (BMS) is managed by Fujitsu's
Business A ssurance team s and com prises of asetof mandatory Master Policies and Business
Processes. The key Master Policies cover Ethics, Security, Human Resources, Corporate Responsibility,
Finance, Legal, Serv ice Deliv ery, Quality, Project Managem ent, Risk Managem ent and Busines s
Continuity under each of which is a set of specific business processes owned by Senior Managenent.
Within POA each Serv ice Line and Function follows the BMS. W_ here ex ceptions to the BMS are
necessary, local standards, procedures and work instructions are docum ented with a ‘Let’f rom the
Corporate Process Owner where the Corporate Process Owner authorises that local departure f rom the
BMS.
4.4.2 Human Resources
4.4.2.1 Policies and Practices
Human resource policies and practices relate to hiring, orienting, training, ev aluating, counselling,
promoting and com pensating per sonnel. The com petence and integrity of Fujitsu's personnel are
essential elements of its control environment.
4.4.2.2 Performance Management
Performance Managem ent is a process f or managing and im proving perf ormance of team s and
individuals through proactive management of objectives / deliverables which are clearly linked to the Mid
Term Plan. It includes the identification of development needs and ongoing ev aluation of achievement
and capability by the reviewer and the individual involved. Fujitsu UK & Ireland is committed to providing
the organisation and ourem __ ployees with acomm__ on perf ormance m anagement process that is
consistently applied across the organisation and is aligned with organisational goals.
This process also defines how individual employees express their short and long term desires for career
development. The process inv olves the indiv idual in planning career goals by identif ying the specific
steps to develop skills to fulfil and manage career transitions.
The Fujitsu UK & Ireland's Performance process applies to all employees within Fujitsu UK & Ireland and
embodies the principle that strong business perf ormance is m ost likely when em ployees feel they are
operating at the peak of their potential in roles that match the company’s objectives.
Fujitsu’s Human Resource policies are held and m aintained on its CafeVik web portal and m anaged by
Fujitsu’s HR team s. These policies operate em ployment policies to prov ide af ramework f or the
employment of people and provide employees with a clear and concise set of rules in which to operate.
Its policies apply to Fujitsu UK & Ireland. This means all Employees, Contractors and businesses carried
on by Fujitsu Serv ices Limited and its subsidiaries and any other com _ pany or organisation that is
managed by the Chief Executive Officer, Fujitsu United Kingdom and Ireland.
Description of Fujitsu's System 15
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.5 Information and Communication
Fujitsu UK and Ireland Serv ice Lines and Functions as have Caf éVik portals to enable sharing of
knowledge across the company, and throughout their own business areas.
These portals provide information about each of the Service Lines and Functions and what products and
services they offer to the company.
Fujitsu has a robust and reliable comm ___unication fram ework that utilises push and pull strategies to
ensure that all employees have the information they need to perform their roles effectively, efficiently and
ethically. Some of the mechanisms used to communicate directly with Fujitsu employees include:
« Road Shows.
Staff Briefings.
«Team Meetings.
«Leader ship and Management Cascades.
In April 2011 invitations were sent to all employees in the Group to participate in a Global wide employee
engagement survey.
Fujitsu also seeks the v iews of employees via representative groups in diff erent parts of the Company.
During this year (2012) in the UK it has set up Fujitsu Voice with ov er 60% of employees voting in an
election for its 23 members. Fujitsu management consults regularly with these bodies, providing updates
and seeking v iews on im portant issues. In addition Fujitsu has agreements with Trade Unions that
include regular meetings with local and senior management to discuss issues affecting employees in the
unions’ area of interest.
4.6 Monitoring
Fujitsu utilises a \ariety of systems, processes and tools to help ensure that operations are efficient, effeetiv
and ethical, including:
Performance Dashboards.
« Standard Reporting Packs.
« Audits and Health Checks.
« Reviews and Lessons Learned.
« Customer Satisfaction Scores.
Audits by Fujitsu Business Assurance Teams, Fujitsu Ex ternal ISO Accreditors (the account is itself
accredited to ISO 27001) and POL or its agents (including PCI DSS and Link Auditors) are used to
support the design, im plementation and post im plementation review of the controls in place and to help
ensure that the relevant governance, strategy and needs and requirements of both POL and Fujitsu are
met.
Data and information from these sources are used to identify weaknesses, inefficiencies or potential
performance issues. Performance issues are remediated and opportunities for improgment are identified,
evaluated, prioritised and managed through to appropriate implementation.
The BMS Team interacts periodically with both the internal and external auditors.
Description of Fujitsu's System 16
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.7 Risk Assessment
4.7.1 Risk Policy and Implementation
All operating com panies within Fujitsu’s Global Business Group (GBG) are required tohav _—e a Risk
Management Framework. Each group is also required to hav e a designated Chief Risk Managem ent
Officer (CRMO) whose responsibilities include bi-annual risk reporting and prom pt escalation of
significant risks to GBG in addition to m anaging the risk process f or the Board. Fujitsu's Risk
Management Framework centres on the Risk Managem ent Policy which is a key m anagement policy
overseen by the Corporate Governance Committee (CGC) of the Board chaired by the Ex ecutive
Chairman. Responsibility for implementation of the Risk Management Policy is delegated throughout the
business cycle. Fujitsu prov ides support and guidance toem_ployees through the Custom er Solution
Lifecycle, a repository of best practice and training. Managem __ ent oversight at critical points in the
business cycle is prov ided through the Rev iew Framework, a structured set of formal management
reviews. Fujitsu’s m anagement of risk is ex hibited throughout these structures such that potential
problems can be planned for and managed appropriately.
4.7.2 Fujitsu’s Risk Process
The Fujitsu Risk Process is used to support the ev aluation reporting and management of risks within the
business and is consistent with recognised Risk Managerent standards.
Fujitsu’s Enterprise Risk Management System (ERM) provides clear and effective monthly risk reporting
to the regional leadership teams and forms the basis of the GBG. This helps to ensure a high level of risk
management is maintained throughout the organisation.
4.8 Services provided
4.8.1 Physical and Environmental Controls
1. Control Objective 1: Controls provide reasonable assurance that access to data centres and
facilities with computer equipment, storage media and program documentation is restricted to
properly authorised individuals.
# Control
11 Data centre access: Data centre specific physical access security policies and procedures to
control access to the data centre and other sensitiv e areas, including computer equipment and
storage media, are implemented. These are made available to Fujitsu staff via the intranet.
1.2 Access within the data centre: Access beyond the security desk is protected by a key-card
system that restricts individual access to specific data processing areas. Security management
has determined appropriate levels of physical access to the data centre, which is based on the
roles and responsibilities of staff. Staff requiring access to the data centre m ust complete an
access form, which must be signed as approved by the line manager responsible for the zones
requested.
1.3 CCTV: The data centre(s) is controlled and monitored through the use of CCTV video cameras.
Video cameras are placed at strategic locations around the perim eter of the building to help
ensure that coverage of the data centre is obtained.
14 Security guards: Security guards are present at the data centres 24 hours per day, seven days
per week. The data centre can only be accessed through a central area.
1.5 Data centre visitors: Visitors are required to sign in at the reception areas and tem porary
badges are issued. Visitors m ust have been pre notified to data centre security by a Fujitsu
employee.
Description of Fujitsu's System 17
FUJ00237007
FUJ00237007
FUJITSU
# Control
1.6 Failed access monitoring: Attempts to enter restricted areas without using authentication
devices are denied and a security alert is triggered and logged. Data centre managem ent
proactively follows up on security alerts that are triggered.
17 Review of user access within the data centre: Periodic reviews are performed of users who
have access to the data centre to help ensure that their access rights are appropriate.
18 Deletion of user access: The m anagers of the v arious delivery teams are responsible f or
notifying the local site facilities team of terminations or transf ers of their direct reports. Upon
notification of em ployment changes, access through the security access control system is
revoked.
2. Control Objective 2: Controls provide reasonable assurance that computer equipment and
facilities are protected from damage by fire, flood and other environmental hazards and
maintenance agreements are in place.
# Control
2.1 Fire Suppression: Fire detection and suppression dev ices, such as hand-held fire
extinguishers, are strategically placed throughout the entire data centre.
2.2 Maintenance Schedule: Periodic inspection and maintenance is performed on protection
devices, sensors and alarm systems.
2.3 Environmental monitoring: Smoke detectors and water, humidity and temperature monitoring
devices are installed to detect abnormal environmental conditions.
24 UPS Supply: A UPS system is installed to protect the f acilities and com puter equipment from
electrical power fluctuations and outages.
The Trident House campus comprises of a two storey office block (Phase 1!) with an adjoining com puter
room and data / output handling area. There is also a separate single storey building (Phase II)
containing offices and another computer room. There is one main entrance to the Trident House Phase I
building and a loading bay and one main entrance to the Trident House Phase II building
The IRE11 data centre com ponent of the Trident House cam pus is com posed of raised floor com puter
rooms, office space and f acility support (Un-interruptible Power Supply [UPS], backup generators and
power distribution equipment). The IRE11 data centre is staffed with its own security guards, who are on
duty 24 hours a day, seven days a week (1.4). Physical access to the data centre can only be obtained
through the security officer's desk at the m ain entrance to the cam pus. The Trident House cam pus is
also equipped with Closed Circuit Television (CCTV) cameras, monitored by the campus security guards
(for all areas) and the Data Centre Operations team for all secure Data Centre com puter rooms. These
cameras are located along the IRE11 cam__ pus perimeter, entry / exit locations, m ain entrances and
numerous additional strategic locations within the secure com _ puter rooms to help ensure com plete
coverage of the data centre (1.3).
The IRE11 data centre has dev eloped and im plemented data centre specif ic physical access security
policies and procedures to control access to the data centre and other sensitiv e areas, including
computer equipment and storage media (1.1).
The POL computing hardware and storage media are located in secure areas of the data centre facility
with access restricted to appropriate personnel through the use of _ an electronic cards access sy stem
(SAFE), the com puter room employs keypad / PIN code technology as an additional level of access
control (1.2). Personnel are required to individually swipe in and where applicable, swipe out of an area.
“Piggy backing” off someone else swiping in is prohibited. Attem pts to enter restricted areas without
using authentication dev ices are denied and asec __urity alert is triggered and logged. Data centre
management proactively follows up on security alerts that are triggered(1.6 and 1.7).
Description of Fujitsu's System 18
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Access to the data centres is secured based on electronic card access systens (1.2).
This system controls entry to personnel who need it, while maintaining the security of the building.
When an employee leaves the company, the card is rem oved from the system database and would no
longer provide access to the cardholder. Therefore if cards are not retrieved, the security of a facility can
be maintained. Unique cards are issued f or each em ployee, for individual control, accountability and
tracking of activity. Flexible control is accom plished by allowing each person access to diff erent areas
and only at certain times.
An audit trail is provided for management tracking and reporting of who entered and / or left a particular
area at a particular time. Tracking of all access attempts is provided to allow management to determine if
employees are attem pting to enter areas they are not permitted into, or whether em ployees are
attempting to get into areas at the times when they are not allowed access to those areas (1.6).
4.8.1.1 Visitor Access
Visitors (and initially new joiners who have not yet been issued their photo access card) are issued with a
visitor's access card (1.5). Visits to the IRE11 cam pus, and the issue of visitor access cards, must be
recorded in the local site visitors’ log. The details must include: Date and time of entry, Name, Company
(where applicable), Person visiting, Unique number of the visitor access card and Time of exit.
Visitors should norm ally be escorted around Fujitsu sites, but they can be issued with either an
‘unescorted’ access card, depending on the provisions in the Local Site Building Security Procedures.
The ‘escorted’ and ‘unescorted’ badges (and lanyards) clearly distinguish Wsually which is which.
All access to the computer rooms is strictly controlled. To access the computer rooms an individual must
first complete a request in the data centre on-line access request sy stem to obtain approv al; if a valid
reason has not been prov ided for multiple accesses, the access will only allow the indiv idual to access
the data centre once. No access is granted unless a valid reason has been prov ided and the on-line
access ticket has been authorized (1.5).
All visitor access cards (common areas) are handed into the issuer (normally reception or site security) at
the end of each day. All visitor access cards (computer rooms) must be handed into the issuer (IRE11
Operations team) at the end of each day.
Persons issuing visitor access cards (reception / site security / DC Operations team _) must check the
records to help ensure that all v isitor access cards are recov ered at the end of each day. If cards are
outstanding at the end of the day they must be electronically disabled and enquiries made to the person
issued with the access card, or the person they were \siting, as to the return of the access card.
4.8.1.2 Monitoring of Individuals with Access to the Data Centre
Listings are m aintained showing indiv iduals with IRE11 data centre access. The IRE11 Data Centre
management and Fujitsu Group Security personnel periodically review reports that list user access levels
to restricted areas of the data centre to determine whether user access rights are appropriate (1.7). The
managers of the v arious delivery teams are responsible f or notifying the local site f acilities team of
terminations or transfers of their direct reports. Upon notification of employment changes, access through
the security access control system is rev oked and the card key and other physical access dev ices are
collected (1.8).
4.8.1.3 Environmental systems
The IRE11 data centre is equipped with env _ironmental systems to saf eguard POL’s hardware and
information assets located within the facilities. The com puter room is equipped with leak detection
systems, sm oke detectors, fire suppression sy stems, hand held fire extinguishers and tem perature
Description of Fujitsu's System 19
FUJ00237007
FUJ00237007
Fe)
FUJITSU
monitoring systems (2.1, 2.3). Condensing units, pumps, and chillers provide cooling for the data centre.
This equipment supports multiple computer room air conditioning units distributed throughout the raised
floors. The POL client's serv ers and hardware equipment are m ounted in locked racks or f ree standing
cabinets on the raised floors.
Each com puter room is supplied by separate comm __ercial power f eeds, each from a single power
generation substation. Separate diesel generators support each com _ puter room and prov ide backup
power in the event that commercial power is temporarily unavailable. These generators are supplied by
additional fuel tanks that prov ide an operating window at f ull load. The power distribution equipm ent
consists of two uninterruptible power supply (UPS) systems providing conditioned power to a UPS Static
Switch. The UPS Static Switch prov ides power as the prim ary and alternate source of power to the
associated Static Switch Power Distribution Unit (PDU). The PDUs have dual feeds designed to provide a
seamless transfer in the event of a power loss (2.4).
The IRE11 data centre ism _ onitored by a Building Managem _ ent System (BMS) located in the Site
facilities office (monitored by 3 party GS Hall engineers) in the Phase I buildings within the data centre
location, with repeater heads located in the Security office and the data centre Operations Bridge. The
BMS automatically alerts all three stations if abnormal environmental conditions occur.
The GS Hall engineers, Security and Operations teams monitor the system 24 hours a day, seven days a
week to prov ide rapid ev aluation and response to facility problem s (2.3). Scheduled inspection and
maintenance are perf ormed on env ironmental protection dev ices, sensors, and alarm systems (2.2).
Checks are performed at varying intervals dependent on the devices being maintained; however, devices
are checked at least annually.
4.9 IT Operations
4.9.1 Backup
3. Control Objective 3: Controls provide reasonable assurance that programs, files and dataset s
that have been identified as requiring periodic backup are backed up and retained.
# Control
3.1 Backup Definition: The Backup High Lev el Design docum ents define Backup and recov ery
requirements and policy for the platform.
3.2 Backup Toolset: Backups are performed using Netbackup or RMAN (autorsted tools).
3.3 Backups are written to a secondary location: Backups performed are written to a separate
disk array and are simultaneously written to a disk array at the disaster recovery site.
3.4 Failed backups are tracked and monitored: Failed backups are signalled to the Master Batch
Scheduling system which raises events in a generic manner to the SMC.
The Solution Owner is responsible f or ensuring that in the ev ent of accidental deletion or corruption of
data that the data can be recov ered. The Platf orm Physical Design docum ent will def ine whether a
NetBackup client is required and the Application High Lev el Design will define the backup and recovery
policy and m ethod (3.1). The Solution Owner is also responsible f or defining the archiv e and deletion
policy and data that needs to be retained for audit purposes.
At the discretion of the Solution Owner, backups m ay be perf ormed using Oracle RMAN or the
NetBackup based Backup Sy stem according to patterns defined in the Backup & Recov ery High Level
Design (3.2).
In the case of Oracle RMAN backups the backup data is written to disk in a separate disk array.
Simultaneously it is also written to a disk array at the disaster recov ery site (3.3). Those systems which
Description of Fujitsu's System 20
FUJ00237007
FUJ00237007
Fe)
FUJITSU
have been identified as requiring backups via the NetBackup solution will have their backups scheduled
via the TW S scheduler, this prov ides automatic monitoring of the status of the backups, and will hav e
backups written to each data centre to prov _ ide resilience in the ev ent of a requirem ent to perf orm
Disaster recovery.
Depending on the size of the dataset to be backed up either a direct client backup v_ia the network may
be performed or a split mirror backup using standard features (clones and snapshots) of the storage
arrays which are presented to the backup media server. Data is written to a virtual tape library at both the
primary and the disaster recov ery sites. No tapes are ex ported from the system unless specif ically
requested and authorised.
Note that in some circumstances, the recovery may by design be affected by replaying the data from an
upstream system rather than by perf orming a traditional "backup recov ery" as m any systems need to
keep a consistent view of each other and going backwards in time is not always appropriate.
The Backup Development team deliv ers appropriate NetBackup policies according to these definitions.
The Live System Test team rev iews the delivered policies against the design requirem ent. If an RMAN
backup has been specified, the Liv e System Test application instance will perf orm those same RMAN
backups or, in the case of aPOLSAP or POLMI (MIf or POL) application serv ice, the Operational
Acceptance Test OAT system will be used to confirm the operation of the RMAN backup bef ore
deploying to Production.
The backup jobs are autom ated as defined by the Solution Owner in the Batch Scheduling High Lev el
Design and implemented by the Schedule Development team. If a backup does not complete or does not
backup all files it will exit with af ailure status. Detection of failed backups is through job f ailure being
signalled to the Master Batch Scheduling system which raises events in a generic manner to the System
Management Centre (SMC). SMC uses the Known E rror Log (KEL) sy stem to identify the appropriate
team to respond to the backup f ailure and pass a Triole f or Service (TFS) call to their call stack with a
voice prompt. Corrective action that is required beyond a simple rerun via the batch scheduler is planned
and a Managed Serv ice Change (MSC) ticket is raised f or approval. A m echanism exists to prov ide
emergency approval by escalating to the Duty Service Manager out of hours (3.4).
The backup and recovery methods are based on well known industry standard solutions, and the general
operation was extensively tested during non-functional testing prior to HNG-X go-live. The responsibility
of the operational team s only ex tends to recov ering data f rom tape or clone im ages and perf orming
database recovery, such as archiv elog replay. There m ay subsequently be application support activ ity
required to return the service to an operational state. Recovery is tracked through the incident number of
the call raised f or the original f ault report, and is only perf ormed when a MSC has been approv ed by
Service Management. This same process is followed for all systems that may perform backup recoveries.
Recoveries for RMAN backups are performed by the DBA team that supports those databases.
Recoveries for NetBackup backups are performed by the Unix team.
Recoveries from clones are performed by the Unix or NT team depending upon the OS type of the target
system.
There is no f ormal periodic testing of backup recovery as the account has not prov ided any servers or
disk space to perform such recoveries and recovery to the live server is not permissible unless a failure
has occurred. There have in the past been operational recoveries of each type.
Audit retrievals are happening on a f airly constant basis driven by formal customer requests from POL.
Audit retrieval is tested as part of an upgrade or change to the audit infrastructure such as firm ware
upgrades of the EMC Centera.
Description of Fujitsu's System 21
FUJ00237007
FUJ00237007
Fe)
FUJITSU
POLSAP retrievals also happen on a fairly constant basis as generating a report in SAP that spans a tine
period which is in the archiv e causes an automatic retrieval which is seamless to the user. There i s no
change control process, retriev als are autom atic as part of the norm al user reporting process. Report
retrieval is tested as part of an upgrade or change to the audit inf rastructure such as firmware upgrades
of the EMC Centera.
4.9.2 Job Scheduling
4. Control Objective 4: Controls provide reasonable assurance that processing is appropriately
authorised and scheduled and that deviations from scheduled processing are identified and
resolved.
Control
41 Maintenance of Job Schedules: Access to am end job schedules is restricted to appropriate
Fujitsu personnel required to have this level of access by their role.
4.2 SAP Schedules are continuously monitored : The SAP Basis Team uses the SAP GUI and
SAP transaction code SM37 to monitor the success / failure of SAP batch jobs. The SAP Basis
team will also check and monitor the batch job start and end times and send the daily monitoring
statistics to agreed parties.
43 Failed job schedules are monitored and alerted: Automated alerts are configured and sent to
relevant parties upon the occurrence of a batch job failure. These are investigated in line with
the incident management process.
4.9.2.1 HNG-X Job Scheduling
Scheduling of jobs within the HNG-X Data Centre environment is an automated process using Tivoli. The
Tivoli Workflow Scheduler (TWS) is used to orchestrate the ex ecution of jobs within the Horizon Online
(HNG-X) data centre. Each v ertical application has its own set of tasks which are defined and TW S is
used to schedule those and maintain the dependencies within that application.
The Managed System Support (MSS) team is responsible for the initial im plementation of the schedule
(4.1). The platf orm architect will outline the required jobs needed f or that platform as part of the High
Level Design (HLD) docum ent. It is then the responsibility of MSS to help ensure that these jobs are
appropriately configured within TWS. MSS also performs day to day monitoring and management of the
Tivoli toolsets with more advanced support when required from the Systems Management Group.
If there are f ailures in the daily processing, alerts are raised to the Tiv oli Business Serv ice Manager
TBSM module and TWS co-ordinates the reporting of the abnorm al end of those jobs that are in error.
These alerts are then identif ied as part of the SMC proactiv e monitoring of the TBSM m odule, further
detailed in Control Objective 6. They will then raise a TFS ticket to the Unix Team based in IRE11 and
ask them to investigate the failed schedule (4.3).
Access to maintain and amend schedules is restricted to the Unix Team based in IRE11. If changes are
required to the initial schedule that has been im plemented, this will f ollow the standard MSC process.
Please refer to Control 8 for further details of this process.
4.9.2.2 SAP Job Scheduling
The POLSAP Basis team manages and maintains the batch scheduling (4.1). The details of the POLSAP.
batch is held in Dim ensions, documented in POLSAP/DES/APP/SCH/TBC. Dim ensions has sev eral
roles in supporting services to POL including:
* Acting as adocum ent management system.
* Acting as a software configuration repository.
Description of Fujitsu's System 22
FUJ00237007
FUJ00237007
Fe)
FUJITSU
The SAP Basis team performs the daily proactiv e monitoring of POLSAP-PLP system (4.2) which
includes:
« General healthcheck of all system s.
« The SAP Basis team will m aintain the Batch Jobs scheduling docum ent “POLSAP BATCH
CATALOG’ so if there are changes to the batch jobs then the document will be updated. This
document is available on the project repository on the intranet.
« SAP batch jobs are maintained in the POLSAP R3 system.
« SAP batch jobs are m_onitored from SAP GUI through SAP transaction code SM37. This screen
is monitored on a daily basis by the SAP Basis team
« The SAP Basis team _ will also check and monitor all the batch job start and end tim es and send
the daily monitoring statistics to agreed parties.
* The SAP Basis team __ will check and send the transaction response time to the agreed parties.
« The SAP Basis Team _ is responsible for the investigation and resolution of issues found with the
batch jobs.
If the monitoring identifies an issue with a critical job (a critical job being def ined as a job is part of the
team's daily monitoring list) the team will ask the SMC team to raise an incident on the Post Office-owned
and managed Triole incident logging tool. The SMC team will then assign this incident to the appropriate
resolving team. These tickets would then be m —_anaged through the standard incident m anagement
procedure that is described in Control Objective 6 (4.3).
If there is a batch job failure in POLSAP, the Solution Manager system __ is configured to trigger an
automated alert to SMC team. Based on that alert the SMC team will raise an incident in the Triole tool.
If a change in the Schedule of the Batch jobs is required or a new Batch Job is required, an MSCi ss
raised and once the MSC is approved the change implemented in the system by the Basis Team.
4.9.3 Availability and Capacity Management
5. Control Objective 5: Controls provide reasonable assurance that system availability,
performance and capacity are routinely monitored to help ensure that potential issues are
captured and investigated.
Control
51 SAP Performance Monitoring : The SAP Basis team regularly m onitors table space and
databases to help ensure there is suff icient system availability and capacity and that potential
issues are captured and investigated.
5.2 SAP Capacity Alerting: An automated alert will be generated in the Solution Manager System
(PLM) if the table space is more than 95% filled and the SAP Basis team will monitor and review
these alerts.
5.3 SAP Availability Alerting: Automated alerts are configured in Solution Manager to adv ise if a
part of the system is shutdown / not available for users. These alerts go to SMC team and they
will create an incident.
5.4 HNG-X Performance Monitoring : The Tiv oli ITM proactiv ely monitors CPU, Mem ory, Disk
utilisation and capacity of internal services on these platforms, raising alerts for investigation by
the SMC as appropriate.
Description of Fujitsu's System 23
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Control
5.5 HNG-X Capacity and Availability Monitoring: The Tiv oli ITM tool proactiv ely monitors the
availability of W intel and Unix platf orms, feeding platform availability data to Tiv oli Business
Service Manager (v ia Netcool Omnibus) about the av _ailability of platforms. Tiv oli Business
Service Manager present s this data in a business context to the SMC, highlighting serv ice
affecting issues.
5.6 Monitoring of Service Delivery: A monthly Service Review Book is provided to POL to review
its agreed Serv ice Levels. Within this book are det ails of capacity, av ailability and incident
management performance.
4.9.3.1 SAP Availability and Capacity Management
Details of the system availability and agreed SLAs are detailed in the OLA document held on Dimensions.
database. The document reference is POLSAP/SVIM/SDM/OLA/874.
The SAP Basis team regularly m onitors the Table space and database; an autom ated alert will be
generated in the Solution Manager System (PLM) if the table space is more than 95% filled (5.1 and 5.2).
The SAP Basis Team also monitor the weekly and monthly database growth for the POLSAP system and
based on that can plan the future growth ofthe database.
Automated alerts are configured in Solution Manager to adv ise if a part of the system is shutdown / not
available for users (5.3). These alerts go to SMC team and it will create an incident and assign to the
appropriate team (which again will be handled as per Incident Management process described in Control
Objective 6.
The Athene product is used to manage the Component capacity of UNIX and Wintel Hardware on POA.
This tool is located within the IRE11 data centre and its results are managed by the Capacity Manager in
the SSC. The tool looks at the CPU, Mem ory, Disk utilisation and capacity of internal serv ices on these
platforms.
4.9.3.2 HNG-X Capacity and Availability Management
SYSMAN3 is a generic nam e for the set of Platforms and sof tware that prov ides System and Estate
Management support to all HNG-X Platforms. This m anagement includes the capture of availability
information for the platforms via the IBM Tivoli Monitoring system and SYSMANS (5.3).
SYSMAN3 comprises the following applications:
Application Scope
IBM Tivoli Monitoring (ITM) Proactive Monitoring of Data centre Platforms.
Netcool Omnibus Event collection from:
Data Centre
« Branch Estate
« Network s ( NNM)
« EMC Storage
¢ Applications
Tivoli Business Service Manager (TBSM) Presentation of Alerts and events in a business context.
Netcool Reporter Reporting Product for SYSMAN reports.
Oracle Enterprise Manager (Oracle Grid) Monitoring of Oracle Databases.
(OEM)
Description of Fujitsu's System 24
FUJ00237007
FUJ00237007
Fe)
FUJITSU
SYSMANS collects Events using Tivoli Omnibus Technology and presents this to the SMC using Tiv oli
Business Service Views (TBSM) views and alerts in a business’ context, correlated to the application or
system that is impacted.
WebTop an Omnibus Graphical User Interface (GUI) is used to provide a filtered view of events that are
not consumed within TBSM particularly Counter and Security Alerts.
One month’s historical reporting from both TBSM and WebTop is available from Tivoli Reporter.
Events collected by a SYSMAN version are sent to the Audit Server.
The SYSMAN system, an earlier version of SYSMAN3, collects events from the counter estate including:
¢ Quality of Service.
* Operating System
« Application and Branch Router.
Systems within the Data Centre are proactiv ely monitored through the use of ITM the Tiv oli Monitoring
tool. ITM agents gather the event data at regular intervals and measure the data against thresholds and
alerts are raised if the thresholds are breached (5.4). ITM includes operating system agents that alert on
CPU and Disk space ev ents. Databases are also m onitored using the ITM database agent. Custom
Agents are used within HNG-X to capture:
« Radius Authentication Ev ents.
* Netcool Ev ent Statistics.
« BNS Statistics.
« HNG-X Application Statistics.
SYSMAN gathers alerts into Tivoli Omnibus using Omnibus event probes. Probes used within the HNG-X
solution include:
« SNMP Traps.
« Unix (Solaris and Redhat) Syslog probes.
«Unix SyslogNG (Syslog Server).
« Windows Event logs.
«Tex t file (Application logs).
EIF Probe (Integration to Tiv oli Monitoring ITM).
The SMC m onitors the output from the Tiv oli systems and raises appropriate alerts v ia the Triole for
Service toolset and where appropriate Known Error log fies, incidents or major incidents are applied.
The Athene product is used to manage the Component capacity of UNIX and Wintel Hardware on POA.
This tool is located within the IRE11 data centre and its results are managed by the Capacity Manager in
the SSC. The tool looks at the CPU, Mem ory, Disk utilisation and capacity of internal serv ices on these
platforms.
The SSC receives reports from Athene detailing capacity on a regular basis.
Applications report their availability and capacity issues to the Business System s Database and reports
are reviewed from this on a monthly basis by the SSC 6.5).
Description of Fujitsu's System 25
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.9.4 Incident Management
6. Control Objective 6: Controls provide reasonable assurance that significant operations
incidents are adequately reported, tracked, monitored through resolution and resolved timely.
Control
6.1 Incident policies and procedures are in place: Fujitsu has documented policies and
procedures for managing incidents impacting the in sc ope applications which are av ailable via
CafeVik to Fujitsu teams.
6.2 Incident prioritisation: Incidents are assigned a priority in accordance with the sev erity levels
agreed with POL.
6.3 Incident resolution: Incidents are handled in a timely manner, as per priority.
64 Major & Security Incident review: Once a Major or Security Incident is resolv ed there is a
formal closure of the incident and a review including, if applicable a Root Cause Analysis.
6.5 Incident reporting: On a daily basis, the Fujitsu HSD / IMT reviews the number and severity of
outstanding incidents in TFS.
66 Alert handling: The Tiv oli ITM and Netcool Om nibus automate the collection of events and
using Tivoli Business Service Manager highlight areas of concern to the SMC.
4.9.4.1 Incident Management Process
Fujitsu Post Office Account (POA) f — ollows its own im plementation of Fujitsu’s Corporate Incident
management process (6.1).
The process applies to all Incidents raised by Fujitsu’s Help Serv ice Desk (POA HSD) or by the System
Management Centre (SMC) (out of hours or from systems monitoring tools), where they are related to the
Fujitsu outsourcing contract. POL staff raise calls at POL’s Net work Business Support Centre (NBSC)
and, where relevant, they are passed to the POA HSD or SMC. Calls presented to POA HSD / SMC that
should be placed with Post Office Ltd’s Net I work Business Support Centre (NBSC) are transf _erred/
referred from POA HSD / SMC to NBSC. Incidents are logged and managed using the Triole for Service
Call Management system (TFS) which also produces status reporting on incidents. On a daily basis, the
Fujitsu HSD / IMT reviews the number and severity of outstanding incidents in TFS 6.5).
The scope of the process is from the receipt of an incident by the HSD / SMC, through to the successf ul
workaround or resolution of the incident.
The key objectives of the process are:
Log, track and close all types of incident requests.
« Respond to all types of incident requests.
« Restore agreed serv _ice to the business as soon as possible.
« Resolve incidents within the target tim escales set for each priority level within the Service Level
Agreement(s).
« Resolv ea high number of requests at first contact.
« Ensuring incident priorities are linked to business priorities.
« Keeping the user informed of progress.
« Reduced unplanned downtime.
elm _ proved Customer satisfaction.
Description of Fujitsu's System 26
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Fujitsu has defined an incident as “Any event which is not part of the standard operation of a service and
which causes an interruption to, or a reduction in, the quality of that service”.
Incidents are triggered by the following methods:
* All Incidents reported by Contact with the HSD / SMC. Contact is defined asv _oice or a Tivoli Alert
generated by the Tivoli Event Monitoring tool as the methods of communication with the HSD / SMC
and fall into the following categories:
o Business process error
o Hardware or software error
o Request f or information e.g., progress of a previously reported Incident
o User com plaint
o Network Error
o Logging v_ia HNG-X web interface
« Severity and Service Level Target (SLT) information.
« Ev idence of an Error.
« System Alerts received automatically from transaction monitoring tools (6.6). Due to the urgent
nature of some of these alerts, they m ay be dealt with directly by the Fujitsu Software Support
Centre (SSC), with an update of workaround or resolution supplied to HSD / SMC.
The initial detection stage is the responsibility of the HSD and SMC who receive calls from Users:
e Fujitsu Service Lines or Functions.
e¢ POAIT Serv ice Management.
Third Parties.
e Fujitsu Serv ice Delivery Management.
* Post Office Ltd, including Post Office Information Security.
These calls are recorded in TFS and are classified in one of the following ways:
« Adv ise and Guidance.
© Out of Scope.
© Quality Issue.
¢ Incident.
The first three abov e are ref erred back to Post Office NBSC and the last follows Fujitsu's incident
management steps.
Once the details of the incident are recorded in TFS the HSD / SMC team assigns a severity level to the
call (6.2). If the call is classed as a Security Incident or Major Incident it f ollows a different route detailed
below. Call Priority for Hardware and Network calls is assigned in accordance with the Priority m atrix as
detailed in the agreed contractual Engineering Service Description.
The table overleaf does not indicate resolution times as Fujitsu is required to work to POL Service Level
Agreements and availability targets and not incident resolution times (6.3). Major Incidents are therefore
resolved in as short a time as possible dependent on the nature of the incident. The high priority placed
on a Major Incident by Fujitsu’s POA m anagement team helps to ensure that the full resources required
to resolve it are forthcoming.
Description of Fujitsu's System 27
Fe)
FUJITSU
FUJ00237007
FUJ00237007
Severity I Importance I Definition
A Critical « BUSINESS STOPPED, a Post Office unable to trade (where
engineering cov er av ailable), unable to process any business, or
central system f ailure which will result ina num _ ber of Post Offices
being unable to process work.
* Causes significant financial loss (as agreed between POL and POA
Operations).
Results in data corruption or unrecov erable data loss.
B Major « BUSINESS RESTRICTED, a Post Office restricted in its ability to
transact business e.g., 50% of counters unable to trade or trading with
restricted business capability.
e Has an adv erse impact on the deliv ery of service to a num ber of end
users.
e Causes af inancial loss that impacts POL and / or POA reputation (as
agreed between POL and POA Custorrer Services).
elf a PCI Major Incident process is invoked.
Cc Medium e NON-CRITICAL, a Post Office working norm ally but with a known
disability, e.g., an interim solution (workaround) has been provided.
e If aPCI Minor Incident process is invoked.
«Has am_ inor adverse impact upon the deliv ery of service to a sm all
number of end users.
D Low © Non-urgent.
¢ Insignificant and usually cosm_ etic error, either a triv ial documentation
error or spelling error on the system.
The Incident Managem ent process contains 5 stages as detailed in the diagram below and ownership
passes between the various service lines and towers delivering the service.
Description of Fujitsu's System
28
FUJ00237007
FUJ00237007
Fe)
FUJITSU
1.
> Incident Detecting, recording and initial
5 classification
=
6
D
&
=
S
€
E)
2
2 ve
= — > Assign priority and initial support ‘¢
5
5)
2
&
c
2
G
g =
3 3. zs
= E Investigate and diagnose 8 5
@
2 25
3
o =o
£ x ge
3 20
g<—_, + I p> 22
2 Resolution and recovery Ro
= a
S &
€
a
S
2
o
S
2
° 5.
Incident closure
If an incident is not a Security Incident or Major Incident then a check is m ade against the SSC Known
Error Log KEL to establish whether the problem has been seen before and if there are known actions that
need to taken. If the KEL has information about the problem then the resolution or work around is applied
and details are linked to the Master Incident / error log for this known problem.
If it is a new issue the TFS call is passed to first line support who will attem pt to resolve the incident with
the help of Product Support Engineers (PSE). If the call is resolved this is agreed with the Incident owner
and the TFS call record is closed.
If the incident is not resolved, the TFS call is passed to the appropriate Service Delivery Unit (SDU) using
the HSD / SMC Support Matrix and the Incident Managem ent Team (IMT) are apprised of the position.
For Hardware calls, the caller is given an indication of engineer arrival time, based on the Service Level
Agreement (SLA) associated with the priority of the call.
If the incident is a known current issue then the caller is advised of the status of the problem and the TFS
Master call updated with this occurrence and the SDU(s) m_ anaging the call's resolution are adv ised of
another occurrence of the issue and the IMT are apprised of _ the position. The SDU inv estigates and
diagnoses the Incident, based on the inf ormation in TFS, together with new inf ormation. The SDU also
coordinates where sub-contract third parties are involved.
Description of Fujitsu's System 29
FUJ00237007
FUJ00237007
Fe)
FUJITSU
If the Incident has no associated KEL or itis com _ plex and inv olves multiple SDUs, or if it has been
unresolved for an extended period, the IMT will alert the POA Serv ice Delivery Manager (SDM) to the
existence of a pattern likely to produce a Problem.
The SDU will produce a workaround or resolution f or the problem. The SDU then either applies the
workaround or resolution or passes it to the HSD / SMC to implement. The Master Incident Record is the
first call for an issue in TFS and is used as a tracking call br a major incident.
Where this Incident has a num ber of Calls referenced to it, or where there is a probability that proactive
action is required to prev ent further occurrences of this Incident the IMT will alert the POA SDM to the
existence of a pattern likely to produce a Problem.
The Incident is then passed to the HSD / SMC to manage and if the call is resolved this is agreed with the
Incident owner and the TFS call record is closed.
Throughout the Incident, the HSD / SMC retains ownership for monitoring and keeping the call raiser
informed of progress, unless the incident is specifically sof tware related, in which case SSC holds the
responsibility for confirming details of closure.
The HSD / SMC manage the complete end-to-end Incident process. Their activities include:
« Regularly monitoring the status and progress towards r_esolution of all open Incidents.
« Keeping affected users informed of progress without waiting for them to call, thus creating a pro-
active profile.
« Monitoring Serv ice Level target (SLT) information and escalating accordingly if an incident looks
likely to breach SLA thresholds.
« Updating HSD /SMC knowledge database f rom information supplied by SSC KEL. This may be
applied as a direct copy or am __ ended for use by the agents, dependent upon the technical
complexity of the update.
4.9.4.2 Major Incidents Definition
As a general rule a Major Incident will always be an incident rated as severity level A (critical) in the POA
BU Operations Incident Managem ent Procedure docum ent (SVM/SDM/PRO/0018), or a series of
connected lower severity rated Incidents, which combine to have a significant business impact. However
not all incidents rated at sev erity level A qualify as Major Incidents ( 6.4). This is because the sev erity
levels do not necessarily translate to the global business impact on POL’s business. For example a single
counter post office which is unable to transact, regardless of its business volumes is rated as a Severity
A.
For simplicity, Incidents are classified into three impact levels: High, Medium and Low.
High — An Incident that has occurred with a significant and potentially prolonged adv erse impact on POL
business. Typically these Incidents will initially require a significant am _ ount of reactive management
before they can be controlled and resolved.
Medium — An Incident that has the potential to cause significant im pact to POL business but can be
controlled and mitigated against through effective management.
Low — An Incident that requires business attention but if managed effectively will not hav e significant
impact on POL business.
A Major Incident can be triggered by a range of causes including network triggers, application / serv ice
outages, hardware / infrastructure failures or security issues.
Description of Fujitsu's System 30
FUJ00237007
FUJ00237007
Fe)
FUJITSU
In the event of a Security Major Incident (which may also include PCI Incidents), the Security SDM MUST
be alerted and they will then follow the Security Incident Management procedure as detailed in both:
* SVM/SDM/PRO/0018 Appendix A.
« SVM/SDM/PLA/0031 HNG-X Security Business Continuity Plan defines the actions to be taken if
security violations are identified.
4.9.5 Major Incident Process
An initial impact assessment of an incident is undertaken by members of the IMT to determine if it should
be classified as a Major Incident, taking into account as described above.
The Major Incident Manager will consult with the Business Continuity Plans to identify if potential Major
Business Continuity Incident (MBCI) or MBCI triggers hav e been m et and inf orm POA Business
Continuity Manager if appropriate.
POL Service Delivery (SD) will be inf ormed by the Major Incident Manager of the incident, and the
incident will also be escalated to Fujitsu Service Delivery / Service Support team managers, if this has not
already occurred.
With agreement from POA Service Delivery Manager/s, or Duty Manager out of hours, a Short Message
(Phone text) will be sent to POA and POL Management alerting to the potential existence of a Major
Incident.
Once a Major Incident is opened the relev ant internal SDUs / Third Parties are contacted to initiate
investigation and diagnosis and the Major Incident Manager opens a Major Incident Report which is held
on SharePoint.
A Technical Bridge is scheduled, with a standard agenda, with all the relevant Service Delivery Units, IMT
and Service Delivery Managers (SDM) and an agenda distributed. The Technical Bridge is technically
focused.
The Technical Bridge aims to:
« To discuss & agree the recov ery investigation & resolution of Major Incidents.
«¢Toprov idea forum for up-to-date progress reports.
* To aidcomm __ unication and, if necessary, support the Technical Recov ery Manager (TRM) in
producing a short term technical recovery plan and if appropriate longer term corrective actions.
These will be included in the Major Incident (MI) report. This ensures that Major Incident progress
is known by all, whilst also, ensuring that all actions whether short term or long term are clearly
stated.
* To collate information for inclusion on the Service Portal.
Attendees at the Technical Bridge include, but are not limited to, POA Serv ice Management, SDU, Third
Parties, POL, and POA Security & POL Security Managers.
If the outcome of the Technical Bridge is that the Incident is determined Business A s Usual (low) then a
SMS communication will be sent stating that the Incident is not a Major Incident, and the incident is then
resolved using the standard incident management process.
The Major Incident Manager will also distribute actions (prov ided by the Technical Recov ery Manager
(TRM), following the conference call.
If during the Technical Bridge a clear recovery path is identified, this is discussed and agreed on the call.
Following agreement the recovery is implemented.
Description of Fujitsu's System 31
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Following the Technical Bridge the Technical Recov ery Manager will liaise with the SDUs and / or third
parties during the inv estigation / recovery. If no clear recov ery path is identified, the decision is then
taken on whether to escalate for Service Bridge direction.
The nature of the Major Incident determines which POA BU Service Team members and POL Managers
are involved in the Service Bridge.
The purpose of the Service Bridge is to:
« Prov ide appropriate direction on Incident resolution.
« Prov ide added impetus to restoration of service ASAP.
« Define communication intervals to Key Stakeholders.
« Prov ide focused Incident Managerrent in line with the impact and severity of the Incident.
Once the incident is deem ed to be resolv ed, a final Technical Bridge is held to agree and confirm the
resolution of incident. The Major Incident Review date is set atthe f —_inal Technical Bridge. SMS
communication is sent confirming resolution of incident.
A Draft Major Incident Report is distributed within 24hrs ofresolution of Major Incident.
Once a Major Incident is resolv ed there is a Form al Closure of the Major Incident and a review of the
Incident including consideration of:
« Lessons learnt.
Incident def inition.
« W_hat went well?
«Tim eline
« Changes required to infrastructure.
« Arev_iew of the Major Incident Communication Procedure.
« Root Cause Analysis.
« Business im pact.
¢ Action plan, including any changes requiring MSC’s.
« Serv ice Improvement Plan update.
« Rev_iew service risk(s) and update Risk Register as appropriate.
4.9.6 Security Incident Pr ocess
An inf ormation security Incident is:"an adv _erse ev ent or series of ev ents that com promises the
confidentiality, integrity or av ailability of Fujitsu Services Post Office Account inf ormation or information
technology assets, hav ing an adv erse im pact on Fujitsu Serv ices and/or POL reputation, brand,
performance or ability to m eet its regulatory or legal obligations." This will also extend to include asset s
entrusted to Fujitsu including data belonging to Post Office Ltd, its clients and its custoners.
Fujitsu classifies Security incidents using one of two levels of severity:
« A MINOR incident will norm ally have limited and localised impact and be confined to one domain.
* AMAJOR incident will have a significant impact on the Network Banking Automation Community.
NB. For a Major Incident the POA Major Incident Process (SVM/SDM/PRO/0001) is 6llowed.
Description of Fujitsu's System 32
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Whenever a security incident is identified which presents a serious threat to conducting normal business
it is contained and isolated as quickly as possible.
A security Incident is first notified to a person’s Line M anager. The Line Manager gathers as much detail
of the incident as possible, f ollowing Fujitsu BMS procedures. He or she will undertake an initial local
investigation into the incident, seeking to ensure that in the case of missing equipm ent or materials that
they have not just been misplaced. Information gathered will be entered into the initial Fujitsu case report
template (ICR).
If the severity of the Incident is considered as Minor but warrants further investigation, the Line Manager
would immediately log a call with the Horizon Serv_ ice Desk, stating that they are reporting a security
incident, giving brief details. Hav ing logged the call and obtained a call ref. erence number, the Line
Manager may then continue with the investigation if they believe the incident warrants this, and act as a
liaison between the person reporting and all concerned parties. All Incidents reported to the HSD with a
call reference and even when classified as Minor are still f orwarded to POA Security Managem ent to
determine if there is a Security Impact.
If the severity of the Security Incident is considered as Major, the Incident details are reported directly to
the POA Security Manager imm_ ediately. Depending on the type of Incident and the severity of the
incident, POA Security m akes the decision to escalate the details to the POL Security. In the case of
Data Centre incidents specifically, POA Security also inf orms the Data Centre Manager if this has not
already been done. Regardless of the severity of the incident, when a com promise in card data occurs,
the incident is reported to POL Security so that POL can com ply with its contractual obligations with its
card acquirer.
Once a call is raised with the SSC the call is then placed on the call stack of the POA Security Team,
which monitors the incident, assist or advises the Line Manager if required, and be available to take over
the investigation should the need arise, but always be able to respond, within 2 hours of _ the initial call
being made.
In most cases, the initial inv estigation of a reported incident is carried out by anom_ inated investigator
normally the POA Security Manager or his nominated deputy. POA and POL Security Team s will be on
hand to provide backup and assistance if required. The inv estigator will endeav our to obtain as m uch
original evidence as possible. In the ev ent of a court appearance the court prefers the original evidence
rather than a copy but will accept a duplicate if the original is lost or destroyed or is in the possession ofa
third party who cannot be subpoenaed.
Following the initial inv estigation and where considered appropriate, the inv estigator reports to / liaises
with the local Police and / or other external Agencies; this will only be done following consultation with the
POL Head of security and POL Head of Information Security or substitute.
Copies of the initial and f ollow up reports are submitted to relev ant authorities and details of
investigations are held on file by POA Security to aid subsequent trend analysis.
When the final report of an investigation has been com pleted, it is passed to the relev ant authority for
follow up action, the results of which are reférred back to the POA Security Manager.
When an inv estigation is closed the POA Security Manager seek s to ensure that details of the
investigation have been recorded and can be made available for subsequent future analysis.
On call closure, the POA Security Team completes and notifies CPNI where required. Thereafter the
incident is rev iewed to identif y the lessons learnt and the processes and relev ant documentation is
updated as appropriate.
Description of Fujitsu's System 33
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.9.6.1 Security Incident Trends and Checks
POA Security Team carries outa m_ onthly check of inv estigations and creates asumm_ ary report
highlighting incidents to the POL Head of Information Security.
The report highlights trends or weaknesses which m ay need to be raised at f uture Information Security
Management Forums (ISMF).
Details from the monthly reports may also be considered suitable for Line Managers.
4.9.7 Network Incident Managem _ ent
Incidents relating to network problems are managed using the standard incident management processes
and controls described above.
4.9.8 Networks
7. Control Objective 7: Controls provide reasonable assurance that networks are managed to
contractual and site requirements, monitored for availability and response times and issues
are identified, tracked and resolved.
# Control
5.6 Monitoring of Service Delivery: A monthly Service Review Book is provided to POL to review
its agreed Serv ice Levels. Within this book are det ails of capacity, av ailability and incident
management performance.
71 Network performance criteria: Network availability and performance requirements are clearly
defined between Fujitsu and POL in the Network Serv_ice descriptions and network serv ice is
measured and monitored using these agreed servce levels.
7.2 Network change management: Network changes are m anaged using the standard Fujitsu
MSC process including authorisation, testing (where deem ed appropriate) and approv al of
changes before they are implemented.
7.3 Network availability monitoring: Network availability is m onitored using sev eral tools which
send autom ated alerts to the Network Operating Support Serv ice Team (NOSS) if key
components are unavailable, or if traffic levels breach predefined thresholds.
74 Network incident management: Incidents relating to network av ailability are m anaged using
standard incident management procedures used on the POA, and are included in the standard
incident management reporting to POL.
4.9.8.1 Network Service Description
POL defines the network serv ices it requires f rom Fujitsu in two contract controlled docum ents the
Branch Services Network Serv ice Description (SVM/SDM/SD/0011) and the Central Network Serv ice
description (SVM/SDM/SD/0012) (7.1 and 7.2).
4.9.8.2 Provision of the Network Service
Fujitsu provides a network service to POL using its Hosting and Network Serv ices (HNS) teams. These
teams provide technical support and implementation for the following products and platforms:
« The HNS Post Office Account Network team —_ based in W arrington supports Routers, S witches,
Load balancers and Firewalls.
« A separate team also based in W__arrington supports the Intrusion Detection System (IDS) and
proxy server (Web Washer).
Description of Fujitsu's System 34
FUJ00237007
FUJ00237007
Fe)
FUJITSU
« Acentralised Network Operations Support Serv ice (NOSS) overviews and monitors the systems.
Wide Area Network Services are provided through a num ber of third parties depending on the circuit or
communications requirement.
Controls operated by these third parties are outside the scope ofthis report.
4.9.8.3 Network Change Management
Fujitsu f ollows the MSC change m_ anagement structure f or all changes to Network equipm ent as
described below in section 4.9.9 which describes Control Objective 8 (7.3).
4.9.8.4 Network Availability Monitoring
Fujitsu has it own dedicated Network Operating Support Serv ice to m onitor the av ailability of Network
Services to POL and these use the Triole for Service tool (TFS) to raise problem s or incidents to the
Network, Firewall or IDS teams and where applicable the Incident management process (described under
Control Objective 6) is used to resolve these (7.4).
4.9.8.5 Network Service Monitoring
A monthly Service Review Book is prov ided to POL to rev iew its agreed Service Levels and within this
book are details of Network perf ormance. This book is jointly rev iewed monthly at a Serv ice Review
Board and network performance is included.
4.9.8.6 Overview of Network Technical Design
The Network that Fujitsu prov ides to support its serv ices and applications to POL is divided into the
following at the top level:
e IP Network Space Data Centre Networks.
« Branch Networks.
Transit Networks.
« W_ ide Area Networks.
As shown in the diagram overleaf.
Description of Fujitsu's System 35
FUJ00237007
FUJ00237007
IRE 1x Data Centre Data Centre
Core Tier iP Storage
High Speed Layer3 switching between Routing
Distribution Tiers
Connectivity between Data Centre's
Distribution Tier . I
Server port density Post Server
Virtualization, Branch Client Office Support I I connectivity
Load Balancing, ‘SAN
Security (VPN, Firewalls, IDS) / “ /
Post - i
Branch Client I I I Support I I Client I
Access Tier I : Office
Remote Access , I I I SAN
Connectivity between Data Centers I" Beefiag Arrangement I extension
I {Peering Arrangement
Securiy (VPN, Firewalls IPS) f LPeinsttaN I
Sa —— tL ——! a
Branch wage ea Network ( RMGA provided Wide Area Network & tN
a a _ Wide Area Networks)”
a Remote I Client Post Support
Branch LAN Locations Office
— Pearing Arrangement Transit LAN
(Pod I I o>
( office )I I (Support) mode
Network’ I I \Network? NetwoniAcmocxe 8d
Testing is prov ided through the standby data centre f or Live System Test and System and Volum e
Integration during normal operations. This test support would disappear if the standby data centre was
required to act the prim ary. Under norm al business as usual conditions the traffic is segregated with
access between production and test env ironments prevented by means of various physical and logical
means of separation as appropriate. Change Managem ent is strictly controlled through av __ariety of
internal change & release processes and procedures — see below f or more inf ormation on change
management for network components [Control Objective 8).
The network is div ided into 11 Security Dom ains. The term Network dom ain is defined tom eana
collection of platforms and network components grouped together based on type, perceived vulnerability
and risk rating. Even so, it may be necessary to restrict traffic between platf orms in a common Security
Domain (intra-dom ain traffic) through the im _—_ plementation of logical separation, (using VLAN’s), or
physical separation, (using separate network segrrents in the same domain).
Any traffic which crosses network dom ain boundaries (inter-dom ain traffic) m ust pass through an
enforcement point that restricts data flow based on its source, destination, protocol, port, type or content /
format. This can be a firewall, router or other in-line control point. (i.e., the control is physically part of the
data path)
The following diagram illustrates how Network Domains fit within the Network tier model.
Description of Fujitsu's System 36
FUJ00237007
FUJ00237007
Re)
FUJITSU
ee ‘is anion i sain ane mene
I {
I
I Ios
I I
I
I
I ee a
Network Domains are the basic building blocks for enforcing security in the Network.
The Domain structure places a logical ring around the logical Security Perimeter of the HNG-X Network in
the Data Centres, but this perimeter extends beyond the Data Centre in some cases and is protected by
means of IPSEC VPN technology using access lists to allow specif ic classes of traffic to enter HNG-X.
More specifically, this perim eter can be best described as the collection of dev ices m anaged (or
monitored) by Fujitsu Serv ices. At the boundary of these m anaged devices a f irewall (hardware or
software-based) will be located, and the perimeter will be secured according to firewall guidelines laid out
in ARC/NET/ARC/0001.
4.9.8.7 Network Asset Management
Network Assets are m anaged through Cisco W orks Inventory along with an offline hardware inv entory
register. Hardware and Sof tware maintenance is on a business case basis and is based on business
availability targets.
Description of Fujitsu's System 37
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.9.9 Change Managem _ ent
8. Control Objective 8: Controls provide reasonable assurance that modifications to system
software and networks are authorised, tested, approved, properly implemented and
documented.
Control
8.1 Change management: The MSC toolset is used to m anage all changes with a joint decision
between Fujitsu and POL as to which parts ofthe tool are relevant for a change.
8.2 Change approval: All changes m ust be authorised by the Fujitsu Duty Manager or technical
bridge, with approval being documented in the MSC system. Changes that cause major service
interruption must also be authorised by the Change Advisory Board (CAB), with approval being
documented in the meeting minutes and within the MSC system
8.3 Emergency Changes: A change deem ed necessary in order to resum e live service will be
agreed and authorised and docum ented during the incident along with updates to POL at an
agreed timeframe dependent on the severity of the incident.
4.9.9.1 Business as Usual Change
All change is subject to the Managed Sy = stem Change (MSC) change pr ocess whether it requires
changes to existing serv ices or the m anaging of new serv ices or functionality (8.1). Key change types
that fall into scope for this process are listed below:
« Changes that require physical access to or are m_ aking changes to POL services being hosted in
Data Centres.
« Changes that are requested to be shared by POL Data Centres or Branch Counter estate by
either:
o Asupplier ie., BT, C&W _, the Data Centre utility suppliers etc.
o Shared network s
o Shared infrastructure
o Account specific infrastructure
o Account specific networks
« Changes that require the release of an application software change or support patching / security
patching changes.
« POLSAP serv ice offering change.
« Credence serv ice server support changes (note these relate only to hosting of the service).
« On-line serv ices changes.
« Changes as the result of an Incident.
* Changes to resolv e a Problem.
These changes include POL authorised project work with Fujitsu or POL 3 @ Party or POL Network
Partners. These types of changes are supplied by POL and are then recorded in MSC and assessed /
reviewed by Fujitsu staff with issues or concerns &d back to POL.
The Manage Serv ice Change (MSC) operational change process uses the Fujitsu MSC toolset to
progress the change through control gates which are described overleaf.
The MSC toolset is secure and auditable (at both system —_and user lev els with tim e stam ping being
employed). As changes are made to a change record and it progresses through the control gates listed
below with permissions and ownership of the change recorded at the various stages.
Description of Fujitsu's System 38
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Both POL and Fujitsu change control team s participate in tailoring the questions in the MSC toolset to
enable the relev ant information to be obtained f or POL’s internal change process. This helps their
network partners and third party suppliers assess a Fujitsu-controlled change f _or risks and im pacts.
These controls, along with the KPI's established by POL to m onitor the MSC toolset information
standards for quality, timings of the notice of the change etc., help to ensure the efficient and eff ective
control and management of operational change.
Once a change is ready to be tested it becom es subject to the Manage Service Change (MSC) process
and Change Advisory Board (CAB) approvals are obtained before deployment can begin, approvals are
documented both in CAB m eeting minutes and within the MSC system (although these are not f ormal
signoffs, for example, they can be copied in from POL e-mails).
The control gates to be established around change are:
« The request f or the change from POL (projects).
« The establishment of a Design Proposal by POL (projects).
« The acceptance of the Design Proposal by Fujitsu (projects).
* POL raises a Change Request (CR) or a Contract Technical Change (CT) or Contract Change
Notice (projects).
« Fujitsu raises a Change Proposal (CP) to im pact change (projects).
* Costs and IIm_ pacts are sent to POL and approved or rejected (projects).
«lf accepted, then a set of Requirements is jointly agreed with POL (projects).
« A project is initiated and project plans drawn up (projects).
« Architecture, High Lev el Designs and Low level Designs and interface documents are written and
where appropriate discussed with POL.
« Dev _ elopment of Code is undertaken (projects).
« Code is tested by development (projects).
* Code is packaged by integration into Dim ensions ready f or deliv ery to System Volume and
Integration Test or Live Systems Test (projects).
« Code is tested by Solution Validation & Integration(SV&I) and Liv e Systems Test (LST) based on
project plans from requirements (projects).
Tickets are raised in the PEAK system (these are known as PEAKS) f or defects identified by
SV&l and / or LST (projects).
* Def ects are fixed and follow Test cycle until approved (projects).
« Consecutiv ely to Code Development platf orms are built where appropriate using current
standards (projects).
e Platforms are tested in conjunction with the code in SV&l and LST (projects).
« PEAKS are raised f or defects (projects).
« Def ects are fixed and follow Test cycle until approved (projects).
* Todeliv er integration packages to SV&l & test the recording of the change takes place in MSC
and contains appropriate release notes and details (Projects).
« MSC is used to Record and authorise BAU changes also (Operational changes).
« The MSC systems records assessment by other potentially impacted team s to determine risks
associated with the change in their area (Operational Changes).
Description of Fujitsu's System 39
FUJ00237007
FUJ00237007
Fe)
FUJITSU
« The MSC system ss contains a plan of the change (Operational Changes).
«The MSC team agrees the change internally and with the custom er where relev ant at CAB’s,
(Operational Changes).
* The CAB’s review helps to ensure (Operational Changes):
o The change m eets the governance requirements
o The change does not ov erlap with other changes
o That the change has considered any group or associated f —_urther risks and im pacts by
doing the change
o The CAB follows the standard CAB Term s of Reference (TOR) which defines:
= Attendees
= sign off or rejection or associated actions
= recording and issuing of minutes from the CAB
= Updating the MSC toolset with the CAB decision
« The Change Manager satisfies them selves that the change has (Operational Changes):
o Met all areas of governance
o Considered im pacts / risks
o CAB agreem ent for the change to proceed is in place
« Ifthe above are in place, the Change Manager authorises the change within the MSC system to
proceed and implement the change (Operational Changes) @.2).
« Postim plementation outcom es of change are recorded in post im _ plementation rev iew and
records are updated and success criteria ex amined and lessons learnt are docum ented
(Operational Changes).
« Change close down (Operational Changes).
In summary, MSC is a Fujitsu toolset that allows a securely accessed, time stamped auditable system to
record change, provides Service Delivery Units and Service owners with audit trails and gives reasonable
assurance that m odifications to sof tware and inf rastructure are assessed f or risks & im pacts. The
changes are authorised by the Service owner and Change Manager, are tested by appropriate m ethods
and teams, and are approv ed to be deployed to a live env ironment subject to testing results, they are
implemented by the authorised and approved teams and the changes are docum_ ented into new or
existing documentation.
Description of Fujitsu's System 40
FUJ00237007
FUJ00237007
FUJITSU ES
MSC Process Step-Qvaview
Notice sett to FOL lier for I
Approval of Crengeand = MSCRequest I
uncersendngd inpacts I
witha view authaisation Pd_appo d Crane and I
to) ary Aoryiare Giteria, I
x Tirings their Rejection I
Plan dttedane I
Git Pret I
a I
Fired Cot&
Testi I
Non SericeAffeting Low Risk I sates I
A=Approve to proceed further R= Optional Reviewpproe ATI Approval to Injpleent I
48 OFjitsu Sates 206 AanFlack NMenege Sevice Geye = = o I
FUIITSU I
I
Description of Fujitsu's System 41
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.9.9.2 Emergency Changes
Emergency changes are progressed through one of two nethods:
© aserv ice incident; or
ethe em ergency CAB (E-CAB) process.
Both processes will document changes required in the MSC toolset.
A service-affecting incident sees a technical bridge conv ened (see the incident management section of
this document above — Control Objective 6) to analyse the cause and im pacts of the incident. This team
will include serv ice managers, an incident m anager and technical staff and the Operational change
manager. Any change deemed necessary in order to resume live service will be agreed and authorised
and documented during the incident along with updates to POL at an agreed timefame dependent on the
severity of the incident.
If the lev el of the em ergency is at lower lev el such as a disk failure the resolv er (often an incident
manager) will request that an E-CAB is called. The Change manager will call the E-CAB meeting together
following the process as docum ented in the CAB Term s of Reference (TOR) via a conf erence call to
discuss the change with both technical staff and service managers. The MSC r ecord will be E-m ailed
around the mandatory assessment teams with a timeframe turn round of assessments within an hour and
documented with the Incident Management documentation. The incident or change manager will contact
POL Change Control to discuss the em ergency and ask for verbal permission to proceed during which
time the Fujitsu change Administration staff will send the change ov er to POL Change Control f or their
records (8.3).
9. Control Objective 9: Controls provide reasonable assurance that new or modified application
software development efforts are authorised, tested, approved, properly implemented and
documented.
Control
9.1 System Development and Maintenance policies and procedures: Fujitsu has af ormal
Systems Dev elopment Lif e cycle (SDLC) which incorporates phases including initiation,
Requirements, Definition, Design, Development, Deployment and Maintenance.
9.2 Change Control Board: Depending on the nature, changes m ust either be approv ed by the
Change Control Board (CCB) bef ore progressing into dev elopment or by the PEAK Targeting
Forum (PTF).
9.3 Design Proposal: Projects are outlined in a Design Proposal (DPR) that is held in DOORS or
Sharepoint and is reviewed and approved by POL as well as Fujitsu management.
94 Change Testing: Changes are tested in line with the defined procedure.
9.5 Ability to implement changes: Only appropriate individuals have access needed to move code
builds between environments or prom ote transports to liv e. Segregation of duties is enf orced
between users able to develop and implement changes.
9.6 Approval to implement changes: POL approval is required to prom ote software changes to
the live environment. Approval is captured within the relevant MSC.
Fujitsu’s change management process consists of two com ponents Project Changes and Business a s
Usual (BAU) changes. Project changes relate to the deliv ery of new or changed serv ices and BAU
Changes to Operational changes to the live service provided to POL (9.1).
Description of Fujitsu's System 42
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.9.9.3 Project Changes for HNG-X and SAP
External requests for changes will be raised on a change request and sent electronically to Comm ercial
Change Management (ChM) and allocated to a Change Owner and conv erted into a Change Proposal
(CP).
All CPs are initially reviewed by appropriate teams and are returned to ChM where they are collated and
shared with the Change Owners and where appropri _ ate indicate that they hav e the Design Authority
Board approval (DAB).
Once reviewed, CPs will be submitted to the Programme Change Control Board (PCCB) for agreerent to
progress the CP. The PCCB typically meets weekly. The PCCB is chaired by ChM and brings together
representatives from a wide range of functions potentially affected by proposed changes.
Once the PCCB has assessed and agreed the progression of a CP, it will be submitted to the Change
Control Board (CCB), which includes the Account m anagement team, with a recomm endation from the
PCCB as to whether the CCB should approve or reject it (9.2).
The CCB typically meets weekly. Change Owners are required to attend to sponsor the change detailed
in their CP. The CCB consists of members who represent the key functions within the Account to ensure
that if the CP is accepted for implementation it will:
¢ Commercial / Finance
o Hav eno adverse financial or commercial implications
o Not increase the ov _erall risk to the Account / Custom er contract and Service
commitments
« Customer Service
o Be operationally supportable and will m eet the Account’s service obligations
« Development
o Be dev eloped within the agreed timescales to the required quality level
¢ Architects
o Be constrained within the overall architectural solution and is technically vable
« Testing
o Be tested and integrated to the required quality lev el within the agreed timescales
e Business Management
o Not inhibit the Account in exploiting future business opportunities for the Account and its
Customers
A minimum of three Directors are required to be in attendance f or a CCB to be able to reach a decision
on CPs.
Minutes from both of these meetings showing approval of the CP are held in PVCS.
Once the CCB has approved a change the following occurs:
¢ If the change is internal the Programm e team is advised, time codes and plan activities are set-
up and work can start.
elf itis external, the change will be subm itted to the customer (electronically and hard-copy) and
POL reviews the change until formal agreement which then allows the CP to be progressed.
Work on a project will not begin unless approval is in place.
Description of Fujitsu's System 43
FUJ00237007
FUJ00237007
Re)
FUJITSU
Project Changes are allocated unique num _ bers and lodged within a database (PVCS) and related
accordingly. These can be v iewed by all m embers of the team working on that project but can only be
updated, edited and actioned by members of ChM.
All Minutes from the Change Boards (PCCB and CCB) and actions f rom the same are recorded in the
change history of the change vehicles in the database.
Comments and decision around the changes are also lodged in the change history.
CP Impacts are collated into CP specific files and stored on a back-up sener.
Approvals from the CCB and POL are documented in the relevant change history.
4.9.9.4 Projects for HNG-X
Fujitsu follows its Corporate Methodology outlined in the diagram below to deliver a project to POL. Each
project has clear requirem ents, is designed, tested and deployed prior to its acceptance into the Liv e
Production Estate. All projects are assigned a Project Manager to deliv er the specific project with
oversight of all projects by the Programme Director.
Customer
Change
Design & Development Testing Deployment
The diagram below shows an overview of the design and builds m ethodology used by Fujitsu to define,
design, develop and deliver a project into the POL production environment.
This Methodology is used for HNG-X projects and projects that integrate HNG-X and SAP.
Description of Fujitsu's System 44
FUJ00237007
FUJ00237007
Re)
FUJITSU
HNGxDBM unex Design & Build Method Lifecycle Method (v1)
Inputs Imtegrate & Test “Support implementation
Strategic p 2 I Il
; =
eas at I
SS twanage I
Integration Release i
POA Stterert Process II Process i
5 Process I
hens
ee Stress I
reattepot
HNGK (STR)
‘event
‘ray
or <Stresen=
I acct eat
HNOX Test I Report (UAT
Waamneas Saran, I Pulte tra Ercuin
TERE sen }
Project II Requirements I
Management ih casei Process I
‘tater i
i Bannng A Prep [Toa : TeabemtnsN I I
"See ~~ > E> E>
ea
x z Srtmonsion
gs om : — I
~~ Process ees 5). > I Soeur HP) Pack (RAP) Document 048 >
4.9.9.5 Definition
POL defines projects according to their def ined business needs and prov_ ides these to Fujitsu as
documented requirements and acceptance criteria.
4.9.9.6 Requirements
Requirements are managed within Fujitsu by the Requirements manager.
POL defines a requirements baseline and where applicable a baseline design proposal (DPR) and Fujitsu
may be requested to assist POL in the preparation of these ( 9.3). These requirements are stored within
the POL DOORS system and replicated within Fujitsu and exceptions, non-compliances etc are recorded
in the Design Proposal and in the Commercial Term s response to POL. The DOORS system is jointly
managed by Fujitsu and POL and is used to contain the docurentation of the requirements for changes.
The Design Proposal contains 3 key elements:
« The Acceptance Criteria.
« The W_ ork Packages that are built to deliver the project.
* The Monitoring Criteria f or the project after go live.
There is no f ormal POL sign off of the DPR howev er they are inv olved throughout the process and
through the use of DOORS have visibility of the detailed requirements that the project must deliver. Once
POL has approved the detailed requirements in DOORS this is taken as approv al of the overall DPR by
POL.
Description of Fujitsu’s System 45
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.9.9.7 Design
Application Development for the in scope applications will be performed by a range of Fujitsu teams
depending on the nature of the project.
4.9.9.8 SDLC Methodology
POA Design and Build Methodology (DBM) engineering lif ecycle was derived from the Fujitsu corporate
Applications Design and Build Methodology (ADBM), Infrastructure Design and Build Methodology
(IDBM) and Test & Validation lif ecycles. This is the SDLC currently used by Post Office Account (POA)
team to m odify existing or dev elop new applications for Post Office Limited (POL). It is defined in the
standard document sets that are specific to the in scope applications.
High level designs (HLD) and Low-lev el designs (LLD) are the way Fujitsu m_ eets the relev ant Design
Proposal requirements and these are stored in Dimensions or SharePoint. The HLD’s and LLD’s for
HNG-X projects are approv _ ed by one of the approv ers defined in PGM/DCM/ION/0001 &
PGM/DCM/PRO/0001. SAP HLD’s and LLD’s are approved more informally within the SAP teams.
4.9.9.9 Code Build and Test
The Dev elopment Manager is responsible f or the building and testing of code. Code is built in a
segregated env ironment using appropriate repositories. These r epositories use standard code
management tools including locking, the booking of code in and out and the m anagement of changes.
Each project will have a Development manager who will take the relevant HLD’s and LLD’s and allocate
these to developers, the Development manager will also develop their own project plan to track progress
of the code development and testing. Code will be booked out by dev elopers and worked on within the
context of this project plan.
A generic code rev iew template is used to rev iew the code and it is approv ed by the Team Leader or
Senior Designer once outstanding issues are resolv ed. The resulting rev iew docum ent is stored in
SharePoint.
Individual Dev elopers are responsible f or producing Unit Test plans and rev _iewed by a separate
developer. The initial dev eloper will then dev elop the Unit Test plan which will be signed off by the
reviewer, a developer will then execute the unit test plan and the results are recorded by the Dev eloper
in the Unit Test plan — usually as an appendix and the com bined Test plan and report is stored in
SharePoint / Dimensions. This evidence of results of testing is then signed off by a separate developer.
Component Integration Testing (CIT) is an independent testing phase that carries out initial integration of
developed com ponents it is perf ormed to a CIT test schedule produced by the CIT tester and the
schedule is updated with test results and stored in SharePoint / Dim ensions. A f ormalised def ect
management (JIRA / Quality Centre) is used to record and track issues to resolution. The CIT testing is
undertaken in a segregated environment under the supervision of the CIT manager.
Approval to move from the Code build and Test phase is an informal process agreed by the Development
Manager and CIT manager. Once the Development is assessed as passing CIT the Development team
will use one of the standard tools to create a deployable build of the updated / new sof tware, they will
then place this build into Dimensions f _ or integration to then load into the next test env ironment.
Development only have access to place the build into Dimensions, they cannot then move it into the next
test environment.
Description of Fujitsu's System 46
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.9.9.10 Integration and Test
HNG-xX has 2 test streams responsible for testing software changes to the live estate:
* Solution Validation and Integration (SV&l):
o Testing against Requirements - Functional and Non Functional cov ering business and
infrastructure and based on testing the complete integrated solution
o Has End-to-End capability f or testing with 3rd parties e.g., Merchant Acquirer
«Liv e Support Test (LST):
co Final pre-production prov ing and release deployment validation
The dev elopment-written test autom ation framework (docum ented in TST/SOT/HTP/0976) has been
deployed into the SV&I environment to support testing. This automation framework offers the benefits of
unattended execution, and allows the expansion of the automation suite to encompass a larger share of
the regression test overhead.
Testing uses Quality Centre as the test m anagement and def ect m anagement tool f or def ect
management. Quality Centre interf aces with Peak which is the POA Dev elopment Defect Management
System:
« Adherence to gateway criteria such as test stage entry criteria.
Entry into each test stream (or test cycle within test stream _) will be subject to rev iew against a pre-
defined and agreed set of entry criteria. These criteria are set by the Test stream manager. Similarly
testing within each stream will not be considered complete until the testing is adequately reported and a
resolution path for all outstanding issues is understood (9.4):
« Progressive, incremental development, testing and acceptance.
Each test cycle is subject to entry criteria acceptance. Quality Centre is used to store and m easure
progress against project requirem ents. An assessment of requirements coverage is produced towards
the end of test completion. This feeds into the Acceptance Process which is a joint board (with POL) with
agreed criteria for acceptance.
4.9.9.11 SV&l Testing Process
Test Analysis is based on Requirem ents and high level designs. Test cases are docum ented in Quality
Centre (QC) and details are ex tracted into a High Lev el Test Plan f or each release. This docum ent is
reviewed via POA document management.
Entry into Test Cycles is controlled by Test Readiness Revews.
Test Execution is recorded in QC and defects are recorded within QC.
Daily and Weekly reports are produced using QC to produce statistics e.g., test cowrage.
After the last cycle of testing (pre LST) a report is produced covering the full release.
4.9.9.12 LST Testing Process
Testing is controlled via the Release Management team.
Release Planning sessions identify maintenance test slots and Peak targeting Forums assign defects into
appropriate maintenance releases.
Release Management engage with test via Release Notes and Deployment plans.
Description of Fujitsu's System 47
FUJ00237007
FUJ00237007
Fe)
FUJITSU
LST put test plans together which are held in SharePoint and once testing is complete these are updated
with results. LST assess test results and determine a release sign-off or release rejection position. The
final document is attached to the release peak which is returned to Release Managenent.
4.9.9.13 Acceptance
The Acceptance phase is managed by the Acceptance m anager. The Acceptance m anager will review
the progress of the testing teams in completing the testing specified for each acceptance criterion in the
design proposal. The results of testing are summarised in the Acceptance Report this is then discussed
by the Acceptance Assessm ent Board which rev iews the Acceptance report including Acceptance
Incidents. An acceptance incident is where the acceptance criteria hav e been tested and either not met
or are partially met.
A joint Release Acceptance Board is then held with POL to agree how to progress the Acceptanc e
Incidents and overall whether the project as stand alone entity is ready to be im plemented. The decision
is documented in the minutes of the release acceptance board which are held in Dirrensions.
The POL and Fujitsu Project Managers will then produce a slide pack for presentation to the Release
Authorisation Board; this board will then consider whether to approve implementation based on:
« The Release has passed the Release Acceptance Board.
« That Fujitsu Serv ice teams are ready to support the new serves / functionality.
* That Post Office Serv ice teams are ready to support the new servces / functionality.
« Thatcomm nications to interested parties e.g., Post Masters are ready.
Authorisation is documented in the meeting minutes that are held in Dimensions.
Once these approvals are in place the project can be implemented into production.
4.9.9.14 Deploy and Support
Release management is based around the use of two documentation tools, PEAK and Managed System
Change (MSC), and two delivery tools, Dimensions and Tivoli Provisioning Manager (TPM). A ticket will
be created in PEAK f or each change or elem ent of a project. The PEAK Targeting Forum (PTF) which
meets weekly reviews the open PEAK tickets and groups these into deploym ent groups each of which
contains typically no more than 20 PEAK tickets.
Development will then create a PEAK Fix Baseline (PFB) for the deployment group and this is effectively
what is placed into production on the successful completion of the relevant testing. Development will then
perform unit and com ponent and integration testing as outlined abov __e, once this is successfully
completed, they will use one of __ the standard tools to create a build package which is placed in
Dimensions.
The relev ant operating team s will then pick up the package and place it into the relev ant test
environments for further testing as outlined above. When the operating team moves the package into the
test environment Release m anagement will create a Release Note. Once testing is com plete Release
Management will update the release note to reflect this. They will also create a new release note with the
same number but a PR suffix to manage the movement into production.
At the same time as Release Management release the RN to the LST team, the ticket will be created in
MSC. MSC is used by Release Management to manage the process steps that need to be completed to
move a change into production. The approv als to move the change through the v arious stages (both
Fujitsu and POL approvals) are logged in the MSC ticket, and are typically copies of emails pasted into
the ticket- MSC does not use formal workflow-based sign offs (9.6).
Description of Fujitsu's System 48
FUJ00237007
FUJ00237007
Fe)
FUJITSU
When Release Managem ent believes the package is ready to be im_ plemented the PR suffix Release
note will be passed to Sof tware Configuration Managem ent (SCM). SCM will then place this package
onto the TPM server, based on receiving authority from Release Management, in the Release Note. SCM
are the only team with access rights to move software onto the TPM server.
The final move into production is then made by the relevant deployment team, depending on the platform
the change is being made to (9.5). The authority and ability to m ove the change into production is given
to the deployment team when Release Management assigns the MSC and the release note ticket to the
deployment team.
Once the deployment is complete the PEAK ticket will be raised by the Change Owner who opened it.
4.9.9.15 Post Implementation
4.9.9.15.1 Monitoring and Review
Fujitsu Project Managers monitor and control projects throughout their lifecycle through the following:
Weekly Releases report to Post Office Project Managers
A collated reporting pack issued to the Post Office Project Managers showing the RAG (Red, Amber, and
Green) status, Ex ecutive summ ary, key milestones, dependencies risks andi ssues for each of the
Releases that are currently in Delivery.
Monthly Joint Programme Board (with Post Office)
Presentation of a collated reporting pack to the Post Office Programm e Manager and the Fujitsu
Programme Director showing the RAG status, Ex ecutive summary, key milestones, dependencies risks
and issues for each of the Releases that are currently in Delivery.
Monthly Demand Planning Forum (with Post Office)
A monthly meeting held with Post Office to look at the forward expected work load f rom Post Office
against the committed resources currently allocated to the Account to see ifdem and equals resource
supply or if any whitespace (not enough work fr the committed resources).
Internal Fortnightly Releases Board
Presentation of a collated reporting pack to the Fujitsu Programm e Manager showing the RAG status,
Executive summary, key milestones, dependencies ri sks and issues f or each of the Releases that are
currently in Delivery.
Internal Monthly Programme Board
Presentation of a collated reporting pack to the senior Fujitsu Post Office Managem ent and Fujitsu
capability units showing the RAG status and Ex ecutive summary, plus any matters relevant at that time,
for each of the Releases that are currently in Delivery.
4.9.9.16 POLSAP Application Changes
4.9.9.16.1 POL SAP Application Changes Overview
POLSAP follows the account processes fr change control.
The customer will draft a change request (CR) which will be sent from POL’s change management team
to the change management team in Fujitsu.
Description of Fujitsu's System 49
FUJ00237007
FUJ00237007
Fe)
FUJITSU
It will send that CR to the relevant assessing team which will assess:
« The lev el of resource needed for the change.
« How long it might take.
« How m_ uch it might cost.
« W_hether it would impact anything else already being done br POL.
This assessment process is known as “impacting the change”, based on the information supplied. A
Change Proposal (CP) is drafted and sent to potentially affected teams to provide their impacts. This will
give an overview of what will be changed, what is not included, assumptions and a breakdown of effort in
man days.
Once impacts are collated, the CP is discussed at the Pre Change Control Board (PCCB), which m eets
weekly. The PCCB is made up of various technical and functional team leaders.
Changes are allocated unique num bers and lodged within a database (PVCS) and related accordingly.
These can be viewed by all members of the team working on that project but can only be updated, edited
and actioned by members of ChM.
All Minutes from the Change Boards (PCCB and Change Control Board (CCB)) and any actions from the
same are recorded in the change history of the change vehicles in the database.
All comments and decision around the changes are also lodged in the change history.
All CP Impacts are collated into CP specific files and sbred on a back-up server.
Approvals from the CCB and POL are docurrented in the relevant change history.
Once agreed at the PCCB and minuted as such (added to CP history in PVCS) a Comm __ ercial Terms.
(CT) document is created and di scussed at the Change Control Board (CCB), which m__ eets weekly.
Assuming this is approv ed by the CCB and minuted as such (added to CP history in PVCS) the CT is
then sent to POL. This whole process has to be com pleted in 21 days from Change request received to
CT sent to POL.
POL then has a further 21 days to agree the CT and sign it. Once a signed CT is receiv ed by the Fujitsu
change management team (initially by e-mail, fax and then signed hard-copy — stored locally at first then
transferred to a secure Fire-safe), this is announced to the Programme and relevant timesheet codes can
be created (aligned to the impacts included for the change) and work can begin on the change.
The change will be developed in the development client (PLD) and the relevant transports created. It will
be unit tested in this client bef ore the request is raised to m igrate the transports sim ultaneously to the
PLQ and PLE quality assurance clients. The transport requests are authorised by the POLSAP support
manager via emailed response to the Basis team and the actual migration is performed by the SAP Basis
Team.
The change will now be sy stem tested by the relev ant POLSAP Fujitsu team, and then integration, and
end to end tested by the dedicated Post Office testing team. The Post Office test team _ place their test
plans and any defects on their Quality Centre application.
Once all testing is com pleted and an em ailed sign off has been receiv ed from the Post Office testing
manager, or change manager, Fujitsu will raise an MSC for onward migration to the Production client.
This MSC is usually giv en seven working days notice period unless deem ed an emergency change by
the customer. The MSC will be discussed at the weekly CCB meeting and will not proceed unless all sign
offs both internally and from the customer have been received and updated on the MSC. In the case of
Description of Fujitsu's System 50
FUJ00237007
FUJ00237007
Fe)
FUJITSU
minor application changes, they may not be discussed at the CCB, however they will appear on the CCB
agenda and identified as a m inor change. The (Fujitsu) Post Office Account Operational Change team
determine which internal team s need to rev iew each MSC, however as f ar as approv als go, it is the
customer — The Post Office Change Manager approval thatis required to be on the MSC. This is
reflected in the notes section on the MSC itself and no change should go to Production without this
approval.
The development resource will then request the migration of the transport/s to the Production system in
line with the agreed tim elines detailed on the MSC. Again this transport will need em ailed authorisation
from the POLSAP support m anager to the SAP Basis team and is carried out by the SAP Basis team
The MSC process is described above under Control Objective 8.
4.9.9.17 Network Change Management
All Network changes are considered in accordance with established Fujitsu operational practices. All
changes require an approved design, all changes must be impact assessed by all business and technical
stakeholders, an im plementation plan is prov ided, and a change window is agreed and acted on. The
system used by Fujitsu f or change m anagement is the MSC system. Full details of the change
management are in the section above.
All docum ents concerning the architecture, design, serv ice deliv ery, monitoring and rev iew of POL
networks are held in the appropriate Fujitsu’s docurrent repositories Dimensions or SharePoint.
4.9.9.18 Exceptions to Fujitsu Change Management Process
The exception to this process is Ref erence Data which is supplied by POL f or onwards transmission to
the POL Branch Counter estate v ia the Fujitsu network and is subject to a POL authorisation / POA to
release and having followed the POL / POA reference data testing process.
4.9.10 Security
10. Control Objective 10: Controls provide reasonable assurance that access to system
resources, including computing platforms and operating systems, i s restricted to properly
authorised individuals.
# Control
10.1 Client Security Policies: Security requirem ents for infrastructure and software are designed,
documented and agreed by both POL and Fujitsu.
10.2 Baseline Operating System Standards: Platforms in operational use hav e defined baseline
standards that document their set up and configurations, as agreed by Post Office Limited.
10.3 Baseline Operating System Standards Implementation: Platforms in operational use are set
up and configured in line with documented and agreed baseline standards. Variances from the
baseline standard are fully documented and appropriately approved.
10.4 User (Fujitsu) Set-up and Amendment: Fujitsu users requiring new or modified access to Post
Office Limited system s are set up appropriately and approv ed by an appropriate Fujitsu line
manager.
10.5 User (Fujitsu) Deletion: Access to Post Office Limited systems for Fujitsu users is removed in
a timely manner once no longer required.
10.6 Periodic User Reviews: Fujitsu and POL m eet regularly in the ISMF to rev iew whether user
access to systems remains appropriate, with changes then processed as necessary by POL.
10.7 Two-Factor Authentication: Access to Post Office Limited system __s f or Fujitsu users is
controlled using two-factor authentication.
Description of Fujitsu's System 51
FUJ00237007
FUJ00237007
Fe)
FUJITSU
4.9.10.1 Policies and Procedures
The Comm unity Information Security Policy (CISP) prov ides gov ernance and direction in information
security for those responsible f or initiating, implementing or maintaining security for POL infrastructure.
The docum ent describes end-to-end security m I anagement process and phy _ sical and technical
requirements for the in scope systems. This document is authored by POL and shared with relevant third
parties. Fujitsu is required, where appropriate, to adhere to the requirem ents outlined within the
document.
The SVM/SEC/POL/0003 document is Fujitsu’s interpretation of the CISP document. This policy complies
with POL’s CISP; the Fujitsu Manage Inf ormation Security Policy and the Fujitsu Security Master Policy.
SVM/SEC/POL/0003 is reviewed annually and / or by request of the POL as a result of a major change.
Immediate issues will be dealt with through addendum _s. The policy is rev iewed against POL’s CISP,
regulatory standards and methodologies (10.1).
The ARC/SEC/ARC/0003 docum ent provides a technical standard to the architects and designer s to
assist them in implementing and maintaining the solutions they provide to POL. The ARC/SEC/ARC0003
is reviewed in line with the abov e SVM/SEC/POL/003; changes in the latter would result in changes
required in the former.
4.9.10.2 General System Security Settings
Each Operating System and Databases in use by Fujitsu to support both POLSAP and HNG-X (e.g.,
Windows, Red Hat Linux, Solaris, Oracle), has its own High Level Design (HLD) documentation in place.
This sets out the required settings and configuration specific to that Operating System (OS) or Database
(DB) at a high ‘requirem ent driven’ level. For ex ample, the document might specify that Red Hat Linux
servers are required to disallow remote shell access attempts (10.2).
A corresponding Low Level Design (LLD) document details the OS or DB specific configuration settings
needed to meet the requirements set out within the HLD document. These configuration settings are fully
documented at a granular lev el, for ex ample including ex tracts of OS / DB configuration code and
initialisation files (10.3).
Both the Operating System / Database HLD and LLD are subject tom andatory review and m ust be
approved by relev ant approval authorities docum ented within Dimensions. All new dev ice builds m ust
conform to specifications set out within the HLD and LLD. Dev iations again m ust be rev iewed, risk
assessed and approved by POL prior to configurations being implemented or updated.
New devices must be set up in line with the HLD f or the required OS / DB. If an HLD does not exist (for
example if a new server type is being im plemented), an HLD document must first be created, reviewed
and approved by the individuals defined in the Reviewers and Approvers Role Matrix. This document is
owned and managed by the Fujitsu Document Manager. This document is reviewed upon changes to in
key members of staff, i-e., major document owners, as well as on an annual basis.
Platform Physical Design (PPD) Document
Each infrastructure element is initially set up f rom an agreed baseline configuration. Elem ents of the
infrastructure (for example servers) are grouped by type — based on the role they perf orm within the IT
environment — this is defined within Platf orm Hardware Instance List which is m anaged and maintained
by Infrastructure Lead on the Post Office Account. An example of this is ‘ACD’, a server type for servers
providing directory services for support staff. Each server type has its own technical requirem ent, and a
PPD document is created by the Solution Architects detailing these requirem ents. The PPD sets out
exact hardware specifications, software requirements and configuration requirem ents for that particular
device type.
Description of Fujitsu's System 52
FUJ00237007
FUJ00237007
Fe)
FUJITSU
In short, the PPD sets out the ex act requirements that a serv er must cater for prior to it being set up.
Before a server is set up, the PPD m_ust be reviewed and approv ed by the indiv iduals defined in the
Reviewers and Approvers Role Matrix.
There is entry for each server instance within Platform Hardware Instance List stored within Dimensions
and this also includes a link to the PPD that was used to initially set up that serv er. Note that this is a
historic docum ent, and rem ains a record of the initial serv er configuration rather than necessarily
reflecting its current state.
Technical Interface Specification Document
As part of a project where a POL third party is inv olved, both POL and the third party agree a technical
interface specification that defines the connectiv __ ity between the third party and Fujitsu m anaged
infrastructure. This docum ent is held within Dimensions, once f ormally agreed by Fujitsu, POL and
relevant third parties. This is a historical docum ent that is updated upon changes in requirem ents of the
discussed interface. Changes will have to be agreed by Fujitsu, POL and relevant third parties.
Baseline Implementation
A combination of the aforementioned documents dictates the initial configuration of a server added to the
Fujitsu POL account infrastructure - this initial configuration is scoped out by the solution architects. It is
then the responsibility of the network architects to register application software and products to the
identified hardware. A baseline is then sourced and configured using the aforementioned documentation.
This configuration is uploaded into Dimensions. This step in turns creates a Package Virtual Baseline
(PVB) for the platform. The discussed platform is then set for “Ready for Build” within Dimensions.
The task is then handed ov er to the Integration Team . It is the responsibility of this team to convert the
discussed PVB into a Deploym ent Package Virtual Baseline (DPVB). This includes a num ber of
packaging exercises, as well as rigorous unit testing. Once a DPVB is established, serv er definitions are
outlined by the Integration team — essentially deciding which DVPB is applied to the differing technologies
within the platform.
In order to deliv er the DPVB into the Fujitsum anaged POL estate, the DPVB is handed to Release
Management who are responsible f or ensuring the outlined conf iguration is applied to the appropriate
technologies. They will form ulate the release note(s) f or application of the DPVB to both the test and
production environments - the team manages the ov erall release process f rom receipt of request f or
delivery of PSPID / DPVB to authorising deploym ent for all test rigs and live. The Release Management
team act as an escalation point area for the Test team for issues falling within the Release Mechanism.
Once the relevant MSC’s have been raised to issue the platform, the release note will be delivered to the
relevant Core Service Delivery Unit (Core SDU) — in this case either the Windows NT or UNIX teams. It is
the responsibility of the Core SDU to action the release note. They will apply the DPVB to the appropriate
technologies, initially to a test rig which will be handed over to the test team.
The test team will accept rig handover from Core SDU and begin their testing procedures — comprising of
composition of High Level Test Plans which will act as the base f or any Error Logging and Test Reports
that are produced once testing is com plete. The final sign off from the test team results in liaising with
Release Management and the Core SDU to agree deployment of fixes, top-ups or to schedule a rig
rebuild. They will also liaise with Customer Services and POL to agree deferments, if applicable.
Once testing sign off is received, the release note will then be passed back to the Core SDU will deliv er
the baseline via TPM to the relevant technologies.
Changes of Configuration to Existing Infrastructure
Once a device is set up, configured, and added to the Fujitsu infrastructure following the process detailed
above, its configuration remains static until the need for a configuration change is identified. The serv er
Description of Fujitsu's System 53
FUJ00237007
FUJ00237007
Fe)
FUJITSU
configuration is not by def ault updated when (for example) the relating OS HLD or LLD docum ents are
modified. Configuration changes made to in-service devices must follow change / incident m anagement
processes described elsewhere in this report (include obtaining approval from POL).
The exception to this rule is f or the application of standard OS / DB patches and security fix es, which
Fujitsu are (in many cases) contractually obliged to apply. Such patches do not bypass approval, as they
are reviewed by a Patch Approval Board (PAB) (attended by POL) prior to their application.
Changes to in-service infrastructure configurations can be identified in a number of ways, for example:
« Change Projects.
« New Application Development.
« Patch Application.
Infrastructure Refresh.
« Fix es identified through the Incident Managerent process.
Note that these changes follow the formal change and incident management processes.
Password Settings
Password configuration requirements are defined in the relevant baselines for infrastructure components.
If acom ponent cannot im plement the relev ant baseline this ex ception is notif ied to POL who m_ ust
authorise it. Passwords are stored in a one-way encrypted form and are protected against substitution or
dictionary attack.
Passwords shall conf orm to the f ollowing criteria (unless POL has approved a dev iation from these
criteria):
« W_ here passwords are used f or authentication, the user m_ ust be f orced to change the initial
password before any other access to the system is permitted.
« Passwords m_ ust expire in 30 days.
« Re-use of the sam _e password must not be permitted for either a specified time or until at least 4
other passwords have been used.
« Passwords m_ ust be a minim um of 7 characters long and m ust be alphanum eric (i.e., a mix of
letters and num bers). There must not be m ore than two consecutiv e identical characters. The
password must not be the same as the username.
« Af ter 3 consecutive unsuccessful attempts to log-on, the user m ust be locked out for at least 30
minutes or until reset by an administrator.
« In general, system users m ust be subject to the controls specified abov e. The f ollowing
exceptions are permitted.
« The username and password used to autom ate application login m ay be held in ‘clear’ i.e.,
readable format or unencrypted, if it is only accessible to authorised operational m anagement
Staff for that system and the potential damage from misuse of that username is minimised.
The password m ay expire less f requently than the 30 day s for human users where suitably obscure
passwords are used, e.g., strong passwords consisting of upper case, lower case characters, num bers.
and symbols and the risk of external access to such accounts is very low however this concession must
be documented and approved by the POL CISO.
Description of Fujitsu's System 54
Fe)
FUJITSU
FUJ00237007
FUJ00237007
4.9.10.3 User Administration
User Management / Administration
The principle of “least priv ilege” is used to restrict the access rights of
users whether hum an or non-
human. The User Access Process details how access is gained to both phy _ sical and technical asset s
within the PO Account and Fujitsu supporting f unctions and is m anaged by a POA Security Operations
Team (SOT).
New Joiners / Transfers
Detailed below are the steps that m ust be followed for an individual who is new to Fujitsu Serv ices and
joining the PO Account and these are shown in the Figure 1.0. Users who have transferred internally onto
the Post Office Account from another part of the Fujitsu business will f ollow a similar process, illustrated
in Figure 1.1 (10.4).
Figure 1.0 Diagram of User System Access Process Flow for New Joiners
Post Office New Joiners
rs
a
HR and Line
Manager notifed
‘Action to be agreed
Intiate Secunty
Clearance for ‘Compete form:
ee new ine via providing ALL relevant
2 Cafevi Information and return
2 Reauest System CSPOA for progressI
ES Acoess forms from
CSPOA Securty
‘Operations Team
t
Moving, Transfer, Amending Access
Figure 1.1 Diagram of User system access flow for Moving, Transferring, and Amending access __
‘
al
a
I este
coeee
& new joiner via [providing ALL relevant I
= at Information and return
2 se eon feestoR er roars
it CSPOA Security
ai
Description of Fujitsu's System
55
FUJ00237007
FUJ00237007
Fe)
FUJITSU
The Line Manager contacts POA SOT and requests that sy stem access forms are provided. The POA
SOT provides the New User Access Form s to the Line Manager and request s they are com pleted and
returned to the POA SOT both as a soft and hard copy. These forms are filed and stored in the security
operations secure room and kept for audit purposes.
POA SOT check the form is completed correctly, and in line with PO Account Security Policy. POA SOT
then notifies the relevant system owners (Windows NT Team, Unix Team, POLSAP Team) via an e-mail
containing the completed request form and a Triole for Service (TFS) call is raised and suspended whilst
access is granted.
Once System Owners configure the user they will update the TFS call on completion of this configuration.
POA SOT shall then close the TFS call and update the register.
Leavers
The steps that are followed for an individual leaving Fujitsu Services and the PO Account are shown in
the Figure 1.2 Diagram of User system access flow for Leavers (10.5).
The Line Manager contacts POA SOT by v_oice prompt and e-m ail, providing the leav er’s details and
requesting a revocation form. The POA SOT provides the revocation form and asks that it is com pleted
and returned to the POA SOT both as a soft and hard copy. These f —_orms are filed and stored in the
security operations secure roomand kept for audit purposes.
POA SOT check the form is completed correctly, and in line with PO Account Security Policy. POA SOT
notify the relev ant system owners (Windows NT Team, Unix Team, POLSAP Team ) via an e-m ail
containing the com pleted rem oval f orm and a TFS call is raised and suspended whilst access i s
removed.
Once System Owners remove the user they will update the TFS call on com pletion of this configuration.
POA SOT shall then close the TFS call and update the register.
Figure 1.2 Diagram of User system access flow for Leavers
Post Office Leavers Process — Leavers with immediate effect — Follow red steps
IGeneral Leavers Process
[Cexpoie eon Prova]
Line Manager
CSPOA
HR
4.9.10.4 Information Security Monthly Forum
The Information Security Monthly Forum (ISMF) is af ormalised monthly forum where Post Office and
Fujitsu Security production risk and control concerns / issues ar e raised and progressed with the
necessary stakeholders. The purpose of the meeting is to:
* To help ensure the early identification of issues together with tim ely & effective resolution by
those attendees with functional responsibility.
Description of Fujitsu's System 56
FUJ00237007
FUJ00237007
Fe)
FUJITSU
« Rev_iew Security Operations monthly reporting on common security control objectives e.g., Patch
& Vulnerability Managem ent; Anti-virus / Malware; Configuration Managem ent of Security
Infrastructure etc as agreed between Fujitsu and Post Office.
The Security Operations monthly reporting pack will be compiled and circulated one week in adv ance of
the forum by Fujitsu. This pack will include:
« Agendaf or current forum.
« Minutes f rom previous forum and progress against previous actions.
« Open or new Security Risks and Issues.
* Changes to Information Security Architecture relating to joint venture products.
« Upcoming developments.
* Active Directory User Access Review (10.6).
4.9.10.5 User Authentication technologies
User authentication is two-factor, including dynamic password authentication (known as an iKey) against
an external database - TACACS+, RADIUS or similar technology for access (10.7). Once authenticated,
remote access connections are established v ia a VPN using an encrypted session. Authorised user s
should not provide their login token (iKey token) or associated information to anyone at any time for any
reason, other than to surrender it when no longer required or when their relationship with Fujitsu has
ceased as an employee.
The ex ception to this would be if they needed to hav e their account or token reset or a tem porary
passcode allocated. If this was the case then this inform ation could be giv en to an authorised person
(ie., member of the Security Operations team) to validate the user.
iKey access is granted to those users who support the HNG-X platform / application. Users must connect
to SSN Terminal Servers in order to access to HNG-X platforms within data centres. As such, all HNG-X
SSN Servers must be a m ember of the Windows AD (MSAD Domain). Remote users must be granted
the Allow log on through Terminal Services right, or be a member of Remote Desktop Users group.
11. Control Objective 11: Controls provide reasonable assurance that access to databases, data
files and programs is restricted to properly authorised individuals.
# Control
11.1 Patch Management: In-scope platforms are maintained with vendor released security updates
and patches in line with agreed procedures and timescales.
11.2 System Administrators: Access to perf orm system adm inistrator functions restricted to
appropriate Fujitsu personnel required to have this level of access by their role.
11.3 Database Administrators: Access to adm inister POL databases is restricted to appropriate
Fujitsu personnel required to have this level of access by their role.
11.4 Administration Tools and System Utilities: Access to administration tools and system utilities
on Post Office Limited infrastructure is restricted to appropriate Fujitsu per sonnel required to
have this level of access by their role.
11.5 Unauthorized changes are monitored: The TripWire system is configured to monitor and alert
on changes made to in-scope applications and underlying data.
11.6 Access to Data Files / Programs Access is restricted to production program and data files
through the use of user groups to restrict and allow access.
Description of Fujitsu's System 57
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Patch management
Fujitsu’s POA Operational Security Team (POA SOT) and the Serv _ice Deliv ery teams subscribe to
relevant v endor inf ormation f eeds to receiv e details of patches f rom v endors that prov ide critical
operating systems, applications, databases and network equipment to POL Ltd.
Details of patches are reviewed and docum ented in the Patch Deploym —_ ent Spreadsheet. This
spreadsheet will be held within Dimensions document management system.
The Deployment Spreadsheet is rev iewed by the SDUs and Application Support teams on a regular
basis; they assess whether the patch applies to equipm —_ ent they m anage. They will then update the
spreadsheet with the reasoning behind their decision to apply or not to apply a patch in readiness f — or
submission to the Path Approval Board (PAB (11.1)).
The PAB consists of members of the Inf rastructure Services division, Applications Solutions Team ,
Operational Security Team and a POL Security representative. The PAB is held on a monthly basis. The
PAB will review the Patch Deployment Spreadsheet and seek agreement on the patch set to be deployed
and in what timescale (e.g., deploys patches as an emergency fix or include at next release).
System Administrators & Database Administrators
The user management database utilised by the POA SOT holds details of all the support teams and the
system access the team resources have (11.2 and 11.3). This document is monitored on a regular basis
to prov ide assurances against contractual requirem ents and obligations against the Unit's Roles
Responsibilities and Access Requirements.
Access and resources in the teams are reviewed and confirmed as appropriate on a monthly basis by the
line managers (11.4 and 11.6). The POA SOT then com pletes the monthly access report for privileged
users and presents at the monthly ISMF with POL.
Throughout the POL infrastructure the same authoritative source of authentication and authorisation data
is used to manage access control for all operational support users. The purpose ofthis approach is to:
1) Reduce the num ber of passwords required for support purposes.
2) Help ensure better audit and logging f acilities for authentication and authorisation.
3) Stream line the process f or adding, changing and removing authentication and authorisation
information.
4) Prov ide a standard method of authentication and authorisation throughout the estate.
Database access control also requires indiv idual role-based accounts f or each class of user, both f or
controlling the actions a user can perform and for helping to ensure administrative and other actions are
traceable to an individual to provide a valid and informative audit trail.
The main classes of database users will be:
1) Application - Accounts used by applications for database access to either Oracle or SQL Server
Databases.
2) System Administrators - Operational support users with responsibility for managing the database
systems.
3) Database Adm inistrators — Operational support users with responsibility for specific databases.
4) Non-adm inistrative Database support user s - Operational support users with responsibility f or
specific databases.
Description of Fujitsu's System 58
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Unauthorised changes are monitored & reviewed
Tripwire compares files and directories against a baseline database of file locations, dates modified, and
other data. It generates the baseline by taking a snapshot of _ specified files and directories in a known
secure state. After creating the baseline database, Tripwire compares the current system to the baseline
and reports m odifications, additions or deletions ( 11.5). Tripwire helps to ensure the integrity of critical
system files POA SOT who monitor the console.
On a monthly basis, the POA SOT rev iews alerts that hav e been raised from Tripwire. Monthly reports
are produced detailing alert statuses and a root cause analysis f or each alert. The reviews are available
for POL management, in order to m onitor unauthorised attempts to modify datasets. The Tripwire alert
report is included in the ISMF Security Operational Reports. In cases where no alerts are raised within
the month, a report may not be produced and this will be noted within the nex month's report.
12. Control Objective 12: Controls provide reasonable assurance that networks and system
resources are protected from external threats and access violations are detected, reported
and investigated.
# Control
64 Major & Security Incident review: Once a Major or Security Incident is resolv ed there is a
formal closure of the incident and a review including, if applicable a Root Cause Analysis.
12.1 Configuration Access: Access to set-up and conf igure firewalls is restricted to appropriate
Fujitsu personnel required to have this level of access by their role.
12.2 Configuration Changes: Changes to firewall configuration are managed using the standard
Fujitsu MSC process including authorisation, testing (where deemed appropriate) and approval
of changes before they are implemented.
12.3 Anti-virus software: Anti-virus software is installed on critical networked Windows and Red Hat
Linux platforms as agreed with POL. Installed anti-virus software is up to date in line with agreed
contractual requirements.
Overall network security design
Within each Data Centre, the POL network is segm__ ented following the Security Dom ain model. The
Security Domain model provides a framework for the network architecture and designs, such that the flow
of data around the network is controlled f ollowing the principle of least priv _ilege. The applied
segmentation is furthered developed within the Network Architecture document and Network High Level
and Low Level Design documents — stating the specific details that have been configured on the network.
The purpose of network segm entation is to reduce the scope of a potential attack. By restricting the
‘attack surface’ to a limited num ber of systems, damage caused as a consequence of an attack, can be
kept to a minimum.
The network segmentation is achiev ed using a com bination of physical and virtual controls. Dependent
on the Security Domain and specific contractual agreements with third parties, the network segmentation
is enforced using VLANs, IP’s and Statef ul Inspection Firewalls, ACLs, AES Encryption and physical
separation.
Network segm entation will also be used to prov _ide separation between environments. Each Test
environment will be separated f rom other test environments, as well as f rom the live environment. This
will be enforced through the use of Firewall and Router access control lists, VLAN restrictions and user
and network access control. These controls will be monitored using the ev ent management system to
verify that access control lists and conf iguration settings are not changed in a way thatm ay allowa
network path from one environment to another except under strictly controlled conditions.
Description of Fujitsu's System 59
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Firewalls
Direct access between the internet and systems or system components in areas of the network that have
been classified as “sensitive” is prohibited and all traffic is routed through a DMZ - a logical subnetwork
that contains and exposes a Fujitsu’s external-facing services to the internet. Firewalls are configured to
perform stateful inspection in that only established connections are pernitted to connect to the network.
Perimeter firewalls and router com ponents are conf igured to m asquerade internal addresses to the
internet using NAT technologies.
Access to set-up and conf igure firewalls is restricted to appropriate Fujitsu personnel required to hav e
this lev el of access by their role (12.1). MSC is used to raise rule set changes f or the firewall
configurations (12.2). Upon operational change process inv ocation an appropriate deployment plan is
uploaded to the file store within the MSC system which is subjected to peer rev iew prior to deployment,
this plan is also used to facilitate change regression if appropriate.
Should any protocols that have been deemed as insecure be required to be included in the configuration
then additional inf ormation m ust be supplied that details the security f eatures that hav e been
implemented.
Rule Set Review Process
In order to verify the current configuration of network security enforcement devices that manage the POL
estate, all configurations are manually inspected at least every 6 months.
Authorized firewall configuration elem ents in relation to network security enf orcement are in docum ent
reference SVM/SEC/STD/1985 stored securely in Dimensions. This docum ent is compared against the
appropriate device’s active configuration helping to ensure these are in line with the standards in the
document. SVM/SEC/STD/1985 is updated when operational configurations are changed through the
completion of MSCs. As such SVM/SEC/STD/1985 ref _lects the secure elem ents of appropriate
operational devices at all times.
If discrepancies are f ound between SVM/SEC/STD/1985 and the oper ational configuration these are
investigated to help ensure the environment has not been com promised and ascertain why correct
process was not followed in relation to inconsistencies.
The review page of SVM/SEC/STD/1985 is updated ev ery 6 months with the new version and contains
the date carried out, nam e and reason f or rev iew. This docum ent is stored in a secure area in
Dimensions.
Anti-Virus Software
The ESET Anti-virus product has been im planted during the period under rev iew, replacing the existing
Sophos product (12.3). ESET runs in real-time and performs automatic, scheduled and manual scans on
all managed clients, in order to identify and contain and eliminate the spread ofmalicious code.
For the in-scope Wintel systems, real-time file system protection is implemented. All files are scanned for
malicious code at the moment they are opened, created or run on the computer.
For the in-scope Linux systems (DXC, DGI and DGE), an on dem and daemon has been created using
the ESET SDK that can scan files as they are transferred through the respective platforms. ESET is not
installed on all Linux systems, by agreement with POL.
In cases where a specific v ulnerability or virus stream constitutes a high risk threat to the system s, a
scheduled scan is setup from the management console and the client configuration updated accordingly.
Description of Fujitsu's System 60
FUJ00237007
FUJ00237007
Fe)
FUJITSU
ESET prov ides regular updates of both signatures and engines. For engine updates, these are
distributed to clients using the existing Tivoli software distribution management system after having been
verified and tested in the test environment to help ensure that no system functionality is compromised by
the updated.
The ESET AV System_ is based on a central Managem _ ent Serv er (ERAS) where all the updates
(signatures) are stored andm_ anaged. ERAS receiv es the updates f rom ESET, v ia an Internet
connection, and makes them available for clients to install.
Whenever a v irus, vulnerability or suspicious ev ent is detected, the ESET Antiv irus system will react
according to a configuration that will be enabled using ESET antivrus policies.
The workflow describing the process bllowed is as follows:
1. Windows
a. On access (read, copy, ex ecute, etc) every item will be scanned by the AV system.
2. Linux
a. On Dem and scanning is performed by the ESET Scanner Daemon.
3. If a threat is identified, the AV system will try to autom atically clean the item. If the cleaning is
successful, an alert ev ent is logged in the ESET Notification m anager - which has the ability to
take actions when configurable alerts are identified within the ESET env ironment. This
functionality provides an integration point between E SET and the Tiv oli Netcool ev ent system.
The ESET Notification Manager is monitored proactively by the POA SOT.
4. If the cleaning is not successf ul, an alert event is logged and an incident is raised in TBSM, with
alerts going through to SMC start a rem ediation action (refer to Control 6 f or further information
around the incident process):
a. If development is needed to solve the issue, a PEAK is raised.
b. A fix is produced and assessed according to normal procedure:
i. If the fix is rejected, a risk is raised on the Risk register.
ii. If the fix is approved, the fix is deployed on Test and Live environment.
The following is a diagram of the workflow to be applied. Tiv oli and KELS are integrated with ESET in
order to automate the alerting process in the event of a High/Critical virus being identified by ESET, and
start the appropriate remediation activities.
Description of Fujitsu's System 61
FUJ00237007
FUJ00237007
Fe)
FUJITSU
Possible raise
PEAK if
development
is required
/ \
/ \
Alett to
Tivoli 4
and
Scan—BI Virus. I—Yes— 8} raise call -——]
via TFS
and
raise
Incident
Assess
fix
Deploy
[—DeployI
Reject fix
Raise Risk on
Risk Register
13. Control Objective 13: Controls exist to provide reasonable assurance that remote accessi s
appropriately restricted to authorised personnel.
# Control
10.4 User (Fujitsu) Set-up and Amendment: Fujitsu users requiring new or modified access to Post
Office Limited system s are set up appropriately, and approv ed by an appropriate Fujitsu line
manager.
10.7 Two-Factor Authentication: Access to Post Office Limited system _s f or Fujitsu users is
controlled using two-factor authentication.
13.1 Remote Access Authorisation: The use of Radius Authentication and CHAP (Challenge
Handshake Authentication Protocol) f or Counters accessing the Data centres ensures that
access is restricted to approved devices.
As noted above, remote access for individual users is managed through issuing iKey tokens.
CHAP is used to authenticate the Post Office counters at the Outlets when they connect to the data
centre. Each counter is authenticated using a dedicated RADIUS serv _ er instance f or network dev ice
access, with different CHAP credentials per Branch Router (13.1).
Counters and external devices accessing the data centre can only do so via an ADSL connection utilising
the CHAP (Challenge Handshake Authentication) Protocol. CHAP requires that both connecting parties
(the data centre and the counter) know the plaintex t of a secret string of text (the CHAP secret). During
the ‘handshaking’ phase, (which must take place prior to any other data being communicated), the data
centre ‘challenges’ the counter with a unique calculated value, and expects a particular response.
Description of Fujitsu's System 62
FUJ00237007
FUJ00237007
Fe)
FUJITSU
This expected response must be generated by the counter using both the CHAP secret, AND the dat a
centre challenge value, helping to ensure that:
« The counter is the sam _e device that sent the initial connection request.
« The counter is an authorised dev _ ice, as only authorised dev ices have knowledge of the CHAP
secret.
Note that the CHAP secret is:
« Nev er shared across the network as part of the handshaking process.
« Securely stored, always in obfuscated or encrypted form.
« 11 characters long and com plex.
« Changed at least ev ery two years.
If the counter returns an unexpected value, the connection is immediately terminated. For added security,
the handshaking process is repeated at set time intervals, requiring the counter to re-authenticate with the
data centre regularly. The CHAP secret is not known by or accessible to user s, as it is automatically and
randomly generated offline, and encrypted prior to being supplied to serv ers such as the ACDB that act
as ‘distributors’ of the secret.
RADIUS (remote authentication dial in user serv ice) provides an additional layer of security, through a
centralised Authentication, Authorisation, and Accounting management system. A RADIUS server within
the network keeps track of devices approved to connect to the data centre, along with their credentials.
These are stored in a secure em bedded database. Connection attem pt credentials are com pared to the
RADIUS server, which allows or denies access to the data centre based on whether the connecting
device is listed as approved within the database.
Description of Fujitsu's System 63
FUJ00237007
FUJ00237007
FUJITSU ES
5. Not used
Description of Fujitsu's System 64
FUJ00237007
FUJ00237007
Fe)
FUJITSU
6. Complementary User Entit y Controls
In designing its sy stem, Fujitsu has contem plated that certain com plementary controls would be
implemented by POL to achiev e certain control objectiv es included in this report. The com plementary
user entity controls are as follows:
« Organisation and Administration
Controls should be established to:
o Ev aluate that contracted processes and controls have been implemented
o Ev aluate and m onitor Fujitsu's deliv ery of services for conf ormance with contractual
obligations
o Designate their own internal client representative to determine adequate maintenance of
controls over Fujitsu services
o lm plement and m onitor proper segregation of duties ex ist at POL owned/m anaged
facilities
« Physical Access
Controls should be established to:
o Appropriately restrict access to terminals, workstations, and other com _ puting equipment
at POL sites, which can also allow access to infastructure located in Fujitsu data centres
o Request and approve employee access to computer rooms in a fashion that limits access
to only those employees requiring it based on job function
« Computer Operations
Controls should be established to:
o Approv e additions, modifications or deletions to scheduled jobs ifnecessary.
o Inf orm Fujitsu of critical scheduled jobs and the appr opriate escalation procedures are
associated to those jobs
o Define SLAs f or availability, capacity and perf ormance management in the agreem ent
with Fujitsu
o Rev _ iew and take action on reports on av ailability, capacity and performance
management, supplied by Fujitsu, where required
o Data Retention requirem ents are documented and agreed with Fujitsu
o Periodically, request restores f rom backup to validate that programs, files and data ar e
recoverable
« Networks
Controls should be established to:
o Rev _ iew network performance statistics (e.g., response time, availability) periodically and
that the service levels received are in compliance with the service levels specified in their
contracts
o Com pare metrics in network av ailability and performance reports to user ex perience to
determine whether availability and performance statistics are accurate
« Change Control
Controls should be established to:
o Ensure that application changes f ollow a formal change process and are approved
o Ensure that requests f or Fujitsu to implement changes to systems come from authorised
individuals
o Ensure that a POL representativ e participates in, or has input to, the sy stem
development activ ities that are relev ant to POL, including participation in testing
activities, if applicable
Description of Fujitsu's System 65
FUJ00237007
FUJ00237007
Fe)
FUJITSU
o Ensure that POL individuals who are perm itted to authorise f irewall changes hav e an
understanding of the impact the change could have and carry out a risk assessment prior
to authorising a change
« Logical Access
Controls should be established to:
o Establish and im plement procedures and docum entation for authorising user access to
terminals and application functions
o Periodically, rev iew access granted to users at the application layer, to confirm that such
access remains appropriate based on users’ job functions
o Establish and im plement procedures to ensure additions, changes, and deletions in client
organisations’ per sonnel and their associated job responsibilities are authorised and
communicated to Fujitsu in a tim ely manner (if applicable). Where it is the responsibility
of POL to remove users, POL should implement procedures to review that all leavers are
removed in a timely manner
o W here Fujitsu is asked to implement compensating controls to address situations where
infrastructure cannot be configured to meet agreed baselines (e.g. additional m onitoring
controls), ensure they are comfortable that such controls are being operated whether it
be by Fujitsu or POL’s employees or contractors
o Establish and im plement procedures to prohibit the use of shared user IDs or user IDs
whose passwords are not changed on a regular basis
o Adv ise POL employees regularly of the im portance of security and to report suspicious
personnel, transactions or activity to management
o Establish and im plement procedures to review operating system configurations to ensure
settings are prov iding adequate security, particularly where security param eters are
maintained at the original client settings when trans€rred to Fujitsu
« Applications Development
Controls should be established to:
o Docum ent, review and sign off user requirements by the business, prior to commencing a
change
o Ensure that requests for Fujitsu to im plement changes to POL system s come from
authorised individuals
o Ensure that when where POL or its other suppliers administer POL inf rastructure, the
applications developers have appropriate access
o Rev _ iew reporting received from Steria about the use of the SCC4 transaction to unlock
the SAP production env ironment and to check that these are part of changes that POL
has authorised
The list of client control considerations presented above is not a comprehensive list of all internal controls
that should be applied by POL. Other internal controls may be needed at POL.
Description of Fujitsu's System 66
FUJ00237007
FUJ00237007
Fe)
FUJITSU
7. Description of Control Objectives, Controls, Tests
and Results of Tests
7.1 Testing Performed and Results of Tests of Entity-Level
Control
In planning the nature, timing and extent of our testing of the controls specified by Fujitsu, we considered
the aspects of Fujitsu’s control environment, risk assessment processes, information and communication
and management monitoring procedures and performed such procedures as we considered necessary in
the circumstances.
7.2 Control Objectives, Control Activities, Testing
Procedures and Results of Testing
On the pages that follow, the description of control objectives and the controls to achieve the objectives
have been specified by, and are the responsibility of, Fujitsu. The testing performed by Ernst & Young
and the results of tests are the responsibility ofthe service auditor.
The service auditor's examination was limited to the IT general controls relev ant to Fujitsu’s operations
supporting IT services provided to POL to support the POLSAP and HNG-X applications. Accordingly,
the service auditor ex presses no opinion on the operating effectiv eness of any aspects of application
processing and application controls, individually or in the aggregate. POL m ay need to gain inf ormation
about application processing and application controls through other means.
Description of Tests and Results 67
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.1 Control Objective 1
( Controls Specified by Fujitst
_ Testing Performed by Ernst & Young LLP
_ Results of Tests ve
Conca Objective 1: Controls prov ide ees assurance that access to data centres and f
documentation is restricted to properly authorised individuals.
acilities ‘with com a alet equipniact storage m edia and program
1.1 Data Centre Access
Data centre specific physical access security
policies and procedures to control access to the
data centre and other sensitiv e areas, including
computer equipm ent and storage m_edia, are
implemented. These are m__ ade av ailable to
Fujitsu staff via the intranet.
Through discussion with m anagemernt, identified the
documents that def ine the data centre specific physical
access security policies and procedures f or the in scope
data centre. Observ ed that these docum ents existed and
were held on the Fujitsu intranet.
Determined whether these were av
Fujitsu employees.
ailable to relevant
No deviations noted.
1.2 Access Within the Data Centre
Access beyond the security desk is protected by
a key-card sy stem that restricts indiv _idual
access to specific data processing areas.
Security m anagement has determined
appropriate levels of physical access to the data
centre, which is based on the roles and
responsibilities of staff. Staff requiring access to
the data centre m ust complete an access f orm,
which must be signed as approv ed by the line
manager responsible for the zones requested.
Observed the com puter rooms and determined whether
access door s are equipped with a card key lock or
equivalent to restrict access to sensitive areas.
Selected a sam ple of Fujitsu new starters to the site and
determined that the access granted has been authorised in
accordance with the defined procedure.
No deviations noted.
1.3 CCTV
The data centre(s) is controlled and m_ onitored
through the use of CCTV video cameras. Video
cameras are placed at strategic locations around
the perimeter of the building to help ensure that
coverage of the data centre is obtained.
Observed that CCTV v ideo cam eras are placed at key
locations around each data centre to m onitor activ ity.
Observed that these screens are monitored by security
staff at the data centre.
No deviations noted.
Description of Tests and Results 68
oO
FUJITSU
FUJ00237007
FUJ00237007
Controls Specified by Fujitsu
Control Objective 1: Controls prov ide reasonable assurance that access to datacentres andf _acilities with com puter equipment, storage m edia and program
documentation is restricted to properly authorised individuals.
1.4 Security Guards
Security guards are present at the data centres
24 hours per day, sev en days per week. The
data centre can only be accessed through a
central area.
Through discussion with management and observ ation,
determined that security guards (or equiv _ alent) are in
place at the data centres (24 hours a day and sev en days
per a week) and that each data centre can only be
accessed through a central point (front desk), which has
security guards (or equivalent) in place.
No deviations noted.
1.5 Data Centre Visitors
Visitors are required to sign in at the reception
areas and tem porary badges are issued.
Visitors m ust hav e been pre-notified to data
centre security by a Fujitsu employee.
Observed that v isitors are granted access based on the
pre-approval and that they are required to sign in at the
reception area and temporary badges are issued.
No deviations noted.
1.6 Failed Access Monitoring
Attempts to enter restricted areas without using
authentication devices are denied and a security
alert is triggered and logged. Data centre
management proactively follows up on security
alerts that are triggered.
Inspected a sam ple of the m onthly security alert logs
reviews perf ormed by Fujitsu and determined whether
these were reviewed and followed up
No deviations noted.
1.7 Rev iew of User Access within the Data
Centre
Periodic rev iews are perf ormed of users who
have access to the data centre to help ensure
that their access rights are appropriate.
Obtained a sam ple of periodic rev iews of access lev els
and determ ined whether assigned access lev els remain
appropriate based on job responsibilities and appropriate
actions had been taken as necessary.
No deviations noted.
Description of Tests and Results 69
oO
FUJITSU
FUJ00237007
FUJ00237007
Fujitsu
Control Objective 1: Controls prov ide reasonable assurance that access to data centres and f
documentation is restricted to properly authorised individuals.
acilities with com puter equipment, storage m edia and program
1.8 Deletion of User Access
The managers of the various delivery teams are
responsible for notifying the local site facilities
team of terminations or transf ers of their direct
reports. Upon notification of em ployment
changes, access through the security access
control system is revoked.
Identified a Fujitsu em ployee who was term inated during
the period under review and determ ined whether their
access to the data centre had been rev oked in the access
control system.
No deviations noted.
Description of Tests and Results 70
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.2 Control Objective 2
Controls Specified by Fujitsu
Testing Performed by Ernst & Young LLP
Control Objective 2: Controls provide reasonable as:
hazards and maintenance agreements are in place.
surance that computer equipment and facilities are protected from damage by fire, flood and other environmental
2.1 Fire Suppression
Fire detection and suppression devices, such as
hand-held fire extinguishers, are strategically
placed throughout the entire data centre.
Observed the existence of fire detection and suppression
devices (e.g., gaseous fire suppression devices, hand-held
fire extinguishers, sm oke detectors and m onitoring
devices, dry pipe sprinklers and t wo-hour firewall) at each
data centre.
No deviations noted.
2.2 Maintenance Schedule
Periodic inspection and m aintenance is
performed on protection dev ices, sensors and
alarm systems.
Enquired about the monitoring and inspection controls
used to protect com puter equipment from environmental
hazard.
Inspected the m aintenance schedules (including backup
generators, UPS, fire detection and suppression & heating,
ventilation and air-conditioning) and serv ice reports for a
range of dev ices supporting environmental m onitoring
controls in each data centre and determined whether
equipment had been maintained during the period.
No deviations noted.
2.3 Environmental Monitoring
Smoke detectors and water, hum idity and
temperature monitoring devices are installed to
detect abnormal environmental conditions.
Observed that sm oke detectors and water, humidity and
temperature m onitoring dev ices hav e been installed to
detect abnorm al env ironmental conditions at each data
centre.
No deviations noted.
2.4 UPS Supply
A UPS system is installed to protect the facilities
and com puter equipm ent from electrical power
fluctuations and outages.
Observed that a UPS system had been installed to protect
the facilities and computer equipment from electrical power
fluctuations and outages at each data centre.
No deviations noted.
Description of Tests and Results 71
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.3 Control Objective 3
Controls Specified by Fujitsu
WEEE
~ Results of Tests
Control Objective 3: Controls provide reasonable assurance that programs, files and datasets that hav e been identified as requiring periodic backup are backed up
and retained.
3.1 Backup Definition
The Backup High Lev el Design docum_ ents
define Backup and recov ery requirements and
policy for the platform.
Selected a sam ple of platforms and determined whether
the Backup High Lev el Design docum ents f or these
platforms defined backup and recov ery requirements and
policy for the platforms.
No deviations noted.
3.2 Backup Toolset
Backups are perf ormed using Netbackup or
RMAN (automated tools).
Selected a sam ple of platforms and determined whether
NetBackup or RMAN were installed to perform back-ups.
No deviations noted.
3.3 Backups are W
Location
Backups perf ormed are written to a separate
disk array and are simultaneously written to a
disk array at the disaster recovery site.
ritten to a Secondary
Selected a sam ple of serv ers and determined whether
backups performed are written to a separate disk array
and are sim ultaneously written to a disk array at the
disaster recovery site.
No deviations noted.
3.4 Failed Backups are Tracked and Monitored
Failed backups are signalled to the Master
Batch Scheduling system which raises events in
a generic manner to the SMC.
Selected a sam ple of failed backups and determ ined
whether these had been signalled to the Master Batch
Scheduling system which had then raised ev ents in the
SMC.
No deviations noted.
Description of Tests and Results 72
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.4 Control Objective 4
Testing I Performed by Ernst & Young LLP ‘
Control Objective 4: Controls provide reasonable asst
are identified and resolved.
urance that processing is appropriately authorised and scheduled and that aerator: from ecrediied processing
4.1 Maintenance of Job Schedules
Access to amend job schedules is restricted to
appropriate Fujitsu personnel required to hav e
this level of access by their role.
Obtained listings of access rights within the tools used to
maintain HNG-X and POLSAP job schedules and
determined who had access to am ___ end job schedules.
Assessed whether this access is restricted to appropriate
Fujitsu personnel required to hav e this level of access by
their role.
No deviations noted.
4.2 SAP Schedules are Continuously Monitored
The SAP Basis Team uses the SAP GUI and
SAP transaction code SM37 tom _ onitor the
success / failure of SAP batch jobs. The SAP
Basis team will also check and monitor the batch
job start and end tim es and send the daily
monitoring statistics to agreed parties.
Observed the SAP Basis team monitoring SAP schedules.
No deviations noted.
4.3 Failed Job Schedules are Monitored and
Alerted
Automated alerts are configured and sent to
relevant parties upon the occurrence of a batch
job failure. These are inv estigated in line with
the incident management process.
Reviewed the TWS tool, which manages all batch jobs for
in scope applications, and determined that it is conf igured
to raise an alert if a batch job f ails and to then pass this
alert to the Tivoli ITM tool.
See control 6.6 for testing of alert handling.
No deviations noted.
Description of Tests and Results 73
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.5 Control Objective 5
Controls Specified by Fujitsu si
Testing Performed by Ernst & Young LLP
Control Objective: 5 Controls provide reasonable as:
are captured and investigated.
surance that system availability, performance and capacity are
routinely monitored to ensure that potential issues
5.1 SAP Performance Monitoring
The SAP Basis team regularly m onitors table
space and databases to help ensure there is
sufficient system av ailability and capacity and
that potential issues are captured and
investigated.
Observed the SAP Basis team monitoring SAP table space
and databases.
No deviations noted.
5.2 SAP Capacity Alerting
An autom ated alert will be generated in the
Solution Manager System (PLM) if the table
space is m ore than 95% filled and the SAP
Basis team will monitor and review these alerts.
Identified a SAP server that exceeded the defined alerting
parameters and determined whether the ex pected alerts
had been generated and sent to the SAP Basis team.
No deviations noted.
5.3 SAP Availability Alerting
Automated alerts are configured in Solution
Manager to adv ise if apart of the system is
shutdown / not available for users. These alerts
go to SMC team and they will create an incident.
Determined whether autom ated alerts are conf igured in
Solution Manager to adv ise if partof the system is
shutdown / not av ailable for users. Followed through an
alert and determined if this was sent to the SMC team who
then created an incident if appropriate.
No deviations noted.
5.4 HNG-X Performance Monitoring
The Tiv oli ITM proactively m onitors CPU,
Memory, Disk utilisation and capacity of internal
services on these platf orms, raising alerts f or
investigation by the SMC as appropriate.
Determined whether the Tiv oli ITM tool was im plemented
on the HNG-X platf orms and whether it is configured to
look at the CPU, Mem ory, Disk utilisation and capacity of
internal services on these platforms.
Selected an alert from the Tivoli ITM tool and determined if
this went to the SMC for review.
No deviations noted.
Description of Tests and Results 74
oO
FUJITSU
FUJ00237007
FUJ00237007
Controls I Specified by Fujitsu
Testing Performed by I Ernst. & Young LLP —
_ Results of Tests —
are captured and investigated.
Control Obieiva: 5 Controls provide reasonable assurance that system availability, performance and capacity are routinely monitored to ensure that potential issues
5.5 HNG-X Capacity and Availability Monitoring
The Tiv oli ITM tool proactively m onitors the
availability of Wintel and Unix platforms, feeding
platform av ailability data to Tiv _ oli Business
Service Manager (v ia Netcool Om nibus) about
the av ailability of platf orms. Tiv oli Business
Service Manager presents this data ina
business contex t to the SMC, highlighting
service affecting issues.
Obtained ev idence of Tiv oli ITM conf
determined whether:
¢ These showed that the Tiv oli ITM tool m
availability and capacity of servers.
* Thresholds were def ined which, if breached, would
send alerts as described.
¢ See control 6.6 f or testing of alert handling.
igurations and
onitors
No deviations noted.
5.6 Monitoring of Service Delivery
A monthly Service Review Book is prov ided to
POL to review its agreed Service Levels. Within
this book are details of capacity, availability and
incident management performance.
Selected a sample of months and determined whether the:
Monthly Service Review Book is provided to POL to review
its agreed Service Levels.
Monthly Service Review Book contains details of capacity,
availability and incident management performance.
No deviations noted.
Description of Tests and Results 75
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.6 Control Objective 6
Controls Specified by Fujitsu
"Testing Performed by Ernst & Young LLP
_ Results of Tests _
Control Objective 6: Controls provide reasonable assurance that significant operations incidents are adequately reported, tracked, monitored through resolution and
resolved timely.
6.1 Incident Policies and Procedures are in
Place
Fujitsu has documented policies and procedures
for managing incidents im pacting the in scope
applications which are av ailable via CafeVik to
Fujitsu teams.
Through discussion with m anagement, identified the
documents that def ine the incident m anagement for the
POL account.
Determined whether these were av
Fujitsu employees.
ailable to relevant
No deviations noted.
6.2 Incident Prioritisation
Incidents are assigned a priority in accordance
with the severity levels agreed with POL.
Selected a sam ple of incidents and determined whether
these had been assigned a priority in accordance with the
severity levels agreed with POL.
No deviations noted.
6.3 Incident Resolution
Incidents are handled in a timely manner, as per
priority.
Selected a sam ple of incidents and determined whether
these had been handled in a timely manner, as per priority.
No deviations noted.
6.4 Major & Security Incident Review
Once a Major or Security Incident is resolv ed
there is a f ormal closure of the incident and a
review including, if applicable, a Root Cause
Analysis.
Selected a sam ple of Major and Security Incidents and
determined whether a Formal Closure of the Major Incident
took place and a review of the Incident, including, if
applicable, a Root Cause Analysis.
No deviations noted.
6.5 Incident Reporting
On a daily basis, the Fujitsu HSD / IMT rev iews
the number and severity of outstanding incidents
in TFS.
Discussed with m anagement that the Fujitsu HSD / IMT
had rev iewed the num ber and sev erity of outstanding
incidents in TFS.
No deviations noted.
Description of Tests and Results 76
oO
FUJITSU
FUJ00237007
FUJ00237007
ng Performed by Ei
Control Objective 6: Controls provide reasonable assurance that significant operations incidents are adequately reported, tracked, monitored through resolution and
resolved timely.
6.6 Alert Handling
The Tivoli ITM and Netcool Om nibus automate
the collection of ev ents and using Tiv __ oli
Business Serv ice Manager highlight areas of
concern to the SMC.
Selected a sample of events and determined whether the
Tivoli ITM and Netcool Om _ nibus tools autom ated the
collection of ev ents and used Tiv oli Business Serv ice
Manager to highlight areas of concern to the SMC.
No deviations noted.
Description of Tests and Results 77
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.7 Control Objective 7
Controls Specified by Fujitsu
I Testing Performed by Ernst & Young LLP
_ Results of Tests _
Control Objective: 7 Controls prov ide reasonable assurances that networks are m_ anaged to contractual and site requirem ents, monitored for availability and
response times and issues are identified, tracked and resolved.
5.6 Monitoring of Service Delivery
A monthly Service Review Book is prov ided to
POL to review its agreed Service Levels. Within
this book are details of capacity, availability and
incident management performance.
Selected a sample of months and determined whether the:
Monthly Service Review Book is provided to POL to review
its agreed Service Levels.
Monthly Service Review Book contains details of capacity,
availability and incident management performance.
No deviations noted.
7.1 Network Performance Criteria
Network availability and perf ormance
requirements are clearly defined between Fujitsu
and POL in the Network Serv _ ice descriptions
and network service is measured and monitored
using these agreed service levels.
Through discussion with m anagement, we confirm ed that
documents that define the network availability for the POL
account are in place.
Determined whether these were av
Fujitsu employees.
ailable to relevant
No deviations noted.
7.2 Network Change Management
Network changes are m _anaged using the
standard Fujitsu MSC process including
authorisation, testing (where deem ed
appropriate) and approv al of changes bef ore
they are implemented.
Selected a network change and determined whether _ this
change was m anaged using the standard Fujitsu MSC.
process including authorisation, testing (where deem ed
appropriate) and approv al of the changes bef ore it was
implemented.
No deviations noted.
7.3 Network Availability Monitoring
Network availability is m onitored using sev eral
tools, which send autom _ ated alerts to the
Network Operating Support Serv ice Team
(NOSS) if key components are unavailable, or if
traffic levels breach predefined thresholds.
Observed the HP Openv iew, CACTI and Tiv oli Netcool
tools monitoring network availability, including that they are
configured to send autom ated alerts to the Network
Operating Support Service Team (NOSS).
No deviations noted.
Description of Tests and Results 78
oO
FUJITSU
FUJ00237007
FUJ00237007
ntrols Specified by Fujits
esting Performed by Erm:
Control Objective: 7 Controls prov ide reasonable assurances that networks are m anaged to contractual and site requirem ents, monitored for availability and
response times and issues are identified, tracked and resolved.
7.4 Network Incident Management
Incidents relating to network av _ailability are
managed using standard incident m anagement
procedures used on the POA, and are included
in the standard incident m anagement reporting
to POL.
Selected a network incident and determined whether it was
managed using standard incident management procedures
used on the POA, and are included in the standard
incident management reporting to POL.
No deviations noted.
Description of Tests and Results 79
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.8 Control Objective 8
Controls Specified by Fujitsu
Testing Performed by Ernst & Young LLP
Results of Tests —
Control Objectiv e 8: Controls prov ide reasonable
implemented and documented.
assurance thatm odifications to system sof tware and networks are authorised, tested, approv
ed, properly
8.1 Change Management
The MSC toolset is used to manage all changes
with a joint decision between Fujitsu and POL as
to which parts of the tool are relev antfora
change.
Selected a sample of changes and determined whether the
MSC toolset had been used to m anage these changes in
accordance with the defined procedures.
No deviations noted.
8.2 Change Approval
All changes m ust be authorised by the Fujitsu
Duty Manager or technical bridge, with approv al
being documented in the MSC system. Changes
that cause m ajor service interruption m ust also
be authorised by the Change Advisory Board
(CAB), with approv al being docum ented in the
meeting minutes and within the MSC system
Selected a sam ple of changes and determined whether
these had been authorised, with approv al being
documented in m eeting minutes and/or within the MSC
system.
No deviations noted.
8.3 Emergency Changes
Any change deem ed necessary in order to
resume liv e serv ice will be agreed and
authorised and docum ented during the incident
along with updates to POL at an agreed
Selected a sample of emergency changes and determined
whether these had been agreed and authorised and
documented during the incident along with updates to POL
at an agreed tim eframe dependent on the sev erity of the
incident.
No deviations noted.
timeframe dependent on the sev __ erity of the
incident.
Description of Tests and Results 80
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.9 Control Objective 9
Controls Specified by Fujitsu
Testing Performed by Ernst & Young L LLP
Control! Objective 9: Controls provide = assurance that new or modified application software development efforts are authored tested, eppICved: properly
implemented and documented.
9.1 System Dev elopment and Maintenance
Policies and Procedures
Fujitsu has a f ormal Systems Development Life
Cycle (SDLC) which incorporates phases
including Initiation, Requirements, Definition,
Design, Development, Deployment and
Maintenance.
Through discussion with m anagement, we confirm ed that
the documents that define the SDLC f or the POL account
are in place.
Determined whether these were av _ailable to relevant
Fujitsu em ployees, and whether these included phases
including:
¢ Initiation
e Requirem ents, Definition
« Design
« Dev elopment
« Deploym ent
« Maintenance
No deviations noted.
9.2 Change Control Board
Depending on the nature, changes m ust either
be approv ed by the Change Control Board
(CCB) before progressing into dev elopment or
by the PEAK Targeting Forum (PTF).
Selected a sam ple of changes and determined whether
these had been appr oved by either the Change Control
Board (CCB) or the PEAK Targeting Forum (PTF) before
progressing into development.
No deviations noted.
9.3 Design Proposal
Projects are outlined in a Design Proposal
(DPR) that is held in DOORS or Sharepoint and
is reviewed and approv ed by POL as well as
Fujitsu management.
Selected a sam ple of projects and determined whether
these had a Design Proposal (DPR) document that had
been reviewed and approv ed by POL as well as Fujitsu
management.
No deviations noted.
Description of Tests and Results 81
oO
FUJITSU
FUJ00237007
FUJ00237007
_ Results of Tests
Conusl Objective 9: Controls provide reasonable assurance that new or modified application software development ators are authorised tested, approved, properly
implemented and documented.
9.4 Change Testing
Changes are tested in line with the defined
procedure.
Selected a sam ple of changes and determ ined whether,
where applicable, for these changes:
* Testing had been done by the relev
and Post Office team.
Test plans had been placed in the Quality Centre
application:
* The POL testing m anager had emailed to indicate their
approval that all testing has been successf ully
completed.
ant Fujitsu team
No deviations noted.
9.5 Ability to Implement Changes
Only appropriate individuals hav e access
needed tom _ ove code builds between
environments or prom ote transports to live.
Segregation of duties is enforced between users
able to develop and implement changes.
Selected a sam ple of application serv ers and determined
who had access to im plement changes, and assessed
whether these user _s were appropriate and that
segregation of duties is enf orced between user s able to
develop and implement changes.
No deviations noted.
9.6 Approval to Implement Changes
POL approval is required to prom ote software
changes to the liv e env ironment. Approv al is
captured within the relevant MSC.
Selected a sam ple of changes and determined whether
PO approval to implement the change was recorded within
the relevant MSC.
No deviations noted.
Description of Tests and Results 82
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.10 Control Objective 10
" Controls Specified by Fujitsu = I
" Testing Performed by Ernst & Young LLP
_ Results of Tests —
Control Objective 10: Controls provide reasonable assurance that access to system resources, including computing pet GnTe and operating systems, is restricted to
properly authorised individuals.
10.1 Client Security Policies
Security requirem ents f or infrastructure and
software are designed, documented and agreed
by both POL and Fujitsu.
Through discussion with m anagement, identified the
documents that define the information security architecture
and procedures for the POL account.
Determined whether these were av _ailable to relevant
Fujitsu employees, and whether these had been r eviewed
and approved in line with contractual requirements.
No deviations noted.
10.2 Baseline Operating System Standards
Platforms in operational use hav e defined
baseline standards that docum ent their set up
and configurations, as agreed by Post Office
Limited.
Selected a sam ple of platform s in operational use and
determined whether baseline standards had been def ined
and agreed with POL.
No deviations noted.
10.3 Baseline Operating System Standards
Implementation
Platforms in operational use are set up and
configured in line with docum ented and agreed
baseline standards. Variances from the baseline
standard are fully documented and appropriately
approved.
Selected a sam ple of platform s in operational use and
determined whether the platf orms had been set up and
configured in line with docum ented and agreed baseline
standards.
Determined whether variances from the baseline standard
had been docum ented and approv ed in accordance with
defined procedures.
We selected a sam ple of 12 platform s within
the in-scope applications. The Group Policy on
failed access attempts that manages access to
all these serv ers was set to disable account s
after 6 consecutive failed access attempts; the
POL setting should be to disable accounts
after 3f ailed access attem pts. The other
settings tested were in line with the POL
requirements.
No other deviations noted.
Management response
Management accept this deviation and will
rectify at the next rev ision of the Policy
document SVM/SEC/POL/0003.
Description of Tests and Results 83
oO
FUJITSU
FUJ00237007
FUJ00237007
_ Controls Specified by Fujitst
Control Objective 10: Controls provide reasonable assurance that access is Sesleti resources, friend computing platforms and aperating sane: is restricted to
properly authorised individuals.
10.4 User (Fujitsu) Set-up and Amendment
Fujitsu users requiring new or m odified access
to Post Office Limited system _s are set up
appropriately, and approv ed by an appropriate
Fujitsu line manager.
Selected a sam ple of Fujitsu users giv en access to POL
systems during the period under rev iew and determ ined
whether these users had been set up in accordance with
the access request, and that the request had been
approved by an appropriate Fujitsu line manager.
No deviations noted.
10.5 User (Fujitsu) Deletion
Access to Post Office Limited system s for
Fujitsu users is rem oved ina tim ely manner
once no longer required.
Selected a sample of Fujitsu staff that left the POL account
during the period under rev iew and determ ined whether
their access had been removed on a timely basis.
No deviations noted.
10.6 Periodic User Reviews
Fujitsu and POL m eet regularly in the ISMF to
review whether user access to systems remains
appropriate, with changes then processed as
necessary by POL.
Selected asam ple of ISMFm_ eeting minutes and
determined whether roles and access rights had been
reviewed as defined.
No deviations noted.
10.7 Two-Factor Authentication
Access to Post Office Limited system sfor
Fujitsu user s is controlled using t wo-factor
authentication.
Observed Fujitsu staff logging on to POL systems and
determined whether this required two factor authentication.
No deviations noted.
Description of Tests and Results 84
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.11 Control Objective 11
Controls Specified by Fujitsu
I Testing Performed by Ernst & Young LLP
“Results of Tests
Control Objective 11: Controls provide reasonable assurance that access to databases, data files, and prograns is
restricted to properly authorised individuals.
11.1 Patch Management
In-scope platforms are m aintained with v endor
released security updates and patches in line
with agreed procedures and timescales.
Selected an in scope platform and determined whether the
most recent patches had been applied to the serv er
operating system.
Determined that patches are applied using the sam e
change process and controls as tested f or Control
Objective 8.
No deviations noted.
11.2 System Administrators
Access to perf orm system administrator
functions restricted to appropriate Fujitsu
personnel required to hav e this lev el of access
by their role.
Selected a sam ple of serv ers and determined whether
access to perf orm system administrator f unctions was
restricted to appropriate Fujitsu personnel required to have
this level of access by their role.
No deviations noted.
11.3 Database Administrators
Access to adm __inister POL databases is
restricted to appropriate Fujitsu personnel
required to hav e this lev el of access by their
role.
Selected a sample of in scope databases and determ ined
whether access to adm __inister those databases was
restricted to appropriate Fujitsu personnel required to have
this level of access by their role.
No deviations noted.
11.4 Administration Tools and System Utilities
Access to adm _inistration tools and sy stem
utilities on Post Office Limited infrastructure is
restricted to appropriate Fujitsu personnel
required to hav e this lev el of access by their
role.
Selected a sam ple of platforms and determined whether
access to administration tools and system utilities on Post
Office Limited inf rastructure is restricted to appropriate
Fujitsu personnel required to hav e this level of access by
their role.
No deviations noted.
11.5 Unauthorized Changes are Monitored
The TripW ire sy stem is configured to monitor
and alert on changes m ade to in-scope
applications and underlying data.
Selected a sam ple of application serv ers and determined
whether the TripW ire system was conf igured to m onitor
and alert on changes m ade to in-scope applications and
underlying data.
No deviations noted.
Description of Tests and Results 85
oO
FUJITSU
FUJ00237007
FUJ00237007
Control Objective 11: Controls provide reasonable assurance that access to databases, data files, and prograns is restricted to properly authorised individuals.
11.6 Access to Data Files / Programs
restrict and allow access.
Access is restricted to production program and
data files through the use of —_ user groups to
Selected a sam ple of platforms and determined whether
access to significant production program and data files
was appropriately restricted.
No deviations noted.
Description of Tests and Results
86
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.12 Control Objective 12
_____ Controls Specified by Fujitsu
Testing Performed by Ernst & Young LLP
Results of Tests
Control Objective 12: Controls prov ide reasonable
detected, reported and investigated.
assurance that networks and sy stem resources are protected f rom external threats and access v iolations are
6.4 Major & Security Incident Review
Once a Major or Security Incident is resolv ed
there is a f ormal closure of the incident and a
review including, if applicable, a Root Cause
Analysis.
Selected a sam ple of Major and Security Incidents and
determined whether a Formal Closure of the Incident took
place including a review of the Incident with, if applicable,
a Root Cause Analysis.
No deviations noted.
12.1 Configuration Access
Access to set-up and conf __ igure firewalls is
restricted to appropriate Fujitsu personnel
required to hav e this lev el of access by their
role.
Selected a sam ple of firewalls and determ ined who had
access to set up and conf igure these devices. Assessed
whether personnel with these rights were appropriate.
No deviations noted.
12.2 Configuration Changes
Changes to f irewall configuration are m anaged
using the standard Fujitsu MSC process
including authorisation, testing (where deem ed
appropriate) and approv al of changes bef ore
they are implemented.
Selected a change to firewall configuration and determined
whether this:
« had been authorised, tested ( where deem ed
appropriate) and approv ed before being im plemented;
and
* was m anaged using the MSC process tested under
Control Objective 8.
No deviations noted.
12.3 Anti-virus Software
Anti-virus sof tware is installed on critical
networked W indows and Red Hat Linux
platforms as agreed with POL. Installed anti-
virus software is up to date in line with agreed
contractual requirements.
Selected a sample of servers and determined whether AV
software was installed and up to date.
No deviations noted.
Description of Tests and Results 87
oO
FUJITSU
FUJ00237007
FUJ00237007
7.2.13 Control Objective 13
"Controls Specified by Fujitsu
‘Testing Performed by Ernst & Young LLP _
Results of Tests
Control Objective 13: Controls exist to provide reasonable assurance that remote access is appropriately restricted
to authorised personnel.
10.4 User (Fujitsu) Set-up and Amendment
Fujitsu users requiring new or m odified access
to Post Office Limited system _s are set up
appropriately, and approv ed by an appropriate
Fujitsu line manager.
Selected a sam ple of Fujitsu users giv en access to POL
systems during the period under rev iew and determ ined
whether these users had been set up in accordance with
the access request, and that the request had been
approved by an appropriate Fujitsu line manager.
No deviations noted.
10.7 Two-Factor Authentication
Access to Post Office Limited system
Fujitsu user s is controlled using t
authentication.
sf or
wo-factor
Observed Fujitsu staff logging on to POL systems and
determined whether this required two factor authentication.
No deviations noted.
13.1 Remote Access Authorisation
The use of Radius Authentication and CHAP for
Counters accessing the Data centres ensures
that access is restricted to approved devices.
Obtained network documentation and determined whether
Radius Authentication and CHAP for Counters validation is
in place for remote access requests.
No deviations noted.
Description of Tests and Results 88