Nepal GEA 2 - 0 Security Architecture

Nepal GEA 2.
0
Security
Architecture
Final
September 2019
Table of Contents
1. Executive Summary ................................................................................................................. 13
1.1. Purpose of this Document ................................................................................................ 14
1.2. Audience of this Document .............................................................................................. 14
1.3. Need of Security Architecture .......................................................................................... 14
1.3.1. Impact on Businesses ........................................................................................... 15
1.3.2. Recent Cyber Breaches ........................................................................................ 15
1.4. Design Principles and Content of the Security Architecture ............................................ 19
2. Global Trends on Cyber Security ............................................................................................. 20
3. Security Architecture Components .......................................................................................... 25
3.1. Introduction ....................................................................................................................... 26
3.2. Architecture Design and Components ............................................................................. 26
3.2.1. Preliminary Phase ................................................................................................. 27
3.2.2. Architecture Vision ................................................................................................ 28
3.2.3. Business Architecture ........................................................................................... 29
3.2.4. Information Systems Architecture ......................................................................... 30
3.2.5. Technology Architecture ....................................................................................... 32
3.2.6. Opportunities and Solutions .................................................................................. 32
3.2.7. Migration Planning ................................................................................................ 33
3.2.8. Implementation Governance ................................................................................. 34
3.2.9. Architecture Change Management ....................................................................... 34
3.2.10. Requirements Management ................................................................................. 35
4. Organizational Context and Security Objectives ..................................................................... 36
4.1. Organization Structure ..................................................................................................... 37
4.2. Roles and Responsibilities ............................................................................................... 38
4.2.1. Responsibilities of Central Government ............................................................... 38
4.2.2. Chief Information Officer (CIO) ............................................................................. 38
4.2.3. Chief Information Security Officer (CISO)............................................................. 39
2 Nepal GEA 2.0 Security Architecture | Table of Contents

4.2.4. Information Security Manager (ISM) ..................................................................... 39
4.2.5. Information Security Team .................................................................................... 40
4.2.6. Business Owners .................................................................................................. 41
4.2.7. Business Users ..................................................................................................... 42
4.2.8. Data Owners ......................................................................................................... 42
4.2.9. Internal Audit Team............................................................................................... 42
4.2.10. Functional Teams ................................................................................................. 42
5. Leadership Commitment and Support for Security .................................................................. 44
5.1. Leadership Commitment .................................................................................................. 45
5.2. Governance Imperatives .................................................................................................. 45
5.2.1. Management Review ............................................................................................ 46
5.3. Security Resourcing ......................................................................................................... 46
5.3.1. Human Resources ................................................................................................ 47
5.3.2. Tools and Technologies ........................................................................................ 47
6. Information Security Risk Management ................................................................................... 59
6.1. Risk Management Framework ......................................................................................... 60
6.2. Addressing People and Policy Related Risks .................................................................. 61
6.2.1. Security Policy ...................................................................................................... 61
6.2.2. Awareness and Training ....................................................................................... 62
6.3. Addressing Process Related Risks .................................................................................. 63
6.4. Addressing Technology Related Risks ............................................................................ 72
7. Continual Security Assurance .................................................................................................. 75
7.1. Security Assessment ........................................................................................................ 76
7.1.1. Review Techniques............................................................................................... 77
7.1.2. Identification and analysis of active devices, associated ports and services ....... 79
7.1.3. Vulnerability validation .......................................................................................... 81
7.2. Third Party Auditing .......................................................................................................... 82
7.3. Service Provider Performance Management ................................................................... 83
7.3.1. SLA Measurement and Service Maturity Index .................................................... 84
8. Annexure 1: Vulnerability Management ................................................................................... 87

9. Annexure 2: Common Web Application Security Risks and Security Vulnerabilities .............. 91
10. Annexure 3: Cloud Security ..................................................................................................... 95
10.1. Before Cloud Migration ....................................................................................... 96
10.2. Infrastructure as a Service (IaaS) ....................................................................... 96
10.2.1. Access Control ...................................................................................................... 96
10.2.2. Edge Protection .................................................................................................... 97
10.2.3. Encryption ............................................................................................................. 97
10.2.4. Application Segmentation ..................................................................................... 98
10.2.5. Logging and Monitoring ........................................................................................ 98
10.2.6. Server Security Stack ........................................................................................... 98
10.2.7. Vulnerability Management and Secure SDLC ...................................................... 98
10.2.8. Container Security ................................................................................................ 98
10.3. Platform as a Service (PaaS) ............................................................................. 99
10.3.1. Access Control ...................................................................................................... 99
10.3.2. Application Isolation .............................................................................................. 99
10.3.3. Encryption ............................................................................................................. 99
10.3.4. Vulnerability Management and Secure SDLC ...................................................... 99
10.3.5. Logging and Monitoring ...................................................................................... 100
10.4. Software as a Service (SaaS) ........................................................................... 100
10.4.1. Access Control .................................................................................................... 100
10.4.2. Encryption ........................................................................................................... 100
10.4.3. Logging and Monitoring ...................................................................................... 100
10.5. Guidelines for Cloud Security ........................................................................... 100
11. Annexure 4: IoT Security ....................................................................................................... 103
11.1. IoT Secure Design and Threat Modelling ......................................................... 104
11.2. IoT Security Layers ........................................................................................... 106
11.2.1. Protecting Devices .............................................................................................. 106
11.2.2. Protecting Communications ................................................................................ 107
11.2.3. Managing Devices .............................................................................................. 107
11.3. Guidelines for IoT Security ............................................................................... 107

12. Annexure 5: Data Classification ............................................................................................. 109
13. Annexure 6: API Security ....................................................................................................... 112

List of Tables
Table 1. Recent cyber breaches..................................................................................................... 16
Table 2. Preliminary phase ............................................................................................................. 27
Table 3. Architecture vision phase ................................................................................................. 28
Table 4. Business architecture phase ............................................................................................ 29
Table 5. Information systems architecture phase........................................................................... 30
Table 6. Technology architecture phase ........................................................................................ 32
Table 7. Opportunities and solutions phase ................................................................................... 32
Table 8. Migration planning phase ................................................................................................. 33
Table 9. Implementation governance phase .................................................................................. 34
Table 10. Architecture change management phase ...................................................................... 35
Table 11. Responsibilities of team members under specific domains ........................................... 40
Table 12. Attack surfaces and security technologies ..................................................................... 48
Table 13. Description of security technologies ............................................................................... 49
Table 14. Process related risks ...................................................................................................... 63
Table 15. List of security processes ............................................................................................... 65
Table 16. Technology related risks ................................................................................................ 73
Table 17. Review techniques ......................................................................................................... 77
Table 18. Identification and analysis techniques ............................................................................ 80
Table 19. Vulnerability validation .................................................................................................... 81
Table 20. Illustrative areas for service provider contracts .............................................................. 83
Table 21. Illustrative SLAs for service providers for security implementation services .................. 85
Table 22. OWASP top 10 for application security .......................................................................... 92
Table 23. SANS top 25 ................................................................................................................... 93
Table 24. OWASP top 10 for cloud security ................................................................................. 100
Table 25. OWASP top 10 for IoT security .................................................................................... 108
6 Nepal GEA 2.0 Security Architecture | List of Tables

List of Figures
Figure 1. Top 10 risks in terms of likelihood and impact ................................................................ 21
Figure 2. Heat map showing geographical commitment towards cyber security around the world23
Figure 3. National CIRTs across the world ..................................................................................... 24
Figure 4. GEA 2.0 enterprise security architecture ........................................................................ 26
Figure 5. Security architecture components ................................................................................... 27
Figure 6. Organization structure ..................................................................................................... 37
Figure 7. Risk management framework ......................................................................................... 60
7 Nepal GEA 2.0 Security Architecture | List of Figures

Document History
Date Version Author Description

Nepal GEA Security Architecture – Draft
November 2010 Draft PwC India
version
Nepal GEA Security Architecture – Final
January 2011 Final PwC India
version
Nepal GEA 2.0 Security Architecture – Draft
August 2019 Draft PwC India
version
Nepal GEA 2.0 Security Architecture – Final
Final PwC India
version
8 Nepal GEA 2.0 Security Architecture | Document History

Abbreviations
9 Nepal GEA 2.0 Security Architecture | Abbreviations

Abbreviations
Abbreviation Expansion
API Application Programming Interface
APT Anti Persistent Threat
ATP Advanced Threat Protection
AV Anti-Virus
BCP/DR Business Continuity Plan/ Disaster Recovery
BYOD Bring Your Own Device
CASB Cloud Access Security Brokers
CEH Certified Ethical Hacker
CFS Cross Frame Scripting
CIA Confidentiality, Integrity, Availability
CIO Chief Information Officer
CISO Chief Information Security Officer
CSRF Cross-Site Request Forgery
DB Database
DLP Data Loss Prevention
DNS Domain Name System
ECSA EC-Council Certified Security Analyst
EDR Endpoint Detection and Response
GEA Government Enterprise Architecture
GRC Governance Risk and Compliance
HR Human Resources
HSM Hardware Security Module
HTTP Hyper Text Transfer Protocol
IaaS Infrastructure as a Service

IAM Identity and Access Management
ICMP Internet Control Message Protocol
ICT Information and Communications Technology
IdAM Identity and Access Management
IPS/IDS Intrusion Prevention System and Intrusion Detection Systems
ISM Information Security Manager
ISMS Information Security Management System
ISO International Organization for Standardization
IT Information Technology
LD Liquidated Damages
MFA Multi Factor Authentication
N/W Network
NIC Network Interface Card
OEM Original Equipment Manufacturer
OS Operating System
OSCP Offensive Security Certified Professional
OTA Over The Air
OWASP Open Web Application Security Project
PaaS Platform as a Service
PII Personally Identifiable Information
PIM Privileged Identity Management
RBAC Role Based Access Control
SaaS Software as a Service
SAML Security Assertion Markup Language
SDLC Systems Development Lifecycle
SIEM Security Information and Event Management
SLA Service Level Agreement

SOC Security Operations Center
SQL Structured Query Language
SSL Secure Sockets Layer
Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and

STRIDE
Elevation of Privilege
TCP Transfer Control Protocol
TLS Transport Layer Security
TOGAF The Open Group Architecture Framework
TPM Trusted Platform Module
UAT User Acceptance Testing
VLAN Virtual Local Area Network
VM Virtual Machine
VPN Virtual Private Network
WAF Web Application Firewall
XSS Cross Site Scripting

1. Executive Summary
13 Nepal GEA 2.0 Security Architecture | Executive Summary

1. Executive Summary
1.1. Purpose of this Document
This document describes the security architecture, which is a part of the Government Enterprise Architecture
2.0 for the Nepal Government. It describes how the security processes and controls are positioned, and how
they relate to the overall systems architecture in an organization. These processes and controls will serve the
purpose to maintain the system’s quality attributes such as confidentiality, integrity and availability (CIA triad of
information security).
The purpose of this document is to establish a countrywide framework for security management. This would
entail identification of information and assets, and the development, documentation and implementation of
policies, standards, procedures and guidelines for the protection of assets, and describe the resources required
pertaining to information security.
1.2. Audience of this Document

This document, while generic in nature, provides the background information to understand the development of
an information security architecture.
The level of security established by this GEA 2.0 security architecture lays guidelines for establishing minimum
level of protection for shared assets and information, regardless of the location. The security standards
specified by the architecture are meant to be followed by everyone involved in the design and development of
new services and the citizens, enterprises and institutions who use the services being offered.
This document applies to all government departments. It also should be applied contractually where
government information is processed by the private sector. This document is specifically addressed to:
 Senior executives of public and private sector organizations, who decide on the key principles and security
policies for implementation of services
 Business managers of the public administration units, who decide on rules and guidance in organizational
and operational aspects of organizations regarding the roles, responsibilities and processes required to
support the operation and continuous improvement of services.
 Chief information security Officers (CISOs) of organizations who are responsible for establishing and
maintaining vision, strategy and program to ensure that the information assets and technologies are
adequately protected
 Chief Information Officers (CIOs) of organizations, who help to set up and lead the technology strategy for
organizations
 Developers of information systems and web sites, software development sites and related services, interest
of whom is focused on rules and instructions made on technical issues in the design and development
electronic services in the country.
1.3. Need of Security Architecture

A security architecture facilitates security capabilities across lines of businesses in a consistent and cost-
effective manner and enables organizations to be proactive with their security investment decisions.
Security is the protection of systems, information (data), resources and services from accidental and deliberate
threats to confidentiality, integrity and availability. The Security Architecture describes both measures that
prevent or deter attackers from accessing a facility, resource, or information stored on physical media and
guidance on how to design structures to resist various hostile acts. While IT Security deals with data,
applications and network, Physical Security deals with infrastructure and physical facilities. IT security
professionals evaluate, implement and administer a vast array of security technologies to ensure that data is
protected and computer systems are not compromised. The security measures will either ostensibly block the

attacks, or at least warn IT security personnel so that steps can be taken to stop the attacks and protect the
data. The guidelines for application security would be helpful in discovering and avoiding vulnerabilities in
system applications. Similarly, the physical security framework will help protect physical and infrastructural
assets from unpropitious access. The Security Architecture also defines a set of rules governing the security
framework of any governmental organization and all private concerns which interact with governmental
organizations. Since assets and data can be compromised in many ways, the best security against misuse or
theft should involve a combination of technical measures, physical security and well educated human resources
to handle the facilities.
1.3.1. Impact on Businesses

A successful cyber attack can cause major damage to business. The impact of a security breach can be
broadly divided into the following categories:
Financial Impact
Cyber attacks often result in substantial financial loss arising from:
 Theft of organizational information
 Theft of financial information (e.g. bank details or payment card details)
 Theft of money
 Disruption to trading (e.g. inability to carry out transactions online)
 Loss of business or contract
Organizations that suffered a cyber breach will also generally incur costs associated with repairing affected
systems, networks and devices.
Reputational Impact
Trust is an essential element of customer relationship. Cyber attacks can damage your business' reputation
and erode the trust your customers have for you. This, in turn, could potentially lead to:
 Loss of customers
 Loss of sales
 Reduction in profits
The effect of reputational damage can even impact on organization’s suppliers, or affect relationships with
partners, investors and other third parties.
Legal Impact
Data protection and privacy laws require managing the security of all personal data in an organization. If this
data is accidentally or deliberately compromised, and the organization has failed to deploy appropriate security
measures, fines and regulatory sanctions may be implied.
1.3.2. Recent Cyber Breaches

From loss of data to complete network lockdown, global organizations face the continuous onslaught of cyber
security breaches. While these attacks have attempted to cripple many organizations, they also provide an
opportunity to learn from such incidents and appropriately build security controls to safeguard against them.
Some of the recent cyber security incidents which have been noticed across the globe are given below.
References for these have been taken from various sources on the internet. Such incidents and their extreme
business impact further the need for a concrete security architecture and policy for the government of Nepal.

Table 1. Recent cyber breaches
S.No. Organization Brief Description Business Impact
1. Equifax  Personal data of 145 million consumers  Over 300 million USD of breach
breached expenses in the first year and
300 million USD expected in
 Data includes SSN, personal data, second year
documents, driving licenses, passwords
 Offered lifetime free service to
 Data of residents of multiple countries customers to control data,
(US, UK, Canada) costing anywhere from 55 million
USD to 100 million USD
 Share price dropped early next
day by 13%
 Multiple contracts worth millions
of USD suspended
 Multiple lawsuits costing millions
of USD from individual and
organisations perspective
2. Bulgaria  Records of over 5 million Bulgarians got  Global reputational loss

stolen by hackers from the country's tax
revenue office. (Population of Bulgaria:  Personal records of over 5 million
7 Million) residents leaked
 In Bulgaria, cybercriminals were able to

infiltrate the country’s tax revenue
office, lifting personal data of 5 million
Bulgarians. The scale of the hack
means that just about every working
adult has been affected.
 This includes personally identifiable
information, tax information, from both
the NRA, and from other government
agencies who shared their data.
 The names, addresses, incomes and
social security information of as many

as five million Bulgarians and foreign

residents
3. Yahoo  In 2016, Yahoo disclosed two separate  A decline in the acquisition price
breaches involving approximately 1 of the company of 350 million
billion and 500 million users in 2013 USD
and 2014, respectively.
 Direct cost to the expenses
 In 2017, Yahoo reportedly increased its caused due to breaches
estimate of the number of users
affected to 3 billion (all of its users at  43 consumer class action
the time of the breach). lawsuits
 The incidents involved a breach of  Reputation damage and criticism

confidentiality of names, email for not reporting the incidents
addresses, telephone numbers, dates earlier
of birth as well as encrypted or partial
information on passwords and security
questions and answers
4. Anthem  Data of 78.8 million customers leaked  Lawsuits costing over 115 million
USD
 Various types of personal information,
including names, birthdays, health care  Attorney fee in over 31 million
identification/social security numbers, USD
street addresses, email addresses,
phone numbers and employment  16 million USD paid to health
information, including income data department as part of penalties
 12 million USD on initial forensic
investigation
 Free credit monitoring and
identity protection services to
those affected (reportedly for two
years)
 Ongoing investigations by
various state and federal
regulators
5. Target  Massive data breach at Target  Cost to Target over 200 million
corporation where 40 million credit card USD
numbers and Personally Identifiable
Information (PII) of 70 million customers  90+ lawsuits filed
compromised  Profits fell by 50% and share
 Data sold in underground market at a price fell by 11% in the fiscal
price of $20 – $45 / card when it was reported
 The CIO (Chief Information
Officer) of Target resigned
 Overhaul of security at Target
 Lawsuits against security auditor
and contractor
6. Saudi  Saudi Aramco, one of the largest  75% of the company systems
Aramco company in the world with largest SAP affected
implementation was hit by a

cyberattack, where 30,000+  Many of the business functions

workstations were impacted and it took such as shipping and contracting
one week to restore the services. The shut down
malware succeeded in deleting data
from approximately 75% of all of Saudi  Purchased 50,000 new
Aramco's corporate computers. computers to replace affected
systems
 The choice of attack is 15 August, 2012
– a holy day in Saudi Arabia (Lailat al
Qadr) – meant that a very large
percentage of Saudi Aramco's
employees were not in the office.
7. Iran  Stuxnet reportedly ruined almost one  Ruined almost one fifth of Iran's
fifth of Iran's nuclear centrifuges. nuclear centrifuges
 It also targeted industrial control
systems, over 200,000 computers and
caused 1,000 machines to physically
degrade
 The worm malfunctioned the
centrifuges by varying its frequency.
The stress caused due to this destroyed
the machines
8. TCS  TCS was fined for Intellectual Property  TCS was fined 940 million USD
breach for allegedly stealing healthcare in 2014 for IPR infringement
software from an American company,
Epic Systems.  TCS paid 440 million USD to
Epic Systems as part of penalty
9. Marriott  Marriott suffered a massive data breach  Breach came under GDPR and
affecting the records of up to 383 million fines included up to 4$ of global
customer records, 25 million passport turnover
numbers, and 8 million payment cards
details  Shares subsequently fallen by
5.6%
 Potential 1 billion USD in
regulatory fines and litigation
costs

1.4. Design Principles and Content of the Security Architecture
The Government of Nepal shall securely and economically protect its business functions, including public
access to appropriate information and resources, while maintaining compliance with the legal requirements
established by existing statutes pertaining to confidentiality, privacy, accessibility, availability, and integrity.
Departments that are maintaining their own network and resource infrastructure shall tightly integrate their
security architecture/ technologies with common services including remote access, internet access, firewall,
VPN, spam and anti-virus email filtering, etc.
It is an understanding that security has always relied upon the three pillars – Confidentiality, Integrity and
Availability. Combining these pillars and GEA’s business strategy, we have identified a set of key security
architecture design principles, which can be applied to ensure that all future systems and applications are
designed in a consistent manner.
 Defence in Depth – While one control would be reasonable for protection, multiple controls that approach
risks in different fashions should be used. Controls, when used in depth, can make severe vulnerabilities
extraordinarily difficult to exploit, and thus unlikely to occur.
 Least Privilege – Every program and every user of the system should operate using the least set of
privileges necessary to complete the job. This limits the damage that can result from an accident or error,
as well as reduce the number of potential interactions among privileged programs to the minimum.
 Separation of Duties – More than one person should be required for the completion of a task, through
spreading the tasks and privileges among multiple personnel. A protection mechanism that requires two
keys to unlock it is more robust and flexible than one that allows access to the presenter of only a single
key, ensuring that no single accident, or breach of trust is sufficient to compromise the protected
information.
 Economy of mechanism – The design and implementation of security mechanisms should be kept as
simple and small as possible. Complex mechanisms may not be correctly understood, configured or
implemented, increasing the possibility for human error.
 Implicit deny – Unless a subject is granted explicit access to an object, it should be denied access to that
object. A user should be initialised with no access rights, and granted permissions to resources as required.
This limits the damage that can result from an individual possessing excessive rights.
 Open design/ Avoid security by obscurity – The design of the system should not be secret. The
mechanisms should not depend on the ignorance of potential attacks but on the possession of specific
protection keys. By prioritising security for protection keys, it is more feasible and realistic than attempting
to maintain secrecy for any system which receives wide distribution.
 Complete mediation – Access checks to an object should be required each time a subject requests
access, especially for security-critical objects. This allows for a system-wide view of access control, as well
as decreases the chances of mistakenly granting elevated permissions to that subject.
 Accountability / Traceability – All actions should be traceable and used to uniquely identify the user who
is performing them or on whose behalf the actions are being taken. This ensures that in the case of a
security violation, the root cause can be identified.
 Secure the weakest link – A holistic view of the architecture should be considered, with security controls,
commensurate to risk and exposure applied across the various components which make up the entire
systems.
 Zero-trust – Anything inside or outside the system’s perimeters should not be trusted automatically and
should always undergo thorough verifications.
Acknowledging the abovementioned design principles, the security architecture has been designed referencing
internationally recognized standards ISO 27001:2013 and ISO 22301:2012, guidance as per TOGAF standard,
and various laws of land such as Draft National Cyber security Policy of Nepal, 2016 and National ICT Policy of
Nepal, 2015.

2. Global Trends on Cyber
Security
20 Nepal GEA 2.0 Security Architecture | Global Trends on Cyber Security

2. Global Trends on Cyber Security
2.1. Global Trends in Cyber Security
Massive cybersecurity breaches have become almost commonplace, regularly grabbing headlines that alarm
consumers and leaders. But for all of the attention such incidents have attracted in recent years, many
organizations worldwide still struggle to comprehend and manage emerging cyber risks in an increasingly
complex digital society. As our reliance on data and interconnectivity swells, developing resilience to withstand
cyber shocks – that is, large-scale events with cascading disruptive consequences – has never been more
important.
With evolving technology comes evolving hackers and the world is not keeping up with the fight against
cybercrime. The global risks report 2019 by World Economic Forum mentions cyber attacks as one of the top
10 risks in terms of likelihood as well as their impact.
Figure 1. Top 10 risks in terms of likelihood and impact
Source: World Economic Forum, Global Risks Report 2019
2.2. Initiatives by Nepal

As forward-looking nation, Nepal has taken some initiatives to strengthen its cyberspace. These include efforts
to create a strong policy environment and strengthen security monitoring capabilities, and international
cooperation. Some of such key initiatives (non-exhaustive list) are mentioned below under:
 The digital forensics lab has been established by Nepal Police within its headquarters.
 Security audits of different governmental applications/ websites have been carried out effectively by the
Department of Information Technology (DoIT).

 All financial institutions in Nepal are required to carry out security audits as regulated by the Central Bank
of Nepal.
 The Nepal Telecommunications Authority has signed a memorandum of understanding (MoU) with Nepal
Police to enhance Digital Forensic Capabilities and strengthen the Digital Forensics Laboratory.
 Information Technology Guidelines were released (August 2012) by Nepal Rastra Bank for the financial
sector. These guidelines regulate and guide IT related activities in commercial banks with the objectives of
strengthening banks for tackling with emerging cyber frauds, managing information technology prudently
and mitigating risk aroused from implementation of information technology.
 National Information and Communication Technology Policy was released in the year 2015 to formulate
strategic responses to account for technological trends shaping the ICT sector.
 The electronic transactions act 2063 of 2008 was released which has provisions related to:
o Electronic Record and Digital Signature
o Attribution, Acknowledgement and dispatch of Electronic Records
o Controller and Certifying Authority
o Digital Signature and Certificates
o Functions, Duties and Rights of Subscriber
o Electronic Record and Government use of Digital Signature
o Network Services
o Offence Relating to Computer
o Cyber Tribunal
o Cyber Regulations Appellate Tribunal
 A draft structure bill regarding cybercrime (The Cybercrime Act, xx (2018)) was released underlining the
relevance that information and communication technology has for the citizens of Nepal. However the bill
remains draft as of date.
 Being a member state of ITU, a draft national cyber security policy was released by the government in 2016
as per of ITU’s National Cyber security Strategy program. However, the policy is in a draft stage as of date.

2.3. Some Areas of Improvement
The Global Cybersecurity Index (GCI) is an initiative of the International Telecommunication Union (ITU)
involving experts from different backgrounds and organizations. The Global Cybersecurity Index (GCI) is a
composite index produced, analysed and published by the International Telecommunication Union (ITU) to
measure the commitment of countries to cyber security in order to raise cyber security awareness.
As per the Global Cybersecurity Index 2018 by ITU, Nepal is one of the countries that have just started to
initiate commitments in cyber security, and has a long way to go further.
Figure 2. Heat map showing geographical commitment towards cyber security around the world
Countries that demonstrate high commitment to national cyber security
Countries that have developed complex commitments and engage in cyber security
programmes and initiatives
Countries that have started to initiate commitments in cyber security – Includes Nepal
Source: Global Cybersecurity Index 2018 by ITU

According to the same organization (ITU), as of March 2019, Nepal is one of the few countries who do not have
a National Computer Incident Response Team (CIRT). Effective mechanisms and institutional structures at the
national level are necessary to reliably deal with cyber threats and incidents. The absence of such institutions
and lack of national capacities poses a genuine problem in adequately and effectively responding to cyber
attacks. National Computer Incident Response Teams (CIRT) play an important role in the solution.
Figure 3. National CIRTs across the world
Source: itu.int/en/ITU-D/Cybersecurity/Pages/national-CIRT.aspx

3. Security Architecture
Components
25 Nepal GEA 2.0 Security Architecture | Security Architecture Components

3. Security Architecture Components
3.1. Introduction
This Information Security Architecture under GEA 2.0 provides a broad overview of information security
program elements to assist organizations in understanding how to establish and implement an information
security program. The topics within this document are selected based on the laws and international standards
relevant to information security, including the standards ISO 27001, TOGAF, Draft national cyber security policy
of Nepal, etc.
The material in this architecture can be referenced for general information on a particular topic or can be used
in the decision-making process for developing an information security program. While reading this security
architecture, please consider that it is not specific to a particular organization. Organizations in Nepal should
tailor this architecture according to their context, security posture and business requirements.
The purpose of this security architecture is to inform key members of various organizations (business heads
(CEOs, MDs); chief information officers (CIOs); chief information security officers (CISOs), security managers,
etc.) about various aspects of information security that they will be expected to implement and oversee in their
respective organizations. In addition, this architecture provides guidance for facilitating a more consistent
approach to information security programs across the country.
3.2. Architecture Design and Components

GEA 2.0’s enterprise security architecture distils the interaction of people, processes, and technology down,
creating actionable financial and technical insights into how to most effectively defend an organisation
Figure 4. GEA 2.0 enterprise security architecture

The various components of the security architecture inspired from TOGAF, ISO 27001, and Nepal’s laws of
land are given below:
Figure 5. Security architecture components
The various components of the security architecture are explained in detailed in further sections.
3.2.1. Preliminary Phase

The various activities under the “preliminary” phase, which should be followed by every organization, are:
Table 2. Preliminary phase
Requirement for all

S.No. Implementation Guidance
organizations
1. Identify the scope  Identify core enterprise units – Those who are most affected and
impacted by this achieve most value from the security work
Security Architecture
 Identify soft enterprise units – Those who will see change to their
capability and work with core units but are otherwise not directly
affected
 Identify extended enterprise units – Those units outside the scoped
enterprise who will need to enhance their security architecture for
interoperability purposes
 Identify communities involved – Those stakeholders who will be
affected by security capabilities and who are in groups of communities
 Identify the security governance involved, including legal frameworks
and organizational geographies
2. Define and document  A written security policy for the organization should be in place, and
applicable regulatory there should be regular notification and education established for
and security policy employees. International standards ISO/IEC 27001 and ISO 27002 are
requirements good to start the formation of a security policy, and can be used to
assess the security readiness of an organization.

Requirement for all
organizations
3. Define the required  Security considerations can conflict with functional considerations and
security capability a security advocate is required to ensure that all issues are addressed
and conflicts of interest do not prevent explicit consideration of difficult
issues.
 Executive policy decisions should be established at this point about
what security policies can be negotiable and which policies should be
enforced.
4. Implement security  The approach to security tools may be based on usage of standard
architecture tools office productivity applications, or may be based on a customized
deployment of specialist security architecture tools and techniques.
3.2.2. Architecture Vision

The various activities under the “architecture vision” phase, which should be followed by every organization,
are:
Table 3. Architecture vision phase
Requirement for all

organizations
1. Obtain management  Management endorsement of the security-related aspects of the

support for security architecture implementation effort should be obtained.
measures
2. Define necessary  The traceability of security-related architecture decisions should be

security-related documented.
management sign-off
milestones for this  Appropriate executives and line management who should be informed
security architecture of security-related aspects of the project should be identified and the
implementation cycle frequency of reporting should be established.
3. Determine and  Any existing disaster recovery and business continuity plans should be
document applicable understood and their relationship with the planned system defined and
disaster recovery or documented.
business continuity
plans/ requirements
4. Identify and All architecture decisions should be made within the context of the
document the environments within which the system will be placed and operated.
anticipated physical/
business/ regulatory  Physical environments that should be documented may include
environment(s) in commercial environments, outdoor environments, mobile
which the system(s) environments, etc. of the organization.
will be deployed  In a similar fashion, the business environment should be defined.
Potential business environments may include different assumptions
regarding users and interfaces, and those users or interfaces may
carry the onus of regulatory environments in which the system should
operate.

Requirement for all
organizations
5. Determine and  Safety-critical systems place lives in danger in case of failure or

document the malfunction.
criticality of systems:
safety-critical/  Mission-critical systems place money, market share, or capital at risk in
mission-critical/ non- case of failure.
critical  Non-critical systems have little or no consequence in case of failure.
3.2.3. Business Architecture

The various activities under the “business architecture” phase, which should be followed by every organization,
are:
Table 4. Business architecture phase
Requirement for all

organizations
1. Determine who are  Development of the business scenarios and subsequent high-level
the legitimate actors use-cases of the project concerned will bring to attention the people
who will interact with actors and system actors involved.
the organizational
products/ services/  It should also be borne in mind that users may not be humans;
processes software applications may be legitimate users. Those tending to
administrative needs, such as backup operators, should also be
identified, as should users outside boundaries of trust, such as
Internet-based customers.
2. Assess and baseline  The business process regarding how actors are vetted as proper users
the current security- of the system should be documented.
specific business
processes  Consideration should also be made for actors from outside the
(enhancement of organization who are proper users of the system.
existing objective)
3. Determine whom/  It is understandable that security measures, while important, can

how much it is impose burden on users and administrative personnel. Some will
acceptable to respond to that burden by finding ways to circumvent the measures.
inconvenience in Examples include administrators finding ways to create "back doors".
utilizing security The trade-offs can require balancing security advantages against
measures business advantages and demand informed judicious choice.
4. Identify and  Every system should rely upon existing systems beyond the control of
document the project. These systems possess advantages and disadvantages,
interconnecting risks and benefits. Examples include the Domain Name System (DNS)
systems beyond that resolves computer and service names to Internet addresses, or
project control paper currency issued by the local treasury. The address returned by
the host or service DNS may not always be trustworthy; paper currency
may not always be genuine, and recourse will vary in efficacy between
jurisdictions. These interfaces should be understood and documented.
5. Determine the assets  Assets are not always tangible and are not always easy to quantify.
at high risk if Examples: loss of life, loss of market value, loss of customer trust.

Requirement for all
organizations
something goes
wrong
6. Determine the cost  Assets most challenging to quantify can be the most valuable and
(both qualitative and should not be neglected. Examples: organizational reputation
quantitative) of asset
loss/ impact in failure
cases
7. Identify and  Assets may be owned by outside entities, or by inside entities. Inside
document the entities may be owned by individuals or by organizations.
ownership of assets
8. Determine and  To be able to enforce security policies, breaches of security should be

document properly captured so that problem determination and possible policy or
appropriate security legal action can be taken against the entity causing the breach.
forensic processes
 Security personnel should be trained to follow the forensic procedures
and training material regarding the need to collect evidence should be
considered for the standard security education given to employees.
9. Identify the criticality  The risks associated with loss of availability should be identified.
of the availability and Examples: power failure, human error, natural disasters
correct operation of
the overall service
10 . Determine and  A quantitative risk analysis (an understanding of the value of assets at
document how much risk and the likelihood of potential threats) provides an important
security (cost) is guideline for security investments in mitigation strategies for the
justified by the identified threats. It is understood that an asset worth amount “$”
threats and the value should not be protected with security measures worth “2$”.
of the assets at risk
3.2.4. Information Systems Architecture

The various activities under the “information systems architecture” phase, which should be followed by every
organization, are:
Table 5. Information systems architecture phase
Requirement for all

organizations
1. Identify and evaluate  From a security standpoint, standard protocols, standard object
applicable recognized libraries, and standard implementations help to ensure that errors do
guidelines and not find their way into implementations. While international standard for
standards security ISO 27001 has been incorporated in this security architecture,
the same should be assessed independently as well.
2. Revisit assumptions  In light of the risk assessments performed, assumptions regarding

regarding interconnecting systems should be reviewed.
interconnecting
systems beyond
project control

Requirement for all
organizations
3. Determine and  The absence of any official classification does not necessarily absolve
document the the onus on maintaining the confidentiality of data. Consideration
sensitivity or should be made to determine and document the sensitivity and
classification level of classification of information within the organization.
information stored/
created/ used
4. Identify and  All assets of value are kept and maintained on behalf of the owner. The
document custody of specific persons or organizations charged with this responsibility
assets should be identified.
5. Identify the criticality  Presumably, in the event of system failure or loss of functionality, some
of the availability and value is lost to stakeholders. The cost of this opportunity loss should be
correct operation of quantified, if possible, and documented.
each function
6. Determine the  Existing business continuity/ disaster recovery plans may

relationship of the accommodate the system under consideration. If not, analysis should
system under design be done to determine the gap and the cost if that gap goes unfilled.
with existing business
disaster/ continuity
plans
7. Identify what aspects  Systems should evolve to accommodate change. Systems architected
of the system should for ready reconfiguration will better reflect that change and result in
be configurable to lower cost over the life of the system.
reflect changes in
policy/ business  Security is enhanced when security-related changes can be
environment/ access implemented inexpensively and are, hence, not sidelined.
control
8. Identify lifespan of  Information maintained beyond its useful lifespan represents wasted
information used as resources and, potentially, business decisions based upon suboptimal
defined by business data. Regulation, however, sometimes mandates the timetable for
needs and regulatory maintenance of information as archival data. In this regard, lifespan of
requirements information stored should be identified and documented.
9. Identify actions/  Logging will help reconstruct chains of events, facilitate root cause
events that warrant analysis, and, potentially, establish evidence for civil or criminal action.
logging for later
review or triggering  Logs should be regularly reviewed to identify malicious attacks on a
forensic processes system.
10 . Identify and  Since malicious tampering of systems is commonly accompanied by

document tampering of logged data, the ability to protect and establish the
requirements for rigor accuracy of logs through cryptographic methods will remove
in proving accuracy uncertainty from investigations and bolster cases in legal proceedings.
of logged events
(non-repudiation)

3.2.5. Technology Architecture
The various activities under the “technology architecture” phase, which should be followed by every
organization, are:
Table 6. Technology architecture phase
Requirement for all

organizations
1. Assess and baseline  Baselining of current security specific technologies will help in
current security- establishing their target state and enhancement imperatives. The same
specific technologies can be done against international standards ISO 27001 and ISO 22301
(enhancement of for processes, OEM guidelines for security products, and such.
existing objective)
2. Identify methods to  As resources are reaching their end-of-life period, functionality may be
regulate consumption impaired or may fail altogether. Steps that may identify such resources
of resources and recognize resource depletion period, can enhance the overall
reliability and availability of the systems.
3. Engineer a method  As systems are deployed and operated in dynamic environments,

by which the efficacy security measures will perform to varying degrees of efficacy as
of security measures unexpected threats arise and as expected threats change in the
will be measured and environment. A method that facilitates ongoing evaluation of the value
communicated on an of security measures will inform ongoing changes to the system in
ongoing basis response to changing user needs, threat patterns, and problems found.
4. Identify the trust  Regulatory requirements, information classification levels, and

(clearance) levels business needs of the asset owners will all influence the required level
of trust that all interactive entities will be required to fulfil to qualify for
access to data or services.
 Trust levels for users, administrators, and interconnecting systems
should be identified.
5. Identify minimal  Granting all-encompassing capabilities to any user, application, or

privileges required for other entity can simplify successful transaction completion at a
any entity to achieve significant cost of complicating effective control and audit.
a technical or
business objective
3.2.6. Opportunities and Solutions

The various activities under the “opportunities and solutions” phase, which should be followed by every
organization, are:
Table 7. Opportunities and solutions phase
Requirement for all

organizations
1. Identify existing  It is an understanding that there will be existing security infrastructure
security services and security building processes that can be applied to the requirements
available for re-use derived from this security architecture. For example, if the requirement
exists for application access control external to an application being
developed, and such a system already exists, it can be used again.

Requirement for all
organizations
2. Engineer mitigation  Having determined the risks amenable to mitigation and evaluated the
measures addressing appropriate investment in that mitigation as it relates to the assets at
identified risks risk, those mitigation measures should be designed, implemented,
deployed, and/or operated.
3. Evaluate tested and  Since design, code, and configuration errors are the roots of many
re-usable security security vulnerabilities, taking advantage of any problem solutions
software and security already engineered, reviewed, tested, and field-proven will reduce
system resources security exposure and enhance reliability.
4. Identify new code/  Populate the Architecture Repository with new security building blocks.
resources/ assets
that are appropriate
for re-use
3.2.7. Migration Planning

The various activities under the “migration planning” phase, which should be followed by every organization,
are:
Table 8. Migration planning phase
Requirement for all

organizations
1. Assess the impact of  In a phased implementation, the new security components are usually
new security part of the infrastructure in which the new system is implemented. The
measures upon other security infrastructure needs to be in a first or early phase to properly
new components or support the project.
existing leveraged
systems
2. Implement assurance  During the operational phases, mechanisms are utilized to monitor the
methods by which the performance of many aspects of the system. Its security and availability
efficacy of security are no exception.
measures will be
measured and
communicated on an
ongoing basis
3. Identify correct  Security of any system depends not on design and implementation
secure installation alone, but also upon installation and operational state. These
parameters, initial conditions should be defined and monitored not just at deployment, but
conditions, and also throughout operation.
configurations
4. Implement disaster  Plans for business continuity and disaster recovery of operations
recovery and should be implemented at this stage.
business continuity
plans or modifications

3.2.8. Implementation Governance
The various activities under the “implementation governance” phase, which should be followed by every
organization, are:
Table 9. Implementation governance phase
Requirement for all

organizations
1. Establish architecture  Many security vulnerabilities originate as design or code errors and the
artifacts, design, and simplest and least expensive method to locate and find such errors is
code reviews and generally an early review by experienced peers in the craft. Locating
define acceptance such errors, of course, is the first step and implementing corrections at
criteria for the an appropriate point in the development lifecycle is necessary to
successful benefit from the investment.
implementation of the
findings  Follow-on inspections or formalized acceptance reviews may be
warranted in high-assurance or safety-critical environments.
2. Implement methods  While planning and specification is necessary for all aspects of a
and procedures to successful enterprise, they are insufficient in the absence of testing
review evidence and audit to ensure adherence to that planning and specification in
produced by the both deployment and operation. Among the methods to be exercised
system that reflects are:
operational stability
and adherence to o Review system configurations with security impact which can
security policies be modified to ensure configuration changes have not
compromised security design
o Audit the design, deployment, and operations against security
policies and business objectives
o Run test cases against systems to ensure the security systems
have been implemented as designed
o Run business continuity and disaster recovery tests
3. Implement necessary  Training is not necessary simply to preclude vulnerabilities introduced

training to ensure through operations and configuration error, though this is critical to
correct deployment, correct ongoing secure performance.
configuration, and
operations of  Proper training should be performed and documented to demonstrate
security-relevant due diligence and substantiate corrective actions or sanctions in cases
subsystems and where exploits or error compromise business objectives or to absolve
components; ensure contributory responsibility for events that bring about harm or injury.
awareness training of
all users and non-
privileged operators
of the system and/or
its components
3.2.9. Architecture Change Management

The various activities under the “architecture change management” phase, which should be followed by every
organization, are:

Table 10. Architecture change management phase
Requirement for all

organizations
1. Determine change  Good security forensics practices in conjunction with a written
imperatives and published security policy make determination of what has gone wrong
drivers possible. Further, they make enforcement possible.
 Minor changes can be made in the context of change management
and major changes will require a new architecture effort.
2. Incorporate security-  Changes that arise as a result of a security problem or new security
relevant changes to technology will feed into the Requirements Management process.
the environment into
the requirements for
future enhancement
3.2.10. Requirements Management

Requirements Management is not a static set of requirements, but a dynamic process whereby requirements
for enterprise architecture and subsequent changes to those requirements are identified, stored, and fed into
and out of the relevant phases described above.
The inputs to the requirements management process are the requirements-related outputs from each phase
given above. The first high-level requirements are articulated as part of the Architecture Vision, generated by
means of the business scenario or analogous technique. Each architecture domain then generates detailed
design requirements specific to that domain, and potentially to other domains (for example, areas where
already designed architecture domains may need to change to cater for changes in this architecture domain;
constraints on other architecture domains still to be designed).
Covering the various aspects of information security in various phases of TOGAF architecture, the security
dimensions for this security architecture are broken into the following 4 key components of a cyber security
framework:
 Organizational Context and Security Objectives
 Leadership Commitment and Support for Security
 Information Security Risk Management
 Continual Security Assurance

4. Organizational Context
and Security Objectives
36 Nepal GEA 2.0 Security Architecture | Organizational Context and Security Objectives
4. Organizational Context and
Security Objectives
4.1. Organization Structure
Governance in Nepal has moved from centralised to federated structure having multiple advantages such as
division of powers between center and states, people being more interested in local and regional affairs, better
political organization, etc.
In consideration of governance changes from GEA 1.0 to GEA 2.0, the following governance structure for
organization of information security in Nepal has been established.
Figure 6. Organization structure
4.2. Roles and Responsibilities
The roles and responsibilities as per the updated federated governance structure of GEA 2.0 for center,
provinces, and local bodies are given in the following sections.
4.2.1. Responsibilities of Central Government

The responsibilities of the central government include the following:
 Consider establishing a national CERT and release guidelines for State and Local CERTs.
 Promote research and development in the area of cyber security.
 Include security-related skills in the job descriptions of government employees.
 Define the reporting channel and guidelines, and subsequent disciplinary actions and guidelines for entities
in the event of a lapse in security on an organisation’s part.
 Create cyber awareness across government organisations and its employees.
 Encourage small and medium sector enterprises to adopt cyber security practices by providing incentives.
 Create and support the building of capacities within user organisations on security skills development and
enhancement.
 Conduct periodic and mandatory security assessments of government organisations and their ecosystems
to maintain security postures and hygiene.
 Enforce all government departments to report data security breaches compulsorily to nodal agencies.
 Define third-party vendor guidelines for secure cyber practices and adherence to policies, procedures and
standards defined.
4.2.2. Chief Information Officer (CIO)

The CIO is responsible for the establishment and maintenance of the information security and Management in
the organization. Responsibilities of the CIO include:
 Identifying information security objectives and aligning them consistent with the organization’s strategic
plans.
 Set the directions for adoption for Information Security Management System (ISMS).
 Provide Management support for security architecture and policy implementation and operations.
 Monitor achievements of Security objectives to ensure continual improvement of the security architecture
and policy.
 Provide guidance and direction on security architecture and policy to CISO to ensure on-going
maintenance of information security.
 Overseeing Security operations, including Information Security Incident Management and Business
Continuity Management.
 Overseeing investigations/ forensics of Security breaches, including suspected insider threat.
 The CIO could issue ‘special instructions’ in emergent cases required for carrying out investigations and
forensics. Such special instructions would be issued by the CIO to the investigation team to enable
maintaining confidentiality of the investigation and achieving speed in collecting evidentiary material before
the same is either destroyed or altered knowingly or wilfully by those being investigated.
 Managing the development and implementation of the information security policy and its procedures to
ensure on-going maintenance of information security.
4.2.3. Chief Information Security Officer (CISO)

The responsibilities of the CISO/ CISO’s Office include the following:
 Obtain board approval on information security policy.
 Discuss issues of non-compliance with the information security committee.
 Articulate information security policy and architecture for the organization.
 Facilitate security awareness and training sessions within the organization.
 Provide advice and support to management and users for implementation of information security policy and
architecture, and for correcting deficiencies related to information security.
 Build and lead information security team with appropriate competencies within the organization and ensure
members of the information security team undergo relevant information security training.
 Ensuring non-disclosure agreements are signed off by users and third parties, including contractors and
vendors.
 Ensure the security policy and architecture are addressed in project management, regardless of the type of
the project.
 Carry out risk assessments with information security manager on an on-going basis and update
management regularly.
 Conduct continuity drills as per the information security policy.
 Review the security policy and architecture documents periodically (or) if significant changes occur to
ensure their continuing suitability, adequacy, and effectiveness.
 Periodically review and assess compliance to the information security policy and architecture.
4.2.4. Information Security Manager (ISM)

The ISM is responsible for the establishment and maintenance of the information security within the
organization. ISM should directly report to the CIO and CISO. Responsibilities of ISM include:
 Managing the implementation of the security architecture, security policy, and its procedures to ensure
ongoing maintenance of information security.
 Overseeing security operations, including information security incident management and business
continuity management.
 Overseeing investigations/ forensics of security breaches, including suspected insider threat.
 Assisting in consequence management and matters associated with such breaches, as necessary.
 Managing the development and implementation of information security training and awareness programs.
 Keeping the management updated with effective, efficient and reliable approaches for information security.
 Prepare documentation of all the events in line with the cyber laws and statutory boarding.
 Periodically review the ISMS documentation.
 Adhere to the architecture, policy and guidelines to protect electronic/ physical information security across
primary and secondary sites and associated organizational functions.
 Enforcing effective implementation of policies across the organization.
 Reviewing users/ departments’ access rights on a periodic basis.
 Responding to escalated security incidents and track repeated incidents for taking preventive actions.
 Verifying and validating that non-disclosure agreements are signed by users and third parties including
contractors and vendors.
 Organizing and conducting information security training to relevant users across departments.
 Carrying out risk assessment on an on-going basis and update management.
 Ensuring adequate physical security to protect organizational assets across primary and secondary data
centre sites and all functions.
 Enforcing effective implementation of physical security for primary and secondary data centre sites.
 Responding to queries related to physical security process and procedures.
 Reviewing physical access rights periodically and taking corrective actions as required.
 Responding to escalated security incidents and tracking repeated incidents for taking preventive actions.
 Liaison management with external agencies such as law, cyber-crime authorities to meet statutory and
legal requirements.
 Identifying and introducing new processes to reduce security vulnerabilities.
 Reporting to management on security violations and exceptions.
4.2.5. Information Security Team

The organization’s information security team should focus exclusively on information security management.
The responsibilities of information security team include the following:
 Translate the security architecture and policy into specific actions, which include awareness, security
infrastructure, incident response, and risk management.
 Monitor implementation of information security and management projects.
 Provide counsel and advice to different stakeholders for information security matters.
 Identify current and potential legal and regulatory issues affecting information security.
 Perform and report information security risk assessments on a regular basis.
 Monitor information security incident management and implementation of information security projects and
controls.
Table 11. Responsibilities of team members under specific domains
S.No. Role / Domain Responsibilities
1. Security operations  Implement SIEM technology

 Create correlation rules
 Analyse SOC incidents
 Fine tune correlation rules
 Implement Data Leak Prevention
 Create DLP rules
 Fine tune DLP rules
 Create workflow
2. Vulnerability  Perform network scans

management
 Perform application testing
S.No. Role / Domain Responsibilities
 Test closures through scans

 Scan new images
3. Security governance  Internal audit, risk assessment

 Exception management
 BCP/DR plan, readiness and testing
 Implement audit recommendations
 Manage security incidents
 Security training
 Code review
 Policy/ procedures/ standards
 Review access rights
4. Perimeter security  Manage firewall, IPS, Switches, routers etc.

 Manage AV, HSM, WAF
 Define baseline configurations N/W devices
 Ensure hardening of N/W devices
 Perform periodic review of rules
5. Fraud and forensics  Maintain Fraud Detection policy, process

 Detect fraud incidents
 Manage fraud incidents
 Ensure closure of audit findings
6. Security design and  Review security architecture

architecture
 Review network changes for security
 Review architecture of applications
 Review functionalities of various applications etc.
4.2.6. Business Owners

Business owners hold the primary responsibility for defining the value and classification of assets within their
control by participating in the risk management process and undertaking business impact assessment.
Responsibilities of business owners include:
 Authorize access and segregate duties for individual users and groups including third parties to the
information contained within the organization’s applications.
 Ensure that appropriate access of administration roles or teams exist for their applications to administer
access.
 Ensure implementation and compliance to the information security architecture and policy as applicable for
their business units.
 Be primarily responsible for risk, data security and access of third party partners and vendors to whom line
of business has been outsourced.
 Review the self-assessment of third parties at defined frequency to whom line of business has been
outsourced.
 Conduct security assessments and audits of third party processes/ sites.
 Define information security requirements for third parties in concurrence with the information security team
of the organization.
4.2.7. Business Users

The responsibilities of business users (also referred as ‘users’) with respect to information security include:
 Ensure that they are aware of, and understand, the security requirements for the specific information
systems they use.
 Take all reasonable precautions to protect information systems against unauthorized access, use,
disclosure, modification, duplication or destruction.
 Assist and co-operate in the protection of the information systems they use.
 Comply with the organizations security architecture, policies, procedures, guidelines, and standards.
 Use information systems only as appropriate for their job responsibilities.
 Report security problems, issues, or incidents as per the defined reporting channel.
4.2.8. Data Owners

The responsibilities of data/ asset owners include:
 Ensure that the security requirements are implemented for assets and data under their control.
 Determine access rights for their applications and data.
 Ensure that the applications and data under their control are being administered and operated in a secure
manner.
 Adhere to the information security architecture, policies guidelines, procedures, and standards on the
information systems where the data has been stored.
 Apply policies relating to the systems, data, and other information resources under their control.
 Reporting any suspected cyber security incident.
4.2.9. Internal Audit Team

The responsibilities of Internal Audit Team include the following:
 Internal Audit plan of the organization should have a separate information security plan covering IT/
Technology infrastructure and applications. The audit plan and reports should be presented to the board.
 Conduct audit for third parties/ vendors handling critical data on planned and ad-hoc basis.
 All instances of non-compliance related to information security should be communicated and discussed
with the relevant management and CISO.
4.2.10. Functional Teams

The responsibilities of functional teams such as Operations, Administration, and HR etc., specific to information
security include:
 Ensure appropriate and adequate security mechanisms are provided in the systems and network
infrastructure.
 Provide agreement on security classification of infrastructure components.
 Maintain applicable security tools and applications.
 Monitor secure status on each system and network within its control.
 Have primary ownership to comply with specific security policies, which shall be applicable for systems
development and acquisition.
 Report on security weaknesses and breaches to the management.
 Drive endpoint and server security.
 HR department should ensure that:
o Employees and contractors understand their responsibilities, and are suitable for the roles they are
considered for, and to reduce the risk of theft, fraud or misuse of facilities.
o Relevant employees of the organization and contractors receive appropriate awareness training
and regular updates in organizational policies and procedures, as relevant for their job function.
 Legal department should:
o Assist in negotiation of insurance coverage and/or contracts transferring risk, where available.
o Look into legal effectiveness of policy and legal contractual documents within objective, which they
should abide by all legal obligations.
o Engage with cyber security police officials, lawyers, and government agencies as required.
 IT Department should:
o Govern and provide the operating parameters for individuals' and operating units for the use of the
IT systems, networks, architecture, etc.
o Maintain IT security and data assurance in the organization.
Respective heads of all aforementioned departments should provide leadership to the agreed security program
by driving the same to the teams under their management and mandate compliance. All functional team heads
should designate a suitable and qualified team member who should report the incidents and effectiveness of
security control to CISO/ ISM/ information security team/ CIO.
5. Leadership Commitment
and Support for Security
44 Nepal GEA 2.0 Security Architecture | Leadership Commitment and Support for Security
5. Leadership Commitment and
Support for Security
5.1. Leadership Commitment
It is important that the top management of an organization is involved in the decision-making and demonstrates
leadership commitment with respect to the security policy and architecture. This can be done by:
 Ensuring the information security policy and the information security objectives are established and are
compatible with the strategic direction of the organization;
 Ensuring the integration of the security policy and architecture requirements into the organization's
processes;
 Ensuring that the resources needed for the security architecture and policy are available;
 Communicating the importance of effective information security management and of conforming to the
information security management system requirements;
 Ensuring that the security policy and architecture achieve their intended outcome(s);
 Directing and supporting persons to contribute to the effectiveness of the security policy and architecture;
 Promoting continual improvement;
 Supporting other relevant management roles to demonstrate their leadership as it applies to their areas of
responsibility.
5.2. Governance Imperatives

The purpose of information security governance is to ensure that organizations are proactively implementing
appropriate information security controls to support their mission in a cost-effective manner, while managing
evolving information security risks. As such, information security governance has its own set of requirements,
challenges, activities, and types of possible structures.
To ensure an appropriate level of support of organizational missions and the proper implementation of current
and future information security requirements, each organization should establish a formal information security
governance structure. In this regard, an illustrative information security governance structure has been included
as part of section – “organization structure” of this security architecture.
Information security governance can be defined as the process of establishing and maintaining a framework
and supporting management structure and processes to provide assurance that information security strategies
are aligned with and support business objectives, are consistent with applicable laws and regulations through
adherence to policies and internal controls, and provide assignment of responsibility, all in an effort to manage
risk.
An effective security governance structure provides a multitude of benefits to the organizational management:
 Top management visibility: Provides top management with clear visibility and a strategic agenda on
cyber security matters
 Investment prioritization: Helps prioritize resource investment to reduce cyber-related risks to an
acceptable level
 Activities steering: Creates levers and enables top management to steer cyber security efforts and
coordinate them across all stakeholders
 Stronger ownership: Establishes clear ownership of domains and processes with a clearly defined set of
roles and responsibilities
 Progress monitoring: Oversees cyber security progress by establishing a clearly delineated program
scope with formal feedback loops
The following list is a summary of good information security governance practices that are critical for ensuring
the security of enterprise information assets and should be followed as part of this security architecture:
 Information security responsibilities should be assigned and carried out by appropriately trained individuals.
 Individuals responsible for information security within the organization should be held accountable for their
actions or lack of actions.
 Information security priorities should be communicated to stakeholders of all levels within an organization to
ensure a successful implementation of an information security program.
 Information security activities must be integrated into other management activities of the enterprise,
including strategic planning, capital planning, and enterprise architecture.
 Information security managers should continuously monitor the performance of the security program/ effort
for which they are responsible, using available tools and information.
 Information discovered through monitoring should be used as an input into management decisions about
priorities and funding allocation to effect the improvement of security posture and the overall performance
of the organization.
5.2.1. Management Review

Organizational management should review the information security management system at least annually to
ensure its continuing suitability, adequacy and effectiveness. The information security team should collect/
assess the following information for the purpose of conducting the management review:
 Results of information security audits and reviews;

 Monitoring and measurement results or performance results;
 Feedback from interested parties;
 Changes in external and internal issues that are relevant to the information security management system;
 Techniques, products or procedures, which could be used in the organization to improve the performance
and effectiveness of information security management;
 Status of non-conformities and corrective actions;
 Vulnerabilities or threats not adequately addressed in the previous risk assessment;
 Results of risk assessment and status of risk treatment plan;
 Results from the effectiveness measurements;
 Follow-up actions from previous management reviews;
 Any changes that could affect the information security management;
 Recommendations for improvement.
The minutes of meeting and action items for every management review meeting should be clearly defined,
documented, and tracked.
5.3. Security Resourcing

It is important to have the right resources in order to effectively run the security function in an organization. The
resourcing should be in line with the security objectives of the organization and aligned with the requirements of
the business functions. For security resourcing, it is important to focus on both the people aspect as well as the
technological aspect. These two together will form the crux of the security in an organization.
5.3.1. Human Resources

In order to run the operations of an organization effectively, it is important to not only have an operations team
in place but they need to be complemented by a security team as well. The security team should be
responsible for all security related aspects including end-to-end security of the organization.
Following principles should be taken care of while addressing the sourcing of the human resources component
for security:
 Leverage People: At the end of the day, if an organization creates an elegant design but cannot staff it
with the right talent, it is likely to fail. Hence, finding the right talent and hiring them should be of the prime
importance.
 Identification of roles to protect critical specialists: While sourcing, the organization should have a
clear understanding of the roles for which it is hiring and the specific responsibilities of the same.
 Clarity of roles: In an increasingly dynamic and connected global economy, new organizations are
constantly being created and existing organizations are re-inventing themselves. In response, jobs and job
roles have been changing at a frenetic pace. Clarity of roles provides accountability, reduces confusion by
eliminating unintentional job overlap, establishes an objective basis for measuring and managing
performance and improves collaboration.
 Optimize hierarchy: Any management layer should provide more value to lower levels than just
supervision.
 Strengthen Accountability: If supervisors cannot assess their subordinates’ performance, they will not be
able to exercise adequate control. A good design strengthen accountability for work that the unit or
individual is performing.
The organization should base its sourcing keeping the abovementioned principles in mind.
5.3.2. Tools and Technologies

The various security technologies that should be adopted by organizations under GEA 2.0 to support emerging
digital business requirements and deal with increasingly advanced threat environment by reducing attack
surfaces are given here.
Attack Surfaces and Security Technologies
Attack surface describes the different points where an adversary could get into a system and where he could
retrieve data. There are four main attack surfaces identified – Human, Device, Network and Application.
Table 12. Attack surfaces and security technologies
Attack
Human Device Network Application
Surface
 Employees, third  Adversaries may  Every point of  Running code

parties, gain network may have
customers and unauthorized interaction is a vulnerabilities
administrators access to potential part of which
can be tricked by infrastructures network attack adversaries
Description adversaries to or such as surface. exploit to gain
intentionally endpoints and access to the
perform servers where target system.
unauthorized data is stored or
activities. services are
running.
 Social  Malware  Man-in-the-  Attacks against

Engineering Middle Attack application
Possible  Unauthorized vulnerabilities
Threats  Insider Threats Access  Malware
 DDoS Attack
IAM Asset Discovery Firewall Web Application Firewall
PIM Configuration Management
Fraud Detection Endpoint Management IDS/IPS Code Scanning
Email Security VPN Network ATP Penetration Testing
Remote Access Controls Network Access Control
Vulnerability Assessment
Security Information and Event Management
Threat Intelligence
Security
Data Loss Prevention
Technology
to reduce Data Discovery
Attack
Surfaces BYOD DDoS Protection
Database Firewall HSM
EDR
Governance, Risk and Compliance
Digital Forensics
Malware Analysis
Tokenization
Encryption
The common security technologies, which can be leveraged to address threats posed to various attack
surfaces, are given below. The table summarizes technology description, features and adoption requirements.
Table 13. Description of security technologies
S.No. Area Description
1. Asset Discovery
Description Asset Discovery helps organizations catalogue and locate its IT assets,
providing a continuous profile of all assets on the organization’s network.
The inventory information could then be used for configuration
management.
Features  Continuous real-time asset monitoring

 Compliance check
 Search engine
 Highlight and rank criticality of assets
 Integration with configuration management database
Adoption  Endpoint
Requirements
 Server
 Network Device
2. Configuration Management
Description Configuration Management allows organizations to continuously monitor

and harden the security configurations of their environment’s operating
systems, applications and network devices. It provides governance
ensuring configuration consistency among physical and logical assets.
Features N/A
Requirements
 Server
 Network Device
3. Endpoint Management
Description Endpoint Management can centrally discover, provision, deploy, update

and troubleshoot endpoint devices within an organization. It helps
organizations to protect endpoints from a wide range of threats, including
unpatched operating systems and applications, out-of-date software with
security holes, and improper security configurations.
Features N/A
Requirements
 Server
4. Identity and Access Management
Description Identity and Access Management, enabled by its features, facilitates the
management of digital identities. It enables authorized individuals to access
resources at the right time for the right reasons.
Features  User and Asset Repository / Directory

 User/Account Management and Provisioning
 Access Management (AM)
 Identity Management (IDM)
 Reporting Engine
 Single Sign-On (SSO)
 Federation
Adoption All organization-wide systems and applications should integrate with and
Requirements leverage existing IAM solution.
5. Privileged Identity Management
Description Privileged Identity Management helps organizations manage, automate

and track the use of shared privileged identities.
Features  Centralized administration, secure access, and storage of privileged

shared account credentials
 Role-based access control for shared accounts
 Lifecycle management of shared accounts ownership
 Single sign-on through automated check-out and check-in of shared
credentials
 Auditing of shared credentials access activities
Adoption Where possible, all infrastructure and critical enterprise applications should
Requirements integrate with the PIM solution.
6. Firewall
Description Firewall is a network security device that monitors incoming and outgoing
network traffic and decides whether to allow or block specific traffic based
on a defined set of security rules.
Features  Packet filtering

 Stateful inspection
 Protection against modern threats such as advance malware and
application-layer attacks
Adoption On the edge of network zones (all internal and external traffic must go
Requirements through firewall)
7. Virtual Private Network (VPN)
Description Virtual private network (VPN) is an encrypted connection over the Internet
from a device to a network. The encrypted connection helps ensure that
sensitive data is safely transmitted. It prevents unauthorized people from
eavesdropping on the traffic and allows the user to conduct work remotely.
Features N/A
Adoption
Endpoint
Requirements
8. IDS/IPS
Description Intrusion Detection System monitors network traffic and provides visibility
into security posture of the network.
Intrusion Prevention System inspects network traffic based on
predetermined rules, and decides if the data packets are allowed through
or should be blocked.
Features  Network access control

 Signature-based detection
 Reputation services
 Inspection of SSL-encrypted traffic
Adoption Network
Requirements
9. Remote Access Controls
Description It allows users to access organization’s network and resources from remote
locations while minimizing the risk that an attacker can gain unauthorized
access to the same resources.
Features  Protection of credentials

 Real-time detection and alerting of suspicious behaviour
Adoption Network
Requirements
10 . Web Application Firewall
Description It is a firewall that monitors, filters or blocks data packets as they travel to
and from a Web applications. By applying rules for communication, it
protects web applications from common attacks such as cross-site scripting
(XSS) and SQL injection.
Features  Common web attack protection

 Zero-day attack protection
Adoption
Application
Requirements
11 . Vulnerability Assessment
Description Vulnerability scanners are designed to access computer systems and

networks for known weaknesses such as misconfiguration or flawed
software. Vulnerability scanner also has the capability to customize
vulnerability reports, installed software, open ports and other host
information that can be queried by users to increase network security.
Features  Internal scanner

 External scanner
Adoption N/A
Requirements
12 . Security Information and Event Management (SIEM)
Description SIEM solution centrally collects, stores, and analyses logs from perimeter
to end user. It monitors for security threats in real time for quick attack
detection, containment, and response with holistic security reporting and
compliance management. When the attack occurs in a network using
SIEM, the software provides insight into all the IT components (gateways,
servers, firewalls, and so on).
Features  Data aggregation

 Correlation
 Alerting
 Forensic analysis
Adoption Collection Agents deployed at:

Requirements
 Endpoint
 Server
 Network Device
13 . Threat Intelligence
Description Threat Intelligence is organized, analysed and refined information about

potential or current attacks that threaten an organization. The information
helps organizations to anticipate and respond to sophisticated cyber-
attacks by gaining more insights into attackers’ motivation, intention,
characteristics and methods.
Features  Centralized threat feeds

 Integration with SIEM and other network devices
 Real-time alerts
Adoption Threat data feeds

Requirements
14 . Data Loss Prevention
Description Data Loss Prevention protects sensitive information from being lost,
misused or accessed by unauthorized users. It covers data at rest, data in
motion and data in use.
Features  Data identification

 Data monitoring
 Data protection
 Prioritization
Requirements
 Server
 Network device
15 . Data Discovery
Description Data Discovery helps collect data from various locations such as
databases and endpoints, consolidating it into a single source that can be
easily and instantly evaluated. It allows users to search for specific items or
patterns in data set. It also leverages business intelligence enabling users
to build insights about organization’s data.
Features  Visualization
 Search engine
 Data transformation
Requirements
 Shared drive
16 . Database Firewall
Description Database Firewall monitors databases to identify and protect against

database specific attacks that mostly seek to access sensitive information
stored in the databases.
Features  Database access monitoring

 Database access audit
 Compliance reports generation
 Signature analysis on known database attacks such as SQL injection
and buffer overflow
Adoption Server (database)

Requirements
17 . Encryption
Description Encryption translates data into another format so that only people with
access to the decryption key can read it.
Features  Full disk encryption

 File and directory encryption
 Database encryption
Adoption
Corporate system (laptop/ desktop)
Requirements
18 . Tokenization
Description Tokenization refers to substituting a sensitive data element with a non-

sensitive equivalent (token) that has no extrinsic meaning. The association
between the token and the original value is maintained in a database and
there is no other way to connect the two.
Features  Format preserving tokenization

 Token vault database
Adoption Highly sensitive transaction data

Requirements
19 . Code Scanning
Description Source code analysis tools are designed to analyse source code and/or its
complied versions to help organizations discover security flaws and
vulnerabilities. Code scanning is usually performed as part of source code
review.
Features  Static Code Analysis

 Dynamic Application Analysis
Adoption
In-house developed software/ application
Requirements
20 . Governance, Risk and Compliance (GRC)
Description GRC provides a common foundation for managing policies, controls, risks,
assessments and deficiencies across organization’s lines of business.
Features  Threat Management

 Policy Manager
 Incident Manager
 Compliance Management
 Certification and Accreditation
Adoption N/A
Requirements
21 . Digital Forensics
Description Digital Forensics tools are used to search, preserve and analyse
information obtained from incident victim device and use it as evidence.
Features  Network forensics

 Forensic data analysis
 Mobile device forensics
 Computer forensics
 Database forensics
Adoption  Network
Requirements
 Endpoint
 Standalone solution
22 . Malware Analysis
Description Malware Analysis tools allow organizations to analyse and reverse

engineer malware.
Features  Static analysis

 Dynamic analysis
Adoption
Standalone solution
Requirements
23 . Network Advance Threat Protection (ATP)
Description Network ATP solution uncovers the stealthy threats that would otherwise
evade detection by leveraging global cyber intelligence networks combined
with local organizational context. It also prioritizes, investigates, and
remediates advanced threats across organization network. By monitoring
all traffic coming into or out of the network, the solution is able to inspect
traffic using the multiple advanced detection technologies.
Features  Event correlation and prioritization

 Reputation analysis
 Zero-day threat detection and prevention
Adoption Network (applicable to all organizational traffic including ingress, egress,

Requirements third-parties and subsidiaries)
24 . Email Security
Description Email Security helps to keep sensitive information in email communication

and account secure against unauthorized access, loss or compromise.
Features  Secure email gateway – anti-malware protection, anti-spam protection

 Targeted threat protection – anti-phishing protection
 Data leak protection
 Email encryption
Adoption Server
Requirements
25 . Endpoint Detection and Response (EDR)
Description EDR tools typically record numerous endpoint and network events, and
store this information either locally on the endpoint or in a centralized
database. Databases of known indicators of compromise (IOC), behaviour
analytics and machine-learning techniques are then used to continuously
search the data for the early identification of breaches (including insider
threats), and to rapidly respond to those attacks.
Features  Antivirus
 Host-based Intrusion Detection System
 Ingress/Egress firewall
 APT
Requirements
 Server
26 . Penetration Testing
Description Penetration Testing solution assists security professionals to discover the

known weaknesses in organization’s applications.
Features  Automated crawl

 Active scanning
 Passive scanning
 Man-in-the-middle proxy
 Intruder
 Manual testing tools
Adoption
N/A
Requirements
27 . Network Access Control
Description Network Access Control solution supports network visibility and access
management through policy enforcement on devices and users of
organization networks.
Features  Policy lifecycle management

 Profiling and visibility
 Guest networking access
 Security posture check
Adoption
Network
Requirements
28 . BYOD
Description BYOD solution provides secure access to business email, apps and
content on any device, allowing employees to use their personal mobile
devices and laptops for work.
Features  Mobile device management

 Network access control
 Network security management
 File sharing and sync
 App store
Adoption
Endpoint
Requirements
29 . DDoS Protection
Description The solution protects organization from bombardment of simultaneous data

requests generated from compromised systems.
Features  Volumetric DDoS attack protection

 TCP state-exhaustion DDoS attack protection
 Application layer DDoS attack protection
Adoption
Network
Requirements
30 . Hardware Security Module (HSM)
Description HSMs are hardened, tamper-resistant hardware devices that strengthen

encryption practices by generating keys, encrypting and decrypting data,
and creating and verifying digital signatures.
Features  Cryptographic key provisioning, managing and storing

 Logging and auditing
Adoption
N/A
Requirements
31 . Fraud Detection
Description The solution provides real-time monitoring and analytics, protecting

organization from fraud risks by matching data with predefined check
scenarios.
Features  Machine learning

 Know Your Customer
Adoption
N/A
Requirements
6. Information Security Risk
Management
59 Nepal GEA 2.0 Security Architecture | Information Security Risk Management

6. Information Security Risk
Management
6.1. Risk Management Framework
Organizational management should ensure performance information security risk management in terms of the
following:
 Identification of information security risks that may have an adverse impact on the business processes
 Analysis of these risks to determine the likelihood of occurrence and its consequences on business
operations
 Identification of strategy for mitigation of risks down to either zero or to an acceptable level of risk.
Given below is a reference risk management framework that should be followed by organizations. The given
framework is referenced from the standard ISO 27005 and is internationally recognized.
Figure 7. Risk management framework

The organizational risk management framework should include all identified services, processes, systems, etc.
and should entail risk identification, estimation, evaluation, and further provide mitigation strategies along with
risk acceptance criteria. Additionally, the risk management should include development of a risk mapping and
keeping it up-to-date by defining the indicators to monitor for risk mitigation to an acceptable level, and
development of an inventory of assets with classification and keep it current.
Key parameters such as risk acceptance criteria should be approved by the security committee and senior
management of organizations.
The various steps of the risk management process given above are defined below:
 Context Setting: The context for information security risk management should be established first, which
involves setting the basic criteria necessary for information security risk management, defining the scope
and boundaries, and establishing an appropriate organization operating the information security risk
management.
 Risk Identification: The purpose of risk identification is to determine what could happen to cause a
potential loss, and to gain insight into how, where, and why the loss might happen. Risk identification
should be conducted in consideration of identification of assets, threats, existing controls, vulnerabilities,
and consequences.
 Risk Estimation: Risk estimation may be qualitative or quantitative, or a combination of these depending
on the organizational circumstances.
 Risk Evaluation: Level of risks should be compared against risk evaluation criteria and risk acceptance
criteria as approved by the organizational management.
 Risk Response / Treatment: Controls should be established to reduce, retain, avoid, or transfer the risks
and a risk treatment plan should be defined.
 Residual Risk Evaluation: Residual risk evaluation should be conducted post application of information
security controls for risk response/ treatment.
 Risk Monitoring and Review: Information security risks and their factors (such as value of assets,
impacts, threats, vulnerabilities, likelihood of occurrence) should be monitored and reviewed to identify any
changes in the context of the organization at an early stage, and to maintain an overview of the complete
risk picture.
 Risk Communication: Information about the risks should be exchanged and/or shared between decision-
makers and other stakeholders within an organization.
6.2. Addressing People and Policy Related Risks

6.2.1. Security Policy
Information security adds value to the organization only when taken in the context of the business. Business
objectives drive the requirements for security; security can enable business objectives by efficiently and
effectively managing risk. Balance must be maintained between the drive to accomplish aggressive business
objectives and ability to manage risks influencing the business. The approach for information security for
Government of Nepal must be flexible, remain conscious of the market and the business and result in an
effective, efficient, economical security infrastructure.
In this regard, GEA 2.0 includes a baseline information security policy for organizations. The policy addresses
the following domains:
 Policy management, scope, purpose: Provides management direction and support to ensure protection
of organization’s information assets, and to allow access, use and disclosure of such Information in
accordance with appropriate standards, laws and regulations.
 Personnel security: Specifies the information security requirements that should be integrated in the HR
processes including recruitment, during employment and separation.
 Management of organizational assets: Specifies the importance of information assets including
identification of the asset owner, asset classification and determining confidentiality, integrity and

availability ratings of the assets. The policy establishes the requirement of controls that should be
implemented for protecting Information assets.
 Logical access control: Defines the controls that should be implemented and maintained to protect
Information assets against unauthorized access that poses substantial risk to organizations. The policy
section intends to establish adequate controls for user access management, networks access, operating
system security and mobile computing.
 Physical and environmental security management: Provides direction for the development and
implementation of appropriate physical security controls that are required to maintain the protection of
information systems and processing facilities from physical and environmental threats.
 Security in information systems acquisition, development, and maintenance: Defines the security
requirements that should be identified and integrated during the development and maintenance of
applications, software, products and/or services.
 Security in operations: Defines the controls that should be implemented to prevent unauthorized access,
misuse or failure of the information systems and processing facilities. Confidentiality, integrity and
availability of information processed by or stored in the information systems should be ensured.
 Securing organizational infrastructure: Defines the controls that should be implemented to ensure the
protection of information in networks and its supporting information processing facilities.
 Audit and compliance management: Provides direction to design and implement appropriate controls to
meet legal, regulatory and contractual requirements within the business departments of an organization.
6.2.2. Awareness and Training

Insufficiently trained personnel can be the weakest security link in the organization’s security perimeter and are
the target of social engineering attacks. It is therefore crucial to provide adequate security awareness training to
all new hires, as well as refresher training to current employees periodically.
Security awareness and training provides every employee with a fundamental understanding that there are
imminent and ongoing cyber threats, preparing enterprise employees for common cyber attacks and threats.
Organizations should determine the appropriate content of security awareness training and security awareness
techniques based on the organizational context, specific requirements, and the information systems to which
personnel have authorized access. The content should include a basic understanding of the need for
information security and user actions to maintain security and to respond to suspected security incidents.
Security awareness techniques can include, for example,
 Displaying posters, “do and don’t lists,” or checklists
 Offering supplies inscribed with security reminders
 Generating email advisories/ notices from senior organizational officials,
 Displaying logon screen messages, screensavers and warning banners/messages
 Conducting information security awareness events, in-person, instructor-led sessions
 Awards program (e.g., letters of appreciation)
Security awareness and training should be focused on the organization’s entire user population. Management
should set the example for proper IT security behaviour within an organization. An awareness program should
begin with an effort that can be deployed and implemented in various ways and is aimed at all levels of the
organization including senior and executive managers. The effectiveness of this effort will usually determine the
effectiveness of the awareness and training program.
Information security education and training should also cover general aspects such as:
 Stating management’s commitment to information security throughout the organization;
 The need to become familiar with and comply with applicable information security rules and obligations, as
defined in policies, standards, laws, regulations, contracts and agreements;

 Personal accountability for one’s own actions and inactions, and general responsibilities towards securing
or protecting information belonging to the organization and external parties;
 Basic information security procedures (such as information security incident reporting) and baseline
controls (such as password security, malware controls and clear desks);
 Contact points and resources for additional information and advice on information security matters,
including further information security education and training materials.
A significant number of topics can be mentioned and briefly discussed in any awareness session or campaign:
 Password usage and management – including creation, frequency of changes, and protection
 Protection from viruses, worms, Trojan horses, and other malicious code – scanning, updating definitions
 Policy – implications of noncompliance
 Unknown e-mails/ attachments
 Web usage – allowed versus prohibited; monitoring of user activity
 Spam
 Data backup and storage – centralized or decentralized approach
 Social engineering
 Incident response
 Shoulder surfing
 Use of encryption and the transmission of sensitive/ confidential information over the Internet
 Laptop security while on travel
 Timely application of system patches
 Software license restriction issues
 Supported/ allowed software on organization systems
 Access control issues including least privilege and separation of duties
 Visitor control and physical access to spaces
 Desktop security – Use of screensavers, restricting visitors’ view of information on screen (preventing/
limiting “shoulder surfing”)
 E-mail list etiquette
6.3. Addressing Process Related Risks

The processes part of security architecture ensures that IT and security teams have strategies in place to
proactively prevent and to respond quickly and effectively in the event of a security incident.
Given below are some of the common process related cyber security risks (illustrative):
Table 14. Process related risks
S.No. Risk Probable Impact
1. Inadequate patch  Missing patches can leave loopholes in IT systems, and have
management process the potential to present serious cyber security risks to the
affected systems

2. Unnecessary system access  Unmanaged system access can result in personnel obtaining,
changing, or deleting information that they are no longer
authorized to access. Related problems include:
o Administrators with false assumptions of what actions
any one user may be capable of performing
o Unauthorized disclosure of information: Disclosure of
confidential, sensitive or embarrassing information can
result in loss of credibility, reputation, market share,
and competitive edge
o Loss of productivity: Misuse of IT resources such as
network bandwidth may cause slow response times,
delaying legitimate computer activities that, in time-
critical applications such as stock trading, can be very
costly
o One user (or many individual users) with sufficient
access to cause complete failure
o Inability to prove responsibility for a given action or
hold a party accountable
o Accidental disruption of service by untrained
individuals
3. Inadequate change and  Improperly configured software/ systems/ devices added to

configuration management existing software/ systems/ devices can lead to insecure
configurations and an increased risk of vulnerability
4. Inadequate/ lack of periodic  The objective of a cyber security audit is to provide

security audits management with an assessment of an organization’s cyber
security policies and procedures and their operating
effectiveness. Additionally, cyber security audits identify
internal control and regulatory deficiencies that could put the
organization at risk.
 The audit process is the only true measure by which it is
possible to continuously evaluate the status of the
implemented security program in terms of conformance to
policy, to determine whether there is a need to enhance
policies and procedures, and to evaluate the robustness of the
implemented security technologies. Failure to perform periodic
security audits may lead to unidentified security risks or
process gaps.
5. Inadequate continuity of  An inadequate continuity of operations or disaster recovery

operations and disaster plan could result in longer than-necessary recovery from a
recovery management possible plant or operational outage. Probable impacts could
include business failure, injury or death, financial loss,
reputational loss, etc.
6. Ineffective risk assessment  Lack or misapplication of adequate risk assessment processes

process can lead to poor decisions based on inadequate understanding
of actual risk along with complete misidentification of actual
and applicable security risks.

7. Ineffective risk management  Lack of an adequate risk management process may result in
process the organization focusing its resources on mitigating risks of
little impact or likelihood, while leaving more important risks
unaddressed. It may also result in lack of focus on actual risks
that the organization may be facing.
8. Inadequate security incident  Without an efficient incident response process, response

response process actions may not be completed in a timely manner, leading to
the increased duration of risk exposure for the organization.
9. Insecure SDLC  Failure to secure the SDLC during software development can
leave the software susceptible to many application layer
security risks. It can further cause increment in business risks,
cost of security testing and resolution.
10 . Lack of physical security  Failure to maintain proper physical security controls may
adversely affect the confidentiality, integrity, and availability of
the information
11 . Failure to incorporate security  Acquisition of products and services that do not meet security
requirements in RfPs requirements or ones for which security features are
misunderstood
12 . Failure to request results of  Acquisition of products that do not meet security requirements
independent security testing or ones for which security features are misunderstood
of hardware and software
prior to procurement
13 . Failure to request evidence  Acquisition of products or consumption of services with an

from a third party of its risk insufficient security posture
management and security
practices
14 . Failure to request information  A SDLC process that does not follow security development
from a third party on its practices will likely result in insecure software
secure SDLC process
Based on risk assessment, mitigation planning, and organizational context, the various processes, which
organizations should implement as security best practices, are given below.
Table 15. List of security processes
S.No. Process Description
1. Asset management  The purpose of this process is to provide organization management,

asset owners and the information security team with the following
benefits
o Visibility into all the organization technology assets the
businesses owns and its mapping to business processes.

o Visibility into criticality of the assets and associated

vulnerabilities.
o Provides governance gates to ensure technology assets are
identified and are safe to be used in the production.
2. Personnel security  Human resource plays a very important in ensuring information security
within the organization. Therefore, it becomes important to address
information security requirements related to employees throughout the
lifecycle of an employee/ staff from hiring to separation. These include
but not limited to background checks, trainings, deletion of access etc.
3. Physical and  Effective physical security measures help protect against unauthorized
environmental access, damage, or interference in areas where critical or sensitive
security information is prepared or located, or where information processing
services supporting key business processes are hosted.
 The requirements and placement of each physical security barrier /
control should depend upon the value of the information or service
being protected.
 Each level of physical protection should have a defined security
perimeter, around which a consistent level of physical security
protection should be maintained.
 Physical information processing resources that support key business
processes should be housed in a secure area that should be designed
to reasonably protect the resources from unauthorized physical access,
fire, flooding, explosions, and other forms of natural or man-made
disaster.
4. Communications and  Communication will help to minimize information security risk to a great
operations extent and protect the organization against threat of unintended
management information disclosure.
 The primary objectives of communications and operations
management include:
o Correct and secure operation of systems
o Responsibilities and procedures for management and
operation of systems are established
o Segregation of duties, where appropriate, are implemented
o Development, test, and production environments are separated
o Appropriate information security and service delivery in line
with contractual agreements
o Risk of system failures are minimized
o Availability of adequate capacity to deliver required system
performance
o Safeguards are implemented to prevent, detect, and remove
malicious code
o Integrity and availability of information and information
technology are maintained, etc.

5. Change management  Objective of this process is to ensure all changes are assessed,
approved, implemented and reviewed in a controlled manner.
 The primary purpose of the change management process is to ensure
that standardized methods and procedures are used for efficient and
prompt handling of all changes, in order to minimize impact of change-
related Incidents upon service quality and consequently to improve
day-to-day operations of the organization.
6. Third party  In order to have a seamless expected level of service from third
management parties, organizations should have effective procedures controlling and
monitoring the third party’s activities to ensure confidentiality, integrity
and availability of information, enabling organizations to provide
services and conduct its operations without any interruptions.
 Objective of third party management is to ensure that third parties who
are given access to organization’s information and facilities, have
extremely limited and controlled access to the information systems
assets, and to apply preventive and monitoring mechanisms
commensurate to the level of criticality and sensitivity of the information
shared.
7. Systems planning  Systems planning and acceptance processes enable system/ capacity
and acceptance planning and new system acceptance into the existing infrastructure to
minimize the risk of system failures.
 This process also entails advance planning and preparation required
for ensuring the availability of adequate capacity and resources to
deliver the required system performance, and on the acceptance and
use criteria with respect to the operational requirements of new
systems.
8. Antivirus and  Organizations use various types of software and information assets
malicious software that may be vulnerable to the introduction of malicious code, such as
control computer viruses, network worms, trojan horses and bots.
 Malicious software control processes aim to detect and prevent the
spread of virus, malicious code and other spyware/ malware through
mobile codes and other modes in order to secure the various
information assets owned by the organization.
 The process includes the controls regarding detection, prevention, and
recovery, and appropriate user awareness processes to avoid
unauthorized use or disruption of system, network, or application
resources and other breaches of information security.
9. Data backup and  The purpose of backup and restoration process is to maintain the
restoration integrity and availability of information and data present in the
organization.
 Routine processes for carrying out the agreed back-up strategy, taking
backup copies of data and rehearsing their timely restoration.
 Adequate back-up facilities should be provided to ensure that all
essential information and software can be recovered following an
application failure/ malfunction, data corruption, media failure or a
disaster.

10 . Network security  The implementation of network access processes depends on being

able to identify all the network components (nodes and the
communications infrastructure that support Internet and intra-net
connectivity) and then applying effective controls that will enable
detection, measurement and quick response to any conditions
negatively affecting the secure condition of information contained on
the network.
11 . Media handling  Organizations generally use various types of media to store data and
information. The main types are paper, compact disks, and magnetic
tapes. Media contains confidential proprietary information that needs to
appropriately handled.
 All organizational information should be protected and safeguarded
from being leaked out. In this regard, processes for media storage,
protection mechanisms (such as passwords, lock & keys) for the same,
transportation mechanisms, review and replacement of IT media, and
disposal of media should be established.
12 . Monitoring  Monitoring processes are necessary to ensure that users are only
performing activities that have been explicitly authorized.
 Monitoring is an important aspect of security as it serves a dual
purpose of acting as a deterrent to malicious activity and provides audit
trails for reconstruction whenever required.
 Monitoring should be performed in a systematic manner and
procedures should be administered to ensure the required controls are
in place around the monitoring mechanism.
13 . Access control  It is important to implement an effective and efficient process for user
access management since it reduces the risks associated with
unauthorized access, modification or disclosure of data that could lead
to compromise of critical information, which in turn could result in
financial and reputation losses to the organization.
 The user access management process is deployed for controlled
access to information and information resources based on
organizational business and security requirements.
 Consistent and robust processes should be in place for user access
provisioning, user access de-provisioning, privilege access
management, password management, and periodic review of user
access.
14 . Business continuity  Business Continuity Management process is a holistic management

management process that identifies potential impacts that threaten an organization
and provides a framework for building resilience and the capability for
an effective response that safeguards the interests of its key
stakeholders, reputation, brand and value creating activities.
 The core objective of this process is to ensure:
o Critical activities are identified and protected ensuring their
continuity
o An incident management capability is enabled to avoid
incidents becoming a crisis

o Organization’s understanding of itself, and its relationships with

other organizations / agencies is enhanced
o Relevant regulators or government departments, local
authorities and the emergency services, is properly
documented and understood
o Staff are trained to respond effectively to an incident or
business interruption through appropriate exercising
o Staff are properly supported and communicated with, in the
event of business interruption
o Organizational reputation is protected
15 . Cryptography  This process addresses the use of cryptographic controls to protect the
management confidentiality, authenticity or integrity of information. This process
assures that the organization has capabilities to deal with increasing
data / information security requirements.
 The implementation of cryptographic security controls is important for
organizations to ensure that the information systems are secure, and
compliant with legal and regulatory requirements.
16 . Compliance  The compliance processes enhance the importance of having security

monitoring that includes user reporting of security related events and
violations, monitoring of events, provision of mechanisms to retrieve
and report information on logged events, and a process for responding
to security incidents.
 The compliance process establishes requirements for organization’s
enterprise-wide compliance with information security policies,
standards, procedures, guidelines and applicable laws and regulations.
17 . Information labelling  Information labelling and handling process enumerates a set of rules
and handling for information labelling and handling which should be implemented in
accordance with the classification scheme adopted by the organization.
 This process details the procedures to label and handle organization’s
information systems assets in order to protect them from unauthorized
disclosure and misuse.
 The Information labelling and handling process should be used in
conjunction with the organization’s asset classification process and
standard.
18 . Audit management  The purpose of this process is to familiarize all concerned with the work
practices adopted for conducting Information security audits (Internal
and External). An annual audit program should be established that
contributes in the determination of the effectiveness of information
security practices.
 The management should ensure that audit objectives are established
and entrust lead internal auditor with the responsibility to manage the
program. Further, it will also help to standardize the audit methodology
and maintain optimum quality of results.
 The audit program should focus on those entities that are of
significance to the management of the organization. The audit program

should have one external and internal audit as part of the audit
calendar.
 The external security audit should be conducted every year, and
should be conducted by the external agency to ensure compliance to
the management system requirements. The internal audits should be
conducted by a separate team who is not part of information security
team.
19 . Security control  Purpose of this process is to define the approach for measuring the
effectiveness effectiveness of implemented security controls in order to lower the risk
measurement exposure to an acceptable level. Risk analysis process defines the
critical variables that, when monitored, shows the risk exposure level
and effectiveness of the existing controls. Organizations should
establish a measurement system capable of determining the
effectiveness of controls in accordance with Annex A of the ISO
27001:2013 standard.
 The objective of establishing this process is:
o To show ongoing improvement and enhancement of the
Information security controls
o To show level of compliance (with Standards, contracts, SLAs,
OLAs, etc.).
o To justify the return on investment for the security controls
implemented.
o To justify any past/ future expenditure (new security software,
hardware, training etc.).
o To identify where implemented controls are not effective in
meeting their objectives.
o To provide confidence to senior management and stakeholders
that implemented controls are capable of lowering the risk
exposure of the organization, to an acceptable level.
20 . IT infrastructure and  The objective of this process is to establish security governance gates
application security to move new IT infrastructure (server/ device) or an application to
governance production environment. This process should be applicable on all
applications that move from pre-production/ development environment
to production environment for first time or any further upgrades.
 Any chances to production application/ servers/ devices for business
needs should follow change management process and security
component should be a part of the change management process.
 It is important to carry out security assessment of IT infrastructure,
including servers, network devices, applications and other components,
before commissioning into production in order reduce information
security risk to ensure a safe and secure computing environment.
 IT infrastructure and application security process provides a guideline
to secure production environment from known attacks and be
compliant to legal requirements (such as Electronic Transaction Rules
2064 (2007) and The Electronic Transactions Act, 2063 (2008)).

21 . System development  System development and maintenance process is framed to produce

and maintenance robust systems on which organizations can depend, which requires a
sound approach and methodology to system development.
Accordingly, this process covers the organization of systems
development staff, the methodology used in developing systems,
quality assurance, and the security of development environments.
22 . Exception  Exceptions are deviations reported against the defined and approved
management organizational policies for specified periods. Policy exceptions are
reported due to change in business circumstances or due to any
technology constraint.
 The purpose of exception management process is to ensure that
adequate mechanism is in place to report any policy exception.
 The main objectives of exception management process are to ensure
the following:
o Establish a process for obtaining exception of security policies
along with document, approve and retain the policy exception
records.
o Identification of risks that arises due to policy exception.
o Ensure risks are accepted by business owners.
o Implementation of appropriate control to bring residual risk
within acceptable risk value range.
o Track approved policy exception for the approved time period.
o Ensure policy exceptions extensions are contained and are not
reported more than three times.
23 . VPN access  The objective of the VPN access management process is to ensure
management that only the authorized users have access to the organizational
systems.
24 . Vulnerability  The purpose of vulnerability management process is to identify, assess

management and validate vulnerabilities of Information systems with the following
benefits:
o Vulnerabilities can be detected proactively and reactively from
various sources.
o Vulnerabilities are segregated based on impact, and
consolidated and tied to respective information assets for
prioritization and mitigation.
25 . Patch management  Organizations should endeavour to protect information systems from

known vulnerabilities and security risks by applying the latest patches
recommended by product vendors, or implement other compensatory
security measures.
 Before security patches are applied, proper risk evaluation and testing
should be conducted to minimize any undesirable effects to the normal
running of information systems. A clear operational process that
enables rapid testing and deployment should be established.

26 . Incident management  Information is an asset and like other important business assets, the
information asset has value to an organization and consequently needs
to be secured. Handling information breaches is different from regular
incident management and requires additional actions by an
organization.
 Information security incident can impact any of the information
attributes confidentiality, integrity and availability, and thus security
incident response and management capability is necessary for
detecting information security incidents, minimizing loss and damage,
mitigating the exploited weaknesses and restoring information assets
and facilities in a timely manner.
 The objective of this process is to manage security incidents
consistently and effectively. Security incident response is the ability to
detect and resolve problems that threaten people, process, technology
and facilities. This process ensures:
o Incident Identification
o Timely reporting & appropriate response
o Validation, Analysis
o Containment
o Restoration of partial or complete service based on
management expectation
o Root Cause Analysis
o Employee Health & Safety during incident
o Embedment of incident learning into the organization
o Non recurrence
27 . Document and record  Documents required by an organization’s information security

control management system and security architecture should be protected and
controlled.
 Records should remain legible, readily identifiable and retrievable. The
controls needed for the identification, storage, protection, retrieval,
retention time and disposition of records should be documented and
implemented.
6.4. Addressing Technology Related Risks

The technology part of security architecture ensures that IT and security teams have tools and technologies in
place to proactively prevent and to respond quickly and effectively in the event of a security incident.
Given below are some of the common technology related cyber security risks (illustrative):

Table 16. Technology related risks
1. Unneeded services running  Many operating systems are shipped and installed with a
on organizational network number of services running by default. Every service that runs
is a security risk, partly because intended use of the service
may provide access to system assets, and partly because the
implementation may contain exploitable bugs. Services should
run only if needed, and an unneeded service is a vulnerability
with no benefit.
2. Inadequate log management  Inadequate log management can lead to various security
and integrity checking issues:
o Failure to detect critical events.
o Removal of forensic evidence.
o Log wipes.
 Similarly, inadequate integrity checking can lead to issues such
as:
o Compromise of smart device, head node, or utility
management servers.
o Buffer overflows.
o Covert channels.
o Man-in-the-middle.
o Denial of service or distributed denial of service (DoS /
DDoS).
3. Insufficient redundancy  Systems can be exposed to intentional or unintentional denial

of service.
4. Inadequate network  Direct compromise of any portion of the network from any other
segregation portion of the network
 Compromise of the utility network
 VLAN hopping
 Network mapping
 Service / device exploit
 Covert channels
 Back doors
 Worms and other malicious software
 Unauthorized multi-homing
5. Insufficient/ weak  An adversary can gain unauthorised access to organizational

authentication and systems. Additionally, systems become vulnerable to the
authorization of users following attacks:
o DoS / DDoS
o Man-in-the-middle attacks

o Session hijacking
o Authentication sniffing
o Session injection
6. Operating system  Vulnerabilities at the operating system level may help

vulnerabilities undermine the other security controls in place.
7. Inadequate malware  Malicious software can result in performance degradation; loss

protection of system availability; and the capture, modification, or deletion
of data. Malicious software may also affect the operation of
grid hardware.
8. Insecure firmware updates  Insecure firmware updates may allow the introduction of
malware into critical grid equipment. As this malware can
potentially alter the behaviour of that equipment, the
consequences can be serious.
9. Application layer risks (such  Exploitation of application layer weaknesses may result in a
as OWASP Top 10) confidentiality, integrity, or availability impact on the system.
Refer Annexure 3 – Common Web Application Security Risks and
Security Vulnerabilities for more details.
10 . Insufficient patch  Missing patches can leave loopholes in IT systems, and have
management the potential to present serious cyber security risks to the
affected systems
Based on risk assessment, mitigation planning, and organizational context, an illustrative list of various security
tools and technologies, which organizations can implement as security best practices, are given in Section
“Tools and Technologies”.

7. Continual Security
Assurance
75 Nepal GEA 2.0 Security Architecture | Continual Security Assurance

7. Continual Security Assurance
Cyber Assurance is the warranted confidence that the digital world, i.e. the interconnected and networked
systems of an organization, are adequately secure to meet operational needs, even in the presence of attacks,
failures, accidents, and unexpected events. This requires appropriate consideration of security across all
aspects of acquisition, development and deployment, and operations and sustainment.
The goal of continual security assurance is to ensure that organizational systems are Cyber Security effective,
meet at least the minimum baseline requirements, and support the organizational mission. Continual security
assurance part describes the Cyber Security assurance mechanisms that inform organizational management
about the long term cyber security strategy which needs to be implemented for protection of the company.
Implementing this drives performance improvement by self-identifying, preventing, and correcting issues.
Cyber Assurance must be effectively fused with day-to-day acquisition, development, and operational activities
and not viewed as separate add-on actions. In order to assure the operational security characteristics of the
digital world, appropriate methods and metrics for managing and monitoring are critical.
With the highly interconnected, complex environments in use today, effective cyber assurance must be
addressed across multi-program acquisitions, through the supply chains, and among operational environments
that span across multiple departments of an organization.
7.1. Security Assessment

Information security testing or assessment is the process of determining how effectively an entity being
assessed (e.g., host, system, network, procedure, person – known as the assessment object) meets specific
security objectives. Assessment results are used to support the determination of security control effectiveness
over time. Security testing is to help organizations confirm that their systems are properly secured and identify
any organization security requirements that are not met as well as other security weaknesses that should be
addressed.
Because information security assessment requires resources such as time, staff, hardware, and software,
resource availability is often a limiting factor in the type and frequency of security assessments. Evaluating the
types of security tests and examinations the organization will execute, developing an appropriate methodology,
identifying the resources required, and structuring the assessment process to support expected requirements
can mitigate the resource challenge. This gives the organization the ability to reuse pre-established resources
such as trained staff and standardized testing platforms; decreases time required to conduct the assessment
and the need to purchase testing equipment and software; and reduces overall assessment costs.
A phased information security assessment methodology offers a number of advantages. The structure is easy
to follow, and provides natural breaking points for staff transition. Its methodology should contain at minimum
the following phases:
 Planning – Critical to a successful security assessment, the planning phase is used to gather information
needed for assessment execution – such as the assets to be assessed, the threats of interest against the
assets, and the security controls to be used to mitigate those threats – and to develop the assessment
approach. A security assessment should be treated as any other project, with a project management plan
to address goals and objectives, scope, requirements, team roles and responsibilities, limitations, success
factors, assumptions, resources, timeline, and deliverables.
 Execution – Primary goals for the execution phase are to identify vulnerabilities and validate them when
appropriate. This phase should address activities associated with the intended assessment method and
technique. Although specific activities for this phase differ by assessment type, upon completion of this
phase assessors will have identified system, network, and organizational process vulnerabilities.
 Post-Execution – The post-execution phase focuses on analysing identified vulnerabilities to determine
root causes, establish mitigation recommendations, and develop a final report.

7.1.1. Review Techniques
Review techniques passively examine systems, applications, networks, policies, and procedures to discover
security vulnerabilities. They also gather information to facilitate and optimize other assessment techniques.
Because review techniques are passive, they pose minimal risk to systems and networks. Some of the
common review techniques – documentation, log, ruleset, and system configuration review; network sniffing;
and file integrity checking – are given below.
Table 17. Review techniques
Baseline skill set

Review Capabilities of the
S.No. Brief description required from the
technique technique
assessor
1. Documentation  Documentation review Evaluates policies General knowledge
Review determines if the technical and procedures for of security from a
aspects of policies and technical accuracy policy perspective
procedures are current and and completeness
comprehensive.
 Documents to review for
technical accuracy and
completeness include security
policies, architectures, and
requirements; standard
operating procedures; system
security plans and authorization
agreements; memoranda of
understanding and agreement
for system interconnections; and
incident response plans.
 Documentation review does not
ensure that security controls are
implemented properly – only that
the direction and guidance exist
to support security infrastructure.
2. Log Review  Log review determines if security  Provides Knowledge of log

controls are logging the proper historical formats and ability
information, and if the log information on to interpret and
management policies are being system use, analyse log data;
adhered to. Log review may also configuration, ability to use
reveal problems such as and automated log
misconfigured services and modification analysis and log
security controls, unauthorized correlation tools
accesses, and attempted  Could reveal
intrusions. potential
problems and
 Log information that may be policy
useful while conducting security deviations
assessments include –
Authentication server logs, IDS
IPS logs, firewall and router
logs, application logs, antivirus
logs, security solution logs such
as patch management solution.
 Automated tools are available
that can significantly reduce
review time and generate

Baseline skill set
technique technique
assessor
predefined and customized
reports that summarize log
contents and track them to a set
of specific activities.
3. Ruleset  A ruleset is a collection of rules Reveals holes in Knowledge of
Review or signatures that network traffic ruleset-based ruleset formats and
or system activity is compared security controls structures; ability to
against to determine what action correlate and
to take – for example, forwarding analyse rulesets
or rejecting a packet, creating an from a variety of
alert, or allowing a system event. devices
 Review of these rulesets is done
to ensure comprehensiveness
and identify gaps and
weaknesses on security devices
and throughout layered
defences such as network
vulnerabilities, policy violations,
and unintended or vulnerable
communication paths.
 Rulesets to review include
network- and host-based firewall
and IDS/IPS rulesets, and router
access control lists.
4. System  System configuration review is  Evaluates the Knowledge of

Configuration the process of identifying strength of secure system
Review weaknesses in security system configuration,
configuration controls, such as configuration including OS
systems not being hardened or hardening and
configured according to security  Validates that security policy
policies. systems are configuration for a
configured in variety of operating
 Assessors using manual review accordance with systems; ability to
techniques rely on security hardening use automated
configuration guides or policy security
checklists to verify that system configuration testing
settings are configured to tools
minimize security risks.
 Automated tools are often
executed directly on the device
being assessed, but can also be
executed on a system with
network access to the device
being assessed. While
automated system configuration
reviews are faster than manual
methods, there may still be
settings that must be checked
manually.
5. Network  Network sniffing monitors  Monitors General

Sniffing network communication, network traffic Transmission
decodes protocols, and on the local Control Protocol/

Baseline skill set
technique technique
assessor
examines headers and payloads segment to Internet Protocol
to flag information of interest. capture (TCP/IP) and
information networking
Organizations can deploy network
such as active knowledge; ability to
sniffers in a number of locations
systems, interpret and
within an environment. These
operating analyse network
commonly include the following:
systems, traffic; ability to
 At the perimeter, to assess communication deploy and use
traffic entering and exiting the protocols, network sniffing
network services, and tools
applications
 Behind firewalls, to assess that
rulesets are accurately filtering  Verifies
traffic encryption of
communications
 Behind IDS/ IPS, to determine if
signatures are triggering and
being responded to
appropriately
 In front of a critical system or
application to assess activity
 On a specific network segment,
to validate encrypted protocols.
6. File Integrity  File integrity checkers provide a Identifies changes General file system
Checking way to identify that system files to important files; knowledge; ability to
have been changed computing can also identify use automated file
and storing a checksum for certain forms of integrity checking
every guarded file, and unwanted files, tools and interpret
establishing a file checksum such as well-known the results
database. attacker tools
 File integrity checking is most
effective when system files are
compared with a reference
database created using a
system known to be secure—
this helps ensure that the
reference database was not built
with compromised files. The
reference database should be
stored offline to prevent
attackers from compromising the
system and covering their tracks
by modifying the database.
7.1.2. Identification and analysis of active devices, associated ports and

services
Identifying active devices and their associated ports and services, and analysing them for potential
vulnerabilities can be used by an assessor to continue to explore devices that will validate existence of the
vulnerabilities.

Table 18. Identification and analysis techniques
Identification Baseline skill set

Capabilities of
S.No. and analysis Brief description required from the
the technique
techniques assessor
1. Network  Network discovery uses a number  Discovers
discovery of methods to discover active and active devices
responding hosts on a network,
identify weaknesses, and learn  Identifies
how the network operates. Both communication
passive (examination) and active paths and
(testing) techniques exist for facilitates
discovering devices on a network. determination
of network
 Passive techniques use a architectures General TCP/IP and
network sniffer to monitor network networking
traffic and record the IP knowledge; ability to
addresses of the active hosts, use both passive
and can report which ports are in and active network
use and which operating systems discovery tools
have been discovered on the
network. Active techniques send
various types of network packets,
such as Internet Control Message
Protocol (ICMP) pings, to solicit
responses from network hosts,
generally through the use of an
automated tool.
2. Network port  Network port and service  Discovers General TCP/IP and
and service identification involves using a port active devices networking
identification scanner to identify network ports knowledge;
and services operating on active  Discovers knowledge of ports
hosts and the application that is open ports and and protocols for a
running each identified service. associated variety of operating
services/ systems; ability to
applications use port scanning
tools; ability to
interpret results from
tools
3. Vulnerability  Vulnerability scanning identifies  Identifies hosts General TCP/IP and

scanning hosts and host attributes (e.g., and open ports networking
operating systems, applications, knowledge;
open ports), and attempts to  Identifies
knowledge of ports,
identify vulnerabilities rather than known
protocols, services,
relying on human interpretation of vulnerabilities
and vulnerabilities
the scanning results. (note: has high
for a variety of
false positive
operating systems;
rates)
ability to use
 Often provides automated
advice on vulnerability
mitigating scanning tools and
discovered interpret/ analyse
vulnerabilities the results
4. Wireless  Wireless scanning should be  Identifies General knowledge

scanning conducted using a mobile device unauthorized of computing and

Identification Baseline skill set
Capabilities of
S.No. and analysis Brief description required from the
the technique
techniques assessor
with wireless analyser software wireless radio transmissions
installed and configured—such as devices within in addition to specific
a laptop, handheld device, or range of the knowledge of
specialty device. scanners wireless protocols,
services, and
Following factors should be  Discovers architectures; ability
considered when planning technical wireless to use automated
wireless security assessments: signals outside wireless scanning
of an
 Location of facility being scanned and sniffing tools
organization’s
 The security level of the data to perimeter
be transmitted using wireless
 Detects
technologies
potential
 How often wireless devices backdoors and
connect to and disconnect from other security
the environment violations
 Existing deployments of wireless
intrusion detection and prevention
systems
7.1.3. Vulnerability validation

Vulnerability validation techniques use information produced from target identification and analysis to further
explore the existence of potential vulnerabilities.
Table 19. Vulnerability validation
Vulnerability Baseline skill set

Capabilities of
S.No. validation Brief description required from the
the technique
techniques assessor
1. Password  Password cracking is the process  Identifies Knowledge of secure
cracking of recovering passwords from weak password
password hashes stored in a passwords composition and
computer system or transmitted and password password storage for
over networks. policies operating systems;
ability to use
 It is performed on hashes that are automated cracking
either intercepted by a network tools
sniffer while being transmitted
across a network, or retrieved
from the target system, which
generally requires administrative
level access on, or physical
access to, the target system.
2. Penetration  Penetration testing is security  Tests security Extensive TCP/IP,

testing testing in which assessors mimic using the networking, and OS
real-world attacks to identify same knowledge;
methods for circumventing the methodologies advanced
security features of an application, and tools that knowledge of
system, or network. It often attackers network and system
involves launching real attacks on employ vulnerabilities and

Vulnerability Baseline skill set
Capabilities of
S.No. validation Brief description required from the
the technique
techniques assessor
real systems and data that use  Verifies exploits; knowledge
tools and techniques commonly vulnerabilities of techniques to
used by attackers. evade security
 Demonstrates detection
 Some categories of vulnerabilities how
exploited by penetration testing vulnerabilities
include misconfigured security can be
settings, kernel flaws, buffer exploited
overflows, insufficient input iteratively to
validation, symbolic links, file gain greater
descriptor attacks, race access
conditions, and incorrect file and
directory conditions.
3. Social  Social engineering is an attempt  Allows testing Ability to influence

engineering to trick someone into revealing of both and persuade
information (e.g., a password) that procedures people; ability to
can be used to attack systems or and the remain composed
networks. human under pressure
element (user
 One form of digital social awareness)
engineering is known as phishing,
where attackers attempt to steal
information such as credit card
numbers, Social Security
numbers, user IDs, and
passwords. Phishing uses
authentic-looking emails to
request information or direct users
to a bogus Web site to collect
information. Other examples of
digital social engineering include
crafting fraudulent e-mails and
sending attachments that could
mimic worm activity.
7.2. Third Party Auditing

In order to increase the accountability and credibility of the organization, it is important to devise a strong/
robust security governance structure. An independent body can be involved to oversee the security
governance, risk, compliance and performance for the organization in order to enhance governance and
transparency, entitlement and access to information, data protection and overall perimeter security. All the
assessments conducted by such a body should be independent of the organization’s management and the
agency should be answerable to the senior most leadership only. This will ensure unbiased and effective
results. Following are the areas for which the third party agency can be included:
 Governance – Security issues have to be addressed in terms of business risk through good governance. It
is important to design security organization and communication strategy to provide visibility to stakeholders
which create an information security culture. The governance structure should ensure the involvement of all
stakeholders and third party vendors who have access to any sorts of data sensitive to the organization.
The governance body should aim to design a comprehensive security framework based on international
standards and best practices.
 Risk – Establishing a system to proactively identify, classify and mitigate risks in a timely manner. This can
be done by conducting periodic risk assessments and risk profiling. Such exercises provide a visibility into
the risks in the ecosystem. The risks can then be prioritized and treated to avoid major security incidents. A

standard process based risk assessment methodology including the risk acceptance and mitigation criteria
may be leveraged. Dashboards can be used to present a unified view to the management for risk
mitigation.
 Compliance – Compliance is critical for organisations to understand the vulnerable areas, which may lead
to major security incidents. Detailed process and procedures related to the periodic compliance
assessments for the internal and external ecosystem partners including audit calendar, checklists, audit
reporting and sampling mechanism shall be created. This will help in a non-biased assessment for all the
stakeholders and develop approaches to promote closures. The governance body shall ensure that the
organization is compliant with industry standards and best practices. Unified dashboards can be leveraged
to present an overview to the management for decision making.
 Performance – In the overall assessment of the ecosystem, a framework to measure the performance of
the ecosystem members is extremely important. The government body should perform tests to ensure that
the reports prevailing in the existing environment do not compromise on the integrity, completeness and
accuracy of the presented data and information. In order to achieve this goal, the security SLA
management framework can be developed in the design itself. This framework should include both
operational level SLAs as well as security SLAs and adequate penalties may be levied. Periodic
assessment and audits should also be carried out to ensure their adherence.
 Fraud and Forensic Investigations – In order to assess various fraud scenarios and proactively mitigate
them, fraud and forensics investigation is necessary. It also enables a detailed root cause analysis for any
incident or fraud so as to curb the possibility future occurrence. A forensics lab can be implemented with all
the necessary tools to conduct investigations. Various fraud management tools may be leveraged for this
purpose.
7.3. Service Provider Performance Management

The factors that should be considered when selecting, implementing, and managing information security
services include:
 The type of service arrangement;
 Service provider qualifications, operational requirements and capabilities, experience, and viability;
 Trustworthiness of service provider employees;
 Service provider’s capability to deliver adequate protection for the organization systems, applications, and
information.
These considerations will apply (to varying degrees) to every information security service depending on the
size, type, complexity, cost, and criticality of the services being considered, and the specific needs and context
of the organization implementing or contracting for the services.
A service agreement can take many different forms depending upon the type and scope of the service, the
service arrangement, and type of organization. The sample service agreement outline provided in this appendix
is intended solely as a guide; the specific format, clauses, and terms will be unique to each organization. IT
security managers should develop their service agreements only after negotiations with the service provider
and, most importantly, in consultation with their organization’s legal and contractual experts.
Given below are the various areas which should be included in service provider contracts for provision of
security services – whether implementation or consulting.
Table 20. Illustrative areas for service provider contracts
S.No. Area Description Components
1. Introduction Introduces the purpose, participants,  Purpose

and service
 Participants
 General service description

S.No. Area Description Components
2. Service Describes the environment in which  Equipment

environment the organization will perform the
service, from physical location, to  Facilities
hardware/software being used, to the  Entities and locations
policy and procedures the service
provider will need to follow.  Policies, procedures, and
standards
 Agreements and licenses
3. Roles and Describes the roles and  Service provider responsibilities

responsibilities responsibilities of all major
participants. The service provider  Service tasks
responsibilities need to articulate not  Documentation
just the service tasks, but also the
documentation of their services,  Service support
reporting their actions, and support  Reporting requirements
functions (e.g., if the new service will
likely initiate trouble calls, the service
agreement should articulate who and
how these calls will be handled).
4. Service levels Identifies the metric, the service level,  Objectives

and methodology for assessing the
service level. Organizations may  Metrics
choose to articulate the service level  Service levels
in a range: from unacceptable to
minimum to interim to target, or they  Service level assessment
may choose to set varying service
levels for various user groups or
schedule times. If so, each service
level will need to be articulated.
5. Terms and Provides the costs and period of  Costs

adjustments performance of the service levels and
roles and responsibilities articulated in  Period of performance
the previous sections as well as  Dispute resolution
providing processes for resolving
service agreement disputes,  Remedies for non-compliance
remedying non-compliance, and  Maintenance of agreements
amending the agreement to account
for changing requirements.
7.3.1. SLA Measurement and Service Maturity Index

The SLA measurement process is the end-to-end process for SLA measurement, validation, approval and
signoff, and is broadly classified in four steps:
 SLA calculation: The service provider collects data points and calculates the periodic SLA, as applicable,
and submits the report to the organization
 Validation of SLA calculation: The organization itself validates the SLA data, calculations and penalties
as per the report submitted by the service provider
 SLA Signoff: The organization provides approval and sign off on the SLA report.

Service maturity index indicates the maturity of the service levels delivered by the service providers. Service
Maturity Index has been divided into five phases, depending upon the level of services delivered and reported
by service providers. These five phases are.
 Initial Phase is the phase where services are delivered by the service provider, however, service levels are
not appropriately defined for each service area.
 Evolving Phase is the phase where service levels are defined, however, processes are not defined and
streamlined to measure and suggest improvements for service levels delivered by the service provider.
 Strategic Phase is the phase where service levels are defined and reported by the service provider,
however, a streamlined methodology does not exist to validate the service levels reported.
 Optimization Phase is the phase where service levels are defined, measured and reported. An SLA
methodology exists to validate the service levels reported by the service provider. In this phase, there is
focus on process improvement for most functions of the organization; however, the areas for improvement
in the service delivery are not identified appropriately on a regular basis.
 Innovation Phase is the phase in which new techniques for enhancing the processes are developed for
improving service quality. Innovation phase is usually a continuous improvement process and ensures that
service quality is enhanced on a continuous basis.
Table 21. Illustrative SLAs for service providers for security implementation services
S.No. Category Metric Type Definition Target Severity
1. Security Completion Creation of 100% 8 weeks from  One week delay –

process and and coverage process and procedure date of signing 0.1% LD
procedure documents as defined of the contract
documents in the RfP  2 weeks delay –
0.2% LD
 More than 2
weeks delay –
0.4% LD
2. Patch Completion Metric: Completion as Quarterly  One week delay –

management per schedule & 0.1% LD
review comprehensive
coverage  2 weeks delay –
0.2% LD
 More than 2
weeks delay –
0.4% LD
3. Firewalls Successful  Successful 8 weeks from  One week delay –

implementation deployment of the date of signing 0.1% LD
of firewalls firewall and UAT. of the contract
 2 weeks delay –
 Hardening of the 0.2% LD
firewall as per CIS
benchmarks or  More than 2
vendor weeks delay –
specifications. 0.4% LD
 All Ports disabled

by default.
 Any open ports
should have a
business

S.No. Category Metric Type Definition Target Severity
justification and
approval in place.
 Submission of
report to the
organization.

8. Annexure 1: Vulnerability
Management
87 Nepal GEA 2.0 Security Architecture | Annexure 1: Vulnerability Management

8. Vulnerability Management
For all applications and network infrastructures, application penetration testing and network vulnerability
assessments should be conducted for the following scenarios.
 Prior to system commissioning or when major changes are performed

 Periodically for internet-facing applications
 Periodically for internal applications
All findings should be remediated in a timely manner to ensure minimal technology risk prior to system
commissioning.
Vendor Selection Criteria
 Good track record in Penetration Testing services

 The penetration tester shall be required to sign a non-disclosure agreement with the organization
 The penetration tester should have relevant certificates in cyber security field such as CEH, ECSA, OSCP,
etc.
Testing Scope
 The penetration testing should cover the entire application and the infrastructure hosting the applications
(e.g. web/ app server, DB server etc.)
 The web/ mobile application penetration test should cover all functions and pages of the application.
 Whitebox/ greybox testing should be conducted on the production code in an UAT environment.
 Where applicable, the testing result should be verified in production environment in a non-intrusive manner.
Methodology
A phased information security assessment methodology offers a number of advantages. The structure is easy
to follow, and provides natural breaking points for staff transition. Its methodology should contain at minimum
the following phases:
 Planning – Critical to a successful security assessment, the planning phase is used to gather information
needed for assessment execution – such as the assets to be assessed, the threats of interest against the
assets, and the security controls to be used to mitigate those threats – and to develop the assessment
approach. A security assessment should be treated as any other project, with a project management plan
to address goals and objectives, scope, requirements, team roles and responsibilities, limitations, success
factors, assumptions, resources, timeline, and deliverables.
 Execution – Primary goals for the execution phase are to identify vulnerabilities and validate them when
appropriate. This phase should address activities associated with the intended assessment method and
technique. Although specific activities for this phase differ by assessment type, upon completion of this
phase assessors will have identified system, network, and organizational process vulnerabilities.
 Post-Execution – The post-execution phase focuses on analysing identified vulnerabilities to determine
root causes, establish mitigation recommendations, and develop a final report.
Network Vulnerability Assessment
 The objective of network vulnerability assessments is to identify weaknesses, which may lead to
vulnerabilities on host systems and network devices being exploited remotely.

 The assessment should include but is not limited to (i) host discovery (ii) port scanning and (iii) service
identification.
 The assessment should be a combination of automated scanning and manual testing.
 The assessment should include the following areas:
o OWASP Top 10 and SANS Top 25 vulnerabilities and risks
o Ports identification
o Backdoors
o CGI abuses including XSS
o CISCO security weaknesses
o Databases vulnerabilities
o Default accounts
o DNS vulnerabilities
o Finger abuses
o Peer-to-peer file share
o Firewall vulnerabilities
o Operating systems security weaknesses
o Detection of RPC programs
o Vulnerable services
o SMTP weaknesses
o SNMP weaknesses
o Web server vulnerabilities
o User management weaknesses
o FTP misconfiguration
Application Penetration Testing
 The purpose of application penetration testing is to identify the weaknesses and vulnerabilities on the web
and mobile applications and the associated web services and interfaces to other systems.
 The test should follow a standardised methodology such as OWASP testing guide or other best practices.
 The test should be a combination of automated scanning and manual testing.
 The test shall include OWASP Top 10 vulnerabilities, SANS top 25, as well as the following areas:
o Buffer overflows
o Denial of Service (DoS)
o Insecure access control mechanism
o Malicious code injection
o Cross-Site Request Forgery (CSRF)
o Cross-Frame Scripting (CFS)
o Insecure authentication and session management
o Insecure direct object references
o Insecure cryptographic storage
o Insufficient transport layer protection

o Invalidated redirects and forwards
o Improper error and exception handling
o Security misconfiguration
o Application logic flaws
Reporting Format
The penetration testing and network vulnerability assessment report should include the following sections
 Executive Summary for organization’s management in a business language

 Scope of testing (Application URL, List of IP addresses, Code version, Testing duration)
 Methodology used
 Detailed findings, as observed
o Reference number
o Short issue title
o Risk rating
o Detailed issue description with testing procedures and affected assets
o Implications
o Remediation imperatives
o Follow-up verification status

9. Annexure 2: Common
Web Application Security
Risks and Security
Vulnerabilities
91 Nepal GEA 2.0 Security Architecture | Annexure 2: Common Web Application Security Risks and
Security Vulnerabilities
9. Common Web Application
Security Risks and Security
Vulnerabilities
For web applications, common security risks should be tested and mitigated. Provided by OWASP, the top ten
web application security risks are given below:
Table 22. OWASP top 10 for application security
S.No. Risk Description
1. A1:2017 - Injection  Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur
when untrusted data is sent to an interpreter as part of a command or
query. The attacker’s hostile data can trick the interpreter into
executing unintended commands or accessing data without proper
authorization.
2. A2:2017 - Broken  Application functions related to authentication and session

Authentication management are often implemented incorrectly, allowing attackers to
compromise passwords, keys, or session tokens, or to exploit other
implementation flaws to assume other users’ identities temporarily or
permanently.
3. A3:2017 - Sensitive  Many web applications and APIs do not properly protect sensitive data,
Data Exposure such as financial, healthcare, and PII. Attackers may steal or modify
such weakly protected data to conduct credit card fraud, identity theft,
or other crimes. Sensitive data may be compromised without extra
protection, such as encryption at rest or in transit, and requires special
precautions when exchanged with the browser.
4. A4:2017-XML  Many older or poorly configured XML processors evaluate external

External Entities entity references within XML documents. External entities can be used
(XXE) to disclose internal files using the file URI handler, internal file shares,
internal port scanning, remote code execution, and denial of service
attacks.
5. A5:2017-Broken  Restrictions on what authenticated users are allowed to do are often

Access Control not properly enforced. Attackers can exploit these flaws to access
unauthorized functionality and/or data, such as access other users'
accounts, view sensitive files, modify other users’ data, change access
rights, etc.
6. A6:2017-Security  Security misconfiguration is the most commonly seen issue. This is

Misconfiguration commonly a result of insecure default configurations, incomplete or ad
hoc configurations, open cloud storage, misconfigured HTTP headers,
and verbose error messages containing sensitive information. Not only
must all operating systems, frameworks, libraries, and applications be
securely configured, but they must be patched and upgraded in a
timely fashion.
92 Nepal GEA 2.0 Security Architecture | Annexure 2: Common Web Application Security Risks and Security Vulnerabilities
7. A7:2017- Cross-Site  XSS flaws occur whenever an application includes untrusted data in a
Scripting (XSS) new web page without proper validation or escaping, or updates an
existing web page with user-supplied data using a browser API that
can create HTML or JavaScript. XSS allows attackers to execute
scripts in the victim’s browser which can hijack user sessions, deface
web sites, or redirect the user to malicious sites.
8. A8:2017- Insecure  Insecure deserialization often leads to remote code execution. Even if
Deserialization deserialization flaws do not result in remote code execution, they can
be used to perform attacks, including replay attacks, injection attacks,
and privilege escalation attacks.
9. A9:2017-Using  Components, such as libraries, frameworks, and other software

Components with modules, run with the same privileges as the application. If a
Known Vulnerabilities vulnerable component is exploited, such an attack can facilitate serious
data loss or server takeover. Applications and APIs using components
with known vulnerabilities may undermine application defenses and
enable various attacks and impacts.
10 . A10:2017- Insufficient  Insufficient logging and monitoring, coupled with missing or ineffective
Logging & Monitoring integration with incident response, allows attackers to further attack
systems, maintain persistence, pivot to more systems, and tamper,
extract, or destroy data. Most breach studies show time to detect a
breach is over 200 days, typically detected by external parties rather
than internal processes or monitoring.
The various attack vectors, security weaknesses, their impact, description of when a web application is
vulnerable to the above given risks, and a guideline on how these risks can be prevented along with example
attack scenarios can be obtained by all organizations from www.owasp.org.
Some of the most dangerous errors that are the commonly reported security vulnerabilities, as described by
SANS, are given below. Apart from OWASP, all organizations should cater to these.
Table 23. SANS top 25
S.No. ID and Name
1. CWE-89: Improper Neutralization of Special Elements Used in an SQL Command ('SQL Injection')
2. CWE-78: Improper Neutralization of Special Elements Used in an OS Command ('OS Command

Injection')
3. CWE-120: Buffer Copy Without Checking Size of Input ('Classic Buffer Overflow')
4. CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-Site Scripting')
5. CWE-306: Missing Authentication for Critical Function
6. CWE-862: Missing Authorization
7. CWE-798: Use of Hard-Coded Credentials
8. CWE-311: Missing Encryption of Sensitive Data
S.No. ID and Name
9. CWE-434: Unrestricted Upload of File with Dangerous Type
10 . CWE-807: Reliance on Untrusted Inputs in a Security Decision
11 . CWE-250: Execution with Unnecessary Privileges
12 . CWE-352: Cross-Site Request Forgery (CSRF)
13 . CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
14 . CWE-494: Download of Code Without Integrity Check
15 . CWE-863: Incorrect Authorization
16 . CWE-829: Inclusion of Functionality from Untrusted Control Sphere
17 . CWE-732: Incorrect Permission Assignment for Critical Resource
18 . CWE-676: Use of Potentially Dangerous Function
19 . CWE-327: Use of a Broken or Risky Cryptographic Algorithm
20 . CWE-131: Incorrect Calculation of Buffer Size
21 . CWE-307: Improper Restriction of Excessive Authentication Attempts
22 . CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
23 . CWE-134: Uncontrolled Format String
24 . CWE-190: Integer Overflow or Wraparound
25 . CWE-759: Use of a One-Way Hash Without a Salt
10. Annexure 3: Cloud
Security
95 Nepal GEA 2.0 Security Architecture | Annexure 3: Cloud Security

10. Cloud Security
Cloud computing is defined as a model for enabling ubiquitous, convenient, on-demand network access to a
shared pool of configurable computing resources (e.g. networks, servers, storage, applications and services)
that can be rapidly provisioned and released with minimal management effort or service provider interaction.
10.1. Before Cloud Migration

Data Sovereignty
Depending on the service model adopted and cloud service provider, organizations may not know the exact
location that data resides in. This may result in conflicts between domestic or international legal and regulatory
requirements. Organizations should identify a cloud service provider, which data center locations ensure that all
applicable data sovereignty law are adhered to.
Avoid Vendor Lock-in

When planning for the implementation strategy of a cloud-based solution, organizations should also consider
scenarios for which there may be a transition to alternate cloud service providers or bring the cloud services
back on-premises. An exit plan should be developed including the potential costs and data/ information
deletion.
10.2. Infrastructure as a Service (IaaS)

In IaaS, organizations provision processing, storage, networks and other fundamental computing resources,
where arbitrary software (e.g. operating systems and applications) can be deployed and run. In this case,
organizations do not have control over the underlying cloud infrastructure, but have control over operating
systems, storage, and deployed applications, and possibly limited control of select networking components
(e.g., host firewalls).
10.2.1. Access Control

A single, Identity and Access Management (IdAM) should be used consistently to allow account management
to be performed from one single location, regardless where the account was created. Role Based Access
Control (RBAC) should be in place, and individuals should only have access to the resources they are
authorized to use or administer. The least privilege and separation of duties principles should be adhered to
wherever possible. The business owner of the application should approve all administrative access requests. In
addition, active logging and monitoring of suspicious activities should be enabled.
IdAM
IdAM should be used for federated authentication via SAML 2.0. Exception should be requested through the
IdAM service for instances where account attributes are required to be synchronized with the provider. In all
cases, the IdAM must provide the authentication. Where technically feasible, organizations should own the
entire authentication and authorization life cycle, including account management.
Built-in functionality for identity and access management in cloud services will be leveraged for in-cloud
authorisation. However, no user entities of the organizations will be created nor maintained in the cloud
provider's IAM service. User entities including userIDs, groups, service accounts and roles may be
synchronised to the provider's IAM from organization’s existing active directory. All authentication to cloud
services for both normal and privileged users will use the IdAM.
Privileged access

 All privileged access to cloud resources must use active directory roles mapped from organization’s active
directory.
 No individuals should be added inside the cloud to resources.
 Multi-Factor Authentication (MFA) should be used by cloud operations teams for privileged administrator
access to the public cloud management console.
 Access to the IaaS instances in cloud as a contributor will be by means of remote console access (RDP) or
SSH from organization’s internal network via a jump-host that resides within the data centre.
10.2.2. Edge Protection

Firewall and third party access
 Edge devices that manages and logs all ingress traffic into and all egress traffic out of the Cloud
Environment should be controlled and managed.
 All unused ports and protocols should be blocked both inbound and outbound. More specifically, the traffic
that is allowed should be explicitly authorized and monitored in the firewall ruleset with the final clean-up
rule that drops all traffic that is not allowed by the earlier rules.
 A next-generation firewall may be utilized as a deep-packet inspection firewall e.g. including application-
level inspection and intrusion prevention.
Public IP addresses
 Removal of public IP addresses will control external access for a Virtual Machine (VM). The IaaS VMs
should have all endpoints removed when provisioning in VC.
 No public IP address should be allowed on any frontend or backend Network Interface Cards (NICs).
 Public IP addresses can be either dynamic or reserved. Since a public IP address is required to connect to
Cloud services, access to VMs should be restricted using endpoint access lists and edge firewall for
approved external facing services.
Load Balancing
 Load balancing capabilities performed by Cloud Service Providers can be used for public-facing
applications to accept connections into the cloud environment and to provide scalability to the ingress/
egress virtual firewalls.
 Internal load balancers can be used between virtual machines that are on internal virtual networks or cloud
service, and should not be used to load balance traffic from the internet to internal endpoints.
10.2.3. Encryption
One of the keys to data protection in the cloud is accounting for the possible states in which the data may
occur, and what controls are available for that state. For the purpose of data security and encryption, GEA’s
recommendations will be around the following data’s states:
Data at-rest
 This includes all information storage objects (e.g. Files), disk or volume and databases (e.g. SQL server).
Encryption can happen on the storage level, disk/ volume level and database level. However, encryption
should take place at the highest level as possible. It should be ensured that the data object and its content
is always stored encrypted.
Data in-transit
 When data is being transferred between components, locations or programs, such as over the network,
across a service bus, or during an input/output process, it is thought of as being in-motion.

 Data should be kept private when it moves from one location to another and encrypted data transfer must
be used for all communication. Data moving from one Tier to the other and within the Tier itself should be
also encrypted.
 Encryption keys used for encryption in the cloud can either be managed by individual organizations through
BYOK (bring your own key) or managed by the cloud vendor. The option of managing the keys in-house
should be considered for highly confidential data.
 Leading industry standards for encryption, for example AES 256, RSA 2048, should be used.
10.2.4. Application Segmentation

IaaS infrastructure in cloud needs to be segmented in different function-tiers like in an on-premise datacentre,
and the communication between Tiers should be allowed for necessary communications only. External network
connections must terminate in a secure isolated segment to prevent direct access to internal networks. For
application segmentation, only needed ports and service across in/ out and internal cloud infrastructure traffic
movement should be allowed.
10.2.5. Logging and Monitoring

Logging and monitoring of security events is critical to detect malicious activities relating to the cloud
application and its data. For security incident detection and response all security, access, and application
related logs should be collected and sent back to the security monitoring solution:
 Any logs that the vendors provide around administrative access

 Server logs
 Security stack logs
10.2.6. Server Security Stack

All virtual machines in the cloud need to be protected like on-premise servers in datacenters:
 Hardened OS following hardening standards

 Anti-Virus/ Malware
 Advanced malware protection
 Critical servers such as active directory should be hardened and isolated
 Vulnerability Management
10.2.7. Vulnerability Management and Secure SDLC

With the Secure SDLC process, security assurance activities such as penetration testing, code review, and
architecture analysis becomes an integral part of the development effort. With Vulnerability Management, it is
verified that no missing OS and third party patches, end-of-life products and unnecessary services / ports /
protocols are configured.
For internally developed applications, the development process should incorporate the use of secure source
code analysis. All applications migrated to the cloud will follow an application security assessment cycle.
10.2.8. Container Security

Just as traditional applications are vulnerable to attackers, containers can be breached too. Due to the nature
of immutable containers, vulnerabilities found in those containers are not simple to fix or patch to the latest
software.

The most effective and proactive way to control the security risk associated with vulnerabilities in containers is
by finding and removing vulnerabilities in base image and redeploy as new containers entirely. Containers
should be monitored continuously because new security vulnerabilities are being discovered every day.
Organizations should use a container orchestration tool to introduce the containers securely. If possible, group
container based on their security and purpose to make it harder in case of a compromise to compromise other
groups. Smart grouping makes the breach easier to detect and contain.
10.3. Platform as a Service (PaaS)

In PaaS, organizations deploy onto the cloud infrastructure consumer-created or acquired applications created
using programming languages, libraries, services, and tools supported by the provider. Organizations do not
manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage,
but have control over the deployed applications and possibly configuration settings for the application-hosting
environment.

Where technically feasible, organizations should own the entire authentication and authorization lifecycle,
including service account management.
 IdAM should be used, except for instances where account attributes need to be synchronized with the
provider. In all cases, the IdAM should be the authentication resource.
 Multi-Factor Authentication should be used for Cloud Administration.
 Role Based Access Control should be in place following the “least privileged” or “need to know” model,
where individuals only have access to the resources they are authorized to use.
 PaaS services should use service accounts that are tied to a specific set of services per each application.
API keys need to be encrypted within the application itself and securely stored and managed outside of the
application.
10.3.2. Application Isolation

The PaaS Application should be isolated. Communications to/from other PaaS VMs should be restricted by the
firewall rules to the necessary communications only. External network connections must terminate in a secure
isolated segment prevent direct access to internal networks.
10.3.3. Encryption
Encryption in transit and encryption at rest need to be utilized. All data moving from or to the Cloud Application
should be encrypted in transit via TLS or VPN. Data transfer between the PaaS Applications needs to be
encrypted by utilizing TLS version 1.2 and higher. All data at-rest must be stored in a strong encrypted format.
If possible, organizations should have full control and ownership over encryption keys e.g. create, rotate, and
revoke.
10.3.4. Vulnerability Management and Secure SDLC

With the Secure SDLC process, security assurance activities such as penetration testing, code review, and
architecture analysis becomes an integral part of the development effort. With Vulnerability Management, it is
verified that no missing OS and third party patches, end-of-life products and unnecessary services / ports /
protocols are configured.
For internally developed applications, the development process should incorporate the use of secure source
code analysis. All applications migrated to the cloud will follow an application security assessment cycle.

Detailed logging from PaaS services should be utilized when the capability exists, and the logs should be sent
to the Security Monitoring solution.
10.4. Software as a Service (SaaS)

In SaaS, organizations utilize the cloud service provider’s applications running on the cloud infrastructure.
Organizations do not have control on the underlying cloud infrastructure, which includes servers, operating
systems and individual application capabilities. However, organizations may be able to manage a limited set of
application configuration settings.

Where technically feasible, organizations should own the entire authentication and authorization life cycle,
including account management.
IdAM should be used for federated authentication via SAML 2.0, except for instances where account attributes
need to be synchronized with the provider. In all cases, the IdAM should still be the authentication resource.
Multi-Factor Authentication should be used for Cloud Administration. Role Based Access Controls (RBAC)
should be in place following the “least privileged” or “need to know” model, where individuals only have access
to the resources they are authorized to use.
10.4.2. Encryption
Encryption in transit and encryption at rest need to be utilized for SaaS services. All data moving from or to the
cloud Application should be encrypted in transit via TLS or VPN. Data transfer between the SaaS Applications
needs to be encrypted by utilizing TLS version 1.2 and higher. The SaaS provider must store the organization’s
data in an encrypted format or in a manner to which it cannot be assembled if extracted from their cloud service
provider’s environment.
If possible, organizations should have full control and ownership over encryption keys (e.g. create, rotate, and
revoke).

Detailed logging from SaaS services should be utilized when the capability exist, and the logs should be sent to
the security monitoring solution.
10.5. Guidelines for Cloud Security

OWASP’s list of top 10 security risks in cloud environment are given below. While implementing a cloud
environment and performing security testing, these risks should be taken into consideration by organizations.
Table 24. OWASP top 10 for cloud security
1. Accountability and  A traditional data center of an organization is under complete control of

data ownership that organization. The organization logically and physically protects the
data it owns. An organization that chooses to use a public cloud for
hosting its business service loses control of its data. This poses critical
security risks that the organization should carefully consider and
mitigate. The guarantee of recovering data must be ensured.

2. User identity  It is very important for the organizations to keep control over user
federation identities as they move services and applications to the different cloud
providers. Rather than letting cloud providers create multiple islands of
identities that become too complex to manage down the line, users
should be uniquely identifiable with a federated authentication (e.g.
SAML) that works across the cloud providers. User experience is
enhanced when he/she does not manage multiple user ids and
credentials. This allows easier back-end data integrations between
cloud provides.
3. Regulatory  In cloud-based solution, data is stored at a random place. In most of

compliance the cases, customers are not even aware where they are hosted. As
different countries following different regulatory rules, the data that is
supposed to be protected in one country is not supposed to be
protected in another country.
4. Business continuity  Business Continuity is an activity an IT organization performs to ensure

and resiliency that the business can be conducted in a disaster situation. In case of
an organization that uses cloud, the responsibility of business
continuity gets delegated to the cloud provider. This creates a risk to
the organization of not having appropriate business continuity. About
service continuity and quality of service, one have to ensure about the
contractual solutions proposed by the operator of cloud, and the
service level agreements as well.
5. User privacy and  User's personal data gets stored in the cloud as users start using social
secondary usage of web sites. Most of the social sites are vague about how they will handle
data users personal data. Additionally most of the social sites go with the
default share all (least restrictive) setup for the user. Organizations
need to ensure with cloud providers what data can or cannot be used
by them for secondary purposes. It includes data that can be mined
directly from user data by providers or indirectly based on user
behaviour (clicks, incoming outgoing URLs etc.).
6. Service and data  The security of data in transit should be a great concern to every
integration organization. In the cloud computing solution, the data are transmitted
between the end user and cloud data center. While utilizing cloud, the
transmission is carried over the internet, where there is an increase in
risk for the organization. Unsecured data is susceptible to interception
and compromise during transmission.
7. Multi tenancy and  Multi-tenancy in cloud means sharing of resources and services among
physical security multiple clients(CPU, networking, storage/databases, application
stack). It increases dependence on logical segregation and other
controls to ensure that one tenant deliberately or inadvertently can not
interfere with the security of the other tenants. In addition, there is the
possibility of misconfiguration, uncoordinated change controls, and
single point of failure.
8. Incident analysis and  In the event of a security incident, applications and services hosted at a
forensic support cloud provider are difficult to investigate as logging may be distributed
across multiple hosts and data centers, which could be located in
various countries and hence governed by different laws. In addition,
the multiple customers are storing the data in same shared hardware

and data center, issues in law enforcement will arise during forensic
recovery.
9. Infrastructure security  All infrastructure should be hardened and configured securely, and the
hardening/ configuration baselines should be based on industry best
practices. Applications, systems and networks should be architected
and configured with security zones, and access should be configured
to only allow required network and application protocols. Administrative
access should be role-based, and granted on a need-to-know basis.
 Failure to keep the system and network device up-to-date might
compromise the system security. Running of services that include
security-related bugs will enhance the possibility of infrastructure
becoming a target for the security exploit. In addition, configuration
mistakes and coding errors also enhance the exploitability chances.
10 . Non-production  Organizations generally use non-production environment internally to

environment design, develop and test their software or application. This environment
exposure is not so much secure as like the production environment. In the non-
cloud environment, the organization includes complete control over the
non-production environment, hence there is a minimum risk in security
when compared to a cloud-based solution where the non-production
environment is beyond the control of the organization.
 In cloud computing, there is a risk of malicious user accessibility in the
non-production environment. This environment often includes generic
authentication credentials which may not be align with the standard
password policy of the organization and hence makes it effortless to
achieve unauthorized access. With unauthorized access, attacker can
make the environment useless or they can even delete it entirely.

11. Annexure 4: IoT Security
103 Nepal GEA 2.0 Security Architecture | Annexure 4: IoT Security

11. IoT Security
Device defined as all computing devices, mechanical and digital machines that are provided with unique
identifiers and the ability to transfer data over a network without requiring any human interaction. Trusted
Platform Modules defined as a root of trust by protecting sensitive information and credentials (i.e., not
releasing encryption keys outside the chip). These modules are designed to prevent tampering. Connectivity
networks defined as mediums over which the data is securely transmitted/ received.
11.1. IoT Secure Design and Threat Modelling

The objective of threat modelling is to understand how an attacker might be able to compromise a system and
then make sure appropriate mitigations are in place. Threat modelling forces the design team to consider
mitigations as the system is designed rather than after a system is deployed. This fact is critically important
because implementing additional security measures to a myriad of devices in the field is infeasible, error-prone,
more costly and leaves organizations at risk.
When to perform Threat Modelling

Threat modelling should be incorporated at the design stage of the IoT solution development. Eliminating
threats by secure design is the desired outcome.
What to include in Threat Modelling

Threat model the solution as a whole and focus in the following areas:
 The security and privacy features

 The features whose failures are security relevant
 The features that touch a trust boundary
Features
 Processes such as web services, Win32 services.

 Data stores (anywhere data is stored, such as a configuration file or database)
 Data flow (where data moves between other elements in the application)
 External Entities (anything that interacts with the system, but is not under the control of the solution,
examples include users and satellite feeds)
Who will perform Threat Modelling

Threat modelling is usually performed by development teams with input from IT security team to understand
what an attacker might do and why.
How to perform Threat Modelling

The threat modelling process is composed of four steps:
 Model the solution

 Enumerate threats
 Mitigate threats
 Validate the mitigations

In order to optimize security best practices, it is recommended that a typical IoT architecture is divided into
several component/ zones as part of the threat modelling exercise. These zones are described fully throughout
this section and include:
 Device
 Field Gateway
 Cloud gateways
 Services
Zones are broad way to segment a solution; each zone often has its own data and authentication and
authorization requirements. Zones can also be used to isolation damage and restrict the impact of low trust
zones on higher trust zones.
Each zone is separated by a Trust Boundary, which is noted as the dotted line in the following diagram. It
represents a transition of data/ information from one source to another. During this transition, the data/
information could be subject to threats of the following nature: Spoofing, Tampering, Repudiation, Information
Disclosure, Denial of Service and Elevation of Privilege (STRIDE).
The zones depicted within each boundary are also subjected to STRIDE. The following sections elaborate on
each of the components and specific security concerns and solutions that should be put into place.
The Device Zone

The device environment is the immediate physical space around the device where physical access and/ or
“local network” peer-to-peer digital access to the device is feasible. A “local network” is assumed to be a
network that is distinct and insulated from – but potentially bridged to – the public Internet, and includes any
short-range wireless radio technology that permits peer-to-peer communication of devices. It does not include
any network virtualization technology creating the illusion of such a local network and it does also not include
public operator networks that require any two devices to communicate across public network space if they were
to enter a peer-to-peer communication relationship.
The Field Gateway Zone

Field gateway is a device/ appliance or some general-purpose server computer software that acts as
communication enabler and, potentially, as a device control system and device data processing hub. The field
gateway zone includes the field gateway itself and all devices that are attached to it. As the name implies, field
gateways act outside dedicated data processing facilities, are usually location bound, are potentially subject to
physical intrusion, and has limited operational redundancy. All to say that a field gateway is commonly a thing
one can touch and sabotage while knowing what its function is.
A field gateway is different from a mere traffic router in that it has had an active role in managing access and
information flow, meaning it is an application addressed entity and network connection or session terminal. A
NAT device or firewall, in contrast, does not qualify as field gateways since they are not explicit connection or
session terminals, but rather a route (or block) connections or sessions made through them. The field gateway

has two distinct surface areas. One faces the devices that are attached to it and represents the inside of the
zone, and the other faces all external parties and is the edge of the zone.
The Cloud Gateway Zone

Cloud gateway is a system that enables remote communication from and to devices or field gateways from
several different sites across public network space, typically towards a cloud-based control and data analysis
system, a federation of such systems. In some cases, a cloud gateway may immediately facilitate access to
special-purpose devices from terminals such as tablets or phones. In the context discussed here, “cloud” is
meant to refer to a dedicated data processing system that is not bound to the same site as the attached
devices or field gateways. Also in a Cloud Zone, operational measures prevent targeted physical access and
are not necessarily exposed to a “public cloud” infrastructure.
A cloud gateway may potentially be mapped into a network virtualization overlay to insulate the cloud gateway
and all of its attached devices or field gateways from any other network traffic. The cloud gateway itself is not a
device control system or a processing or storage facility for device data; those facilities interface with the cloud
gateway. The cloud gateway zone includes the cloud gateway itself along with all field gateways and devices
directly or indirectly attached to it. The edge of the zone is a distinct surface area where all external parties
communicate through.
The Services Zone

A “service” is defined for this context as any software component or module that is interfacing with devices
through a field or cloud gateway for data collection and analysis, as well as for command and control. Services
are mediators. They act under their identity towards gateways and other subsystems, store and analyse data,
autonomously issue commands to devices based on data insights or schedules and expose information and
control capabilities to authorized end users.
11.2. IoT Security Layers

The following sections discuss standard security measures typically implemented in these zones.
11.2.1. Protecting Devices

All devices in the IoT solution should run only authorised code on trusted platforms. This is implemented via the
following:
 Code signing
Code signing cryptographically ensures that code has not tampered after they have not been signed at the
software and firmware level. Examples of such implementations are Trusted Platform Module (TPM) that
performs the cryptographic signing and protects the signing keys.
 Runtime protection
Runtime protection ensures code is not overwritten by malicious code after it is loaded. Examples of such
implementation are secure booting to ensure only verified software will run on the device.
 Physical security protection
Physical security protection ensures that physical tampering is prevented when physical access is gained
to the device by an intruder. Examples of such implementation are full metal shield covering/ casing for all
internal circuitry.
 Host-based protection
Host-based protection ensures that code is protected after code begins running. Examples of such
implementations are hardening, lockdown, whitelisting, sandboxing, network-facing intrusion prevention,
behavioural and reputation-based security, including blocking, logging, and alerting, some of which has
been adapted for IoT security.

11.2.2. Protecting Communications
All devices in the IoT solution should only communicate via a secure manner. This is implemented via the
following:
 Encryption and authentication

Encryption and authentication ensure that data in transit and at rest is securely protected with trusted
parties. Constraints on conventional IT security measures should be taken into consideration when
applying to sensitive data in transit over the connectivity networks of the IoT solution. Examples of such
implementation include the use of digital certificates, signatures, customised implementations of
cryptographic algorithms intended for lightweight yet secure use (e.g. elliptic curve cryptography, encrypt
then MAC approach).
 Network-based protection
Network-based protection designed to examine specific traffic flows (e.g., non-IT protocols) terminating at
the device, are also increasingly being used to detect unwanted intrusions and prevent malicious activities
on the communication layer. Examples of such implementations are firewalls and intrusion prevention
systems.
 Cloud-based protection
Cloud-based protection ensures that data from devices that are ingested, analysed and interpreted is
protected from data breaches and downtime. Sensitive information stored in the cloud must be encrypted
and third-party applications that communicate to the IoT solution’s cloud services must be authenticated.
Examples of such implementation are digital certificates, reputation-based services and cloud access
security brokers (CASB).
11.2.3. Managing Devices

All devices in the IoT solution should be securely managed throughout their lifecycle. This is implemented via
the following:
 Over-the-Air (OTA) manageability

OTA provides a way for devices in the IoT solution to receive instructions, patches and updates in a secure
manner. For example, 4G can be used as a medium to transmit and receive information from devices in the
field.
 Active monitoring and analytics
Active monitoring and analytics provide for anomalies detection through big data security analytics
infrastructure and threat intelligence feeds. The IoT solution would be baselined and monitored for
deviations. For example, device security logs are examined by SIEM to detect suspicious activities.
11.3. Guidelines for IoT Security

In consideration of the growing use of IoT because of its various benefits ranging from fitness trackers and the
products that control door locks, appliances, and energy use in homes to the systems that deliver water and
power to buildings, OWASP foundation has released top 10 cyber security issues found in IoT environment.
Organizations should keep these issues in consideration while implementing such environments and
conducting security testing.

Table 25. OWASP top 10 for IoT security
1. Weak, Guessable, or  Use of easily brute-forced, publicly available, or unchangeable

Hardcoded credentials, including backdoors in firmware or client software that
Passwords grants unauthorized access to deployed systems.
2. Insecure Network  Unneeded or insecure network services running on the device itself,
Services especially those exposed to the internet, that compromise the
confidentiality, integrity/ authenticity, or availability of information or
allow unauthorized remote control.
3. Insecure Ecosystem  Insecure web, backend API, cloud, or mobile interfaces in the
Interfaces ecosystem outside of the device that allows compromise of the device
or its related components. Common issues include a lack of
authentication/ authorization, lacking or weak encryption, and a lack of
input and output filtering.
4. Lack of Secure  Lack of ability to securely update the device. This includes lack of
Update Mechanism firmware validation on device, lack of secure delivery (unencrypted in
transit), lack of anti-rollback mechanisms, and lack of notifications of
security changes due to updates.
5. Use of Insecure or  Use of deprecated or insecure software components/ libraries that

Outdated could allow the device to be compromised. This includes insecure
Components customization of operating system platforms, and the use of third-party
software or hardware components from a compromised supply chain.
6. Insufficient Privacy  User’s personal information stored on the device or in the ecosystem
Protection that is used insecurely, improperly, or without permission.
7. Insecure Data  Lack of encryption or access control of sensitive data anywhere within
Transfer and Storage the ecosystem, including at rest, in transit, or during processing.
8. Lack of Device  Lack of security support on devices deployed in production, including

Management asset management, update management, secure decommissioning,
systems monitoring, and response capabilities.
9. Insecure Default  Devices or systems shipped with insecure default settings or lack the
Settings ability to make the system more secure by restricting operators from
modifying configurations.
10 . Lack of Physical  Lack of physical hardening measures, allowing potential attackers to

Hardening gain sensitive information that can help in a future remote attack or
take local control of the device.

12. Annexure 5: Data
Classification
109 Nepal GEA 2.0 Security Architecture | Annexure 5: Data Classification

12. Data Classification
The Data Classification Framework establishes a scheme to classify data into the categories (Confidential,
Internal and Public), and defines physical and electronic security controls for each classification.
All of organization’s data, including information entrusted to the organization from third parties falls into either of
the classifications listed below, presented in order of decreasing sensitivity.
Confidential
Confidential data is categorized as regulated or controlled data that has legal ramifications if disclosed either
internally or externally, or data that if improperly disclosed or accessed without authorization, will cause grave
damage to the organization’s competitive advantage, its business partners, and/or the privacy or financial
viability of its customers or associates. This category of data is extremely sensitive in nature and may not be
shared except when deemed absolutely necessary for continuation of business.
Examples of confidential data include:
 Individually identifiable customer or client information/ data

 Payment card or credit card numbers
 Individually identifiable sensitive personnel information (e.g. employee data)
 Organization’s business strategies and forecasts
 Financial results prior to release
 Files containing clear-text passwords, digital certificate, private keys, PINs, or any form of cryptographic
keys
 Suspicious activity reporting – Reports related to money laundering, terrorist financing and other illegal or
suspicious activity
 Technical or Security Information, which if exposed could lead to breach
 Source code
Internal
Internal data is categorized as sensitive business data concerning the organization, organization’s external
business partners and/or customers. All of organization’s associates may be provided access to this level of
data. A non-disclosure agreement is required before access to this level of data is granted to third-party
individuals. At a minimum, external parties who receive the organization’s internal data are required to strictly
comply with the handling requirements.
Examples of Internal data include:
 Training material
 Company policy and organization chart
 Employee work phone and email address
 Market Research
Public
This type of data does not require special handling, marking or storage. However, only authorized associates
should make public data known to the general public (e.g. public relations). There are no restrictions on who
may read public data.

Examples of Public data include:
 Product and service brochures (only after public launch)

 Advertisements
 Job opening announcements
 Press releases
 Financials, Accounting releases as required by regulatory authorities (only after publication to the general
public)

13. Annexure 6: API Security
112 Nepal GEA 2.0 Security Architecture | Annexure 6: API Security

13. API Security
Given the foundational role that APIs play in organization’s infrastructure, keeping APIs secure is critical. Given
below are some of the best practices that organizations should follow to ensure API security.
1. API authentication  API authentication is important to protect against various cyber attacks.
Typically, the username and password are not passed in day-to-day
API calls. Rather, an API key or bearer authentication token is passed
in the HTTP header or in the JSON body of a RESTful API. Tokens
should expire regularly to protect against replay attacks.
 By using client certificates and certificate pinning in organizational
applications, man-in-the middle attacks can be prevented and it can be
ensured that only authorised applications can access the API.
2. API authorization  Access should be restricted to only what is required and who needs it.
3. API encryption  API data should be protected from unauthorized access via encryption.
Depending on the specific API protocol, one of the following methods
for API encryption can be used:
o HTTPs should be implemented to protect the request in transit,
so that the messages are secured and encoded with TLS.
o JSON WEB TOKEN: For JSON response data, JSON Web
Token (JWT) is an open standard that defines ways to securely
transmit information as a JSON object between parties. JWTs
can be signed using a secret (with the HMAC algorithm) or a
public/ private key pair using RSA.
4. Application layer  Attacks against API endpoints are one common means of
security compromising applications via APIs. Some of the common attacks
include:
o Cross-site scripting – Malicious scripts are injected into one of
the request parameters.
o Code injection – Inject valid code to services, such as SQL
(SQL injection) or XQuery, to open the interface to user control
o Business logic – Allows the attacker to circumvent the
business rules
o Parameter pollution attacks – Exploit the data sent in the API
request by modifying the parameters of the API request.
5. Whitelisting  Whitelisting is a powerful approach for restricting access to resources

by default, and opening access only to specific trusted users.
 In the context of API, organization’s internal APIs should restrict API
traffic at the IP address level, and there should be a known list of
devices, servers, networks, and client IP addresses that are accepted.

6. API logging  API transactions should always be logged. Logs can help resolve
security issues, as well as monitor activity and discover any patterns or
excessive usage that could signal an intrusion or intrusion attempt.
 When configuring API logs, it is a good practice to return simple error
objects with the conventional HTTP status code, and to keep required
error messages to a minimum. This will improve error handling and
protect API implementation details from an attacker.
7. Throttling and rate  When protecting APIs against abuse or DDoS attacks, it is necessary
limiting to have rules that restrict usage once certain criteria are met. This
would include requests per time unit, bandwidth limits, or monthly
quotas.
 Rate limiting is important if API is public-facing. It will help protect the
API and back-end from DOS.
8. Blocking large  Some attackers may try to overwhelm the API or trigger a buffer
requests and overflow vulnerability with large requests. These may be in the form of
responses a large JSON body or even unusually large individual JSON
parameters within the request. Also, an abnormally large response may
be and indicator of data theft.
9. Input validation  Organizations should apply strict user input validation, including:
o Restricting, where possible, parameter values to a whitelist of
expected values
o Facilitating a whitelist (have strong typing of input value)
o Validating posted structures data against a formal schema
language to restrict the content and structure.
 SQL Injection attacks on standard web applications are common,
though these and other input abuse attacks can be carried out against
APIs as well. For example, SQL, PHP, xpath/ xquery, LDAP DN/ LDAP
Query, BASH Script, JavaScript or other code can be entered into a
JSON parameter within an API request body.
10 . Geo-fencing  In case of a public API, users from irrelevant countries should be

blocked.

www.pwc.in
All images in this presentation are protected by copyright, trademark, patent, trade secret and other intellectual
property laws and treaties. Any unauthorised use of these images may violate such laws and shall be punishable
under appropriate laws. Our sharing of this presentation along with such protected images with you does not
authorise you to copy, republish, frame, link to, download, transmit, modify, adapt, create derivative works based
on, rent, lease, loan, sell, assign, distribute, display, perform, license, sub-license or reverse engineer the images.
In addition, you should desist from employing any data mining, robots or similar data and/or image gathering and
extraction methods in connection with the presentation.
© 2019 PricewaterhouseCoopers Private Limited. All rights reserved. In this document, “PwC” refers to
PricewaterhouseCoopers Private Limited (a limited liability company in India having Corporate Identity Number or
CIN : U74140WB1983PTC036093), which is a member firm of PricewaterhouseCoopers International Limited
(PwCIL), each member firm of which is a separate legal entity.
[August]/Month Year-17205

Nepal GEA 2 - 0 Security Architecture

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nepal GEA 2 - 0 Security Architecture

Uploaded by

Copyright:

Available Formats

Nepal GEA 2.

1. Executive Summary ................................................................................................................. 13

1.1. Purpose of this Document ................................................................................................ 14

1.2. Audience of this Document .............................................................................................. 14

1.3. Need of Security Architecture .......................................................................................... 14

1.3.1. Impact on Businesses ........................................................................................... 15

1.3.2. Recent Cyber Breaches ........................................................................................ 15

1.4. Design Principles and Content of the Security Architecture ............................................ 19

2. Global Trends on Cyber Security ............................................................................................. 20

3. Security Architecture Components .......................................................................................... 25

3.1. Introduction ....................................................................................................................... 26

3.2. Architecture Design and Components ............................................................................. 26

3.2.1. Preliminary Phase ................................................................................................. 27

3.2.2. Architecture Vision ................................................................................................ 28

3.2.3. Business Architecture ........................................................................................... 29

3.2.4. Information Systems Architecture ......................................................................... 30

3.2.5. Technology Architecture ....................................................................................... 32

3.2.6. Opportunities and Solutions .................................................................................. 32

3.2.7. Migration Planning ................................................................................................ 33

3.2.8. Implementation Governance ................................................................................. 34

3.2.9. Architecture Change Management ....................................................................... 34

3.2.10. Requirements Management ................................................................................. 35

4. Organizational Context and Security Objectives ..................................................................... 36

4.1. Organization Structure ..................................................................................................... 37

4.2. Roles and Responsibilities ............................................................................................... 38

4.2.1. Responsibilities of Central Government ............................................................... 38

4.2.2. Chief Information Officer (CIO) ............................................................................. 38

4.2.3. Chief Information Security Officer (CISO)............................................................. 39

2 Nepal GEA 2.0 Security Architecture | Table of Contents

4.2.5. Information Security Team .................................................................................... 40

4.2.6. Business Owners .................................................................................................. 41

4.2.7. Business Users ..................................................................................................... 42

4.2.8. Data Owners ......................................................................................................... 42

4.2.9. Internal Audit Team............................................................................................... 42

4.2.10. Functional Teams ................................................................................................. 42

5. Leadership Commitment and Support for Security .................................................................. 44

5.1. Leadership Commitment .................................................................................................. 45

5.2. Governance Imperatives .................................................................................................. 45

5.2.1. Management Review ............................................................................................ 46

5.3. Security Resourcing ......................................................................................................... 46

5.3.1. Human Resources ................................................................................................ 47

5.3.2. Tools and Technologies ........................................................................................ 47

6. Information Security Risk Management ................................................................................... 59

6.1. Risk Management Framework ......................................................................................... 60

6.2. Addressing People and Policy Related Risks .................................................................. 61

6.2.1. Security Policy ...................................................................................................... 61

6.2.2. Awareness and Training ....................................................................................... 62

6.3. Addressing Process Related Risks .................................................................................. 63

6.4. Addressing Technology Related Risks ............................................................................ 72

7. Continual Security Assurance .................................................................................................. 75

7.1. Security Assessment ........................................................................................................ 76

7.1.1. Review Techniques............................................................................................... 77

7.1.3. Vulnerability validation .......................................................................................... 81

7.2. Third Party Auditing .......................................................................................................... 82

7.3. Service Provider Performance Management ................................................................... 83

7.3.1. SLA Measurement and Service Maturity Index .................................................... 84

8. Annexure 1: Vulnerability Management ................................................................................... 87

3 Nepal GEA 2.0 Security Architecture | Table of Contents

10. Annexure 3: Cloud Security ..................................................................................................... 95

10.1. Before Cloud Migration ....................................................................................... 96

10.2. Infrastructure as a Service (IaaS) ....................................................................... 96

10.2.1. Access Control ...................................................................................................... 96

10.2.2. Edge Protection .................................................................................................... 97