nepal gea 2.0 security architecture

Nepal GEA 2.0 Security Architecture Final

September 2019

2 Nepal GEA 2.0 Security Architecture | Table of Contents

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


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

6 Nepal GEA 2.0 Security Architecture | List of Tables

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

7 Nepal GEA 2.0 Security Architecture | List of Figures

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

8 Nepal GEA 2.0 Security Architecture | Document History

Document History

Date Version Author Description

November 2010 Draft PwC India Nepal GEA Security Architecture – Draft version

January 2011 Final PwC India Nepal GEA Security Architecture – Final version

August 2019 Draft PwC India Nepal GEA 2.0 Security Architecture – Draft version

Final PwC India Nepal GEA 2.0 Security Architecture – Final version

9 Nepal GEA 2.0 Security Architecture | Abbreviations

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

STRIDE Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and 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

13 Nepal GEA 2.0 Security Architecture | Executive Summary

1. 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 breached

Data includes SSN, personal data, documents, driving licenses, passwords

Data of residents of multiple countries (US, UK, Canada)

Over 300 million USD of breach expenses in the first year and 300 million USD expected in second year

Offered lifetime free service to customers to control data, 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 stolen by hackers from the country's tax revenue office. (Population of Bulgaria: 7 Million)

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

Global reputational loss

Personal records of over 5 million residents leaked



as five million Bulgarians and foreign residents

3. Yahoo In 2016, Yahoo disclosed two separate breaches involving approximately 1 billion and 500 million users in 2013 and 2014, respectively.

In 2017, Yahoo reportedly increased its estimate of the number of users affected to 3 billion (all of its users at the time of the breach).

The incidents involved a breach of confidentiality of names, email addresses, telephone numbers, dates of birth as well as encrypted or partial information on passwords and security questions and answers

A decline in the acquisition price of the company of 350 million USD

Direct cost to the expenses caused due to breaches

43 consumer class action lawsuits

Reputation damage and criticism for not reporting the incidents earlier

4. Anthem Data of 78.8 million customers leaked

Various types of personal information, including names, birthdays, health care identification/social security numbers, street addresses, email addresses, phone numbers and employment information, including income data

Lawsuits costing over 115 million USD

Attorney fee in over 31 million USD

16 million USD paid to health 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 corporation where 40 million credit card numbers and Personally Identifiable Information (PII) of 70 million customers compromised

Data sold in underground market at a price of $20 – $45 / card

Cost to Target over 200 million USD

90+ lawsuits filed

Profits fell by 50% and share price fell by 11% in the fiscal 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 Aramco

Saudi Aramco, one of the largest company in the world with largest SAP implementation was hit by a

75% of the company systems affected



cyberattack, where 30,000+ workstations were impacted and it took one week to restore the services. The malware succeeded in deleting data from approximately 75% of all of Saudi Aramco's corporate computers.

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.

Many of the business functions such as shipping and contracting shut down

Purchased 50,000 new computers to replace affected systems

7. Iran Stuxnet reportedly ruined almost one fifth of Iran's 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

Ruined almost one fifth of Iran's nuclear centrifuges

8. TCS TCS was fined for Intellectual Property breach for allegedly stealing healthcare software from an American company, Epic Systems.

TCS was fined 940 million USD in 2014 for IPR infringement

TCS paid 440 million USD to Epic Systems as part of penalty

9. Marriott Marriott suffered a massive data breach affecting the records of up to 383 million customer records, 25 million passport numbers, and 8 million payment cards details

Breach came under GDPR and fines included up to 4$ of global turnover

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.

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

2. 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

25 Nepal GEA 2.0 Security Architecture | Security Architecture Components

3. 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

S.No. Requirement for all organizations

Implementation Guidance

1. Identify the scope impacted by this Security Architecture

Identify core enterprise units – Those who are most affected and achieve most value from the security work

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 applicable regulatory and security policy requirements

A written security policy for the organization should be in place, and there should be regular notification and education established for employees. International standards ISO/IEC 27001 and ISO 27002 are good to start the formation of a security policy, and can be used to assess the security readiness of an organization.




3. Define the required security capability

Security considerations can conflict with functional considerations and 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 architecture tools

The approach to security tools may be based on usage of standard 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



1. Obtain management support for security measures

Management endorsement of the security-related aspects of the architecture implementation effort should be obtained.

2. Define necessary security-related management sign-off milestones for this security architecture implementation cycle

The traceability of security-related architecture decisions should be documented.

Appropriate executives and line management who should be informed of security-related aspects of the project should be identified and the frequency of reporting should be established.

3. Determine and document applicable disaster recovery or business continuity plans/ requirements

Any existing disaster recovery and business continuity plans should be understood and their relationship with the planned system defined and documented.

4. Identify and document the anticipated physical/ business/ regulatory environment(s) in which the system(s) will be deployed

All architecture decisions should be made within the context of the environments within which the system will be placed and operated.

Physical environments that should be documented may include commercial environments, outdoor environments, mobile environments, etc. of the organization.

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.




5. Determine and document the criticality of systems: safety-critical/ mission-critical/ non-critical

Safety-critical systems place lives in danger in case of failure or malfunction.

Mission-critical systems place money, market share, or capital at risk in case of failure.

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



1. Determine who are the legitimate actors who will interact with the organizational products/ services/ processes

Development of the business scenarios and subsequent high-level use-cases of the project concerned will bring to attention the people actors and system actors involved.

It should also be borne in mind that users may not be humans; 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 current security-specific business processes (enhancement of existing objective)

The business process regarding how actors are vetted as proper users of the system should be documented.

Consideration should also be made for actors from outside the organization who are proper users of the system.

3. Determine whom/ how much it is acceptable to inconvenience in utilizing security measures

It is understandable that security measures, while important, can impose burden on users and administrative personnel. Some will respond to that burden by finding ways to circumvent the measures. Examples include administrators finding ways to create "back doors". The trade-offs can require balancing security advantages against business advantages and demand informed judicious choice.

4. Identify and document interconnecting systems beyond project control

Every system should rely upon existing systems beyond the control of the project. These systems possess advantages and disadvantages, risks and benefits. Examples include the Domain Name System (DNS) that resolves computer and service names to Internet addresses, or 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 at high risk if

Assets are not always tangible and are not always easy to quantify. Examples: loss of life, loss of market value, loss of customer trust.




something goes wrong

6. Determine the cost (both qualitative and quantitative) of asset loss/ impact in failure cases

Assets most challenging to quantify can be the most valuable and should not be neglected. Examples: organizational reputation

7. Identify and document the ownership of assets

Assets may be owned by outside entities, or by inside entities. Inside entities may be owned by individuals or by organizations.

8. Determine and document appropriate security forensic processes

To be able to enforce security policies, breaches of security should be properly captured so that problem determination and possible policy or legal action can be taken against the entity causing the breach.

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 of the availability and correct operation of the overall service

The risks associated with loss of availability should be identified. Examples: power failure, human error, natural disasters

10. Determine and document how much security (cost) is justified by the threats and the value of the assets at risk

A quantitative risk analysis (an understanding of the value of assets at risk and the likelihood of potential threats) provides an important guideline for security investments in mitigation strategies for the identified threats. It is understood that an asset worth amount “$” should not be protected with security measures worth “2$”.

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



1. Identify and evaluate applicable recognized guidelines and standards

From a security standpoint, standard protocols, standard object libraries, and standard implementations help to ensure that errors do not find their way into implementations. While international standard for security ISO 27001 has been incorporated in this security architecture, the same should be assessed independently as well.

2. Revisit assumptions regarding interconnecting systems beyond project control

In light of the risk assessments performed, assumptions regarding interconnecting systems should be reviewed.




3. Determine and document the sensitivity or classification level of information stored/ created/ used

The absence of any official classification does not necessarily absolve the onus on maintaining the confidentiality of data. Consideration should be made to determine and document the sensitivity and classification of information within the organization.

4. Identify and document custody of assets

All assets of value are kept and maintained on behalf of the owner. The specific persons or organizations charged with this responsibility should be identified.

5. Identify the criticality of the availability and correct operation of each function

Presumably, in the event of system failure or loss of functionality, some value is lost to stakeholders. The cost of this opportunity loss should be quantified, if possible, and documented.

6. Determine the relationship of the system under design with existing business disaster/ continuity plans

Existing business continuity/ disaster recovery plans may accommodate the system under consideration. If not, analysis should be done to determine the gap and the cost if that gap goes unfilled.

7. Identify what aspects of the system should be configurable to reflect changes in policy/ business environment/ access control

Systems should evolve to accommodate change. Systems architected for ready reconfiguration will better reflect that change and result in lower cost over the life of the system.

Security is enhanced when security-related changes can be implemented inexpensively and are, hence, not sidelined.

8. Identify lifespan of information used as defined by business needs and regulatory requirements

Information maintained beyond its useful lifespan represents wasted resources and, potentially, business decisions based upon suboptimal data. Regulation, however, sometimes mandates the timetable for maintenance of information as archival data. In this regard, lifespan of information stored should be identified and documented.

9. Identify actions/ events that warrant logging for later review or triggering forensic processes

Logging will help reconstruct chains of events, facilitate root cause analysis, and, potentially, establish evidence for civil or criminal action.

Logs should be regularly reviewed to identify malicious attacks on a system.

10. Identify and document requirements for rigor in proving accuracy of logged events (non-repudiation)

Since malicious tampering of systems is commonly accompanied by tampering of logged data, the ability to protect and establish the accuracy of logs through cryptographic methods will remove uncertainty from investigations and bolster cases in legal proceedings.


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



1. Assess and baseline current security-specific technologies (enhancement of existing objective)

Baselining of current security specific technologies will help in establishing their target state and enhancement imperatives. The same can be done against international standards ISO 27001 and ISO 22301 for processes, OEM guidelines for security products, and such.

2. Identify methods to regulate consumption of resources

As resources are reaching their end-of-life period, functionality may be impaired or may fail altogether. Steps that may identify such resources and recognize resource depletion period, can enhance the overall reliability and availability of the systems.

3. Engineer a method by which the efficacy of security measures will be measured and communicated on an ongoing basis

As systems are deployed and operated in dynamic environments, security measures will perform to varying degrees of efficacy as unexpected threats arise and as expected threats change in the environment. A method that facilitates ongoing evaluation of the value of security measures will inform ongoing changes to the system in response to changing user needs, threat patterns, and problems found.

4. Identify the trust (clearance) levels

Regulatory requirements, information classification levels, and 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 privileges required for any entity to achieve a technical or business objective

Granting all-encompassing capabilities to any user, application, or other entity can simplify successful transaction completion at a significant cost of complicating effective control and audit.

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



1. Identify existing security services available for re-use

It is an understanding that there will be existing security infrastructure and security building processes that can be applied to the requirements 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.




2. Engineer mitigation measures addressing identified risks

Having determined the risks amenable to mitigation and evaluated the appropriate investment in that mitigation as it relates to the assets at risk, those mitigation measures should be designed, implemented, deployed, and/or operated.

3. Evaluate tested and re-usable security software and security system resources

Since design, code, and configuration errors are the roots of many security vulnerabilities, taking advantage of any problem solutions already engineered, reviewed, tested, and field-proven will reduce security exposure and enhance reliability.

4. Identify new code/ resources/ assets that are appropriate for re-use

Populate the Architecture Repository with new security building blocks.

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



1. Assess the impact of new security measures upon other new components or existing leveraged systems

In a phased implementation, the new security components are usually part of the infrastructure in which the new system is implemented. The security infrastructure needs to be in a first or early phase to properly support the project.

2. Implement assurance methods by which the efficacy of security measures will be measured and communicated on an ongoing basis

During the operational phases, mechanisms are utilized to monitor the performance of many aspects of the system. Its security and availability are no exception.

3. Identify correct secure installation parameters, initial conditions, and configurations

Security of any system depends not on design and implementation alone, but also upon installation and operational state. These conditions should be defined and monitored not just at deployment, but also throughout operation.

4. Implement disaster recovery and business continuity plans or modifications

Plans for business continuity and disaster recovery of operations should be implemented at this stage.


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



1. Establish architecture artifacts, design, and code reviews and define acceptance criteria for the successful implementation of the findings

Many security vulnerabilities originate as design or code errors and the simplest and least expensive method to locate and find such errors is generally an early review by experienced peers in the craft. Locating such errors, of course, is the first step and implementing corrections at an appropriate point in the development lifecycle is necessary to benefit from the investment.

Follow-on inspections or formalized acceptance reviews may be warranted in high-assurance or safety-critical environments.

2. Implement methods and procedures to review evidence produced by the system that reflects operational stability and adherence to security policies

While planning and specification is necessary for all aspects of a successful enterprise, they are insufficient in the absence of testing and audit to ensure adherence to that planning and specification in both deployment and operation. Among the methods to be exercised are:

o Review system configurations with security impact which can 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 to ensure correct deployment, configuration, and operations of security-relevant subsystems and components; ensure awareness training of all users and non-privileged operators of the system and/or its components

Training is not necessary simply to preclude vulnerabilities introduced through operations and configuration error, though this is critical to correct ongoing secure performance.

Proper training should be performed and documented to demonstrate due diligence and substantiate corrective actions or sanctions in cases where exploits or error compromise business objectives or to absolve contributory responsibility for events that bring about harm or injury.

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



1. Determine change imperatives and drivers

Good security forensics practices in conjunction with a written published security policy make determination of what has gone wrong 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-relevant changes to the environment into the requirements for future enhancement

Changes that arise as a result of a security problem or new security technology will feed into the Requirements Management process.

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

36 Nepal GEA 2.0 Security Architecture | Organizational Context and Security Objectives

4. 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 management

Perform network scans

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 architecture

Review security 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.

44 Nepal GEA 2.0 Security Architecture | Leadership Commitment and Support for Security

5. 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 Surface

Human Device Network Application

Description

Employees, third parties, customers and administrators can be tricked by adversaries to or intentionally perform unauthorized activities.

Adversaries may gain unauthorized access to infrastructures such as endpoints and servers where data is stored or services are running.

Every point of network interaction is a potential part of network attack surface.

Running code may have vulnerabilities which adversaries exploit to gain access to the target system.

Possible Threats

Social Engineering

Insider Threats

Malware

Unauthorized Access

Man-in-the-Middle Attack

Malware

DDoS Attack

Attacks against application vulnerabilities

Security Technology to reduce Attack Surfaces

Asset Discovery

Governance, Risk and Compliance

Code Scanning

Database Firewall

Data Discovery

Data Loss Prevention

Threat Intelligence

Security Information and Event Management

Vulnerability Assessment

Web Application Firewall

Remote Access Controls

IDS/IPS

VPN

Firewall

PIM

IAM

Endpoint Management

Configuration Management

Malware Analysis

Digital Forensics

DDoS Protection

Network Access Control

Penetration Testing

EDR

Network ATP Email Security

BYOD

Fraud Detection

HSM

Encryption

Tokenization


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 Requirements

Endpoint

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


Endpoint

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


Endpoint

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


All organization-wide systems and applications should integrate with and 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


Where possible, all infrastructure and critical enterprise applications should 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


On the edge of network zones (all internal and external traffic must go 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


Endpoint

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


Network

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


Network

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




Application

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


N/A

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


Collection Agents deployed at:

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




Threat data feeds

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


Endpoint

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


Endpoint

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


Server (database)



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


Corporate system (laptop/ desktop)

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


Highly sensitive transaction data

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


In-house developed software/ application

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




N/A

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


Network

Endpoint

Standalone solution

22. Malware Analysis

Description Malware Analysis tools allow organizations to analyse and reverse engineer malware.

Features Static analysis

Dynamic analysis


Standalone solution

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


Network (applicable to all organizational traffic including ingress, egress, 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


Server

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


Endpoint

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


N/A

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


Network

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


Endpoint

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


Network

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




N/A

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


N/A

59 Nepal GEA 2.0 Security Architecture | Information Security Risk Management

6. 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 management process

Missing patches can leave loopholes in IT systems, and have 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 configuration management

Improperly configured software/ systems/ devices added to existing software/ systems/ devices can lead to insecure configurations and an increased risk of vulnerability

4. Inadequate/ lack of periodic security audits

The objective of a cyber security audit is to provide 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 operations and disaster recovery management

An inadequate continuity of operations or disaster recovery plan could result in longer than-necessary recovery from a possible plant or operational outage. Probable impacts could include business failure, injury or death, financial loss, reputational loss, etc.

6. Ineffective risk assessment process

Lack or misapplication of adequate risk assessment processes 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 process

Lack of an adequate risk management process may result in 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 response process

Without an efficient incident response process, response 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 requirements in RfPs

Acquisition of products and services that do not meet security requirements or ones for which security features are misunderstood

12. Failure to request results of independent security testing of hardware and software prior to procurement

Acquisition of products that do not meet security requirements or ones for which security features are misunderstood

13. Failure to request evidence from a third party of its risk management and security practices

Acquisition of products or consumption of services with an insufficient security posture

14. Failure to request information from a third party on its secure SDLC process

A SDLC process that does not follow security development practices will likely result in insecure software

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 environmental security

Effective physical security measures help protect against unauthorized access, damage, or interference in areas where critical or sensitive 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 operations management

Communication will help to minimize information security risk to a great extent and protect the organization against threat of unintended 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 management

In order to have a seamless expected level of service from third 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 and acceptance

Systems planning and acceptance processes enable system/ capacity 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 malicious software control

Organizations use various types of software and information assets that may be vulnerable to the introduction of malicious code, such as 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 restoration

The purpose of backup and restoration process is to maintain the 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 management

Business Continuity Management process is a holistic 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 management

This process addresses the use of cryptographic controls to protect the 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 and handling

Information labelling and handling process enumerates a set of rules 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 effectiveness measurement

Purpose of this process is to define the approach for measuring the effectiveness of implemented security controls in order to lower the risk 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 application security governance

The objective of this process is to establish security governance gates to move new IT infrastructure (server/ device) or an application to 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 and maintenance

System development and maintenance process is framed to produce 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 management

Exceptions are deviations reported against the defined and approved 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 management

The objective of the VPN access management process is to ensure that only the authorized users have access to the organizational systems.

24. Vulnerability management

The purpose of vulnerability management process is to identify, assess 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 control

Documents required by an organization’s information security 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 on organizational network

Many operating systems are shipped and installed with a 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 and integrity checking

Inadequate log management can lead to various security 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 segregation

Direct compromise of any portion of the network from any other 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 authentication and authorization of users

An adversary can gain unauthorised access to organizational systems. Additionally, systems become vulnerable to the following attacks:

o DoS / DDoS

o Man-in-the-middle attacks



o Session hijacking

o Authentication sniffing

o Session injection

6. Operating system vulnerabilities

Vulnerabilities at the operating system level may help undermine the other security controls in place.

7. Inadequate malware protection

Malicious software can result in performance degradation; loss 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 as OWASP Top 10)

Exploitation of application layer weaknesses may result in a 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 management

Missing patches can leave loopholes in IT systems, and have 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”.

75 Nepal GEA 2.0 Security Architecture | Continual Security Assurance

7. 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

S.No. Review technique

Brief description Capabilities of the technique

Baseline skill set required from the assessor

1. Documentation Review

Documentation review determines if the technical aspects of policies and procedures are current and 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.

Evaluates policies and procedures for technical accuracy and completeness

General knowledge of security from a policy perspective

2. Log Review Log review determines if security controls are logging the proper information, and if the log management policies are being adhered to. Log review may also reveal problems such as misconfigured services and security controls, unauthorized accesses, and attempted intrusions.

Log information that may be useful while conducting security 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

Provides historical information on system use, configuration, and modification

Could reveal potential problems and policy deviations

Knowledge of log formats and ability to interpret and analyse log data; ability to use automated log analysis and log correlation tools





predefined and customized reports that summarize log contents and track them to a set of specific activities.

3. Ruleset Review

A ruleset is a collection of rules or signatures that network traffic or system activity is compared against to determine what action to take – for example, forwarding or rejecting a packet, creating an alert, or allowing a system event.

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.

Reveals holes in ruleset-based security controls

Knowledge of ruleset formats and structures; ability to correlate and analyse rulesets from a variety of devices

4. System Configuration Review

System configuration review is the process of identifying weaknesses in security configuration controls, such as systems not being hardened or configured according to security policies.

Assessors using manual review techniques rely on security configuration guides or checklists to verify that system settings are configured to 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.

Evaluates the strength of system configuration

Validates that systems are configured in accordance with hardening policy

Knowledge of secure system configuration, including OS hardening and security policy configuration for a variety of operating systems; ability to use automated security configuration testing tools

5. Network Sniffing

Network sniffing monitors network communication, decodes protocols, and

Monitors network traffic on the local

General Transmission Control Protocol/





examines headers and payloads to flag information of interest.

Organizations can deploy network sniffers in a number of locations within an environment. These commonly include the following:

At the perimeter, to assess traffic entering and exiting the network

Behind firewalls, to assess that rulesets are accurately filtering traffic

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.

segment to capture information such as active systems, operating systems, communication protocols, services, and applications

Verifies encryption of communications

Internet Protocol (TCP/IP) and networking knowledge; ability to interpret and analyse network traffic; ability to deploy and use network sniffing tools

6. File Integrity Checking

File integrity checkers provide a way to identify that system files have been changed computing and storing a checksum for every guarded file, and establishing a file checksum database.

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.

Identifies changes to important files; can also identify certain forms of unwanted files, such as well-known attacker tools

General file system knowledge; ability to use automated file integrity checking tools and interpret the results

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

S.No. Identification and analysis techniques



1. Network discovery

Network discovery uses a number of methods to discover active and responding hosts on a network, identify weaknesses, and learn how the network operates. Both passive (examination) and active (testing) techniques exist for discovering devices on a network.

Passive techniques use a network sniffer to monitor network traffic and record the IP addresses of the active hosts, and can report which ports are in use and which operating systems 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.

Discovers active devices

Identifies communication paths and facilitates determination of network architectures General TCP/IP and

networking knowledge; ability to use both passive and active network discovery tools

2. Network port and service identification

Network port and service identification involves using a port scanner to identify network ports and services operating on active hosts and the application that is running each identified service.

Discovers active devices

Discovers open ports and associated services/ applications

General TCP/IP and networking knowledge; knowledge of ports and protocols for a variety of operating systems; ability to use port scanning tools; ability to interpret results from tools

3. Vulnerability scanning

Vulnerability scanning identifies hosts and host attributes (e.g., operating systems, applications, open ports), and attempts to identify vulnerabilities rather than relying on human interpretation of the scanning results.

Identifies hosts and open ports

Identifies known vulnerabilities (note: has high false positive rates)

Often provides advice on mitigating discovered vulnerabilities

General TCP/IP and networking knowledge; knowledge of ports, protocols, services, and vulnerabilities for a variety of operating systems; ability to use automated vulnerability scanning tools and interpret/ analyse the results

4. Wireless scanning

Wireless scanning should be conducted using a mobile device

Identifies unauthorized

General knowledge of computing and


S.No. Identification and analysis techniques



with wireless analyser software installed and configured—such as a laptop, handheld device, or specialty device.

Following factors should be considered when planning technical wireless security assessments:

Location of facility being scanned

The security level of the data to be transmitted using wireless technologies

How often wireless devices connect to and disconnect from the environment

Existing deployments of wireless intrusion detection and prevention systems

wireless devices within range of the scanners

Discovers wireless signals outside of an organization’s perimeter

Detects potential backdoors and other security violations

radio transmissions in addition to specific knowledge of wireless protocols, services, and architectures; ability to use automated wireless scanning and sniffing tools

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

S.No. Vulnerability validation techniques



1. Password cracking

Password cracking is the process of recovering passwords from password hashes stored in a computer system or transmitted over networks.

It is performed on hashes that are either intercepted by a network 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.

Identifies weak passwords and password policies

Knowledge of secure password composition and password storage for operating systems; ability to use automated cracking tools

2. Penetration testing

Penetration testing is security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network. It often involves launching real attacks on

Tests security using the same methodologies and tools that attackers employ

Extensive TCP/IP, networking, and OS knowledge; advanced knowledge of network and system vulnerabilities and


S.No. Vulnerability validation techniques



real systems and data that use tools and techniques commonly used by attackers.

Some categories of vulnerabilities exploited by penetration testing include misconfigured security settings, kernel flaws, buffer overflows, insufficient input validation, symbolic links, file descriptor attacks, race conditions, and incorrect file and directory conditions.

Verifies vulnerabilities

Demonstrates how vulnerabilities can be exploited iteratively to gain greater access

exploits; knowledge of techniques to evade security detection

3. Social engineering

Social engineering is an attempt to trick someone into revealing information (e.g., a password) that can be used to attack systems or networks.

One form of digital social 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.

Allows testing of both procedures and the human element (user awareness)

Ability to influence and persuade people; ability to remain composed under pressure

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, and service

Purpose

Participants

General service description


S.No. Area Description Components

2. Service environment

Describes the environment in which the organization will perform the service, from physical location, to hardware/software being used, to the policy and procedures the service provider will need to follow.

Equipment

Facilities

Entities and locations

Policies, procedures, and standards

Agreements and licenses

3. Roles and responsibilities

Describes the roles and responsibilities of all major participants. The service provider responsibilities need to articulate not just the service tasks, but also the documentation of their services, reporting their actions, and support 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).

Service provider responsibilities

Service tasks

Documentation

Service support

Reporting requirements

4. Service levels Identifies the metric, the service level, and methodology for assessing the service level. Organizations may choose to articulate the service level in a range: from unacceptable to minimum to interim to target, or they may choose to set varying service levels for various user groups or schedule times. If so, each service level will need to be articulated.

Objectives

Metrics

Service levels

Service level assessment

5. Terms and adjustments

Provides the costs and period of performance of the service levels and roles and responsibilities articulated in the previous sections as well as providing processes for resolving service agreement disputes, remedying non-compliance, and amending the agreement to account for changing requirements.

Costs

Period of performance

Dispute resolution

Remedies for non-compliance

Maintenance of agreements

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 process and procedure documents

Completion and coverage

Creation of 100% process and procedure documents as defined in the RfP

8 weeks from date of signing of the contract

One week delay – 0.1% LD

2 weeks delay – 0.2% LD

More than 2 weeks delay – 0.4% LD

2. Patch management review

Completion Metric: Completion as per schedule & comprehensive coverage

Quarterly One week delay – 0.1% LD



3. Firewalls Successful implementation of firewalls

Successful deployment of the firewall and UAT.

Hardening of the firewall as per CIS benchmarks or vendor specifications.

All Ports disabled by default.

Any open ports should have a business

8 weeks from date of signing of the contract

One week delay – 0.1% LD




S.No. Category Metric Type Definition Target Severity

justification and approval in place.

Submission of report to the organization.

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

8. 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

91 Nepal GEA 2.0 Security Architecture | Annexure 2: Common Web Application Security Risks and Security Vulnerabilities

9. 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 Authentication

Application functions related to authentication and session 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 Data Exposure

Many web applications and APIs do not properly protect sensitive data, 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 External Entities (XXE)

Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used 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 Access Control

Restrictions on what authenticated users are allowed to do are often 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 Misconfiguration

Security misconfiguration is the most commonly seen issue. This is 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.



7. A7:2017- Cross-Site Scripting (XSS)

XSS flaws occur whenever an application includes untrusted data in a 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 Deserialization

Insecure deserialization often leads to remote code execution. Even if 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 with Known Vulnerabilities

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a 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 Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective 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

95 Nepal GEA 2.0 Security Architecture | Annexure 3: Cloud Security

10. 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 data ownership

A traditional data center of an organization is under complete control of 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 federation

It is very important for the organizations to keep control over user 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 compliance

In cloud-based solution, data is stored at a random place. In most of 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 and resiliency

Business Continuity is an activity an IT organization performs to ensure 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 secondary usage of data

User's personal data gets stored in the cloud as users start using social web sites. Most of the social sites are vague about how they will handle 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 integration

The security of data in transit should be a great concern to every 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 physical security

Multi-tenancy in cloud means sharing of resources and services among 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 forensic support

In the event of a security incident, applications and services hosted at a 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 environment exposure

Organizations generally use non-production environment internally to design, develop and test their software or application. This environment 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.

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

11. 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 Hardcoded Passwords

Use of easily brute-forced, publicly available, or unchangeable credentials, including backdoors in firmware or client software that grants unauthorized access to deployed systems.

2. Insecure Network Services

Unneeded or insecure network services running on the device itself, especially those exposed to the internet, that compromise the confidentiality, integrity/ authenticity, or availability of information or allow unauthorized remote control.

3. Insecure Ecosystem Interfaces

Insecure web, backend API, cloud, or mobile interfaces in the 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 Update Mechanism

Lack of ability to securely update the device. This includes lack of 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 Outdated Components

Use of deprecated or insecure software components/ libraries that could allow the device to be compromised. This includes insecure customization of operating system platforms, and the use of third-party software or hardware components from a compromised supply chain.

6. Insufficient Privacy Protection

User’s personal information stored on the device or in the ecosystem that is used insecurely, improperly, or without permission.

7. Insecure Data Transfer and Storage

Lack of encryption or access control of sensitive data anywhere within the ecosystem, including at rest, in transit, or during processing.

8. Lack of Device Management

Lack of security support on devices deployed in production, including asset management, update management, secure decommissioning, systems monitoring, and response capabilities.

9. Insecure Default Settings

Devices or systems shipped with insecure default settings or lack the ability to make the system more secure by restricting operators from modifying configurations.

10. Lack of Physical Hardening

Lack of physical hardening measures, allowing potential attackers to gain sensitive information that can help in a future remote attack or take local control of the device.

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

12. 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)

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

13. 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 security

Attacks against API endpoints are one common means of 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 limiting

When protecting APIs against abuse or DDoS attacks, it is necessary 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 requests and responses

Some attackers may try to overwhelm the API or trigger a buffer overflow vulnerability with large requests. These may be in the form of 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.

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

www.pwc.in