The Office of the Minister of State for Administrative Reform (OMSAR) provides the contents of the ICT Standards and Guidelines documents, including any component or part thereof, submission, segment, form or specification, on an 'as-is' basis without additional representation or warranty, either expressed or implied. OMSAR does not accept responsibility and will not be liable for any use or misuse, decision, modification, conduct, procurement or any other activity of any nature whatsoever undertaken by any individual, party or entity in relation to or in reliance upon the ICT Standards and
Guidelines or any part thereof. Use of or reliance upon the ICT Standards and Guidelines is, will be and will remain the responsibility of the using or relying individual, party or entity.
The ICT Standards and Guidelines are works in progress and are constantly being updated. The documentation should be revisited regularly to have access to the most recent versions.
The last date of update for this document was June 2003.

1.0
Executive Summary for Information Integrity and Security ..................... 1
2.0
The Background of Security and Information Integrity ............................ 3
2.1
The Scope of Information Integrity and Security ................................... 4
2.2
The Objectives and Benefits of Information Integrity and Security ........... 4
2.3
Policies for Proper Information Integrity and Security ............................ 5
2.4
Risks Resulting from the Standardization Activities ................................ 5
2.5
Related Documents ........................................................................... 6
2.6
How to Use This Document? ............................................................... 6
2.7
Related Terms and Acronyms ............................................................. 6
2.8
Related Segments and Cross References .............................................. 7
2.9
Related International Standards .......................................................... 7
2.10
All Segments in the ICT Standards and Guidelines ................................. 8
3.0
Roles and Responsibilities in Security and Information Integrity ............. 9
4.0
Process 1 - Security Awareness ............................................................. 10
5.0
Process 2 - Securing Equipment ............................................................. 11
5.1
Operating Systems .......................................................................... 11
5.2
Virus Protection .............................................................................. 11
5.3
Server Rooms ................................................................................. 12
5.4
Mandatory Conditions for Intrusion Detection System Software ............. 12
5.5
Security Checklist when Installing a New System ................................ 12
6.0
Process 3 - Securing the Network .......................................................... 14
6.1
Network Connectivity ....................................................................... 14
6.2
Internet Connectivity ....................................................................... 14
6.3
File and Data Transfers .................................................................... 14
6.4
Remote Access ............................................................................... 14
6.5
Remote Control ............................................................................... 15
6.6
TCP/IP Packet Filtering ..................................................................... 16
6.7
Shunning ....................................................................................... 16
6.8
Islanding ........................................................................................ 16
6.9
Domain Name Service (DNS) ............................................................ 17
6.10
Honeypot ....................................................................................... 17
7.0
Process 4 - Securing Applications .......................................................... 18
7.1
Software Applications ...................................................................... 18
7.2
Web Applications ............................................................................. 18
7.2.1
Virtual Private Network (VPN) ................................................. 19
7.2.2
Secure Socket Layer (SSL) ..................................................... 19
8.0
Process 5 - Securing Passwords ............................................................. 20
8.1
Password Standards ........................................................................ 20
8.2
Creating and Maintaining Passwords .................................................. 20
9.0
Process 6 - Securing Protected Data ...................................................... 22
10.0
Process 7 - System Access Management ................................................ 23
10.1
SOP 1: Identify Functions to be Secured ............................................ 23
10.2
SOP 2: Assign Privileges and Access Rights ........................................ 25
10.3
Good Practice: Insure the ICT Systems .............................................. 28
11.0
Process 8 - Backup and Data Protection ................................................. 29
11.1
SOP 3: Identify What is to be Backed Up and When ............................. 30
11.2
SOP 4: Backing Up .......................................................................... 32
11.3
SOP 5: Identify What is to be “Restore Tested” and When .................... 34
11.4
SOP 6: Restore Testing .................................................................... 35
11.5
Good Practices: Back Up and Restore ................................................ 36
12.0
Process 9 - Disaster Recovery and Contingency Plans ............................ 39

12.1
SOP 7: Disaster Recovery Procedures ................................................ 40
12.2
SOP 8: Business Continuity - Contingency Plans .................................. 42
12.3
Good Practices: Disaster Recovery .................................................... 43

Figure 1: CERT Statistics on Security Breaches Since 1990 ................................ 3
Figure 2: Password Standards .......................................................................... 20
Figure 3: Access Rights Matrix ......................................................................... 25
Figure 4: Typical Roles with Access Rights ....................................................... 26

This segment provides a uniform practice for use by government organizations toward protection of ICT equipment, operations, and resources within the government of
Lebanon.
These standards apply to all computing resources for the creation, modification, transmission, retention, deletion, manipulation, and presentation of information in electronic format. For purposes of this standard, computing resources include, but not limited to, all computer equipment, interconnecting devices, supporting data communications, workstations, terminals, peripherals, programs, and data.
The IT Unit manager at the Ministry or Agency is responsible for implementing and maintaining the security policy. In large ministries and agencies, it is recommended that the role of Security Officer be created within the IT Unit.
Security is an ongoing process that does not end with the implementation of a security schema or software. Furthermore, most security solutions are designed and implemented as a result of a particular threat. With this in mind, this standard describes the minimum security and information integrity requirements. These are:
Security Awareness
It is recommended that each ministry or agency prepare a Security Awareness Booklet and that the staff be trained on it. Human Beings are the weakest link in security breaches and they should be educated on the agency’s passwords policy, handling their workstations, reporting security threats, and protected data.
Securing Equipment
The security of equipment must be ensured first at the operating system set up level and with the installation of virus protection software. Then the IT Manager must select and install an Intrusion Detection Software (IDS) on network equipment. The mandatory conditions for selecting an IDS are given. Finally, the security of equipment depend on the availability of secure server rooms free from dust, food, and fire which can be more threatening to security as hackers attacks.
Securing the Network
Ministries and Agencies may not be connected to untrusted networks. The only exception is the Internet. For that a DMZ must be established to protect the inside network. Rules for using file and data transfers over the internet are given as well as remote access and remote control over the internet. Finally, for blocking attacks, several techniques are described. These are TCP/IP packet filtering, shunning, islanding, and honeypot.
Securing Applications
While not all applications manage access the same way, most application allow some degree of access differentiation. Applications must support role-based security whereby user access to application and data are granted based on the functional role of the user.
A Standard Operating Procedure is given to assign role based access rights.
For Web applications, they must generate and manage the session ID in order to solve the stateless and sessionless issues of the Internet. In order to prevent the user ID, password, and other data from being captured on the network, the segment proposes
Information Integrity and Security Page 1

the use of Virtual Private Networks or SSL encryption. All session keys must be 128 bit long for all systems that have direct or indirect access to Protected Data.
Securing Passwords
All systems must use passwords as the main authentication method. Passwords must be at least 8 characters long with at least 2 numeric and at least 4 alpha characters. The standard also describes the standards for creating and maintaining passwords.
Securing Protected Data
Protected data is data that the Ministry or Agency may deem confidential. The Security
Officer must be told if an ICT system handles protected data. Protected Data should be encrypted using PKI technology natively inside the database.
Information Integrity
The unavailability of ICT systems or data may disrupt business at the Ministry or Agency over periods of different lengths. In order to maintain the business continuity, the standard identifies three standard operating procedures.
Backup
Data needs to be backed up daily by the IT manager on a removable media. A copy of the last full backup must be taken off site.
Disaster Recovery
Disaster recovery is the process of rolling up data from the backup tape into the system that suffered the loss of data. The IT manager should periodically test the recovery procedure to insure that it will be operational in case of need.
Contingency Planning
During down time, the standard describes how the Ministry or Agency can revert to manual operations that can be entered in the system once it is up and running. The contingency plan minimizes the Ministry or Agency down time.
Information Integrity and Security Page 2

Security breaches are damaging and embarrassing incidents to organizations. For some industries, such as banking, investment, or healthcare, security breaches inflict such a deep scar in confidence that some organizations are unable to recover. Security breaches have much more pronounced consequences for governmental organizations.
Security protects an information system from unauthorized access to its information and interference with its operation.
The threats can be both micro and macro in nature. Micro threats are those that affect a
Ministry or Agency or an agency. Damages are limited to systems and data which reside within the affected Ministry or Agency or agency. Macro threads are those that impact the entire government or the entire country. It is important to understand that all threats are inter-related. That is, all micro threats have macro implications.
The awareness of security risks on networks and systems are heightened after several high-profile attacks. However, there are still great needs for understanding information security. Traditionally, security equated to network security and system security.
However, with the advent of the Internet, all networks are now subject to penetration attempts by intruders on a global scale. As a result, security breaches are increasing at an alarming rate. According to CERT (Computer Emergency Response Team), an organization of the Carnegie Mellon University that tracks security breaches around the world, the number of security breach incidents has increased to over 2,500% since the
Internet became the medium of choice for the dissemination and acquisition of information. Figure 1 shows the increasing trend of security breaches since 1990.
Figure 1: CERT Statistics on Security Breaches Since 1990
This chart displays a very critical phenomenon. Notice the trend turns sharply upward beginning 1998 - the dawn of electronic commerce.
Information Integrity and Security Page 3

2.1
The Scope of Information Integrity and Security
These standards provide a uniform practice for use by government organizations toward protection of ICT equipment, operations, and resources within the government of
Lebanon.
These standards apply to all computing resources for the creation, modification, transmission, retention, deletion, manipulation, and presentation of information in electronic format. For purposes of this standard, computing resources include, but not limited to, all computer equipment, interconnecting devices, supporting data communications, workstations, terminals, peripherals, programs, and data.
These policies and standards apply to all Ministries or Agencies of Lebanon. They are to be observed by all Lebanese government employees, contractors and other authorized users of the government’s computing resources. Controls for external use of government systems and services through network access service provider are established in contracts between the Lebanese government and each external user.
Security is an ongoing process that does not end with the implementation of a security schema or software. Furthermore, most security solutions are designed and implemented as a result of a particular threat. With this in mind, this standard describes the minimum security and information integrity standards for application in ministries or agencies. These are:
Security Awareness 
 Securing Equipment
 Securing the Network
 Securing Applications
 Securing Protected Data
 Securing Passwords
 Disaster Recovery
 Contingency Planning
The administrators and employees of each Ministry or Agency should not hesitate to impose more stringent standards if, in their judgment, these are necessary to satisfy the mission needs of the Ministry or Agency.
Security and Information Integrity controls should address threats in a cost effective manner that does not seriously interfere with the productivity of the applications and users. In protecting information from such threats, security measures are intended to preserve desirable security attributes, including confidentiality, integrity, availability or auditability.
2.2
The Objectives and Benefits of Information Integrity and Security
Technology undoubtedly is becoming the tool for organizations of the future. Along with this growth, a parallel increase in attempts on gaining unauthorized access, through the
Internet, to computer systems will occur. Protecting the systems, thus, becomes a strategically integral part of securing and implementing an enterprise technology plan.
While planning and implementing security strategies, it is important to be aware of the following:
Information Integrity and Security Page 4

 The investment made to acquire and implement proper security is an ongoing process and cycle. Continuous vigilance is essential to ensure implementation of sound security practices; and
 e-Security is a strategic line of defense. Intruders with their attempts to penetrate counter all actions taken to defend against outside intrusion.
The CERT report reveals the known fact that, as long as networks and systems are connected to the Internet, they will be vulnerable to penetration. Although this is a risk every organization takes, it would be in rash judgment to entertain the thought of disconnecting an enterprise network from the Internet. The benefits that the Internet has brought to an organization and continues to bring far outweigh the risks caused by network penetration and the damage it would affect. As long as e-security is implemented and managed properly, network penetration attempts shall be thwarted.
Operationally, security benefits outweigh the cost of procuring the tools. According to an estimate made by Bear Stearns, a global investment banking and financial services company, the typical security breach costs a firm an average of $1.8M. This figure is expected to escalate with the ongoing growth of Internet based applications and the likelihood of organizations gradually evolving into e-Enterprises.
The best approach to prevent security breaches is to apply protective measures across the entire environment consistently. This requires a set of standard policies and procedures. Standardizing policies and procedures provides the following benefits:
2.3
 Allows for consistent measure of degree of exposure
 Provides an environment in which the level of protection is consistent
 Prevents breaches through “back-doors”
 Facilitates the tracking of potential and actual breaches
Policies for Proper Information Integrity and Security
 Clear procedures should be initiated to implement such processes.
 A discipline must be implemented to monitor and control their proper use
 Research into new breeches, security technologies and other information integrity methods should be ongoing. This allows the Government to maintain a state of the art environment for information integrity and security.
 Where needed, the proper legal framework needs to be implemented for handling situations where security breeches occur.
 Awareness at all levels should be promoted to ensure that information integrity and security policies are known to all concerned.
2.4
Risks Resulting from the Standardization Activities
The following risks might arise upon the implementation of security policies proposed in this segment:
 That the government will show no commitment to monitor and control these policies
 Human errors will cause many security risks
 Lack of knowledge of security
 Bugs in various software products that are not known or investigated
Information Integrity and Security Page 5

 Using software without proper security features
 Not setting the security features of software properly
 Not staying up to date on security updates: patches, releases, work arounds,
 Not designing applications with security in mind
 Having an unclear set of roles and responsibilities to setup and maintain the security policies proposed in this segment
 Not having disaster recovery plans in case security is broken
2.5
Related Documents
Two documents are presented with this segment:
 Encryption Standards and Algorithms
 Password Systems
These can be downloaded from OMSAR's website for ICT Standards and Guidelines at www.omsar.gov.lb/ICTSG/SC .
2.6
How to Use This Document?
This document covers 9 major processes:
Process 1 - Security Awareness
Process 2 - Securing Equipment
Process 3 - Securing the Network
Process 4 - Securing Applications
Process 5 - Securing Passwords
Process 6 - Securing Protected Data
Process 7 - System Access Management
Process 8 - Backup and Data Protection
Process 9 - Disaster Recovery and Contingency Plans
There is no specific sequencing for these processes. They can be reviewed and applied as needed.
2.7
Related Terms and Acronyms
Compromise A violation of the security system such that an unauthorized disclosure of sensitive information may have occurred.
DMZ Demilitarized Zone, a network created by connecting two firewalls.
Systems that are externally accessible but need some protections are usually located on DMZ networks.
IDS Intrusion Detection System, a software application that can be implemented on host operating systems or as network devices to monitor for signs of intruder activity and attacks.
Firewall a system or group of systems (router, proxy, gateway...) that implements a set of security rules to enforce access control
Information Integrity and Security Page 6

between two networks to protect 'inside' networks from 'outside' networks. Commonly used between the Internet and an Intranet.
Protected Data The term Protected Data is the designated level of security for information, whether in electronic or other forms physical or otherwise, that should not be released without proper authorization. The information, if compromised, posts a undesired outcome to the Ministry or Agency that owns it.
Examples of Protected Data are: budget for a project and request for proposal work in progress.
Protected Data must is identified at the Ministry or Agency level who is the only body that can authorize release of its Protected
Data.
2.8
Related Segments and Cross References
The following segments relate directly to Information Integrity and Security. They are listed with their website locations:
102 www.omsar.gov.lb/ICTSG/NW
104 www.omsar.gov.lb/ICTSG/DB
105 www.omsar.gov.lb/ICTSG/OS
Networks
Database Systems
Operating Systems
202 www.omsar.gov.lb/ICTSG/SW Software Applications
Each page contains the main document and supplementary forms, templates and articles for the specific subject.
2.9
Related International Standards
ISO17799 ISO17799 is a comprehensive set of controls comprising best practices in information security. It is an internationally recognized generic information security standard.
The standard is intended to serve as a single reference point for identifying a range of controls needed for most situations where ICT systems are used in industry and commerce facilitation of trading in a trusted environment
X.509
X.9.32
Secure Socket Layer
Source: International Telecommunication Union. http://www.itu.int/home
Source: International Telecommunication Union. http://www.itu.int/home
Source: Netscape http://dev.netscape.coom
Information Integrity and Security Page 7

2.10
All Segments in the ICT Standards and Guidelines
OMSAR's website for ICT Standards and Guidelines is found at www.omsar.gov.lb/ICTSG and it points to one page for each segment. The following pages will take you to the home page for the three main project document and the 13 segments: www.omsar.gov.lb/ICTSG/Global www.omsar.gov.lb/ICTSG/Cover
Global Policy Document
Cover Document for 13 segment
101 www.omsar.gov.lb/ICTSG/HW
101
102
202
203
204
205 www.omsar.gov.lb/ICTSG/Legal www.omsar.gov.lb/ICTSG/HW www.omsar.gov.lb/ICTSG/NW
103 www.omsar.gov.lb/ICTSG/TC
104 www.omsar.gov.lb/ICTSG/DB
105 www.omsar.gov.lb/ICTSG/OS
106 www.omsar.gov.lb/ICTSG/EN
201 www.omsar.gov.lb/ICTSG/QM www.omsar.gov.lb/ICTSG/SW www.omsar.gov.lb/ICTSG/EV www.omsar.gov.lb/ICTSG/SC www.omsar.gov.lb/ICTSG/DE
Legal Recommendations Framework
Hardware
Hardware Systems
Networks
Telecommunications
Database Systems
Operating Systems
Buildings, Rooms and Environment
Quality Management
Software Applications
Evaluation + Selection Framework
Information Integrity and Security
Data Definition and Exchange
206 www.omsar.gov.lb/ICTSG/RM
207 www.omsar.gov.lb/ICTSG/CM
Risk Management
Configuration Management
Each page contains the main document and supplementary forms, templates and articles for the specific subject.
Information Integrity and Security Page 8

The IT Ministry or Agency Head or IT Manager is responsible for the application of the standards and procedures related to ICT security and referred to as the “security policy”.
In large ministries or agencies, it is advisable to appoint a Security Officer within the IT
Ministry or Agency dedicated to the application of the security policy.
The role of the Security Officer cannot be under estimated because instating a security policy is not a guarantee for achieving security. Security must be planned for and implemented on a case by case basis. Most security breaches must be traced and investigated also on a case by case basis. Furthermore the maintenance of the security measures in place is as important as instating them.
The roles and responsibilities of the Security Officer include but are not limited to:
1.
Know the security policy of the Ministry or Organization
2.
Know which data is protected and which is not
3.
Prepare and update the security documentation
-
Security Awareness Booklet (optional)
-
List of Systems, list of access rights per system (see section 10.0)
4.
Intervene during the installation of any new equipment and system to insure that security schemes have been planned for and implemented
5.
Perform backups on all servers
6.
Test the recovery procedures periodically
7.
Perform routine checks on operating systems logs and systems audits to try to identify evidence of security attacks attempts.
Determining data retention requirements or in conjunction with the legal 8.
requirements
9.
Resolve audit reports of access rule violations
10.
Handle and resolve the security violation incidents. As in any set of pre-planned procedures, attention must be paid to a set of goals for handling an incident. A specific set of objectives can be identified for dealing with incidents:
 Figure out how it happened.


Find out how to avoid further exploitation of the same vulnerability.
Avoid escalation and further incidents.
 Assess the impact and damage of the incident.
 Recover from the incident.
 Update policies and procedures as needed.
 Find out who did it (if appropriate and possible).
Information Integrity and Security Page 9

In any secured environment, the strongest part is the weakest link. Historically, human elements are the most often the weakest link. Therefore, it is important to ensure the personnel who is authorized to have access or power to administer and maintain any systems is not a potential risk for security breach.
It is advisable that each Ministry or Agency should produce a Security Awareness
Booklet. The Booklet is a way to bring security awareness to personnel. The Security
Awareness Booklet must contain, at a minimum, the following:
 Password privacy policy
1.
Do not reveal password to anybody at any time and for any circumstances
2.
Do not write the password down and never leave in the proximity of the workstation
3.
Do not use names, numbers or dates which are personally identified with you
4.
Change your password often, but change it immediately if you think it has been compromised
 Workstation management
1.
Powering the workstation on and off
2.
Leaving the workstation unattended
3.
Backup information that is not on the server
 Installation of unauthorized software. It is the government policy not to use pirated software. Personnel should be responsible for unauthorized installation of software on their workstations.
 Reporting of security threats or suspected security violations
 Protected Data (users must be aware if the data they are allowed to handled is protected by their Ministry or Agency)
 Secured System (systems containing protected data)
 All access is implemented within Role-Based access rights as seen in Section
10.0.
Information Integrity and Security Page 10

Equipment require their own security procedures. These are defined in the following sections.
5.1
Operating Systems
All servers must run on operating systems that meet ALL of the following criteria:
Users must logon through a valid user ID set by the system administrator with 
NO default user allowed (i.e. no user ID/password, no access)
 User account is disabled after three (3) failed attempts
 User is notified immediately and via e-mail whenever his or her account or password is changed
 Operating system must support activity logging
 Operating system must support directory access security
5.2
Virus Protection
Objectives: viruses are increasing in their damaging capability as well as the way they carry out such damages. The aim of this SOP is to provide Good Practices that reduce the problems associated with Virus infection to a minimum.
Risks: virus can corrupt data, stop access to systems, wipe out files and cause system slow down. In websites, they may create a denial of access to the site or even redirect traffic.
Good Practices and Recommendations:
1. Backup: one of the best insurance schemes against infection is proper data backup. This includes all operating or application software. Review the earlier activities in this Section for a discussion of backup procedures.
2. Use up to date anti-virus products with the latest patches and upgrades.
These have to be licensed to run on the various machines in the center.
3. Use up to date virus definitions: ensure that a responsible person regular checks and updates the data definitions of the viruses. Many centers wrongly assume that if they have the latest version of the software, they are protected. It is estimated that 200 new viruses are identified per month. Developers of anti-virus products frequently release new virus definitions to meet this surge.
4. System scans: on a regular basis, scan the whole system including zipped files.
This can be carried out at night when there is no work load on the system.
5. Importing data into the site: in the sites where there is a lot of traffic of data to and from the outside world, it may be required to implement strict techniques about using data on floppies or CDs or zip drive disks coming from the outside.
Some centers disable all such units. Others remove them completely. In the case where a center cannot remove a CD drive because of its internal use, it becomes critical to discipline users to scan CDs for viruses before using them.
Information Integrity and Security Page 11

6. Virus hoaxes: even though there are many virus hoaxes, it is better to be safe than sorry. Stories should be believed until proven innocent. There are several sites on the web published by the major anti-virus developers that list the hoax viruses. Virus warnings sent by mail should be checked against these sites. Here are some examples: http://www.europe.f-secure.com/news/hoax.htm
http://vil.nai.com/VIL/hoaxes.asp
http://vil.mcafee.com/hoax.asp
?
These and other sites will also list real viruses and explain what their effect is and they can be treated.
5.3
Server Rooms
Servers and other communication equipment should be kept in secure server rooms. The following security measures must be taken for server rooms:
Keep them dust free 
 Control their temperatures using air conditioning
 Keep them secure and locked at all times
 Do not allow food, drink, and cigarettes in server rooms
 Know where the fire suppression equipment is located and know how to use it
5.4
Mandatory Conditions for Intrusion Detection System Software
Intrusion Detection System (IDS) inspects every packet that comes through the router to determine if the packet contains data that may post a threat to the network. However, most IDSs, in order to gain higher throughput, take a myopia approach to packet content examination. As such, the effectiveness of packet screening is compromised.
Therefore, this policy is to provide a minimum capability necessary for an effective IDS.
 Must be state aware capable.
 Must be configurable for policy management
 Must have packet forensic analysis capability


Must support ANSI SQL server
Must be able to capture and inspect
 Must support shunning with “never shun” capable
 Encrypted inter-component transmission
 Integration with major enterprise management system (e.g. Tivoli, OpenView, or
Unicetner)
5.5
 Support interface monitoring speed of at least 1 Gbps
 Support independent interface for management functions
Security Checklist when Installing a New System
The following is a quick checklist when installing any new operating system. This checklist is also applicable to certain software application.
Information Integrity and Security Page 12

 Make sure the default user account, such as Guest, Root, and Default User, etc., is deleted. If deleting the default account is not allowed, change the default password and make sure the password should be expired and account is disabled after three (3) failed attempts. Follow the password standard in Section 6.
 Make sure all directories are restricted to administrator access only initially (add access later as needed).
 Turn off all remote debugging capability if the system is accessible from outside of the network or is on the same network where remote access or remote control server is connected.
 For operating systems and applications that support it, turn on access audit logging.
 For operating systems, disable all non-essential services.
Information Integrity and Security Page 13

The network is the first line of defense against security risks from external hackers.
Therefore, it is important to address the defensive techniques first. The following are the policies for securing the ministry or agency network.
This policy applies to network connectivity and networking equipment including, but not limited to, the following:
 Router
 Firewall
 Proxy Server,
 Local Area Networking (LAN) Hub
 LAN Switch
 Remote Access services (e.g. modem, Remote Access Server, Dial-up server, etc.)
 Remote Control Applications
6.1
Network Connectivity
Networking equipment may not have direct connection with any untrusted networks.
Untrusted networks are defined as networked that has not been audited by authorized personnel of the government agency. VPN and VN are considered trusted networks. The
Internet is the only untrusted network that is allowed to have direct connection with the
Ministry or Agency network.
6.2
Internet Connectivity
For networks that are connected to the Internet, a DMZ must be established to protect the inside network. All networking equipment in the inside network must be configured to isolate the internal network addresses (IP address or MAC address) from publishing to the Internet.
6.3
File and Data Transfers
Agency-to-agency data transfers or application integration should be done over private connections such as Virtual Private Network or secured terrestrial-based leased line.
File and data transfers over the Internet must be accomplished through Secure FTP.
All severs accepting files or data through the Internet must have a server version virus protection software installed and running.
6.4
Remote Access
Remote access allows a user to log on to a network from a remote location either through a dial-up connection or over the Internet. For purposes of this policy, remote access server includes dial-up server, WAP gateway server, terminal server, and Citrix server. It is an often-exploited area through user identity theft. It is important to realize that remote access, once connected, is at the system level not application level. Once logged on, a user will have visibility to all the systems and networks that are connected
Information Integrity and Security Page 14

to the logged on network. Care must be taken to consider remote access. Therefore, this policy should be strictly enforced at all times:
 Networks that have one or more remote access server connected must be isolated from other networks or systems that have access to Protected Data.
 Isolation must be done through one of the following methods: o Air gap o LAN switch segmentation o Router segmentation
 Remote access servers must support PKI technology.
 Remote access password and user ID must be encrypted natively using X.509 compliant digital certificate (i.e. password and user ID must be encrypted by the remote access client application prior to forwarding to the lower layer of the protocol stack).
 Communication between remote user and server must be encrypted throughout the entire session.
 Passwords for remote access log on must be follow the Password Standards
provided in Section 8.1.
6.5
Remote Control
Unlike remote access, remote control allows a user to take control of a system through a dial up access or over the Internet. Once logged on to a system, the user will have access or visibility to all other systems connected to the network. Since the reason for remote control is often to allow a user to execute applications on the controlled system, the controlled system is therefore allowed to access data that reside on the same system or on another system on the network. The controlled system is often a trusted system on the network or across networks. Therefore, remote control is an extreme threat to systems with Protected Data. This policy must be strictly enforced at all times:
All systems allowing remote control must be configured as follow:
 No systems having access to Protected Data can be connected to a network with remotely controlled systems.
 All remote control systems (server) must support PKI technology.
 Remote access passwords and user IDs must be encrypted natively using X.509 compliant digital certificate (i.e. password and user ID must be encrypted by the remote access client application prior to forwarding to the lower layer of the protocol stack).
 All communications between the client (controlling system) and server (controlled system) must be encrypted during the entire session using PKI.
 All passwords must be changed every 30 days.
Information Integrity and Security Page 15

 Passwords for remote access log on must follow the Password Standards provided
in Section 8.1.
6.6
TCP/IP Packet Filtering
This section provides the policy for packet filtering and operating system verbose configuration in responding to requests from other systems. This is a minimum standard;
Ministries or Agencies are free to apply policies that are more stringent.
TCP/IP Packet filtering should be applied to all boarder routers. This policy is to safeguard systems within a network from malicious attacks by hackers. These attacks may come in different forms and the signature of such attacks may various significantly from case to case. Therefore, in addition to applying packet filtering, the network administrator should be vigilant in reviewing logs from IDS and other captured files.
All boarder routers must be configured to filter out the following packets:
 ICMP echo request
 ICMP echo response
 ICMP resource quench
It should be noted that the following activities would not be available when the above packet filtering is implemented. However, the benefits of higher security outweigh the inconveniences. The activities that will not be available are:
 Ping
 Traceroute (Note: Unix traceroute uses UDP instead of ICMP)
 MTU discovery will not be available
 Host unreachable will not be available
6.7
Shunning
Shunning is a technique used to block attacks. Shunning can be done automatically or manually. Shunning is to block traffic from an offending IP address and its subnetwork.
It is important to make sure the shunning software is capable to implement “never shun” file. Since there are certain systems that should never be shunned. Shunning software is usually part of the IDS.
It should be noted, however, shunning does not help if the attacker is using two address families.
6.8
Islanding
Islanding is a last resort technique. Islanding is to shutdown the router thereby cutting the network from the outside world. This technique should be used whenever a System is being compromised or attacked and there is no immediate way to isolate the offending source and implement other blocking methods.
It should be noted, however, Islanding could be used as a denial-of-service attack by triggering the Islanding.
Information Integrity and Security Page 16

6.9
Domain Name Service (DNS)
DNS is a globally distributed system that depends on the cooperative interaction of many
DNS servers to collect records about other domains and to communicate with each other. DNS provides translation between host names and their IP addresses. DNS is an important component of the Internet so that systems can find each other without typing out the IP addresses, which can be difficult to remember. However, DNS is also a great source for hacker to conduct reconnaissance about a network. DNS can also be a way that hackers use to manipulate name and address translations for malicious purposes.
Therefore, it is important to protect the amount of information that a DNS gives out. This policy provides a minimum requirement for all DNS set up.
 No system information can be stored in the HINFO record
 Disable the dissemination or transfer of data functionality
 Disable the BIND version number display
 BIND version must support DNSSEC
6.10
Honeypot
This is a suggestion only and is not a policy.
Honeypot is an advance technique. When a system is found compromised, a new system is set up with minimum capability and a very small hard drive. Configure the new system with the IP address and host name as the compromised system (rename the compromised system). Install the Deception Tool Kit (DTK) on the “flake” system. This
“flake” system serves as the honeypot for hackers so that the real system is safe. The honeypot can also be used to collect information of the hackers.
Information Integrity and Security Page 17

This section provides the policies for user access to software applications. While not all applications manage access the same way, most applications allow some degree of access differentiation. Application security is important to since data are accessed through applications. For purposes of this policy, software applications include business applications and data base applications.
This policy does not include applications that are considered Office Productivity tools such as Microsoft Office™.
7.1
Software Applications
The following is the minimum requirements for application security:
 Applications must support role-based security. Role-based security is a security method whereby user access to application and data are granted based on the role of the users. The procedure that must be followed to build the list of access
rights is detailed in section 10.0.
 Applications that allow users to log on over the network or Internet must encrypt user ID and password natively (i.e. user ID and password are encrypted prior to transmission) using PKI technology.
 Communication between remote user and server must be encrypted throughout the entire session.
 Passwords for remote access log on must be follow the Password Standards
provided in Section 8.1.
 Applications should notify the user whenever more than one simultaneous logon occurs.
7.2
Web Applications
Web applications allow access to data through software applications that are accessible over the Internet. All web applications are vulnerable to security breach since HTTP (The protocol the web browser communicates with the web server) is stateless and sessionless. That is the web server does not check or validate the request’s identity nor does it care about if the first or second requests come from the same source. This design is primarily due to the use of the web in the early days to access static documents. When the technology is used as the transport of application data, session management becomes a key issue. All web-based applications generate their own session ID using a variety of mechanisms. For examples, Microsoft Active Server Pages uses cookie while others embed the session ID within the Universal Resource Locator (URL) or within the body of the web page.
While the session ID generated and managed by the web applications resolve the stateless and sessionless issues, the data transmitted between the browser and the web server is unencrypted. The user ID and password, for examples, can be captured by a
Information Integrity and Security Page 18

hacker “listening” on the network. There are a couple of ways to prevent such security breach: VPN and SSL.
7.2.1
Virtual Private Network (VPN)
The first method of protecting data from unauthorized access over the network is to set up the browser and server with a Virtual Private Network (VPN). The browser and server communicating over a VPN protect the data from being captured by any user outside of the VPN. Although this method provides the protection needed, it limits the availability of the system to those that are within the VPN. This method is useful for inter-agencies or inter-Ministry or Agency communications where the user universe is known and controllable.
7.2.2
Secure Socket Layer (SSL)
The second method of protecting application data is to encrypt the data using Secure
Socket Layer (SSL). SSL is a layered protocol. It first encrypts the data before it is transmitted to lower layer of the transport protocol. Therefore, all data except the URL are encrypted natively (i.e. prior to transmission). SSL provides the protection needed and does not have the limited availability issue in VPN.
While SSL encrypts data prior to transmission, it, nevertheless, transmits data over an open network. It, therefore, can be captured. Therefore, all session keys must be 128 bit long for all systems that have direct or indirect access to Protected Data.
Information Integrity and Security Page 19

Passwords are the most often used mechanism for software application, computer systems, networks, or electronic devices to authenticate users. However, the reliance on password as the sole identification method has always been questioned. This uneasiness is because the method relies heavily on the weakest link of the security process chain - the human being. The most common breach is through passwords that are written down somewhere in the proximity of the computer system. Passwords are also often intercepted on the network.
This policy is developed to ensure a standard and secured process of handling passwords from the point of creation to usage and modification.
The following paragraphs provide the policies for password creation and management. It also provides a discussion on password system and password generation algorithm.
8.1
Password Standards
All passwords length must be at least 8 characters long with at least 2 numeric and at least 4 alpha characters. This will give the follow combinations of password with weak keys of duplicating characters and numeric values eliminated:
Alpha
4
Numeric
4
5,118,131,200,000
3 2
5 21,291,425,792.00
6 55,357,707,059,200
Figure 2: Password Standards
This requirement will provide a password lifetime between 160 and 1,740 years
(assuming a guess rate of 61,370 per minutes).
The formula used to compute the number of passwords combination is
C p
=
n r1, r2
Where
C p
x 52 r1 x 10 r2
= Number of passwords available (password space)
n = Password length requirement
r1 = Minimum number of alpha characters
r2 = Minimum number of numeric characters
8.2
Creating and Maintaining Passwords
The following is the policy for creating and maintaining passwords for application access, system access, and network access. Please note that the password for physical entry to facilities may differ.
Information Integrity and Security Page 20

 Passwords are to be assigned only after the access rights have been defined. The
IT Manager must have an updated list of all users current at all times
 Passwords must be changed by the user once every 30 days.
 Password from the last two (2) changes cannot be used as new password.
 Passwords must be validated through known weak password file or database
(weak passwords are those that can be guess easily, such as birthday, wife’s name, etc.)
 Users must be informed that they do not to reveal the password.
 All new passwords must be required to change after the successful initial logon.
 Passwords must be expired after three (3) failed attempts (user account should be disabled at the same time).
 Disable the option of “Password do not expire” or similar function from any
 system.
User account should be disabled if the account has not been accessed for three
(3) consecutive password-change periods (i.e. 90 days or whatever the password change interval is).
 All Secured Systems must be able to create and maintain an audit trail of password usage and changes. The actual password should NOT be stored as part of the audit trail.
 All Secured Systems should notify the user immediately via e-mail whenever his or her password is changed.
Information Integrity and Security Page 21

This section provides the policies for security regarding Protected Data. For purposes of this policy, data means information stored electronically on a computer system or subsystem. This includes databases and files. This policy applies to access of the
Protected Data as well as encryption of the data stored.
 All Protected and Secured Data should be encrypted using PKI technology natively inside the database.
 All database systems containing Protected and Secured Data should have guest account removed.
 All database systems must change the default root password before deployment.
 All database systems must have their debug account deleted or disabled (for
Microsoft SQL server, delete the probe account).
 Directory access should be configured based on needs.
Information Integrity and Security Page 22

ICT Systems need to be secured so that specific functions can only be accessed by specific staff.
10.1
SOP 1: Identify Functions to be Secured
Objectives: in order to control access to ICT systems, the Ministry or Agency has to prepare a complete list of all functions that are to be secured. For each item in the functions list there would be a definition of the kind of accesses that may be allowed.
Scope of usage: typical functions are:
Access to the network 
 Access to a specific PC desktop
 Access to a particular database application
 Access to specific websites
 Access to physical locations
3.
4.
Standard Operating Procedure:
1. The Ministry or Agency’s management must decide who can prepare such a list.
2. List all types of ICT systems to be secured (See above list under scope as a guideline)
Define the functions to be secured in each system.
Define the nature of access. These are called Privileges. These can be of various types or levels:
 Record level: access to read, to write, to update, to delete records on the database
 Data element level: this is more specific than record level security. If a use can view a record, he or she will need to have special privilege to view specific data elements within the record. For example: a user may view the full purchase order but will need privileged access to view the purchase price, or to view the salaries on employee records, Etc.
 Function level: this is where the user can access major functions but will need privileged access to activate minor functions within them. For example, a user can create a purchase order but will need privileged access to update the exchange rate, or change payment date, Etc.
 Badges: Monitor entry manually through registration at the desk and the issuance of visitor badges
 Card Readers: Use automated badge card readers and provide staff with cards that can access specific areas in the center.
 Password Access: Use password protected door locks
Most of these items would have been detailed in the previous sections of this segment.
Information Integrity and Security Page 23

5. If the privilege is subject to an expiry period, then this has to be defined. This is useful when employees are given time restricted privileges such as when the supervisor is on leave and hands over his or her duties to someone else.
Documentation and Deliverables: the list of Accesses or Privileges.
Good Practices and Recommendations:
1. Privileges in customized software: when software is being designed, it is a good time to establish some of the above accesses and privileges. Many system designers leave the security at the level of the database and hence, expose the system to more than necessary.
2. Vendor security: database engines are often secured by a single password.
Knowing that password will allow intruders to access the database from outside the application. Special care must be had to ensure that such a password is protected either by making it dynamic or by changing it frequently.
3. Remote Access to Site: some Ministry or Agency’s provide remote sites access to their system. These sites are to be secured so that no illegal access takes place. It is important to ensure that all access from such sites is password controlled. As discussed in the previous paragraph, Encryption may be used to further secure the access. Should the access be through wide area networks, the communications protocols should be secured. It is important to be able to log the remote access and analyze it. Patterns in the usage of remote access may show illegal attempts at access.
4. Staff may change posts and may retain Physical Access privileges they are not supposed to have. Secondly, they may then be restricted from areas they are supposed to use. Review the list periodically.
5. In the case of access control through registry at the reception, it is important that persons entering are properly checked through the use of their IDs, staff cards,
Etc. When necessary, it can be dictated that such persons never enter the site on their own but that they are escorted by an authorized staff member.
Acceptance Criteria: The list is considered accepted when the Management approves its content.
Information Integrity and Security Page 24

10.2
SOP 2: Assign Privileges and Access Rights
Objectives: having identified the functions to be secured on the ICT systems, the next
SOP is that of determining the staff that can access the various functions and assign them these privileges.
Scope of usage: all staff that can access the system must be included. All the privileges defined in the previous SOP must be included.
Standard Operating Procedure:
1. The Ministry or Agency’s management must decide who can assign such privileges to the various members of staff.
2. Ensure that the previous SOP that identifies all Privileges and Access Rights has been completed.
3. Prepare a list of all users, i.e. the staff who might be allowed to access the system.
4. Group the staff by groups or roles to ease the task of assigning privileges and access rights. For example, all secretaries will have the same role. A new secretary will automatically inherit the same privileges and access rights as the rest of the group.
5. Define the access rights for each role. The access rights are the combinations of the above two lists into a matrix or a spreadsheet. At the top of each column, enter the name of the function. In each row, enter the name of the role. In the intersection of the column and role enter the privileges allowed to this role for this function as explained in the next paragraph.
6.
7.
8.
Figure 3: Access Rights Matrix
Define the privileges for each access right allowed. The privileges are four and are commonly referred to as CRUD for Create, Read (query, view, or retrieve),
Update, and Delete
If the privilege is subject to an expiry period, then this has to be defined. This is useful when employees are given time restricted privileges such as when the supervisor is on leave and hands over his or her duties to someone else.
In case the system is a database system, the access rights might not be limited to functions but need also be defined on the:
Information Integrity and Security Page 25

9.
 Record level: access to read, to write, to update, to delete a whole record on the database
 Data element level: access to a particular data item within the record such as the purchase price, or the salary of an employee. This is more specific than record level security and is used for Protected Data only.
In case the system is a database system, other people will have access to the system and/or the data. The table below shows the list of typical roles with access rights to the system:
Roles
System Administrator
Data Administrator
Network Administrator
System Owner
System Owner Level 1
System Owner Level 2
Role 1
Role 2
View Only User (Public)
Access to
System
Network
Administr ation
Access to
All Data
Data
Access
Limited to
Yes
Limited
Limited
No
No
No
No
No
No
No
No
Yes
No
No
No
No
No
No
File Level
Yes
No
Yes
No
No
No
No
No
All
Country
Regional
Specific
Specific
Figure 4: Typical Roles with Access Rights
System Administrator This user has access to all systems. This user is responsible for system maintenance and management such as software installation and operating system maintenance.
This user has visibility to all files on any system including the data files. This user does not have access to the data through applications.
Data Administrator This user has access to the data through the database system. This user will have access to the portion of the system where the database system, data file, and backup files are located.
Network Administrator This user has access to all network devices including router and IDS configurations. This user also has limited system access.
System Owner This is usually the Ministry or Agency head who has commissioned the application. He is the user responsible for maintaining the functional administration for business applications (e.g. for financial application, the functional administrator will be adding new users, updating users access rights within the financial application). This user typically has all access to the data accessible by the application he or she owns.
Information Integrity and Security Page 26

Documentation and Deliverables: the list of all staff and their related Privileges and
Access Rights.
Good Practices and Recommendations:
1. Review the list periodically as Staff may change posts and may retain privileges they are not supposed to have. Secondly, they may then be restricted from privileges they are supposed to use because of the change.
2. Review the list of Privileges regularly as new software is introduced or existing software is modified or enhanced. Such software may have holes from which unauthorized persons may access functions they are not authorized to access.
Acceptance Criteria: The list is considered accepted when the Management approves its content.
Information Integrity and Security Page 27

10.3
Good Practice: Insure the ICT Systems
Objectives: to present a set of Good Practices that aim at insuring the various ICT resources in the Ministry or Agency. The financial value of a Ministry or Agency’s systems along with related equipment may reach a high enough value to warrant such insurance.
Scope of usage: insurance can cover a variety of losses. These are defined in the Good
Practices section below.
Good Practices and Recommendations:
1. Equipment: all equipment such as computers, communications components, printers, scanners, etc, can be insured proportional to their financial value. These can easily be insured against theft, sabotage, damages due to various reasons or acts of civil strife.
2. Loss of documentation: training, operating and other documentation form a major part of the ICT resources. Such documentation can be lost due to theft, negligence, water, Etc. These can easily be insured.
3. Loss of Work: loss of time spent on work caused by Force Majeure or other damaging situations can be insured. Such work can be insured: recovery costs, rework, reentry of data, reinstallation of software and systems, cost of the emergency procedures, Etc.
4. Loss of Source Code: this often happens in different ways. Source code may become inaccessible for various reasons. Source code may be corrupted. Wrong backup may take place. Backup media may be destroyed due to various reasons.
The Ministry or Agency can also insure itself against such losses.
5. Loss of Software Products: some of the more expensive products can be insured. Loss may take place due to theft, corruption of media, loss or theft.
In many cases, losses can be averted by proper backup, increased Risk Analysis and better physical security management as shown in the previous Activities in this Section.
In the case of setting up a Disaster Recovery System, various works can be insured.
Review paragraph (3) in the
Information Integrity and Security Page 28

One of the most frequent causes of damage or the highest risks in ICT Systems is loss of data or its corruption. The reasons are many: equipment breakdown, operator error, software bugs, Etc. The only effective measure that can be taken to ensure that
Information Integrity is maintained in an acceptable state is to have a rigorous Backup and Archiving policy.
Some Definitions
Backup is the storage of data, source code, software products, scripts, Etc., on a separate medium that can be used to restore the data to its initial form if need be. This could be a regular or an ad hoc activity.
Archiving: This term is essentially the same as Backup. However, some centers use it to signify removal of the data or cyclical backup that is not very frequent. In all cases, the procedures are the same as for Backup, so this Guide will not differentiate between the Backup and Archiving.
Purging: Removing data from the initial medium to make space or reduce database size. Example: transactions are kept within the operational database for the current and the most recent 3 years. On completion of each year, the ICT Unit would need to purge the oldest year from the database.
Checkpoints: these are points in time where the Ministry or Agency has to take a full backup so that disaster recovery schemes can be used to restart the system from such
Checkpoints. (Review Section 12.0 on Disaster Recovery)
The following Activities present various procedures and good practices related to the above.
Information Integrity and Security Page 29

11.1
SOP 3: Identify What is to be Backed Up and When
Objectives: the purpose of this SOP is to document the data, software or other electronic information that need to be backed up and/or purged. A Backup Definition
List will define the scope of the data and will include a variety of information about each specific backup.
Scope of usage: the following is a recommended list of data and software but is not restricted to these items. These are targets for back up:
Operational data (Used by the various software applications)
Development data
Source Code
Scripts
Web pages
Graphics used in screens
Documentation and help files
Test scripts
Test plans
Operating data
Shell scripts
Operating Instructions
Software products
Libraries
Compiled systems (To avoid recompilation on restore)
Off the Shelf Commercial Software
Updates / Upgrades / Patches
Operating Systems / Tools / Utilities
User Data
Data that is processed on client stations and centrally stored on servers
Reports
ASCII based output
COLD technology output: Computer Output on Laser Disks
Acrobat Reader output (PDF files)
Risks: not preparing a proper list of items to be backed up will cause the Ministry or
Agency to be exposed to loss of data.
Standard Operating Procedure:
1. Classify the types of data to be backed up as suitable for the Ministry or Agency.
Refer to the Scope of Backup above for a proposed classification.
2. List all data in appropriate groups. For example, it is inappropriate to backup master files alone and without their related transaction files. These should be backed up with all related transaction and parameter files.
3. Prepare the Backup Definition List which contains the following data elements:
 The frequency of backup: Daily, weekly, monthly, end of cycle, Etc.
 When to backup: In case backups are required on an ad hoc basis.
 The type of backup: is this an incremental backup or does it fully replace the data? Is it a purge or a copy? Etc.
 The type of backup media and where it will be located.
Information Integrity and Security Page 30

2.
 Who is to carry out the backup?
Good Practices:
1. User Input: it is good practice to include users when defining the Backup
Definition List. Users usually have a good sense of how to avoid data loss and would indicate at which critical points backup is to be made.
The Backup Definition List may be setup on the Configuration Management database if that is suitable. Changes to the list can then be controlled.
3. When to backup? Most centers tend to backup at specific frequencies such as end of day, end of week. However, there are other times when backup becomes necessary:
At the end of specific business cycles
Before migration to new systems (Equipment or software)
Before upgrading/updating software or introducing patches
Before relocating systems
Before introducing new staff/users to the system
4.
In fact, any time the Ministry or Agency feels that there will be a risk of data corruption, backup should take place.
Regularly review the Backup Definition List as it often arises that new systems or situations arise such as those in the previous paragraph that will require the
Ministry or Agency to update the list.
Acceptance Criteria: the Backup Definition List is considered accepted when the
Management approves its content, storage and means of frequent update.
Information Integrity and Security Page 31

11.2
SOP 4: Backing Up
Objectives: to prepare a Backup procedure observing all backup requirements stated in the Backup Definition List and to ensure that there is a record of all backups taken for all types of information. This is the most crucial SOP to be carried out by the Ministry or
Agency and it aims at maintaining Information in total integrity. It may be time consuming and it may be costly, but it is an insurance against data loss or corruption.
Risks: not backing up the data on a regular basis will cause the Ministry or Agency to be exposed to loss of data and software items.
Standard Operating Procedure:
1. Consult the Backup Definition List on a regular basis to ensure that no backup is missed.
2. Backup Media: ensure that there is available media for the backup well in advance of the backup itself. Many centers lose valuable data because media is not available and operators end up backing up over backed up media with useful data.
3. Complete the backup and fill in a register that has the following recommended columns:
Date of backup
Time of backup
Type of backup (Incremental, full, purge, Etc.)
Source data: describe it and its status
ID of the backup as per the Backup Definition List (Refer to the previous SOP)
Operator
Media type
Media label
Where the media is to be stored
Has restored testing been tried?
Result of restore testing
Remarks
Documentation and Deliverables: The backup register which can be a printed form or a database.
Good Practices and Recommendations:
1. Centralization of the Backup Register: in the case where Ministry or Agency’s have several sites, servers, applications, Etc., it would be necessary to have a centralized register. Copies of printed forms can be sent to such a location. If the register is setup on a minor database, it can be located centrally and made accessible to all operators. Alternatively, different databases can be consolidated on a regular basis.
2. Configuration Management: it may be suitable to setup the Backup Register as part of the Configuration Management database.
3. Securing Backup: some centers follow the recommended practice of carrying out the backup by well trained personnel. In order to do that, some security
Information Integrity and Security Page 32

1. measures may be implemented so that only such persons can carry out the backup.
4.
For further good practices, review Section 11.5.
Acceptance Criteria:
On a regular basis, the Backup Register should be checked against the actual media. Verification can be made that the backup entries correspond totally to the stored media.
2. On a regular basis, the Backup Register should be checked against the Backup
Definition List prepared in the earlier the earlier SOP 3 in Section 11.1.
Verification can be made that all items in the Backup Definition List are being properly backed up. (To facilitate matters, the Backup Definition List ID is included in the Backup Register).
2. More importantly, and this will be discussed in the next SOP, restore checking should be made on random or specific backups. This should be part of the
Acceptance Criteria of the Backup Register preparation.
XXX
Information Integrity and Security Page 33

11.3
SOP 5: Identify What is to be “Restore Tested” and When
Objectives: many centers face major upsets upon realizing that their backed up media is badly backed up or is corrupted. The main reason for such a state is the lack of testing of the backed up media. Sometimes, it is a matter of deterioration of the backed up media or its environmental corruption. This SOP presents a procedure that defines what media is to be “Restore Tested”, how frequently and what the tests are.
Scope of usage: all data that is backed up may be subjected to Restore Testing.
Risks: not testing backed up data will cause the Ministry or Agency to be exposed to loss of data and software items.
Standard Operating Procedure
1. Identify the type of data to be Restore Tested and enter the relevant information
on the Backup Definition List prepared in the SOP in Section 11.1. The ID of that
2. item would then be known. A new List can then be prepared which can be called the Restore Definition List.
Define for each item in the Restore Definition List:
 The frequency of restore testing: daily, weekly, monthly, end of financial period, Etc.
 The mode of testing: is this a simple hardware test? Is it a logical data checking test? Etc.
3. For each item in the Restore Definition List, prepare a Test Plan that covers all aspects of the Restore and its testing. A typical test plan is presented below:
 Prepare sufficient space on the local disk
 Ensure that the versions of the operating system that is running, the version
 of the application software and the database structure are all compatible.
Physically restore the data into the hard disk
 Logically restore the data into the database server (Import, Etc.).
 Run the program that presents a list of system parameters: number of items, number of citizens, number of transactions, Etc.
Compare the above list with the same list produced on the day when backup  was made.
 Pass or fail the test
Documentation and Deliverables: the Restore Definition List.
Good Practices:
1. User Input: it is good practice to include the users when defining the Restore
Definition List. Users usually have a good sense of what is risky in their work.
They would help the ICT Unit identify which data is to be tested, when and what constitutes a good Test Plan.
2. The Restore Definition List may be setup on the Configuration Management database if that is suitable. Changes to the list can then be controlled.
Information Integrity and Security Page 34

Acceptance Criteria: the Restore Definition List is considered accepted when the
Management approves its content, storage and means of frequent update.
11.4
SOP 6: Restore Testing
Objectives: this SOP presents a procedure that allows the Ministry or Agency to reduce the risk of bad backup media through regular Restore Testing.
Scope of usage: in most cases, it is too costly and time consuming to test all backed up media. However, frequent and random tests can reduce the risk of damaging situations.
Risks: not carrying out restore testing will cause the Ministry or Agency to be exposed to loss of data.
Standard Operating Procedure:
1. Consult the Restore Definition List to identify the items that require Restore
Testing.
2. Prepare the receiving system for the Restore and restore the data
3.
4.
Apply the Restore Test Plan as indicated in the Restore Definition List.
Prepare a Register that shows the Restore Test details and results:
5.
6.
Identify the ID of the backed up media to get all the data elements for it
Date of Restore test
Time of Restore test
Type of backup (Incremental, full, purge, Etc.)
Operator
Test script or plan
Result of restore testing
Pass or Fail
If fail, remedial actions
Remarks
Pass or fail the test as per the Test Plan.
If the Restore Test fails, the Ministry or Agency would have unusable data. It becomes the responsibility of operators to do one of two things:
Data recovery is possible: the operators will recover the data through some means like reindexing, Etc. Alternately, they can get the data from duplicate media stored outside the Ministry or Agency.
Data recovery is not possible: if neither of the above schemes is possible, the operators would need to give warning to the ICT Unit Management and the user, that such data is not available. In case of needing such data, it may have to be re-entered and processed.
7. In all cases, enter the data related to the Restore Test in a Restore Test Register.
Documentation and Deliverables: the Restore Test Register.
Information Integrity and Security Page 35

Good Practices and Recommendations:
1. It is important to relate Restore Testing with the Business Continuity Process discussed in the next Section.
2. Configuration Management: it may be suitable to setup the Restore Register as part of the Configuration Management database.
3. Securing Restore Testing: some centers follow the recommended practice of carrying out the Restore Testing by well trained personnel. In order to do that, some security measures may be implemented so that only such persons can carry out such Tests.
4. Auditing Restore Testing: similarly, some centers may wish to have auditors or user representatives on the spot when such tests are carried out.
Acceptance Criteria:
On a regular basis, the Restore Register should be checked against the Restore
Definition List prepared in the earlier SOP in Section 11.3. Verification can be made that
all items in the Restore Definition List have been properly tested.
11.5
Good Practices: Back Up and Restore
Objectives: the main aim of this SOP is to present a set of Good Practices that apply to the variety of back up procedures presented so far.
Scope of usage: covers all types of data backup.
Good Practices and Recommendations:
1. Media Availability: ensure that there is available media for the backup well in advance of the backup itself. Many centers lose valuable data because media is not available and operators end up backing up over valid and much needed backed up media.
2. Labeling Procedures: one of the major problems facing ICT Units is that when a backup medium is required for restore, the operators are never sure which data it contains. Labeling is important but not sufficient. A rigorous scheme for labeling must be followed and should be linked to the Backup Definition List identification.
This should also include Directory or File Listing so that file dates are clearly shown.
3. What to do with Local Data? With the increasing spread of PCs on user desks, larger and larger portions of a Ministry or Agency’s information will be processed on these local PCs. This presents a risk to the Ministry or Agency because users are not very disciplined about their own backups. There are two solutions to this problem:
Server based data: force users to work on a folder hierarchy that is setup on the Server and is secure, so that no other person than the specific user can access such a hierarchy. This is a safe process. However, it does present an
Information Integrity and Security Page 36

4.
5.
6.
7.
8. additional load on the network since processing requires data traffic with the server.
Locally based data that is regularly backed up: Users can be shown how to concentrate all their data in a folder hierarchy on their own PC. On a regular basis, scripts can be prepared to push that data from the local folders to secure folders on the Server. This is more efficient in terms of network traffic but is slightly more risky as the data is as fresh as the most recent backup.
Rotational Backup: ensure that there is a daily backup for all operational data that is stored on separate media so that there is a tape for Monday, one for
Tuesday, Etc. These can be rotated during the next week.
Once a week, prepare an end of week tape separately for each week in the month. These can be rotated during the next month.
Once a month, prepare an end of month tape separately for each month in the year. These can be kept as archives.
The above scheme therefore requires:
7 daily tapes that can be reused
4 weekly tapes that can be reused
12 monthly tapes for each year
Of course, some Ministry or Agency’s may consider the above too risky and would need to establish daily or weekly backups that are rotated less frequently. Some may even require hourly backup.
Offsite Locations: ensure that duplicate backups made for key periods such as end of week or end of month or end of key closing periods are stored outside the site to avoid theft, damage or loss. Usually, it is best to store such off site backup media with a Bank or a branch of the Ministry or Agency.
Media Duplication: often magnetic media spoils with time. It is therefore highly recommended to include in the above list backups whereby existing backups are duplicated on other media. Both are then kept in case of need.
Media Technology: change in technology is becoming frequent. This can present a problem. For example: some centers are finding that they have a mass of 5 inch floppies as a back up only to find that on a specific day, they do not have a 5 inch floppy drive or that it has not been tested and is not operational. The same would apply to 3 inch floppies, DAT tapes and CD-ROMs one day.
It is highly recommended that when the ICT Unit feels that a specific backup media is being slowly phased out of the market (As what happened with the
LSI-120 disks), that all backed up data gets migrated onto more popular media.
Automating Backup: there are products in the market that automate the tasks of Backup with such features as: scheduling, tracking, incremental backup, Etc. It is recommended that such software be used.
Information Integrity and Security Page 37

9. Mirroring: disk systems can be duplicated to allow the system to use mirroring of data. Furthermore, the RAID technology allows such mirroring with the facility of hot swapping in case of breakdowns, Etc. This is also recommended.
It is important to follow these good practices as they will secure the data in the Ministry or Agency.
Information Integrity and Security Page 38

Force Majeure situations may occur and disrupt business at the Ministry or Agency over periods of different lengths. Such situations as the following can cause disasters:
 Civil strife
 Lack of access due to security reasons
 Flooding or water seepage


Total electrical failure
Construction damages
 Extreme weather conditions
 Chemical or toxic gases
 Etc
Whatever the case, the Security Officer should guarantee that there is a continuity of the
Ministry or Agency’s business by setting up countermeasures to such failures and disasters.
Business Continuity Plans should be available to describe how the Ministry or Agency can continue to operate in the event of its ICT Systems not being available. The Plans should include:
1. Disaster Recovery Procedures describe how the Ministry or Agency can obtain alternate ICT resources in the event of the primary systems being unavailable.
These procedures would be followed if the system is to be down for longer than manual procedures could feasibly be used.
2. Contingency Procedures describe how the functions provided by the system can be performed manually in the event of the system being unavailable.
The procedures that are detailed below are conceived to differentiate among the three kinds of ICT systems:
Small and Non-Critical Systems or Short Stoppages
Non-critical systems that operate batch based applications 
 Non-critical systems that solely use office technology products.
 Systems that do not operate in real-time
 Systems that do not have external users such as private sector companies, citizens or banks.
 Semi-critical or medium systems as in the next SOP but only in the case where the stoppage is known to take less than is justifiable for a full disaster recovery.
Medium and Semi-Critical Systems
 Semi-critical systems that operate with central applications
 Systems that may operate in real-time
 Systems that do not operate in real time but have short cycles such as daily closing.
 Systems that have external users such as private sector companies, citizens or banks.
Mission Critical Systems
Information Integrity and Security Page 39

 Systems whose interruption is considered to be a disaster
 Systems whose users are in the public domain: citizens, private companies, overseas users, banks, etc.
 Systems that have real time operations that depend on minute by minute up to
 date information
Systems that depend on the Internet for their processing.
In determining the appropriate solution, the Ministry or Agency’s must analyze their requirements in the case of a disaster. The analysis must consider up front costs, maintenance costs, Ministry or Agency inconvenience, and recovery time.
12.1
SOP 7: Disaster Recovery Procedures
Objectives: There is a variety of situations that can be considered disastrous depending on the criticality and the size of the site in question as well as on the nature and duration of the disaster. When a disaster takes place, the Ministry or Agency has to move to an
Alternate System. This is called the Recovery System. All software and data will be recovered on such a system. However, there are different ways of acquiring such a system depending on the classification of the disaster defined at the beginning of this
Section. This SOP presents a general procedure for dealing with the recovery from disasters.
The following are broad steps to be followed depending on the size of site and criticality of that site:
Recovery Systems for Small and Non-Critical Sites
1. Acquire another similar system. This may take time.
2.
3.
Recover all software and data
Resume operations
Recovery Systems for Medium and Semi-Critical Sites
1.
2.
3.
Prepare an agreement with another center a distant from the current site so that the equipment in that center can be used in emergency situations.
Recover all software and data
Resume operations
3.
4.
Recovery Systems for Mission Critical Sites
1. On a regular basis, take a Checkpoint backup and restore it on the Recovery
System in anticipation of a disaster. Being mission critical, Checkpoint backup
may be very frequent, say twice a day. (Review the start of Section 11.0 for a
definition of Checkpoint).
2. Acquire a mirror system through purchase or agreement with a third party for use in such situations. The system need not have the same capacity as the current system. Minimally, it should be able to run the mission critical applications.
Install the software and ensure that the operating environments are compatible.
In an emergency situation, the Ministry or Agency can resume its work from the latest Checkpoint.
Information Integrity and Security Page 40

Note: in the following discussion, the Guide will not differentiate between the above choices but will present a generic Disaster Recovery Procedure or Plan for all types.
Standard Operating Procedure
The Minimal Requirements for Recovery are:
1. Prepare the following documentation before the Disaster:
Emergency Procedures: describes the immediate action to be taken following a major incident which jeopardizes business operations. Such actions are usually not ICT related and would cover such activities as: moving files or special equipment, ensuring personnel get to the new location, moving support to the new location, informing external users such as citizens or companies of the change, etc.
Responsibles: specify the individuals responsible for executing each component of the plan.
Configuration: prepare a document that describes the configuration of the recovery system to avoid reconfiguring such elements as user names, passwords, directory structure, service packs, etc.
The Recovery Procedure: a document that describes the Recovery Procedure in a step by step fashion.
The Recovery Test Plan: a document that shows the procedure needed to certify that the Recovery has been properly executed. For example, the Test Plan can include:
File counts
File sizes
Tests on various reports (Transaction listings, etc)
Database record counts
Date checking
Etc
Related Documents: other documents prepared by related activities such as
Security lists, Backup Registers, etc.
Keep the above documents ready outside the Ministry or Agency so that they can be immediately accessed in the case of Disaster.
2. Prepare whatever is necessary to ensure access to a Recovery System as selected for the particular site from the choices presented at the beginning of this
SOP.
Note that even if agreements exist for such systems, the organization in question might also be under the same disaster, so it is preferable to have recourse to more than one such site.
Information Integrity and Security Page 41

3. Backup Media: prepare an offsite location for the backup media. It is recommended that the media be stored at a significant distance from both the
Production and the Recovery environment in order to avoid total loss in the event of a widespread disaster. It is vital that the backed up media can be accessed in a hurry, so again, it is best to have recourse to multiple backups in different sites.
4. Disaster Specific Backup: on a regular basis, take a back up of the full system.
The point at which the backup is taken is called the Checkpoint. Backups at
Checkpoints should be “operation ready”. This means that all the Operating
System and the related software tools should be backed up in a recoverable form to avoid re-installation in the new recovery site. (Note that this is not the same as the regular data backup taken by most Ministry or Agency’s).
1.
The frequency of such backup should be commensurate with the time of stoppage that the Ministry or Agency can afford. For example, if the Ministry or Agency is worried about interruptions that may last more than 1 week, then the backup should be taken at least once a week, preferably on daily basis.
Recovery Procedure
Setup the new Production environment according to the documented Recovery
Procedure.
2. Restore the backed media from the latest Checkpoint.
3.
4.
Conduct a test of the recovery procedure as per the Test Plan prepared earlier.
Inform all users as to when they can start in the sequence of their work. This totally depends on the most recent restoration of the data.
5. Open access to users.
12.2
SOP 8: Business Continuity - Contingency Plans
Objectives: as an insurance against the possibility that a system may not be available for any reason, it is essential to have recourse to Manual Operating Procedures.
Technology being addictive, most organizations forget how to process their work in a manual fashion and end up losing time and money in case Disasters take place. The aim of this SOP is to prepare a procedure that defines how Manual Operating Procedures can take place in case the ICT Systems are not available.
Standard Operating Procedure:
1. Prepare a Procedure for each of the information processes within the system. For example, Entry of project data is one such procedure.
2. The Procedure will generally consist of the following structure:
 Define the reports that define the status of the data at specific checkpoints.
 Identify the transactions through their manual vouchers
 Define the procedure used to update the data manually and check it
 Define the procedure to be used upon re-starting the system
Information Integrity and Security Page 42

3. On turning into the Manual procedure, follow the steps of each of the above procedures.
Example: the following is a typical procedure for the Maintenance of the Vehicle Fleet in the Ministry of Public Works:
Prerequisites: a daily list showing all vehicles with transactions on each starting from the beginning of the month. There will be a list identifying the following vouchers: change of location, change of Ministry or Agency, entry of petrol usage, entry of distance counter, change of vehicle particulars (Color, chassis, etc), entry of maintenance summary, etc.
1. Prepare the Vehicles list from separate media
2. As each voucher is received, then manually update the statement by adding one line by hand showing the specifics of the particular transaction.
3. In case cumulative totals are required such as in the case of Maintenance Costs, these can be computed on the hard copy report.
4. On a weekly basis, prepare a summary list of all totals (In the above case, only the accumulated costs).
Upon resuming the system, the operators can re-enter the data directly from the manually prepared transaction histories.
Documentation and Deliverables: all manual procedures.
12.3
Good Practices: Disaster Recovery
Objectives: the previous SOP presented a procedure for handling the recovery from disaster by preparing alternative systems. This SOP supplements the previous SOP by presenting good practices to be followed when handling such situations.
The following Good Practices are suggested as a support to the Disaster Recovery
Procedures of the previous SOP
1. Outsourcing: the major servers needed as Recovery Systems may not always be available within the Ministry or Agency. Indeed, in some cases, it has been known to resort to such systems outside the country. Therefore, any outsourcing to be made to have access to such systems must be submitted to rigorous qualification.
Furthermore, it is critical to regularly test the alternate site to ensure that the
Recovery System is ready for operation.
2. Testing: as in the case of Backup, Disaster Recovery is a kind of a “Restore” operation. Therefore, it is crucial to test the Recovery on a regular basis by simulating a disaster.
3. Insurance: not all problems generated by the Disaster can be resolved by a
Disaster Recovery Procedure. A lot of cost and effort is required to setup of a
Recovery System:
Information Integrity and Security Page 43

4.
5.
The increase in backup frequency
Repeat work that is lost during Emergency and Recovery
Replacement of equipment
Additional running costs such as transportation, relocation, data entry, etc.
Outsourcing of servers, sites, etc.
It is recommended that such activities be insured so that the Ministry or Agency can recover parts of its losses.
Training drills: an emergency is sure to have people lose their heads. It is therefore crucial in semi-critical and critical situations to have training drills on
Emergency and Recovery Procedures.
Risk Analysis: much of the cost and time loss of the Disaster Recovery can be avoided by a rigorous Risk Analysis of such situations. Ensure that Disasters are included in the Risk Events to be analyzed in the Ministry or Agency.
Information Integrity and Security Page 44