CHAPTER 5 RISK ASSESSMENT OF AN M-

COMMERCE APPLICATION
5.1 INTRODUCTION

According to ISACA, "Risk management is the process oI identiIying vulnerabilities and threats
to the inIormation resources used by an organization in achieving business objectives, and
deciding what countermeasures, iI any, to take in reducing risk to an acceptable level, based on
the value oI the inIormation resource to the organization|Methodware 2010|. However, Risk
management is not limited to inIormation security and should be applied over all areas oI the
organization.
The core oI any risk management procedure lies the actual assessment oI risk i.e. how the risk is
classiIied, evaluated and assessed. The aim oI inIormation security risk assessment is to use a
variety oI techniques to identiIy all Iorms oI inIormation security risks to an organizations asset
and determine the likelihood oI the risk occurring, impact oI the risk on business continuity and
providing risk mitigation strategies. NIST deIines risk assessment as 'The process oI identiIying
the risks to system security and determining the probability oI occurrence, the resulting impact,
and additional saIeguards that would mitigate this impact|Stoneburner et al 2002|. There are
diIIerent types oI risk assessment but they are essential categorized under two major approaches,
which are quantitative and qualitative risk assessment.

5.2 QUANTITATIVE ANALYSIS

Quantitative analysis is an approach that relies on speciIic Iormulas and calculations to determine
the value oI the risk decision variables. |Landoll 2006|. It is an approach that can be used when
monetary value can be mapped to a speciIic risk and results derived are gotten in numerical
values and percentages


The advantages oI Quantitative risk assessment include:
It is easier to calculate return on investment since all analysis are perIormed using
monetary values
Results can be used to support budget decisions Ior upcoming projects |Landoll 2006|
Results oI the risk assessments are non-biased and objective
Assessment made using the quantitative methodology are more reliable since they are
based on numerical values attached to speciIic numbers, probabilities, and impacts
It can be used Ior project level analysis by providing probabilistic estimates oI time and
cost

Disadvantages oI Quantitative risk assessment include the Iollowing:
It is time consuming and expensive process, as it requires the use oI specialized tools.
Results gotten are in numerical values and may be diIIicult Ior non-technical people to
interpret |Risk.biz 2011|
Quantitative risk assessment provide a Ialse sense oI accuracy because the report is based
on numerical value and it is sometimes diIIicult to provide an accurate data such that data
provided are probability educated guesswork. |Landoll 2006|

5.3 QUALITATIVE RISK ASSESSMENT

Qualitative risk assessment is a subjective risk assessment methodology that depends on the
discretion oI the risk assessment team as to what comprises oI a risk to the organization. This
methodology assumes that there is a level oI uncertainty in the likelihood oI a risk occurring and
the impact oI the risk |Elky 2006|. Each identiIied risk is assigned a value oI low, medium or
high to indicate the impact oI the risk on the organization. |Mochal 2007|. It is more oIten the
quicker, cost eIIective and easier to explain to non-technical (management) team technique oI
evaluating risk. Most accepted methodologies oI a qualitative assessment have some basic
concepts such as assets, threats, impacts and vulnerabilities.
Assets are valuable items that require protection such as systems inIrastructure, buildings,
inIormation etc. Threats are event with an undesired impact on the organization`s assets
|Onwubiko et al 2007|. An impact is the prospective outcome oI a threat emerging and
instigating damage to your assets. Vulnerabilities are weakness or breach in a system that will
allow a threat to exploit an asset.

The advantages oI Qualitative risk assessment include the Iollowing:
O It is cheaper and easier to perIorm than a quantitative risk assessment
O Qualitative analysis is easy to translate into non-technical terms and business implication
oI risks Ior the management team.
O It is not necessary to know the Iinancial value oI all the organization`s assets

Disadvantages oI Quantitative risk assessment include the Iollowing:
O indings Irom this type oI approach are subjective, so their validity and reliability may
come into question
O Results are subjective hence may be inIluenced by the assessment team (especially
internal assessment teams)
O Monitoring oI risks aIter implemented controls are diIIicult because risk are categorized
in hierarchical order as opposed to numerical values in a quantitative assessment
O DiIIicult to justiIy the cost oI implementing controls necessary aIter the risk assessment
since there is no Iinancial value attached to the analysis and no basis Ior a cost beneIit
analysis. |risk.biz 2011|
In the world today, there are many qualitative risk assessment methodologies available such as
OCTAVE(Operationally Critical Threat, Asset, and Vulnerability Evaluation), NIST Risk
management, SABSA(Sherwood Applied Business Security Architecture), CCTA Risk Analysis
and Management Method), STREAM, ISO 31000 Risk management etc.




ig 5.1: Standard Risk Assessment Process Flow |Methodware, 2010|

5.4 NIST SP 800-30 Risk Assessment Methodology

In the last decade, diIIerent assessment methodologies have been developed in the inIormation
security industry Ior the classiIication, identiIication and impact analysis oI risk in an
organization. SigniIicant risk assessment methodologies include NIST SP800-30(National
Institute oI Standards and technology) , SABSA (Sherwood Applied Business Security
Architecture), CRAMM(CCTA Risk Analysis and Management Method), OCTAVE
(Operationally Critical Threat, Asset, and Vulnerability Evaluation) etc. NIST SP 800 is a
comprehensive and precise risk assessment method that is well accepted by inIormation security
proIessionals as a cost conscious and eIIicient way oI perIorming risk assessment. This section
oI this dissertation presents an insight into the NIST risk assessment approach as deIined by the
SP800-30 document written in 2002.

S41 Steps of the NIS1 k|sk Assessment process
NIST deIines Nine-step approach Ior conducting a Iormal risk assessment. This sub section
contains the nine steps described by NIST with detailed explanation oI the expection oI each step.
System characterization
Threat IdentiIication
Vulnerability identiIication
Control Analysis
Likelihood determination
Impact analysis
Risk determination
Control recommendations
Results documentation
System Characterization
This is the Iirst stage oI the risk assessment and it involves the using inIormation gathering
techniques Ior the collation oI system related inIormations such as hardware and soItware
inIormation, architecture inIormation, users and staII oI the IT system or application,
classiIication oI data sensitivity levels, system architecture, business and Iunctional requirements
oI the IT system. Data gathering oI system inIormation may involve review oI system or
application documentation(iI available), interviews with IT staII and users oI the systems,
automated data collection tools

Threat Identification
This stage involves the identiIying the sources oI threat and pairing them with the motivation oI
the threat in an attempt to understand the cause oI the threat and implement mitigation techniques.
A threat-source is deIined as 'any circumstance or event with the potential to cause harm to an IT
system |Stoneburner et al, 2002|. Threat sources alone do not present risks to a system but a
combination oI threat source, threat motivation and threat action constitute to a risk to the system.
Everyday threat sources include natural threat sources ( extreme weather conditions), human
threat sources( hackers and dissatisIied employees) and environmental threat sources. Threat
motivations are motivations include dissatisIied employees motivated by rage, vengeance and
proIit, business competitor trying to gain competitive advantage, hackers, cyberstalkers etc
Vulnerability Identification
This stage attempts to list all technical and non technical vulnerabilities in the system`s or
application architecture in order to mitigate the threat source that can exploit the vulnerabilities.
IdentiIication oI vulnerabilities can be done through penetration testing, automated vulnerability
scanning tools etc.

Control Analysis
The aim oI this stage oI the risk assessment approach aims to assess the eIIiciency oI the al
controls that are present in a IT system, it could also examine the controls that are planned Ior
implementation. This is done in an attempt to minimize the risk oI a threat being materialized
and to ensure that vulnerabilities are not exploited by threats. The results oI the control analysis
allows an organization acquire a 'likelihood rating. Likelihood rating is the ratio or percentage
that vulnerability will be compromised by a threat. Control methods are categorized as preventive
and detective controls. Preventive controls aim to counteract the exploit oI vulnerabilities by not
allowing they to occur.. They include access control mechanism, antivirus and Iirewall
protections. Detective controls identiIy the actions that violate the security policy oI the
organizations. These includes audits, intrusion detection systems etc.

Likelihood Determination
This is the IiIth stage oI risk assessment approach and its aim to determine the likelihood oI a
threat source exploiting a vulnerability present in the system. The likelihood rating is determined
by analyzing the threat source, threat motivation, type oI vulnerability and the eIIectiveness oI
currently implemented controls. The likelihood ratings can be ranked as high, medium or low.
The table below provides a description oI the likelihood ratings
Likelihood level Likelihood definition
High The threat-source is highly motivated and suIIiciently capable, and
controls to prevent the vulnerability Irom being exercised are
ineIIective.
Medium The threat-source is motivated and capable, but controls are in place
that may impede successIul exercise oI the vulnerability.
Low The threat-source lacks motivation or capability, or controls are in
place to prevent, or at least signiIicantly impede, the vulnerability
Irom being exercised.
Table Likelihood deIinitions |Stoneburner et al, 2002|
Impact Analysis
This stage involves analyzing adverse impact that arises Irom a successIul exploitation oI
vulnerability by a threat source. Damages could be calculated in monetary terms, loss oI
conIidentiality and integrity oI inIormation, server downtime or loss oI availability oI resources,
loss oI company`s reputation, loss oI competitive advantage etc. The table below shows the
impact ratings

Magnitude of
Impact
Impact definition
High Exercise oI the vulnerability
May result in the highly costly loss oI major tangible assets or
resources;
May signiIicantly violate, harm, or impede an organization`s
mission, reputation, or interest; or
May result in human death or serious injury.
Medium Exercise oI the vulnerability
May result in the costly loss oI tangible assets or resources;
May violate, harm, or impede an organization`s mission,
reputation, or interest
May result in human injury.
Low Exercise oI the vulnerability
may result in the loss oI some tangible assets or resources or
may noticeably aIIect an organization`s mission, reputation, or
interest.
Table Magnitude oI Impact DeIinitions |Stoneburner et al, 2002|

Risk Determination
The aim oI this stage is to determine the possible level oI risks Ior each threat/vulnerability pair
by considering the likelihood oI the threat exploiting a vulnerability and the impact oI the risk
being exploited on the system. It also estimates iI the implemented controls are suIIicient in
mitigating the risks present in a system
The risk levels are categorized as high, medium, or low. The table describes the three levels oI
risks.




Risk Level Risk description and Necessary Actions
High II an observation or Iinding is evaluated as a high risk, there is a strong need Ior
corrective measures. An existing system may continue to operate, but a
corrective action plan must be put in place as soon as possible.
Medium II an observation is rated as medium risk, corrective actions are needed and a
plan must be developed to incorporate these actions within a reasonable period
oI time.
Low II an observation is described as low risk, the system`s DAA must determine
whether corrective actions are still required or decide to accept the risk.
Table Risk Scale and Necessary Actions |Stoneburner et al, 2002|
Risk-level Matrix
The actual level oI a risk is determined by analyzing the threat likelihood rating and threat impact
rating using a matrix. The table below shows a matrix to calculate the overall risk rating based on
the threat likelihood and threat impact values previously assigned in earlier stages oI the NIST
risk assessment method.

Impact
Likelihood
High Medium Low
High High High Medium
Medium High Medium Low
Low Medium Low Low

Control Recommendations
NIST risk assessment process oIIer controls that assist in the mitigation oI risks identiIied in
earlier steps oI the risk assessment process. The aim oI control recommendation is to reduce the
risks posed to the IT system to a level acceptable by management. Control recommendation are
the result oI the entire risk assessment process and provide input to the risk mitigation process.
NIST recommends that these controls are chosen based on the Iactors below|Stoneburner et
al,2002|:
System compatibility
Organizational policy
Legislations and regulations
SaIety and consistency
EIIectiveness oI recommended controls
Operational impact

An organization needs to perIorm a cost beneIit analysis on whether to implement the
recommended control, as the organization might not gain as much value to the implemented
control as the cost they have spent in implementing the control.

Results Documentation
This is the Iinal stage oI the risk assessment process; it involves the documentation oI all the
deliverables and result oI the risk assessment. The report generated at this stage is presented to
the senior management team oI the organization, as such it should be in a Iormat that is clear and
concise and easy Ior non-technical IT staII to comprehend.

Risk Assessment Report Format

NIST SP800-30 recommends that a risk assessment report will contain the Iollowing inIormation
sections |Stoneburner et al,2002|:
I. Introduction. it contains the purpose and the scope of the risk assessment. It should describe
the system components, elements, users, field site locations (if any), and any other details about
the system to be considered in the assessment.
II. Risk Assessment Approach. - This involves briefly describing the approach used to conduct
the risk assessment, such as. -
The participants (e.g., risk assessment team members)
The technique used to gather information (e.g., the use of tools, questionnaires)
The development and description of risk scale (e.g., a 3 x 3, 4 x 4 , or 5 x 5 risk-level
matrix).
III. $stem Characterization: - this is a step to characteri:e the system, including hardware
(server, router, switch), software (e.g., application, operating system, protocol), system interfaces
(e.g., communication link), data, and users. Provide connectivity diagram or system input and
output flowchart to delineate the scope of this risk assessment effort.
IJ. %hreat $tatement: - it involves Compiling and listing the potential threat-sources and
associated threat actions applicable to the system assessed.
J. Risk Assessment Results. - it involves listing the observations (vulnerability/threat pairs).
Each observation must include. -
bservation number and brief description of observation (e.g., bservation 1. User
system passwords can be guessed or cracked)
discussion of the threat-source and vulnerability pair
Identification of existing mitigating security controls
ikelihood discussion and evaluation (e.g., High, Medium, or ow likelihood)
Impact analysis discussion and evaluation (e.g., High, Medium, or ow impact)
#isk rating based on the risk-level matrix (e.g., High, Medium, or ow risk level)
#ecommended controls or alternative options for reducing the risk.
JI. $ummar. - Total the number of observations. Summari:e the observations, the associated
risk levels, the recommendations, and any comments in a table format to facilitate the
implementation of recommended controls during the risk mitigation process.


IMPLEMENTING NIST SP 800 IN PRACTICAL SCENARIOS
As discussed earlier, the third stage oI the NIST Risk assessment methodology is the vulnerability
identiIication. Although NIST speciIies we conduct a identiIication oI vulnerabilities through the
use oI automated scanning tools, penetration testing and security test and evaluation criteria
checklist, it however does not speciIy in details which security checklist to use, what type oI
scanning tools to use, the nature oI penetration testing to be conducted such as an internal
penetration testing or an external black box penetration testing. These are concerns that are
discovered by a security team whilst conducting a risk assessment system using NIST. It can lead
to ambiguous risk assessment outcomes perIormed on the same IT system iI diIIerent checklist
and test are perIormed. In order to calculate the risk, it is necessary Ior the test team to determine
which testing checklist or parameters are to considered and this decision is based on the IT
system under evaluation and the knowledge and technical know- how oI the assessment team.
To this end, the author is conducting the risk assessment oI the ZAP inIrastructure and application
based on three tests
1. An external penetration testing which would be conducted to step outline in the EC
COUNCIL Ethical hacking series (CEH v5). It would involve the use oI automatic tools
Ior steps such as OS Iingerprinting, network mapping, vulnerability identiIication etc. this
methodology is used because it is a widely accepted test Ior carrying out penetration
testing.
2. Open Web Application Security Project (OWASP) Top 10 Tests 2010, a checklist oI
common security vulnerabilities Iound in web application. This methodology is used
because oI the presence oI web application i.e. ZAP Customer manager, Distro GUI in
the ZAP application
3. PCI Requirements, a set oI requirement presented by PCI security Standards Council as
standared requirements to be achieved by the payment industry. This is used because the
ZAP application is a payment system as it involves the transIer oI cash between one
subscriber to another subscriber, or merchant Ior the payment oI bills etc.




THE RISK ASSESSMENT REPORT CONDUCTED ON ZAP
1 INTRODUCTION
1.1 Purpose
The purpose oI this risk assessment is to evaluate the adequacy oI the ZAP Application and
inIrastructure security. This risk assessment provides a structured qualitative assessment oI the
operational environment. It addresses sensitivity, threats, vulnerabilities, risks and saIeguards.
The assessment recommends cost-eIIective saIeguards to mitigate threats and associated
exploitable vulnerabilities.
A qualitative approach oI risk assessment will be employed in this risk assessment to enable the
use oI risk scale (containing values low, medium and high) to assess relevant risks. This
approach would let us identiIy and categorize business critical risk rather than a numerical
evaluation oI the components, which may not necessarily be aIIect business continuity.
1.2 Scope
The scope oI this risk assessment assessed the system`s use oI resources and controls
(implemented or planned) to eliminate and/or manage vulnerabilities exploitable by threats
internal and external to ZAIN. II exploited, these vulnerabilities could result in:
Unauthorized disclosure oI data
Unauthorized modiIication to the system, its data, or both
Denial oI service, access to data, or both to authorized users
This Risk Assessment Report evaluates the conIidentiality (protection Irom unauthorized
disclosure oI system and data inIormation), integrity (protection Irom improper modiIication oI
inIormation), and availability (loss oI system access) oI the system. Recommended security
saIeguards will allow management to make decisions about security-related initiatives.

2. Risk Assessment Approach
Zain IT is interested in understanding the loopholes in the Zain ZAP architecture and internal
processes. This risk assessment tries to show all the vulnerability and ensure there is a business
continuity plan and disaster recovery procedures Ior all possible hardware and soItware Iailure. It
would also ensure that techniques are in place to prevent Iraud within the ZAP system.
The data collection phase included identiIying and interviewing key personnel within the
organization and conducting document reviews. Interviews Iocused on the operating
environment. Document reviews provided the risk assessment team with the basis on which to
evaluate compliance with policy and procedure.
To aid in the identiIication oI technical risk in the system, the author intend to perIorm 3
standard test which are The results oI the assessment will be presented to management oI the
ZAIN IT department with recommendation oI controls

External Penetration Testing
Penetration testing is a methodology used by security administrators to discover security
vulnerabilities in their networks, system and application that could let an attacker penetrate the
network or computer systems (Skoudis, 2008). An external (outside the companies network)
Penetration testing was used to identiIy risk in the ZAP inIrastructure Iollowing EC council
CEHv5 guidelines. The Iollowing lists the steps that were carried out on the ZAP inIrastructure
penetration testing:
1. InIormation gathering: - this was done using internet look up tools such as whois,
nslookup and traceroute.
2. Port Scanning: - This is the use oI port scanning tools to identiIy open ports in the
scanned IP address gotten Irom the inIormation gathering stage. The port scanning is also
useIul in identiIying which services and operating system are running on the backend
server. The tool used here was Nmap and HPING
3. Vulnerability scanning: - this is used to detect the presence oI any actual vulnerability
present in the system. I used Nessus tool and GI languard tool to scan Ior the
vulnerabilities present in the system
4. Report: - this is the process oI analyzing the Iindings Irom all previous stages oI the
penetration testing.
The result oI the penetration testing perIormed on the ZAP inIrastructure can be Iound in
Appendix 1(External attack and penetration testing report) oI this dissertation



Open Web Application Security Project (OWASP) Top 10 Tests 2010

The Open Web Application Security Project (OWASP) is an open-source application security
project. The OWASP Top Ten oIIers a useIul documented checklist oI common web application
vulnerabilities used in understanding web application security. As an open source security
project, the OWASP uses a consensus among security proIessional to determine the most critical
web application Ilaws |OWASP, 2011|.
As discussed in chapter 4, ZAP application has 3 web application GUIs i.e. the ZAP customer
manager application, ZAP AP merchant GUI and ZAP distribution application. OWASP Top ten
test is used as a standard test to test these web applications Irom an internal perspective. The
results oI this test can be Iound in appendix 2 oI this dissertation

PCI Requirements

PCI security Standards Council`s mission is to enhance payment account data security by driving
education and awareness oI the PCI Security Standards. It is a set oI requirement that is used to
ensure security standards oI any payment company. As a best practice guideline, it is
recommended that the ZAP application is checked against PCI requirements Ior Ilaws.
Appendix 2 oI this dissertation identiIies the Ilaws oI the ZAP application in the PCI requirement

5.4.3 System Characterization

Below is a Iull list oI the main elements oI ZAIN`s ZAP InIrastructure
Hardware
2 DB Servers in RAC / High availability ConIiguration connected to SAN, 1 DB server in
Standalone connected to SAN or with local disks,3 Application Servers per module and scalable,
4 Web Client servers intranet & DMZ, 2 Cross border connectivity
Software
Windows Server 2008 and Windows 2003 Operating System, Oracle database, ZAP application
soItware (TLC SMPP Receiver, MCASH, NET ramework 2.0, Oracle 10g 32-bit Client, Oracle
Data Access Components (ODAC), Mobile Cash Application ManagerTLC SMPP Gateway and
SMSC Relay ActiveX SDK-set oI optimized ActiveX component enabling quick creation oI
application implementing the communication with smsc thru TCP/IP
System interIaces (e.g. communication link)
Data
O Company database this maintains all transaction carried out by ZAP customer
O Company policy these are documents that assert all the company rules and laws as
pertaining to regulatory compliance
O inancial data this includes all the company`s Iinances such as accounts and payments
made by customers
Users
ZAP is an application open to all subscribers oI the ZAIN network. It includes application support
team which ensures 99.9 availability oI the application (these staII have administrative rights on
the application as well as the database), Database team, Revenue assurance team( anti Iraud
prevention) , ZAP vendor(3
rd
line support) and business owners oI the application.

5.4.4 Threat Statement

All systems have threats and vulnerabilities and ZAP application is not an exception to this norm.
A threat-source is deIined as a situation or event that has the potential to cause harm to system.
Every threat source has a target or an objective to achieve and the Iollowing should be put under
consideration when analyzing security risk oI a m-commerce application
1. An external attacker gaining Iull or partial control oI the application and system
inIrastructure without being detected by access control mechanism
2. InIormation leakage or disclosure oI transactions carried out on the m-commerce
application ZAP
3. Loss oI service availability oI the application (DOS)
Below is a list oI potential threat-sources and possible threat actions they could carry out iI
vulnerability exists in the system architecture

Natural threats
Threat source Threat Action
Man made disaster such as Iire ire can destroy all inIrastructure equipment
such as hardware, SS& Iiber optic connection
etc
Natural disaster on inIrastructures i.e. Iloods,
tornados, cyclone
Water can cause electrical shocks in rooms
with technical hardware

Human threats
Threat source Threat Action
Hackers and Iraudsters Input oI wrong data (loss oI data integrity) E.g.
input oI Iraudulent data Ior spooIing purposes,
Breach oI privacy, blackmail, theIt oI personal/
Iinancial data or apparatus
Employees Damage oI technical equipment due to bad
quality/ unsaIe procedures and practices,
deliberate attack on the system to aIIect
availability oI the ZAP application,
modiIication oI commands to deIraud the
system Ior their own private gain.
Malicious code virus insertion attack into the stk menu,
malware attack into the application

5.4.5 Risk Assessment Results
This risk assessment is carried based on the results oI an external penetration testing (result is
located in the appendix 1), Open Web Application Security Project (OWASP) top 10 tests Ior
web Iacing applications and Ilaws by PCI requirements (Appendix 2). This was done by critical
analyzing each stage oI the ZAP process to identiIy risk scenarios that may aIIect the availability
oI the ZAP application as well as conIidentiality and integrity oI transaction data carried out on
the Application. I hope by the Iindings presented in this assessment the Zain Management team
would be able to implement a more the recommended control in the aim oI a more secure m-
commerce application. This section attempts to look at risk that have been ranked as HIGH or
Medium in the risk ranking. Low ranked risks inIormation and recommendation can be located in
the appendix oI this report.

Observation 1: Information Leakage Of Database By Hackers
Threat-source and vulnerability pair The source oI this threat is malicious crackers. It may
occur due a possibility oI a Iirewall breach by an attacker who can gain access to the ZAP
database to alter transactions. The vulnerability present in this scenario is due to an weak access
control inIormation and publishing sensitive document on a web Iacing server. (ReIer to OWASP
test result in Appendix two)
Likelihood rating The likelihood oI this threat occurring is HIGH, this is because the threat
source has motivation (money or blackmail) to break into the system, manipulate or delete data,
or even disclose personal data belonging to users (both employees and customers).
Impact rating: - the Impact rating is High because should the risk occur, the entire integrity oI
the database is lost, conIidentiality oI customers data can be lost and loss oI conIidence in Zain
Brand is lost by the consumers
Risk rating The overall risk rating is HIGH based on matching the likelihood and impact
indicators Irom the risk level matrix.
Recommended controls Avoid putting sensitive inIormation on web Iacing servers, implement
proper error handling pages to prevent inIormation leakages about the backend server
conIiguration Ior OS and network mapping by attackers in a bid to launch more dangerous attacks

Observation 2: Broken Access Control
Threat-source/ vulnerability pair I observed that the application support, database and
windows team and customer service agents share user accounts i.e. one user account is used
among many member oI staII making it diIIicult to have proper audit logs oI each employees
activities on the system. I also observed that restrictions on what authenticated users are allowed
to do are not properly enIorced. Attackers can exploit these Ilaws to access other users' accounts,
view sensitive Iiles, or use unauthorized Iunctions. (ReIer to appendix 2 oI Ilaws oI PCI
requirement)
Likelihood rating The likelihood oI this threat is HIGH. This is because the teams are still
using this type oI access to the servers and applications.
Impact rating The impact rating is HIGH. This is because these mistakes made by employees
can aIIect auditing purposes and aIIect accountability oI personnel.
Risk rating The overall risk rating is HIGH based on matching the likelihood and impact
indicators Irom the risk level matrix.
Control recommendations/ alternative options EnIorce the use oI individual account to each
member oI staII that have access to the application and servers oI ZAP. Enable audit logs in the
application and servers.
Observation 3: Employee Problem (No Accountability In The System)
This is perhaps one oI the most serious vulnerability present in the ZAP system as it aIIects the
integrity oI the system, transaction, availability oI the application. I observed that the system
administrators (Application Support team and Vendor team) oI the ZAP Application have the
ability to perIorm any transaction on ZAP without creating an audit trail. An 'insert transaction
can be made on the database itselI thereby bypassing the audit trail oI the system. The same
administrator is so powerIul, he can delete his logs Irom the database server because he has the
ability to perIorm the tasks oI a DBA, and he can also delete logs on the windows server.
This vulnerability in ZAP is present because there is no properly enIorced role based access
control. Also, Majority oI the actions perIormed by a ZAP application administrator were
designed not to an audit trail.
Likelihood rating The likelihood oI this threat is HIGH. This is because the teams are aware
that there is no traceability in the system so their actions cannot be monitored making it easier to
commit Iraud
Impact rating The impact rating is HIGH. This is because the entire accountability oI the ZAP
system can be compromised
Risk rating The overall risk rating is HIGH based on matching the likelihood and impact
indicators Irom the risk level matrix.
Control recommendations/ alternative options EnIorce role based access control in which no
employee has the ability to perIorm Iunctions oI multiple employee Iunctions such as DBA role,
application administration as well as windows server support. Revenue assurance team should
perIorm

Observation 4: Insecure Communication
This vulnerability leads to a loss oI conIidentiality, authentication and could lead to a breach oI
availability oI the ZAP application. It occurs Ior two reasons; the Iirst being transactions sent in
plain text between the web server and the application server. The second is that it is possible Ior
an external customer to send a clear text sms transaction message to a short code SMSC number
thereby bypassing all the security oIIered by the STK Menu and Hardware security server(HSM).
The ability oI a subscriber to send a message in clear text can lead to a more serious attack
Likelihood rating The likelihood oI this threat is MEDIUM. This is because Ior customers to
get the correct shortcode, it can only be done through guesswork and employees would read the
plain text message between the WEB RX and RAT server have administrator privileges on the
system hence do more damage to the system that just loss oI conIidentiality
Impact rating The impact rating is MEDIUM. This is because the entire accountability oI the
ZAP system can be compromised
Risk rating The overall risk rating is MEDIUM based on matching the likelihood and impact
indicators Irom the risk level matrix.
Control recommendations/ alternative options Prevent the USSD gateway Irom receiving
transactions Irom subscriber i.e. allows subscribers to use only the STK menu to carry out
transactions. Use encryption when transmitting transactions Irom the WEB server to the RAT
and AT server.

OBSERVATION 5: Insecure Configuration Management
This vulnerability occurs because there is out oI box conIiguration on ZAIN ZAP database and
windows server. DeIault password Ior generic user ids have been leIt unchanged. An attacker
who is able gather inIormation about the type oI server setup in the network can proceed to gain
unauthorized access to the inIrastructure (ReIer to Appendix 2)
Likelihood rating The likelihood oI this threat is MEDIUM. An attacker who exploits this
vulnerability must understand the Zain architecture
Impact rating The impact rating is HIGH. This is because the iI the vulnerability is exploited
then
Risk rating The overall risk rating is MEDIUM based on matching the likelihood and impact
indicators Irom the risk level matrix.
Control recommendations/ alternative options: - Ensure that database and serve administrators
disable all un-used services, disable all deIault user accounts and remove deIault conIigurations
Observation 6: Single Point Of Failure (Lack Of Redundancy/Backup Services)
This vulnerability aIIects the availability component oI the inIormation security traid. The ZAP
architecture was not built Ior complete redundancy oI each component oI the architecture.
Currently there are only warm backup Ior most oI the components oI ZAP such as the database
server, the applications server, there is no redundancy Ior the HSM server. With the current setup
scenario, iI there is a hardware problem on any component in the architecture, the entire ZAP
system would be aIIected. A warm backup oI components takes between 90minutes to
260minutes to restore ZAP services into Iull operation.
Likelihood rating The likelihood oI this threat is MEDIUM. Hardware Iailures are possible
although rare in the telecommunications industry as hardware are built to be Iault tolerant
Impact rating The impact rating is HIGH. II this risk should occur, the availability oI the ZAP
Application would be compromise.
Risk rating The overall risk rating is MEDIUM based on matching the likelihood and impact
indicators Irom the risk level matrix.
Control recommendations/ alternative options: - A temporary workaround oI providing an hot
backup (redundancy) Ior each component oI the ZAP architecture. A more permanent and best
practice recommendation would be to create an oIIsite hot backup that would take less than
3minutes to switch Irom SITE A to B incase oI any problems

Observation 7: IT continuity management
It was noted that Zain does not have a Iormally documented Business Continuity Plan or a
Disaster Recovery Plan covering the Zap application and related inIrastructure. Moreover, it was
noted that there is an absence oI a disaster recovery (DR) site and all the critical servers are hosed
at the primary site itselI.
Likelihood rating The likelihood oI this threat is MEDIUM. It is possible Ior 3
rd
line support to
be able to restore the application back iI it goes down.
Impact rating The impact rating is HIGH. II a disaster occurs, the availability oI the ZAP
Application would be aIIected and thereIore revenue impacting to the organization
Risk rating The overall risk rating is MEDIUM based on matching the likelihood and impact
indicators Irom the risk level matrix.
Control recommendations/ alternative options: - Create and document business continuity and
disaster recovery plans. It is also advised to train support staII on the understanding oI the BCP
document to enable them recover the application as soon as possible while under pressure

5.4.6 Summary

Below is a summarized total the number oI all observations along with their associated risk
levels, and control recommendations. This table should make it easier to Iacilitate the
implementation oI these controls Ior risk mitigation.

Threat Risk Level Control Recommendations
InIormation leakage oI
database by hackers
HIGH InIormation Iiltering on server and page error handling
Broken access control HIGH EnIorcement oI individual account Ior employee
Employee problem (No HIGH EnIorce role based access control and ensure a revenue
Accountability in the
System)
assurance team to perIorm a bi-monthly Iraud review.
Insecure communication MEDIUM Use oI encryption between the WEBRX and Application
servers and prevent USSD Irom receiving transactions Irom
subscribers
Insecure conIiguration
management
MEDIUM Ensure proper conIiguration management oI all servers and
application by removing deIault conIigurations
Single Point oI ailure MEDIUM Create hot backup oI components as well as an oIIsite
backup
IT Continuity management MEDIUM Create and document a business continuity plan