Professional Documents
Culture Documents
Policies & Procedures
Policies & Procedures
Policies & Procedures
Network Project
1.
Information Communication
C
Technology
echnology
Standard Operating Guidelines and Procedures
Manual
Prepared by
If you have any questions about this document, please contact the following individual:
Name
Date
ICT TWG
20/12/2013
Revision history
This section identifies revisions to this document:
#
Name
Revision
Description
Date
1.0
ICT TWG
V001
20/12/2013
1.1
Contacts
For more information about this manual please contact
Name
Position
ICT TWG-Chair
jbaptist.mugisha@gmail.com
Please also visit our web portal for further information on http://eaphln-ecsahc.org/
Table of Contents
1
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
37
38
39
40
41
42
45
46
47
48
49
50
51
52
55
56
57
58
59
60
61
62
63
65
66
67
Table of figures
FIGURE 1: NETWORK CONFIGURATION FLOWCHART ......................................................................................................... 30
FIGURE 2: SUPPORT AND MAINTANCE FLOW CHART ......................................................................................................... 34
FIGURE 3: HARDWARE FLOWCHART .............................................................................................................................. 39
FIGURE 4: PHYSICAL SECURITY AND ENVIRONMENTAL CONTROLS FLOWCHART .................................................................... 100
FIGURE 5: CHANGE APPROVAL BOARD RISK MATRIX ...................................................................................................... 105
FIGURE 6: NORMAL CHANGE MANAGEMENT FLOWCHART ............................................................................................. 108
FIGURE 7: EMERGENCY CHANGE PROCESS FLOWCHART ................................................................................................... 109
FIGURE 8: GENERAL SOFTWARE GUIDELINE FLOWCHART ................................................................................................. 123
FIGURE 9: ICT QUALITY MANAGEMENT FLOWCHART ..................................................................................................... 128
FIGURE 10: INCIDENT MANAGEMENT PROCESS ............................................................................................................. 134
FIGURE 11: INCIDENT MANAGEMENT FLOWCHART ........................................................................................................ 136
FIGURE 12: INCIDENT MANAGEMENT FLOWCHART ........................................................................................................ 136
FIGURE 13: CONTINGENCY PLANNING FLOWCHART ........................................................................................................ 140
FIGURE 14: DEFINING IT GOALS AND ENTERPRISE ARCHITECTURE FOR IT ........................................................................... 146
FIGURE 15: ICT PROJECT MANAGEMENT FLOWCHART ................................................................................................... 154
FIGURE 16: ICT PROJECT CONCEPTUALIZATION AND APPROVAL FLOWCHART ...................................................................... 157
FIGURE 17: ICT PROJECT PLANNING FLOWCHART .......................................................................................................... 160
FIGURE 18: PROJECT IMPLEMENTATION MONITORING FLOWCHART .................................................................................. 164
FIGURE 19: PROJECT CLOSURE, SIGN-OFF AND RETENTION OF PROJECT DOCUMENTATION FLOWCHART ................................... 168
FIGURE 20 : QUALITY ASSURANCE AT ACQUISITION FLOWCHART ...................................................................................... 173
FIGURE 21 : QUALITY ASSURANCE AT INSTALLATION/IMPLEMENTATION FLOWCHART ............................................................ 175
FIGURE 22: RESEARCH & DEVELOPMENT FLOWCHART .................................................................................................... 180
FIGURE 23 : CONTINGENCY PLANNING SCENARIOS......................................................................................................... 196
FIGURE 24: SOFTWARE BUSINESS CASE VALIDATION FLOWCHART ..................................................................................... 205
FIGURE 25: SOFTWARE REQUIREMENTS DEFINITION FLOWCHART ..................................................................................... 207
FIGURE 26: SOFTWARE SECURITY REQUIREMENTS DEFINITION FLOW CHART ....................................................................... 221
FIGURE 27: SOLUTION DESIGN FLOWCHART .................................................................................................................. 225
FIGURE 28 : DEVELOPMENT & CUSTOMISATION FLOWCHART........................................................................................... 230
FIGURE 29: SEPARATION OF DEVELOPMENT AND OPERATIONAL FACILITIES FLOWCHART ....................................................... 233
FIGURE 30: SYSTEM ACCEPTANCE AND TESTING FLOWCHART ........................................................................................... 236
FIGURE 31: CONTINGENCY PLANNING FLOWCHART ........................................................................................................ 243
FIGURE 32: SECURITY INCIDENT FLOWCHART ................................................................................................................ 246
FIGURE 33: INCIDENT LOGGING / IDENTIFICATION AND PROTECTING EVIDENCE FLOWCHART................................................... 249
FIGURE 34: CONTAINMENT OF INCIDENTS FLOWCHART ................................................................................................... 252
FIGURE 35: ESCALATION OF INCIDENTS TO DISASTER MANAGEMENT FLOWCHART................................................................. 255
FIGURE 36: ERADICATION OF INCIDENTS FLOWCHART ..................................................................................................... 258
FIGURE 37: INCIDENT RECOVERY FLOWCHART ............................................................................................................... 261
FIGURE 38: EVALUATION OF INCIDENT REPORTS FLOWCHART ........................................................................................... 263
FIGURE 39: INCIDENT CLOSURE FLOWCHART ............................................................................................................. - 266 -
Tables
TABLE 1:DATA CENTER OPERATION CHECKLIST .............................................................................................................. 199
Acronyms
CIRT
EAPHLNP
ECSA-HC
ICT
ICTSOPs
LAN
Organisation
OS
Operating System
PBX
WHO
Definitions
Abuse of Privilege:
Backup:
Change:
any implementation of new functionality
any interruption of service
any repair of existing functionality
any removal of existing functionality
Change Management:
Computer Incident Response Team (CIRT): Personnel responsible for coordinating the
response to computer security incidents in an organization
Custodian:
Emergency Change:
Firewall:
Host:
Information:
Information Attack:
Information Resources (IR): Any and all computer printouts, online display devices,
magnetic storage media, and all computer-related activities
involving any device capable of receiving email, browsing Web
sites, or otherwise capable of receiving, storing, managing, or
transmitting electronic data including, but not limited to,
mainframes,
servers,
personal
computers,
notebook
computers, hand-held computers, personal digital assistant
(PDA), pagers, distributed processing systems, network
attached and computer controlled medical and laboratory
equipment (i.e. embedded technology), telecommunication
resources, network environments, telephones, fax machines,
printers and service bureaus. Additionally, it is the procedures,
equipment, facilities, software, and data that are designed,
built, operated, and maintained to create, collect, record,
process, store, retrieve, display, and transmit information.
Information Security Officer (ISO): Responsible to the IRM for administering the
information security functions within the Organisation. The ISO
is the Organisations internal and external point of contact for
all information security matters.
Information Services (IS): The name of the Organisation department responsible for
computers, networking and data management.
Internet:
Intranet:
IT governance :
Owner:
Password:
Portable Computing Devices: Any easily portable device that is capable of receiving
and/or transmitting data to and from IR. These include, but are
not limited to, notebook computers, handheld computers,
PDAs, pagers, and cell phones.
Production System:
Scheduled Change:
Security Administrator:
Server:
Strong Passwords:
System Development Life Cycle (SDLC): a set of procedures to guide the development of
production application software and data items. A typical SDLC
includes design, development, maintenance, quality assurance
and acceptance testing.
Trojan Horse:
Unscheduled Change:
User:
Vendor:
Virus:
Webserver:
Web Site:
Worm:
1 Organisation/ICT/02/01/02 - INTRODUCTION
1.1 Preamble
The East Africa Public Health Laboratory Networking Project is a regional World Bank
funded Project designed to strengthen laboratories in the region. This is a five-year project
being implemented in five countries, namely Kenya, Rwanda, Tanzania , Uganda and
Burundi in collaboration with the East, Central and Southern Africa Health Community
Secretariat (ECSA-HC), East African Community (EAC) , World Health Organization (WHO),
US Centers for Disease Control and Prevention (US CDC) and the Microsoft Organisation
(USA).
Rwanda has agreed to take a regional lead in expanding use of ICT and promoting PBF
approaches for laboratory services, building on its well-recognized successes in these areas.
Cross cutting ICT innovations will be promoted to improve the quality of laboratory and
surveillance data; facilitate the sharing of information; and promote e-learning and webbased knowledge sharing across countries. Rwanda will: (i) share its tools (e.g. standards
and guidelines, reporting forms, request for proposals); (ii) provide related training, capacity
building, and technical support as well as organize site visits; and (iii) take a lead in
determining the applicability of the PBF approach to public health laboratories and document
and share lessons. Rwanda will also share lessons in MDR-TB as it has been selected by
KNCV (Dutch TB Foundation) and will be supported by USAID to become a center of
excellence for MDR-TB for the Africa region. Through this initiative these ICT SOPs have
been developed to assist in improvement of ICT standards across the East African
Community.
The term Organisation shall be used in this ICT standard operating procedures and
Guidelines to represent the EAPHLNP supported organisations where this manual shall be
used on a day-to-day bases.
The Organisation ICT Environment includes all the computers, servers, monitors, printers,
cables, hubs/switches, software, data, information systems, internet connectivity, emailing,
scanners, modems, mouses, keyboards, laptops, use of external data communications
infrastructure, UPSs, data backups, disaster recovery, antivirus protection, help desk,
software library, manuals library, hardware repairs, internet usage, user log-ons, security
permissions, firewalls, web sites, strategic plans and Guidelines, procedures and standards,
training facilities, data replication, and telephony.
Comprehensive computerization and provision of cost effective, reliable and secure
integrated ICT systems and services across and within departments therefore remains
Organisations ICT mission in the immediate and medium terms. Organisation requires
quality, effective and reliable information systems that provide relevant, accurate and timely
data. The ICT infrastructure and systems ought to be developed, maintained and sustained
through appropriate planning, budgeting, ad-hoc and pro-active maintenance, and User
education
To achieve this intent, Organisation needs to operate in an effectively controlled ICT
environment and adhere to the highest standards in the management and utilization of ICT
systems. The development and maintenance of expensive and complex information and
technology environments the hardware, software, data and human resources, requires
discipline and rigid rules to ensure the existence of the highest levels of consistency and
control. It is for this purpose that Organisation has developed this Information
Communication Technology Standard Operating Procedures, Guidelines and Guidelines
(ICTSOPS).
2.2 Objective
The main purpose of this Guideline is to define the eligibility for use of ICT resources. The
general principles that underlie eligibility and Responsible use Guidelines for information
technology are:
Organisation ICT resources are for its core business purposes and must be used in line, and
to achieve its core mandate, vision and mission.
Any use counter to this, or which interferes with core use by others, is unacceptable
Specialized information technology services may require additional authorization, approval,
or separate registration as per the User management and Network Access Guidelines.
2.3 Scope
This Guideline applies to all users of Organisation information technology resources
regardless of affiliation, and irrespective of whether those resources are accessed from
Organisation offices or remote/off-site locations.
2.5 Responsibility
These are people that are affected by this Guideline.
Roles
All ICT Department Staff
Responsibility
1.Comply with the ICT SOPs
2. Implement in daily
operations
1. Comply with the ICT SOPs
2. Implement in daily
operations
3.2 Objective
This Guideline has been established to:
i.
ii.
iii.
3.3 Scope
These regulations apply to:
Users (staff whether permanent, contractual, temporary or trainees) using either personal or
Organisation provided equipment connected locally or remotely to the network of
Organisation. Throughout this Guideline, the word "user" will be used collectively to refer to
all such individuals or groups.
All ICT equipment connected (locally or remotely) to Organisation servers and ICT systems
owned by and/or administered by ICT department of Organisation
All devices connected to the Organisation network irrespective of ownership and all external
entities that have an executed contractual agreement with the Organisation
3.5 Responsibility
These are people that are affected by this Guideline.
Roles
Responsibility
All ICT Department Staff
1. Comply with the ICT SOPs
2.Implement in daily
operations
All ICT Resource Users
1.Comply with the ICT SOPs
2. Implement in daily
operations
4.2 Objective
It is the intention of the organisation to ensure that ICT systems are of the highest technical
and operational standards.
It is also important to ensure that all systems are interoperable and integrated.
4.3 Scope
This covers all ICT systems including hardware, software, algorithms, e.g. Compression,
encryption, and processes.
4.5 Responsibility
These are people that are affected by this Guideline
Department
Head of ICT
Role(s)
1. Ensure that standards are
implemented in ICT operation.
2. Monitor implementation of
standards
1. Observe standard implementation
in daily operation
1. Confirm that standard are being
implemented in all operations
5.2 Objective
This is to ensure that members of staff are aware of these Guidelines and their obligations to
the conformity to these Guidelines and procedures.
These Guidelines are also an education aid meant to train users on best practices.
5.3 Scope
This applies to all ICT Guidelines and procedures, and any directives from management
regarding ICT usage that may be released from time to time.
The Guideline also covers all Organisation staff that may use ICT resources or may be
affected by ICT resources.
All Organisation Staff including staff who may not be organisational staff but are at the site or
laboratory are expected to demonstrate awareness and caution in information security
matters. In turn, Organisation shall identify and provide appropriate Information Security
awareness tools to support this process.
The ICT Department shall be responsible for awareness related campaigns to educate the
users about ICT Standard Operating Procedures and Guidelines and all related awareness
campaign shall be adequately communicated and scheduled for attendance.
5.5 Responsibility
These are people that are affected by this Guideline
Roles
ICT Department
All Users
Responsibilities
1. Provide Awareness campaign to
users about the ICT SOPs
2. Apply the ICT SOPs in all process
3. Ensure that users a compliant with
the ICT SOPS
1. Shall comply with the ICT SOPs
6.2 Objective
The purpose of the Organisation User Account Management Guideline is to establish the
rules for the creation, monitoring, control and removal of user accounts
6.3 Scope
The Organisation User Account Management Guideline applies equally to all individuals with
authorized access to any Organisation Information Resources. The scope of this Guideline
includes Organisation computer and telecommunications systems and the employees,
contractors, consultants, temporary personnel and other agents of the state who use and
administer Organisation systems.
6.5 Responsibility
These are people that are affected by this Guideline
Roles
User
Responsibilities
1. Requests access to the Laboratory
information System/Health Information
system through the use of User
Requisition Template.
2. The User department approves the
request
Authoriser
1.
2.
ICT Department
1.
User Department
1.
6.6 Procedure
This Procedure describes the process for establishing user accounts for accessing the
information systems used in Organisation. This includes requesting, approving, creating and
maintaining user accounts for all applications supported by ICT Department. Adherence to
this procedure protects the security, privacy and data integrity issues of information held in
Organisation applications.
Conducting background and security checks of users requesting access to Organisation
applications are and remain the sole responsibility of the Organisation ICT Department.
Users must request access to the system through the use of a User Requisition Template.
The user requisition template must be approved by the User Department head.
User Help Desk (UHD) will approve the users access and determine the users appropriate
level of access or role in accessing the requested application. Where appropriate, UHD will
verify with the party responsible for authorizing the users access. UHD will provide the user
with a user name and a password. The password is set to expire upon initial user log in (This
may vary with the Laboratory information systems/Health information system configuration)
and must be re-established following the password rules established in the password
Guideline guidelines.
Where appropriate, training on the application must be completed prior to being granted
access.
It remains the sole
users access must
personnel, change
employment status
required).
All appropriate Organisation sites will use this procedure for guidance relative to establishing
user accounts to Organisation applications and information systems
7.2 Objective
The purpose of this Guideline is to provide guidance in the process of performing reviews
and audits in the environment as a countermeasure for protecting the information assets of
the organisation.
7.3 Scope
The Organisations ICT Assessment Guideline shall apply to all the entire ICT environment
Hardware, software, networks and people who use the network.
7.5 Procedure
Three different types of audits have been developed to support the ICT Assessment
compliance program: documentation review, network vulnerability scan, and field audit. At
the conclusion of any audit, an audit report documenting the findings will be produced.
Submitting entities may be subject to any combination of these three audits and are
requested to define a responsible party (i.e., someone who will assist with all audit activities
and be accountable for all deliverables required by the audit on behalf of the submitting
entity as outlined below). All audits will be conducted in English. Local resources may be
required to assist with language translation in order to properly manage the cost of the audit.
The audits consist of the following components:
Documentation review
This audit will review the documentation referenced in the Self-Assessment. If audited, the
submitting entity will be asked to supply a set of documents which define the information
security program as described in their Self-Assessment. Auditors will then review this
documentation against the Guideline requirements.
The documentation review consists of Pre-Audit and Audit phases:
Pre-Audit - One month before the audit, the audit team will send out an information pack
outlining the process to be followed, what documentation is to be made available for the
audit, and other relevant information. A conference call is then conducted between the audit
team and the responsible party for the submitting entity to answer questions and plan the
audit. The responsible party then prepares and submits the documentation requested.
Audit - The Audit Team reviews the documentation submitted and determines if the
requirements are met for the audited Guideline. The Audit Team will maintain a dialog with
the responsible party during this process and may request clarification or additional
documentation.
Network vulnerability scan
This audit will use industry-standard network tools to perform vulnerability scans of the
selected entitys network infrastructure. Based on a mutually agreeable scope and schedule,
these scans examine the network for potential vulnerabilities. The audit team will coordinate
with the responsible party to avoid any impact to normal operations.
A Network Vulnerability Scan consists of two phases, the network mapping and the
vulnerability scan. During the network mapping phase, the scanner discovers the target
network topology and information systems that are online within the given IP address space.
The audit team will examine the network map to determine if all devices included are in fact
considered in scope for the scan.
Once complete, the vulnerability scan phase will begin during which time the scanner will be
set to programmatically scan all devices within the address space for predefined port ranges.
The scan identifies known vulnerabilities that may allow information leakage, denial of
service or privileged access to the unauthorized user.
Field audit
This audit is the most in-depth and includes a mixture of documentation review and on-site
visits and interviews with selected personnel. It may also include attack and penetration
testing of the infrastructure. Each audit will follow a standard process, which consists of PreAudit and Field Work.
Pre-Audit - One month before the audit, the audit team will send out an information pack
outlining the process to be followed, what documentation is to be made available for the
audit, and other relevant information. The audit team will conduct a workshop session with
each entity being audited. The workshop will help the responsibility party to prepare for the
audit and provide the audit team with the information needed to complete the audit.
Field Work - This stage includes interviews with business and IT personnel, review
documentation, selected attack and penetration testing, and feedback to the responsible
party. The length of the audit will vary with the size and complexity of the submitting entity
and will require spending anywhere from three to eighteen days on location.
Audit findings
Each audit will conclude with the audit team consolidating and documenting their findings in
a formal report. The report is reviewed with the responsible party and may recommend the
enabling of or improvement to security controls to become compliant, e.g. installation of
firewalls or establishing a process. Once the accuracy of the findings is acknowledged by the
responsible party, the formal report is shared , the responsible the Information Security
head and/or Area CIO as appropriate or lead Information Security on in ICT Department.
The entity is responsible for documenting a remediation plan which addresses
noncompliance and identifies the timeline. Based upon this remediation plan, an exception
may need to be filed.
If any verification audit identifies significant areas of noncompliance posing risk to the
organisation, a decision may be made to disconnect a location from the network or reduce
available services in order to help mitigate the risk to the rest of the organisation while
remediation activities are undertaken.
7.6 Responsibility
These are people that are affected by this Guideline
Roles
ICT Department
ICT Department
Responsibilities
1.Plan for Audit
2.Coordination of the Audit
3.Review the Findings
4. Plan remedial Actions
1. Plan for Audit
2. Coordination of the Audit
3. Review the Findings
4. Plan remedial Actions
8.2 Objective
The purpose of the Organisation Network Configuration Guideline is to establish the rules for
the maintenance, expansion and use of the network infrastructure. These rules are
necessary to preserve the integrity, availability, and confidentiality of Organisation
information.
8.3 Scope
These regulations apply equally to:
i.
ii.
iii.
All connections of the network infrastructure to external third party networks is the
responsibility of Organisation ICT. This includes connections to external telephone networks.
The use of departmental firewalls is not permitted without the written authorization from
Organisation ICT.
Users must not extend or re-transmit network services in any way. This means you must not
install a router, switch, hub, or wireless access point to the Organisation network without
Organisation ICT approval.
Users must not install network hardware or software that provides network services without
Organisation ICT approval.
Users are not permitted to alter network hardware in any way.
No network equipment or other electronic communication facility may be borrowed, removed
or moved from a designated location, without the explicit permission of the ICT Department
or their representative, as appropriate
No equipment other than equipment designed to be portable and used outside Organisation
can be taken out of the Organisation premises without the explicit permission of the ICT
Department of ICT or their representative, as appropriate. For permission to be granted, the
necessary forms (see annex) detailing the purpose of the removal of the equipment and the
equipment details must be filled by the applicant and countersigned by the appropriate
manager or owner as mentioned above.
8.5 Responsibility
These are people that are affected by this Guideline
Department
Network Administrators
End User
Role(s)
1. Design Network
2. Configure network according to design
3. Ensure network is configured according to
best practise
1. Shall use the network as set out and
approved by the Network administrators
8.6 Procedure
The following procedure shall be followed in setting up preliminary networks or altering
configurations of existing networks
Determine the purpose of the network you intend to set up and document it accordingly
Determine the network components needed to set up the network (this includes cabling,
servers, routers, switches and other hardware and the software needed)
i.
Determine the addressing schemes and labelling for the components identified in 2
above. If IP addresses are required, get the right one from appropriate authorities
ii.
Draw a detailed network diagram showing the configuration as you intend to set it up.
Highlight the relationship to other existing networks both internal to Organisation
(intranet) or external (e.g. Internet)
iii.
Seek the approval for this implementation through the right change management
processes as defined in this manual.
iv.
Acquire the network components and other items needed for this configuration
v.
Set up the network as required
vi.
Update Network documentation
The Organisation ICT gives support and maintenance to users of their ICT systems.
Maintenance aims at retaining the system in the working state which it was supposed to
have been delivered while in support of any efforts by the ICT depart to enable users
achieve their objectives in the usage of ICT.
Support includes such effort as :Additional training, assisting users in activities which are
would enable them complete their tasks, developing minor reports, modifications and
enhancements, undertaking activities such as upgrades, migration, re-installing software,
trouble shooting, etc.
Maintenance here includes both scheduled, preventive maintenance as well as incidental
maintenance which is ad hoc
9.2 Objective
These Guidelines and procedures provide a framework for an support and maintenance of
ICT services for smooth and efficient ICT Services in which they were initially intended.
They are also meant to streamline the way in which support requests are reported, logged
and resolved.
9.3 Scope
The support and maintenance Guidelines and procedure applies equally to all users
(individuals working for Organisation, including permanent full-time and part-time employees,
contract workers, temporary workers, consultants, contractors and business partners, and
vendors) who access ICT services. That is; Management, Technical and Operational Staff
and Users accessing the system from outside the ICT Department.
The support is for all types of applications and requirements:
i.
Hardware: its fault reporting, usage, preventive and corrective maintenance and
installation
ii.
iii.
iv.
usage,
installation,
upgrades,
updates,
9.5 Responsibility
These are people that are affected by this Guideline.
Roles
System Administrators
Responsibilities
1. Ensure that all support activities are
done in a timely manner in
accordance
to
support
and
maintenance plan
2. Carry out all support activities in
accordance
to
service
level
agreements
3. Ensure that support is carried out by
competent and approved personnel
either internally or externally
9.6 Procedure
Each call should be registered or logged on the selected media: printed form, email, intranet
web page, application, etc.
The Maintenance and Support Request form should contain the following data :
i.
Time/Date
ii.
iii.
Type of call (To be entered by the user and later modified if need be)
iv.
Description of problem
v.
vi.
The Calls should be processed by support staff who can tell which one is to be supported by
which unit. They will then be routed accordingly. During routing, the support person can
enter the receiving partys name on the form. It will be the responsibility of the Support or
Maintenance person to process the Change Request if there is reason to change the
Configuration.
External Maintenance or Support: in case these are to be supplied by Suppliers outside the
Department, it will be the responsibility of the Support person to liaise between the User and
the Suppliers. Suppliers will receive copies of the Request and will act accordingly.
The support person will then review the situation, visiting the user if need be. On completion,
the following is entered on the call form:
i.
ii.
iii.
Real problem/ Diagnosis: as the user may have phrased the problem wrongly,
the support person will enter the actual cause or issue of support.
iv.
Action taken/resolution: describes what was done to solve the problem or give
support
Name of support staff
In case the call is being handled by a Supplier, then the Supplier must complete the call and
fill in some of the information above.
10 Organisation/ICT/02/01/10 - Hardware
10.1 Description
This Guideline covers all the Organisations computing hardware systems whether or not it is
actively used on the computer network. It is meant to ensure that hardware is acquired,
used, maintained and later disposed of using the proper and authorized Guidelines and
procedures.
10.2 Objective
This Guideline aims to promote standardisation, and consequently a reduction in costs to
Organisation through economies of scale and improved efficiencies, by mandating a number
of hardware standards.
10.3 Scope
The Guideline will apply to all Organisation employees and covers ICT equipment procured
for use in all Organisation environments. It also covers other equipment either donated to
Organisation or not owned by the Organisation but being used for Organisation business or
holding Organisation data.
10.5 Responsibility
Departments
ICT Department
Roles
1. Inspect new equipment
2. Develop equipment specifications
10.6 Procedure
The procurement of hardware shall be in accordance with the procurement guidelines.
Ownership and asset registration
i.
All equipment covered by this Guideline document must be asset registered
before first use via Organisations IT Help Desk and with the Asset Register.
ii.
Usage
iii.
iv.
Users will also ensure that proper records, including the IT Inventory Database,
are kept and maintained when equipment is returned, replaced or transferred
between users.
v.
Upon exiting employment with the Organisation, users must over all hardware in
their possession to the their relevant line managers, Human Resources or to the
IT department
Installation
vi.
For reasons of security and support, ICT Support staff must undertake all
installation and initial configuration work for equipment covered by this
document.
Movement of equipment
vii.
Any movement of ICT equipment must be logged in advance with the ICT Help
Desk. Any change of keeper must be logged in advance with the IT Service
Desk. For network and security reasons the uplift and re-connection of nonportable IT equipment without notification is not permitted. The keeper is defined
as the primary user of a piece of IT equipment.
viii.
All requests to take equipment off site must be approved by the relevant Head of
Department and ICT Department, and notified in advance to the IT Service Desk.
ix.
Suppliers of equipment
x.
xi.
Insurance
xii.
The ICT Department will prepare and found a list of all ICT equipment eligible
for insurance
xiii.
The Finance and Accounts Department will provide the book values from the
Fixed Assets Register to be used for insurance.
xiv.
Personal equipment
xv.
xvi.
Use of personal equipment may be restricted to certain areas of the network and
certain network services. This equipment should have up to date anti-virus
software and current security fixes.
xvii.
Disposal of Equipment:
xviii.
Heads of Departments will periodically or as the need arises present a list of old,
obsolete, faulty or unnecessary equipment in their respective Departments and
Areas to the ICT Department for consideration for disposal.
xix.
The ICT Department will also compile and initiate a disposal request for
equipment that is no longer economical to repair, is obsolete, unnecessary, is no
longer supported by the vendors, has reached Zero book value or whose
existence on the Organisation network poses an information security risk. This
shall be in accordance with the Public procurement and disposal guidelines.
All Computers are to be configured by the ICT department. Only unless the user
needs administrative rights for an authorized program, there should be no
change in configuration of the computer.
xxi.
Organisation Staff need approval from the ICT Department in order to add any
extra hardware to the existing systems in place.
xxii.
Computers added to the Organisation domain must have been done by the
Systems Administrator or authorized personnel.
xxiii.
Laptop users should always turn off their laptops before storing them in the carry
cases.
xxiv.
xxv.
All information system hardware faults are to be reported promptly and recorded
in an IT helpdesk database.
xxvi.
xxvii.
11.2 Objective
Service level management provides a benchmark and standard of performance that is
expected from internal and external service provides. This is to enhance service availability
and quality, and provide a platform for measurement and appraisal of performance.
11.3 Scope
This relates to and covers all internal and external service provision.
All service providers must have Service level agreement(s) or contracts.
11.5 Responsibility
These are people that are affected by this Guideline
Department
ICT Department
Role(s)
1. Draft the service level agreement based on
Procurement Department
Legal Department
Users
11.6 Procedure
The ICT Department will develop the Service level parameters and draft the general terms
and conditions to be included the contracts for service provision.
The Legal and procurement departments will incorporate the Service level parameters in the
procurement documents and final agreements
The ICT department will monitor the service level agreement performance and generate
monthly reports on the performance of the ICT environment components under service level
agreement.
The ICT department will report and escalate any support problems causing interruptions to
service.
12 Organisation/ICT/02/01/12 - Email
12.1 Description
This
Guideline
defines
and
distinguishes
unacceptable/inappropriate use of electronic mail (email).
acceptable/appropriate
from
With Email, messages can be transferred quickly and conveniently across internal network
and globally via the public Internet. These messages contain information which can be
intercepted, stored, read, modified and forwarded to anyone, and sometimes go missing.
Casual comments may be misinterpreted and lead to contractual or other legal issues.
12.2 Objective
The purpose of this Guideline is to ensure the proper use of Organisations email system
and make users aware of what the organisation deems as acceptable and unacceptable use
of its email system. The organisation reserves the right to amend this Guideline at its
discretion. In case of amendments, users will be informed appropriately
Information resources are strategic assets of Organisation that must be managed as
valuable state resources. Thus this Guideline is established to achieve the following:
i.
ii.
iii.
12.3 Scope
The Organisation e-mail Guideline applies equally to all individuals granted access privileges
to any Organisation information resource with the capacity to send, receive, or store
electronic mail.
Organisation provides electronic information and communications systems to facilitate the
companies business needs and interests. These systems include individual computers, the
computer network, E- mail, and access to the Internet. This system introduces new
opportunities and new risk exposures for the organisation.
In response to the risks, this Guideline describes Organisation's official practices regarding
Electronic Mail (E-mail) security.
This Guideline applies to all users of the corporate email system of Organisation. The Email
Guideline covers:
i.
E-mail Usage
ii.
iii.
E-mail Retention
iv.
E-mail Attachments
ii.
iii.
iv.
v.
Posing as anyone other than oneself when sending email, except when
authorized to send messages for another when serving in an administrative
support role.
vi.
All email accounts maintained on the organisations email systems are property of the
Organisation. Passwords should not be given to other people and should be changed once a
month. Email accounts not used for 60 days will be deactivated and possibly deleted.
All sensitive Organisation material transmitted over external network must be encrypted.
All user activity on Organisation Information Resources assets is subject to logging and
review.
Electronic mail users must not give the impression that they are representing, giving
opinions, or otherwise making statements on behalf of the Organisation or any unit of the
Organisation unless appropriately authorized (explicitly or implicitly) to do so. Where
appropriate, an explicit disclaimer will be included unless it is clear from the context that the
author is not representing the Organisation. An example of a simple disclaimer is: "the
opinions expressed are my own, and not necessarily those of my employer."
Individuals must not send, forward or receive confidential or sensitive Organisation
information through non-Organisation email accounts. Examples of non-Organisation email
accounts include, but are not limited to, Hotmail, Yahoo mail, AOL mail, and email provided
by other Internet Service Providers (ISP).
Individuals must not send, forward, receive or store confidential or sensitive Organisation
information utilizing non- Organisation accredited mobile devices. Examples of mobile
devices include, but are not limited to, Personal Data Assistants, two-way pagers and
cellular telephones, smart phones.
In order to ensure compliance with this Guideline, Organisation also reserves the right to use
monitoring software in order to check upon the use and content of emails. Such monitoring is
for legitimate purposes only and will be undertaken in accordance with a procedure agreed
with employees.
Email facility shall be available only to the active employees of Organisation. Consequently,
email access shall be provided to a new employee after he/she has joined the Organisation
employment and will be withdrawn immediately upon termination of employment due to any
reason.
Email facility shall not be made available to any other person, including Organisation
contractors, and any other third party providers.
The usage of the E-mail system is subject to the following:
vii.
viii.
ix.
All outgoing E-mails shall include a disclaimer such as This email and any files transmitted
with it are confidential and intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify IT Service desk
All E-mail communication shall be in compliance with Organisation standards regarding
decency and appropriate content. Message content restrictions include:
Organisation information resources shall not be used to transmit or receive statements that
contain any material that is offensive, defamatory, or threatening to others
The corporate email systems shall not be used to communicate statements, messages, or
images consisting of pornographic material, ethnic slurs, racial epithets, or any other
material that may be construed as harassing, offensive, or insulting to others based on race,
religion, national origin, colour, marital status, citizenship status, age, disability, sexual
orientation or physical appearance.
Any statements or comments made via E-mail that could in any way be construed as an
action of Organisation must bear a disclaimer such as These statements are solely my
own opinion, and do not necessarily reflect the views of my employer.
Any user of Organisation Email facilities shall be responsible to safeguard the Organisations
reputation.
Staff shall exercise the same care in drafting E-mails, as they would for any other written
communication that bears Organisations name. Staffs are reminded that any use of E-mail
from the network is easily traceable to Organisation and is likely to be attributed to
Organisation even when a suitable disclaimer is included.
Organisations E-mail system shall not be used to produce or distribute chain mail, operate a
business, or make solicitations for personal gain, political or religious causes, or outside
organizations. Users shall not forward or otherwise propagate, to individuals or groups,
chain letters, pyramid schemes or any other types of data that may unnecessarily consume
system resources or interfere with the work of others.
The following activities are prohibited because they impede the functioning of network
communications and the efficient operations of electronic mail systems:
x.
xi.
xii.
xiii.
Each users must only use their own Organisation official E-mail account and must not allow
anyone else access to their account. Also, users are not allowed to use their personal
(unofficial) email accounts for sending official mail.
Users shall not publish or distribute internal mailing lists to any non-Organisation person.
Organisation corporate email systems shall not be used to transmit or receive trade secrets,
copyrighted materials, or proprietary or confidential information.
Any information regarded as confidential including legal or contractual agreements, technical
information related to Organisations operations or security etc. shall not be communicated
through E-mail without additional security measures.
Under no circumstances, information received through unsecured E-mail is to be considered
private or secure. Clear text information in transit may be vulnerable to interception. Secure
communication through E-mail can be ensured only by using encryption and digital
signatures.
Attachments from unknown or un-trusted sources must not be opened. All E-mail
attachments, regardless of the source or content, shall be scanned for Virus/Malicious code
and other destructive programs before being opened or stored on any Organisation
computer system. Personnel shall perform a virus scan on all material that is transmitted to
other users via E-mail prior to sending it.
Users must not send unsolicited bulk mail messages (also known as junk mail or
spam). This practice includes, but is not limited to, bulk mailing of commercial advertising
and religious or political tracts. Malicious E-mail, such as mail bombing, is prohibited.
Users shall not execute any programs that are received via E-mail. Specifically, users must
not install any upgrades or patches received via E-mail.
The information contained in the systems (including computer files, E-mail and, Internet
access logs, etc.) are Organisations property. At any time, with or without notice, this
information may be monitored, searched, reviewed, disclosed, or intercepted by
Organisation for any legitimate purpose, including the following:
xiv.
To monitor performance
xv.
xvi.
xvii.
xviii.
xix.
The mailbox size for each user shall be restricted to a prescribed mailbox sizes. Wherever
possible, the system flashes a warning colour indicator when a users mailbox size
approaches the limit (75% of the upper limit) and further incoming mail will be blocked when
the mailbox size exceeds the defined upper limit.
The size of incoming and outgoing E-mails shall be restricted as per the organisations
regulations
Any emails exceeding the limits defined shall automatically be rejected and a system
message shall be forward to sender, otherwise a change request form shall be filled by the
recipient user should such a mail be of business importance.
E-mail Security Settings
Organisation employees shall not modify the security parameters within the corporate E-mail
system. Users making unauthorized changes to the E-mail security parameters are in
violation of this Guideline.
E-mail Retention
Information (mail messages and attachments) on Organisations E-mail system shall be
backed up on the server and shall be available for recovery for a period of 1 year.
E-mail Attachments
All attachments bigger than 10 MB (Internal) and 5 MB (external) shall be compressed using
file compression utilities and will be limited in combined size by the email size as defined in
the previous section.
Attachments size shall be controlled as per above to prevent excessive use of mail server
storage capacity and bandwidth.
System administrator shall ensure that all incoming and outgoing E-mails and attachments
are scanned for Virus/Malicious code and the system blocks any password protected
attachments that cant be scanned by the anti-virus agent.
12.5 Procedures
E-mail Usage
When a new employee joins Organisation, HR Department shall provide such an employee
with Organisation E-mail Guideline and obtain consent of understanding and adherence to
the Guideline from the employee. The responsibility and the disciplinary actions associated
with violation of these Guidelines shall apply thereafter.
As part of the user access setup process, the system administrator takes the following
actions to grant email access:
i.
Define the email ID and password to be the same as network ID and password
in accordance with the user management and password management
Guidelines.
ii.
Open the email account and setup the mailbox size in accordance with the limits
defined.
iii.
Inform the user that his/her email account has been opened
iv.
v.
On an on-going basis, the ICT department monitors email usage and performs automated
content scanning, spam detection and prevention. Any violations of the Guideline are
immediately reported to the Head of ICT.
Upon termination of employment, HR Department sends an urgent message to Head of ICT.
Immediately the email id shall be deactivated once the employee terminated his/her
employment with the Organisation.
12.6 Responsibility
These are people that are affected by this Guideline
Roles
All Users
ICT Department
ICT/ Management
ICT Department
Internal
(ICT/Management)
Responsibility
Responsible for complying with this and other
corporate Guidelines at all times. This Guideline also
applies to third party employees acting in a similar
capacity whether they are explicitly bound (e.g. by
contractual terms and conditions) or implicitly bound
(e.g. by generally held standards of acceptable
behaviour) to comply with our information security
Guidelines
responsible for building, configuring, operating and
maintaining the corporate email facilities (including
anti-spam, anti-malware and other email security
controls) in accordance with this Guideline
Responsible for maintaining this Guideline and
advising generally on information security controls.
Working in conjunction with other corporate functions,
it is also responsible for running educational activities
to raise awareness and understanding of the
responsibilities identified in this Guideline
responsible for assisting users with secure use of
email facilities, and acts as a focal point for reporting
email security incidents
Audit is authorized to assess compliance with this and other
corporate Guidelines at any time
ii.
iii.
the internet
13.2 Objective
Thus this Guideline is established to achieve the following:
i.
ii.
To establish prudent and acceptable practices regarding the use of the Internet.
iii.
To educate individuals who may use the Internet, the intranet, or both with
respect to their responsibilities associated with such use
13.3 Scope
The Internet usage Guidelines and Procedure applies to all Internet users (individuals
working for the Organisation, including permanent full-time and part-time employees,
contract workers, temporary workers, business partners, and vendors) who access the
Internet through the computing or networking resources of Organisation
The Organisation Internet Usage Guideline applies equally to all individuals granted access
to any Organisation Information Resource with the capacity to access the Internet, the
intranet, or both
All sensitive Organisation material transmitted over external network must be encrypted.
Electronic files are subject to the same records retention rules that apply to other documents
and must be retained in accordance with departmental records retention schedules.
Incidental personal use of Internet access is restricted to Organisation approved users; it
does not extend to family members or other acquaintances.
Incidental use must not result in direct costs to the Organisation.
Incidental use must not interfere with the normal performance of an employees work duties.
No files or documents may be sent or received that may cause legal liability for, or
embarrassment to, the Organisation.
Storage of personal files and documents within Organisations Information Resources should
be nominal.
All files and documents including personal files and documents are owned by the
Organisation, may be subject to open records requests, and may be accessed in
accordance with this Guideline.
Internet connectivity presents the Organisation with new risks that must be addressed to
safeguard the facilitys vital information assets. Access to the Internet, by personnel, that is
inconsistent with business needs results in the misuse of resources. These activities may
adversely affect productivity due to time spent using or "surfing" the Internet. Additionally,
the Organisation may face loss of reputation and possible legal action through other types of
misuse
Access to the Internet will be provided to users to support business activities and only on an
as-needed basis to perform their jobs and professional roles. This procedure describes the
processes involved in the request, by employees for internet services and the approval for
such services by the requisite approvers in the ICT department at Organisation.
Internet access is requested by the user or users manager submitting an IT Access Request
form to the IT department along with an attached copy of a signed Internet usage Coverage
Acknowledgment Form
Access to the Internet will be approved and provided only if reasonable business needs are
identified. Internet services will be granted based on an employees current job
responsibilities. If an employee moves to another business unit or changes job functions, a
new Internet access request must be submitted within 5 days.
User Internet access requirements will be reviewed periodically by Organisation departments
to ensure that continuing needs are updated
Having reviewed the requirement, the ICT department shall proceed to grant access to a
user (giving the employee the requisite software, usernames and passwords) and shall
inform the user's manager of this approval
Internet access will be discontinued upon termination of employee, completion of contract,
end of service of non-employee, or disciplinary action arising from violation of this Guideline.
In the case of a change in job function and/or transfer the original access code will be
discontinued, and only reissued if necessary and a new request for access is approved.
All user IDs that have been inactive for thirty (30) days will be revoked. The privileges
granted to users must be re-evaluated by management annually. In response to feedback
from management, systems administrators must promptly revoke all privileges no longer
needed by users
13.5 Responsibility
These are people that are affected by this Guideline
Change the responsibility list
Role
ICT Department
Users Manager
User
Internal Audit
Responsibility
is responsible for maintaining this Guideline and
advising generally on information security controls.
Working in conjunction with other corporate functions, it
is also responsible for running educational activities to
raise
awareness
and
understanding
of
the
responsibilities identified in this Guideline.
is responsible for building, configuring, operating and
maintaining the corporate email facilities (including antispam, anti-malware and other email security controls) in
accordance with this Guideline.
is responsible for assisting users with secure use of
email facilities, and acts as a focal point for reporting
email security incidents.
is responsible for complying with this and other
corporate Guidelines at all times. This Guideline also
applies to third party employees acting in a similar
capacity whether they are explicitly bound (e.g. by
contractual terms and conditions) or implicitly bound
(e.g. by generally held standards of acceptable
behaviour) to comply with our information security
Guidelines.
is authorized to assess compliance with this and other
corporate Guidelines at any time
14 Organisation/ICT/02/01/14 - Anti-Virus
14.1 Description
A virus is a piece of potentially malicious programming code that will cause some
unexpected or undesirable event. Viruses can be transmitted via email or instant messaging
attachments, downloadable Internet files, USBs, and CDs. Viruses are usually disguised as
something else, and so their presence is not always obvious to the computer user.
It will also specify how files can get into the trusted network and how these files will be
checked for hostile or unwanted content.
A virus infection can be very costly to Organisation in terms of lost data, lost staff productivity,
and/or lost reputation. As a result, one of the goals of Organisation ICT Department is to provide a
computing network environment that is virus-free
14.2 Objective
. The purpose of this Guideline is to provide instructions on measures that must be taken by
the users to help achieve effective virus detection and prevention
14.3 Scope
This Guideline applies to all computers that are connected to the Organisation network via a
standard network connection, wireless connection, modem connection, or virtual private
network connection. This includes both Organisation-owned computers and personally
owned computers attached to the Organisation network. The definition of computers
includes desktop workstations, laptop computers, handheld computing devices, and servers.
In addition, all e-mail gateway providers must provide malware checking and protection for
email messages processed by the gateway.
The settings for the virus protection software must not be altered in a manner that will reduce
the effectiveness of the software.
The automatic update frequency of the virus protection software must not be altered to
reduce the frequency of updates.
Each file server attached to the Organisation network must utilize Organisation ICT
approved virus protection software and setup to detect and clean viruses that may infect file
shares.
Each e-mail gateway must utilize Organisation ICT approved e-mail virus protection software
and must adhere to the ICT rules for the setup and use of this software.
Every virus that is not automatically cleaned by the virus protection software constitutes a
security incident and must be reported to the User Help Desk (UHD).
The Organisation virus protection software shall be set to automatically pick updates from
the internet and shall be monitored daily to ensure the latest updates are installed
14.5 Responsibility
These are people that are affected by this Guideline
Roles
Responsibility
The following activities are the
1) The ICT Department is responsible for
responsibility
of
the
maintaining and updating this Anti-Virus
Organisation ICT Department
Guideline. Copies of this Guideline shall be
made available to all users in an
appropriate forum
2) The ICT Department will keep the anti-virus
products it provides up-to-date in terms of
both virus definitions and software version
in use.
3) The ICT Department will apply any updates
to the services it provides that are required
to defend against threats from viruses
4) The ICT Department will install anti-virus
software on all Organisation owned and
installed desktop workstations, laptops, and
servers.
5) The ICT Department will assist employees
in installing anti-virus software according to
standards on personally owned computers
that will be used for business purposes.
Users
6) Users shall
report all
incidences
suspected to be related to virus infection
15 Organisation/ICT/02/01/15 Back- up
15.1 Description
Backup is a copy of a program or file that is stored separately from the original. These
duplicated copies of data on different storage media or additional hardware resources are
used to restore the original after a data loss event. Backups are used primarily for two
purposes. The most common is to restore small numbers of files after they have been
accidently deleted or corrupted. The second is to restore a state following a disaster.
Backups are not archives and are not a substitute for record retention plans, nor are they, by
themselves, business continuity plans
15.2 Objective
This Guideline defines the backup for computer systems that store State data. These
systems are typically servers but are not necessarily limited to servers. Servers expected to
be backed up include file servers, mail servers, web servers, application servers and
database servers.
This Guideline is to establish the rules for the backup and storage of electronic information at
Organisation.
This Guideline is also designed to prevent the loss of Organisation data in the event of an
equipment failure or destruction
15.3 Scope
This Guideline applies to all Staff, permanent or temporary, and third parties who use ICT
devices connected to the Organisation network or who process or store information owned
by Organisation. All users are responsible for arranging adequate data backup procedures
for the data held on IT systems assigned to them
The back procedures in this Guideline apply to all Network Managers, System
Administrators, and Application Administrators who are responsible for systems or for a
collection of data held either remotely on a server or on the hard disk of a computer. ICT
department are responsible for the backup of data held in Organisation databases
This Guideline applies to:
i.
ii.
All data owners whose data is maintained on any of our central shared systems
iii.
The vendor(s) providing offsite backup storage for the Organisation must be cleared to
handle the highest level of information stored.
Physical access controls implemented at offsite backup storage locations must meet or
exceed the physical access controls of the source systems. Additionally backup media must
be protected in accordance with the highest Organisation sensitivity level of information
stored.
A process must be implemented to verify the success of the Organisation electronic
information backup.
Backups must be periodically tested to ensure that they are recoverable. This period shall be
set according to the criticality of the data backed up and the frequency of its change
Signature cards held by the offsite backup storage vendor(s) for access to Organisation
backup media must be reviewed annually or when an authorized individual leaves
Organisation.
Procedures between Organisation and the offsite backup storage vendor(s) must be
reviewed at least annually.
Backup tapes must have, at a minimum the following identifying criteria that can be readily
identified by labels and/or a bar-coding system:
i.
System name
ii.
Creation Date
iii.
iv.
All user information on the servers must be identified and scheduled for back-up in line with
the routine back up procedures based on the sensitivity classification.
All back-up tapes or medial shall be tested post the back-up exercise to confirm that all the
data has been adequately and completely backed up in cases of incremental back up.
All routine server back- up shall include server scripts and database scripts to ensure that in
cases on server failure the System Administrators are in a position to restore the server to its
last known good configuration including the data on the server.
Data backup
The ICT department recognizes that the backup and maintenance of the files for all
organisational servers, PCs (including application data files) are critical to the viability and
operations of the organisation. Therefore IT must put in place certain basic standard
practices be followed to ensure that data files are backed up on a regular basis.
Restoration
In-line with business requirements, ICT Department must put in place restoration procedures
and mechanisms and ICT Department shall test the backup & restoration plan to ensure that
the backup operation and media work as expected. The process of backup and restoration
shall be reviewed quarterly;
Regular verification of usability of back-ups;
v.
vi.
Restoration to the production and test environment will be formerly requested for and authorized
to ensure a consistent and predictable computing environment.
15.5 Procedure
Network Server Backups
The servers deployed in the Organisations Network have a backup tape device attached to
the server, or have access to a backup tape devices attached to another server in the local
network. The type of backup tape device varies with the model of the server and the volume
of data to be backed up.
Backup software on the network server is used to control the backup processes (e.g.
Windows NT Backup for Win Servers);
i.
ii.
Logs are maintained to verify the success backup process
Daily backups
iii.
The Logs shall be retained for a period of 7 days and be over-written on the 8th
day
Backup Contents
The contents of the backups vary with the server and location. The primary data that will be
backed up are:
Data files:
iv.
Transactional data, document files (like Word, Excel, PowerPoint, PDF, HTML
etc. and Images.)
v.
E-Mail data for all email accounts located on our E-Mail server.
vi.
System Data:
vii.
Applications files for the server and other selected software installed on the
server.
viii.
Daily Backups
ix.
Backups of data on production servers will occur every business day at 8:00PM
x.
Backup of the satellite labs environment on the branch servers will occur every
business day after end of day processes.
xi.
Daily backups (Monday Sunday) take place on a 1-week rotation; tapes overwritten on the 8th day
xii.
Monthly full backups of servers occur on the last day of every month and these
tapes shall not be rotated;
xiii.
Special backups may be made for longer retention periods before or after
system upgrades, major business projects, or for financial reporting periods.
xiv.
Tapes preceding service disruption events (such as power failures that could
lead to data loss, transaction stripping) shall be isolated and treated as special
backups for longer retention periods.
xv.
Incremental backup will be taken on the same cartridge at least twice a week.
Daily backups for days other than the current day will be stored in the safe at the
server room.
xvii.
Monthly Backups: Monthly backups for all network locations will also be moved
to an offsite location for long-term storage. The retention period for the monthly
tapes is as follows:
xviii.
A monthly backup will be kept for each month, for each server for a period of at
least 5 years.
xx.
A tape transfer log shall be appropriately signed off by staff responsible for
migration of the backup media to the organisations off-site storage location;
15.6 Responsibility
These are people that are affected by this Guideline
Roles
Responsibilities
ICT Department
doing the backups or delegating
15.7 Procedure
Below are guidelines of procedures and responsibilities for defined information and
communications technology (ICT) employees (i.e., system administrators, network
administrators). These guidelines will include a backup strategy that applies to the following:
i.
ii.
Implement standard frequency and type of backup for each type of computer
system or platform in use based on the significance of the information and its
frequency of change.
Backups should occur on a daily basis or be based on the significance of the information and
its frequency of change. A preferred method of backup is disk-to-disk backup. If this method
is not applicable for the system, then tape backup is required.
Back up all necessary data files and programs to recreate the operating environment.
Implement procedures for transferring a recent copy of backup media to a physically and
environmentally secure off-site storage location. An inventory and tracking system must be
maintained. Ensure that the following are stored at the off-site storage location:
iii.
Source and object code for production programs
iv.
Master files and transaction files necessary to recreate the current master files
v.
vi.
vii.
Ensure that documented procedures exist for the recovery and restoration of information
from backup media.
Identify I.T. staff responsible for ensuring successful back-ups.
Routinely copy operating software, application software, and production information to
backup media based on frequencies set by management. This applies to major systems
(e.g., local area network (LAN) or wide area network (WAN) servers, client/server database
servers, special-purpose computers) in use
Maintain at least three generations of backup media, i.e. grandfather, father, son
arrangement for operating and application software.
Define data model to be used for each type of data; i.e. full + incremental, full + differential,
(for file servers) or database exports or extracts (for applications)
Back up of the printed documentation and pre-printed forms necessary for recovery. Convert
printed documentation and pre-printed forms into electronic format and move them into the
DR site.
Test the backup to determine if data files and programs can be recovered
16.2 Purpose
To control access to information and information systems and to only provide access to
those who need it based upon a business requirement to perform their duties and functions.
This Guideline ensures that only authorized users are granted access to information
systems, and users are limited to specific defined, documented and approved applications
and levels of access rights.
16.3 Scope
This Guideline applies to entire information technology assets (computers and servers)
operating in Organisation and is intended for use by all Organisation employees, contract
workers or others who use the IT resources of Organisation, collectively termed User.
Users have responsibility to safeguard access to Organisation information assets that has
been entrusted to them. Each User shall be uniquely identified, properly authenticated and
properly authorized as required.
ii.
iii.
Access privileges shall be granted only to the minimum level required by the
users role, on principle of need-to-know and need-to-do basis in accordance
with users job responsibilities, business and security requirements.
iv.
The owner of the information resources and business application shall review the
access rights periodically (at least every six months.) for unused, redundant, or
expired user accesses or accounts, or incorrect privileges. Special attention
should be given to privileged access rights which allow users to override system
controls.
v.
vi.
The ICT Department shall ensure that such mechanisms prevent unauthorised
personnel, remote connections and other system (network) entry ports from
accessing computer resources and minimize the need for authorised users to
use multiple sign-ons.
vii.
ix.
Provide all users with a unique identifier (user ID) for their personal use only and
use a suitable authentication technique to substantiate the claimed identity of a
user.
x.
xi.
xii.
Strictly limit access rights, particularly those of temporary staff and contractors,
to a need-to-know basis that permits access only to the systems and resources
that are required for them to perform their duties.
xiii.
xiv.
Perform regular reviews of access controls and rights to all systems with
consideration given to level of sensitivity of the information processed by and
stored on the system.
xv.
xvi.
xvii.
Users must inform the ICT Department that they are to provide appropriate
protection (e.g., termination of active sessions, log-off from information systems,
activation of a screen saver, and preventing unauthorized access) of unattended
equipment.
xviii.
Users must be provided a written statement of their access privileges and verify
that they understand and agree to the conditions of access evidenced by their
signature.
xix.
16.5 Responsibility
Roles
ICT Department
All staff
Responsibilities
ICT Department of Organisation shall be
responsible for communicating and ensuring
compliance with this Guideline and its
supporting guidelines and procedures.
Additionally managers and Directors of
Organisation shall provide guidance and
decisions regarding granting and removing
access to Organisation information and
systems.
All Organisation related people (employees,
suppliers, trade, channel, and joint venture
partners) who are in possession of, or
control access to Organisation information
or systems covered by this Guideline shall
be responsible and accountable for its
protection in accordance with this Guideline,
supporting standards and procedures, and
any applicable national laws.
16.6 Procedures
Procedures addressing user access should cover all stages in the life-cycle from
initial registration of new users to de-registration once access is no longer required. The
Access control procedure at a minimum, shall consider adequate mechanisms for:
i.
ii.
iii.
iv.
v.
viii.
ix.
x.
xi.
All contract workers User IDs shall have an automatic termination date
consistent with the negotiated contract dates.
xiii.
The authorizing party will verify that the type of access requested is appropriate
for the users role and responsibilities.
xiv.
Users are provided a written statement of their access privileges and verify that
they understand and agree to the conditions of access.
xv.
xvi.
xvii.
xix.
xx.
xxii.
xxiii.
Privileged access is used only for system administrative tasks where such
access is required. Non-administrative tasks are performed through standard
user identities and privileges.
xxiv.
Privileged access is reviewed regularly to identify and remove invalid users and
accounts
Initialization of Passwords
xxv.
xxvi.
xxvii. Initial or temporary passwords are changed immediately upon their first use
Remote access procedure
xxviii.
Use of highly privileged IDs and utility programs / access to source code
xxix.
Compliance statements
xxx.
will
be
logged
and
audited
and
at
a. Access time
b. User account
c. Method of access
xxxii.
xxxiii.
All system and application logs must be maintained in a form that cannot readily
be viewed by unauthorized persons.
xxxv.
All logs must be audited on a periodic basis. Audit results should be included in
periodic management reports.
Unauthorized Access:
xxxvii.
Screen savers
xxxviii. Staff must make use of password protected screen savers or lock workstation
utility when PCs and terminals are left unattended and still connected to
the network or accessing applications.
17.2 Purpose
This Guideline aims at putting in place a framework for the handling and usage of removable
media in order to protect the information resource of Organisation. It is not meant to limit the
usage of such media but rather to enhance the safety of such usage
17.3 Scope
This Guideline covers the usage of removable media on all computers and servers operating
65 | East Africa Public Health Laboratory Network Project
in Organisation.
17.5 Responsibility
These are people that are affected by this Guideline
Roles
System Administrator
Responsibilities
1.Ensuring that users comply with the
removable media guidelines
2. Shall consistently monitor the
network for removable media related
risks.
Users
18.2 Purpose
To enable Organisation control all connections to its networks in order to preserve the
private nature of the Organisation's network and computing facilities
18.3 Scope
Network Access scope entails the following guidelines; The scope of these controls should
also be extended to allow only authorised access between the separate internal IT systems
within Organisation.
Application development
ii.
Operations
iii.
Extranet services
iv.
Network perimeter
Network Connection Control: The access capabilities of users connecting across the shared
network are limited to only those capabilities defined by their user privileges. Services,
whose degree of access is determined by the nature of the users network connection, are
identified, documented, and their access controlled. These services may include:
v.
vi.
vii.
Network Routing Control: The network routing from a users access point to the users
intranet destination ensures that the users network traffic remains within the network
segments and nodes for which the user has been authorized to use. The controls to achieve
this include, but are not limited to:
viii.
ix.
x.
Pre-defining the users network path in the applications, to prevent any user
intervention and eliminate the opportunity to explore the network.
Security Network Services: The owner of a network system or device is aware of its security
features and limitations. Appropriate measures shall be implemented to manage the risk of
the assets security limitations.
xi.
The security features and limitations of the asset are reviewed and documented
before the asset is deployed into production.
xii.
The asset is kept up-to-date with its respective patches and updates.
Concurrent network sessions: User access to the network shall be limited to only single login
session on the network. Multiple concurrent login sessions from more than one computer
terminal connected on the network is strictly prohibited and shall be enforced.
Internal Network Areas
xiii.
xiv.
All networks and network equipment must have a nominated owner and a
nominated management authority.
xv.
xvi.
xvii.
xviii.
xix.
xx.
xxi.
Tunnel end points are security gateways unless the networks at both ends have
identical security requirements and characteristics and must comply with the
Organisation's standards.
Network management
xxii.
xxiii.
xxiv.
xxv.
xxvi.
Management of a device must not offer the capability to introduce traffic through
that device to any connected end point.
xxvii.
xxviii.
xxix.
xxx.
The management protocol must ensure the integrity and, where appropriate,
privacy of all management commands and responses.
xxxi.
xxxii.
xxxiii.
xxxiv.
xxxv.
xxxvi.
Backbone core networks must include appropriately placed probes to detect illicit
addresses or protocols as determined necessary by risk.
xxxvii.
xl.
WEP must not be relied upon for transport integrity and confidentiality. The risk
to desktop devices visible on broadcast wireless networks must be managed
using WPA, anti-virus software and personal firewalls origination/destination
address.
xli.
xlii.
xliii.
xliv.
All third party wireless networks must be treated as the Internet and appropriate
controls must be applied.
Gateway Management
xlv.
xlvi.
All access to Organisation networks from public or third-party networks must only
take place through approved and authorised secure network gateways.
xlvii.
xlviii.
xlix.
Firewalls must perform proxy and address translation functions that will hide the
Organisation's network addressing structure and other directory information,
except for that which is required to support the service permitted by the firewall.
l.
li.
All access through an external channel must ensure that TCP/IP connections are
staged via a proxy device in each De-militarized Zone.
lii.
liii.
liv.
All data transfers with third parties must, where feasible, be initiated by
Organisation systems.
lv.
lvi.
A secure network gateway must only permit through connectivity for authorised
services/protocols to authorised destination network addresses.
lvii.
lviii.
lix.
Applications must be restricted to using a limited and defined range of ports for
connectivity through firewalls.
lx.
lxi.
lxii.
lxiii.
Routing controls must include controls to check the source and destination of
management traffic.
lxiv.
Traffic Isolation
lxv.
lxvi.
Connections over public/shared routed (e.g. IP) networks must take place over
encrypted Virtual Private Network tunnels.
lxvii.
The ability to make network connections must be controlled to ensure that the
external end of the connection is known.
lxix.
lxx.
lxxii.
lxxiii.
lxxiv.
lxxv.
lxxvi.
lxxvii.
lxxviii.
lxxix.
Where the other end of the connection is a single responsible user (e.g. dial up
or VPN), user authentication is sufficient where the Organisation can ensure that
the connection is only to that user, from only one workstation and that the
workstation is under Organisation control.
lxxx.
Firewall protection will provide a point of defence and a controlled and audited
access mechanism for all internal or external accesses to the
Organisations network. This audit access should be sufficient to detect breaches
of firewall security and attempted network intrusions.
lxxxii.
All traffic between the internal network and external access points must pass
through an authorised firewall.
lxxxiii.
All traffic within the different internal networks must be kept logically separate.
lxxxiv.
lxxxv.
lxxxvii. The default condition of the firewall should be to deny all connections to and
from the network. Only explicitly authorised connections should be allowed.
lxxxviii. All non-essential networking and system services must be eliminated or removed
from the firewall.
lxxxix.
xc.
Tight controls and close monitoring processes are to be applied to the on-going
management of an installed firewall, so that at any point in time it can be verified
that the firewall is effectively fulfilling its intended purpose. The verification of the
firewall integrity should be done at least once a month.
xci.
Firewall audit logs must be reviewed for firewall security breaches and attempted
network intrusions on a daily basis.
xcii.
xciii.
18.5 Responsibility
These are people that are affected by this Guideline
Roles
All User
ICT Department
ICT Department
Responsibility
Responsible for complying with this and other
corporate Guidelines at all times. This Guideline also
applies to third party employees acting in a similar
capacity whether they are explicitly bound (e.g. by
contractual terms and conditions) or implicitly bound
(e.g. by generally held standards of acceptable
behaviour) to comply with our information security
Guidelines
responsible for building, configuring, operating and
maintaining the corporate network and enforcing
security controls in accordance with this Guideline
responsible for assisting users with secure
connections to the network
19.2 Purpose
The purpose of this Guideline is to provide security guidelines that will govern
implementation of all third party connections made to or from the Organisation network to
ensure that connections between Organisation systems and networks and public switched
networks are permitted via secure network gateways.
19.3 Scope
A third party connection is any connection between Organisations network and a foreign
network owned by another person/Organisation not related to Organisation.
Within the scope of this Guideline, third party connections will refer to the following: Remote
Access via Dial In, Internet Remote Access, Website Administration and Maintenance,
Extranet, Internet Service Usage, WAN, LAN to LAN, Virtual Private Network (VPN
ii.
iii.
The physical and logical security controls used by the outside party to control
access to Organisations information assets are specified by the outside party
and approved by the appropriate Security Manager.
iv.
The processes used by the outside party to protect the availability, integrity and
confidentiality of Organisation s information assets are specified by the outside
party and approved by the appropriate Security Manager.
v.
vi.
viii.
The third party is granted the minimum degree of access required for its designated and
authorized purposes.
Vendors must not have access to the production environment unless explicitly authorised by
the ICT Department.
Organisation reserves the right to audit the activities and practices of the third partys access
Third parties connecting to or using Organisation facilities, systems, or data, comply with the
relevant Organisation security Guidelines and standards, as determined by the Security
Manager, before access is granted.
The Security Managers are responsible for the review and authorization of third party access
requests.
The third party is bound to conduct its business with Organisation consistent to
Organisations degree of ethical standards and professional conduct.
Third Party Administration of Access to Systems
ix.
x.
xi.
xii.
xiii.
xiv.
xv.
xvi.
All the requirements of Guideline regarding the monitoring of security and user
activity as well as the reporting and escalation of suspected or actual security
breaches must be applied to third-party administration of access to applications
and systems.
xvii.
xix.
xx.
The third-party and all its staff or agents engaged in the access must be
contractually bound to comply with the requirements of Organisation ICT
Guidelines and procedures manual.
xxi.
xxii.
xxiii.
xxiv.
xxv.
Where third-parties are given support access to the Organisation system that is
Internet connected, static IP addresses must be used for the third-party or
Organisation workstation so that network connectivity controls via IP address
filtering (such as at the Organisation 's firewall) can be maintained as granular as
possible.
xxvi.
xxvii.
xxviii.
xxx.
xxxi.
xxxii.
The contract governing the service must include an undertaking that none of
their staff or agents will access or attempt to access any system other than that
which they are contracted to support.
xxxiii.
xxxiv.
The logs showing the activities undertaken during third party access to the
Organisation system must be reviewed by the appropriate IT manager on
completion of the access and any unexplained activity discussed with the thirdparty immediately.
xxxv.
xxxvi.
All system logs used to record activity on the system must be secured against
access by the third-party.
xxxvii.
xl.
xlii.
xliii.
xliv.
xlv.
xlvi.
xlvii.
xlviii.
xlix.
l.
li.
lii.
Organisation critical third party hosted systems must be segregated from other
organisation's systems as determined by risk. Third parties must not enable
connectivity between Organisation systems and other organisation's systems
19.5 Responsibility
These are people that are affected by this Guideline
Roles
ICT Department
Contractor/ Vendor/ Visitor
Responsibility
Ensuring compliance with this Guideline and ensuring
that third party connections are vetted and approved
before they are accepted
It is the responsibility of each vendor or contractor to
ensure all external third party connections initiated
from within or remotely to Organisations local / wide
area network are secure, approved by ICT department
and do not expose the network to any threats that
compromise the confidentiality, availability and
integrity of Organisation data and information.
20 Organisation/ICT/02/01/20 - Password
20.1 Description
Security is an on-going responsibility, and appropriate measures must be taken on a regular
basis to ensure compliance and monitor effectiveness. Passwords are an important aspect
of computer security. They are the front line of protection for user accounts. A poorly chosen
password may result in the compromise of Organisations entire corporate network. As such,
all Organisation employees (including contractors and vendors with access to Organisation
systems) are responsible for taking the appropriate steps, as outlined below, to select and
secure their passwords.
20.2 Purpose
The purpose of this Guideline is to establish a standard for creation of strong passwords, the
protection of those passwords, and the frequency of change.
The application of these password rules and guidelines will ensure appropriate protection of
Organisation assets.
The effectiveness of this Guideline is entirely dependent upon passwords remaining
confidential at all times.
20.3 Scope
The scope of this Guideline applies to all systems and personnel who have or are
responsible for an account (or any form of access that supports or requires a password) on
any system that resides at any Organisation facility, has access to the Organisation network,
or stores any non-public Organisation information.
Should it be impossible to implement these specifications on a particular system, this must
be reported to security management.
20.5 Responsibility
Roles
ICT Department
Responsibility
Ensure that all user accounts have passwords on
them and the Guidelines governing password creation,
Roles
All Users
Responsibility
change and expiry are enforced
It is the responsibility of each user to adhere to the
guideline provided in this Guideline and to ensure
conformity to the set rules on password creation and
usage, avoiding sharing of passwords or writing them
down on papers for remembrance
ii.
Passwords must be given to users in a secure manner which limits the potential
for unauthorised interception.
iii.
The use of shared accounts is only permissible in exceptional cases and only
after consultation with IT security management and explicit approval of the ICT
Department.
iv.
v.
Passwords that are signed out, e.g. providing increased levels of access as
part of emergency production systems access must be changed immediately
after use. A record of use must be maintained by the designated owner and
available for audit
vi.
Password use
vii.
Passwords must not be recorded (e.g. paper, software file or hand held device)
unless this can be stored securely and the method of storage has been
approved
viii.
ix.
x.
Temporary passwords must be changed at the first logon and after a password
reset.
xi.
xii.
Passwords must not be included in any automated log-on process, e.g. stored in
a macro script, hard coded scripts, trouble ticket system or function keys unless
this can be stored securely and the method of storage has been approved by the
IT security manager or ICT Department.
xiii.
Passwords must not be inserted into email messages or other forms of electronic
communication.
xiv.
The same password must not be used for Organisation accounts as for other
non- Organisation access (e.g. personal email account, option trading, benefits,
etc.). Where possible, don't use the same password for various Organisation
access needs. For example, select one password for the Finance systems and a
separate password for IT systems.
xv.
xvi.
xviii.
xix.
xx.
xxi.
xxii.
Passwords set for system IDs (e.g. to facilitate file transfers or authenticate
background system tasks) do not have to change at regular intervals but in
mitigation of this, password construction must abide by the rules set out for
Administrator Ids as specified in the Password selection rules procedure.
xxiii.
xxiv.
xxv.
xxvi.
Passwords must not be displayed in readable text on the screen at any one time,
particularly when being entered.
xxvii.
xxviii.
xxix.
xxx.
Users must not use the Save Credentials option when logging in to either
applications or web pages.
xxxi.
Passwords which have been used and then changed can only be used again
after 12 password changes. For administrators, this must be at least 13 different
passwords to prevent annual cycles. If this is not possible, then minimum life
xxxiii.
xxxv.
The password must contain a mixture of at least one character from 3 of the 4
sets of permissible characters described below:
a. Contain a upper and lower case characters (e.g., a-z, A-Z)
b. Numerals 0-9
c. Special characters created
d. Special characters created using the shift function (e.g. &; %, ?; ; $; etc)
xxxvi.
xxxvii.
Good Passwords
a. Good passwords are those that can still be remembered despite the
proscribed guidelines yet which are not difficult to replace at the end of
each 90 day period.
Good practice:
Select a saying like
Humpty Dumpty sat on a wall
This produces the following password
HDsoaw
Break up the character sequence using numbers and/or special
characters:
H%Dsoa&w
xxxviii. Good passwords have the following characteristics:
a. Are at least fifteen alphanumeric characters long and is a
passphrase (No0neHas29Fl0wers).
b. Are not a word in any language, slang, dialect, jargon, etc.
c. Are not based on personal information, names of family, etc.
d. Passwords should never be written down or stored on-line.
e. Try to create passwords that can be easily remembered. One way
to do this is create a password based on a song title, affirmation,
or other phrase. For example, the phrase might be: "This May Be
One Way To Remember" and the password could be: "TmB1w2R!"
or "Tmb1W>r~" or some other variation.
xxxix.
Bad passwords
Don't reveal a password over the phone to ANYONE. This also applies to
enquiries made by IT support
xli.
xlii.
xliii.
xliv.
xlv.
xlvi.
xlvii.
xlviii.
If someone demands a password, refer them to this document or have them call
someone in the IT security manager.
xlix.
If you want to use personal questions to help you remember your password, so
with care. Bad example: Whats my wifes last name?
l.
li.
Again, do not write passwords down and store them anywhere in your office.
lii.
Do not store passwords in a file on ANY computer system (including Black berry
or similar devices) without encryption.
liii.
If you keep a list of password, please keep in mind that this should be stored in a
safe place. As a matter of principle, this information must be stored separately
from the access media used
liv.
Do not choose a name for the list that reveals its contents (e.g. passwordlist.xls).
Passphrases
lvi.
lvii.
lviii.
NOTE: All of the rules above that apply to passwords apply to passphrases.
Database password standards
lix.
lx.
lxi.
21.2 Purpose
To ensure that ICT take appropriate measures designed to safeguard the physical perimeter
of Organisation facilities that house ICT information assets.
To protect Organisation's computing facilities from physical harm.
To provide guidance in the protection of restricted areas using control technologies to
prevent unauthorized access attempts
21.3 Scope
This Guideline applies to Organisation facilities that physically house information and
technology assets and covers server room access and Health Laboratories, movement of
computer equipment, network cabling and set up of server room. Access control Guideline
shall be applicable to all employees, contractors and visitors.
ii.
Security perimeters shall be clearly defined, and the siting and strength of each
of the perimeters shall depend on the security requirements of the ICT assets
within the perimeter and the results of a risk assessment;
iii.
iv.
v.
Physical security for offices, rooms, Health Laboratories and ICT facilities must
be designed and applied.
vi.
ICT buildings housing computing systems such as server rooms, data centres,
Health Laboratories shall be unobtrusive and give minimum indication of their
purpose, with no obvious signs, outside or inside the building identifying the
presence of information processing activities;
viii.
Visitors who are at the Organisation for multiple days must follow all procedures
associated with this Guideline on each day of their visit. Longer term contractors
can be sponsored for a photo-ID badge.
ix.
All requests by groups for tours of ICT facility will be referred to the ICT
Department and/or the Human Resources/Administration Department for
handling as an exception.
Physical protection against damage from fire, flood, earthquake, explosion, civil
unrest, and other forms of natural or man-made disaster shall be designed and
applied commensurate with the identified risks.
Supporting utilities
xiv.
Equipment must be protected from power failures and other disruptions caused
by failures in supporting utilities. In case of such failure, a minimum level of
functioning must be guaranteed
Cabling security
xv.
Equipment maintenance
xvi.
integrity
Security of equipment off premises
xvii.
Security must be applied to offsite equipment taking into account the risks of
working outside Organisation premises.
xviii.
All employees using Organisation issued laptops must ensure that the laptops
are securely locked using physical Kensington locks when unattended.
All items containing storage media must be checked to ensure that any sensitive
data and licensed software has been removed or securely overwritten prior to
disposal
21.5 Responsibility
Enforcement of this Guideline falls to these offices as indicated in this document.
Administration of the Check-In / Check-Out procedure is the responsibility of identified
individuals in each facility. In most facilities it is a duty of the main Reception Desk.
Roles
All users
Responsibility
Enforcement of this Guideline falls to the organisation as
indicated in this document. Administration of the Check-In /
Check-Out procedure is the responsibility of identified
individuals in each facility. In most facilities it is a duty of the
main Reception Desk.
The date and time of entry and departure of visitors shall be recorded, and all
visitors shall be supervised unless their access has been previously approved;
they shall only be granted access for specific, authorized purposes and shall be
issued with instructions on the security requirements of the server room and on
emergency procedures.
ii.
iii.
Keypad access codes used for physical access to server rooms and equipment
rooms must be unique and changed on a quarterly basis.
iv.
Log books of access to server rooms and equipment rooms and records from
access control systems must be kept secure and archived for six months.
v.
All employees, contractors and third party users and all visitors must be required
to wear some form of visible identification and should immediately notify security
personnel if they encounter unescorted visitors and anyone not wearing visible
identification within the server room or ICT premises;
vi.
vii.
Access to the server room must be restricted on a need-to-use basis. Any other
person entering the room must sign the Server Room Access Log giving details
like name, time in, time out, reason for entry, accompanied by, date, etc. This
Guideline includes ICT staff, visitors and contractors like the maintenance team
from suppliers.
viii.
ix.
x.
There shall be no clear directions to the server room for outsiders to follow.
xi.
xii.
All equipment and consumables that are taken in or out of server room and
computing facilities must be inspected by local physical guarding staff or agents
and must be signed off in the inventory by the ICT Department or a delegate.
xiii.
Keypad access codes used for physical access to server rooms and equipment
rooms must be unique and changed on a quarterly basis.
xiv.
Access passes, cards, keys or other tokens for entry into server room or
equipment rooms must be retrieved from staff, agents or third-parties when their
employment or contract ceases. Key codes must be similarly changed if known
to departing personnel unless the facility and its access points are guarded 24
hour a day.
xv.
xvi.
Line managers must inform server room or equipment room (e.g. LIS/HIS)
managers when an employee no longer has a business need to access a facility.
xvii.
Visitors requiring access to server rooms controlled by swipe card access locks
should arrange temporary cards with their sponsor. These cards are limited to
activation windows of 24 hours.
The server room must not be used as an office for day to day work
xix.
Power supply to the server room must provide for three lines of defence for
backup power: multiple feeds from the public utility; UPS service to provide a
minimum of 20 minutes of backup power; and, diesel generators to sustain
power for longer-term outages. The UPS and, backup diesel-powered
generators are crucial to maintaining a constant flow of power in the event of
a power failure from the public utility.
xx.
The UPS should be sized to energize all computer equipment, HVAC systems
and other electrical devices (such as emergency lighting and security devices)
for 100 per cent of the power demand for no less than 15 to 20 minutes after a
power interruption.
xxi.
Backup generators and UPS provided for Server room and equipment rooms
must be tested regularly in accordance with the manufacturers instructions and
not less than once a month
xxii.
xxiii.
Provide maintenance and emergency shutdown switches at all entry points in the
facility. Staff working in Server room and equipment rooms regularly must be
instructed in how and when to use this switch
xxiv.
xxv.
xxvii.
The server room must have CCTV cameras installed with minimal blind spots to
monitor the server room at all times
xxviii.
xxix.
xxx.
The server room floor must have raised floor systems 12 inches for less than
1,000 square feet; 12 to 18 inches for 1,000 to 5,000 square feet; 18 to 24
inches for 5,000 to 10,000 square feet; and 24 inches for more than 10,000
square feet.
xxxi.
The server room shall be fitted with moisture detectors and water proof covers of
the appropriate class or category.
xxxii.
Server rooms and equipment rooms must be fitted with suitably located smoke
and heat detectors at regular spacing to warn of developing fire hazards.
xxxiii.
Hand-held fire extinguishers must be located outside all server room and
equipment room doors and at suitable regular points throughout the facility.
xxxiv.
Local fire and emergency service agencies must be made aware of the location
of all server room and equipment rooms through prior agreements that include
provision for suitable electrical fire fighting equipment, remote alarming,
response procedures, staff registers and false alarm notification procedures
xxxv.
Staff or agents who regularly undertake work in Server room and equipment
rooms must be trained in the use of personal safety and evacuation procedures,
including the use of the fire extinguishers provided and those appropriate for use
on electrical equipment
xxxvi.
Emergency alerting facilities within Server room and equipment rooms must
include provision of a telephone allowing direct external access that would be
functional in the event that main telephone switches become unusable
xxxvii.
All fire detection, alarming, protection and suppression facilities used to protect
Server room and computing equipment rooms, including detectors, alarms,
dampers, sprinklers, gas suppressors, portable extinguishers and fire barriers,
must be tested on a quarterly basis
xxxviii. Server room and equipment rooms must be kept organised and tidy at all times
to comply with fire and safety regulations and insurance requirements
xxxix.
Selectively position perforated tiles in the raised floor to direct chilled air into the
rack area.
xl.
Flood control valves shall be fitted on the raised floor in case of flooding.
xli.
The server room shall be fitted with a fore proof door and wall panels designed
to with stand fire for at least 2 hours.
xlii.
xliii.
xliv.
xlv.
xlvi.
xlvii.
Server room must be fitted with a central and remote alarm routing facility that
will trigger at a suitable fire an emergency service office so that dispatch of
emergency services can be expedited.
xlviii.
xlix.
li.
lii.
liii.
liv.
lv.
Data centres must be provided with at least two independently routed trunk
communications links to carrier networks to avoid a single point of failure in
communications
lvi.
Network cabling must be swept for unauthorized attached devices at least once
every 3 months.
lvii.
lviii.
lix.
lx.
21.7 Procedures
ICT Equipment movement procedures
SCOPE: This process applies to ICT equipment that is taken off Organisation premises.
i.
The individual intending to take ICT equipment off Organisation premises fills out
the gate pass with the necessary information and hands it over to his/her
manager/supervisor for approval.
ii.
After the managers approval, the individual intending to move the property
makes two copies of the gate pass.
iii.
At the security office, the individual moving the ICT equipment hands a copy of
filled out gate pass to the security officer who crosschecks the details on the
form against the physical item(s) being transferred.
iv.
If items are being taken out of the warehouse or storage, an approved requisition
form should be attached.
v.
If the details on the gate pass do not correspond with the items being moved, the
individual is asked to return to the security office with a correctly filled and duly
approved gate pass for the items he/she intends to takes out
vi.
If the details on the gate pass correspond with the items being moved, the
security officer endorses all the gate passes, retains the security offices copy
and hands over the other two copies to the individual who ensues to the gate.
vii.
The copy of the gate pass left at the security office is filed for future reference.
viii.
ix.
At the gate, the gate pass is given to the guard who crosschecks the details on it
with the item(s) being taken out. If all the items being taken out are indicated on
the signed gate pass, the individual is allowed to take the item(s) off
Organisation premises.
x.
If some of the items being moved are not indicated on the signed gate pass, the
individual is asked to fill out a gate pass for the extra items. Only the items
indicated on the duly signed gate pass are allowed off Organisation premises.
xi.
Follow up is made by the security office to ensure that the items were received at
the intended destination. If the items were not received, an inquiry is made into
the matter.
xii.
For items that are being delivered to Organisation premises, on arrival, the gate
pass is handed over to the security officer/guard who crosschecks the details on
the gate pass against the items delivered.
xiii.
If all the items indicated on the gate pass have been delivered, the security
officer endorses all the copies of the gate pass and allows the items to be
brought into Organisation premises.
xiv.
A copy of the gate pass is retained by the resident security officer at the
destination.
xv.
If more items are delivered compared to the number indicated on the gate pass,
the deliverer is asked to obtain a duly signed gate pass for the extra items
xvi.
If fewer items are delivered compared to the number indicated on the gate pass,
the deliverer is asked to present all the missing items. If he or she fails to do so,
the matter is reported to their supervisor so that disciplinary action can be taken.
xvii.
The recipient of the items signs on the delivery note to acknowledge receipt.
When entering Organisation ICT premises, all staff members should clearly
display their identification cards.
xix.
The staff member places his/her luggage including all metallic items in his/her
possession onto the tray/table next to the metal detector and walks through the
detector.
xx.
If the employee doesnt activate the metal detector, his/her luggage is searched
to ensure that harmful items arent being brought in illegally.
xxi.
xxii.
xxiii.
If the employee activates the metal detector, he/she is asked to put any other
metallic objects on him/her on to the tray/table next to the metal detector and
after the removal of such objects, the employee walks through the metal detector
a second time.
xxiv.
xxv.
xxvi.
xxvii.
If anything suspect is detected, the staff shows the object to the guard.
xxviii.
If the staff refuses to show the suspect object to the guard, he/she should be
If it is a harmful object, the employee is detained by the security guard while the
security team is informed.
xxx.
The employee is handed over to the security team or ICT director so that
disciplinary action can be taken.
xxxi.
xxxii.
xxxiii.
If the employee still refuses to be searched, inform the security team so that the
situation can be resolved.
xxxiv.
If the employee has successfully completed the search procedure and is carrying
an Organisation laptop, it is recorded at the reception.
xxxv.
Private laptops for employees are prohibited from entering Organisation ICT
premises; these are left in the custody of the security guard at the reception. In
cases where private laptops enter the organisation premises they shall be
logged with the security and their serial numbers recorded. The usage of the
private laptops for organisational work shall require authorisation from
management in-line with Network access guidelines and user access guidelines.
xxxvi.
xxxvii.
the
employee
proceeds
to his/her
xxxviii. If an employee is carrying luggage that the guard has deemed suspicious, the
employee is asked to hand over this luggage to a guard who will search it in
order to ensure that no Organisation property is exiting Organisation premises
illegally.
xxxix.
xl.
xlii.
The visitor places his/her luggage including all metallic items in his/her
possession onto the tray/table next to the metal detector and walks through the
detector.
xliii.
If the visitor doesnt activate the metal detector, their luggage is searched to
ensure that harmful items arent being brought in illegally.
xliv.
xlv.
If the visitor activates the metal detector, the security guard inquires whether
he/she has any other metallic objects on him/her and after the removal of such
objects, the individual walks through the metal detector a second time.
xlvi.
If the visitor doesnt activate the metal detector the second time, their luggage, is
searched to ensure that harmful items arent being brought in.
xlvii.
xlviii.
If a harmful item is found in the visitors possession, he/she is detained while the
security team is informed so that disciplinary action can be taken.
xlix.
l.
li.
lii.
If anything suspect is detected, the visitor shows this item to the guard.
liii.
liv.
If the visitor refuses to submit to a search, inform him/her that he/she will not be
allowed to proceed unless he/she submits to the search.
lv.
If the visitor remains resistant to the search, he/she should be escorted off
Organisation ICT premises or site.
lvi.
If the visitor has successfully completed the search procedure and is carrying a
laptop, it is recorded at the reception.
lvii.
At the reception desk, the visitor identifies him/herself and notifies the
receptionist of where he/she intends to go and whom he/she intends to visit.
lviii.
The receptionist calls the host in ICT department to confirm if he/she is expecting
the visitor.
lix.
If the host in ICT agrees to receive the visitor, the visitor is given a visitors card
and their identification card is retained at the reception.
lx.
lxi.
lxii.
lxiii.
When the visitor intends to leave Organisation premises, he/she hands over the
visitors card to the receptionist and signs in the visitors book; his/her
identification card is given back to him/her.
lxiv.
lxv.
The visitors luggage is searched to ensure that Organisation property isnt being
taken off Organisation premises without the proper authorisation.
lxvi.
If no Organisation property or ICT equipment is found, the visitor signs out in the
lxviii.
lxix.
The employee or visitors sponsor submits signed request for access to server
room by completing a server room access control form stating the reason,
duration and proposed timing of the visit.
lxxi.
lxxii.
lxxiii.
The system administrator or authorised staff with access rights to the server
room escorts the staff or visitor to the server room
lxxiv.
Both the system administrator, escort and the visitor/escorted persons sign the
data server room access log book indicating time, date and reason for entry.
lxxv.
The system administrator or designate must be present at all times when the
visitor is in the server room
lxxvi.
Once the purpose for the visit has been accomplished, the staff/visitor will sign
out of the visitors log book.
lxxvii.
22.2 Purpose
To implement formal change management control procedure that protects Organisation
information assets and to ensure that the change management procedure is used for efficient,
planned, authorised and prompt handling of all changes, in order to minimise the impact of any
related incidents upon service.
22.3 Scope
This Guideline addresses the definition and documentation of Organisation information assets
change management control procedures.
This Guideline applies to normal and emergency changes that affect Organisations information
technology systems, hardware, software, systems infrastructure including network, and
databases, and all documentation and procedures associated with the running, support and
maintenance of live systems.
For the purposes of this Guideline, the term changes to Organisations information systems will
include but is not limited to the following categories of changes:
i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
Problem fixes
ix.
Functionality enhancements
Separation of Development and operational facilities: The Development, Test and Operational
facilities / environments shall be physically and/or logically separated
Transfer of software between the development test and operational environments shall be
subject to authorization and approval by the ICT Department as per the specific procedures to
be developed and implemented for this purpose.
22.5 Responsibility
These are people that are affected by this Guideline.
Role
Change Requester
Description
This is the staff member or
department requesting the
change /modification of a system
or environment, The Requestor
submits the request for change
Change authoriser This individual should confer with
other individuals as necessary to
come to a conclusion on the
appropriateness of the change
Change Control
The staff member responsible for
officer/Implementer administering change control in
the ICT department.
Change Approver
The staff responsible for
analysing the change and
approving or rejecting the
request.
Responsibility
This person will be the user or
business process lead
Business/Systems Owner
22.6 Procedures
This section describes the procedures by which all changes to facility equipment or controls are
proposed, approved and implemented. It encompasses the initiation of a proposed change, the
process by which the proposed change gains management approval, and the procedure by
which the approved changes are controlled during the subsequent design, implementation and
commissioning phases. It also outlines what constitutes a change requiring the use of this
procedure.
Create the Request for Change: The change request will be created by the change Initiator
using a request for change (RFC). Some information shall be recorded directly on the RFC
form and details recorded in other documents and referenced from the RFC, such as impact
assessment reports. The RFC form shall be kept simple in order to encourage compliance with
the process. The changes shall be classified as one of the following;
i.
Normal change
ii.
iii.
iv.
Emergency change
With the assistance of the Change manager and subject matter experts, all the
procedures for preparation, installation, verification, and back-out shall be
documented in detail. Impact and risk analysis of the change shall also be recorded, in particular
the worst-case impact, analysing the situation of a failed change and a failed back-out
procedure.
Review, Assess and Evaluate the RFC: A Change Approval Board (CAB) shall be constituted by
the Change Manager and it (the CAB) shall consider each request and filter out any that seem to
be Totally impractical, Repeats of earlier RFCs, Incomplete submissions, such as those with
an inadequate description, or without necessary budgetary approval or justification, These
shall be returned to the
initiator, together with brief details of the reason for the rejection, and the log shall record this
fact.
During this phase, there shall be a check of the following aspects of the proposed change Correctness of all technical information, including preparation, implementation,
verification, and back-out procedures, Completeness of change, testing procedures, and
documentation, Feasibility of the change, Potential side
effects and impact on other services or infrastructure, Worst-case impact (both change and backout procedure fail) This review shall be facilitated by technical subject matter experts coopted by the CAB familiar with the area affected by the change.
The potential impact to services and service assets and configurations shall be fully considered
during this phase. When conducting the impact and resource assessment
for RFCs referred to them, the CAB shall consider relevant items, including;
v.
The effect of not implementing the change,
104 | East Africa Public Health Laboratory Network Project
vi.
vii.
viii.
Impact
x.
Urgency
xi.
Risk
xii.
Benefits
xiii.
Costs
The CAB will use the following simple matrix to categorize risk.
Impact
High Impact
Low Probability
Low Impact
Low Probability
High Impact
High Probability
Low Impact
High Probability
Probability
The priorities of proposed changes shall be established based on the assessment of the impact
and urgency of the change. Initial impact and urgency will be suggested by the change initiator
but may be modified in the change authorization process.
Impact shall be based on the beneficial change to the business that will follow from a successful
implementation of the change, and on the degree of damage and cost to the business due to
the error that the change will correct. The configuration Manager will be responsible for
performing a baseline assessment of the IT environment. The CAB will use this baseline
assessment in evaluating the impacts of a change.
The urgency of the change shall be based on how long the implementation can afford to be
delayed. Below are the IT Change Priority descriptions
Priority
Immediate
Treat as emergency change
High
To be given highest priority for
change building, testing,
and implementation resources
Corrective Change
Putting operations at risk. Causing significant loss of
revenue or the ability to deliver important services.
Immediate action required.
Severely affecting some key users, or impacting on a
large number of users.
Medium
Low
Change Organisation
XXXXXX
Emergency CAB
CAB
ICT Department
xvi.
xvii.
CAB and supervised by the Change Manager to confirm that the change has met its
objectives, that the initiator and stakeholders are happy with the results, and that there
have been no unexpected side effects. Lessons learned shall be factored into future
changes.
Close the Change
The change manager shall close the change by signing off at the RFC (Request For Change)
Form section application of closing changes and the sign off will be documented in the
configuration database by the CMDB Manager. It is important to note that every step of the
change process and every status change of the RFC must be documented in the configuration
database. The change success, failure, related plans shall be communicated to all
stakeholders (Initiator of the change, ICT Department, heads of Business units affected and
head of the operation division) by the Change manager on behalf of the CAB.
A critical application error is reported to ICT. This error is documented and recorded
through ICT Help desk.
ii.
ICT Help desk will assign the problem to a Senior Owner Department staff member
for immediate action.
iii.
The developer creates a fix or work around for short term resolution of the problem.
iv.
The short term fix will be submitted to operations for immediate implementation in
the Test environment.
v.
Operations will immediately migrate it to Test and inform the software development
that it has been migrated.
vi.
The developer will immediately test the fix to ensure that it works as desired.
vii.
Upon successful testing, the developer will report to ICT Department that the
change is ready to implement, and will obtain verbal approval to proceed.
viii.
ix.
Operations will immediately migrate it to Production, and will inform the developer
that it has been migrated.
x.
The developer will immediately test the change in Production to validate that the
problem has been corrected.
xi.
If the change does not fix the problem, or it creates a new problem, Operations will
If the change fixes the immediate problem, the developer will record the details of
the change made, and will initiate a formal Change Request (RFC) for a more
detailed and thorough review and correction of the problem. This will initiate the
normal change control process.
xiii.
23.2 Objective
To provide for the tracking of computing resource activity that will benefit the disclosure of
unauthorized activity.
To ensure that the security status of Organisation is known and understood by those who are
responsible for maintaining that security.
To provide a mechanism to retrieve and report information on logged events; and
To allow reporting on the effectiveness and compliance to systems security requirements.
To identify suspected or actual misuse or abuse and enable the enterprise to respond before
serious damage is done.
23.3 Scope
The tracking of security related events and the data logs produced by the tracking mechanisms
23.5 Responsibility
Each System owner is responsible for ensuring he / she fully implements the principles and
procedures as set forth in this Guideline.
Roles
All Users
Responsibilities
All Organisation users (employees, customers,
suppliers, and business partners) who are in
possession of, or control access to
Organisation information or computers
covered by this Guideline are responsible and
accountable for its protection in accordance
with this Guideline and supporting guidelines
and procedures.
23.6 Procedure
Logging procedure
i.
On a daily basis:
The IT security manager will liaise with the business unit manager or system
owner to set up the respective system to log the following security events on a
daily basis:
a. All security violations, such as System access denied, Invalid password,
Invalid security certificate, Password revoked, and Resource access
denied
b. All accesses to sensitive/significant areas of the systems.
c. All security commands issued using the security administrative authority.
d. All accesses to operating system resources, with the exception of the
default access. If the resources can be read publicly, record the update or
allocation and deletion of access
e. Successful connections;
f.
j.
should not result in the loss of the audit trail or identity of the user.
The following information must be logged for each securityrelated event that occurs within
each application or infrastructure environment:
ii.
iii.
iv.
v.
vi.
vii.
The following changes to users access control and rights that may occur within each application
or infrastructure environment must be logged:
viii.
Creation of a user profile;
ix.
x.
xi.
xii.
xiv.
Unsuccessful login;
xv.
xvi.
xvii.
xviii.
The following changes to the operation or content of the security audit log that may occur must
be logged:
xix.
Change to auditable events;
xx.
xxi.
xxii.
xxiii.
Logon Monitoring
xxiv.
A user event logging system shall contain at a minimum the following information:
a. User ID
b. Dates and times of logon and logoff.
retained for a defined period of time; this time period must be consistent
with relevant local legal and regulatory requirements, and business and
operational requirements.
24.2 Objective
To Ensure Management, permanent and temporary employees and contractors of Organisation
are aware of the appropriate use of software, the inherent risk of using pirated software and
caution them against practices that can result to infringement of software license and copyright.
24.3 Scope
This Guideline applies to all software including server and client operating system software,
application software, custom developed software and utility software, not only to any original
installation but also to any upgrades to later versions of the software, which must also be
properly licensed
Department in consultation with the ICT Department to ensure that all applications conform to
corporate software standards. All requests for corporate software must be submitted to the
Departmental head for approval. The request must then be sent to the ICT, who will then
determine the software that best accommodates the desired request.
The ICT department is exclusively responsible for installing and supporting all software on the
Organisations computers.
Most of the software titles on organizations current software list are not freeware; therefore, the
cost of software is a consideration for most titles and their deployment. It is the goal of the ICT
department to keep licensing accurate and up to date. The ICT department is responsible for
purchasing software licenses in liaison with the Finance and Administration Department
All software used for or on behalf of Organisation shall be correctly and appropriately licensed
and used only in conformity with the terms of the license, whether the usage is on hardware
belonging to Organisation or not.
No staff member, contractor or agent working for or on behalf of Organisation shall copy and/or
install software onto any Organisation computers without prior electronic or written approval
/confirmation from the person(s) nominated by ICT Department.
It is the responsibility of the ICT department to ensure that Organisation has the
necessary software licenses for all software installed or authorised to be installed on
Organisations computers or computers used by Agents or Contractors conducting business on
behalf of Organisation.
All copies of any illegal software installed by employees on Organisation computers shall be
uninstalled immediately. This includes legally purchased software that has not approved in
writing or in electronic format by the Organisation ICT management.
once it is delivered to Organisation to provide assurance that the security of functionality has not
been compromised by another party during development.
Open Source Software (OSS) is software whose source code is openly published, is often
developed by voluntary efforts and is usually available at no charge under a license defined by
the Open Source Initiative which prevents it from being redistributed under a more
restrictive license. OSS is also subject to the requirements and restrictions stipulated in this
software Guideline and govern its acquisition and use within Organisation
All purchased, pre-developed and packaged software acquired for use within Organisation must
be subject to the same security controls as bespoke software.
All packaged software acquisitions must be subject to a formal risk analysis to determine the
necessary security requirements derived from Guideline.
Security requirements must have been produced, at least in draft form, and used as part of the
selection process before packaged software is acquired for use in Organisation.
Where all purchased software functionality does not fulfil the security requirements derived from
Guideline for a specific application or infrastructure and the vendor is unable to modify to
comply then the standard process for the granting of a Risk Acceptance by the business owner
or a Guideline Dispensation must be adhered to.
Contracts for the purchase of pre-developed packaged software or for the development of
software by third parties must provide clarity and protection of Organisation rights over
licensing, ownership of code, escrow access to source code and intellectual property.
All packaged application software must be screened for viruses prior to distribution and
installation; all such software must be operated in an environment that is protected by a full
implementation of Organisations standard Anti-Virus controls.
All third-party software used in business applications (or as part of an associated business
process) must be from reputable sources whose reliability, legal status and past performance
has been verified. The use of unsupported or non-marketed software, such as freeware or
shareware, must not be made without a source code review.
All third-party software used in business applications (or as part of an associated business
process) must be properly designed for the use to which it is applied and must be properly
licensed for its use within Organisation from the originator, vendor or their agent(s). All
associated intellectual property or copyright must be respected at all times during its use or
exploitation within Organisation.
All proposed software into the Organisation ICT environment should have a supported business
case and such a business case should be approved by the user department head and the ICT
Department
No pirated software, i.e. computer software which one possesses illegally, is permitted to be
used either on Organisation's computer or on Personal computers for Organisations business.
When implementing Commercial off the shelf solutions, similar considerations should be part of
the evaluation. The functional requirements of a system should:
i.
Document the process of the process flow for the automated process
ii.
Should specify the competencies and roles that are required to complete the
process.
iii.
Specify the key performance indicators required for the process to be completed
iv.
Specify the key inputs and expect outputs for each process
Only trained and experienced programmers shall be allowed to develop or customise internally
developed software.
Regarding outsourced software Organisation shall ensure that competent and approved
development and customisation team shall work on the project.
Prior to the implementation of new or upgraded information systems, care should be taken to
ensure that all requirements for acceptance have been met.
24.5 Responsibility
Roles
Software developers (Vendors)
Responsibilities
Shall be responsible for building of
supplying the software in accordance
with the general software guidelines and
related software development guidelines
Shall comply with the guideline and
ensure that they only used approved
software on their computers
Management of software in accordance
with the software guidelines
24.6 Procedure
The following is the procedure that shall apply in the acquisition of software
User department will present a business case for the new software
Conduct a feasibility study or business case validation for the request for new software.
Business case is approved by Director of ICT and User Department or shall be rejected and
sent back to the user department for additional information.
Once business case is approved Software development section shall validate the requirements
and assess whether Organisation has the capacity to develop the software in-house.
If Organisation does not have the capacity to develop the software, the software will be
acquired through tendering from external vendors who will be responsible for providing an off
the shelf package.
Detailed requirements for the software will be developed and such requirements will include
functional, technical and security.
The requirements will be approved by the Software development section head, ICT Department
and the head of the user department.
For both in-house development and external or outsourced development/customisation design
for the system shall be documented outlining the software architecture and functionality.
Once the solution design is completed the design shall be approved by the ICT Department,
Software development section head and the vendor head if the software is outsourced.
The software shall be developed by either the Organisation internal team or the vendor based
on the solution design.
Once completed the software shall be tested by the user department and approved by the user
department head and head of software section and ICT Department.
If the software does not meet user requirement is shall be reverted back to development for
further customisation or developed
The software shall be licensed and handed over to the user for usage.
25.2 Objective
To ensure that quality standards are implemented when acquiring computer hardware and
software for usage within the Organisation environment.
This Guideline would ensure that quality standards are observed by all Organisation ICT
department personnel when they acquire and introduce new hardware, software and network
equipment into the Organisation operating environment
25.3 Scope
This Guideline applies to the acquisition of new hardware, networking and software within
Organisation ICT environment
This applies to all software, network and hardware and ICT related projects.
The vendor should be able to offer support for the software post the implementation of the
software.
All software applications should have a licensing agreement that is consistent with the Software
Guideline
A knowledge transfer plan should be developed and approved in the acquisition process to
ensure that internal staff develops the capacity the support the software, hardware and network
services
An implementation methodology should be developed and approved in acquisition of the
software.
Installation and implementation of new hardware, network and software should be compliant
with the project management standards and approach as specified in the hardware and
software Guideline
The Quality Assurance shall ensure that the implementation of the ICT project is in line with the
various Guidelines related to software, hardware and Network within Organisation and where
there are variations flag all the issues to the ICT Department and the project manager
responsible
25.5 Responsibility
Roles
ICT Department
Quality Assurance
Responsibilities
Apply ICT Quality Standard in all
operations
Test for Quality in ICT Operations
25.6 Procedure
This procedure shall apply to the quality processes in ICT projects
At acquisition software, hardware and network devices perform quality control check as follows;
Inspect whether the process of acquisition of software is compliant with the software Guideline
Inspect whether the processes of Hardware and Network equipment acquisition is compliant
with the hardware Guideline, software Guideline and network Guideline
Inspect whether the software requirements are compliant with the software Guideline
Inspect whether the hardware requirements is compliant with hardware Guideline quality
standards.
During the implementing ICT projects confirm if the ICT project are being implemented in
accordance with the software Guideline, hardware Guideline, network Guideline and the ICT
project management Guideline.
26.2 Objective
To respond to serious attacks quickly and effectively, reducing any potential business impact
and to reduce the risk of similar incidents occurring.
To ensure that Organisation is able to identify perpetrators of malicious acts and that
Organisation preserves sufficient evidence to prosecute them if required.
26.3 Scope
The purpose of this Incident Management Guideline is to provide a structured method to
managing the incidents that are within Organisation.
The scope of incidents is limited to incidents that require the activation of the Computer Incident
Response Team.
This does not cover operational incidents that are managed by the service desk.
This guideline also does not cover incidents that have been escalated to disaster management
response procedure must feed into any existing change management process.
Incidents must be reviewed to identify common threats and trends.
Access to the information security incident management system must be restricted to authorised
individuals.
Potentially compromised technology must not be used for any element of the information
security incident reporting process.
A process to maintain contacts with relevant authorities to support the information security
incident management process must be documented.
There must be mechanisms in place to enable the number, frequency, types and impact of
information security incidents and issues to be quantified and reviewed.
A clear point of contact must be established for all employees, contractors and third party users
allowing them to raise information security incidents.
A point of contact must be available to respond to information security incidents at all times.
All users (including third party users) of Organisation ICT Services must be made aware of their
responsibility to report suspected or actual information security non- compliance, and incidents,
and the correct process for reporting information security incidents.
The security incident owner must track the information security incident to resolution and
closure.
All users (including third party users) made aware of an information security incident must report
it to the central information security incident response team in Organisation Global Information
Security.
Once incidents are identified measures should be put in place to ensure that the incident does
not spread to other systems or areas within the network.
Only (Computer Incident Response Team) CIRT members with the support of ICT technical
team shall be authorised to contain the incident(s). (The full list and terms of reference in of the
CIRT is found in the annex section)
Due care should be taken by the CIRT to ensure that the incident containment process does not
result in loss of evidence which will be key in resolving the cause of the incident.
Once incidents are identified measured should be put in place to ensure that the incident does
not spread to other systems or areas within the network.
Only CIRT members with the support of ICT technical team shall be authorised to contain the
incident(s).
Due care should be taken by the CIRT to ensure that the incident containment process does not
result in loss of evidence which will be key in resolving the cause of the incident.
Computer incidents shall be separate from the Organisation disaster management incidents.
All identified disaster management incident shall be escalated to the disaster management
130 | East Africa Public Health Laboratory Network Project
team.
All traces of ICT incidents must always be removed so as to prevent re-occurrence
The CIRT shall be responsible for coming up with recovery procedures for the incidents
As part of recovery the CIRT shall maintain and refer to previous incident logs for reference in
recovery.
Once recovery is successful the recovery procedure shall be recorded in the lessons learnt and
recovery procedure in the incident log
Only members of the CIRT and competent ICT Technical staff shall be allowed to manage the
recovery process
The CIRT team shall be responsible for evaluating the incident report with the objective of
updating the incident log as well as educating the CIRT team
Once an incident is resolved a formal closure process should be initiated through the CIRT
All information about the incident must be recorded and stored for future reference
26.5 Responsibility
Ref
Department
CIRT
Role(s)
The CIRT is comprised of a Team Leader and team members
with various roles and responsibilities.
The Team Leader is responsible for the following:
1. Making the judgement on whether the incident
should be classed as an Incident type I or II.
2. Constituting the appropriate CIRT for the incident
and assigning technical and support (e.g.
research, scribing and welfare) responsibilities.
3. Providing
a central reporting point and
coordinating response efforts.
4. Scheduling periodic status update meetings as
appropriate.
5. Ensuring that the CIRT follow set procedures in
responding to incidents and that documentation
of events is comprehensive.
6. Escalating the incident information to department
management. Providing a contact point for
support departments.
26.6 Procedure
The diagram below shows the processes involved in proper Incident Management
Logging
The essential first step in managing incidents correctly is to receive and log them.
Incidents may be reported from various sources, such as users, application
managers, the User Help Desk or technical support, among others.
Incidents should be logged immediately as it is much more difficult to log them later
and there is a risk of new incidents emerging, causing the process to be postponed
indefinitely.
The following are key activities that must be performed in the incident logging process
i.
Commencing handling of the incident: the User Help Desk must be able to evaluate
whether the service required is included in the customer's SLA in the first instance
and if not, forward it to a competent authority.
ii.
Checking that the incident has not already been logged: it is commonplace for more
than one user to report an incident, so it is necessary to check to avoid unnecessary
duplication.
iii.
iv.
Initial logging: the basic information needed to process the incident (time,
description of the incident, affected ICT systems ) has to be entered on the
associated database.
v.
Supporting information: Any relevant information for the resolution of the incident
that may be asked for from the client using a specific request which can be
requested from the helpdesk.
vi.
Incident notification: in those cases where the incident may affect other users,
these should be notified so that they are aware of how the incident may impact their
usual workflow.
Classification
The main aim of incident classification is to collect all the information that may be
134 | East Africa Public Health Laboratory Network Project
viii.
Establishing the level of priority: the incident is assigned a level of priority, based
on predefined criteria, depending on its impact and urgency.
ix.
Allocation of resources: if the User Help Desk cannot resolve the incident in the
first instance, it will designate the technical support personnel responsible for
resolving it (second level).
x.
Monitoring the status and the expected response time: an incident is associated
with the incident (for example, logged, active, suspended, resolved, closed) and the
resolution time for the incident is estimated based on the relevant SLA and the
priority.
xii.
xiii.
xiv.
xv.
26.7 Responsibility
Roles
User
Helpdesk
CIRT
Responsibilities
Shall be responsible for logging all incident and passing them on the CIRT
Shall manage the escalation process of the incidents
Figure 12:
11: Incident Management Flowchart
ii.
iii.
27.2 Objective
ICT contingency planning is be part of the fundamental mission of the Organisation as a
responsible and reliable public institution.
To ensure the continuous performance of the Organisation information systems especially
during emergencies through;
i.
Protecting equipment, data, and other assets. reducing or mitigating disruptions to
operations.
ii.
iii.
Achieving timely and orderly recovery from emergencies and resumption of full
service to the public
27.3 Scope
The scope of the contingency plan should cover all critical systems identified by Organisation
The contingency plan will apply in all cases of disruption of operation where the critical systems
will be affected
All staff within the ICT department shall be trained on the execution of the contingency plan.
27.5 Responsibility
Department
CIRT
ICT Operations
ICT Department
Role(s)
See detailed roles as in the Incident
Management guidelines
Ensure that all necessary mechanisms
are in place to be able to recover in case
of a disaster
Ensure that all Sections in the Unit are
able to respond to any disasters
27.6 Procedure
This procedure will be executed in conjunction with the Incident management procedures
28 Organisation/ICT/02/01/28 - IT Governance
28.1 Description
Increasingly, top management is realising the significant impact that information can have on
the success of the enterprise. Management expects heightened understanding of the way
information and communications technology (ICT) is operated and the likelihood of its being
leveraged successfully for competitive advantage.
Successful enterprises understand the risks and exploit the benefits of ICT, and find ways to
deal with:
i.
Aligning IT strategy with the business strategy
ii.
iii.
iv.
v.
Enterprises cannot deliver effectively against these business and governance requirements
without adopting and implementing a governance and control framework for IT to:
vi.
vii.
viii.
ix.
x.
Business managers and boards demanding a better return from IT investments, i.e.,
that IT delivers what the business needs to enhance stakeholder value
xii.
xiii.
The need to meet regulatory requirements for IT controls in areas such as privacy
and financial reporting (e.g., the Sarbanes-Oxley Act, Basel II) and in specific
sectors such as finance, pharmaceutical and healthcare
xiv.
The selection of service providers and the management of service outsourcing and
acquisition
xv.
xvi.
xvii.
The need to optimise costs by following, where possible, standardised rather than
specially developed approaches
xviii.
xix.
The need for enterprises to assess how they are performing against generally
accepted standards and against their peers (benchmarking)
28.2 Objective
To ensure that management is responsible for aligning ICT with business processes. Meaning
that IT delivers value, performance is measured, resources are properly allocated and risks
mitigated
28.3 Scope
The scope involves Organisation top management governance of information technology
section
A governance and control framework needs to serve a variety of internal and external
stakeholders each of whom has specific needs:
i.
Stakeholders within the enterprise who have an interest in generating value from IT
investments:
a. Those who make investment decisions
b. Those who decide about requirements
c. Those who use the IT services
ii.
iii.
b.
c.
c.
28.5 Responsibility
Roles
Head of ICT
ICT Department
Responsibilities
Shall be responsible for setting up IT
governance structures.
Reports to senior management on IT
governance issues
Implements the ICT governance standard as
outlined in the manual
28.6 Procedure
Plan and organise (PO)
This domain covers strategy and tactics, and concerns the identification of the way IT
can best contribute to the achievement of the business objectives. Furthermore, the
realisation of the strategic vision needs to be planned, communicated and managed
for different perspectives. Finally, a proper organisation as well as technological
infrastructure should be put in place. This domain typically addresses the following
management questions:
i.
ii.
iii.
iv.
v.
Are new projects likely to deliver solutions that meet business needs?
ii.
iii.
iv.
ii.
iii.
iv.
i.
ii.
Does management ensure that internal controls are effective and efficient?
iii.
iv.
EAPHLNP Enterprise
Direct
Metric
IT Goals
IT Scorecard
Direct
Metrics
Deliver
Business
Requirements
Governance
Requirements
Information
Run
IT processes
Require
Influence
Information Services
Application
(includingrespon
Imply
Information
Criteria
Need
Infrastructure &
people
29.2 Objective
To ensure that all ICT projects and activities are headed by a steering committee comprised of
ICT professionals and business heads tasked in providing oversight and strategic direction.
29.3 Scope
Organisation shall have an IT Steering committee responsible for offering strategic direction.
Such a steering committee shall be responsible for the following;
i.
Coordinate major IT projects within Organisation
ii.
iii.
iv.
v.
Support and work with the head of the ICT department in improving ICT strategic
initiative
vi.
29.5 Responsibility
Roles
ICT head
User Department
Responsibilities
Shall present ICT progress and strategies
at steering committee
Shall Nominate lead to address matter at
steering committee
29.6 Procedure
The steering committee is charged with the following responsibilities
i.
ii.
iii.
To resolve any material issues or problems before they impact on project progress,
iv.
v.
vi.
vii.
viii.
30.2 Objective
To ensure that all processes within the Organisation IT environment are identified and
documented within a procedure manual
To ensure that a relevant Guideline is developed in line with each process identified
To ensure the secure operation of ICT operations through the documentation and maintenance
of operating procedures
30.3 Scope
The scope will include the Information processing and communication facilities of the
organisations ICT Department. This Guideline addresses the definition, documentation, and
maintenance of the operating procedures for the IT environment within Organisation.
Organisation Management and staff shall comply with the documented procedure manuals one
they have been documented and approved
Operating procedure and responsibilities for all Organisation ICT Department information
processing facilities should be formally documented, authorised and maintained
The Quality Assurance (Read the Quality Assurance guidelines) will consistently be reviewing
the various processes within the IT environment to identify, additional processes, process
improvement opportunities, and any processes gaps
Once identified discussion will be conducted with the affected users and department to agree on
what needs to be included in the identified process
The procedure for the process will be documented and the underlying Guidelines associated
with the procedure will be identified and documented
The new Guideline and procedure will be validated by the user and user department who will
then approve the new additional Guideline and procedure. The ICT Department will have the
final approval and the IT Guideline and procedure manual will then be updated
Training on ICT Guidelines and procedures; Quality Assurance will have the responsibility of
ensuring that user of the ICT Guidelines and Procedures are consistently updated on changes
to the Guideline and will arrange for training and awareness programs regarding the ICT
Guidelines and procedures
30.5 Responsibility
Roles
ICT Department
Users
Responsibilities
1. Consistently apply the ICT SOPS in
operations
2. Identify gaps in the ICT SOPS
3. Implements the gaps through updating
the ICT SOPs
Inform
4. Update users on changes in the ICT
SOPs
1. Comply with the ICT Department in
complying with the ICT SOPs
2. Provide feedback on usage of the ICT
SOPs
31.2 Objective
The purpose of this Guideline is to ensure that ICT projects are consistently initiated, planned,
implemented and closed in a manner that they deliver solutions that are within schedule, budget
and desired quality.
31.3 Scope
This Guideline applies to all ICT and other Organisation staff involved in the initiation, planning,
implementation and delivery of any type of ICT project.
and ICT division, will all the solution/product documentation, as well as project management
documentation.
Post implementation review, and management of Warranty, Snugs, guarantees must be carried
out after project closure.
31.5 Responsibility
These are people that are affected by this Guideline.
Roles
User department
ICT Department
Responsibilities
1. Initiate project
2. Responsible for co-developing the project
terms of reference
3. Monitoring of project
4. Approving the project deliverables
1. Drafting the terms of reference
2. Implementation of the ICT project
3. Monitoring the project implementation
process
31.6 Procedure
Identify the Business need / requirement that needs to be fulfilled
Design and define high level solution that provides a solution to the business requirement. This
will clearly identify business goals, scope, requirements and deliverables.
The Project Initiator shall develop a Project Initiation Document which will be approved by the
Accounting Officer in conjunction with the Head of the User/Beneficiary department. A Project
Manager will be identified and appointed.
The Project Manager will develop a project implementation activity schedule, with resource and
related costs. This will be approved by the Project Sponsor represented by the ICT director and
Head of User department.
The Project Manager will ensure the project is implemented according to schedule, budget and
desired quality/set of deliverables. Any changes will first be approved through a formal change
management procedure.
Once all activities have been performed, the Project manager will test for completeness and
document all project activities.
The project manager will then handover and close the project.
This procedure shall be read in conjunction with preceding project management procedures
32.2 Objective
To ensure that all potential project concepts are supported with a background of sufficient
research information justifying their viability and feasibility to ensure that Organisation invests in
ICT projects with acceptable return on investment and such project shall impact Organisation
positively.
32.3 Scope
The Guideline shall apply to all ICT projects that include;
Software,
i.
ii.
iii.
Hardware
iv.
Acquisition of new hardware
v.
vii.
ii.
Benefit
iii.
iv.
v.
vi.
vii.
viii.
ix.
x.
xi.
5. The project concept shall be presented to the IT Steering committee for approval before
commencement
32.5 Responsibility
Roles
User department
Responsibilities
1. Providing need for a project
2. Feasibility study for project concept
3. Seeking approval for project concept
5. Obtaining resource commitment for the
project
ICT Department
ICT Project
R.1
Planning
33.2 Objective
All ICT projects shall be subjected to project planning (First objective ends here). To ensure that
there is adequate allocation of resources such that projects are completed within time, budget
and within acceptable quality standards.
33.3 Scope
All ICT projects in the Organisation annual business plan shall be subjected to a formal project
planning process
33.5 Responsibility
Department
ICT Department
User department
Role(s)
1. Develop project terms of reference
2. Assigning of project team members
3. Develop project plans
1. Nominate project team members
2. participate in project planning
3. Approve project plans
33.6 Procedure
In the project planning stage of the organisation should develop a project team structure which
shall decide what resources to use
The project initiators will develop terms of reference for the project team staff.
A project charter shall be developed outlining the key governance aspect of the project as well
as include the project plan
The project charter will be signed by the user department and the ICT department
representatives
158 | East Africa Public Health Laboratory Network Project
Tracking of the project plan to ensure that the project team members are working
within the budgeted time and conditions.
ii.
Quality control of the project deliverables at each phase to ensure that they are
being implemented in accordance to the project standards.
iii.
Confirm that all the necessary test and quality assurance activities are being
performed efficiently.
34.2 Objective
To ensure that the project is being managed consistently according the approved approach and
standards.
34.3 Scope
The scope covers all the ICT projects within Organisation
34.5 Responsibility
161 | East Africa Public Health Laboratory Network Project
Role
ICT Department
Steering Committee
Responsibility
Ensure teams are constituted to handle the projects and
approvals are given in a timely manner
Ensure that work on projects is well documented and the
projected Is carried out as prescribed in this manual
34.6 Procedure
Project implementation monitoring shall be the responsibility of the project team, and
Organisation study projects and total quality management.
Project monitoring will be done by the Quality Assurance through review of the activities being
performed by the project manager outlined in the planning phase of the project
Monitoring will shall be performed by the Quality Assurance team through consultation with the
user department to confirm whether the deliverables are being issued as agreed in the planning
stage throughout the project cycle
Monitoring will also be performed by the Quality Assurance member on delivery if the ICT
project to ensure that the deliverable are of the expected quality and that the solution is
sustainable.
In the course of the project monitoring progress reports shall be issued by the project manager
as part of project control and the Quality Assurance members shall also develop project
monitoring report with input from the project manager in order to provide an independent view of
the project.
Guideline Name
Organisation/ICT/02/01/33
ICT Project
R.1
Planning
R.2
Organisation/ICT/02/01/35 Project Closure,
Sign-off
35.2 Objective
To confirm and approve the final project deliverables and officially close the project
35.3 Scope
The scope covers the entire ICT projects within Organisation
All project deliverables resulting from the project shall be recorded and archived in line within
the documentation retention polices of the organisation and shall be stored in-line with country
specific regulations on document retention
35.5 Responsibility
Role
Designated project manager
Steering committee
Responsibilities
1. Ensure that all project deliverables are
completed
2. Seek approval for all completed
deliverables
3. Store completed project deliverables
4. hand over deliverables.
Approve and sign off completed
deliverables.
User department
35.6 Procedure
The project closure procedure shall commence with the delivery and handover of the project
final deliverables to the user and/or user department.
Upon the user department testing and accepting the deliverable(s), a sign-off of the
deliverable(s) shall be made by the head of the user department or a rejection of the deliverable
will be made resulting in rework on the deliverable(s) if unacceptable.
The project closure and sign off process should include the following
i.
Report on the variance between baseline project plan and final project plan.
ii.
iii.
iv.
v.
vi.
vii.
Procedure for documentation resulting from project shall include the following
i.
ii.
iii.
iv.
v.
The project manager shall compile all documentation from the project and this
documentation shall include the following
a. Project plans
b. Documentation on all project deliverables
c. Issues log
d. Risk logs
e. Lessons learned reports
f. Project status report
g. Project budget baseline and final budget
The project manager shall copy any back-up all the soft copy documentation to an
electronic media such as CD, DVD, Data Tape. Where possible all hard copies of the
documentation shall be scanned and also backed up on electronic media.
In cases were an document management system exists the electronic form of
documentation shall be added to the electronic document management system for
reference and archiving
All hard copy documentation such as signed off files and documentation shall be
compiled and indexed and archived using the organisation archiving procedures and
stored securely in the organisation archives and records for future reference.
All documentation resulting from a project shall be stored in line with documentation
retention laws of the country at a minimum and where the organisation may require the
documentation archived for more than the country minimum retention period the project
manager shall clearly document the retention period for all hard copy and soft copy files
of the respective project.
Figure 19: Project Closure, Sign-off and Retention of project documentation flowchart
Section
Reference
33
Guideline Name
Organisation/ICT/02/01/33
ICT
Project
R.1
Project
R.2
Planning
34
Organisation/ICT/02/01/34
Implementation monitoring
36.2 Objective
168 | East Africa Public Health Laboratory Network Project
To ensure the all project documentation is formally documented and stored in a safe and secure
environment for purposes of future references and retention period and must be in accordance
with the laws of the country and organisation guidelines on retention.
36.3 Scope
All documentation that will be generated as part of ICT activities covered in this Guideline.
36.5 Responsibility
Roles
ICT Department
User Department
Project managers
1. Collect all project document
2. Archive all project documentation in
accordance
with
the
laws
of
documentation retention
1. Retain the project documentation as
prepared by the project manager
36.6 Procedure
On commencement of each ICT project activity an electronic file or database shall be created to
store all project information.
The electronic file shall be scheduled for regular back up in line with the back- up Guideline.
Once the activities or project have been concluded the project manager or team leader of the
project will be requested to take a stock of all project documentation from the project members
and this project information shall be stored within the electronic project file for final back up.
Hard copies shall be scanned and copied into the electronic file and the original hard copies
stored securely in line with retention Guidelines for the country and organisation.
.
37.2 Objective
To ensure that quality standards are implemented when acquiring computer hardware and
software for usage within the Organisation environment.
37.3 Scope
This Guideline applies to the acquisition of new hardware, networking and software within
Organisation ICT environment
A quality assurance officer shall be appointed in the organization who shall be responsible
for quality assurance of ICT projects and shall work with all the respective departments and
persons in the project as stipulated under the responsibilities section.
37.5 Responsibility
Roles
ICT Department
Quality Assurance
Responsibility
1. Confirm terms of reference
2.
ensure implementation of quality
standards in the acquisition process
3. Address any recommendation from
quality assurance
1. Confirm terms of reference
2. Check compliance with quality
standard and stated in the guidelines
3. Report on findings
37.6 Procedure
The following quality standards should be considered for hardware and software
All software should comply with the software Guideline procedures in furthermore all software
should include the following;
For all acquired software there must be requirements specified by the user department which
will be signed off and approved
All off the shelf software identified for acquisition should satisfy user requirements and should
ensure minimal customisation where possible.
i.
Vendors for off the shelf software should have implemented successfully the
software in at least three sites successfully and the reference sites should be
verifiable.
ii.
The vendor should be able to offer support for the software post the implementation
of the software.
iii.
All software applications should have a licensing agreement that is consistent with
the licensing Guideline
iv.
All software acquired should be compliant with the software testing procedures in
Annex
v.
vi.
vii.
Hardware and network equipment -All Hardware should comply with the Hardware Guideline
procedures, furthermore all hardware should include the following;
viii.
For all acquired hardware there must be requirements specified by the user
department which will be signed off and approved
ix.
All hardware should have a warranty for a specified period of not less than 1 year.
x.
All new hardware and network equipment should be compliant with the minimum
baseline standard
xi.
xii.
All hardware and network equipment should be compliant with the software
requirements in cases where it shall host specific software(s).
xiii.
All hardware and network equipment should carry a seal for quality to confirm
quality standards in the assembly as well as quality control checking.
xiv.
All hardware and network equipment should be acquired from approved local and
international suppliers from Organisation as well as the hardware manufacturer.
xv.
R.1
R.1
R.2
R.3
R.2
NO
1
Review
requirements
Refer concerns to
Supplier and
project team
NO
NO
2
Requirements
met?
Yes
11
Is vendor
approved?
YES
10
Is it software?
NO
9.
Refer to supplier
No
5.
Is an approved
brand?
3
Is hardware or
network device?
YES
Yes
12
Does vendor have
credible reference
4
Is it an approved
Vendor?
YES
Yes
6
Was it quality
checked ?
NO
YES
NO
YES
15.
Approve Quality
15.
Does vendor offer support
post implementation ?
YES
7
Does it have
warranty ?
YES
YES
16.
Issue Quality
Repor
8
Does it comply with
minimum baseline
standards
14
Vendor uses approved
implementation
methodology ?
R.4
Guideline Name
General Software Guideline
Organisation/ICT/02/01/Annex
Design
Hardware and Network
NO
Solution
R.2
R.3
38.2 Objective
To ensure that the installation or implementation of hardware and network equipment and
Software is compliant with Organisation Guidelines and quality standards
38.3 Scope
This applies to all software, network and hardware projects.
38.5 Responsibility
Department
Project manager
Quality Assurance
Role(s)
1.Implement the project using quality
assurance guidelines
2. Implement quality recommendations
1. Review the implementation process
compliance to quality standards.
2. Monitor the implementation process
3. Issue quality recommendations
38.6 Procedure
Installation and implementation of new hardware, network and software should be compliant
with the project management standards and approach as specified in the hardware and
software Guideline.
The following should be considered;
i.
A quality plan should be developed and referenced in the implementation process
and quality plan should be approved by the ICT Department.
ii.
Quality assurance should be deployed at all stages to ensure that the standards are
maintained at all times.
iii.
The Quality Assurance shall ensure that the implementation of the ICT project is in line with the
various Guidelines related to software, hardware and Network within Organisation and where
there are variations flag all the issues to the ICT Department and the project responsible
Guideline Name
General Software Guideline
Organisation/ICT/02/01/Annex
Design
Hardware and Network
Solution
39.2 Objective
To ensure that Organisation invests in building knowledge related to information communication
technologies resulting in the development and enhancement of processes, procedures,
information systems and IT infrastructure
39.3 Scope
The Guideline shall cover the following
All ICT processes and information communication technologies.
ICT enables process and general processes within Organisation.
39.5 Responsibility
Roles
ICT Department Research team
Responsibilities
1. Identify key research areas
2. Approve research areas
3. Perform research
5. Publish research results to department
and running projects
39.6 Procedure
The research development function shall be key in providing knowledge to ICT project and
procedures. The following procedures shall assist in the research and development within
Organisation.
The organisation study projects and total quality management team shall develop and maintain
an inventory of the past, present and planned project in Organisation.
The organisation study projects and total quality management team shall record all the issues,
ICT projects and risks within Organisation that may require and ICT based solution.
Deliberate research will be conducted by the organisation study projects and total quality
management team on the issues, risk and ICT project and such research will include internal
knowledge and external knowledge that includes secondary research from reputable knowledge
sources.
The findings from the research will be communicated to the various user departments , ICT
projects and ICT department management for consideration in the Organisation improvement
plans. Periodically the Quality Assurance will also review the Organisation business plan and
identify areas of improvement in relation to the research and such communicate to the ICT
Department and the head of the various departments including the Director General
Organisation.
40 Organisation/ICT/02/01/40 Training
40.1 Description
Training is a fundamental aspect of enhancing skills within the Organisation and this Guideline
will aim to address training key areas within the Organisation.
40.2 Objective
To ensure the Organisation staff and third parties receive relevant training on aspect related to
ICT operations such that capacity is developed and maintained.
40.3 Scope
All employees and third parties that access Organisation communication systems and
computing platforms
40.5 Responsibility
Roles
Responsibilities
Human Resources
ICT Department
40.6 Procedure
Access Guidelines
i.
Organisation should create procedure for training all employees and other users on
how to access and use its communication systems. Each employee should
understand what areas are acceptable and what areas are not to be accessed. All
employees should be trained on access controls and legal responsibilities. All
employees should be aware and remain vigilant for possible fraudulent activities.
Well defined procedure should be in place in order for employees to report incidents
involving their personal accounts or the acts of others.
Software Packages
ii.
Training should be conducted on the acceptable use of all software used for
communication with other systems and personnel. All applications should have a
logon process with a secure method of password protection. Guidelines and
procedure are to be developed and delivered in a training arrangement with all
employees.
New Systems
iii.
All users should be trained on the use of new systems. The level of Information
Security training required for individual system users must be appropriate to their
specific duties, so that the confidentiality, integrity, and availability of information
they would normally handle is safeguarded.
Technical Staff
iv.
Information Security staff both protects the information asset, but equally, may
inadvertently (or maliciously) put it at greater risk. Therefore it is essential that they
be trained to a level of competence in Information Security that matches their duties
and responsibilities.
Incident Reporting
v.
Organisation ICT Department is to have resources that oversee the operation with
respect to all forms of Information Security. This resource shall be responsible with
safeguarding all information asset, measuring effectiveness, providing
countermeasures, and development of training and awareness programs.
40.7 Reference
Quality Assurance Guideline
41.2 Objective
To ensure that all Web Applications or Websites are developed and Managed in a controlled
manner by all the ICT TWG members and Partner states who are responsible for creation and
managing the content.
41.3 Scope
The scope of this guideline and Procedure shall cover the Web Application or Website
development, Hosting and Content Publication.
Abusive statements that are against the objective and goals of the EAPHLN
Viruses and embedded Spam
Advertisement of services of other organisations
Poor formatting of content that makes it difficult to view
The Web Portal shall have a service level agreement with an Internet service provider and the
service level agreement shall be compliant with the guidelines and procedures related to
Network configuration, network access, third party network access.
The Web Portal shall be updated frequently with current content. The content on the Web Portal
shall be reviewed by a ICT TWG before publishing.
The Web Portal shall comply with the respective cyber laws of the EAC partner states.
41.5 Procedure
Web Development
1. Web development shall follow the guidelines and procedures of software development
and security requirements detailed in Annex I, Annex II, Annex III, Annex IV and the
General Software Guidelines.
Web Hosting
2. The EAPHLN Web Portal shall be hosted on the internet in the public domain and shall
use the following URL http://www.eaphln-ecsahc.org.
3. When hosting, a service level agreement shall be put in place with the internet service
provider.
4. The Webmaster shall ensure that the internet service provider is in compliance with the
service level agreement or contract at all times and shall review performance of the
hosting services and consult with the ICT TWG for any amendment to the contract or
service level agreement to improve value of the service.
5. The Webmaster shall also confirm whether the ISP does not present a security risk by
testing compliance with the security related guidelines and procedures of the
organisation and work closely with the IT security team to identify any potential security
weaknesses and breaches.
Content
1. The designated Webmaster shall keep track of all relevant news, information, images,
statistics regarding activities and projects within the EAPHLN.
2. The Web Master shall request for potential content in the form of pictures, reports,
information, project updates from the various user departments.
3. All the potential content shall be reviewed by the Web Portal committee based on a
criterion they shall set.
4. All approved content shall be handed over to the Web Master who shall upload the
content based on the categories in the Web Portal.
185 | East Africa Public Health Laboratory Network Project
5. The Web Master shall follow change management guidelines when applying any
changes or updates to the Web Portal.
6. All non - current content shall be moved into archives based on a criteria set by the ICT
TWG, and a decision will be made to include the archiving of the content within the
portal or store the content outside the portal.
7. The Web Master will review all the content after posting new content to confirm
consistency, user friendliness of navigation and also confirm that there are no dead links
or links that do not lead to the right content or errors.
41.6 Responsibility
Roles
Responsibilities
ICT TWG
Web Master
42 ANNEXES
43
43.1 Background
The key aim of Organisation ICT Contingency Plan (Contingency Planning) is to assist in
preventing, where possible, events which disrupt the Organisations business operations and
services, and to minimize the potential impact of any unavoidable disruption by containing it to a
predictable and pre-determined acceptable period of time.
In preparation of this plan, consideration has been given to the possibility that implementation
and execution of specific phases of the plan may be required by individuals with limited prior
knowledge and exposure to the details of the entire plan. Therefore, the approach taken in the
plans development was one with particular focus on the following:
i.
Heightened awareness of management and employees to disasters and their
impacts;
ii.
iii.
The Organisation recognizes and acknowledges that the protection of its assets and business
operations is a key responsibility to its employees, shareholders, business associates, and other
communities that it serves. Therefore, The Organisation seeks to establish its viable
Contingency Plan.
The Organisation is committed to supporting resumption and recovery efforts at alternate
facilities, if required. The Organisation and its management are responsible for developing and
maintaining a viable Contingency Plan that is consistent with the provisions and direction of the
Organisations strategic and tactical plans.
The Organisation mandates the existence of a Contingency Plan that fully supports the
philosophy of providing and maintaining the highest quality services to its customers and
employees
43.2 Scope
The primary objectives of the plan are:
i.
Provide the Organisation with a plan that will help in an efficient, effective and timely
recovery and resumption of the interrupted ICT Operations affecting the LIS and HIS
ii.
Ensure recovery of LIS and HIS within the timeframes specified by the various
business units;
iii.
iv.
Prevent Organisation from sustaining financial and operational impacts that could
seriously jeopardize the Organisation;
v.
vi.
vii.
Resume operations and support of all critical IT functions within the time frame
specified by the business units;
viii.
Provide a proper work environment for the displaced staff while the primary site and
its set-up are in the process of restoration; and
ix.
Ensure that normal business operations at the primary site or other alternate sites
are restored in a timely manner
xii.
xiii.
Loss of data and information, recognizing that the loss of some data and information
is inevitable.
xiv.
xv.
xvi.
The total elapsed time required for completing the recovery, response, resumption,
and restoration
43.3 Approach
Organisation should employ the following approach to accomplish the contingency planning
objectives:
i.
Prevention by improved employee awareness and preventive controls.
ii.
iii.
Readiness actions are the activities to be performed to ensure that the Organisation is ready to
meet any contingency / disaster. These are in the nature of preparatory actions for readying the
required facilities and purchase and set up of hardware systems and telecommunications
facilities to be used during a disaster.
The main steps to be undertaken in the recovery process are provided below:
Systems are to be maintained at High availability site with online real-time replication with no or
very low (less than 5 minutes) time delay. Systems are also to be maintained at the DR site
with online replication of data with time delay (maximum time delay of 8 hours).
In order to ensure a viable recovery using backup tapes, it is important that copies of the backup
are stored at a secured off-site location within the country for local recovery. The tapes should
be retrievable from this location within a few hours for restoration in the event of a crisis
Work closely with other Teams to ensure all LIS and HIS are available off-site along
with other relevant information such as configuration details, license certificates,
technical and operational documentation and vendor support contact information
iii.
iv.
v.
Post-Disaster
Platform
vi.
vii.
viii.
Ensure the security Guideline of the network operating system is adequate and
appropriate with relevant controls configured to authenticate and authorize users
access to network resources
ix.
Ensure that the active directory is set up appropriately with the required group and
individual privileges and services for effective and secure access
x.
Assess the operating system for system and data integrity before release to end
users
xi.
Update the Contingency Planning Lead Team Leader on the status of platform
recovery and availability at the alternate site
Applications
xii.
Coordinate restoration HIS and LIS applications and data which are critical to end
users and business operations as a whole
xiii.
xiv.
Assess the applications for system and data integrity before release to end users
xv.
Ensure backups of applications and data are scheduled once the alternate site is
active
xvi.
Update the Contingency Planning Lead Team Leader on the status of application
recovery and availability at the alternate site
43.7 Incidents
Having a Contingency plan is taking measures to prevent a disaster or to mitigate its effects
beforehand. This portion of the plan reviews the various threats that can lead to a disaster,
where our vulnerabilities are, and steps we should take to minimize our risk. The threats
covered here are both natural and man-made.
Force Majeure
Force Majeure refers to risks caused by acts beyond human influence, for events
outside of human control, such as sudden floods or other natural disasters, for which
no one can be held responsible to; fire in the Computer Room, especially in the server
room area, earthquakes, floods, lightening
Application / Operating Systems Failures
The threat of application and /or operating systems failure affects all the three
systems in question and is a very possible and imminent threat. This could be caused
by virus attacks, buffer overflows, configuration errors, human errors and sudden
power outages.
Links and Network Failures
These pertain to failures that arise when links or the network is down. Given the
centralised nature of the systems mentioned, it is imperative that links are always
available. Link outages can be caused by Service Provider failures and / or inefficient
infrastructure.
Hardware Failure
The threat of hardware failure pertains to server outages where hardware breaks
down. This can be caused by lack of preventive maintenance, obsolete equipment
and accidental damage.
This threat poses an impact on three systems as it can cause inaccessibility of the
systems to the Organisation.
Data Corruption & Database Failure
All the systems in question use centralised databases. They are therefore susceptible
to data corruption and database failure. The impact of data corruption is loss of data
integrity, financial loss resulting from lost data, impairs decision making and opens up
Organisation to fraud. Data corruption and Database failure can be caused by
malicious staff, poor database backup and turning procedures, virus attacks,
exposure to magnetic fields and careless mistakes.
Power Failure
The threat of power outages in particular causes disruption in normal operations and
can lead to Hardware breakdown, data corruption, OS corruption, etc. Because it is
the commonest threat to all the three systems by virtue of its frequency, there is need
to address it very particularly.
192 | East Africa Public Health Laboratory Network Project
43.8 Scenarios
These options, detailed below, are not alternatives and the Organisation will need to implement
all of these scenarios to ensure effective Contingency.
Incident or Threat: Force Majeure
Impact: a. Primary data center unavailable
b. Critical people at primary site unavailable
Scenario 1 (Plan A): Use DR Resources
Recovery: Attempt recovery by activating the recovery site and use
resources (facility / data center / backup personnel) from there. The alternate
location would have pre-established connectivity with the data center setup at
the primary site and users would be able to access HIS and LIS applications
there as soon as they have been restored / updated and brought online.
ii.
iii.
iv.
Restore the data into the Database using external media (tapes, hard
disks, etc.)
v.
Threats
Force Majeure
Application / OS Failure
Hardware Failure
Impact
Plan A
1. Primary DC unavailable
2. Critical people at PS
unavailable
Use DR Resources
Plan B
Switch to Back up
Server at DR Site
1. PDC unavailable
2. DR Site unavailable
Use DR Resources
Repair/ Replace
Faulty Hardware
Use DR Resources
Reconfigure Database
from Manual Data
Rebuild Server at
Primary Site
Power Outages
Plan C
Use DR Resources
Acquire New Hardware
and rebuild System
iii.
Summarize and evaluate the disaster response including developing the lessonlearnt document,
iv.
v.
43.10
backup tapes and its availability at the onsite and offsite storage and provide a
status report on the same.
ii.
iii.
iv.
v.
vi.
Description
Facility
Part
Facility
IT
Part IT
Business as
usual
Primary facility
unavailable
Part primary
facility
unavailable
Primary data
center
unavailable
People
Recovery Strategy
N/A
Use alternate
facility with primary
IT and people
Part primary
data center
unavailable
Critical people
at primary site
unavailable
Primary facility
and primary IT
unavailable
All resources at
primary site
unavailable
vii.
Invoke country
level disaster plan
43.11
The contingency team will test the application integrity for all the applications. As
the servers at the alternate location may be replicated on a real time basis with or
without time delay there is a possibility that the application integrity may have been
compromised and the data available on systems may not be up to date or reliable
(e.g. in instances where the primary system data has been compromised due to a
hacking attack or virus outbreak).
ii.
If the application does not load properly or there are a number of instances of illegal
operations and unforeseen aborts, the contingency team will need to recover the
application from the last know reliable backups of the production systems taken
from the primary site.
iii.
The team will have to determine whether the last transaction passed through the
application servers at the main location has been replicated at the servers at the
alternative processing site. The contingency team will need to recover application
Prior to the commencement of the software recovery process from backup tapes,
the Software Team Leader will intimate the Contingency Plan Team Leader of the
failure / issue faced in the recovery process.
vi.
vii.
Restore backups
The backup team will restore the relevant back-ups from tapes based on
requirements defined by the contingency team.
viii.
Retest application/database
Once the back-ups are restored, the Software Team will re-test the relevant
application to ensure that the data is up to date and system is performing as
expected
Once the restoration process has been completed, the backup team will return
the back-up media to the archives and schedule periodic backups from the
production systems at the alternate site
ix.
xi.
There can be a requirement to restore applications and or data from backup tapes.
The data will be restored only on a need basis during the recovery process.
xii.
One of the responsibilities for the data integrity test is to identify if there are any
inconsistencies in the various databases in use.
xiii.
If the data integrity has been compromised, the Software Team will be responsible
for liaising with the backup team to obtain the required back-up media and restoring
the data.
xiv.
If any backup tapes are not usable, the software contingency team leader will revert
to the latest working backup and also inform the Contingency Plan team Leader of
the number of days of data loss due to the failure of the restore process.
44.2 Objective
All software that is procured, and/or developed in-house must have an approved
case to support the cost and time for development and outsourcing of the software.
business
44.3 Scope
The Guideline shall cover the following areas;
Proposal for changes to existing software
Acquisition of new software
Development of new software
44.5 Responsibility
Roles
User department
User Department head
ICT Department
Responsibilities
1. Generate business case for Software
1. Approve software business case
2. Commit resources for the project
1.Assist in reviewing and approving
software business case
A feasibility study shall be conducted for proposed changes to the current software(s) or
acquisition of new software(s).
Such a study shall be jointly carried out with the business unit or department requesting the
software, the software development team and the Quality Assurance
203 | East Africa Public Health Laboratory Network Project
The business case shall include the purpose of the software, the expected benefit as a result of
the software.
The expected benefit should be qualitative and quantitative in nature.
A business case shall be the end result and shall be escalated to the ICT Department and the
Head of the user department for approval. A business case shall be completed.
The business case form shall include;
ii. Purpose of software
iii.
Benefit
iv.
v.
vi.
44.6 Reference
Ref
Document name
ISO 27001 and ISO 27002 Standards
Information Technology Infrastructure Library (ITIL
Control Objectives for Information and Related Technology (COBIT)
START
1.
Request for new
functionality
2.
Is it for existing
software application
NO
3.
Document the
Problem or Need
Statement
YES
9.
Prepare a
functionality
decline report
4
Develop Change
request
5.
Analyse High level
requirements
7.
Proceed with
the project?
6.
Carry out
feasibility Study
NO
R.1
8.
Commence
Project Planning
process
YES
R.2
R.3
45.2 Objective
Software requirements definition aims to provide guidance for defining functional and technical
related business requirements for new systems and/or enhancements to existing systems.
These business requirements should specify and define the expected automated processes
45.3 Scope
This applies to all software that is used by East Africa Public Health Laboratory Network Project
supported organisations.
Should specify the competencies and roles that are required to complete the
process.
iii.
Specify the key performance indicators required for the process to be completed
iv.
Specify the key inputs and expect outputs for each process
45.5 Responsibility
Department
Software Development team
User Department
Role(s)
Develop software requirement based on
the user requirement
Develop users requirement against
detailed terms of reference
45.6 Procedure
206 | East Africa Public Health Laboratory Network Project
The development of the user requirements shall be jointly developed with the User department
and the software department
A scope for the requirements shall be outlined and signed by the user department and the
section head of the software department.
The programmer shall develop software requirements specifications (what the software can do)
and present it to the analyst who presents it to the users to seek consent and approval (if the
software meets the needs of the users).
Using unified modelling language UML the requirements shall be documented by the analyst
programmer
The requirements shall be include functional and technical aspects
Once completed they shall be reviewed and signed-off by the user department head and the
software section head and the ICT Department
R.3
46.2 Objective
To provide guidance for defining security related business requirements for new systems or
enhancements to existing systems. These business requirements should specify and define the
type and method of controls (automated and manual) to be incorporated into the systems, along
with the scenarios of their expected use
To ensure that security is an integral part of information systems; Information systems include
operating systems, infrastructure, business applications, off-the-shelf products, services,
and user-developed applications. The design and implementation of the information system
supporting the business process can be crucial for security. Security requirements should be
identified and agreed prior to the development and/or implementation of information
systems.
To ensure that all security requirements are identified at the requirements phase of a project
and justified, agreed, and documented as part of the overall business case for an information
system.
46.3 Scope
A minimum list of issues to be addressed by security requirements follows:
i.
Access controls (mandatory or discretionary)
ii.
Administrator controls
iii.
Data classifications
iv.
Data encryption
v.
vi.
vii.
viii.
Network security
ix.
x.
xi.
xii.
xiii.
xiv.
xv.
User identification
Include a risk analysis that documents the types of risk associated with the
system
iii.
Consider all pertinent data security standards that may affect security
requirements (e.g.., Law Enforcement and other applicable compliance
requirements)
46.5 Responsibility
Department
Software Development team
User Department
Role(s)
1. Develop software requirement based
on the user requirements
1. Develop users requirement
2. Develop security features of the user
requirements
46.6 Procedure
All application and infrastructure developments must undertake security design and coding or
build activities in such a way as to implement the specified security requirements in an effective
and
complete
manner.
The
procedure
is
as
follows;
210 | East Africa Public Health Laboratory Network Project
i.
ii.
iii.
iv.
The security design must adhere to the secure design principle of simplicity: the
more complex a design, the less secure is the system; however, the use of
complex protocols (e.g. networks) and sophisticated coding techniques (e.g.
cryptography) has a positive role in ensuring security.
v.
The security design must adhere to the secure design principle of appropriate and
balanced security: security functionality must be appropriate to the scale of threat
and risks and balanced against the cost in terms of development and limitations
on design.
vi.
The security design must adhere to the secure design principle of least privilege:
all processes and users within a system should be given just sufficient access to
information and resources as the functionality requires.
vii.
The security design must adhere to the secure design principle of overt design:
security mechanisms should be overt and positive, rather than rely on obscurity of
coding, function or protocols. Only in specific circumstances should complexity
and obscurity be relied upon, based on guidance from Organisation Information
Security.
viii.
The security design must adhere to the secure design principle of design for a
hostile environment: security mechanisms must be resilient to attacks or
unpredicted changes in other parts of a system.
ix.
The security design must adhere to the secure design principle of defence in
depth: each basic threat to security of the design should be countered by at least
two applicable mechanisms.
x.
The security design must adhere to the secure design principle of default to
denial: security mechanisms should default to not granting access to information
or resources, rather than attempt to successively remove all undesirable access.
xi.
The security design must adhere to the secure design principle of maintaining
integrity of security: as far as possible, security mechanisms should be selfdefending, i.e. any tampering with basic mechanisms or data should be signalled.
xii.
The security design must adhere to the secure design principle of security
auditing: security mechanisms must provide a complete record of relevant events
and alarms of attempted breaches; also mechanisms to allow regular inspection
of events.
xiii.
The security design must adhere to the secure design principle of secure lookand-feel: security mechanisms should provide obvious warnings and indicators of
their presence, without any loss of secrecy of their method of working.
xiv.
The security design must adhere to the secure design principle of automated
installation of security: as far as possible, the installation of a secure environment
and initiation of security mechanisms should be automated (e.g. scripted server
builds).
xv.
The security design must adhere to the secure design principle of secure
maintenance: maintenance of the software and hardware environment during
operational life should never require the dismantling of any security mechanism.
(However, temporary disabling may be acceptable, under strict control.)
xvi.
Security aspects of the design must be tested during early stages of development
through design reviews, unit test and system test; security functionality must be
subject to rigorous testing at integration and acceptance testing stages of
development.
xvii.
xviii.
xix.
The design and operation of any user interfaces into specific security functions
provided by an application or infrastructure must take into account ease-of-use by
the target user-base.
xx.
The design of the user authentication and user input mechanisms for an
application or infrastructure must take into account the general physical
environment in which the typical user will operate with the system, and suitable
enhancements to the security of the interface included.
xxi.
xxii.
xxiii.
The design of each application must include allowance for the use of computerassisted audit and logging tools in order to capture an appropriate variety of both
application and system data during monitoring and investigations.
iii.
Application source code, object code, code editors, code generators and
language compilers must not be stored on any production system, except where
the application code is run-time compiled or interpreted; in this case, the
application design must include specific controls to ensure the security of this
code.
iv.
All user application sessions and processes must be terminated when the
application is shut down so that no direct operating system or any other form of
unauthorised access becomes available to the user.
v.
vi.
Each application must provide robust mechanisms that ensure that every user's
logon session is captive to the designed application environment and
functionality and cannot give unrestricted access to the operating system level.
vii.
Each application must provide robust mechanisms that ensure that every user's
logon session restricts access to the application and to authorised application
functions only.
viii.
e.g. via report writing options, query options, batch processing, command line
access, ODBC database links, shell escapes etc.
ix.
x.
xi.
iii.
iv.
Multiple applications that are run on a common database server must have the
same level of security requirements.
v.
vi.
ii.
Each application must include controls to ensure that input transactions are
processed only once.
iii.
All applications must provide for the validation of input data against pre-defined
parameters representing valid ranges, etc.
iv.
The application must provide facilities to enable changes to the data input
validation parameters to be made without any application code or configuration
changes.
v.
Modifications to critical static data and configuration data must only be allowed by
certain privileged application accounts that should be allocated to specific staff
(business line or support) as appropriate.
vi.
vii.
viii.
ix.
The access rights and permissions applied to application data files must protect
against unauthorised modification, patching or overwriting of the flies.
x.
xi.
During testing, development staff must check that the application actually does
what it was designed to do and that the output is complete and accurate.
xii.
xiii.
The integrity and completeness of printed output from an application must be able
to be validated using report numbering, end of report messages, nil reports (where
nothing explicit is reported) and periodic report acknowledgements (i.e. every 6
months check the user is receiving reports and that they are still needed).
xiv.
Each application or its associated business process must provide for checks during
input to ensure that data entered complies with, and is not contradictory to, any
static data for that application.
xv.
Common static data must be shared and maintained across as many applications
ii.
iii.
Web applications must be based on the Organisation standard web server platform
that will be situated in Organisation standard firewall complex for customer-facing
applications; the design and build must take into account all constraints that this
will impose.
iv.
The IP protocols, ports and services that the Web application is designed to make
use of must be specified and approval of Organisation Information Security sought
prior to the completion of the design stage of the development.
v.
All Web sessions between remote users and web servers over the Internet that
involve the transfer of customer-specific information and/or business transactions
must be protected for confidentiality and integrity by use of cryptographic tunnelling
initiated via cryptographic certificate authentication; where the IP Web protocol
(http) is being used, this requires the use of Secure Sockets Layer (SSL) protocol.
vi.
Where the SSL protocol is being used to protect applications that are being
developed to offer customer services or products over the Internet ("Web
applications"), the encryption tunnel must be based on at least 128-bit length
encryption keys.
vii.
Where Web applications are being developed, the design of the authentication of
remote users connecting via a browser session must provide, as a minimum level
of security, authentication by secret password followed by initiation of
cryptographic tunnels using key exchange protected under server-side certificates;
security requirements must be reviewed with a view to increasing the
authentication strength as appropriate from this minimum.
viii.
ix.
Where Web applications are being developed, the design of the information flows
into and out of the web server to support the application must comply with certain
basic rules:
a. the web server must not act as pass-thru for information flowing from the
Internet directly to any host or destination on the internal network;
b. updates of information resident on the web server from internal systems must
be initiated by the internal systems;
c. updates of information from users or nonOrganisation hosts on the Internet to
the web server are allowed (and must be subsequently subject to
authentication and validation checks on the web server);
d. Updates of information from the web server to internal systems must not be
initiated by the web server, but must be initiated by the internal systems. No
other information flows are allowed without specific Guideline Dispensation.
Where Web applications are being developed, the design of the application code
must minimise the number and complexity of interfaces between the web server(s)
and internal systems.
x.
Where Web applications are being developed, the design of the application code
resident on the web server must not require the code to operate with high
operating system privileges in normal operation; the minimum sustainable level of
privilege must always be designed.
xi.
Where Web applications are being developed, specific code reviews must be
undertaken of any scripted or run-time executed code of any type of class; all such
code must be located in non-public and suitably protected directories within the
web server.
xii.
Where Web applications are being developed, specific checks must be made
during development to ensure that all rendered web content (HTML and XML
content) is valid and is rendered correctly and that all hyperlinks embedded in the
content are valid and functional.
xiii.
Where Web applications are being developed, the design must provide specific
controls that ensure that the integrity of any SENSITIVE information that is resident
on the web server (e.g. price information) is maintained and confirmed regularly.
xiv.
Where Web applications are being developed, the design of each application must
not rely upon the security of any other web application server co-located in the
firewall complex and must not present vulnerabilities itself that could compromise
the security of other web application servers.
xv.
Where Web applications are being developed, the design of each application must
ensure that any web server, operating system and security mechanism
configuration information is not exposed through the html and web publishing
functionality of the server.
Where Web applications are being developed, the application development plan
must take into account the requirement under Group Information Security
Guideline and potentially under specific local statute and regulation that the web
server code and infrastructure must be subject to independent Security
Functionality
Acceptance Testing, involving probing of specified and unspecified functions (sometime called
"Penetration Testing").
i. Where Web applications are being developed, a written signed contract or a
published set of standards terms and conditions of business must exist to govern
the provision of services or products.
ii.
Where Web applications are being developed, the business process and liabilities,
privacy Guideline and customer statement regarding information and system
security Guideline must be codified within the contract written to govern the
provision of the service or products.
iii.
Where Web applications are being developed, the contract written to govern the
provision of the service or products must specify the responsibilities and actions
expected of the customer for maintaining the security of information.
iv.
Where Web applications are being developed, the business process, contractual
terms of business, published privacy Guideline and customer statement regarding
information and system security Guideline must be reviewed and agreed by Group
Information Security, Group Legal & Compliance, and where appropriate, by
external expert legal and regulatory advisors.
v.
Where Web applications are being developed, any limitations on the markets, valid
geographical territory, business sectors for which the services or products are
being offered must be determined and suitable wording provided on the service or
product home page to make these limitation on scope absolutely clear to the
connecting user.
vi.
Where Web applications are being developed and the scope of the service is
global, then the aggregate of the local statutory and regulatory requirements of the
Group's principal markets regarding business practice and information and
systems security must all be fulfilled.
vii.
Where Web applications are being developed and the scope of the product and
service is limited to various local markets, all local statutory and regulatory
requirements regarding business practice and information and systems security
must be fulfilled.
viii.
Where Web applications are being developed, the contract written to govern the
provision of the service or products must specify the process for the registration,
validation and authorisation of new customer-users of the application; specific
mechanisms for validation of customer-user identity and access rights must be
devised and documented.
ix.
Where Web applications are being developed, the Web home page to which users
connecting via remote browser sessions are directed must include, directly or via a
highly visible hyperlink, a clear understandable statement of the Group's Guideline
regarding the privacy and security of information provided to it via such Internetbased applications; such statement must have been approved by Group Legal &
Compliance and Group Information Security.
x.
Where Web applications are being developed and the application makes use of a
third-party service component (e.g. information feed), a contract must exist that
addresses responsibilities and liabilities for the security of information received and
as processed on the web server.
iii.
iv.
Planning;
i.
Plans for the development of applications and infrastructure must explicitly include
work activities and milestones for the relevant information security tasks and
deliverables.
ii. Guidance must be sought from Organisation Information Security regarding the
219 | East Africa Public Health Laboratory Network Project
The project plan for an application or infrastructure development must include the
activity required to produce at least the following specific security deliverables:
security requirements document derived from a formal risk analysis, security
design document, security test plan and specifications, risk acceptance document
(if relevant), Guideline Dispensation requests (if relevant).
iv.
v.
All resources and costs required for the production of security deliverables during
an application or infrastructure development are the responsibility of the
development project manager and the business owner and estimates must be
included in all project cost projections.
iii.
iv.
The use of active mobile code whether within the Organisation's development or
operating environments, or where downloaded by staff presents a real threat to
Organisation, therefore where appropriate, Organisation will filter for active mobile
code
iii.
iv.
Guideline Name
Organisation/ICT/02/01/Annex 3 - Software
Requirements Definition
47.2 Objective
To provide a guideline for the solution design for new systems or enhancements to existing
systems
To provide a guideline for information content and metadata organisation of software design
description
To provide guidance on the selection of design languages to be used for software design
description and requirements for documenting design viewpoints to be used in organizing a
software design description.
47.3 Scope
The software designed Guideline shall apply to internally developed software as well as
outsourced software from the vendors.
Software design shall considered be for upgrading existing software and the designing of new
software.
47.5 Responsibility
Roles
Software Development
User Department
Responsibilities
1.Design software based on approved
software requirement and user
requirements
2. Seek user approval of the software
design
1.Participate in software design process
2 Approve software design
47.6 Procedure
In house developed Software
i. The following are the procedures that shall be used in the development of in-house
software.
ii.
iii.
iv.
A software design plan shall be developed prior to the design process and such a
plan shall include;
a. Key design activities
b. Software design team
c. Tool and methods to be employed
d. Project and design methodology
The Organisation software development team shall identify appropriate software
design tools and standards that will be used in the documentation of the software
design and such tools will be approved by the Software section head and the head
of the particular software project.
The software design process will be based on the approved and signed user
requirement and such requirements will include the technical, functional and
security requirements.
v.
vi.
vii.
viii.
Once design standards are developed and documented they shall be approved by
the head of the software section and the ICT Department
Outsourced software
i. This procedure shall apply to external software vendor responsible for off the shell
package software. This procedure shall apply to all selected software vendors be
Organisation.
ii.
Software vendor shall avail and train Organisation Software department team on
their software design and the standards they employ.
iii.
The software design process will be based on the approved and signed user
requirements and such requirements will include the technical, functional and
security requirements.
iv.
Vendor will make effort to train Organisation on the development lifecycle that will
be employed in the project
v.
Once design standards are developed and documented they shall be approved by
the head of the software section and the ICT Department and the vendor project
director and managers.
48.2 Objective
To provide a guideline for the customisation or development of new or existing software
applications in compliance with the software design standards.
To ensure that the programming source code follows a consistent standard that is readable and
maintainable.
To enable system developers and administrators to implement consistent and simpletouse
security standardising software development projects
48.3 Scope
This Guideline shall apply to internally developed software and shall be used to review external
or outsourced development of software as well as customisation of software packaged by
external vendors.
48.5 Responsibility
226 | East Africa Public Health Laboratory Network Project
Roles
Software Development
Responsibility
1. Customise or develop the software
based on approved designs.
2 Reference the design against approved
software and user requirements
48.6 Procedure
Control over Development Processes;
i. All development activities must be conducted in such a manner so as not to
compromise the security of any information and functionality.
ii.
iii.
iv.
v.
vi.
Business information may only be used for testing of code under development if
the relevant business owner(s) have given specific permission.
vii.
viii.
ix.
Development staff must not be granted access to production systems for the
purposes of support or emergency fixes unless the access has been authorised by
the business owner or a suitable and authorised delegate.
x.
Development staff must not be granted access to production systems for the
purposes of support or emergency fixes unless the access is timelimited and the
activity of the development staff is subject to monitoring by designated production
IT staff.
xi.
All development environments must implement the full Bank standard AntiVirus
controls; this applies whether the development environment consists of servers,
workstations or both.
xii.
iii.
The process of development of software must provide for the proper specification,
justification and authorization of changes to requirements, design and code
affecting security functionality.
iv.
v.
vi.
vii.
viii.
The version and change control applied to security deliverables for an application
or infrastructure development must provide for the full recording of the details,
justification, timing and authorization of each change and the versions resulting.
ix.
x.
Release of changed versions of coded deliverables must occur only after any
security testing required by Bank Information Security has been successfully
completed.
xi.
Release of changed versions of coded deliverables must occur only after the
formal signoff by the developer, justifier and authorizer of the change has been
recorded; these roles must not be held by the same individual.
xii.
xiii.
The vendor must review all code before submitting the application to the
Organisation. Once received by the Organisation, the application will be reviewed
by Organisation to ensure that the relevant standards have been met. These
standards include, but are not limited to, the following Standards, practices,
conventions, and metrics;
a.
b.
c.
d.
e.
f.
g.
49 Organisation/ICT/02/01/Annex 7 - Separation of
Development and Operational Facilities
49.1 Description
Operational computing environments should be separated from development, and test
computing environments to reduce the risk of one environment adversely affecting another
49.2 Objective
To require that there is separation of operational, development, and test computing
environments to reduce the risk of unauthorized access or accidental changes to operational
software or data.
49.3 Scope
The scope of this Guideline applies to the Organisation information processing and
communication facilities used for development of software. This Guideline addresses procedure
that defines the separation of Organisation computing environments.
49.5 Responsibility
Roles
Software Development
Responsibilities
1.Set up software development and
operation environment
2. Test environment
3. Ensure the environment in compliant
with the general software guidelines,
access control and network access
guidelines
4. Address any recommendation from the
Quality assurance team
Quality Assurance
49.6 Procedure
The following control procedures should be considered by the Organisation software
development team;
Run development and operational software on different computer processors, in different
domains, or in different directories.
Separate development and testing activities from production activities.
Prevent the access of software development utilities from operational systems, when not
required.
Avoid using the same log-on procedures, passwords, and display menus for both operational
and test systems, to reduce the risk of accidental log-on and other errors.
Implement controls to ensure that administrative passwords for operational systems are closely
monitored and controlled.
Define and document the procedure for transferring software from development to operational
status. Such transfers should require management approval
50.2 Objective
To minimize the risk of system failure due to inadequate testing and validation acceptance of
new or upgraded information systems
To ensure that user accept a system that working in accordance to the specified and outlined
user requirements
50.3 Scope
The scope of system Acceptance testing shall apply to Organisation information processing and
communication facilities; this Guideline addresses the requirement for system acceptance
testing of all new or upgraded Organisation information systems and services.
System acceptance testing shall apply to software that is developed in house and software the
is developed externally by software vendors on behalf of Organisation
50.5 Responsibility
Roles
Software Development
User Department
Responsibilities
1. Co-test the system with end users.
2. Develop a technical test criteria
3. test technical test criteria
4. Provide pass fail result
5. Address all fail results in-order to get
approval.
1. Develop a test criteria for the system
2. Design and develop test scripts.
3. Test the software
4. Provide pass or fail results to software
development team
5. Approve software once all test have
passed
50.6 Procedure
User acceptance testing is a very critical part of the software development life cycle and the
same criteria for systems acceptance testing shall apply for all system i.e. developed internally
or externally developed by the vendor on behalf of Organisation.
A System Acceptance testing criteria shall be compiled by the user department of the system
and the criteria shall be developed based on the approved user requirements and scope of the
project. The main aim of the testing criteria which shall be in the form of test scripts is to confirm
whether the system is working accordance to requirements.
Once the test criteria is developed through test scripts a pass or failure decision will also be
determined based on the scoring or performance of the system in deferent areas.
Where the systems passes the acceptance testing it shall be handed over to the user
department and where fails it may go back to any of the phases before acceptance testing for
correction.
51.2 Objective
To respond to serious attacks quickly and effectively, reducing any potential business impact
and to reduce the risk of similar incidents occurring.
To ensure that Organisation is able to identify perpetrators of malicious acts and that
Organisation preserves sufficient evidence to prosecute them if required.
51.3 Scope
The scope of incidents is limited to incidents that require the activation of the Computer Incident
Response Team.
This does not cover operational incidents that are managed by the service desk.
The document also does not cover incidents that have been escalated to disaster management
51.5 Responsibility
Ref
Department
CIRT
Role(s)
The CIRT is comprised of a Team Leader and team members
with various roles and responsibilities.
The Team Leader is responsible for the following:
11. Making the judgement on whether the incident
should be classed as an Incident type I or II.
12. Constituting the appropriate CIRT for the incident
and assigning technical and support (e.g.
research, scribing and welfare) responsibilities.
13. Providing
a central reporting point and
coordinating response efforts.
14. Scheduling periodic status update meetings as
appropriate.
15. Ensuring that the CIRT follow set procedures in
responding to incidents and that documentation
of events is comprehensive.
16. Escalating the incident information to department
management. Providing a contact point for
support departments.
Technical Team members are responsible for the following:
17. Promptly responding to queries and requests
from the Team Leader.
18. Participating
in evaluating and resolving
incidents.
19. Accurately and comprehensively documenting
their actions.
20. Evaluating the incident response.
The Welfare role (optional) is responsible for the following:
4. Ensuring team members have access
to the premises outside regular
working hours if required.
5. Organising safe parking for team
members outside regular working
hours.
6. Provision of refreshments for team
members required to work long hours.
Transport to and from work, if required.
Note: All members of the ICT Department are potential
Technical and Support Team members.
Users
a. Users should immediately report any suspicious activity
that may indicate a security incident is in progress to the
Help Desk administrator. For example virus warnings,
unusual behaviour of the workstation, unreasonable
51.6 Procedure
There are seven roles that constitute the incident management structure. The responsibilities of
each of these roles are detailed below;
239 | East Africa Public Health Laboratory Network Project
1.
2.
3.
4.
Note: All members of the ICT Department are potential Technical and
Support Team members.
xiv.
Users
b. Users should immediately report any suspicious activity that may indicate a
security incident is in progress to the Help Desk administrator. For example
virus warnings, unusual behaviour of the workstation, unreasonable figures
in applications, denial of service etc.
xv.
xvi.
xvii.
Security Administrators
a. Security Administrators report any suspicious activity reported by the monitoring
tools to the CIRT leader. They may also be called upon by the CIRT leader to
determine and implement a solution.
xviii.
Support Departments
a. Support departments include Administrative Services, Human Resources,
Security, and Legal who may be required to participate in resolution of the
incident. ITD management will request them for support in incidents that require
their involvement for example if the incident is caused by a power failure or is
deliberately caused by a staff member or if there is likely to be violence.
Request will be made according to the communications plan (Appendix A).
b. When support departments participate in incident resolution, they will be
responsible for accurately and comprehensively documenting their activities and
submitting the report to the CIRT leader. Activities will be recorded in the
Actions Taken Form (Appendix B).
xix.
Vendors
a. Vendors work with the CIRT team to resolve the incident.
Threat Environment
i.
The threat may be from an internal source i.e. any person authorised to
access the Organisation Network (employee, contractor, consultant, external
support staff, etc.) or from an external source i.e. one without authorised
access to the Organisation Network services.
ii.
Technical Incidents
i.
Hardware Failure; Failure of infrastructure that leads to a disruption of any
Organisation Network service for more than sixty (60) minutes. Infrastructure
includes network devices, cabling, servers and the components included therein
241 | East Africa Public Health Laboratory Network Project
iii.
iv.
Power Failure; Loss of power to any Organisation Network component that leads
to a disruption of any Organisation Network service for more than thirty (30)
minutes.
Note: The minimum Recovery Time Objective for Organisation Services is sixty (60)
minutes for critical systems.
Security Incident
i.
Malicious Code Attacks; Viruses, worms, Trojans, and spyware that lead to a
disruption of any service on the Organisation network.
ii.
iii.
52.2 Objective
The objective of this Guideline is ensure that all Incidents falling under the respective classes
are identified and reported
52.3 Scope
This Guideline relates to all system related incidents for Organisation systems
52.5 Responsibility
Roles
CIRT
Users
Help desk
Responsibilities
1. identify all security incidents
2 log the security incidents
1. Identify all potential security incidents
and report to help desk
1. record all potential incident for
evaluation by the CIRT
52.6 Procedure
Identification of the nature of the incident involves 8 steps which have been outlined
244 | East Africa Public Health Laboratory Network Project
below;
Activity
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Description
Determine systems or services
affected, symptoms and
frequency
Report to CIRT leader
Determine if it is an incident
Determine whether to block
activity
Record incident information in
Incident Report (Appendix 1.4)
Activate CIRT
Determine whether and who to
notify: System owner, all staff
etc. according to
communications plan( If
Available)(Appendix 1.1)
Decide whether to escalate to
Strategy and Risk Management
or Audit. If escalation is agreed
perform actions in XXX
Actor (s)
Service Desk / User Support /
Technical Support/security
operations
Service desk / user
support/technical support/security
operations
CIRT leader in consultation
CIRT leader in consultation
CIRT leader
CIRT leader
IT dept. management in
consultation with CIRT leader
IT dept. management in
consultation with CIRT leader
ii.
Note 2: Only the people required to know about the incident should be notified.
iii.
Note 3: All notification from the CIRT will be through the CIRT leader and this should be
according to the communications plan. If the email is unavailable, information for all
staff will be communicated to Departmental Risk Liaison Officers and Secretaries in
addition to notice board posts. (Appendix XX).
iv.
Note 4: In the absence of the CIRT Leader and deputy, the decision to block the activity
will be made in consultation with any ITD manager. In the absence of IT department
management as well the System Administrator or Security Administrator will make the
judgement on whether to block the activity
52.7 Reference
245 | East Africa Public Health Laboratory Network Project
Ref
Document name
ISO 27001 and ISO 27002 Standards
Information Technology Infrastructure Library (ITIL
Control Objectives for Information and Related Technology (COBIT)
R.1
Organisation/ICT/02/01/Annex 9 Contingency Planning
Organisation/ICT/02/01/Annex 11 - Incident
Logging / Identification and protecting
evidence
R.3
R.2
Organisation/ICT/02/01/Annex 13 - Escalation
of Incidents to disaster management
53.2 Objective
The main objective is to preserve evidence for further investigation, for use in the
evaluation phase, to improve protection and procedures, and for use in case the Organisation
decides to take legal action.
53.3 Scope
Information security incident management process includes:
i.
procedure for conducting a forensic investigation
ii.
iii.
iv.
v.
Details of how the process complies with a published standard or code of practice
for the recovery of admissible evidence.
53.5 Responsibility
247 | East Africa Public Health Laboratory Network Project
Roles
End Users
User Help Desk
Responsibilities
1.Identify all potential incidents
2.Log the incidents with Help
desk
1.Record all incidents
2. Escalate the incidents to the
CIRT for action
53.6 Procedure
The forensic investigation approach must include steps to:
Establish and document a chronological sequence of events log investigative actions
Demonstrate that evidence has been collected and preserved in accordance
with guidelines and best practice rules of evidence and chain of custody
Secure target IT systems
Ensure that processes used to create and preserve evidence can be repeated
by an independent third party
Limit information to authorised individuals and ensure that it is kept confidential.
Include steps to classify the information in accordance with the CRCB
Information Classification Standard
Relevant results from the forensic investigations must be reported to authorised senior
management, legal, or regulatory bodies as required.
Forensic investigations must only be carried out by authorised individuals.
54 Organisation/ICT/02/01/Annex 12 - Containment of
Incidents
54.1 Description
Containment of incidents is critical and there is need to limit the magnitude of an incident as
quickly as possible and not to let it continue in order to get evidence.
54.2 Objective
The main objective is to preserve evidence for further investigation, for use in the
evaluation phase, to improve protection and procedures, and for use in case the Organisation
decides to take legal action.
54.3 Scope
249 | East Africa Public Health Laboratory Network Project
This Guideline relates to all system related incidents for Organisation systems result
54.5 Responsibility
Role(s)
ICT Department
Responsibilities
1. Contain all identified incidents by
isolating the problem
CIRT
54.6 Procedure
The procedure for containment of incidents is as below;
Determine the cause of the incident
Determine the source of the incident
Determine the appropriate response:
1. whether to isolate a system, segment or service
2. Whether to shut down a system or service. whether to change passwords
and the particular passwords that must be changed i.e. specific system
passwords, or all users passwords
3. Any other response
Provide updates to IT department management as detailed in the communications plan
Contact all possible support options, internal and external to Organisation.
Contact the Vendor Manager
Decide whether to escalate to SRM.
Diligently record all observations, assumptions, decisions, actions, people spoken or written to,
date and time.
If the attack is network based, the team should be careful not to alert the intruder. Avoid a flurry
of email or other in-band communication, a change in established routines, indiscrete
discussions etc.
In the absence of the CIRT Leader and deputy, determining an appropriate response will be
made in consultation with any IT department manager.
In the absence of IT department management as well, the System Administrator or Security
Administrator will make the decision.
If a system is suspected of being compromised, do not log in as root or Administrator if
it can be avoided.
Consider use of relay teams in the CIRT if the incident requires working late hours. Team
members should not work more than 12 hours at a time.
Refer to the list of IT department staff contacts. A comprehensive list of contacts (internal and
external) to be maintained on the IT Intranet webpage or with the Vendor Manager.
Document all the lessons learned
Guideline Name
Organisation/ICT/02/01/Annex 11 - Incident
Logging / Identification and protecting
evidence
R.2
Organisation/ICT/02/01/Annex 13 - Escalation
of Incidents to disaster management
R.3
Organisation/ICT/02/01/Annex 14 252 | East Africa Public Health Laboratory Network Project
Eradication of incidents
55.2 Objective
The main objective is an orderly transfer of incident management from this Incident Response
Plan to Disaster Management.
55.3 Scope
This Guideline relates to all system related incidents for Organisation systems
55.5 Responsibility
Role(s)
CIRT
Responsibilities
Escalate disasters to the disaster
management team based on the
organization business continuity plans
and disaster recovery plans
55.6 Procedure
The procedure for escalating incidents includes;
Formally escalate to Strategy and Risk management department
Compile known information for handover to Recovery and Resumption Team Leader (Refer to
Organisation Disaster Recovery Plan)
Continue containment activities until Disaster declaration is made
Hand over leadership to Recovery and Resumption Team Leader
Store evidence in a secure location
254 | East Africa Public Health Laboratory Network Project
Section
Reference
Guideline Name
54
R.2
56 Organisation/ICT/02/01/Annex 14 - Eradication of
incidents
56.1 Description
Eradication of incidents is important to Organisation in order to prevent re-occurrence of the
incident
56.2 Objective
The main objective is to remove all traces of the incident and prevent recurrence.
56.3 Scope
This Guideline relates to all system related incidents for Organisation systems
Responsibilities
1. Eradicate incident based on the
agreed resolution procedures
2. Document the lessons learned and
update the incident resolution register.
3. share the knowledge with the rest of
the organization
56.5 Procedure
In order to eradicate the incident, the following should be performed
Remove or resolve the cause of the incident.
Implement appropriate protection techniques to prevent recurrence
Perform vulnerability analysis on systems connected to the affected system.
Resolve any incident related issues
57.2 Objective
The main objective is to restore the affected system(s)/devices to their normal mission status.
57.3 Scope
This Guideline relates to all system related incidents for Organisation systems
57.5 Responsibility
Roles
CIRT
Responsibilities
1. Implement incident resolution
procedures.
2. Confirm that the incident has been
resolved.
3. Carry out confirmation test
4. Inform the organization that the
incident has been resolved.
57.6 Procedure
Determine what needs to be done to restore affected systems
Define recovery action plan
Get the necessary approvals for recovery actions
Implement the recovery decisions
259 | East Africa Public Health Laboratory Network Project
58.2 Objective
The main objective is to improve incident management in the department.
58.3 Scope
This Guideline relates to all system related incidents for Organisation systems
58.5 Responsibility
Department
CIRT
Role(s)
1. Evaluate the incident report
2. Determine root causes
3. Put in place mitigation
recommendations
4. inform the organization where
necessary
58.6 Procedure
Determine the response quality to the incident
Determine the incident costs including staff time, recovery purchases, outage time, vendor costs
and legal costs if any and include in Incident Report
Review existing Guidelines and procedures in light of the incident.
Submit Incident report that includes lessons learned, costs, resolution timeframes and Guideline
or procedure amendment proposals.
Determine action items to improve incident management
Submit lessons learned information to ITTC for inclusion in security awareness courses.
Update Risk Register
262 | East Africa Public Health Laboratory Network Project
R.1
59.2 Objective
To ensure that all incidents are closed off successfully and evidence is maintained for
future reference
59.3 Scope
This Guideline relates to all system related incidents for Organisation systems
59.5 Responsibility
Department
CIRT Team leader
Role(s)
1. Ensure that the incident has been
closed
2. formally close the incident
3. Inform the CIRT
59.6 Procedure
Closure of incidents involves;
Storing evidence in a secure location
Formally disbanding CIRT by communication to their managers
Email Account
Internet Access
Laboratory Information System
Hospital Management information system
Dept:
I hereby confirm that the aforementioned will be/is a member of my dept and requires an
IT Network Login and E-Mail account (delete E-mail if not required):
SIGNED (HOD/HOS):___________________________________________________
61 Organisation/ICT/02/01/Annex 19 Deletion of
Account form
DELETION OF ACCOUNT FORM
NOTIFICATION OF COMPANY LEAVER (FOR AN ICT/EMAIL ACCOUNT)
Name:
Dept:
I hereby confirm that the aforementioned is leaving/has left the employ of Organisation
and his/her I.T. Systems access can be removed as specified above.
SIGNED (HOD/HOS):___________________________________________________
Other Account(s)
62 Organisation/ICT/02/01/Annex 20 Change
Management form
APPLICATION/SYSTEM:
ISSUE/DESCRIPTION SUMMARY:
RAISED BY:
Signature (Sponsor)
PRIORITY
HIGH:
Name
MEDIUM:
Date
LOW:
BUSINESS IMPLICATIONS
DETAILS:
SYSTEMS/INFRASTRUCUTRE IMPLICATIONS
DETAILS:
IT APPROVAL
RECOMMENDATION:
SIGNATURE:
] APPROVED
NAME:
DATE: ____/____/____
[
] FURTHER ANALYSIS REQUIRED (EXPLANATION
BELOW)
EXPLANATION:
SIGNATURE:
NAME:
] APPROVED
[
] APPROVED WITH MODIFICATION (EXPLANATION
BELOW)
[
DATE: ____/____/____
[
] FURTHER ANALYSIS REQUIRED (EXPLANATION
BELOW)
SIGNATURE:
EXPLANATION:
NAME:
DATE: ____/____/____
IMPLEMENTATION
SIGNATURE:
DATE IMPLEMENTED:
____/____/____
63 Organisation/ICT/02/01/Annex 21 Computer
Equipment Purchase/Requisition form
Computer Equipment Requisition/Purchase Request Form
Department
Type of Request
(Check one)
Date
Replacement
Additional
Check
Model
Tablet
Notebook
Desktop
Printer
Scanner
Other
Justification (Include information about how the equipment will be used and
by whom. If you are requesting high-end specifications, be very explicit about
the function that requires)
Justification (Include information about how the equipment will be used and
by whom. Be very explicit about the function that requires non-standard
equipment)
Responsible Signature: ..
Print Name: .
Request Status (ITC use only)
Approved (Yes No)
Date
Remarks
64 Organisation/ICT/02/01/Annex 22 - Codification
Framework for ICT Guidelines and Procedure Manual
Codification Framework
We propose a codification Framework for Organisation Documents in which all documents
developed would be referenced in the following manner:
[Organisation/UNIT/CATEGORY OF DOCUMENT/NUMBER OF DOCUMENT or NAME]
For Example;
LEVEL ONE
(Company)
Organisation
Organisation
Organisation
Organisation
LEVEL2 (Unit)
[Department]
[Department]
[Department]
[Department]
LEVEL 3
(Classification),
MANUAL
GUIDELINE
FORM
FORM
LEVEL 4 (Name or
Number)
ICTSOPs
01
02
01
Note: All operational Manuals will have to be given names/numbers within this framework
and reference as such in the ICTSOPs.
Ref. No
1
2
3
Type
Guidelines
Manuals
Staff matters
4
5
6
7
General Correspondences
Board and Government communications
Legal matters Agreements, Contracts, court
issues
Audit
8
9
Procurement tenders,
Forms
10
Description
Guideline documents
Operational Manuals
Internal memos, letters to
staff
Letters, etc.
LOGO
Version
Description
Changed
By
Date
1.0
First draft
__________
______
Table of Contents
Introduction/Background
Problem Statement
The problem of . causes.. which means that
<1to 3 sentences describing the business problem for which this system is the solution>
3. Solution Statement
1. The XXX System will
<a 1 to 3 sentence description of how the system will solve the problem described in the problem statement including the benefits of the system to the
business.>
4. Positioning
The XXX System replaces the MMM system currently in use. The XXX System will interact with the yyy system and the zzz system providing
nnn services to its users.
<a paragraph describing the positioning of the system relative to other systems or business processes currently in use. If this is a product that is offered for
sale, describe the positioning of the product within the market >
5. Business Process
The XXX System automates the business process described in Business Process Model
280 | East Africa Public Health Laboratory Network Project
6. Key Features
Feature 1
Feature 2
<10 to 20 bullet point features of the system. Include, technology as well as functionality if it is a particular feature. These will be elaborated in detail in the
Use Case Model and the Non-functional Requirements. Include the order in which they are to be implemented if known e.g. Stage 1, 2 and 3 features.
Change the hyperlink to point to these models/documents>
Description
User Type
Description
<a stakeholder is anyone who is substantially and materially affected by the system development. This list of stakeholder and user types will be used to
gather stakeholder requirements in order to ensure that all requirements are given proper consideration. User is a sub-type of stakeholder>
Refer to Stakeholder Needs List for details of requirements gathered from the above stakeholder types <change the hyperlink to point to the
281 | East Africa Public Health Laboratory Network Project
Project Role
Name
Product Sponsor
Project Manager
Business Analyst
User
Analyst/Programmer
Support
Test Developer
<adjust and complete the above table as required>
Appendix A - Diagrams
A.1 XXXX Model <name of the diagram or model being included>
<insert the diagram here.>
File Reference: file_name.doc < If it is maintained outside of this document and copied into it, give a reference to the model file name>
Date created/copied into this file: nn/mm/pp <insert the date here>
<add any further diagrams that are deemed relevant to summarizing the project>
reference
Mapping
Incident Management
Help desk
Change Management
Service Level
Management
of
software,
infrastructure
hardware
including
All user support is managed through the help desk within the IT Department. An ICT
SOP on help desk has been developed to manage day to-day support of users on
issues related to computer hardware, software and Networks and provides the process
to be followed. IT is the responsibility of the ICT personnel to resolve the problem
based on their capabilities.
Incident Management
There are some incidents that a logged with the IT department that may not be the
Helpdesk
and
files,
routine problem e.g. server, database crush that may result in disruption of the
business of the entire business. These are referred to as incidents and there are
procedures that have been developed under incidents to manage the situation until
c.
Software installation
Change Management
d.
Network
security
for
satellite
network
infrastructure.
e.
PC
Operating
environment (see definition). The changes come in the form of upgrades, configuration
Systems
Installation
and
Upgrades
f.
g.
h.
Change management deals with changes that are implemented to the computing
The ICT SOPS have been developed based on the following Pseudo code;
Policies
and
Guidelines
on
Periodical
Support and
Maintenance;
A procedure have been put in place for the process of maintenance and the apply to all
Anti-Virus;
Service Level
maintenance activities can are also performed within the organisation and are done by
management
hardware
equipment
maintenance
(Preventive
a.
Computers
b.
Printers
Anti-Virus
c.
Photocopying machines
Anti-Virus procedure and guidelines have been described as a separate policy and
d.
Scanners
these policy are targeted at all the users including the ICT department
Service level Management
Service level management guidelines and procedures are responsible for invoking
maintenance procedures that are contractual with the organisation
Notes
The terms of reference have mentioned maintenance to apply to specific hardware i.e.
printers, computers and photocopiers and scanners. Maintenance should also apply to
all computing and networking hardware (routers, switches, firewall, digital projectors).
Maintenance can also apply to software.
The ICT SOPs have been developed based on the following pseudo code
Environmental Controls
This ICT SOP deals with best practice of the ICT environment on provide guidelines on
networking equipment;
Back-up
how to protect ICT hardware equipment, cabling and wiring and protection of the ICT
a.
Incident Management
hardware equipment and general ICT environment. It also deals with UPS battery
b.
c.
Help Desk
Back-up
Anti- Virus
Full procedures on back up have been developed to also include the requirement of
UPS
Service Level
Server backup/restore
Management
Anti-virus
Security Monitoring
The antivirus SOPs have been developed to manage the inter organisation or
necessary
d.
virus scanning.
e.
Server backup/restore
f.
All server and network problems shall be logged with the help desk using the help desk
problems.
ICT SOPs. Depending on the severity of the problems should these problems also
cause significant business disruption then the incident management procedures should
be invoked.
Support and Maintenance, Service level management
Policies
and
Guidelines
on
management
a.
b.
The email ICT SOP cover usage and management of the email within the organisation,
control
the Email ICT SOPs covered the creation of users for email briefly however for greater
Change management
detail on the process the ICT Access control should be referred to as is covered all
Service Level
standard procedures to be followed in ICT Systems Access Controls and the change
Management
management procedures are important for managing users access rights such as
The relationship between the organisation and the ISP should be managed through the
contract between the two organisations hence the service level management ICT
SOPs.
Security Monitoring
Back up
Incident Management
The back-up ICT SOPs cover all back up requirement as outlined in the terms of
Back Up
reference including additional requirement based consultation with the requirement with
a.
Acceptable use
b.
c.
d.
Incident Management
disk.
disaster.
Acceptable use
Acceptable use are referenced in this section to manage the compliance with this
particular ICT SOP
Notes on Encryption and Security
On data Encryption and Security it is important to ensure security of data in storage
and when data is being transmitted
Therefore encryption has been managed as follow
For data transmission and storage this is a covered in the following SOPs
a)
b)
c)
d)
e)
Project Management
The various SOPs for this section of the terms of reference have been covered in the in
Software development
Security Monitoring
Project Management
e.
Information Management
Back up
Software development
f.
System configuration
Help Desk
Security Monitoring
g.
System customization
Change Management
Back up
h.
System upgrade
Help Desk
i.
System maintenance
Change Management
j.
System monitoring
k.
Database analysis
l.
System security
a.
Information Management -
m. Advanced troubleshooting
b.
n.
c.
o.
System functionality
d.
p.
System maintenance
e.
q.
System troubleshooting
r.
level management
f.
System monitoring
g.
Database analysis
h.
i.
j.
k.
l.
Procurement
Procurement
SOPs on procurement have been developed however it should be pointed out that
they should be in full compliance with the procurement guidelines of the organisation
as well as government
regulations
9. SOPs on Training
Training
Training
An SOP on training has been developed this SOP must be used in conjunction with
the Organisation SOP in training from the Human Resources Department.
Network Configuration
Network Access
These SOPs deal with configuration and access of the network including the type of
network and the relationship the organisation should have with third parties such as
Access
Software development
Software development
Development of Web
A full ICT SOP on Software development has been developed to cover the process of
Applications
software development
Software Security
Requirement
This section covers security requirement for software and also covers Web
Applications
SOPs on Web development, hosting, presence and content
An SOP on Web Development hosting and Content has also been developed
Network Access
20.
21.
Network Configuration
The purpose of the Organisation Network Configuration ICT SOP is to establish the
rules for the maintenance, expansion and use of the network infrastructure. These rules
are necessary to preserve the integrity, availability, and confidentiality of Organisation
information.
Network Access
To enable Organisation control all connections to its networks in order to preserve the
private nature of the Organisation's network and computing facilities In this section the
Wireless network Access is defined
Security Monitoring
workstations)
Health)
Service level
management
Inspections
The NATIONAL dataflow level (national domain dataflow): Between the End User, the
National laboratory / IT service supplier, and the National Repository, or, any other
EAPHLNP network related national data flows.
The exchange of data in the EAPHLNP network context can be modelled as follows
1. Authentication and administration Data: Exchanged from End User to National
laboratory, and vice versa. Authentication data clearly identify the End User, and document
its entitlement for the service. Part of this data is added to the logs.
2.
Transactional data: Exchanged between the End Users National laboratory of the
Partner state, and the National laboratory of the Partner state.
3. Validation data: Exchanged between the National laboratory and the End Users.
Validation data may contain customer administrative data, validation decision data,
additional data qualifying the transactions, etc. (existence and content based on general
design).
For the NATIONAL dataflow, the actors should respect the respective national legislation
on privacy and data protection and other related national legal provisions in effect.
For the CROSSBORDER (interstate) dataflow, as an East African network, the EAPHLNP
actors/partners will respect at least:
o
SR 001
Description
SR 002
SR 003
SR 004
End user identification and authentication means must have been audited
and certified by an independent organization which is certified by the
national authorities according to best practice international standards.
SR 005
SR 006
SR 007
Rules SR002, SR003, SR004 are a national (national level) competency, while rules SR005,
SR006, SR007 are a pan African (EAPHLNP network level) competency.
1.2
The following list describes the EAPHLNP laboratories interconnectivity security objectives and
requirements that are identified as critical for the security of the EAPHLNP laboratories
interconnectivity system and processes and form the basis for constructing the Security Policy.
These requirements are based on the security best practices in the field of Health and Laboratory
under the EAPHLNP.
1.3
1.3.1.2 Make users aware about information security and train them using the
authentication mechanisms in place. Users must understand the related
standards and policies and recognize and accept the responsibility for
protecting the passwords, tokens, private keys, etc., by signing the related
statements.
Reference
the
EAPHLNP
laboratories
interconnectivity
1.3.4.2 End Users must be clearly identified by the National Laboratories before
being able to enter the system.
1.3.4.6 The system is using appropriate procedures to ensure data for audit trail
1.3.4.7 Special attention must be given to the Root Certificate Authority, which is
issuing the certificates for the National Portal (Portal to Portal certificates), in
order to ensure that this Certification Authority can be trusted and can be
accepted as root authority. For this purpose the root Certification Authority
must be certified by the national authorities or equivalent (e.g. the Webtrust
programme for Certification Authorities, the standard framework of
AICPA/CISA, tScheme, or equivalent).
1.4.1.3 National laboratory Data and Privacy protection procedures in place must
have been audited and certified by the responsible national data protection
supervisory body.
1.4.1.6 Audit must approve the fulfillment of the application installation and
operation of security principles and guidelines.
Legal framework
Arrangement of Regulations
PART I PRELIMINARY PROVISIONS
1. Citation
2. Interpretation
PART II ESTABLISHMENT
3. East Africa Public Health Laboratory Network Project
PART III ADMINISTRATION
4. Composition and functions of the Committee
5. Financial Responsibility for required Infrastructure
PART IV INFORMATION TO BE STORED ON THE NETWORK
6. Data sharing of Health and Labaratories databases of Partner States
7. Externally sourced information
PART V INFORMATION TECHNOLOGY
8. Application of Information Technology
9. Mode of exchange of Information
10. Document Management System
11. Data Security and Integrity
12. Data Storage
13. Back up of information.
14. Incident reporting
15. Operational guidelines
PART VI ACCESS, USE AND CONFIDENTIALITY PROVISIONS
16. Use of Information
17. Confidentiality of information
18. Personal data protection
19. Access to Information
303 | East Africa Public Health Laboratory Network Project
PART 1
PRELIMINARY PROVISIONS
1. Citation and Commencement
These regulations may be cited as the East African Community Health Laboratories
Management (Health Laboratories Interconnectivity) Regulations 2012 and shall come into
305 | East Africa Public Health Laboratory Network Project
2. Interpretation;
22. In these Regulations unless the context otherwise requires Assignee in relation to users of the Network, means a person to whom an Authorized
User has delegated their duty and therefore right to access information attached to the
Authorized User.
Authorized User means an official of the Laboratory department of a Partner state
nominated as the person who should have access information over the Network and
shall include an assignee.
National Health Laboratories Database means an information depository operated
by the East African Community relating to Health Laboratories matters and fed
information by the Health Laboratories departments of the EAPHLNPpartner states.
Committee means the Committee as established under the East Africa Public Health
Laboratory Network Project
Computer means an electronic, magnetic, optical, electrochemical or other data
processing device or a group of such interconnected or related devices, performing
logical, arithmetic or storage functions; and includes any data storage facility or
communications facility directly related to or operating in conjunction with such a device
or group of such interconnected or related devices;
Computer Service includes computer time, data processing and the storage retrieval
of data;
Computer system (Kenya KICA) means a device or collection of devices including
input and output devices but excluding calculators which are not programmable and
capable of being used in conjunction with external files which contain computer
programmes, electronic instructions and data that perform logic, arithmetic, data storage,
data retrieval, communication control and other functions;
Content includes components of computer hardware and software;
Cyber harassment includes the use of a computer for any of the following purposes
a) making any request, suggestion or proposal which is obscene, lewd, lascivious or
indecent;
b) threatening to inflict injury or physical harm to the person or property of any
person; or
c) Knowingly permitting any electronic communications device to be used for any of
the purposes mentioned in this section.
Damage means any impairment to a computer or the integrity or availability of data,
program, system or information that
INFORMATION TECHNOLOGY
SCHEDULES
1.5
The aim of this section is to describe, the EAPHLNP network minimum security
requirements.
Following the logical architecture of the EAPHLNP Health laboratories interconnectivity
network and taking care of the complexity of the project, it would seem to be useful to divide
the security requirements into three levels.
1st level - Security requirements for the EAPHLNP network as a whole (that is
environmental requirements).
2nd level - Security requirements for the National Health Laboratory (ies) (NHL) in each
partner state, starting from the observation that each National Health Laboratory must
exchange information -in a standard way- with all the others..
3rd level Minimum acceptable common security requirements for the different National
Information Infrastructure in each partner state, starting from the observation that
different levels of security requirements may have been established by the different
NHLs in each Partner state (MS).
o
Identification;
Authentication;
Access control;
Non repudiation;
Data confidentiality;
Data availability;
Logging of any operation, performed by whatever User (Active Actors), which has an
impact on security.
Requirement Specification
EAPHLNPnetwork level
1.5.1.1 Identification: For each EAPHLNP laboratories interconnectivity network user
(actor) a valid and unique electronic identity must be established. The standards to
which this is unique/valid must be established by agreement.
1.5.1.2 Authentication: The identity of EAPHLNP laboratories interconnectivity network
Users (before each system access, transaction or message) must be validated.
1.5.1.3 Robustly Authenticating Users: Each MS must robustly grant the authentication of
his own Users. The conditions on which a single MS may guarantee the User
authentication, may be based on technical and/or organizational measures, These
measures, in any case, should provide that the authenticated entity must not be
repudiated.
1.5.1.4 Access control: The confidentiality and integrity of EAPHLNP laboratories
interconnectivity network information assets must be protected by preventing
unauthorised access and use (protection from both the technical and
organizational point of view).
1.5.1.5 Access control, privilege management and DHCP authorization): the authorization
with which an identified and authenticated user can get access to customer tax
information must be based on the role assigned to the user (as defined by the
Health Laboratories MS organization or authority), on the verification of the parent
Health Laboratories organization that that user is handling that specific customer
transaction.
1.5.1.6 Confidentiality: The unauthorized disclosure of personal information during the
transfer, processing and storage within EAPHLNP laboratories interconnectivity
network must be strongly prevented. The use of cryptographic mechanisms should
be adopted.
1.5.1.7 System and data integrity): the integrity of data within EAPHLNP laboratories
interconnectivity network documents, transactions or messages must be assured
for both data rest and transit.
1.5.1.8 Availability: It must be ensured that information assets are, according to the
Requirement Specification
service level agreements agreed, available in a timely and reliable manner when
needed in the scope of their professional activity by authorised EAPHLNP Users
(or actors/agents) and systems.
1.5.1.9 Non Repudiation: it must be ensured that both the User-Originator and the UserReceiver of documents and messages cannot deny their actions (documents
production, message sending, message receiving).
1.5.1.10
Auditing: it must be ensured that each action which has an impact on security
or privacy must be audited. In any case auditing information must not include
personal client data.
1.5.1.12
provide tools able to discover possible frauds in the use of Health Laboratories
data.
1.5.1.13
Traceability: It must be ensured that log data can be connected from different
how to destroy all data objects created for the EAPHLNP laboratories
interconnectivity network after its conclusion
1.5.1.15
Controller must guarantee the respect of the privacy obligations foreseen by its
National Law and the East Africa Community directives.
1.5.1.16
Trust: each MS should show evidences of the respect, by its own Health
1.5.2.1 NHL identification: a NHL must have a unique electronic identity in a common
cryptographic domain (such as, for example, digital certificates following x509
Standard).
1.5.2.2 NHL local User Identity &Access (I&A): I&A of each local User (NHL technical
staff) must be performed before he/she starts processing. The tool/mechanism
used (individually or with other security tools/mechanisms/procedures) for I&A
must prevent the Users identity (previously submitted to I&A) from being
repudiated.
1.5.2.3 Authenticating Network Access: each NHL must ensure that all connections to
remote computers and servers (for other NHLs, agents and local systems) and
applications are authenticated.
1.5.2.4 Digital Signatures: if in a MS the EAPHLNP laboratories interconnectivity network
Users apply a digital signature, then the MS-related NHL must be able to:
verify that the digital signature is valid (this implies that the user certificate is
also valid)
1.5.2.5 Digital Signatures: if a MS does not adopt a digital signature, then the MS-related
NHL must be able in any case to:
1.5.2.6 confirm to any other MS-NHLs connecting, the data integrity of the exchanged
data through a digital signature.
1.5.2.7 Access Control: a NHL must provide Access Control mechanisms which provide
functionalities that allow, for a given User, the specification of which data and
services the User can get access to, and which privileges the User has with regard
to the data and services.
1.5.2.8 Confidentiality: a NHL must use strong cryptographic mechanisms to prevent the
unauthorized disclosure of personal confidential information or security critical
system data during the transfer and processing within the NHL itself if this
processing has confidentiality vulnerabilities.
1.5.2.9 Protecting Source and Destination Integrity during data transmission): the source
and destination of the message during data transmission between NHLs in Partner
States must be protected to maintain its integrity.
1.5.2.10
Protecting Data Storage: if storage is performed, a NHL must protect
confidential information or security critical system data it contains. The use of
pseudoanonymization mechanisms should be used if possible or reasonable.
1.5.2.11
System and data integrity: a NHL must ensure, by strong cryptographic
mechanisms, the ability to discover if the Health Laboratories information has been
altered or destroyed in a unauthorized manner, so that that Health Laboratories
information may not be further processed.
1.5.2.12
Availability: NHL best effort must ensure the respect of the agreed Service
Level Agreements.
1.5.2.13
Non Repudiation: a NHL must have a strong cryptographic mechanism (e.g.
RSA) to ensure the non repudiation of each document produced by itself or
messages exchanged with other NHLs.
1.5.2.14
Accounting and Control: a NHL must have a mechanism to record every
access request and disclosure of Health Laboratories information and
transactional data, together with the time and identity of the accessing User.
1.5.2.15
Accounting records must be maintained as long as the EAPHLNP
laboratories interconnectivity network lasts, unless otherwise legally required.
1.5.2.16
Auditing: it must be ensured that each action which has an impact on security
is recorded. If data to be recorded contain both transactional and personal data,
an anonymization or pseudo-anonymization process should be used if possible or
reasonable. In any case the recorded data must not contain personal client data,
but can contain a unique identifier to a data object. Audit records must be
maintained as long as the project lasts, unless otherwise legally required.
1.5.2.17
Fraud detection: NHL must provide tools to discover possible frauds in the
use of Health Laboratories data.
1.5.2.18
Continuously Logging: logging on the NHL should be operational at all times.
In case of failure, the NHL involved must inform all the other NHLs.
1.5.2.19
Securing Access to Audit/Account Logs: a NHL must secure the access to
audit records to prevent misuse or compromise.
1.5.2.20
Logging Transactions: a secure audit record must be created each time a
User asks to access tax information of a client or to send an e-notification.
1.5.2.21
Trust: it should be allowed to submit each NHL to a second part security
audit procedure performed by the other MS, so that it will be possible to verify the
compliance with the security requirements established by the EAPHLNPPartner
States agreements.
the organisation of the accessing User (at least in those cases where an
1.5.2.22
1.5.2.23
Reporting Every Access Health Laboratories tax information, notifications
included): it should be possible to identify all requests to access to any clients
record(s) over a given period of time according to different parameters (Users,
clients records, etc)
procedures should be established for carrying out the agreed back-up strategy
taking back-up copies of data and rehearsing their timely restoration, logging
events and faults and, where appropriate, monitoring the equipment environment.
1.5.3.13
1.5.4.1 Identity and Authorization (I&A) of a User: I&A of a User must be performed before
he/she starts processing. The tool/mechanism used (individually or with other
security tools/mechanisms/procedures) for I&A must prevent the Users identity
(previously submitted to I&A) from being repudiated.
1.5.4.2 Access Control): an Access Control tool/mechanism which enables access to
Health Laboratories information on the basis of the User Identity and the role (and
related authorizations) he/she plays, must exist.
1.5.4.3 Confidentiality and Integrity: confidentiality and integrity of the tax information
produced, sent or stored, must be guaranteed. Data should be protected by the
use of acknowledged (by the single MS) cryptographic algorithms.
1.5.4.4 Audit & Accounting: a process which allows the collection and the consultation of
the information of both the actions performed by the Users and the events which
impact on security must exist. All the data collected must be protected from
unauthorized access.
1.5.4.5 Identified Purposes: Organisations connecting to the EAPHLNP network and
organisations hosting components of the EAPHLNP laboratories interconnectivity
network must only use or disclose health and health Laboratory information for
purposes consistent with those for which it was collected, except in the case of
client consent or if permitted (or required) by law.
1.5.4.6 Segregating Network Users, Services and Systems: Organisations hosting
EAPHLNP network components must introduce network controls to segregate
information services, Users and information systems that are not involved in
access to or hosting of the EAPHLNP interconnection systems. Separated
management networks are recommended.
1.5.4.7 Privacy: each EAPHLNP laboratories interconnectivity data Controller must
guarantee the respect of the privacy obligations foreseen by its National Law.
1.5.4.8 Trust: each MS should show evidence of the respect, by its own Health
Laboratories information system, of the security requirements established by the
EAPHLNPdata exchange agreements agreement
Objective
To define how:
EAPHLNPpersonnel emplyees, agents and third party users must understand their
EAPHLNPpersonnel emplyees, agents and third party users are deemed suitable for their
roles
providers must have undergone a background check by their respective organizations and
the assurance of the same shall be provided to EAC. Information provided by personnel, at
338 | East Africa Public Health Laboratory Network Project
All employees and agents must sign and agree to the information security agreement
(Schedule III, regulation 20) before connection the EAPHLNP network is granted by the
committee.
Management Responsibilities
All supervisory roles are responsible for the performance and conduct of the staff personnel
reporting to them.
conduct of each of their staff, as well as to assess their impact on the security of the
Information Assets to which the staff has access.
Employees, agents, contractors and third party users are required to agree and sign nondisclosure obligations (Refer to Schedule III, regulation 20, information security agreement).
Users are required not to disclose organisation information derived as a result of their
access to EACs Information Systems to unauthorized parties.
Disciplinary Process
There shall be a formal disciplinary process for employees, contractors or third party users
who have violated the organizational security policies and procedures. Such a process can
act as a deterrent.
treatment of employees, contractors and third party users who are suspected of having
committed serious breaches of security.
Termination of Employment
EAPHLNP must ensure that termination of employees, contractors and third party users are
done in orderly manner and responsibilities are defined within EAPHLNP to ensure the
same.
Return of Assets
All employees, contractors and third party users must return all of the organizations assets
in their possession upon termination of their employment, contract or agreement.
1.5.5.1
applicable laws.
Managers and supervisors shall ensure that all security procedures within their area of
responsibility are carried out correctly to achieve compliance with security policies and
standards.
SCHEDULE 3:
The information security agreement referred to under Regulation 20 shall be in the format
below
EAPHLNP may temporarily suspend or permanently block access to the network services
and resources, prior to the initiation or completion of an investigation, when it reasonably
appears necessary to do so in order to protect the integrity, security, or functionality of the
EAPHLNP network or other computing resources or to protect the EAPHLNP from liability
I realize privacy is not guaranteed on the EAPHLNP connectivity network, and any
transmission is subject to review. My use of the EAPHLNP provided network services will
constitute acceptance of the information security policy and regulation, and consent to
monitoring while using the EAPHLNP network services.
I understand that I am personally liable for my misuse of EAPHLNP network provided by
EAPHLNP. I also understand failure to adhere to this policy and regulation may result in
disciplinary action up to and including termination of my employment and or services by my
employer. I also understand that failure to comply with the policy and regulations referred to
herein may result in criminal prosecution in the courts of law
By signing this Agreement, I understand and agree to abide by the conditions imposed
above
Name:
_________________________________
Department: __________________________________
Job Title:
___________________________________
Signature:
_______________________________
Date:
__________________________
Copy provided on (date) _______________________
By (Supervisor) _________________________________
The relevant supervisor or supervising authority shall send a copy of a signed ISA to the
Committee as provided for in the regulations.