ICT Security Manual -...

PNP ICT Security Manual S. 2010-01

Philippine National Police

PNP ICT SECURITY MANUAL

(PNPICTSM) Series of 2010-01

Directorate for Information and Communications Technology Management

Plans and Programs Division Release: May 2010



MESSAGE

The subject of network security is a complex matter that is normally well-understood and handled only by experienced IT experts. However, as we head toward electronics solutions to modern policing system in the Philippine National Police, it is a must that we define for our organization how network security will be enforced with clear practices and policies that could be implemented widely and uniformly.

As both local and global influences collaborate to accelerate the innovation of security technologies to maintain critical information technology and telecommunications infrastructure, coming up with this PNP Information and Communications Technology Security Manual (PNP ICTSM) is a good starting point for securing our organization’s network system. The current threats that have been constantly attacking IT enterprises both locally and globally require enduring security procedures that would protect our fundamental network security asset. With this PNP ICTSM, it is hoped that PNP users will have a broader grasp of what is network security in general and gain better understanding of how to reduce exposure and manage the constantly increasing risks.

A better secured PNP network system can only be realized through our collective efforts, intelligent policies, and consistent practices.

i



MESSAGE

The Philippine National Police has included Information and Communications Technology in the PNP Transformation Program. It has also seriously started working out on its ICT priorities and policy agenda. Alongside these new developments is the inevitable exposure of its information and communications system to the highly increasing risk of cyber security threats, pressing comparable demand to the ICT management to implement risk management plan and safeguard its critical networking infrastructures.

In charge with policy-making and oversight of ICT matters, we at the Directorate for Information and Communications Technology Management (DICTM) seriously immerse ourselves into considerations of the best defense possible to secure our network against inevitable threats in our virtual infrastructures and to provide our personnel, managers and users, a toolkit and a guide to their day-to-day operations as a transformed police force by making this first issue of the PNP ICT Security Manual available.

With this PNP ICT Security Manual, we intend to equip our personnel with the necessary know-how to safeguard our infrastructures as we ceaselessly toil to improve and become abreast with the times.

ATTY. MAGTANGGOL B GATDULA, PhD/CEO VI Police Director Director, DICTM

ii



ABSTRACT

This PNP Information and Communications Technology Security Manual

(PNP ICTSM) is published pursuant to the delegated authority of the DICTM to create, update and promulgate policies pertaining to information and communications technology systems, procedures and standards in the PNP as defined in the PNP General Orders Number DPL 09-08 dated April 1, 2009 entitled “Activation”, further defined in Paragraph Number 5, The DICTM’s Duties and Functions”.

This handbook is a reference for PNP personnel who are concerned with

Information and Communications Technology in the Philippine National Police. It is one of the DICTM’s approaches to introducing ICT security awareness as it aims to create a comprehensive and reliable security infrastructure in the PNP. It is designed in such a way that personnel will be guided in the performance of their day-to-day duties and responsibilities with respect to ICT.

Modeled from the New Zealand’s, this PNPICTSM is modified and tailored to fit the PNP requirements. This Manual covers a range of relevant information and recommendations regarding administrative and operational procedures in the handling of PNP Information and Communications Technology. Several existing laws, policies, rules and regulations are mentioned as reference.

This manual is divided in four parts. Part 1 and 2 comprises the two main

parts. Part 3 is supplementary containing reference charts and tables and Part 4 contains the dictionary of abbreviations, glossary of terms, topic reference index and information resources.

DISCLAIMER

This manual is not intended to be an instructional reference for individual and technological functionalities as technologies incessantly evolves. It is the first release of its form by the DICTM and updates will be released from time to time in consideration of the changes in technologies, administrative and operational practices and policy amendments. Other areas still define the need for policy support that shall be considered in later revisions. Inputs, feedbacks, and contributions from users of this manual are encouraged.

iii



MESSAGE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - i MESSAGE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ii ABSTRACT - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - iii DISCLAIMER - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - iii

TABLE OF CONTENTS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - iv

LIST OF CHARTS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - x

LIST OF TABLES - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - xi

iv



TABLE OF CONTENTS

TOPICS Page

PART 1 - ICT SECURITY ADMINISTRATION Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 CHAPTER 1 – ICT SECURITY

1. ICT SECURITY - - - - - - - - - - - - - - - - - - - 2 ICT Security Process - - - - - - - - - - - - - - - - - - - 2

Process Stages - - - - - - - - - - - - - - - - - - - 2 System Disposal - - - - - - - - - - - - - - - - - - - 3

2. ICT SYSTEMS - - - - - - - - - - - - - - - - - - - 3 System Modes - - - - - - - - - - - - - - - - - - - 3

CHAPTER 2 – SECURITY ROLES & RESPONSIBILITIES

The Role of DICTM - - - - - - - - - - - - - - - - - - - 5 The Role of ITMS - - - - - - - - - - - - - - - - - - - 6 The Role of CES - - - - - - - - - - - - - - - - - - - 6 Designating ICT Security Officer - - - - - - - - - - - - - - - - - 7

System Manager - - - - - - - - - - - - - - - - - - - 12 System Users - - - - - - - - - - - - - - - - - - - 13

CHAPTER 3 – SECURITY DOCUMENTATION

Requirements for Documentation - - - - - - - - - - - - - - - - - 15 The Documentation Process - - - - - - - - - - - - - - - - - - - 16 Classifying ICT Security Documents - - - - - - - - - - - - - - - 17

CHAPTER 4 –MANAGING RISK

Outsourcing - - - - - - - - - - - - - - - - - - - 19 Determining the Scope - - - - - - - - - - - - - - - - - - - 20 Process of Conducting Risk Assessment - - - - - - - - - 20

CHAPTER 5 – IDENTIFYING AND DEVELOPING ICT SECURITY POLICIES

ICT Security Policies - - - - - - - - - - - - - - - - - - - 26 ICT Security Policy Contents - - - - - - - - - - - - - - - - - - - 26 National Security Policy Documents - - - - - - - - - - - - - - 26 Inconsistencies - - - - - - - - - - - - - - - - - - - 26

v



Developing an ICT Security Policy - - - - - - - - - - - - - - 27 Identifying Existing Policy Standards - - - - - - - - - - - - - - 27 Organizing Policy Statements - - - - - - - - - - - - - - 28

CHAPTER 6 – DEVELOPING A SYSTEM SECURITY PLAN

About System Security Plans (SSPs) - - - - - - - - - - - - - - 29 Stakeholders - - - - - - - - - - - - - - - - - - - 29 Developing an SSP - - - - - - - - - - - - - - - - - - - 30

CHAPTER 7 – DEVELOPING AND MAINTAINING SOPs

SOP Contents - - - - - - - - - - - - - - - - - - - 31 System Manager SOPs - - - - - - - - - - - - - - - - - - - 31 System Administrator SOPs - - - - - - - - - - - - - - - - - - - 32 System Users SOPs - - - - - - - - - - - - - - - - - - - 33 User Guidance - - - - - - - - - - - - - - - - - - - 34 Improper Use of General Access Right - - - - - - - - - - - 34

CHAPTER 8 – MAINTAINING ICT SECURITY AND MANAGING SECURITY INCIDENTS

Managing Change - - - - - - - - - - - - - - - - - - - 36 Change Process - - - - - - - - - - - - - - - - - - - 36 Detecting Security Incidents - - - - - - - - - - - - - - - - - - - 37 Managing Security Incidents - - - - - - - - - - - - - - - - - - - 38

CHAPTER 9 – REVIEWING ICT SECURITY

About ICT Review - - - - - - - - - - - - - - - - - - - 41 Frequency - - - - - - - - - - - - - - - - - - - 41 Follow-up After Reviews - - - - - - - - - - - - - - - - - - - 42 Process for Review of ICT Security - - - - - - - - - - - - - - 42

PART 2 - ICT SECURITY STANDARDS

CHAPTER 1 – PHYSICAL SECURITY

Fundamentals of ICT Physical Security - - - - - - - - - - - - 45 Environment Testing - - - - - - - - - - - - - - 46 Protection of Office Areas - - - - - - - - - - - - - - 46 Protection of Servers and Communications

Equipment - - - - - - - - - - - - - - 47 Protection of Workstations Media - - - - - - - - - - - - - - 47 Physical Security Incidents - - - - - - - - - - - - - - 48

vi



Emergency Procedures - - - - - - - - - - - - - - 48 CHAPTER 2 – PERSONNEL

User Training and Awareness - - - - - - - - - - - - - - 50 Training Resources - - - - - - - - - - - - - - 51 Clearances and Briefings - - - - - - - - - - - - - - 52

CHAPTER 3 – ICT PRODUCT LIFECYCLE

Evaluated Products - - - - - - - - - - - - - - 54 Product Selection - - - - - - - - - - - - - - 54 Acquiring Products - - - - - - - - - - - - - - 55 Installing and Maintaining Software Products - - - - - - - 55 Data Migration and Archiving - - - - - - - - - - - - - - 56

CHAPTER 4 – HARDWARE SECURITY

Classifying, Labeling and Registering Hardware - - - - - 58 Hardware Repair and Maintenance - - - - - - - - - - - - - - 59 Disposing of Hardware - - - - - - - - - - - - - - 60 Media Sanitation - - - - - - - - - - - - - - 61 Media Destruction - - - - - - - - - - - - - - 63 Portable Computers and Personal - - - - - - - - - - - - - - 63 Electronic Devices (PEDs) Personal Digital Assistants (PDAs) - - - - - - - - - - - - - - 65

CHAPTER 5 – SOFTWARE SECURITY

Operating System - - - - - - - - - - - - - 70 Malicious Code and Anti-Virus Software - - - - - - - - - - - 71 Countermeasures against Malicious Code - - - - - - - - - - 71 Recovering from Malicious Code Infections - - - - - - - - - 72 Software Applications - - - - - - - - - - - - - - 73 Database Security - - - - - - - - - - - - - - 73 Web Application Security - - - - - - - - - - - - - - 74 Web Client Security - - - - - - - - - - - - - - 75 Electronic Mail Security - - - - - - - - - - - - - - 76 Electronic Mail-Protective Marking Policy - - - - - - - - - - - 78 Software Development - - - - - - - - - - - - - - 79

CHAPTER 6 – LOGICAL ACCESS CONTROL

User Identification and Authentication - - - - - - - - - - - - - - 80 Privilege and System Accounts - - - - - - - - - - - - - - 82 Access and Authorization - - - - - - - - - - - - - - 82 Multilevel Systems - - - - - - - - - - - - - - 83

vii



CHAPTER 7 – INTRUSION DETECTION

Intrusion Detection Systems (IDS) - - - - - - - - - - - - - - 85 Audit Logs and Analysis - - - - - - - - - - - - - - 85 Audit Trail Events - - - - - - - - - - - - - - 86 Managing Audit Logs - - - - - - - - - - - - - - 88 System Integrity - - - - - - - - - - - - - - 89 Vulnerability Analysis - - - - - - - - - - - - - - 89

CHAPTER 8 – COMMUNICATIONS SECURITY (COMSEC)

Physical Security - - - - - - - - - - - - - - 91 Transmission Security - - - - - - - - - - - - - - 93 Peripheral Switches - - - - - - - - - - - - - - 95 Wireless Networks - - - - - - - - - - - - - - 95 Infrared and Radio Frequency - - - - - - - - - - - - - - 96 Telephone and Pagers - - - - - - - - - - - - - - 97 IP Telephony - - - - - - - - - - - - - - 98 Facsimile Machines - - - - - - - - - - - - - - 99 Multifunction Devices (MFD) - - - - - - - - - - - - - - 99

CHAPTER 9 – CRYPTOGRAPHY

Requirements for Cryptography - - - - - - - - - - - - - - 106 Approved Cryptographic Algorithms - - - - - - - - - - - - - - 107 Key Management - - - - - - - - - - - - - - 107

CHAPTER 10 – NETWORK SECURITY

Network Management - - - - - - - - - - - - - - 112 Connecting Networks - - - - - - - - - - - - - - 112 Gateways - - - - - - - - - - - - - - 113 Secure Electronic Environment Mail - - - - - - - - - - - - - - 115 Remote Access - - - - - - - - - - - - - - 116 Virtual Private Networks - - - - - - - - - - - - - - 117 Virtual LANs - - - - - - - - - - - - - - 118

CHAPTER 11 DATA TRANSFER

Content Filtering - - - - - - - - - - - - - - 120 Temporary Connections - - - - - - - - - - - - - - 121 Data Import - - - - - - - - - - - - - - 122 Data Export - - - - - - - - - - - - - - 123

viii



PART 3 – CHARTS AND TABLES

Charts and Tables - - - - - - - - - - - 125-130

PART 4 – ABBREVIATIONS, GLOSSARY OF TERMS, TOPIC INDEX AND RESOURCE REFERENCES

Dictionary of Abbreviations - - - - - - - - - - - 140 Glossary of Terms - - - - - - - - - - - 141 Topic Index - - - - - - - - - - - 147 Resource References - - - - - - - - - - - 158

Appendices: Photocopies of related Laws Rules and Regulations

ix



LIST OF CHARTS

Chart 1 Process Stages of ICT Security - - - - - - - - - - - - - 125

Chart 2 Risk Assessment Process - - - - - - - - - - - - - 126

Chart 3 Identifying the Risks - - - - - - - - - - - - - 128

Chart 4 Analyzing the Risks - - - - - - - - - - - - - 129

Chart 5 Assessing and Prioritizing Risks - - - - - - - - - - - - - 130 Chart 6 Developing A Risk Management Plan - - - - - - - - - - 131

Chart 7 Developing An ICT Security Policy - - - - - - - - - - 132

Chart 8 Procedure: Developing A System Security - - - - - - 133

Chart 9 Change Process - - - - - - - - - - - - - 134

Chart 10 Steps in Handling Malicious Codes - - - - - - - - - - - - 135

Chart 11 Hardware Disposal Process - - - - - - - - - - - - - 136

Chart 12 Developing an Access Control List - - - - - - - - - - - - 137

Chart 13 Managing an Audit Log - - - - - - - - - - - - - 138

x



LIST OF TABLES

Table 1 Risk Assessment Procedure - - - - - - - - - - - - - 127

Table 2 Risk Assessment Table - - - - - - - - - - - - - 128

Table 3 Impact Determination Table - - - - - - - - - - - - - 129

Table 4 Likelihood/Threat Determination - - - - - - - - - - - - - 130

xi



PART 1 – ICT SECURITY ADMINISTRATION

Introduction

Part 1 contains information about the way PNPICT Security is managed, implemented and documented.

Contents

Part 1 contains the following chapters:

Chapter 1 – ICT Security

Chapter 2 – ICT Security Roles and Responsibilities

Chapter 3 – Security Documentation

Chapter 4 – Managing Risks

Chapter 5 – Identifying and Developing ICT Security Policies

Chapter 6 – Developing a System Security Plan

Chapter 7 – Developing and Maintaining SOPs

Chapter 8 – Maintaining and Managing ICT Security

Chapter 9 – Reviewing ICT Security

1



CHAPTER 1 – ICT SECURITY Introduction 1.1.0.1. This chapter introduces ICT Security in the Philippine National Police. Contents 1.1.0.2. This chapter contains topics on:

1. ICT Security 2. ICT Systems

ICT SECURITY 1.1.1.1. The Process of ICT Security With insufficient ICT relevant laws in the country, ICT Security in the

PNP could be best achieved when it is made an integral part of the ICT System. DICTM therefore RECOMMENDS that process of ICT security be considered during the analysis and design of every system.

1.1.1.2. Process Stages

The DICTM RECOMMENDS all PNP Units follow the stages described below to implement the appropriate ICT security measures for each system. See: Chart 1, Part 3, p. 125 Stage 1: Conduct Risk Management ▪ Identify the scope of the system to be protected

▪ Develop an initial Risk Management Plan Stage 2: Policy Development

▪ Identify any existing relevant policies, laws and regulations to cover the requirement of each system. When there is none, advice the DICTM for policy references or development.

Stage 3: Security Development Plan ▪ Review Accreditation Requirements and policies, if necessary.

▪ Develop a system security plan to cover the system and its environment.

Stage 4: Implementation ▪ Select and purchase hardware and software according to standard specifications approved by the NAPOLCOM on recommendation of ICT UESB.

▪ Document the Standard Operating Procedure

2



Stage 5: Certification ▪ Complete certification requirements ▪ Seek certification from relevant person or agency

Stage 6: Accreditation ▪ Seek accreditation of the site or system

Stage 7: Ongoing Operations ▪ Utilize the SOPs ▪ Review/Change Control Procedures ▪ Perform configuration and system integrity checks

Stage 8: Review ▪ Revisit this process at least annually.

1.1.1.3. System Disposal The key tasks for system disposal are:

1. Transition planning 2. Migration and Archiving of information

See: Data Migration and Archiving, p.56 3. Sanitizing and redeployment or disposal of equipment and

media. See: Hardware Security, p.58

ICT SYSTEMS

1.1.2.1 Definition: For the purposes of this Manual, an Information and Communications Technology (ICT) system is defined as a related set of hardware and software used for the communication, processing or storage of information, and the administrative framework in which it operates. This definition includes, but is not limited to:

• computers, peripherals; • communication facilities and networks; • software; • information; • maintenance and administration procedures; and • roles.

1.1.2.2. Definition: System Modes for the purposes of this Manual is defined to be an ICT system that is considered to operate in any one of the modes described below. See: • System Users p.13 • Logical Access Control p.80

3



Dedicated: All users with access to the system MUST: • hold a security clearance at least equal to the system classification; • have a need-to-know for all of the information processed by the system; and • be authorized to access all compartments of information on the system.

System High: All users with access to the system MUST: • hold a security clearance at least equal to the system classification; • have a need-to-know for some of the information processed by the system, with need-to-know control enforced by the system; and • be authorized to access all compartments of information on the system.

Compartmented: All users hold a security clearance at least equal to the system classification but not all users are formally authorized to access all compartments of information processed by the system. Access to the compartmented information is enforced by the system.

Multilevel: Information at two or more security classifications is processed, where some of the users are not security cleared for all of the information processed by the system.

4



CHAPTER 2 – SECURITY ROLES AND RESPONSIBILITIES

Introduction 1.2.0.1. This chapter defines ICT security roles and responsibilities. System specific responsibilities 1.2.0.2. Information relating to the system specific roles and responsibilities of ICT security advisers, system managers, system administrators and system users SHOULD be included in the documentation produced for each system. Contents 1.2.0.3. This chapter contains the following topics:

1. The DICTM 2. The ITMS 3. The CES 4. Designating an ICT Security Officer 5. ICT Security Officer Responsibilities 6. System Manager

7. System Users The DICTM’s Role 1.2.1.1. The DICTM was activated by virtue of PNP General Orders Number DPL 09-08 on April 1, 2009. It is specifically tasked to manage and formulate vital policies for the development and administration of ICT resources such as, but not limited to: Hardware, Software (Operating System for Client and Server, Development Tools, Database Management Software, Network Software, Productivity Application Software, Cross-industry Application Software, among others); Network Devices, Telecommunications, System Models, ICT Management Services; and ICT Personnel. It is, in its directorial capacity, commissioned to oversee the roles of the Information Technology Management Service (ITMS) and the Communications and Electronics Service (CES), where they function jointly and/or separately as two technology support units in one ICT environment. The DICTM is responsible for supporting the PNP to ensure the integrity, availability and security of official information. To this end the DICTM provides:

• Production, distribution and control of information system security

(INFOSEC) material; • Production, distribution and control of cryptographic key material and

cryptographic devices for communications security (COMSEC);

5



• Information and Communications Assurance assessment and inspection services;

• ICT Related policy advice and assistance to all PNP Units.

The ITMS’s Role 1.2.2.1. The ITMS, as a National Support Unit of the PNP, is primarily tasked to provide technical expertise to develop and maintain Information Systems and IT Services. Within its specific roles as designer and developer of Information Systems in the PNP are integral responsibilities of maintenance and implementation of IT operations including security of physical and virtual environments. To this end, the ITMS provides:

• Information Technology expertise through the designation/assignment

of IT Officers to all PNP Regions; • Distribution and control of information system security (INFOSEC)

material; • Information Assurance assessment and inspection services; • IT Related policy advice and assistance to all PNP Units.

The CES’s Role 1.2.3.1. The CES, as a National Support Unit of the PNP, is primarily tasked to provide technical expertise in the operation of radio and data communications media such as facsimile and telephone facilities for transmission, receipt of data and communication, multi-trunked systems for communication linkages, maintenance, repair and security communications building and infrastructures. Within its specific roles are integral responsibilities of maintenance and implementation of CT operations including security of physical and virtual environments. To this end, the CES provides:

• Communications Technology expertise through the designation/ assignment of CT officers/personnel to all PNP Regions;

• Distribution and control of cryptographic key material and cryptographic devises for communications security (COMSEC);

• Communications Assurance assessment and inspection services; • CT Related policy advice and assistance to all PNP Units.

Contacting the DICTM, ITMS and CES

For questions, advice and assistance, the DICTM may be contacted through Security Officers at the following addresses:

6



E-mail : [email protected] Phone : 7230401 local 4244 Fax : 4131451 URL : http://www.pnp.gov.ph The ITMS may be contacted at: E-mail : [email protected] Phone : 7230401 loc. 4225 Fax : URL : http://www.pnp.gov.ph and the ITMS Web Services and Cyber Security Division at: E-mail : [email protected] Phone : URL : http://www.pnp.gov.ph The CES may be contacted at: Phone : 7230401 loc. 3670 Fax : 7220825 URL : http://www.pnp.gov.ph

Appointing/Designating ICT Security Officer 1.2.4.1. The ITMS details IT officers to every PNP Regional Offices. These IT Officers SHOULD perform the role of IT System Security Officers (ITSSO) in the PNP regions where they are commissioned during the duration of their detail. Where the ITMS does not designate an ITSSO, or when the detail of an IT Officer expires the responsibilities MUST be assigned to qualified personnel.

The Chiefs of the Regional Communications and Electronics Offices

(RCEO) in all PNP Regions SHOULD act as the Communications Technology System Security Officer (CTSSO) in each PNP region.

The ITSSO and the CTSSO are responsible for ensuring that appropriate

security is applied during each phase of the IT and CT system lifecycle. They will work with each other and across the PNP organization, particularly with the DICTM, the ITMS, the CES, and users, as well as provide coordination with the external support agencies.

Note: Appointment of ITSSO and CTSSO will change when the PNP IT and CT become fully integrated and when the proposed administrative ICT offices in the regional levels are approved and functional.

7



Designating ICT Security Personnel (ICTSP) in all PNP Administrative and Operations Units. 1.2.4.1.1. All PNP Divisions, Branches, Sections, Stations, Offices and Field units that utilize ICT technologies SHOULD appoint IT Security Personnel, and CT Security Personnel who shall act as System Security Officers that would supervise the day-to-day operation and be responsible in the security of information and communications technology systems of their office. Qualifications of ITSSO 1.2.4.2. To oversee a range of technically complex IT security issues, the ITSSO must:

• be fully knowledgeable of the structure and architecture of the organization’s information and communications systems; • have a detailed knowledge of the system’s security features, operating systems, access control, and auditing facilities; • be familiar with security strategies in general and IT security in particular; • provide advice on ICT security to the DICTM, ITMS, CES and users; and • have ready access to the DICTM, ITMS and CES for security issues. Where IT function is outsourced, the ITSSO MUST be independent of the outsourcer.

Important: The PNP Regional Offices concerned retains ultimate responsibility for the security of its IT systems, regardless of what roles or functions are outsourced.

Qualifications of CTSSO 1.2.4.3. To oversee a range of technically convoluted CT concerns, the CTSSO must:

• be fully knowledgeable of the structure and architecture of the organization’s information and communications systems; • have a detailed knowledge of the system’s security features, operating systems, access control, and auditing facilities; • be familiar with security strategies in general and CT security in particular; • provide advice on CT security to the DICTM, ITMS, CES and users; and • have ready access to senior management on security issues. Where CT function is outsourced, the CTSSO MUST be independent of the outsourcer. Important: The PNP Regional Offices concerned retains ultimate responsibility for the security of its CT systems, regardless of what roles or functions are outsourced.

8



Qualifications of ICTSP 1.2.4.4. To oversee the proper and secured utility of ICT in the PNP Divisions/Branches/Offices/Sections/Field Units, an ICTSP must:

• have knowledge of the structure and architecture of the organization’s information and communications systems; • have knowledge of the system’s security features, operating systems, access control, and auditing facilities; • be familiar with security strategies in general and ICT security in particular; • provide advice on CT security to the DICTM, ITMS, CES and users; and • have ready access to senior IT and CT officers on security issues. Where ICT function is outsourced, the ITSSO/CTSSO MUST be independent of the outsourcer. Important: The PNP Regional Offices concerned retains ultimate responsibility for the security of its ICT systems, regardless of what roles or functions are outsourced.

Clearance and Briefing Issues 1.2.4.5. The ITSSO and the CTSSO MUST be:

• security cleared for access to the highest classification of information processed by both the PNP’s IT and CT systems; and • able to be briefed into any compartmented material on the PNP’s ICT systems. The ITSSO and the CTSSO may have unrestricted access to large volumes of classified information. Therefore, the DICTM RECOMMENDS that units/offices require these staff to execute and possess security declaration clearance.

ICT SECURITY OFFICER RESPONSIBILITIES ITSSO Responsibilities 1.2.5.1. Primary Responsibility

The ITSSO is responsible for overseeing IT security within the PNP. He or she must work closely with the ITMS and the DICTM which are responsible for wider security matters.

9



1.2.5.2. Allocation of ITSSO functions The ITSSO role is assigned to qualified individuals. However, its functions

may be performed by several individuals or teams. Regardless of how the functions are allocated, responsibility for their effective execution remains with the designated ITSSO. Where the ITMS have not appointed an ITSSO, the responsibilities MUST be assigned to personnel who qualify. 1.2.5.3. Administrative Responsibilities

The ITSSO is responsible for:

• identifying and recommending security improvements to IT systems; • ensuring security aspects are considered as part of the change management process and in preparation for IT and CT integration;

• coordinating the development, maintenance and implementation of all Security-related system documents, in conjunction with the System Managers in the ITMS and DICTM; and

• investigating and reporting security incidents.

1.2.5.4. Technical Security Advice and Training Responsibilities The ITSSO is responsible for:

• providing technical security advice involved with information system a. development, b. acquisition, c. implementation, d. modification, e. operation, f. support, g. architecture, h. decommissioning, and i. equipment disposal.

• managing information system security awareness within the division/ branch/office/section/field unit.

1.2.5.5. Reviewing Responsibilities

The ITSSO is responsible for the regular review of:

• information system security; • information system audit trails and logs; and • the integrity of the information system configuration.

10



CTSSO Responsibilities Primary Responsibility 1.2.5.6. The CTSSO is responsible for overseeing CT security within the PNP. He or she must work closely with the CES and the DICTM which are responsible for wider security matters. Allocation of CTSSO functions 1.2.5.7. The CTSSO role is assigned to qualified individuals. However, its functions may be performed by several individuals or teams. Regardless of how the functions are allocated, responsibility for their effective execution remains with the appointed CTSSO. Where the CES have not appointed a CTSSO, the responsibilities MUST be assigned to personnel who qualify. Administrative Responsibilities 1.2.5.8. The CTSSO is responsible for:

• identifying and recommending security improvements to CT systems; • ensuring security aspects are considered as part of the change

management process and in preparation for IT and CT integration; • coordinating the development, maintenance and implementation of all

Security-related system documents, in conjunction with the System Managers in the CES and DICTM; and

• investigating and reporting security incidents.

Technical Security Advice and Training Responsibilities 1.2.5.9. The CTSSO is responsible for:

• providing technical security advice involved with communications system a. development, b. acquisition, c. implementation, d. modification, e. operation, f. support, g. architecture, h. decommissioning, and i. equipment disposal.

• managing communications system security awareness within the division/ branch/office/section/field unit.

11



Reviewing Responsibilities 1.2.5.10. The CTSSO is responsible for the periodic review of:

• communications system security; • communications system audit trails and logs; and • the integrity of the communications system configuration.

SYSTEM MANAGER

Protection of ICT Resources 1.2.6.1. The DICTM, ITMS and CES will define the security requirements for the PNP’s ICT systems. In most situations the ITMS and the CES which has functional control of specific resources will be responsible for deciding what type of protection is most appropriate to satisfy those requirements. This responsibility will often lie with the IT and CT Systems Managers. The ITMS and the CES SHOULD appoint respective System Managers, particularly for critical systems.

Qualifications and Experience 1.2.6.2. The use of a well trained and knowledgeable Systems Manager is crucial if the information security measures planned for a system are to be effective over all phases of its lifecycle. The System Manager SHOULD be suitably qualified and experienced in the system he or she will be responsible for. The DICTM, ITMS, CES and Regional Offices SHOULD ensure that the System Manager has the resources needed to keep up-to-date with applicable system and security issues. Documentation, Certification and Accreditation Responsibilities 1.2.6.3. The System Manager is responsible for obtaining and maintaining security accreditation of the system by:

• ensuring that the system complies with the relevant Security Standards, ISSP and TSSP;

• ensuring that the impact of system modifications or additions to security mechanisms is formally managed;

• identifying any system changes that require recertification and reaccreditation;

• ensuring that documentation is complete, accurate and up to date; and • obtaining all necessary certifications.

The System Manager is usually responsible for the development, maintenance and implementation of the following system documentation:

12



• Risk Assessment; • Information System Security Plan and Communications System

Security Plan or Information and Communications Technology System Security Plan;

• Standard Operating Procedures (SOPs). SOPs 1.2.6.4. The System Manager SHOULD be familiar with all SOPs relating to the operation of the system. He or she is responsible for ensuring that the SOPS are followed. System Manager, ITSSO and CTSSO 1.2.6.5. The ITSSO and the CTSSO SHOULD assist the System Manager in the performance of the System Manager’s security-related responsibilities. SYSTEM USERS Types of system users 1.2.7.1. This topic explains responsibilities for:

• general users and those with general access to the information system; and • privileged users with administrative access (privileged access).

Responsibilities of general users 1.2.7.2. System users MUST ensure that they understand and comply with the relevant policies, plans and procedures for the system(s) they are using. PNP Offices SHOULD ensure that users are aware of the sources for this information. Requirements of privileged access (e.g. Administrator accounts) 1.2.7.3. As a minimum, privileged users MUST:

• read and comply with the relevant policies, plans and procedures for the systems they use;

• possess a security clearance at least equal to the highest classification of information processed on those systems;

• protect the authenticators for all their accounts as per the highest level of information it secures;

Example: Passwords for root and administrator accounts.

• not share authenticators for privileged accounts without approval; • be responsible for all actions under their privileged account(s);

13



• use privileged access only to perform authorized tasks and functions that require such access; and

• report all potentially security–related system problems to the ITSSO.

Management of privileged access 1.1.8.4. Offices SHOULD: • keep privileged access to a minimum; and • conduct regular audits of privileged accounts.

14



CHAPTER 3 – SECURITY DOCUMENTATION

Introduction 1.3.0.1. A documentation outline is essential for organizing all the required ICT security documentation that would allow for easy creation, reference and maintenance of the information. Contents 1.3.0.2. This chapter contains the following topics: 1. Requirements for ICT Security Documentation 2. The Documentation Process 3. Classifying ICT Security Documents REQUIREMENTS FOR ICT SECURITY DOCUMENTATION High–level documents 1.3.1.1. It is required that senior management in each PNP Units approves, promulgates and implements security policy that sets out their approach and commitment to security.

The resultant PNP-wide documentation should be linked to an information security risk assessment and SHOULD include security policies, an information security plan and security instructions.

All system specific Risk Assessments, System Security Plans and Standard Operating Procedures developed, SHOULD be consistent with the objectives, risks and requirements defined in these high–level documents. ICT Security Policy 1.3.1.2. The formulated ICT Security Policy may form part of the overall Security Policy or Security Instructions. See.: Identifying and Developing ICT Security Policies, pp.26,27 Risk Assessment for ICT systems 1.3.1.3. The PNP Units SHOULD ensure that every system is covered by a Risk Assessment (RA). Depending on the documentation framework chosen, multiple systems may be able to refer to or build upon a single RA. See.: Managing Risk, p. 19

15



System Security Plans 1.3.1.4. PNP Units SHOULD ensure that every system is covered by a System Security Plan (SSP). Every SSP SHOULD be able to be traced back to a Risk Assessment. Depending on the documentation framework chosen, some details common to multiple systems may be consolidated in a higher level SSP. See.: Developing a System Security Plan (SSP), Chapter 6, pp.29,30 Standard Operating Procedures 1.3.1.5. PNP Units SHOULD ensure that Standard Operating Procedures (SOPs) are developed for every system. The SOP should be clearly linked to the SSP. Depending on the documentation framework chosen, some procedures common to multiple systems may be consolidated into a higher level SOP document. See.: Developing and Maintaining SOPs, p.31

Using higher level documents to avoid repetition 1.3.1.6. Where there is some commonality between systems, the DICTM RECOMMENDS that higher-level documents describing the common aspects be created. System-specific documents MUST then refer to the higher level documents, rather than repeating the information.

Possible areas of commonality include: • geographical location; • security classification; • system functionality; • common technical platform; or • management boundaries.

Using a documentation framework 1.3.1.7. The DITCM RECOMMENDS that an over-arching document describing the unit’s documentation framework be created and maintained. This document should include a complete listing of all ICT security documents, show the document hierarchy, and define how office/unit documentation is mapped to the requirements described here. The framework should also indicate who the document owners are, the period of validity and frequency of review. For easy understanding and for a well–defined documentation framework, the DICTM RECOMMENDS that PNP units use the document names defined in this chapter. The Documentation Process Develop the content 1.3.2.1. The DICTM RECOMMENDS that people with a good understanding of both the subject matter and the PNP project, develop the ICT security documentation. When documentation development is outsourced, the PNP Unit SHOULD:

16



a. review the documents for suitability, b. ensure the documents are treated with confidentiality, c. retain control over the content, and d. ensure that all higher policy requirements are met. Depending on the unit’s documentation framework, some new documentation requirements may be met by referencing or modifying existing documents. Obtain signature 1.3.2.2. All ICT security documents SHOULD be formally approved and signed off by an appropriate person. The DICTM RECOMMENDS that:

a. all high level ICT security documents be approved by the Directors ITMS and CES and

b. all system–specific documents be approved by: i) the owner of the system, ii) the ITSSO/CES; and iii) the System Manager.

Documentation maintenance 1.3.2.3. PNP Units SHOULD develop a schedule for reviewing all ICT security documents at regular intervals. The DICTM RECOMMENDS that: a. the interval between reviews be no greater than twelve months, b. reviews be performed in response to significant changes in the environment, procedures or system, and c. the date of the most recent review is recorded on each document. Note: Any significant change to the environment and/or procedures may require a fresh Risk Assessment. Classifying ICT Security Documents Purpose 1.3.3.1. ICT security documentation contains information that could significantly increase the risk to the systems it covers, if someone with malicious intent gained access to the information. PNP Units’ Classification of ICT security documentation MUST be in accordance with the PNP Information Classification. General guidance 1.3.3.2. The DICTM RECOMMENDS that PNP units, by default, classify system documentation at the same level as that of the system itself. However, an analysis of the applicable risks may determine that a higher or lower classification is appropriate.

17



Examples: The following are two examples of when it may be appropriate to classify documents at a level other than the classification of the system to which they refer.

• Server configuration information for a web server hosting a PNP unit’s public website may be classified as CONFIDENTIAL.

• A cabling diagram for a SECRET system could be classified as RESTRICTED. Document classification 1.3.3.3. PNP Units SHOULD apply the following classifications, as a minimum, to ICT security documentation.

System Classification : Documentation Classification Unclassified : Confidential or Unclassified Confidential : Confidential Restricted : Restricted or Confidential Secret : Secret Top Secret : Top Secret

18



CHAPTER 4 - MANAGING RISK Introduction 1.4.0.1 Risk management is a methodology for comprehensively and systematically managing risks in an organization. A risk assessment is a tool used to aid in the implementation of a risk management approach. Contents 1.4.0.2 This chapter contains information about developing and using a risk assessment to evaluate and control risk affecting ICT systems in the PNP. ICT Security Risk Management 1.4.1.1. ICT security risk management follows the same principles and procedures as general risk management but the risks are specific to ICT and information assets. Consistency with standards 1.4.1.2. The risk management process used in this manual presents a risk assessment and treatment strategy that is consistent with the Risk Management Principles and Guidelines of the International Standard Organization (ISO). The material in this document complements these guidelines and should be used in conjunction with related PNP existing guidelines on Risk Management. Ref.: ISO31000:2009 Development and maintenance 1.4.1.3. The ITSSO and CTSSO SHOULD be responsible for the development and maintenance of the risk assessments for their systems. For new systems the responsibility for developing the initial risk assessment may be done by the project manager. In all other cases a risk assessment should be conducted when there is a significant change to the system or in the environment in which it operates. Where higher level, multi-system or PNP-wide risk assessments are used, the ITSSO and the CTSSO are responsible for their development and maintenance. See: Using higher level documents to avoid repetition, p.16 Outsourcing 1.4.1.4. A PNP Unit whose ICT infrastructure is outsourced remains accountable for the security of the PNP and its information assets. Contents 1.4.1.5. This chapter provides the Guidance for the Risk Assessment Process, which are:

19



Stage 1: Establishing the Context Stage 2: Identifying the Risks Stage 3: Analyzing the Risks Stage 4: Assessing and Prioritizing Risks Stage 5: Developing a Risk Management Plan Stage 6: Risk Assessment Document

Guidance for the Risk Assessment Process Note: This topic contains practical assistance for conducting an ICT security risk assessment. The DICTM RECOMMENDS PNP Units use it in conjunction with Risk Management Guidelines and Chapter 4: Managing Risk Process. Determining the scope 1.4.1.6. The scope of the risk assessment should be defined to meet a specific set of objectives, which may be strategic or operational in nature which may be conducted for reasons, such as: • to assess and manage risks to a system, site or organization, • to determine the impact of a proposed change, or • to focus on an identified high-value area. See: Using Higher Level Documents to Avoid Repetition p.16 Appropriate level of detail 1.4.1.7. The level of detail provided in a risk assessment should be appropriate to address the objectives as defined in the scope. In some cases, it may be prudent to omit some steps. For larger or more detailed plans, or where an increased security requirement exists, additional steps may be required. Process 1.4.1.8. Described below is the process for conducting a Risk Assessment.

1.4.1.8.1. Stage 1: Establishing the Context The aim of this stage is to identify and define the scope, assets, boundaries and environmental context of the risk assessment project and deliverables. The information documented within this stage forms the executive summary of the Risk Assessment document. Procedure

The DICTM RECOMMENDS considering the following matters to establish the context for the risk assessment.

▪ Risk Assessment Project. ▪ Strategy

▪ Organization

20



▪ Assets ▪ Evaluation Criteria

See: See Risk Assessment Procedure Table, p.127 1.4.1.8.2. Stage 2: Identifying the Risks The aim of this stage is to generate a comprehensive list of ICT security threat scenarios and events that could impact the objectives and assets identified in Stage 1: Establishing the Context. See: Step-by-step procedure, p.128

Procedure

Follow the steps below to create a table of threat scenarios.

Step 1: Generate a list of possible ICT security threats to the system and environment. Some of the potential threats include: • malicious software (e.g. viruses); • hackers; • politically motivated groups; • criminals; • users (accidental and intentional); • system administrators (accidental and intentional); • natural disasters (e.g. an earthquake); •local environmental problems (e.g. power disruption); and hardware failures. Step 2: From the significant threats identified in Step 1, generate a list of threat scenarios and events that could have the potential to compromise or otherwise damage the assets defined in Step 4 of Stage 1: Establishing the context. Step 3: Create a risk assessment table with a row for each threat scenario/event. The columns in the table SHOULD include:

• Ref - local reference code or number to uniquely identify each scenario. • Description is a brief description of the attack/event scenario. Include the threat source, the asset(s) affected, and the path/method/event. • Impact Type describes whether the scenario affects the Confidentiality, Integrity, Availability or other functions of the asset(s). • Impact Rating is an assessment of the magnitude of damage the scenario could or would be likely to cause.

21



• Likelihood Rating is an assessment of the probability of the attack being attempted or frequency of the event occurring. • Vulnerability Rating. ‘Vulnerability’ is a characteristic or weakness of an information asset or group of assets that can be exploited by a threat. The Vulnerability Rating is an assessment of the environment’s and/or system’s susceptibility to the scenario • Risk Rating is a culmination of the Likelihood, Vulnerability and Impact Ratings. Complete the Ref, Description & Impact Type fields, the remaining fields are completed in Stage 3.

See: Risk Assessment Table, p. 128 1.4.1.8.3. Stage 3: Analyzing the Risks The aims of this stage are to: • estimate the likelihood of, vulnerability to, and impact from each scenario to derive a ‘risk’ value; • separate the acceptable from the unacceptable risks; and • provide data for the evaluation and treatment of risks.

Procedure

Follow the steps below for each scenario developed in Stage 2, Identifying the Risks. Record the results in the applicable risk worksheet and the risk assessment table.

Step 1: Determine the level and type of impact the scenario could or would be likely to cause.

Step 2: Estimate the likelihood of the scenario occurring. Step 3: Assess the current systems, process and protection to derive the level of vulnerability to the scenario. Step 4: Determine the overall level of risk using a risk matrix table. See: Step-by-step procedure Chart, p.129 Impact determination Below describes example of impact ratings. Impact Rating is: SERIOUS if the attack/event would Halt services for more than a day; or compromise classified or private information; or cause a loss of trust in the integrity of the system. SIGNIFICANT if the attack or event would interrupt services for more than 30 minutes but less than a day; or breach need-to-know

22



requirements; or cause a loss of trust of the integrity of some of the information in the system. MINIMAL if the attack or event would not interrupt services for more than 30 minutes; or breach need to know; or cause a loss of trust in the integrity of the information system. See: Impact Determination Table, p.129 Likelihood/Threat determination Vulnerability ratings that can be selected to show how likely it is that the threat scenario will occur are described below. Vulnerability Rating is:

Very High: If the current protection is unlikely to prevent it or limit the damage in any way. High: If the current protection may delay or otherwise hinder it but is unlikely to prevent it. Moderate: if the current protection will usually prevent or limit it based on past activity. Low: if the current protection is sufficient to prevent it under most circumstances. Very Low: if the current protection is almost certain to prevent it from succeeding or will minimize its effect. See: Likelihood Determination Table, p.130

Documentation of risk matrix The risk matrices or matrix and the associated legend SHOULD be documented in the Risk Assessment document.

1.4.1.8.4. Stage 4: Assessing and Prioritizing Risks The aim of this stage is to determine risk management priorities by assessing whether the level of risk for each scenario is acceptable or not – where it ranks in terms of urgency, effort and cost to mitigate.

Acceptable risks The risks and risk levels deemed acceptable will invariably differ and SHOULD be based on specific goals and objectives. Procedure Below describes the steps taken to assess and prioritize the identified risks and create a risk register.

23



Step 1: For each risk identified in the risk assessment, assess the acceptability of the risk level calculated in Stage 3 with regard to: • management expectations; • vital functions and capabilities; • stakeholder and client expectations about confidentiality, integrity and availability of the information and system; ▪other criteria (e.g. sector best-practices, minimum standards, etc). Step 2: Rank the risks that have unacceptable levels based on importance and urgency (i.e. size of the gap between the assessed risk and the level that would be acceptable). For instance:

High Urgent Action required - risk MUST be reduced Medium Action Required - risk SHOULD be reduced Low Action not required See: Assessing and Prioritizing Risk Chart, p.130

1.4.1.8.5. Stage 5: Developing a Risk Management Plan Definition: Risk Management Plan A Risk Treatment Plan documents how risk treatment controls should be Implemented. A risk management control is a measure that is taken to minimize risks, by reducing the likelihood and/or the consequence of the risk occurring.

The aim of this stage is to identify controls and implementation strategies that will reduce the residual risk for those risks identified (in the risk register) as being unacceptable.

Procedure Steps to be taken to determine appropriate controls and develop a Risk Management Plan:

Step 1: List the unacceptable identified risks from Stage 4 in priority order on the risk worksheets. Step 2: Record one or more options of appropriate controls for each risk.

Step 3: Perform a cost/benefit analysis for each set of controls.

24



Step 4: Calculate the residual risk rating taking into consideration the effect of the proposed control(s). See Stage 3: Analyzing the Risks, p.22 Step 5: Re–assess the acceptability of the new risk ratings according to the criteria used in Stage 4. Select the most appropriate controls. See: Stage 4: Assessing and Prioritizing Risks, p.23, 24 Step 6: Record the accepted controls. Develop the Risk Treatment Plan by defining the responsibilities, timetable and monitoring methods for the implementation of each accepted control. See: Developing a Risk Management Plan Chart, p.131

1.4.1.8.6. Stage 6: Risk Assessment Document

The Risk Assessment document comprises: • an executive summary, derived from Stage 1; • risk assessment documentation, derived from Stages 2, 3 and 4; • a risk treatment plan, derived from Stage 5; and • risk worksheets, included as an annex.

Document the tables used The tables used to determine the impact, likelihood and vulnerability ratings SHOULD be included in the Risk Assessment document. Risk matrix A level of risk can then be derived for each threat scenario via the series of risk matrices.

25



CHAPTER 5 – IDENTIFYING AND DEVELOPING ICT SECURITY POLICIES

Introduction 1.5.0.1. This chapter contains information about ICT Security Policies in the PNP. Contents 1.5.0.2. This chapter contains the following topics:

1. ICT Security Policies; and 2. Developing ICT Security Policies

PNP ICT Security Policies 1.5.1.1. Definition: A PNP ICT Security Policy is a high–level document that describes how PNP protects its ICT resources. It allows the PNP to provide direction and show commitment to ICT security. An ICT Security Policy is normally developed to cover all ICT systems. See: Requirements for ICT Security Documentation, p.15 ICT Security Policy contents 1.5.1.2. Contains description of the ICT security objectives, intent, standards, organization and responsibilities, and set any specific minimum requirements, which will then be part of the development of more specific risk assessments and system security plans.

National Security Policy Documents 1.5.1.3. The key national security policy documents to be considered when developing ICT security policy documents are:

1. E-Commerce Law 2. E-Government Law 3. UN Standards 4. NAPOLCOM Circulars 5. CICT Policies 6. PNP Policies, Rules and Regulations 7. This manual

Inconsistencies between policies 1.5.1.4. PNP Units SHOULD contact the DICTM if any apparent inconsistencies or ambiguities with national information security policy documents require clarification.

26



Developing an ICT Security Policy Process 1.5.2.1. The DICTM within its delegated authority, duties, functions and responsibilities is the policy making-body for ICT in the PNP and therefore the office in charge, to create and implement ICT policies in the Philippine National Police. For this manual, the stages that are being considered by the DICTM in the creation of ICT Security policies are described as follows:

Stage 1: Gain the Command Group’s support for the development of an ICT Security Policy. Stage 2: Determine the overall scope, objectives and structure of the document. Stage 3: Identify all existing applicable regulations, policies and standards. Stage 4: Compare the identified objectives with the existing policies and standards to identify policy gaps.

Stage 5: Write policy statements to address each gap. Stage 6: Identify general and specific responsibilities for ICT security management.

Stage 7: Gain Command Group’s approval and signature. Stage 8: Publish and communicate the ICT Security Policy to all PNP

Units. Reference: DICTM Administrative and Operation Manual

Identifying existing policies and standards 1.5.2.2. Existing applicable policies and standards may include, but are not limited, to the following:

• this manual; • E–government Law • E–Commerce Law • The Privacy Act; • NAPOLCOM Circulars • The Public Records Act • Other agency–specific policies; • ISO31000:2009 and • Other applicable regulations, policies, standards and guidelines are available from:

• The NTC; ▪ The CICT; and • NCC

27



Organizing policy statements 1.5.2.3. Once the policy has been defined, the policy guidelines may be used to produce a more detailed policy framework. This framework may include:

• responsibilities; • configuration control; • access control; • networking and connections with other systems; • physical security and media control; • emergency procedures and incident management; • change management; and • education and training.

28



CHAPTER 6 – DEVELOPING A SYSTEM SECURITY PLAN Introduction 1.6.0.1. This chapter contains information about developing System Security Plans (SSPs). Contents 1.6.0.2. This chapter contains the following topics.

1. About SSP 2. Developing an SSP

About System Security Plans (SSPs) Definition: System Security Plan 1.6.1.1. A System Security Plan (SSP) is a security management document that:

• is a means for implementing the ICT Security Policy and the outcomes of the risk assessment; and • details the high–level security architecture and specific policies that are to be enforced within the system and for any interconnections to other systems.

Purpose 1.6.1.2. The purpose of an SSP is to indicate how all the relevant security requirements identified in the ICT Security Policy and risk assessment will be met in a given information systems context. See: ICT Security Policy contents, p.26

Development and maintenance 1.6.1.3. The System Manager is usually responsible for the development and maintenance of the SSPs for the systems under their control. For new systems, the Project Manager is usually responsible for developing the initial SSP. Where higher level multi–system SSPs are used, the DICTM RECOMMENDS that the ITSSO be tasked with ensuring their development and maintenance. See: Using higher level documents to avoid repetition, p.16

Stakeholders 1.6.1.4. There may be many stakeholders involved in defining the SSP, including representatives from the:

29



• project, who must deliver the secure capability (including contractors); • owners of the information to be processed by the system; • users for whom the capability is being developed; • PNP audit authority; • information management planning areas; • Accreditation Authority; and • infrastructure management (building and communications infrastructure).

Developing an SSP

Procedure 1.6.2.1. The System Manager SHOULD follow the steps described below to develop an SSP. Note: The contents of the SSP should be appropriate for the size and importance of the system.

Step 1: Review the Risk Assessment, ICT Security Policy, and any higher–level SSPs that may be relevant. Step 2: Develop the strategies required to implement the identified policies and controls. Consult with stakeholders if necessary.

Step 3: Select or develop a document structure for the SSP Step 4: Record the strategies in the appropriate section of the SSP.

Step 5: Obtain all necessary certifications and insert them in the appropriate section of the SSP.

30



CHAPTER 7 – DEVELOPING AND MAINTAINING SOPs Introduction 1.7.0.1. This chapter contains information about developing and using Standard Operating Procedures (SOPs).

Contents 1. 7.0.2. This chapter contains the following topics.

1. Developing SOPs 2. SOP Contents

Definition: SOPs 1.7.1.1. Standard Operating Procedures (SOPs) are instructions to all system users, administrators and managers on the procedures required to ensure the correct operation of a system. Security-related SOP content ensures the secure operation of a system.

Relationship between SSP and SOPs 1.7.1.2. The primary function of the security-related content of the SOPs is to ensure the implementation of and compliance with the System Security Plan (SSP). PNP Units SHOULD ensure that SOPs are consistent with all relevant SSPs. See: Developing a System Security Plan (SSP), p.29

Maintenance 1.7.1.2.1. The System Manager SHOULD ensure that SOPs are maintained and updated. This will usually be done as: • a response to changes to the system, or • part of a regular review of documentation.

SOP Contents

System Manager/Administrator SOPs 1.7.2.1.1. Described below is the minimum security procedures that SHOULD be documented in the ITSSO’s/CTSSO’s SOPs.

User Education: instructing new users to comply with ICT security requirements.

31



Audit Logs: reviewing system audit trails and manual logs, particularly for privileged users.

System Integrity Audit: • reviewing user accounts, system parameters and access controls to ensure that the system is secure; • checking the integrity of system software; • testing access controls; and • inspecting equipment and cabling

Data Transfers: • managing the review of removable media containing data that is to be transferred offsite; and • managing the review of incoming media for viruses or unapproved software. Asset Musters: labeling, registering and mustering assets, including removable media. Security Incidents: managing and reporting security incidents.

1.7.2.1.2. The ITSSO/CTSSO is responsible for the technical and operational effectiveness of the system. Described below is the minimum security procedures that SHOULD be documented in the System Manager’s (ITSSO/CTSSO) SOPs.

System Maintenance and Hardware Destruction:

• managing the maintenance of system software and hardware; • managing the sanitization or destruction of unserviceable equipment and media. User Account Management: authorizing new system users and removing unrequired accounts. Configuration Control: approving and releasing changes to the system software or configuration.

Access Control: authorizing user access rights to applications and data. System backup and recovery: backup regime and storage, recovering from system failures.

System Administrator SOPs 1.7.2.1.3. The System Administrator is responsible for the day-to-day operation of the system. Described below is the minimum security procedures that SHOULD be documented in the System Administrator’s SOPs.

32



System closedown: Securing the system after office hours. Access Control: Implementing user access rights to applications and data. Passwords: Enforcing complex and rotating passwords. User Account Management:

• adding and removing users; • setting user privileges; • cleaning up directories and files when a user departs or changes their role.

System backup and recovery:

• backing up data, including audit logs; • securing backup tapes; • backup verification; • recovering system from backups.

System Users 1.7.2.1.4. System Users SHOULD read and agree to abide by the System Users’ SOPs. The DICTM RECOMMENDS that PNP Units require users to sign a declaration to this affect. System Users’ SOPs SHOULD contain: a. an instruction on the security roles and responsibilities at the site, and b. a warning that:

i) users’ actions may be audited, and ii) users will be held accountable for their actions.

System Users– SOPs 1.7.2.1.5. Below is the minimum security procedures that SHOULD be documented in the System Users’ SOPs.

Password: Guidelines on choosing and protecting passwords. Need-to-know: Guidelines on enforcing information protection on the system. Security Incidents: What to do in the case of a suspected or actual security incident. Security Classification: The highest level of classified material that can be processed on the system. Temporary Absence: How to secure the workstation when the user is temporarily absent. End of day: How to secure the workstation at the end of the day. Media Control: Procedures for controlling and sanitizing media, including requirements to check incoming and outgoing media.

33



Hardcopy: Procedures for labeling, handling and disposing of hardcopy material.

Visitors: Procedures relating to visitors. Maintenance: What to do for hardware and software maintenance.

User guidance 1.7.2.1.6. Units/Offices MUST provide guidance to users on their responsibilities relating to ICT security, and the consequences of non–compliance. The DICTM RECOMMENDS that offices/units guidance to users includes the following. Users are to: • only access data, control information, and software to which they have authorized access and a need-to-know; • immediately report all security incidents and potential threats and vulnerabilities involving information systems to the ITSSO; • protect their passwords and other access authenticators (e.g. PINs, tokens, keys) and report any compromise or suspected compromise of them to the ITSSO; • ensure that system media and system output is properly classified, marked, controlled, stored, and sanitized; • inform the ITSSO when access to a particular information system is no longer required; • observe rules and regulations governing the secure operation and authorized use of information systems; and • protect terminals from unauthorized access. Example: User completes a project, transfers, retires, or resigns.

Improper use of general access rights 1.7.2.1.7. PNP Units SHOULD advise users not to: • introduce malicious code into any information system; • physically damage the system; • conduct any unauthorized bypass, strain, or test of security mechanisms; Exception: If security mechanisms must be bypassed for any reason, users must first receive approval from the ITSSO. • introduce to, or use, unauthorized software, firmware or hardware on an information system; • assume the roles and privileges of others; • attempt to gain access to information for which they have no authorization; or • relocate information system equipment without proper authorization.

34



CHAPTER 8 – MAINTAINING ICT SECURITY AND MANAGING SECURITY INCIDENTS

Introduction 1.8.0.1. Maintaining ICT security is a continuing task. It involves implementing mechanisms to protect information and system resources. The ICT areas that require security maintenance include:

• confidentiality – ensuring that information is not accessed by unauthorized persons; • integrity – ensuring that information is not altered without authorization; • availability – ensuring that information and services are accessible when required by authorized users; • authentication – ensuring that users are the persons they claim to be; and • access control – ensuring that users access only those resources and services that they are entitled to access and that qualified users are not denied access to services that they legitimately expect to receive.

Maintaining ICT security 1.8.1.1. Methods used to breach ICT security are continually changing with changes in Information Technology. Once ICT security measures are in place, it is important to maintain them to ensure they remain effective so that it needs to include:

• plans for the protection of the systems and information assets; • a means for the detection of incidents and vulnerabilities; and • the establishment of reaction mechanisms and processes to address and resolve issues and incidents. This involves: • keeping up to date with changing technology and security requirements; • performing regular integrity checks; • auditing security and implementing any changes required; and • identifying breaches of security, responding to them and documenting lessons learnt for future reference.

Compliance with security policy 1.8.1.2. Effective security management also involves a regular review of compliance with the ICT Security Policy, Risk Assessment and System Security Plan.

35



Managing Change The Need for Change 1.8.1.3. The following are indications of a need for change:

• users identifying problems or enhancements; • vendors notifying of upgrades to software or hardware; • awareness of a new threat or vulnerability; • interconnection to another system; • advances in technology in general; • implementing new systems that require changes to existing systems; and • identifying new tasks that require updates or new systems.

Change Management Standards

1.8.1.3.1. PNP Units SHOULD ensure that:

• a change control management system is established; • the change management process defined in the relevant security documentation is followed; • the proposed changes are approved by the relevant authority,

preferably • any proposed changes that could impact the security of the ICT System are submitted to the Accreditation Authority for approval; and

• all associated system documentation is updated to reflect the changes. This policy applies equally to urgent changes. The change

management process SHOULD define appropriate actions to be followed before and after urgent changes are implemented. For higher classified systems more stringent controls SHOULD be in place.

Change Process Types of System Changes 1.8.1.4. A proposed change to a system environment could involve an upgrade to system hardware or application software, the addition of an extra terminal, or major changes to system access controls.

Change Process 1.8.1.4.1. The Recommended Change Process is described in the following stages:

36



System User, ITSSO/CTSSO Stage 1: produce a written request

Stage 2: Submit the request for approval Stage 3: Test and implement the approved changes ITSSO/CTSSO Stage 4: Update the system documentation and the relevant security

documentation to include the following: • Risk Assessment;

• SSP; and • SOPs.

Stage 5: Notify and educate users of the changes that have been implemented. Stage 6: Continually educate users in regards to ICT changes. Detecting Security Incidents What Constitutes a Breach of Security? 1.8.1.5. In ICT, a breach of security is an event that impacts the confidentiality, integrity or availability of a system through an act of unauthorized access, disclosure, modification, misuse, damage, loss or destruction. Standard 1.8.1.6. PNP Units MUST develop, implement and maintain tools and procedures derived from risk assessment covering the detection and handling of potential security incidents, incorporating the following:

• countermeasures against malicious code; • intrusion detection systems; • audit analysis; • system integrity checking; and • vulnerability assessments

See: • Countermeasures Against Malicious Code, p.71

• Intrusion Detection Systems, p.85 • Audit Logs and Analysis, p.85 • System Integrity, p.89 • Vulnerability Analysis, p.89

37



User Awareness 1.8.1.7. Well-trained and security aware personnel may notice potential security incidents rather than software tools. See: User Training and Awareness, p.50 Effectiveness of Tools 1.8.1.8. Automated tools are only as good as the level of analysis that they perform. If tools are not configured to assess the areas of high risk in a system configuration, then it will not be evident when an irregularity emerges. The effectiveness of these tools will be reduced if they are not regularly updated to include knowledge of new exploits or attack profiles. Implementation of Tools 1.8.1.9. Implementation of software security tools should always conform with the goals laid out in the ICT security policy and SSP, which in turn have derived information from the risk assessment. An appropriately configured and managed Intrusion Detection System will present a security administrator with more options to mitigate identified risks. 1.8.1.10. Managing Security Incidents Reporting 1.8.1.10.1. PNP Units MUST direct personnel to report security incidents through the appropriate management channels soon after the incident is discovered. Guidelines 1.8.1.10.2.

• staff should note and report any observed or suspected security weaknesses in, or threats to, systems or services; • create an incident response team, which may be a secondary role; • establish and follow procedures for reporting software malfunctions; • put mechanisms in place to enable the types, volumes and costs of incidents and malfunctions to be quantified and monitored; • deal with the violation of organizational security policies and procedures by employees through a formal disciplinary process; and • have a centralized network time source so that disparate logs may be corroborated.

38



Recording Incidents 1.8.1.10.3. PNP Units SHOULD ensure that all security incidents are recorded in a register to highlight the nature and frequency of the incidents and breaches so that corrective action may be taken. This record of ICT security incidents and breaches contained in the register can be used as reference for future risk assessments.

Handling Data Spillage

1.8.1.10.4. Data spillage occurs when – by faulty labeling, incorrect transfer, system failure, or similar process – data actually or potentially becomes accessible to persons not cleared or briefed for access to it. In all cases of spillage, PNP Units SHOULD assume that the information has been compromised. Standard procedures for all personnel with access to the system SHOULD include the requirement to notify the ITSSO of any data spillage or access to any data classified above that for which they are authorized. Treatment of any such spillage MUST be as an incident, and follow the Incident Response Plan to deal with it.

Handling Malicious Code Infection 1.8.1.10.5. DICTM Recommends that PNP Units follow the steps below in handling detected malicious codes:

Step 1: Isolate the infected computer or network;

Step 2: Scan all connected systems, and any media used within a set period leading up to the incident (including backups), for malicious code.

Step 3: Isolate any other infected systems and/or media to prevent re– infection.

Step 4: Use up–to–date anti–virus software to remove the infection from the systems and/or media. If this fails, seek advice from the vendor. Step 5: Consider need to change system and/or user passwords. Step 6: Report the incident in accordance with the incident response plan.

Allowing Continued Attacks 1.8.1.10.6. The ITSSO may decide to allow an attacker to continue some actions under controlled conditions for the purpose of seeking further information or evidence. Units considering this approach SHOULD seek legal advice well in advance.

39



Integrity of Evidence 1.8.1.10.7. It is important that the integrity of evidence such as manual logs, automatic audit trails and intrusion detection tool outputs be protected even though in most cases an investigation may not lead to prosecution.

1.8.1.10.8. The following SHOULD be done: • transfer a copy of raw audit trails onto media such as CD–ROM or DVD–ROM for secure archiving, as well as securing manual log records for retention; and • ensure that all personnel involved in the investigation maintain a record of actions undertaken to support the investigation. Units should also consider the format of logs and their readability into the future as well as the permanence of the media upon which the logs are written.

40



CHAPTER 9 – REVIEWING ICT SECURITY

Introduction 1.9.0.1. This chapter explains the essentials and the process for ICT Security reviews. Contents 1.9.0.2. This chapter contains the following topics:

1. ICT Security Reviews 2. Process for Reviewing ICT Security

ICT Security Review

1.9.1.1. A review of ICT security is required:

▪ as a result of some specific incident;

▪ due to a change to a system, its use or its environment that significantly impacts on the security architecture and policy; ▪ when considering connection to another system or network; or ▪ as part of a regular or scheduled review.

Frequency

1.9.1.2. The DICTM RECOMMENDS that PNP units review all aspects of ICT Security at least annually. Some aspects may however, need to be reviewed more frequently. The following SHOULD be covered:

Security documentation: Review and update the following as necessary:

▪ Risk Assessment; ▪I CT Security Policy; ▪ SSP; and ▪ SOPs

Operating environment: Review when:

▪ a threat emerges or when there are changes; ▪ there are gains or loses of function; and ▪ operation of functions is moved to a new physical environment

Procedures: Review after an incident or test exercise. System Security components: Review items that may have effect on the

41



security of the system on a regular basis. Example: cryptographic device.

Waivers: prior to the identified expiry date. Who conduct a review?

1.9.1.3. The ITSSO and the CTSSO. The DICTM RECOMMENDS a process of peer review be undertaken where practicable. Follow-up after reviews

1.9.1.4. The DICTM RECOMMENDS that ITSSO and the CTSSO conduct a follow-up process to ensure that security deficiencies identified during security reviews have been effectively resolved. Process for Review of ICT Security 1.9.2.1. Basis: Security reviews SHOULD be based on comprehensive, current and reliable information. 1.9.2.2. Elements: The structure can be broken into set of elements.

▪ Security Risk Management for the whole PNP might be best approached by a review of each program. ▪ For particular program, review could be approached by PROs or division levels. ▪ For particular building or installation, review approach could be by PROs, MPOs, CPOs, Stations, or type of users, separately.

1.9.2.3. Gathering Information: Depending on the scope and subject of the review, the DICTM RECOMMENDS that the ITSSO/CTSSO gather information about areas such as:

• PNP priorities; • Program requirements; • threat data; • consequence estimates; • effectiveness of existing countermeasures; • other possible countermeasures; and • best practices. Information may be gathered from: • the DICTM; • the ITMS; • the CES;

42



• other system administrators and users. 1.9.2.4. Process: PNP ICT Security Reviews SHOULD follow the core PNP ICT Security Process with reference to the existing site and system documentation. See: The High–Level Process of ICT Security, pp.16, 17

43



PART 2 – ICT SECURITY STANDARDS

Introduction

Part 2 contains ICT Security standards, principles and regarding specific aspects of ICT systems, such as hardware, software and access control.

Contents

Part 2 contains the following chapters:

Chapter 1 – Physical Security

Chapter 2 – Personnel

Chapter 3 – Product Lifecycle

Chapter 4 – Hardware Security

Chapter 5 – Software Security

Chapter 6 – Logical Access Control

Chapter 7 – Intrusion Detection

Chapter 8 – Communication Security (COMSEC)

Chapter 9 – Cryptography

Chapter 10 – Network Management

Chapter 11 – Data Transfer

44



CHAPTER 1- PHYSICAL SECURITY

Introduction 2.1.0.1. This chapter provides the standards in developing physical security environment for ICT systems in the PNP. Contents 2.1.0.2. This chapter contains the following topics: 1. Fundamentals of ICT Physical Security 2. Environment testing 3. Protection of office areas 4. Protection of Servers and Communication Equipments 5. Protection of workstations and media 6. Physical Security Incidents 7. Emergency Procedures

Fundamentals of ICT Physical Security

2.1.1.1.Based on standards, the physical security for PNP ICT SHOULD basically consist: ▪ a physical perimeter enclosing the entire site;

▪ a more restrictive area separated from general user areas, containing the servers and communications equipment; and ▪ the protection of the facility by appropriate physical security measures.

2.1.1.2 Storage Requirement Classified media, including equipment containing classified media, MUST

be stored in accordance with the existing policies for Security requirements for the storage of hardcopy materials. The minimum standard of security container or secure room required is set out as follows:

Confidential: can be secured using the normal building security and door access control systems employed to keep the public out of administrative areas of PNP offices.

Secret: In an office environment, this material should be secured in storage area or cabinet with locks. In a storage facility, this material should be protected through controlled access to the storage areas and through a secure physical environment.

45



2.1.1.3. Unclassified System PNP units SHOULD implement measures to protect all equipment from theft and damage. If equipment containing unclassified information is stolen or damaged, work and services could be hampered while equipment are being repaired or replaced. If the information contained in the equipment is unique, whether it be replaceable or irreplaceable the PNP would suffer the consequence with great expense. 2.1.1.4. Risk Review For units with higher risk environment and where circumstances in its operation requires additional physical security measures, existing appropriate physical security measures for PNP installation/building/ environment in which it is operating SHOULD apply. The strategic and operational requirements of the facility SHOULD be included in the Risk Assessment of the unit to identify and assess the site-specific risks associated with its operation.

Environment Testing 2.1.2.1. With regard to environmental security of PNP units’ ICT assets, the DICTM SHOULD provide the following services: ▪ security advice; and ▪ physical security risk reviews. The ITMS and the CES SHOULD provide the following services: ▪ equipment and facilities TEMPEST testing; ▪ Communications Security (COMSEC) installation and Technical Security (TECSEC) inspections; 2.1.2.2. Site-Specific Advice PNP units SHOULD contact the DICTM, the ITMS or the CES as appropriate, for advice:

▪ If any of the measures in this chapter are not possible for site-specific reasons; and

▪ prior to the design and construction of a secure room or facility. Protection of Office Areas 2.1.3.1. PNP units SHOULD implement measures to protect all workstation equipment and components against theft regardless of whether they process classified material. Workstations and unencrypted network infrastructure SHOULD be wholly contained within areas that

46



have controlled access during the day and are appropriately protected after working hours. 2.1.3.2. PNP units SHOULD prevent unauthorized people from observing ICT equipment, and in particular displays and keyboards. This is to protect sensitive material from oversight and the compromise of usernames and passwords. The DICTM RECOMMENDS that PNP units: a. fix net curtains, blinds or drapes to windows, and b. position screens and keyboards so that they cannot be seen by unauthorized people, or c. install partitions. Protection of Servers and Communications Equipment 2.1.4.1. Administrative Measures The Site Security Plan and Standard Operating Procedures developed for the server room MUST be included in the SSP and SOPs for the system and systems within it. The following subjects SHOULD be identified:

• a summary of the site’s risk assessment; • security roles and responsibilities of the facility and ICT staff; • the administration, operation and maintenance of any electronic and communications access control and alarm systems; • site access controls, including key management and access lists; • staff clearances, security awareness training, and regular briefings; • inspection of the audit trails and logs; • end of day checks and lockup; and • reporting of security incidents and breaches.

Protection of Workstations and Media 2.1.5.1. Definition: Removable media is storage media that can be easily removed from an ICT system and is designed for removal. Examples: ▪ Hard disks ▪ CDs/DVDs ▪ Floppy disks ▪ Tapes ▪ USB memory sticks

47



2.1.5.2. Protection of hardware PNP units SHOUD consider the following steps to harden ICT systems to prevent data being removed in an unauthorized manner:

• removing drives that are not required; • disabling USB ports; • restricting the deployment of CD/DVD burners; and • using cases that can be locked in some manner.

2.1.5.3. Protection of removable media If removable writable media is utilized in classified systems it MUST be:

▪ removed for after-working hours storage; and ▪ stored in a container appropriate for the maximum classification of the information processed on the system.

Other removable media (non-writable) MUST be stored in a container appropriate for the maximum classification of the information processed on the system. 2.1.5.4. Protection of laptops Even if laptop hard disks have been encrypted, DICTM RECOMMENDS that they are stored securely after working hours. The level of security required will depend on the maximum classification of the information on the laptop. At a minimum, these laptops require a locked commercial grade cabinet. Physical Security Incidents 2.1.6.1. ICT Resources incidents PNP Units MUST have policies, plans and procedures that address the management of physical security incidents to ICT resources and advise staff to report all physical security incidents, actual or suspected to the ITSSO and/or the CTSSO, whichever is authorized/responsible. Example:

• unauthorized access to equipment and cabling; • detection of unauthorized equipment both covert and overt; and • failures in security mechanisms, which may have allowed unauthorized access.

Emergency Procedures 2.1.7.1. Emergency Situations may occur in any ICT Physical Structure and environment. The DICTM RECOMMENDS that PNP units appropriately orient or brief ICT staff of the existing SOPs regarding PNP

48



Equipment Evacuation Priorities and procedures during emergency situation, which covers:

a. securing of classified material and equipment, and b. sanitization or destruction of classified material and equipment.

Note: The DICTM advices that the preservation of life, health and safety be regarded as the first priority at all times.

49



CHAPTER 2 – PERSONNEL

Introduction

2.2.0.1. This chapter contains information on user education, personnel clearances and briefing requirements.

Contents

2.2.0.2. This chapter contains the following topics:

1. User training and Awareness

2. Training Resources 3. Clearances and Briefings

User Training and Awareness 2.2.1.1. The PNP, through the DICTM, ITMS and CES provides various user training and awareness programs to help users: understand and support ICT security requirements; become familiar with their roles and responsibilities; and learn how to fulfill their security responsibilities. 2.2.1.2. Training responsibility The ITSSO and the CTSSO are responsible for ensuring that an appropriate information system security training program is provided to staff. 2.2.1.3. Security Education PNP units SHOULD ensure that all personnel who have access to their ICT systems have sufficient trainings. They SHOULD provide ongoing ICT security awareness for the staff on topics such as responsibilities, security risks and measures. 2.2.1.4. Degree of Security Training The degree and content of user security training SHOULD be aligned to user responsibilities. The DICTM RECOMMENDS that security training includes, at a minimum, information on:

a. the purpose of the training or awareness program, b. security appointments and roles, c. how to identify a security incident or event, d. contacts in the event of a real or suspected security incident, e. the acceptable use of system accounts,

50



f. what constitutes unacceptable use of system accounts, g. configuration control, h. access and control of system media, i. the security of accounts, including sharing passwords, j. authorization requirements for applications, data and databases, and k. the destruction and sanitization of media and hardcopy output.

2.2.1.5. Promoting User Awareness The DICTM RECOMMENDS that PNP units promote user awareness of ICT security through the implementation of security policies and with the use of several methods such as: logon banners, system access forms and unit bulletins or memoranda. Training Resources 2.2.1.6. Following identifies potential topics and resources for training of: Commanders

• appreciation of computer security issues; and • security problems and solutions. May be derived from DICTM seminars and awareness briefings and manuals.

ICT System and Security Officers/Administrators

• specialist training in implementing and monitoring systems; and • security features of the systems

May be acquired from: ▪ formal courses from the ITMS/CES; ▪ third party vendors; ▪ ICT manuals; ▪ CICT, NCC, NTC, Security forums; and ▪ other user groups

ICT Users • general and specific security requirements;

• potential risks and countermeasures; and • system implementation May be derived from awareness courses and customized training programs provided by the ITMS and the CES; and • external training organizations

ICT Security Trainers

• general and specific security information that may be derived from customized training programs/briefings provided by the ITMS and the CES.

51



PNP ICT Security Awareness Training Programs 2.2.1.7. ICT Training Programs are integrated in the DICTM Program Thrust CY 2010. This includes ICT security awareness program for managers, administrators and users.

Disclosure of information while on courses

2.2.1.8. PNP units SHOULD remind their personnel attending courses, especially those sponsored by other organizations or when there is a presence of non-PNP personnel, not to disclose any information that could compromise PNP or their offices’ security.

Clearances and Briefings

2.2.2.1. Policy

The PNP policy for granting and maintaining security clearances as set out by the Directorate for Intelligence (DI) SHOULD be adopted for ICT in the absence of a clear policy for the granting of security clearance for ICT. PNP units MUST specify the level of security clearance and any briefings required for each type of user in the SSP.

2.2.2.2. Clearances and Briefings Requirements

The System Security Plan (SSP) SHOULD contain the requirements for clearance and briefings for access/accounts granted to staff, including contractors, and privileged access. 2.2.2.3. Responsibilities PNP Units MUST ensure users have the appropriate clearance and “need-to-know” before they are allowed to access a system. PNP Units SHOULD ensure that user accounts are:

a. correctly maintained, b. are provided with least privilege required, and c. disabled when the user ceases to have access rights to the system, for instance when they retire, resign, transferred or reassigned to other roles which does not require access to the system.

2.2.2.4. Users with privilege access are called privilege users. Definition: Privileged Access is defined as access which may give the users:

• the ability to change key system configurations including security settings in operating systems or security appliances; • the ability to change control parameters, Examples: Routing

tables, path priorities, addresses on routers, multiplexers, and other key system equipment;

52



• access to audit and security monitoring information; • the ability to circumvent security measures; • access to data, files and accounts used by other users, including backups and media; and • special access for troubleshooting the information system.

Clearances for Privilege Users 2.2.2.4. The DICTM RECOMMENDS evaluating privileged users to a level one classification above the classification of the system(s) to which they have privileged access. Example: A system administrator on a RESTRICTED system could be vetted to CONFIDENTIAL.

If there are frequent transfers of data from a more highly classified system on to a lower classified system, then the DICTM RECOMMENDS that at least one system administrator on the lower system is cleared to the classification of the higher system. Clearly, only data classified at the lower level may be moved to the lower classified system. Example: If a RESTRICTED system frequently has data transferred to it from a CONFIDENTIAL system then clear at least one of the system administrators on the RESTRICTED system to CONFIDENTIAL. This however, should not be interpreted as an endorsement of movement of data from a higher classified network to a lower classified network. See: Data Export to less Classified System, p.123

53



CHAPTER 3 – ICT PRODUCT LIFECYCLE

Introduction 2.3.0.1. This chapter contains information on selection, acquisition, installation and operation of Evaluated Products. Contents

2.3.0.2. This chapter contains topics on:

1. Evaluated Products 2. Product Selection 3. Acquiring Products 4. Installing and maintaining Software Products 5. Data Migration and Archiving

Evaluated Products 2.3.1.1. Evaluated product is a product that has been evaluated and subsequently certified under the Common Criteria (CC) or Information Technology Security Evaluation Criteria (ITSEC) in a recognized scheme. A recognized scheme is a scheme which is a member of the CC Recognition Agreement (CCRA). The CC is recognized as an international standard: ISO 15408, while the ITSEC is being used for some high-assurance evaluation.

Advantages of using Evaluated Products 2.3.1.2. Evaluated Products provide a level of assurance to consumers that the security functionality of the product operates as claimed by the developer in the Security Target. Evaluation does not offer a guarantee of security but does allow a much greater level of trust that the product works as claimed and that the documentation and support provided are adequate to maintain the product’s security over its lifetime. Assurance be best achieved when using Evaluated Products by configuring them in accordance with the Security Target.

Product Selection

2.3.2.1. Policy Purchase and acquisition of ICT equipment for the PNP SHOULD comply with the PNP ICT Equipment Standardization Policy in consonance with the policy set forth by the Uniform Equipment Standardization Board

54



adopted and being implemented by the DICTM for the PNP. If selected product contains cryptography to enforce security functionality, PNP units SHOULD verify that it uses cryptographic algorithms approved by appropriate agency.

Acquiring Products 2.3.2.2. Delivery of ICT Products The DICTM RECOMMENDS that PNP Units, ensure that all ICT products are delivered in a manner that provides confidence that they have received the product they expected and that it has not been tampered.

2.3.2.3. Delivery of Evaluated Products PNP Units SHOULD ensure that Evaluated Products are delivered in a manner that is consistent with the certified delivery procedures.

2.3.2.4. Leasing Arrangements PNP units SHOULD ensure that leasing agreements for ICT equipment

take the following into consideration: a. difficulties that may be encountered when the equipment requires

maintenance, b. sanitization of the equipment prior to its return, and c. possible requirement for destruction of the equipment if sanitization cannot be performed.

Installing and Maintaining Software Products Installing and Configuring Evaluated Products

2.3.4.1. PNP units SHOULD ensure that Evaluated Products are installed and configured in a manner consistent with the approved configuration.

Use of Evaluated Products in Unevaluated Configurations 2.3.4.2. An Evaluated Product is outside of its evaluated configuration if:

• functionality used was not within the scope of the evaluation; • functionality is not implemented in the specified manner; • patches are applied to resolve “bugs”; or • the environment does not comply with the assumptions or security policies stated in the product’s Security Target.’

Products that have a High Grade level of assurance MUST NOT be used in unevaluated configurations. If an Evaluated Product is intended to use in an unevaluated configuration the ITSSO/CTSSO SHOULD assess the risks, taking into consideration:

55



a. the necessity of the functionality or patch, b. the testing of the functionality or patch, and c. the environment in which the product is to be used.

Operation of Evaluated Products 2.3.4.3. PNP Units SHOULD ensure that products are operated and administered in accordance with the user and administrator guidance. This guidance is generally available from the developer.

Patching and Hardening Products

2.3.4.4. PNP Units SHOULD monitor relevant sources of information about new vulnerabilities, patches and hardening methods in software and hardware used by the unit. Corrective action SHOULD be undertaken by the ITSSO/CTSSO when vulnerabilities that could affect their systems are discovered. They SHOULD consider the affect on the risk assessment when determining what action to take. The ITSSO/CTSSO SHOULD follow the documented change process when applying patches or hardening systems.

Data Migration and Archiving 2.3.5.1. Protection of Data during Migration

Information is at its most vulnerable from compromise when it is migrated from one system to another. Procedures SHOULD be developed in advance that ensure any temporary transfer media is:

a. labeled and handled as for the highest classification being transferred, and b. accounted for at all times until it is sanitized or destroyed.

PNP Units SHOULD have two–person control when migrating highly sensitive information between systems.

2.3.5.2. Logical Access Control

System access controls SHOULD be migrated with information when it is transferred to a new system whenever possible. When not possible, alternative arrangements MUST be put in place to prevent unauthorized access to the information in the new system. For instance, the new system may need to operate in a different mode until the logical access controls are implemented.

2.3.5.3. Maintaining Access and Access Controls

Information in storage MUST be protected from unauthorized access when it is migrated or archived. In some cases, information may have the classification downgraded or removed once it has reduced in sensitivity. Any such action MUST be approved by the office/department that

56



originally classified the information. If encrypted information is archived or migrated, the keys and mechanisms to decrypt it will also need to be retained or converted to the new system.

57



CHAPTER 4- HARDWARE SECURITY

Introduction 2.4.0.1. This chapter contains information on the handling, maintenance and disposal of hardware.

Definition: Hardware Hardware is a generic term for the physical components of computer or electronic equipment, including peripheral equipment.

Definition: Media

Media is a generic term for the components of hardware that are used to store information. The information storage may be short or long term. Media can be: • fixed or removable, and • volatile, which loses its information when power is removed, or non– volatile, which retains its information when power is removed.

Contents 2.4.0.2. This chapter contains the following topics:

1. Classifying, Labeling and Registering 2. Repairing and Maintaining Hardware 3. Disposing of Hardware

4. Media Sanitation 5. Media Destruction 6. Portable Computers and Personal Electronic Devices

Classifying, Labeling and Registering Hardware 2.4.1.1. Definition: Media Declassification Declassification is an administrative decision to remove the classification

from an item of media, based on an assessment of relevant issues including:

a. the effectiveness of any sanitation procedure used, b. the intended destination of the media, and c. the consequences of damage from disclosure or misuse. Example: Declassifying a PC before selling it.

58



2.4.1.2. Definition: Media Reclassification Reclassification is an administrative decision to change the classification of an item of media, based on an assessment of the relevant issues. Example: Reusing previously CONFIDENTIAL media in a RESTRICTED environment. Classifying Hardware 2.4.1.3. Hardware MUST be classified at or above the classification of the media contained in it until the media is either removed or de/reclassified.

Classifying Media 2.4.1.4. Non–volatile media (for example, magnetic disks and memory cards) MUST be classified to the highest classification stored on the media since any previous declassification or reclassification.

Classifying Volatile Media 2.4.1.5. Volatile media that has a continuous power supply MUST be classified to the highest classification stored on the media while the power is on. Volatile media that does not have a continuous power supply may be treated as Unclassified once the power is removed from the media. Labeling Hardware and Media 2.4.1.6 All classified media MUST be labeled with the appropriate classification. Exception: Internally mounted media does not need to be labeled, but the hardware containing the media MUST be labeled instead. The DICTM RECOMMENDS that, where possible, media be labeled so that the classification is visible when the media is mounted in the unit in which it is used and when it has been removed.

Registering Media and Equipment 2.4.1.7. All removable media and equipment containing CONFIDENTIAL or above information SHOULD be registered with a unique identifier in an appropriate register.

Hardware Repair and Maintenance 2.4.2.1. On-Site Repairs

Repairs and maintenance for hardware containing security classified media SHOULD be carried out on–site by appropriately cleared and briefed personnel.

59



2.4.2.2. Off–site repairs If the media contained within the hardware cannot be removed or declassified then the hardware MUST be escorted or repaired at a facility rated to at least the classification of the media. The hardware this UNCLASSIFIED may be repaired off-site at the unit’s discretion provided due care is taken to protect official information. The hardware that is CONFIDENTIAL, RESTRICTED OR SECRET may be repaired by a company approved by the PNP unit for that purpose or any other company if the hardware is escorted at all times by an appropriately cleared and briefed escort and due care is taken to ensure that official information is not compromised.

Disposing of Hardware

Standards 2.4.3.1. Based on Standards PNP, as other government agencies, MUST NOT dispose of hardware containing classified information; the media must be first sanitized or destroyed using an approved method. PNP Units SHOULD NOT dispose of hardware containing information marked as Unclassified until it has been authorized for public release. The DICTM RECOMMENDS sanitation or destroy of all media before it is released, regardless of the classification of the information processed on it.

Faulty Media and Hardware 2.4.3.2. Where media that has held classified information cannot effectively be accessed due to faults in the hardware or the media itself, PNP Units MUST:

a. repair the equipment and then sanitize it, or b. maintain the media at its highest classification, or c. destroy the media in accordance with the PNP’s approved

method of disposal. Disposal Process 2.4.3.3. PNP units MUST have a documented process for the disposal of

hardware. The process RECOMMENDED by the DICTM is described below.

Step 1: If the hardware contain any storage media proceed to Step 2, if not, go to Step 6. Step 2: Determine whether the media should either be sanitized or destroyed, and the most appropriate method of doing so. Step 3. Seek approval for the chosen sanitation or destruction

process from the information owner and the ITSSO or CTSSO. This approval may be in the form of an authorized

60



Security SOP. Step 4: Apply the agreed sanitation or destruction process to the

media. Step 5: Verify that the media has been satisfactorily sanitized or

destroyed. If yes, go to step 6. If no, return to step 2. Step 6: Remove all labels indicating, for instance, the higher

classification and owner. Step 7: Update any relevant documentation and registers. Step 8: Dispose of the hardware.

Media Sanitation

2.4.4.1. Definition: Media sanitization is the process of erasing or overwriting data stored on media. The process of sanitization does not automatically imply that the media can be declassified or reclassified. 2.4.4.2. Requirements PNP Units MUST use an approved declassification or reclassification method whenever media is moved from a higher classification to a lower classification environment. The DICTM RECOMMENDS that PNP Units sanitize all media prior to reuse in a new environment, even when the new environment operates at the same or a higher classification. However, where the new classification of the media will be equal to or higher than the previous classification, a basic form of sanitation will be adequate, for example, formatting magnetic media or clearing Erasable Programmable ROM. 2.4.4.3. Media that cannot be Reclassified or Declassified. The following media types do not have approved sanitation methods, so cannot be reclassified or declassified and MUST be destroyed prior to disposal if they contain or may have contained classified information:

• microfiche and microfilm; • optical disks, including CDs and DVDs and all variations including those that are classed as ‘re–writable’. • printer ribbons and the associated impact surface; and • Read–Only Memory (ROM) and Programmable ROM (PROM).

2.4.4.4. Declassifying and Reclassifying Magnetic Media In declassifying or reclassifying magnetic media up to CONFIDENTIAL, PNP Units MUST use either the overwriting or degaussing techniques defined below.

61



2.4.4.5. Sanitizing Magnetic Media by Overwriting Overwriting is the technique of using a software utility to write patterns or random data to all locations on media to obscure any information stored on it. Utilities that perform a single pass, writing to every location on the media, whether it is in use or not, are suitable for reclassifying or declassifying CONFIDENTIAL, SECRET and RESTRICTED media. The utility SHOULD verify that the entire surface was overwritten successfully. Overwriting utilities that just overwrite the unused sectors on the media, and leave undeleted files and directories in place, do not provide the same level of assurance as those that overwrite the entire media surface and therefore, SHOULD NOT be used for declassification purposes.

2.4.4.6. Sanitizing Magnetic Media by Degaussing

Degaussing is the process of applying a magnetic force to remove information from magnetic media. A degausser is a hardware that, when switched on and placed close to or surrounding the media to be sanitized, induces a magnetic field around the media that causes the media to be zapped. Warning!: Degaussing can damage disk drive motors and remove timing marks and low level formatting, which can make the media unusable after the degaussing process. Additionally, the casing around hard disk drives can attenuate the magnetic field of the degausser, reducing the effectiveness of the procedure.

2.4.4.7. Sanitizing non-volatile memory To declassify or reclassify erasable non–volatile semi–conductor memory (e.g. Erasable Programmable ROM EPROM), Electrically Erasable PROM (EEPROM), Flash cards, Memory sticks) that has held up to CONFIDENTIAL information, erase as per the manufacturer’s specification but repeat the process three times.

2.4.4.8. Sanitizing Electrostatic Devices

To declassify electrostatic memory devices within printers and photocopiers (e.g. laser printer cartridges and photocopier drums) print at least six pages of unclassified text with each cartridge within the device. The text SHOULD cover the page and SHOULD NOT include blank spaces or solid colored areas.

2.4.4.9. Before Disposing of Video Screens

Before disposing of video screens, thoroughly inspect the screen by turning up the brightness to the maximum. If classified or secret information is etched into the surface of the screen, destroy it in accordance with Occupational Health and Safety standards.

62



Media Destruction

2.4.5.1. Definition: Media destruction is the process of physically damaging the media with the objective of making the data stored on it inaccessible.

2.4.5.2. Requirement

PNP Units MUST destroy all classified media prior to disposal using an approved method, as described within this section. This does not include media that has been declassified using an approved method as defined in Media Sanitation. Reasons for not declassifying media include: • no approved sanitization method exists; • a risk assessment identifies destruction as the preferred treatment; • the sanitation method cannot be applied due to defective hardware; or • the cost of sanitizing the media outweighs the benefits.

2.4.5.3. Methods

To destroy media, PNP Units MUST either: a) break up the media until the maximum size of the particles is 9mm or smaller by crushing with a hammer, mill or disintegrator, grinding or sanding, or cutting; or b) heat the media until it has either burnt to ash or melted.

2.4.5.4. Supervision of the Destruction Procedure

PNP Units MUST destroy classified media under the supervision of an officer cleared to the highest level of the media being destroyed. The officer MUST supervise the media to the point of destruction and ensure that the destruction is complete.

Portable Computers and Personal Electronic Devices

2.4.5.5. Definition: A Personal Electronic Device (PED) is defined as being any portable ICT device that can store, process and/or transmit data electronically. It does not include laptop or notebook computers. The significant difference between PEDs and portable computers is the lack of comprehensive security features in PEDs, including user identification, authentication, and auditing.

Examples of PED:

• Personal Digital Assistants (PDAs); • mobile phones; • two–way pagers;

63



• digital cameras; and • audio recorders.

2.4.5.6. Vulnerabilities of Portable Computers and PEDs The main areas of concern with portable computers and PEDs are:

• the inbuilt and removable storage media in these devices is vulnerable to unauthorized access or copying when they are used outside controlled areas; • their portability makes them attractive and easier to steal; • these devices are capable of transmitting and/or recording several hours of audio; • data can often be intercepted from a significant distance; and • they can be a path for malicious software to be introduced into government networks and systems, and for sensitive information to be extracted.

2.4.5.7. Security Policy Documentation

PNP Units that intend to use PEDs MUST include a section on their use and protection, in their ICT security policy documentation.

2.4.5.8. Policy

Portable computers and PEDs used to process CONFIDENTIAL, SECRET or RESTRICTED information MUST be protected appropriately for the level of information processed on them based on requirements for that level of hardcopy material. Personally owned portable computers and PEDs SHOULD NOT be used to conduct PNP operations or to connect to PNP’s internal ICT networks and systems unless through a strictly controlled gateway.

2.4.5.9. Formal Approval

PNP Units SHOULD have procedures in place to formally approve any portable computers and PEDs that may need to process classified information. PNP members SHOULD be made aware that unapproved devices are not to be used for processing such information.

2.4.5.10. Labeling and Physical Protection

Portable computers and PEDs MUST be protected to the same level as the information they process or contain as defined. They MUST be protected to this level until all media within them has been removed or declassified. They SHOULD only be operated in areas where the confidentiality and integrity of the visual or audible information can be assured. PNP Units SHOULD put a label warning against unauthorized use on all portable computers and PEDs. A contact telephone number or unit label SHOULD also be affixed to the equipment in case of loss.

64



2.4.5.11. Secure configuration

Before use, PNP Units SHOULD ensure that the operational configuration of portable computers and PEDs they purchased are appropriate for the classification of the information and the environment they will be used in. These devises normally have minimal security when purchased.

2.4.5.12. User Authentication

Utilize Password authentication as primary mechanism to stop an attacker from accessing the information on the device or loading malicious code. Ref.: Password Selection. 2.4.5.13. Encryption Definition: Encryption is the process of obscuring information to make it unreadable without special knowledge. In the government, encryption is used in protecting widely-used systems, such as Internet e-commerce and mobile telephone networks. Any portable computer or PED that contains classified information and is permitted to be taken out of controlled areas MUST have media encryption. Personal Digital Assistants

2.4.6.1. Use of PDAs

The use of PDAs is determined by the maximum classification of the information that will be accessed, collected, processed or stored by the PDA, and by the security classification of any other ICT devices or systems that the PDA will connect to and exchange information with. PDAs SHOULD NOT be used in high-threat areas to process official information. PDAs MUST NOT be used in areas where CONFIDENTIAL, SECRET or TOP SECRET information is collected, stored or processed. PDAs are considered to be remote access devices and MUST NOT be directly connected to any PNP system that collects, processes or stores information above the UNCLASSIFIED level.

2.4.6.2. PDA Modes

PDAs have the ability to operate in stand alone (Internet) mode and Server (Enterprise) mode.

2.4.6.3 Stand alone mode

In this mode a server does not enforce usage policy on the PDA. The user can typically connect to the internet and has the option of connecting to other PDAs (peer-to-peer operation) via wireless connections such as Bluetooth, Infrared, etc. Security features of the device such as password

65



logon, auto power off and storage encryption are enabled at the discretion of the user.

2.4.6.4. Server Mode In this mode the PDA has usage policy enforced on it via a server, and can only be operated in conjunction with that server. The user cannot override the security features enabled on the device. Connectivity options are also set by the policy enforced by the server and these cannot be overridden by the user.

2.4.6.5. Risks of PDA Usage

Any PDA may be subject to the following risks:

• PDAs can be subject to sustained attack without user knowledge when in ‘always on’ mode; • PDAs typically rely on cellphone technology to transmit and receive information. Weaknesses with this technology make the use of PDAs subject to an elevated level of risk; • PDAs emit high-frequency electromagnetic radiation and can be considered a TEMPEST risk, particularly when used in a ‘hot-sync’ cradle or operated in areas of poor cell phone coverage; • All email sent to or from a PDA may transit servers using the internet. This risks exposure of the transmitted information to unintended parties and creates a vulnerability to Denial of Service attacks; • Depending on the model of the PDA, all data stored on the device may remain unencrypted; • In Server mode encryption may operate only between the PDA and the local server and not be extended over the Internet; • The device can be used in ‘peer-to-peer’ mode without any specific security mechanisms being in place to protect the information stored on the PDA; • PDAs can be configured by default as “Java-enabled” which gives users the ability to download any software onto the handset without the requirement for virus and malware checking.

2.4.6.6. Basic Requirements for all PDAs in PNP Use

All PDAs used in PNP, MUST conform to these specifications: 1. The PDA MUST be PNP supplied. Personally owned PDAs MUST NOT be used for PNP operation.. 2. The PDA SHOULD be clearly labeled as Property of PNP. 3. The PDA MUST be configured to require a power-on password. 4. The PDA MUST have a good quality (i.e. complex) power-on password enabled. 5. Any PDA connected to the Internet, or to another ICT device or system

66



(including other PDAs) MUST have PNP approved anti-virus and anti- malware software enabled. This software MUST be updated at least weekly. These devices SHOULD also have PNP-approved personal firewall software installed and regularly updated. 6. PDA ‘hot-sync’ connections to a PNP LAN SHOULD NOT be allowed,

unless they are via an approved secure gateway. 7. The PDA SHOULD be capable of operating in Server mode. 8. When operating in Server mode, the security settings of the PDA MUST NOT be able to be overridden by the user, and deny the ability to reset to ‘factory default settings.

2.4.6.7. Additional Requirements for PDAs used above the

UNCLASSIFIED level 1. PDAs operating above the UNCLASSIFIED level MUST have

approved encryption enabled to protect information stored on the PDA. 2. PDAs operating above the UNCLASSIFIED level MUST NOT allow any removable or other external storage device to be connected. 3. PDAs operating above the UNCLASSIFIED level MUST NOT have

cameras or sound recording devices enabled or allowed to be connected to the PDA by any method.

4. PDAs operating above the UNCLASSIFIED level MUST NOT allow any form of external connection to be made to the device, outside those specifically approved by the PNP, by any method including headphones and ‘hands-free’ kits.

5. PDAs MUST NOT be used to process or store information above the RESTRICTED level.

6. IR ports MUST be covered with metallic tape to completely prevent IR data transmission.

2.4.6.8. PDAs for UNCLASSIFIED Purposes

PDAs to be used at UNCLASSIFIED level are subject to these additional requirements:

• The PDA may be used in either stand alone or server modes; • Usernames, passwords and other information relating to more highly classified systems MUST NOT be stored on the PDA; • Information stored on the PDA MUST be protected as per the requirements; • Regular audits and inspections SHOULD be conducted on the PDA by the Unit’s ITSSO/CTSSO; and • The PDA MUST NOT subsequently be used for more highly classified purposes without being checked for viruses and malware, or thoroughly sanitized by the Unit’s ITSSO/CTSSO.

67



2.4.6.9. PDAs to be used for CONFIDENTIAL Purposes PDAs to be used at the CONFIDENTIAL level are subject to these requirements in addition to those in 2.4.6.6. ”Basic Requirements”

• The PDA MUST only be used in server mode; • Internet Browsing SHOULD be disabled; • The PDA SHOULD NOT be used in high-threat areas; • The PDA MUST NOT subsequently be used for UNCLASSIFIED purposes, or in stand-alone mode, without being sanitized by the unit’s ITSSO/CTSSO; and • The PDA MUST have storage encryption enabled, with a high quality password (not the same as the PDA power-on password).

2.4.6.10. PDAs for SECRET and RESTRICTED Purposes

PDAs to be used at the SECRET or RESTRICTED level are subject to these requirements in addition to those in 2.4.6.6.”Basic Requirements” • Internet Browsing MUST be disabled; • The user MUST NOT be able to download and install software onto the device. • All email MUST transit via the approved server only. • All information, including email, travelling to or from the device MUST be encrypted using approved algorithm; • The PDA SHOULD NOT be used in high-threat areas; and • The PDA MUST NOT subsequently be used for UNCLASSIFIED or CONFIDENTIAL purposes, or in stand-alone mode, without being sanitized by the Unit’s ITSSO/CTSSO.

2.4.6.12. PDAs to be used above the RESTRICTED LEVEL

PDAs MUST NOT be used to access, process or store information classified above RESTRICTED. Any PDA that is found to contain material classified above RESTRICTED MUST be destroyed in line with related policies of the PNP and this document.

2.4.6.13. Server Requirements Where PDAs are to be used in server (enterprise) mode, the server system(s) and software operating on it MUST meet the following standards when the PDAs are to be used up to the RESTRICTED level:

• The system SHOULD be certified standard compliant; • The server MUST be resident within the PNP, or its designated

outsourced ICT agent; • The system MUST support and enforce all requirements for PDAs; • The system MUST enforce policy to the PDA devices in such a way that the user cannot override the security settings;

68



• The system MUST NOT allow the PDA to operate in stand-alone mode; • The system MUST either be able to send a ‘kill’ signal to the PDA, or be able to remotely wipe all information on the PDA and there must be a way to confirm that this has been successfully completed; • The system MUST be capable of preventing the user from downloading and installing software into their PDA; • The system SHOULD allow the user to remotely back-up information stored on their PDA to a secure location on the server; • The system MUST be capable of remotely resetting a user’s password; • The system MUST be able to prevent the user from sending and receiving email other than via the approved server; and • The system SHOULD be capable of supporting the use of Public Key Infrastructure (PKI).

69



CHAPTER 5- SOFTWARE SECURITY

Introduction

2.5.0.1. This chapter contains information about anti–virus protection, handling malicious code, securing software applications and security considerations during software development.

Contents 2.5.0.2. This chapter covers the following topics:

1. Operating System 2. Malicious Code and Anti-Virus Software 3. Software Applications 4. Software Development

Operating System 2.5.1.1. Risk Considerations Many aspects of ICT security rely on protection at the computer operating system level. Even the most secure operating systems become less secure over time through careless maintenance and as the methods and tools to attack them become more advanced. Therefore, PNP as any other agencies SHOULD make securing the operating systems of mission critical and classified systems an integral part of the development and operational phases of the system lifecycle.

2.5.1.2. Requirements

PNP Units SHOULD configure the operating systems on computers that process classified information with all: a. unnecessary services and networking removed or disabled, b. unnecessary programs, scripts, code, program development systems and administrative utilities removed, and c. current and tested security–relevant patches installed. Extra attention SHOULD be given to the configuration of computers that are connected to the Internet or have other external connections. 2.5.1.3. Service Packs and Patches Security–relevant patches and service packs SHOULD be kept up to date on all systems with external connectivity. Where possible the updates SHOULD be tested on a test or development system before being installed on the operation computers.

70



Malicious Code and Anti-Virus Software 2.5.2.1. Definition: Malicious Code is any software that attempts to subvert the confidentiality, integrity or availability of a system. Types of malicious code include: logic bombs; trapdoors; Trojan programs; viruses; and worms. 2.5.2.2. Methods of Infections Malicious code can be introduced into a system through several different ways, including:

• files containing macro viruses or worms; • e-mail attachments and web downloads with malicious active content; • executable code in the form of applications; • security weaknesses in a system or network; and • contact with an infected system or media.

Countermeasures against Malicious Code 2.5.2.3. Standards PNP Units MUST develop, implement and maintain a set of policies, plans

and procedures covering how to:

a) minimize the likelihood of malicious software being introduced into the system(s);

b) detect any malicious software entering or installed on the system(s); and

c) respond to any incidents resulting from malicious software. PNP Units MUST make their users aware of the policies, plans and procedures and ensure that all instances of detected malicious code outbreaks are handled according to the appropriate procedures.

2.5.2.4. Recommendations

The DICTM RECOMMENDS that PNP Units implement the following protective countermeasures for all information systems.

Security Awareness and User Education: a. Accept software and data from trusted sources only.

b. Educate and train all users in proper security techniques. Anti-Virus Scanners: All workstations, servers and gateways SHOULD: a. install an authorized anti–virus scanner;

71



b. regularly update virus signatures; and c. regularly scan all disks.

System Isolation:

a. use a gateway to restrict access from the Internet and remote systems;

b. progressively minimize connectivity according to the classification of the system;

c. use gateways within the network to isolate sensitive internal systems.

Active Content Blocking: a. use filters to block unwanted content,

b. use settings within the applications to disable unwanted functionality. d. use digital signatures to permit active content from trusted sources only.

Access Control Mechanisms:

Implement adequate access control mechanisms to prevent unauthorized user and program access to system files and resources.

Integrity Checkers: Use checksums to detect unauthorized modifications to critical

systems. The DICTM RECOMMENDS that the checksum database be held offline.

Recovering from Malicious Code Infections 2.5.2.5. Requirements for Content Recovery

The capacity to contain and recover from malicious code is primarily reliant on the ability to:

a. isolate the infected systems, b. purge malicious code from the infected systems, c. restore the integrity of the systems, and d. recover data from backup media.

2.5.2.6. Handling Malicious Code Infection A generalized procedure for handling malicious code infection is located in

‘Part 1 Chapter 8 – Maintaining ICT Security and Managing Security Incidents’

72



Software Applications Software Security Policy 2.5.3.1. All application server and client security mechanisms SHOULD: comply with the general standards outlined in this section, and be documented in the System Security Plan.

Security Standards

2.5.3.2. Below are descriptions of security components and their minimum general standards for software security mechanisms.

User Identification and Authentication All users MUST be uniquely identified and authenticated before access is given to PNP Unit’s systems and applications. In some situations, physical access controls may be used, but they SHOULD usually be supplemented with system identification and authentication.

Resource Access Control

All systems SHOULD be configured to control access to system resources and data based on each user’s needs and responsibilities.

Audit Logs and trails

Security significant events, based on risk assessment, SHOULD be logged.

Database Security 2.5.3.3. Data Labeling

PNP Units SHOULD label all database records with their classification and any other markings such as code words and caveats if the records:

a. may be exported to a different system, or b. have differing classifications and/or have different handling requirements.

In some situations it may be appropriate to label the entire database at a single classification, so that all information entered and extracted from it is assumed to be that classification unless explicitly labeled otherwise. In these cases, the default classification and handling requirements MUST be clearly identified to users.

73



2.5.3.4. Data base Files

The database’s files SHOULD be protected from access that bypasses the database’s normal access controls. This may be achieved by appropriate permission settings on directories and files at the operating system level.

2.5.3.5. Integrity and Availability

For all mission critical database applications, the database management system SHOULD: a. have transaction integrity and rollback capabilities to recover from

errors, and b. be covered by adequate procedures for recovery from data loss or

corruption. 2.5.3.6. Accountability

The database SHOULD provide accountability of users’ actions.

2.5.3.7. Search Engines Users that do not have access to a specific document or record SHOULD NOT see the metadata (e.g. the document title) in a list of results from a search engine query. Where users can see the titles of documents that they cannot access, the metadata SHOULD be appropriately sanitized.

Web Application Security 2.5.3.8. The objective of web security is to:

• protect the integrity of information submitted to, contained in, or retrieved from web servers; • protect the confidentiality of information in storage and transit; • ensure appropriate levels of user authentication; and • protect the availability of the system from malicious code attacks.

2.5.3.9. Server Handling Internet web servers MUST be hardened against network attack.

2.5.3.10. Communications Protection Approved cryptographic protocols, algorithms and crypto–modules SHOULD be used to provide privacy to the communications and authentication of the web server.

74



2.5.3.11. Website Content PNP Units SHOULD:

a. establish formal procedures to manage the publication and administration of material on their website(s);

b. review all active content on web servers for security issues; and c. Refer to DICTM Policy on Website Content for conformity.

2.5.3.12. Auditing and Access Control

PNP Units SHOULD: a. ensure that web servers available to the public are separated from the agency’s internal systems; b. keep user accounts for the operating systems to a minimum; and c. configure auditing Web Client Security This topic applies to all web applications that access HTML documents on Internet web servers. 2.5.3.13. Client Software Hardening PNP Units SHOULD harden and patch web client operating systems and the web browser software in addition to the controls below.

2.5.3.14. Anonymity and Privacy Problems A browser provides information to every site it visits. Privacy and security problems arise because the web server may keep details of the:

• IP address that requested the page; • URL accessed on the site; • user’s name or client browser’s identity; • amount of information transmitted to and from the site; • status of the request; • user’s e-mail address; • operating system of the browser’s host system; and • the URL of the referring page.

As well as potentially affecting personal privacy, this information could provide the external site private information about the agency’s internal network.

75



2.5.3.15. Cookies The DICTM RECOMMENDS PNP Units consider blocking external cookies, noting that such a decision may restrict the legitimate activity of the unit’s users.

2.5.3.1.6. Applications and Plug-ins

Web browsers can be configured to allow the automatic launching of downloaded files. This may occur with or without the user’s knowledge thus, making the computer vulnerable to attack. The DICTM RECOMMENDS PNP Units consider blocking the automatic launching of downloaded files, noting that such a decision may restrict the legitimate activity of the unit’s users.

2.5.3.17. Client-side Active Content

Client–side active content is software that enhances the user’s interactive functionality with the website. The software is automatically transferred from the web server to the user’s computer when the user visits the website. Example: Java The DICTM RECOMMENDS Units consider blocking client-side active content, noting that such a decision may restrict the legitimate activity of the unit’s users.

2.5.3.18. Users

PNP Units SHOULD ensure that users are informed of the dangers associated with using the Internet.

Electronic Mail Security

2.5.3.19. Electronic mail (e-mail) security controls are established to:

• protect the confidentiality of information on a need-to-know basis; • ensure an appropriate level of user authentication; • ensure an appropriate level of e-mail integrity; and • protect the system from malicious code attacks.

2.5.3.20. The main components of an e-mail system are: • the mail server: Software that receives, routes and stores e-mail messages from clients and other servers; • mail clients: Software run by users to view messages and attachments; • messages: The content of the e-mail, either in raw text, HTML or XML, including any attachments; and • attachments: Files included with the messages.

76



2.5.3.21. Minimum Standards PNP Units MUST adhere to and maintain e-mail policies, plans and procedures set by the DICTM and those specifically derived from risk assessment, covering topics such as:

a) information that may and may not be passed within and outside of the organization; b) use of encryption; c) content checking and privacy; d) accountability and auditing; e) private use of e-mail; and f) make their users aware of the PNP’s e-mail policies, plans and procedures.

2.5.3.22. Guidelines

PNP Units SHOULD harden and patch e-mail servers and clients ensure that e-mail servers available to the public are separated from the PNP’s internal systems, disable e-mail relaying, not allow users operating system level access to e-mail servers: a. scan inbound and outbound e-mail, including any attachments for:

i) malicious code, ii) content in conflict with the PNP’s e-mail security policy, and

b. configure auditing to produce logs, and analyze the logs for any security issues. See: Operating Systems, p.87

2.5.3.23. E-mail Gateways

The DICTM RECOMMENDS that PNP Units route Internet e-mail through a centralized e-mail gateway.

2.5.3.24. Remote Access The DICTM RECOMMENDS that remote access to PNP Unit’s internal e-mail servers is disabled and blocked unless it is explicitly required. If it is enabled, the access path and communications through it MUST be appropriately protected for the highest classification of information permitted on the system.

2.5.3.25. Automatic Forwarding of Received E-mails PNP Units SHOULD NOT allow staff to automatically forward e-mails that may contain classified information to systems with a lower classification. Example: The automatic forwarding of e-mail to a web–based e-mail system. PNP Units SHOULD warn staff that the automatic forwarding of e-mail to another staff member may result in the new recipient seeing material that:

a. they do not have a need-to-know, or b. the intended recipient and/or sender considered private.

77



2.5.3.26. Server Auditing PNP Units through ITSSO and CTSSO SHOULD perform regular e-mail server auditing to detect threats such as denial of service attacks and use of the server as a mail relay.

Electronic Mail – Protective Marking Policy

2.5.3.27. Principle: The DICTM RECOMMENDS that PNP Units mark all PNP–originated email with a protective security marking that identifies the maximum classification and set of caveats for the information in the body of the e-mail and any attachments. Example: If the text of an e-mail contains only Unclassified information, but it has a CONFIDENTIAL attachment, an appropriate protective marking would be “UNCLASSIFIED–covering–CONFIDENTIAL”.

2.5.3.28. Blocking of Outbound E-mails

The DICTM RECOMMENDS that PNP Units configure e-mail systems to block: a. outbound e-mails that do not contain a valid protective marking, and b. outbound e-mails with protective markings that indicate that the content of the e-mail exceeds the classification of the:

i) receiving system, or ii) path over which the e-mail would be transferred.

PNP Units SHOULD log the fact the e-mails were blocked and notify the sender that the e-mail was rejected.

2.5.3.29. Blocking of In-bounds E-mails

PNP Units may also wish to configure e-mail systems to reject and log inbound e-mails with protective markings that indicate that the content of the e-mail exceeds the accreditation of the receiving system. The sender and the intended recipient SHOULD be notified that the e-mail was rejected. 2.5.3.30. Location of the Protective Marking The DICTM RECOMMENDS that a protective marking is placed: a. in the first line of the body of the e-mail, and b. in or near the last line of the body of the e-mail, and c. in the subject line, preceding the subject heading, and/or d. in the header of the e-mail 2.5.3.31. Format of the Protective Marking The DICTM RECOMMENDS that protective markings:

78



a. on the subject line be enclosed in square brackets, and Example: Subject: [CONFIDENTIAL] Report. b. within the body of the e-mail, other than any paragraph markings, be prefixed with “Classification:” with or without square brackets. Example: Classification: CONFIDENTIAL 2.5.2.32. Printing E-Mail Messages The DICTM RECOMMENDS that, where feasible, PNP Units modify systems so that the protective marking appears on the top and/or bottom of every page when the e-mail is printed.

Software Development These requirements apply to all systems that require development, upgrade or maintenance for the operating system or application software. 2.5.6.1. Software Development Environment PNP Units SHOULD have separate ICT environments for development and production. Where possible, DICTM RECOMMENDS having three environments:

• Development; • Testing; and • Production.

The environments SHOULD be logically separated (e.g. through gateways, login controls, etc). New development and modifications SHOULD only take place in the development environment. Write–access to vendor’s distribution media or integrity copies of operational software SHOULD be disabled in the testing and production environments. 2.5.6.2. Software Testing Software SHOULD be reviewed and/or tested for security vulnerabilities before it is used in a production environment. Software SHOULD be reviewed and/or tested by an independent party, and not by the developer.

79



CHAPTER 6- LOGICAL ACCESS CONTROL

Introduction

2.6.0.1. This chapter contains information on logical access control.

Contents

2.6.0.2. This chapter contains topics of the following sections:

1. User Identification 2. Privilege and System Account 3. Access and Authorization 4. Multilevel Systems

User Identification and Authentication 2.6.1.1. User Identification and Authentication PNP Units MUST ensure that all users of classified systems are:

a. uniquely identifiable, and b. authenticated on each occasion that access is granted to the system.

The DICTM RECOMMENDS that users of Unclassified systems are: a. uniquely identifiable, and

b. authenticated on each occasion that access is granted to the system. Guest and anonymous accounts SHOULD be disabled where they are not explicitly required.

2.6.1.2. Methods for User Identification and Authentication User authentication can be done by one or more of the following:

a. what the user knows, Examples: passwords, PINs. b. what the user has, Examples: cryptographic tokens, smartcards, keys. c. physical attributes of the user.

Examples: fingerprint scanning, voice recognition, typing characteristics.

The DICTM RECOMMENDS that PNP Units combine the use of multiple methods when identifying and authenticating users. Example: require a USB token and password. Authentication systems with known weaknesses SHOULD be disabled wherever possible.

2.6.1.3. Password Selection Where passwords are used as the sole authentication method, they SHOULD:

a. be a minimum of 8 characters, and b. consist of at least 3 of the following character sets:

80



i) lowercase characters (a-z), ii) uppercase characters (A-Z), iii) digits (0–9), and iv) punctuation and special characters. Examples: !@#$%^&*

These requirements SHOULD be enforced by the system.

2.6.1.4. Password Management. PNP Units SHOULD: a. ensure that passwords are protected in storage and transit (e.g. not transferred unencrypted); b. require passwords to be changed at least every 15 days; c. prevent users from changing their password more than once a day; d. check passwords for poor choices; and e. force the user to change their password on initial logon if it has ‘expired’ or been ‘reset’. The DICTM RECOMMENDS that PNP Units require users to physically present themselves to the person who is resetting their password. Reset passwords SHOULD NOT be predictable (e.g. Do not use “password” or the user’s login ID).

2.6.1.5. Screen and Session Locking PNP Units SHOULD configure workstations and servers with screen and/or session locks. Each computer’s lock SHOULD be configured to activate after a predetermined period of user inactivity. It SHOULD replace the contents of the screen but the computer SHOULD NOT appear to be turned off. The user SHOULD have to re–authenticate before the system is unlocked. Users SHOULD NOT be able to disable the locking mechanism. The period of user inactivity before the screen and session lock activates SHOULD be no longer than 30 minutes in general office areas. A shorter period SHOULD be set for workstations in public access areas such as reception areas.

2.6.1.6. Login Audit PNP Units SHOULD log failed login attempts and audit those records periodically. The DICTM RECOMMENDS that, where possible, ITSSOs configure systems to display the date and time of the user’s previous login during the login process.

2.6.1.7. Suspension of Access PNP Units SHOULD:

a. suspend access after a specific number of unsuccessful logon attempts,

Note: For most systems, 5 attempts are adequate.

81



b. remove or suspend user accounts as soon as possible after the user leaves the PNP, and

Note: This is especially important for systems that can be accessed remotely. c. suspend inactive accounts after a specified number of days.

Privileged and System Accounts 2.6.2.1. Use of Privileged Account Privileged accounts are those accounts that have permissions to bypass system controls, for example ‘root’ or ‘administrator’ accounts. PNP Units SHOULD:

a. ensure that the use of privileged accounts is controlled and accountable; b. ensure that administrators are assigned an individual account for the performance of their administration tasks; c. keep privileged accounts to a minimum; and d. NOT allow the use of privileged accounts for non–administrative work.

2.6.2.2. Default Password PNP Units SHOULD replace default passwords, and delete or rename default accounts within system equipment and software. This is especially important for systems that are connected to the Internet. 2.6.2.3. Group Accounts The DICTM RECOMMENDS that PNP Units avoid the use of group and other non user–specific accounts.

Access and Authorization 2.6.3.1. Guidelines PNP Units SHOULD:

a. limit user access on a need-to-know and need–to–access basis, b. provide users with the least amount of operating system privileges required for them to do their job, and

c. require any requests for access to a critical or classified system to be authorized by the user’s supervisor or manager.

2.6.3.2. Definition: Access Control List An access control list (ACL) is a list of system entities who are authorized to have access to a resource and the rights they have to the resource (i.e. Read, Write, Execute, Delete, Print, etc). A collection of access control lists is sometimes referred to as an access control matrix.

82



2.6.3.3. Developing an ACL Described below is the process of developing an ACL.

Stage 1: Establish groups of all system resources based on similar security objectives. Examples: Files, directories, data, applications, services.

Stage 2: Determine the data owner for each group of resources. Stage 3: Establish groups encompassing all system users based on similar functions or security objectives.

Stage 4: Determine the group manager for each group of users. Stage 5: Determine the types of access to the resource for each user group. Examples: Read, write, delete, and execute. Stage 6: Decide on the degree of delegation for security administration based on the PNP security policy.

Examples: • Delegate group membership to identified group managers. • Delegate resource access control to identified data owners.

Multilevel Systems 2.6.4.1. Security Requirements This section provides security guidance for Dedicated, System High and the two modes of multilevel systems (Compartmented, and Multilevel). See: About ICT Systems, p.3 for a definition of modes of operation. 2.6.4.2. Dedicated A system in dedicated mode for example, is a workstation with no system access controls, located within a secure facility. With the exception of legacy systems, PNP Units MUST NOT operate systems in dedicated mode. 2.6.4.3. System High This is the usual operating mode for government and commercial systems. Standard operating system controls are applied to allow users to only access the areas and functions they need to for their roles. Users control with whom they share their files and information. 2.6.4.4. Compartmented Mode Systems that need to compartment RESTRICTED or SECRET information can operate using standard operating system access and authentication controls. Additional compartmentalization of information can be provided through use of a Public Key Infrastructure (PKI) or database management system (DBMS) with data labeling capabilities. Note: This is an extension of System High mode but where system controls prevent users from sharing information with those who do not have an authorized need-to-know for that compartment of information. It is only normally used for

83



highly classified information. This mode requires access control over and above that found in most and application software. 2.6.4.5. Multilevel Mode Similar with the Compartmented Mode, however, special care SHOULD be taken with hardening and patching systems where users who are not staff members are permitted any access to the system’s resources. Example: A system that processes CONFIDENTIAL information but has some users who do not hold security clearances. Note: Systems that only process below CONFIDENTIAL information (e.g. RESTRICTED and CONFIDENTIAL) are considered to be operating in System–High Mode not Multi–level Mode.

84



CHAPTER 7- INTRUSION DETECTION Introduction 2.0.7.1. This Chapter discusses system and network intrusion detection, audit analysis, system integrity checking and vulnerability assessments. Contents 2.0.7.2. This chapter contains topic on:

1. Intrusion Detection System 2. Audit Logs and Analysis 3. Audit Trail Events 4. Other Logs 5. Managing Audit Logs 6. System Integrity 7. Vulnerability Analysis

Intrusion Detection Systems (IDS)

2.7.1.1. IDS on Internet Gateways PNP Units SHOULD deploy an intrusion detection system (IDS), with regularly updated signatures, at any gateways between the agency’s networks and the Internet. 2.7.1.2. IDS on other Gateways The DICTM RECOMMENDS that PNP Units deploy an IDS, with regularly updated signatures, at any gateways between the agency’s networks and any networks not managed by the agency.

Audit Logs and Analysis 2.7.2.1. Requirements: Audit log and analysis requirements MUST be defined that are based on the organizations overall audit objectives. They SHOULD include information on the:

• audit log mechanisms; • minimum audit events associated with a system or software component; • audit protection and archival requirements; • audit schedule; and • audit log management.

85



2.7.2.2. Audit Trail Facility For each audit event, the audit log facility SHOULD, at a minimum, record the following information:

a. date and time of the event; b. relevant user(s) or process (where known); c. type of event; and d. success or failure of the event.

See: Audit Trail Events, pp.43 and 44.

The DICTM RECOMMENDS that PNP Units establish an accurate time source and use it consistently throughout the agency’s ICT systems to assist with the correlation of audit events across multiple systems.

2.7.2.3. Audit Trail Protection and Archival Audit logs MUST be:

a. protected from modification and unauthorized access, Note: The DICTM RECOMMENDS that systems be configured to save

audit logs to a separate, secure log server. b. archived using a well–documented procedure and retained for future

access, and Note: The DICTM RECOMMENDS archiving audit logs onto write–once media. c. protected from whole or partial loss within the defined retention period.

2.7.2.4. Responsibility for Determining Audit Requirements The ITSSO/CTSSO, System Managers and information owner are responsible for determining the audit requirements of a system, consistent with the requirements of the ICT Security Policy and Risk Assessment.

2.7.2.5. Resources PNP Units SHOULD ensure that a sufficient number of appropriately trained personnel and tools are available to monitor all audit logs for security breaches or intrusions.

Audit Trail Events

2.7.3.1. Audit Trails for Software Components The types of events and information to be recorded SHOULD be based on the system’s risk assessment. Provided below are the DICTM’s recommendations for the events to log for specific software components.

86



Operating System RECOMMENDED events to Audit • successful and failed attempts to logon and logoff;

• failed attempts to access data and system resources; • attempts to use special privileges; • changes to system administration and user accounts

and groups; • changes to security settings and configuration data; • service failures and restarts; and • system start–up and shutdown. Additional events that SHOULD be CONSIDERED are: • access to sensitive data and processes; and • data export operations. Examples: e-mail, ftp transfer, printing and floppy disk transfers.

Database

RECOMMENDED events to Audit • attempted user access that is denied;

Example: Incorrect password. • changes to user roles or database rights; • modifications to critical data; and • modifications to the database metadata.

E-mail System RECOMMENDED events to Audit

• records of all e-mail sent to external systems. Note: If required, the e-mail system should allow full audit of e-mail content for a specific user or the entire system.

Web Application

RECOMMENDED events to Audit • user access to the Web application;

• attempted user access that is denied; • user access to the Web documents; and • search engine queries initiated by users.

Gateways

RECOMMENDED events to Audit • failed attempts to access the network; • transfer of executable content; • files and mail blocked by a content filter; and • attempts to transfer classified data.

87



Other Logs

2.7.4.1. User Logs Retention of past and present user account information can be of significant value during an incident investigation. Therefore, PNP Units SHOULD:

a. maintain a secure log of all authorized users, their user identification and who provided the authorization and when, and

Note: In many cases this could be achieved by retaining the account application form filled in by the user and/or their supervisor. b. maintain the log for the life of the system, after which the log SHOULD be archived in accordance with PNP Regulation 200-12 Re: Promulgating Rules Governing Security of Classified Matters in all PNP Units.

2.7.4.2. System Management Logs PNP Units SHOULD record the following information in a manually updated system management log:

a. system start–up and shutdown, b. maintenance and housekeeping activities, Examples: Backup and archival runs. c. component or system failures, d. system recovery procedures, e. sanitization activities, and f. special or after office-hour activities.

Managing Audit Logs

2.7.5.1. Responsibility for Managing Audit Logs In keeping with the principle of ‘Separation of duties’, the people administering systems processing personal, financial or highly classified information SHOULD NOT be the people who review the audit logs. The DICTM RECOMMENDS that the ITSSO/CTSSO be responsible for managing those audit logs.

2.7.5.2. How to Manage an Audit Log The DICTM RECOMMENDS the following process be adopted for the management of an audit log.

Step 1: Collect relevant audit trail information from the operating system, networks or applications.

Step 2: Collate the information. Step 3: Examine the audit information for events of interest based

on the type of application. Step 4: Examine trends from past audits for or patterns.

Step 5: Transfer files to an appropriate location for archiving.

88



Step 6: Inform appropriate System Managers of relevant security issues.

System Integrity

2.7.6.1. System integrity mechanisms aim to: a. minimize the likelihood of unauthorized tampering of information and system components, and

b. detect attempts or incidents of unauthorized tampering or access. 2.7.6.2. System Integrity Checks PNP Units SHOULD ensure that regular integrity checks are conducted on their critical systems. It SHOULD use cryptographic hashes to detect unauthorized changes to critical files. Examples: Critical files include operating system programs and system configuration files.

2.7.6.3. System Changes PNP Units SHOULD ensure that: a. non–privileged users (e.g. general users) do not have access to privileged administrative utilities; b. non–privileged users cannot change system configurations; and c. changes to system configurations are managed and audited.

Vulnerability Analysis

2.7.7.1. Guidelines PNP Units SHOULD have a vulnerability analysis strategy combining the techniques of: a. monitoring public domain information about new vulnerabilities in their key

operating systems and application software; b. using automated tools to perform vulnerability assessments on PNP Unit’s

systems; c. running manual checks against system configurations to ensure disallowed

services are prevented; and d. auditing against PNP best–practice security checklists for operating systems

and common applications.

2.7.7.2. Authorization The DICTM RECOMMENDS that units require the authorization of the ITSSO/CTSSO before system managers or other staff perform vulnerability assessments on operational systems.

Examples: • password cracking; and • exploit testing.

89



Note: This requirement does not apply when conducting passive vulnerability assessment, such as a configuration

2.7.7.3. When to Perform The DICTM RECOMMENDS that units perform security vulnerability assessments:

a. before the system is first used; b. after every significant change to the system and c. as required by the ITSSO/CTSSO and/or System Manager.

90



CHAPTER 8-COMMUNICATIONS SECURITY (COMSEC)

Introduction 2.0.8.1. This chapter contains information about Communication Security (COMSEC) installation standards. Contents

2.0.8.2. This chapter discusses on the importance and different aspects of COMSEC in the PNP. It also includes discussion on topics about the following media and devices:

1. Peripheral Switches 2. Wireless Networks 3. Infrared and Radio Frequency Devices 4. Telephones and Pagers 5. IP Telephony 6. Facsimile Machines 7. Multifunction Devices

2.0.8.3. Definition: COMSEC is the set of measures and controls taken to deny unauthorized persons information derived from electronic communications and technical eavesdropping. COMSEC includes the following:

a. physical security of ICT components. b. transmission security; and

c. cryptographic security

1. Physical Security Physical security must provide protection to COMSEC material from the time of its production through its destruction. Physical security is that part of COMSEC concerned with measures designed to safeguard personnel and prevent unauthorized access to equipment, facilities, materials and documents. It is also concerned with measures designed to safeguard and minimize the possibility of compromise of COMSEC materials through espionage, damage, salvage, observation, photography and theft.

Importance of Physical Security Maintenance of physical security assures the maximum protection of classified materials from time of production to destruction. Classified

91



materials maybe safeguarded from compromise through capture, salvage, theft, inspection or photography by: a. Proper handling on the part of everyone concerned. b. Proper storage when not in use. c. Complete destruction when necessary.

WARNING! Unsuspected physical compromise is far more critical than known loss. If an undisclosed compromise happens and the cryptosystem persists, an enemy may be able to decrypt all traffic in that cryptosystem. Types of Barriers on Physical Security. Physical Barriers are used/installed to harden defense and enhance security measures such as follows: a. Natural Barriers These are natural objects which delay the entry of the intruder such as rivers, cliffs and ravine. This is always the first type to consider since very often we have to accept them and work around them. Natural terrain feature must be considered from both the standpoint of their value as a barrier to the intruder as cover and concealment. b. Animal Barriers This is where an animal is used in providing or partially providing a guard system. The animals used are limited to dogs, which are known as guard, or sentry dogs. c. Energy Barriers This is where the employment of mechanical, electronic energy used to impose a deterrent to entry by the potential intruder or to provide warning of his presence. d. Structural Barriers These barriers are features constructed by man, regardless of their original intent, which tend to delay the intruder. e. Human Barriers These are guards, in-charge of quarters, ODs, office and shop workers, etc., who stand between the intruder and the matter to be protected. Following MUST be considered in the selection of Human Barriers: • eligible for security clearance. • vigorous and physically able to serve in the capacity of a guard. • intelligence necessary to accomplish the guard functions. • ability to make rapid decisions and react in a calm way during emergencies.

92



• loyalty and discretion required. • experience, although not unusually mandatory, is highly desirable

2. Transmission Security Is the measure/s designed to protect transmission from unauthorized interception, traffic analysis and imitative deception. The total encryption of all electrical/electronics transmission, both messages and conversation is the ideal solution to transmission security problems. Where a total encryption is not possible, other actions must be taken. The transmission practices by operators; failure to change frequencies, call signs, passwords, and excessive use of one or more means of communications, compound the transmission security problem.

Selecting the Means of Transmission Communication personnel shall select the means most appropriate to accomplish the delivery of messages in accordance with the specified precedence and security requirements.

The originator may indicate the desired method of delivery of a message in the block provided for the purpose in the Message Form. The means of transmission, as maybe indicated, is subject to change by the communication center personnel if it is not in accordance with approved existing regulations, policies and other publications on the matter.

Safeguards in the Use of Selected Means of Transmission

Telephone and Facsimile (Fax) • Personnel/Operators manning telephone sets/facsimile

machines should be aware of security measures against wire tapping/bugging of installed telephone line within or outside office, building and/or camps.

• Routine physical inspection of telephone lines, terminals and all accessories to check wire tapping or interception, to be done by PNP personnel assigned to. In case of any detection of wire tapping/bugging, it should be reported immediately to the Chief of Office for proper disposition.

• Installation of anti-bugging device to preempt/prevent any unauthorized access to the telephone system.

93



• Maintain constant coordination with commercial service provider to ensure safety against interception, tapping or sabotage, on their end of the telephone system.

Radio

• Printed messages either incoming or outgoing can be transmitted/received in plain or encrypted form through a radio set from one station to another depending in the level of classification in accordance with the condition/provisions of this rules/regulation.

• Radio operators who are manning radio sets in different PNP officers should conduct routine signal check/authentication with other operators within their radio network to determine efficiency of their respective radio sets and preempt any deception and interception.

• In case of detection of any deception, interception, traffic analysis, this matter should be immediately reported to the superior/chief of office concerned.

• Radio communication facilities such as relay station, repeater sites and the likes should be manned/guarded on a twenty four (24) hour basis.

• Call-words, passwords and/or codes for authentication purposes.

Data Communication (DATACOM)

Printed messages/information classified as “Restricted” and “Confidential” can be transmitted through the DataCom in plain or clear text.

• Messages/Information classified as “Secret” and “Top Secret” can be transmitted through the DataCom provided provisions in transmitting Secret and Top Secret messages/information will be followed.

• Periodic/routine inspection should be conducted to ensure that no unauthorized interception in the lines/terminal will occur.

• Software/programs within the terminals should be checked periodically to ensure their reliability and utmost efficiency.

• Diskettes worksheets and other materials being utilized in the DataCom storeroom should be placed in the designated secured vault/cabinet within the DataCom Section prior to the destruction in accordance with data placement of computer sets.

94



3. Cryptographic Security

See: Chapter 9, p.105 Peripheral Switches

2.8.1.1. Peripheral switches are used to share a set of peripherals between several computers. The most common type of peripheral switch is the Keyboard/Video/Mouse (KVM) Switch.

2.8.1.2. If a KVM switch is used to share peripherals between a SECRET or RESTRICTED system and a lower classification system, the KVM switch SHOULD be selected from those that have been evaluated. If the KVM is for more than two systems then the level is determined by the highest and lowest of the system classification involved.

Wireless Networks

2.8.2.1. Examples of wireless communication technologies and protocols include:

• Bluetooth; • Infrared; • General Packet Radio Service (GPRS); • Global System for Mobile communications (GSM); • Code Division Multiple Access (CDMA); • Multimedia Messaging Service (MMS); and • Short Message Service (SMS).

Security Issues with Wireless Networking

2.8.2.2. The main security issues with devices incorporating wireless networking are:

a. in their default configuration, many wireless networking systems automatically search for and connect to any wireless device within range; b. some wireless systems do not require authentication, or employ

weak authentication, which can allow unauthorized access to the device or network;

c. wireless communications are vulnerable to interception; d. packet flooding or signal interference can effectively stop the network from operating until the flooding or interference ceases.

2.8.2.3. Policy (SECRET, RESTRICTED) PNP Units SHOULD NOT use devices incorporating wireless networking components for processing SECRET or RESTRICTED information unless:

95



a. the wireless functionality is disabled by: i) removing the wireless software components and ii) where possible, removing the wireless hardware components

b. the security has been approved by the ITSSO/CTSSO.

2.8.2.4. Policy (CONFIDENTIAL) PNP Units SHOULD implement the following controls, at a minimum, for CONFIDENTIAL wireless systems:

a. secure any wireless access points into a network to the same level required for a connection to the Internet or any other public network, Example: use an evaluated firewall. b. change the default wireless configuration settings, where appropriate, Examples: enable password authentication, disable broadcasting the network identifier. c. change the default authentication values, Examples: default passwords, encryption keys. d. disable any capabilities to remotely configure the wireless system or protect them with encryption and strong authentication.

Infrared and Radio Frequency

2.8.3.1. Policy on infrared and RF devices [CONFIDENTIAL, SECRET, RESTRICTED] PNP Units SHOULD NOT use infrared (IR) or Industrial, Scientific and Medical (ISM) RF devices on CONFIDENTIAL, SECRET or RESTRICTED systems. Where units have a requirement to use IR or ISM devices, they SHOULD ensure that:

a. all transmissions occur within a controlled space, b. a risk assessment is conducted for each individual controlled space;

c. measures are taken to minimize the likelihood of direct visual access to IR signals from uncontrolled spaces; e. the distance between the device(s) and any uncontrolled

space(s) is at least 20 meters, and f. devices are not used to amplify the strength of the signal.

Exception: PNP Units may use these technologies for the transmission of data associated with pointing devices such as mice and track balls even if the conditions listed above are not met.

96



Telephone and Pagers

2.8.4.1. Definition: Within this section the term ‘telephone’ is used to describe a device that allows voice communications to be sent electronically over a distance. Examples:

• standard, wired handsets; • cordless phones; • mobile phones; • wireless headsets; • stand-alone Voice over IP (VOIP) handsets; and • computer-based VOIP ‘softphones’.

2.8.4.2. Use of Telephones for Transmission of Classified Information PNP Units MUST NOT allow telephone systems to be used for the transmission of classified information above CONFIDENTIAL unless the system has been accredited for the classification of information being transmitted and all traffic is encrypted with an approved cryptographic system. See: Requirements for transit encryption, p.106 Exception: SECRET and RESTRICTED calls may be made over public telephone networks if the parties can assure that the sender and receiver are both located within the Philippines.

2.8.4.3. Telephones in Classified Areas PNP Units SHOULD warn staff of the dangers of using telephones while classified conversations are being held nearby. 2.8.4.4. Cordless and Mobile Phones PNP Units MUST NOT use cordless or mobile phones for transmission of classified information unless their security has been approved by the concerned authority for that classification of information. See: • Cryptography, p.104

• Evaluated Products, Chapter 3, p.54

2.8.4.5. Paging Services Use of paging services MAY be allowed to transmit CONFIDENTIAL information only if they can ensure that sender and receiver are both located within the Philippines. Unencrypted paging services MUST NOT be permitted to transmit information classified above CONFIDENTIAL. This includes Multimedia Messaging Service (MMS) and Short Message Service (SMS).

97



IP Telephony 2.8.5.1. Definition: IP Telephony (IPT) is the transport of telephone calls over Internet Protocol (IP) networks. IPT is also referred to as Voice–Over–IP (VOIP) and Internet Telephony.

2.8.5.2. Standards

The standards in this topic are additional to the standards for Telephones and Pagers. See: Telephone and Pagers, p.97

2.8.5.3. Networks Interconnections

PNP Units MUST install a firewall of sufficient assurance between the PNP’s IP network and a public network such as the Public Switched Telephone Network (PSTN). Note: The PSTN is to be regarded as a public network for the purposes of determining the required level of assurance. See: Gateways, p.113 The firewall MUST be configured to only permit telephony traffic though the interface. It SHOULD be capable of parsing the telephony protocols in use within the PNP.

2.8.5.4. Network Separation

The DICTM RECOMMENDS that PNP run its IP telephony traffic on a network infrastructure separate from that which provides the PNP’s data network. PNP Units that do not run their IP telephony traffic on a separate network infrastructure SHOULD use Virtual LANs (VLANs) to separate the telephony traffic from the rest of the data network. Use of Virtual Private Network for connectivity and access is encouraged.

2.8.5.5. Infrastructure Hardening PNP Units SHOULD ensure all IP telephony components are configured securely.

Examples: the IP PBX, databases, web servers, and phones. PNP Units SHOULD: • disable Trivial File Transfer Protocol (TFTP) on IP phones; • NOT use telnet for the remote management of IPT components; and • NOT run non-IP telephony applications on servers used for IP

telephony services.

98



2.8.5.6. Call Authentication and Authorization When VOIP calls are being established they SHOULD be routed via a voice server for authentication and authorization.

2.8.5.7. Vendor Recommendation

Where feasible, the PNP SHOULD implement the security measures recommended by the vendor of the IP telephony products. If any of the recommendations conflict with this manual then this manual has precedence.

Facsimile Machines

2.8.6.1. Definition: The term ‘facsimile machine’ is used to describe a device that allows copies of documents to be sent over a telephone system. Examples:

• stand–alone fax machines; • ‘multifunction devices’ capable of, among other things, the sending and receiving of faxes; and

• computers equipped with fax processing cards.

2.8.6.2. Use for the Transmission of Classified Information PNP Units MUST NOT allow facsimile machines to be used for the transmission of classified information unless: a. all of the security standards for the use of telephone systems are met

at both ends for the level of classification to be sent; and See: Telephones and Pagers, p.97 b. the sender makes arrangements for the receiver to:

i) collect the information from the facsimile machine as soon as possible after it is received; and ii) notify the sender if the facsimile does not arrive within an agreed amount of time.

Note: The DICTM RECOMMENDS that this be no longer than 10 minutes.

Multifunction Devices (MFD)

2.8.7.1. Definition: Within this document the term ‘multifunction device’ (MFD) refers to the class of devices that combine several functions such as printing, scanning, copying, faxing and voice messaging within the one device. These devices are designed to connect to a computer and telephone network simultaneously. These devices can either be desktop models intended for a single user, or larger stand-alone units intended for shared use by multiple parties. A number of MFDs have multiple storage

99



devices or other mass storage devices in them. Some systems have direct internet email connection options, and others may also incorporate cellular phone transmitters with vendor auto-alert features, adding further security concerns. See: • Telephones and Pagers, p.97 • Facsimile Machines, p.99

Risks with MFDs

2.8.7.2. Multifunction devices share much of their technology with computers. They present a similar range of security issues so need to be treated as such. The three main risks associated with MFDs are:

a. an attacker might enter the computer system via the telephone network connection;

b. information on the storage media within the MFD might be compromised when the equipment is serviced or disposed of; and

c. a user might fax a classified document by accident or by assuming it is acceptable because the capability exists.

Usage Policy

2.8.7.3. MFDs SHOULD NOT have facsimile functionality enabled unless the telephone network they are connected to is accredited to at least the same security classification as the computer network.

Policies, Plans and Procedures

2.8.7.4. PNP Units that use MFDs MUST include a section on their use and protection in their ICT security policy documentation. Policies, plans and procedures governing the use of the equipment SHOULD be based on a risk assessment of the security, technical and support issues. The DICTM RECOMMENDS that PNP Units:

a. develop a set of procedures that define liaison with equipment providers, including: • fault reporting and resolution; • authorization of engineers and other support staff; • introduction and removal of media and other components; • sanitizing or removing any unserviceable components; in particular, electrostatic drums, hard disks and memory components.

See: Media Sanitization, p.60 b. prevent remote access for diagnostic support, updating, etc, c. disable unused communications ports and capabilities, and d. ensure users have appropriate training and awareness of the security issues.

100



Electronic Storage Devices 2.8.7.5. As these devices typically have large storage capacity, they can potentially hold millions of documents. PNP Units SHOULD therefore:

• ensure that the storage device is removed prior to the MFD being removed from the premises (including for maintenance), or has been completely erased using a GCSB-approved product, regardless of the classification of the material contained within the device; • have adequate measures in place that the storage device cannot easily be removed by unauthorized persons; • introduce measures to reduce the likelihood that the storage device will be accessed by unauthorized persons – including from the internal network.

Pins and Passwords 2.8.7.6. MFDs typically have an option for each user to have their own unique password or PIN. The DICTM highly RECOMMENDS that this facility is turned on at all times to ensure that a record is created for each print job, scan or copy. Logs 2.8.7.7. MFDs have an internal log of jobs sent to the device and who sent them. These logs should be treated in the same way as other ICT equipment logs, including back-up and retention.

Requirements for MFDs in PNP Use at the UNCLASSIFIED level 2.8.7.8. All MFDs to be used in PNP at the UNCLASSIFIED level, MUST conform to the following specifications, whether they have mass storage devices or not: • all unused features MUST be disabled; • the MFD MUST NOT be directly connected to the internet i.e. without the use of an agency firewalled connection; • the MFD MUST NOT be connected to multiple networks that have different security classifications; • logging MUST be enabled on MFDs, and these logs SHOULD be treated in line with the PNP’s log handling policy; • the MFD MUST be configured in such a way that removal of any storage device by unauthorized persons is difficult and will alert an administrator; • the MFD MUST NOT allow connectivity through to the LAN when transmitting or receiving faxes, or when connected to the Internet; • the agency MUST ensure that any and all mass storage drives are removed from the MFD prior to its disposal, or removal from the PNP, for any purpose; • PNP Units SHOULD enforce individual passwords or enable individual PIN access for each user, and for all jobs sent to the MFD;

101



• the MFD MUST be configured in such a way to make unauthorized access to storage device via LAN unlikely. Any attempt to access the storage device SHOULD be logged by the MFD or the LAN administration system; • the MFD SHOULD be capable of automatically overwriting space used on its storage device at the completion of each job and this function should be enabled where available; • the MFD SHOULD have PIN or password protection enabled, and any password SHOULD conform to the PNP’s password policy; and • the DICTM RECOMMENDS that when the device is serviced by the authorized agent, this SHOULD be done using a PNP Unit’s provided laptop, with the MFD disconnected from the unit’s LAN.. Additional Requirements for MFDs to be used in CONFIDENTIAL level 2.8.7.9. In addition to the requirements for UNCLASSIFIED, MFDs used up to the CONFIDENTIAL level: • MUST not connect to the internet, either directly or indirectly; • SHOULD be an evaluated product; • SHOULD ensure that when the device is serviced by the authorized agent, that this is done using the PNP’s provided laptop, with the MFD disconnected from the unit’s LAN; • the MFD logs MUST be handled according to unit’s ICT log policy; and • any storage device contained in the MFD MUST NOT subsequently be used for CLASSIFIED purposes before having appropriately sanitized. Additional Requirements for MFDs to be used in SECRET level 2.8.7.10. In addition to the requirements for unclassified, MFDs used up to the SECRET level: • MUST meet the additional requirements for CONFIDENTIAL; • SHOULD be an evaluated product; • MUST ensure that when the device is serviced by the authorized agent, that this is done using an agency provided laptop, with the MFD disconnected from the agency LAN. Any media used to transfer information to or from this laptop (CD, USB key, FLASH card etc) MUST stay within the PNP and MUST NOT be allowed to leave with the service person. The service person SHOULD be supervised at all times when servicing the MFD; • MUST have PIN or password access enabled at all times; • The PNP Unit MUST ensure that any storage devices removed from an MFD are sanitized and disposed of in line with the requirements of this document; and • any storage device contained in the MFD MUST NOT subsequently be used for lower classified purposes, without first being sanitized in line with the requirements of this document.

102



Additional Requirements for MFDs to be used in RESTRICTED level 2.8.7.11. In addition to the requirements for unclassified, MFDs used up to the RESTRICTED level is the same as for SECRET.

Additional Requirements for MFDs to be used in CONFIDENTIAL, SECRET or TOP SECRET level 2.8.7.12. In addition to the requirements for unclassified, MFDs used up to the CONFIDENTIAL, SECRET or TOP SECRET level: • MUST meet the additional requirements for RESTRICTED; • MUST ensure that when the device is serviced by the authorized agent that this is done using the PNP’s provided laptop, with the MFD disconnected from the PNP LAN. Any media used to transfer information to or from this laptop (CD, USB key, FLASH card etc) MUST stay within the PNP Unit and MUST NOT be allowed to leave with the service person. The service person MUST be supervised at all times when servicing the MFD; • the MFD MUST NOT be connected to any other network of a lower classification (including telephone system); • the MFD MUST NOT be connected to, or otherwise permit, internet connectivity; • the MFD MUST perform automatic overwrites of data space once a job is completed; • the MFD MUST encrypt the data stored on the storage device using an encryption algorithm approved by the NTC/authorized office or agency; • jobs sent to and from the printer MUST be encrypted using an encryption algorithm approved by NTC; • MUST have PIN or password access enabled at all times and any password MUST conform with the DICTM’s ICT password security policy; • the agency MUST ensure that any storage devices removed from an MFD are sanitized and disposed of in line with the requirements of this document; • the MFD MUST be located at a site approved to handle either CONFIDENTIAL, SECRET or TOP SECRET material; and • any storage device contained in the MFD MUST NOT subsequently be used for lower classified purposes, without first being sanitized in line with the requirements of this document.

103



CHAPTER 9 - CRYPTOGRAHY Introduction 2.0.9.1. This chapter contains information on cryptography. Purpose of Cryptography 2.0.9.2. Cryptography can be used to provide confidentiality, integrity, authentication, and sender or creator non–repudiation. Contents 2.0.9.3. This chapter contains topics on:

1. Fundamentals of Cryptography 2. Requirements for Cryptography 3. Approved Cryptographic Algorithms 4. Key Management

Fundamentals 2.9.1.1. Normally referred to as “crypto security”, cryptography is the protection resulting from technically sound cryptographic systems and their proper use. It deals with the proper use of authorize codes, cipher devices and machines employed for encrypting messages. It is a basic requirement to control crypto information until it is properly disposed of. Just as with the classified materials, no person is entitled to have knowledge of, or to have access to crypto information solely because of his office, position or security clearance. All persons who require access to crypto information must possess the appropriate security clearance, a need to know, and be authorized access to such material in accordance with the provisions of appropriate regulations and directives. Prompt reporting of actual or possible compromised or lost crypto matter is also essential for maintaining crypto-security. Prompt action is required so that a communication security system (COMSEC) material that may have been compromised can immediately be replaced. Procedures for reporting loss or compromised crypto matters are found in the Communications Electronics Operating Instructions (CEOI) and pertinent COMSEC publications. 2.9.1.2. Personnel Authorized to Perform Cryptographic Duties

a. Only authorized persons who are thoroughly familiar with the provisions of this regulations pertaining thereto shall employ cryptographic systems.

104



b. Only trustworthy personnel shall be assigned to work with classified

material especially cryptographic system. Such personnel shall be investigated and cleared in accordance with service regulations before they are permitted to handle classified and cryptographic materials. Office Chiefs may revoke the clearance of any individual who, for any reason, appears no longer suitable to handle cryptographic material.

c. Personnel who have approved as to trustworthiness shall be carefully instructed and tested for accuracy and proficiency in the use of cryptographic systems before being permitted to code and decode actual messages.

d. Security clearance is the certification by responsible authority that the person described is cleared for access to classified matters at appropriate level. This includes assignments to sensitive positions.

2.9.1.3. Safety Measures to Ensure Cryptographic Security

a. Cryptographic materials will be given the most secure storage available and will never be left unattended except when deposited in a three position, dial, type changeable combination safe or its equivalent.

b. Classified messages must be carefully drafted. c. The classification of message must receive careful consideration by

the originator since over-classification and under classification are equally to be avoided.

d. The selection of the proper cryptographic system is a responsibility of the cryptographic security officer or custodian of cryptographic material where there is no cryptographic security officer. If the time and availability of personnel permit, the crypto graphed text of messages should be checked prior to transmission. The check should determine that the instructions governing the system employed are carefully followed.

e. The handling and filing of both plain and crypto graphed text should conform to prescribed procedures. Classified messages must be carefully drafted.

f. Paraphrasing is resorted to as a protection of the cryptographic system and will not be used in such a manner as to permit loose handling of classified message.

g. When it is necessary to indicate in the text of a classified message information as to the ultimate receiver or the sender, such information must be buried within the text of the message before crypto graphing and will not appear either at the beginning or at the ending of the message.

h. The number of cryptographic systems and quantity of cryptographic materials held at exposed outposts or where capture is probable will

105



be at minimum. The allowances under such condition shall be prescribed by appropriate authorities.

i. Plain language copies of crypto graphed messages and the corresponding cryptographic texts shall be filed separately. They shall be stored as required for other material of the same classification.

j. Excess worksheets copies, typewriter ribbons, diskettes, carbon papers and blotting papers used in preparing and processing classified information shall be accorded the same handling, storage and disposal as that exercised for other classified material.

Requirements for Cryptography

2.9.2.1. Approval of Cryptography PNP Units using cryptography to protect classified information and systems MUST use cryptography:

a. approved by the NTC for the purpose, and b. in accordance with the standards in this section.

Cryptographic products approved to protect information classified up to RESTRICTED and SECRET are defined as ‘Baseline’ products. Baseline products will usually have completed a Common Criteria evaluation, and have their cryptographic functions approved by the NTC/authorized office or agency. See: Evaluated Products, p.54 Note: The use of approved encryption will generally reduce the likelihood of an unauthorized party gaining access to the encrypted information. However, it will not reduce the consequences of a successful attack. 2.9.2.2. Requirements for storage encryption Media or equipment containing up to RESTRICTED or SECRET information MAY be handled as for Unclassified equipment when an approved Baseline product is protecting the classified information. Example: Hard disk encryption on a laptop. 2.9.2.3. Risk Considerations for Storage of Encryption Care must be taken with storage encryption systems that do not encrypt the entire media content. PNP Units MUST ensure that either all of the classified data is encrypted or that the media is handled in accordance with the highest classification of the unencrypted data. Authentication information, such as passwords and tokens, that would allow the information to be decrypted MUST NOT be stored with or on the equipment. 2.9.2.4. Requirement for transit Encryption All SECRET and RESTRICTED information transmitted across public networks within the Philippines, or any networks overseas, MUST be encrypted with a Baseline product, or be otherwise approved by the NTC.

106



Encryption is not required for CONFIDENTIAL information transmitted across external or public networks. However, the DICTM RECOMMENDS that PNP Units consider using a Baseline encryption system for this information. 2.9.2.5. Key Support It might be necessary for the DICTM to support some cryptographic systems with special national key provided. In such cases, the NTC SHOULD be given adequate advanced notice in order to determine its ability to generate the key and to provide it in a timely manner. Specific physical and personnel security measures could also be required to protect the keys. 2.9.2.6. Approve Algorithms and Protocols Where a cryptographic module has a selection of algorithms, it MUST be configured to use NTC approved cryptographic algorithms. The other algorithms SHOULD be disabled if possible. Approved Cryptographic Algorithms 2.9.3.1. This section explains the cryptographic algorithms that the NTC has approved for the protection of non–national security classified information and RESTRICTED information, when implemented in accordance with the relevant standard.

The four types of cryptographic Algorithms are: 1. key establishment algorithms, 2. message and certificate signature algorithms, 3. hashing algorithms, and 4. symmetric encryption algorithms.

Note: The fact that a specific product uses one or more of these algorithms does not automatically mean that it is approved for government use.

Key Management 2.9.4.1. Key management covers the use and management of cryptographic keys and associated hardware and software in accordance with policy. It includes their:

• generation; • registration; • distribution; • installation; • usage; • protection; • storage and archival; • recovery; • deregistration/revocation; and • destruction.

107



2.9.4.2. Definition: Cryptographic System Material Cryptographic system material includes, but is not limited to, key, equipment, devices, documents, and software that embodies or describes cryptographic logic.

2.9.4.3. Definition: Cryptographic System A cryptographic system is a related set of hardware and/or software used for cryptographic communication, processing or storage, and the administrative framework in which it operates.

2.9.4.4. Cryptographic System Requirements In general, the requirements specified for ICT systems apply equally to cryptographic systems. Where the requirements for cryptographic systems are different, the variations are contained within this chapter, and overrule all requirements specified elsewhere within this document. 2.9.4.5. Cryptographic System Administrator Access Cryptographic system administrator access is privileged access. Before an individual is granted cryptographic system administrator access, individuals at a minimum SHOULD:

a. have a demonstrated need for access, b. read and agree to comply with the relevant doctrine for the cryptographic system they are using, c. possess a security clearance at least equal to the highest classification of information processed by the system, d. agree to protect the authenticators for the system at the highest

level of information it secures, Example: Passwords for a cryptographic system administrator account securing CONFIDENTIAL data.

e. agree not to share authenticators for the system without approval, f. agree to be responsible for all actions under their accounts, and g. agreed to report all potentially security-related problems to the ITSSO/ CTSSO.

2.9.4.6. Access Register The DICTM RECOMMENDS that PNP Units hold and maintain an access register that records cryptographic system information such as:

• details of those with administrator access; • details of those whose administrator access was withdrawn; • details of system documents; • accounting procedures; and • audit procedures.

108



2.9.4.7. Accounting PNP Units SHOULD be able to readily account for all transactions relating to cryptographic system material including identifying hardware and software, and who has been issued with the equipment. 2.9.4.8. Audits PNP Units SHOULD conduct audits of cryptographic system material:

• on handover/takeover of administrative responsibility for the system; • on change of individuals with access to the cryptographic system; and • at least annually. The DICTM RECOMMENDS that PNP Units perform audits: • to check all cryptographic system material as per the accounting documentation; and • to confirm that agreed security measures documented in the equipment doctrine are being followed. The DICTM RECOMMENDS that these audits be conducted by two individuals with cryptographic system administrator access.

2.9.4.9. Area Security and Access Control Cryptographic system equipment SHOULD be stored in a room that meets the server room security level appropriate for the classification of data the system processes. See: Physical Security, p.45 Areas in which cryptographic system material is in use SHOULD be separated from other classified and unclassified areas and designated as controlled areas. Example: A locked cabinet containing the cryptographic system is within the server room, with the key held by a cryptographic system administrator. Cryptographic system material remains in the custody of an individual who has been granted cryptographic system administrator access. 2.9.4.10. Key Recovery PNP Units SHOULD develop processes and mechanisms to recover keys and/or critical data in the event that an encryption key becomes unavailable. Example: Lost or damaged keys, software failure. 2.9.4.11. Destruction It shall be the responsibility of any person charged by proper authority with the transportation, storage or supervision of classified communication materials to keep such materials out of the hands of unauthorized person.

Routine Destruction Whenever a person entrusted with registered classified communication materials has no further need for them, he MUST report the fact to the Chief, Regional Communications and Electronics Office or his equivalent or in the case of field forces in time of police operations, to the COMMEL officer of the offices charged with the issue of such materials and

109



destruction SHOULD be accomplished when directed by competent authority. In the case of non-registered classified communication materials, destruction shall be carried out when their usefulness is ended or at specified times as provided for service regulations. Prior to destroying such materials, it shall be thoroughly checked to ascertain that only the materials which should be destroyed are included. In carrying out the destruction procedures, following SHALL be considered: • Routine destruction shall be accomplished only by authorized

personnel; • Routine destruction shall be carried out promptly at the specified time

in order that the amount of materials which would require destruction in an emergency may be kept at minimum. Messages and correspondence files should be allowed to accumulate to an extent greater than what is necessary or required; and

• A report of destruction shall be submitted according to requirements by current instructions after destruction procedures have been undertaken.

Emergency Destruction In general, emergency destruction must be carried out as follows: • Superseded cryptographic materials, still on hand, must be destroyed as soon as question as to its physical safety arises. • Reserve cryptographic materials must be destroyed without waiting until the last possible moment when danger threatens its security. (If danger fails to materialize, replacement can be issued). • Effective cryptographic materials must be retained for as long as practicable. The system of narrowest distribution should be preserved until the end and the system of wide distribution ahead of it should be destroyed. • After the destruction of cryptographic materials, related TOP SECRET and SECRET communication material must be destroyed. When such items are destroyed the remaining classified documents shall be destroyed in the order of importance. Destruction of all copies of one document is more important than the destruction of portion of several documents. • Communication equipment that is classified CONFIDENTIAL and higher must be destroyed beyond recognition, as much as possible. RESTRICTED and UNCLASSIFIED communication equipment shall be demolished, if possible, to such extent that repair or rehabilitation of parts would be impracticable. • Report of emergency destruction. Emergency destruction of

cryptographic materials should be reported to higher authority if communication exists. Plain language may be used as a last resort, quoting short titles only.

110



Examples: “All Communication publications and confidential papers

destroyed, except (short title plain language)”. “All codes destroyed” (Plain language) “Now destroying all registered publications and police

equipment” (in one photographic form).

111



CHAPTER 10- NETWORK SECURITY

Introduction 2.0.10.1. This chapter contains information on network security. Contents 2.0.10.2. This chapter contains topics on: 1. Network Management 2. Connecting Networks 3. Gateways 4. E-mails 5. Remote Access

6. Virtual Private Networks 7. Virtual LANs

Network Management 2.10.1.1. Network Management PNP Units SHOULD:

a. apply logical access controls to the network, b. use gateways to defend the ‘perimeter’ and sensitive parts of their network, and c. be aware of the high–risk points of connectivity in the network. Example: Dial–in connections and Internet gateways are high–risk points.

2.10.1.2. Configuration Management PNP Units SHOULD keep the network configuration under the control ofa central network management group. All changes to the configuration SHOULD be:

a. approved through a formal change control process, b. documented, and c. comply with the network security policy and security plan.

PNP Units SHOULD regularly review the configuration to ensure it conforms to the documented configuration. Connecting Networks 2.10.2.1. Inter-Network Connections Connections between networks of differing security policies MUST have mechanisms and processes in place to prevent and monitor unintended information flow and access.

112



2.10.2.2. Inter-Network Security Policy PNP Units SHOULD ensure that:

• the information flow over inter–network connections is consistent with the PNP ICT Security Policy; • the use of the connections is limited to those users who are authorized to use them; • all users are held accountable for their actions in relation to use of the connections; • all users operate over the connections within the limits of their required rights and privileges; • the confidentiality of information is assured; • any additional security required to protect caveats, codewords and/or special handling requirements are implemented; and • the integrity of the information flowing over the connections is preserved.

Risk of Undesirable Cascaded Connections 2.10.2.3. Before a PNP Unit connects a classified network to another network, the ITSSO/CTSSO SHOULD obtain a list of networks to which the other network is connected. The ITSSO/CTSSO SHOULD examine information from both sources to determine the existence of possible undesirable cascaded connections.

Gateways

2.10.3.1. Definition: Gateway. A gateway is a secured connection between two networks. Gateways usually consist of one or more of:

• firewalls; • routers; • proxy servers; • data diodes; • e-mail servers; • content filters; and • VPN gateways.

2.10.3.2. Definition: Firewall A firewall is a network device that filters incoming and outgoing network data, based on a series of rules. A firewall is one of the principal components used in gateways.

113



2.10.3.3. Definition: One-way Gateway A one–way gateway is a gateway through which data can only flow in one direction. Depending on the requirements, one–way gateways can be deployed two different ways. They can be configured to allow either: a. data from a less trusted system to be pushed up into a more trusted system whilst preventing data in the more trusted system from entering the less trusted system (Low to High), or

b. data from a more trusted system to be pushed down into a less trusted system whilst preventing data, or users, in the less trusted system from entering the more trusted system (High to Low).

2.10.3.3. Definition: Data Diode Data diodes are usually the principal component in Low to High one–way gateways. It is a hardware or hardware and software device that allows data to flow in only one direction. This is generally achieved by breaking the electrical or optical connection on the return path. 2.10.3.4. Requirements of Gateways PNP Units MUST ensure that:

a. all PNP networks are protected from other networks by gateways; and

b. the device used to control the data flow meets the relevant assurance level defined below.

PNP Units SHOULD ensure that gateways: • are the only communications routes into and out of internal networks; • by default, deny all connections to internal networks from outside sources; • allow only explicitly authorized connections; • have a documented network access policy; • are managed via a secure path; • are kept up to date with security patches; • provide sufficient audit capability to detect gateway security breaches and attempted network intrusions; and • provide real–time alarms.

2.10.3.5. Ingress Filtering Gateway routers SHOULD be configured to comply with ICT Security SOP Network Ingress Filtering to reduce the risk of government computers being used in denial of service attacks against other sites

2.10.3.6. Gateway Assurance Levels PNP Units MUST use a gateway device (e.g. firewall or one–way diode) that has been evaluated to higher level when connecting a SECRET or RESTRICTED network to any lower classification or external network or system. Where a

114



SECRET or RESTRICTED network is connected to another network of the same classification, or a CONFIDENTIAL or Unclassified system is connected to an external network or system, PNP Units SHOULD use some form of traffic flow control. 2.10.3.7. Content and volume checks PNP Units SHOULD monitor the content and volume of the data being transferred in and out of its networks to detect problems or misuse.

SECURE ELECTRONIC ENVIRONMENT MAIL (S.E.E.Mail)

2.10.4.1. Definition: The Secure Electronic Environment (S.E.E) is a set of tools, policies and agreements between agencies for the exchange of government material via e-mail and the Web. Essentially, it is a secure extranet for government users. S.E.E.Mail is the e-mail component of S.E.E., providing gateway–to–gateway email protection across the Internet. 2.10.4.2. S.E.E.Mail Architecture The S.E.E.Mail environment is formed by each S.E.E.Mail agency deploying an accredited secure e-mail gateway that signs and encrypts sensitive messages sent between other S.E.E.Mail agencies using S/MIME (Secure Multipurpose Internet Mail Extensions) techniques. 2.10.4.3. S.E.E. Mail Objectives Used appropriately, S.E.E.Mail provides the following assurances:

a. The Recipient in a S.E.E.Mail agency can be highly confident that: • The e-mail message is from the member agency as claimed; • No one outside the agency has read the message; and • No one outside the agency has altered the message. b. The Sender in a S.E.E.Mail agency can be highly confident that: • The sensitive e-mail message can only be read by (the agency of) the recipient; • No one outside the agency can read the message in transit; and • No one outside the agency can alter the message. c. Each S.E.E.Mail agency can be highly confident that: • Sensitive e-mail messages cannot be inadvertently sent to non– S.E.E.Mail agencies; • All e-mail traffic between S.E.E.Mail agencies is secured; and • All e-mail traffic between S.E.E.Mail agencies authenticates the sending agency. Note: The "To:", "From:", and "Subject:" fields are sent unencrypted.

115



2.10.4.4. Forwarding e-mail PNP Units MUST NOT allow automated forwarding of S.E.E.Mail messages unless they can ensure the messages will be appropriately protected going to and at their destinations. This will generally require physical or cryptographic protection of the communication path and destination devices. Remote Access 2.10.5.1. Definition: Remote access is any access to an agency’s system from a location not within the physical control of that agency. Access Control 2.10.5.2.. PNP Units that allow users remote access to systems containing classified information MUST ensure that:

a. the users are authenticated at the start of each session, Note: The DICTM RECOMMENDS that PNP Units use more stringent measures to authenticate remote users than it would for users accessing the systems from sites under the physical control of the agency.

b. the users are given the minimum system access necessary to perform their duties, Note: If privileged access is required remotely, agencies SHOULD ensure that the users require strong authentication; the access is restricted based on time and location; and it is monitored.

c. the users cannot view or download information that exceeds the classification of the remote user’s system, and

d. all data transferred is protected during transmission and at the remote user’s end. See: • Physical Security, p45 • Requirements for Cryptography, p.106

Remote Workstations, PEDs and other Devices 2.10.5.3. PNP Units MUST ensure that any workstations, PEDs and other computing devices used to remotely access government networks are protected to ensure they cannot be exploited for unauthorized access to classified information or government resources. The level of protection MUST be appropriate for the maximum classification on the system and/or available through the remote connection. This will include:

a. physical protection of the equipment and media, See: Protection of Workstations and Media, p.47

b. protection from oversight of information on the screen and printed out, See: Protection of Office Areas, p.46

116



c. network protection from any other networks or systems the device may be connected to, and See: • Risk of undesirable cascaded connections, p.113 • Malicious Code and Anti–Virus Software, p.71 • Web Client Security, p.75

d. clearing equipment and media of all private and classified information before it is released for maintenance or disposal. See: Hardware Security, p.58

Virtual Private Networks 2.10.6.1. Definition: A Virtual Private Network (VPN) encrypts information between two or more parties. It can be used to set up a private channel using existing communications network such as the Internet. 2.10.6.2. Use of VPN. The use of a VPN:

• ensures confidentiality and integrity of data in transit by encrypting the data; • provides some assurance that the connection originates from a trusted source; and • eliminates the cost of using a dedicated encryption link between different sites.

2.10.6.3. Additional Controls for the VPN

The use of VPNs does not obviate the need for traditional security measures. PNP Units SHOULD ensure that measures are in place to:

• authenticate the originator of the connection; • provide access control within the PNP network; • audit the actions of the party obtaining access; See: Logical Access Control, p.56, • maintain the integrity and availability of agency systems; and Example: Against malicious content. • prevent leakage of data of a higher classification to a lower classified network or system.

2.10.6.4. Selecting a VPN Product (CONFIDENTIAL, SECRET, RESTRICTED) PNP Units MUST use Evaluated Products when implementing a VPN for information classified SECRET or RESTRICTED.

See: Evaluated Products, p.54

117



Virtual LANs 2.10.6.5. Many Layer 2 switches can provide a Virtual LAN (VLAN) capability that allows:

a. multiple layer 2 and multiple Layer 3 networks to exist separately on a switch; and

b. a network of computers to behave as if they are on the same LAN even though they may actually be physically located on different LANs. Important: The VLAN capability within switches is not designed to enforce security and techniques have been documented that may allow traffic to pass between the VLANs.

2.10.6.6. Configuration and Administration Policy (CONFIDENTIAL, SECRET, RESTRICTED) Administrative access MUST only be permitted from the most highly classified network or, for networks of the same classification, the most trusted network as determined by the Accreditation Authority. Staff with administrative access or unsupervised physical access to the switch MUST have a security clearance of at least the classification of the highest classified network carried on the switch. The physical security of the switch MUST meet the requirements for the highest classified network carried on the switch. PNP Units SHOULD implement all security measures recommended by the vendor of the switch. Note: if any of the recommendations conflict with this manual then this manual has precedence. Unused ports on the switches SHOULD be disabled. Trunking 2.10.6.7. Using a technique known as trunking, a VLAN may exist across two or more connected switches. This capability MUST NOT be used on switches managing VLANs of differing classifications.

118



CHAPTER 11- DATA TRANSFER

Introduction 2.0.11.1. This topic contains information about transferring data between systems of different classifications, for example, from a classified system to the Internet. Unless stated otherwise, these requirements apply to all methods of transferring data including:

• bi-directional gateways using a firewall; • one-way gateways using a diode; • manual procedures that use software applications to check the data

on a media item during transfer; and • manual procedures that rely on a human to review the data.

Contents 2.0.11.2. This chapter contains the following topics:

1. Content Filtering 2. Temporary Connections 3. Data Import 4. Data Export

Risks Associated with Data Transfer 2.0.11.3. Below are some common risks and recommended treatment with data transfer across system:

If the data is Exported to a less trusted system, there is threat to the confidentiality of the data from the most trusted system. Recommended Countermeasure is to check for and filter sensitive content.

If data is Imported from a less trusted system, there is threat to integrity and availability of the more trusted system. Recommended Countermeasure is to perform integrity checks on the data, and check executable content for malicious code.

Transfer Authorization 2.0.11.4. PNP Units SHOULD ensure that data transfers are either:

a. individually approved by the ITSSO, or CTSSO as the case maybe.

c. performed in accordance with standard processes and procedures.

119



User Responsibilities 2.0.11.5. PNP Units MUST ensure that users:

a. are held accountable for the data they transfer, and b. are instructed to perform the following checks prior to initiating the data transfer:

1) protective marking check, 2) visual inspection, and 3) metadata check, if relevant.

Trusted Source 2.0.11.6. Definition: A trusted source is:

• a person or system formally identified as being capable of reliably producing information meeting certain defined parameters, such as a maximum data classification; or • a person formally identified as being capable of reliably reviewing information produced by others to confirm compliance with certain defined parameters. Examples: Trusted sources may include: • trained sanitization officers tasked with sanitizing data for release to less classified systems; • competent releasing officers tasked with reviewing data submitted by others for release to less classified systems; • an accredited system that automatically generates messages designed for release to less classified systems; and • an automated database replication tool known to operate in an assured manner.

Content Filtering 2.1.11.1. Definition: A filter controls the flow of data in accordance with a designed system security procedures.

Examples: E-mail content scanners and “dirty word” checkers. Guidelines 2.1.11.2. PNP Units SHOULD deploy filters on gateways between their classified systems and other systems. Filtering techniques 2.1.11.3. Below are filtering Techniques:

a. Anti-Virus Scan b. Data Format Check c. Data Range Check d. Data Type Check e. File Extension Check

120



f. Keyword Search g. Metadata Search h. Protective Marking Check i. Visual Inspection

Limiting Transfers by File types (CONFIDENTIAL, RESTRICTED, SECRET) 2.1.11.4. PNP Units SHOULD strictly define and limit the types of files that may be transferred, based on business requirements and the results of a risk assessment. The level of risk will be affected by the degree of assurance PNP Units can place in the ability of their data transfer filters to:

• confirm the file type by examination of the contents of the file; • confirm the absence of malicious content; • confirm the absence of inappropriate content; • confirm the classification of the content; and • handle compressed files appropriately.

Blocking Suspicious Data 2.1.11.5. PNP Units MUST block or drop any data identified by a data filter as suspicious until/unless reviewed and approved for transfer by a trusted source other than the originator. 2.2.11.1. Temporary Connections Interconnecting networks are protected from each other by secure connections known as gateways. In general, however, the temporary connection of a single device will not occur through a traditional gateway. Security controls are therefore needed to ensure that only authorized information flows over the connection.

2.2.11.1.1 Definition: A temporary connection occurs when a system can communicate directly with another device or removable media item via a temporary, human-initiated link. Examples are :

• reading to and writing from removable media inserted into a workstation;

• connecting a PED to a system to update information; and • connecting a laptop to a network to send a few emails.

Airgapped Transfers 2.2.11.1.2. PNP Units transferring data manually between two systems SHOULD use:

• a previously unused piece of media; • a pool of media items used only for data transfer between the two relevant systems; or • a media item which has been sufficiently sanitized to permit its reuse on the less classified of the systems between which the transfer is occurring. See: Media Sanitization, p.61

121



Over Classification of Media 2.11.2.3. PNP Units MUST NOT insert media of any classification into a system of a lower classification.

Classification of Media (CONFIDENTIAL, RESTRICTED, SECRET)

2.11.2.4. PNP Units intending to classify a media item below the classification of the system in which it is inserted SHOULD ensure that:

• the media is read-only; • the media is inserted into a read-only device; or • all data transfers to the media are performed in accordance with agency policy on data export. See: Data Export, p.123

Connection of Portable Computers and PEDs (CONFIDENTIAL, RESTRICTED, SECRET)

2.11.2.5. PNP Units intending to allow portable computers or PEDs to be temporarily connected to a system of a different classification MUST ensure that a firewall of the appropriate assurance is used to protect the more highly classified side of the connection.

This requirement does not apply when a device is using a network purely as a carrier for appropriately encrypted traffic to a remote system. Example: A laptop classified for CONFIDENTIAL does not require a firewall when it is using the Internet to carry only an approved VPN connection back to the PNP’s CONFIDENTIAL network.

Data Import Policy

2.11.3.1. Where the data import occurs via a connection between networks, as opposed to a temporary connection, policy relating to gateways, firewalls and diodes also applies. See: Network Security, p.112 Data Import to a Classified System (CONFIDENTIAL, RESTRICTED,

SECRET)

2.11.3.2. PNP Units importing data to a classified system MUST ensure that the data is scanned for malicious and active content. Exceptions:

• Malicious content may be imported to isolated systems specifically designed for the storage, analysis and/or transmission of such content. • Where the type of data cannot be effectively scanned, and the source and/or content of the data is strictly limited to known safe

122



statues, the Accreditation Authority may choose to approve the importation of unscanned data. Example: Importing automatically generated image files from a fully certified and accredited system known to operate in an assured manner.

Data Export Policy

2.11.3.3.1. Where the data export occurs via a connection between networks, as opposed to a temporary connection, policy relating to gateways, firewalls and diodes also applies. See: Network Security, p.112

Data Export to Less Classified System (CONFIDENTIAL, RESTRICTED, SECRET)

PNP Units SHOULD restrict the export of data to a less classified system by filtering data using at least protective marking checks.

________________________________________________________________

123



PART 3 – CHARTS AND TABLES Introduction 3.0.1.1. This part contains step-by-step illustration charts and tables from different procedures and processes discussed in Parts 1 and 2 of this Manual. Contents 3.0.1.2. This part contains the following sections:

1. Charts 2. Tables

124



Chart 1. Process Stages of ICT Security

125



Chart 2. Risk Assessment Process

NOTE: Follow the Steps for each stages

126



Table 1. Risk Assessment Procedure STAGE 1: ESTABLISHING THE CONTEXT

CONTENTS Risk Assessment Project

The objectives of the project Personnel to conduct the work Timelines and constraints The broad scope and boundaries of the Risk Assessment

Strategy Priorities of the PNP The stakeholders Major threats and opportunities The external drivers

Organization The objectives of the ICT system(s) concerned The internal drivers The key to the success of the ICT system(s) The interconnections to other networks Shared risks with other units Available resources The ICT system’s contribution to the PNP’s wider goals

Assets The tangible assets included within the scope of the risk assessment (e.g. premises, networks, computers, software)

Information that are processed, stored or transferred through the system or environment (e.g. classification, criticality, etc) The services that are provided by the system and how critical are

Evaluation Criteria The legal or statutory requirements

The financial, human resource, and/or operational implications The costs and benefits of actions The level of risk acceptable

127



Chart 3. STAGE 2: IDENTIFYING THE RISKS

TABLE 2. RISK ASSESSMENT TABLE FOR STEP 3

The Risk Assessment Table should contain the following information:

Reference Reference code or number to identify each scenario/event

Description Brief Description of the attack or threat.

Impact Type Describe whether the scenario affects the confidentiality,

integrity, availability of the assets

Impact Rating An assessment of the magnitude of damage the scenario could

cause. (Serious, Significant, Minimal)

Likelihood Rating An assessment of the probability of the attack or frequency of the occurrence of event. (Very High, Moderate, Low, or Very Low)

Risk Rating Is a culmination of the Likelihood, Vulnerability and Impact

Ratings (High, Medium, Low)

128



Chart 4. STAGE 3: ANALIZING THE RISKS

AIMs: 1.To estimate the Likelihood, Vulnerability and Impact from each scenario; 2. To separate the acceptable from the unacceptable risks; and

3. Provide data for the evaluation of treatment.

TABLE 3. IMPACT DETERMINATION TABLE The attack/event would… The Rating is…

• Halt services for more than a day; or • Compromise classified information; or • Cause a loss of trust in the integrity of the

system

SERIOUS

• Interrupt the services for more than 30 minutes; or • Breach need-to-know requirements; or • Cause a loss of trust in the integrity of the system

SIGNIFICANT

• Not interrupt services for more than 30 minutes; or

• Not cause a loss of trust in the integrity of the system

MINIMAL

129



TABLE 4. LIKELIHOOD/THREAT DETERMINATION The threat is likely to occur if the current protection is …

Vulnerability Rating is…

• unlikely to prevent or limit its damage in any way VERY HIGH

• may delay or otherwise hinder it but is unlikely to prevent it MODERATE

• will usually prevent or limit it based on past activity

LOW

• almost certain to prevent it from succeeding or will minimize its effect

VERY LOW

Chart 5. STAGE 4: ASSESSING AND PRIORITIZING RISKS

130



Chart 6. STAGE 5: DEVELOPING A RISK MANAGEMENT PLAN

PROCEDURE: To be taken to determine the appropriate controls and develop Risk Management Plan

STAGE 6: RISK ASSESSMENT DOCUMENT comprises an executive summary derived from other stages including risk assessment and series of risk matrices.

131



Chart 7. DEVELOPING AN ICT SECURITY POLICY NOTE: Consider existing related policies

132



Chart 8. PROCEDURE: DEVELOPING A SYSTEM SECURITY PLAN (SSP)

133



Chart 9. CHANGE PROCESS

FOR System User, ITSSO, CTSSO

FOR ITSSO, CTSSO

134



Chart 10. STEPS IN HANDLING MALICIOUS CODES

135



Chart 11. HARDWARE DISPOSAL PROCESS

136



Chart 12. DEVELOPING AN ACCESS CONTROL LIST

137



CHART 13. MANAGING AN AUDIT LOG

138



PART 4: ABBREVIATIONS, GLOSSARY, TOPIC INDEX AND RESOURCE REFERENCES Introduction 4.0.1.1. This part contains the Abbreviations and Glossary of Terms Used in this Manual. Contents 4.0.1.2. This part contains the following sections:

1. Dictionary of Abbreviations 2. Glossary of Terms 3. Topic Index 4. Resource References

139



Dictionary of Abbreviations ACL Access Control List CC Common Criteria CR Certification Report CCRA Common Criteria Recognition Arrangement COMSEC Communications Security CTSSO Communications Technology System Security Officer IDS Intrusion Detection System ICT Information and Communications Technology ICTSP Information and Communications Technology Security Personnel IP Internet Protocol IPT IP Telephony IR Infared ISSP Information System Security Policies ITSEC Information Technology Security Evaluation Criteria ITSSO Information Technology System Security Officer KVM Keyboard/Video/Mouse [switch] LAN Local Area Network MFD Multifunction Device MMS Multimedia Messaging Service PDA Personal Digital Assistant PED Personal Electronic Device (includes PDAs) PKI Public Key Infrastructure PROM Programmable Read-Only Memory PSTN Public Switched Telephone Network PTT Push-To-Talk [telephone] RA Risk Assessment RF Radio Frequency RMP Risk Management Plan ROM Read-Only Memory S/MIME Secure Multipurpose Internet Mail Extension SOP Standard Operating Procedure SSH Secure Shell SSL Secure Sockets Layer SSP System Security Plan STE Secure Telephone TECSEC Technical Security UESB Uniform Equipment Standardization Board VLAN Virtual Local Area Network VOIP Voice Over IP VPN Virtual Private Network

140



Glossary of Terms

A Accreditation authority The Accreditation Authority is the official with the authority to formally assume responsibility for operating a system at an acceptable level of risk. In the PNP, This is a responsibility of the ITMS and the CES but may be delegated to ITSSOs and CTSSOs. Accreditation The formal acknowledgement of the Accreditation Authority’s decision to approve the operation of a particular ICT system. Assessment (RA) The complete documentation package generated by following the risk assessment and risk management process. Audit An independent review of ICT event logs and related activities performed to determine the adequacy of current system measures, to identify the degree of conformance with established policy, and/or to develop recommendations for improvements to the measures currently applied. Availability Ensures that authorized users have access to information and associated assets when required. A marking that indicates that the information has special handling requirements in addition to those indicated by the classification. C Certification authority An entity with the authority to assert that ICT systems comply with the required standards. Certification Report (CR) The CR contains the findings of the certification for a system, site or product. For products evaluated under the Common Criteria or ITSEC, the CR is the definitive document for product specific guidance and provides detailed security information such as a clarification of the scope of the evaluation and recommendations on use of the product. Certification The assertion by an approved entity that compliance with a standard has been achieved based on a comprehensive evaluation. Certification is generally a prerequisite for accreditation. Common Criteria (CC) The CC is an ISO standard (ISO 15408) for ICT security evaluations. The purpose of CC is to ensure that ICT security evaluations world-wide are performed against a common set of requirements, and that the security claims are expressed unambiguously.

141



Communication security (COMSEC) COMSEC is the set of measures and controls taken to deny unauthorized persons information derived from electronic communications and technical eavesdropping. It includes: transmission security, emanation security (including TEMPEST), and physical security of ICT components. Communications Technology Security Officer (CTSSO) The PNP CT Technology Manager (CTSSO) is the person appointed/designated by the CES to manage the security of the Communications Technology of the PNP units. Control or countermeasure A control is a measure that is taken to mitigate risks. Control register A control register is a document used in a Risk Assessment to record the controls required for a site. Controlled space A controlled space is the three dimensional space surrounding equipment or facilities that process classified information within which unauthorized personnel are denied unrestricted access, and. positive measures are taken to control the movement of personnel and materials including vehicles. Cryptographic system A cryptographic system is a related set of hardware and/or software used for cryptographic communication, processing or storage, and the administrative framework in which it operates. D Degaussing The process of applying a magnetic force to remove information from magnetic media. E Encryption is the process of transforming information (referred to as plaintext) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key. The result of the process is encrypted information (referred to as ciphertext). In many contexts, the word encryption also implicitly refers to the reverse process, decryption (e.g. “software for encryption” can typically also perform decryption), to make the encrypted information readable again (i.e. to make it unencrypted). F Firewall is a part of a computer system or network that is designed to block unauthorized access while permitting authorized communications. It is a device or set of devices configured to permit, deny, encrypt, decrypt, or proxy all (in and out) computer traffic between different security domains based upon a set of

142



rules and other criteria set by the firewall administrator. Firewalls can be implemented in either hardware or software, or a combination of both. Firewalls are frequently used to prevent unauthorized Internet users from accessing private networks connected to the Internet, especially intranets. All messages entering or leaving the intranet pass through the firewall, which examines each message and blocks those that do not meet the specified security criteria. Types of firewall techniques include: Packet filter, Application gateway, Circuit-level gateway, and Proxy server. Firmware is a term often used to denote the fixed, usually rather small, programs and data structures that internally control various electronic devices. Typical examples of devices containing firmware range from end-user products such as remote controls or calculators, through computer parts and devices like hard disks, keyboards, TFT screens or memory cards, all the way to scientific instrumentation and industrial robotics. Also more complex consumer devices, such as mobile phones, digital cameras, synthesizers, etc., contain firmware to enable the device's basic operation as well as implementing higher-level functions. G Gateway is a secured connection between two networks. It is a network node equipped for interfacing with another network that uses different protocols. A gateway may contain devices such as protocol translators, impedance matching devices, rate converters, fault isolators, or signal translators as necessary to provide system interoperability. It also requires the establishment of mutually acceptable administrative procedures between both networks. Gateways, also called protocol converters, can operate at any layer of the OSI model. The job of a gateway is much more complex than that of a router or switch. Typically, a gateway must convert one protocol stack into another. Gateway certification A certification that a gateway environment meets the relevant standards. In the PNP, Gateway certification is performed by the ITMS/CES. General User A General User is a User who can, with their normal privileges, make only limited changes to a system and generally cannot bypass system security. General Users are normally those Users who are not Privileged Users. H Hardware The physical components of computer equipment including peripheral equipment. Examples of hardware include: personal computers, mainframe computers, laptops, printers, routers, hubs, personal digital assistants (PDAs), and mobile phones.

143



High Grade An evaluation level in excess of the defined Common Criteria evaluation levels. I ICT Security Evaluation Criteria (ITSEC) The ITSEC is an older national security evaluation criteria developed by European countries in the early 1990’s. The ITSEC specifies seven levels of assurance, known as E0 (Inadequate assurance) to E6 (highest assurance) ICT system For the purposes of this document, an ICT system is a related set of hardware and software used for the communication, processing and storage of information, and the electronic form (not content) of the information that they hold or process. Information Technology and Communications (ICT) Security Policy An Information Technology and Communications Security Policy is a document that describes the information security policies, standards and responsibilities for an agency. Information Technology System Security Officer (ITSSO) The PNP IT System Security Officer (ITSSO) is the person appointed/designated by the ITMS to manage the security of the information and systems of PNP Units. IP telephony The transport of telephone calls over Internet Protocol (IP) networks. It may also be referred to as Voice-Over-IP (VOIP) and Internet Telephony. K Key A key is a sequence of random or pseudo random bits used initially to set up and periodically change the operations performed in crypto–equipment for the purpose of encrypting or decrypting electronic signals, for determining electronic counter-countermeasure patterns, or for producing other keys. M Malicious code Malicious code is any software that attempts to subvert the confidentiality, integrity or availability of a system. It cannot be efficiently controlled by conventional anti-virus software alone. In contrast to viruses that require a user to execute a program in order to cause damage, vandals are auto-executable applications. It can take the form of Java Applets, ActiveX Controls, Scripting Languages, Browser Plug-ins, and Pushed content. Once inside your network or workstation, malicious code can enter network drives and propagate. They can also cause network and mail server overload by sending email messages, stealing data and passwords, deleting document files, email files or passwords, and even re-formatting hard drives. Media is the component of hardware that is used to store information.

144



Media Declassification The administrative decision to remove all classifications from the media, based on an assessment of relevant issues including the consequences of damage from disclosure or misuse, the effectiveness of any sanitation procedure used, and the intended destination of the media. Media Reclassification The administrative decision to change the classification of the media, based on an assessment of relevant issues including the consequences of damage from unauthorized disclosure of misuse, the effectiveness of any sanitation procedure used, and the intended destination of the media. Media Sanitation The process of erasing or overwriting information stored on media. The process of sanitation does not automatically change the classification of the media, nor does sanitation involve the destruction of the media. Multifunction Devices The class of devices that combine printing, scanning, copying, faxing and/or voice messaging functionality within the one device. These devices are designed to connect to a computer and telephone network simultaneously. N Need-to-know The principle of telling a person only the information that they require to fulfill their role. network, and may consume computer resources destructively. Non-volatile media Non–volatile media is media that retains its information when power is removed. P Peripheral switches Devices used to share a set of peripherals between a number of computers. The most common type of peripheral switch is the Keyboard/Video/Mouse (KVM) switch. Privileged User A Privileged User is a User who can alter or circumvent system security protections. This may also apply to Users who may have only limited privileges, such as software developers, who can still bypass security precautions. A Privileged User may have the capability to modify system configurations, account privileges, audit logs, data files or applications. R Risk Register A list, or database, of the risks faced by an agency.

145



Risk The chance of something happening that will have an impact upon objectives. It is measured in terms of consequences and likelihood. S Security Declaration Clearance A written undertaking of an individual stating therein his/her commitment not to disclose in any manner any knowledge or information seen, heard or acquired in any form while working in an entity or institution. Security incident An event that impacts on the confidentiality, integrity or availability of a system through an act of unauthorized access, disclosure, modification, misuse, damage, loss or destruction. standards. System Administrator The person responsible for the day-to-day operation of an ICT system. System Manager The manager responsible for maintaining the technical and operational effectiveness of an ICT system on behalf of the system owner. System Owner The senior agency manager with formal responsibility for a service or group of information resources. T Trusted source A trusted source is a person or system formally identified as being capable of reliably producing information meeting certain defined parameters, such as maximum data classification, or a person formally identified as being capable of reliably reviewing information produced by others to confirm compliance with certain defined parameters. U User A User is anyone with access to a system. A User is not necessarily an employee of the organization that owns the system. V Virus A computer virus is a computer program that can copy itself and infect a computer. The term "virus" is also commonly but erroneously used to refer to other types of malware, adware, and spyware programs that do not have the reproductive ability. A true virus can only spread from one computer to another (in some form of executable code) when its host is taken to the target computer; for instance because a user sent it over a network or the Internet, or carried it on a removable medium such as a floppy disk, CD, DVD, or USB drive. Viruses can increase their chances of spreading to other computers by infecting files on a network file system or a file system that is accessed by another computer.

146



TOPIC INDEX COMMUNICATIONS SECURITY, 91 Cryptographic Security, 95 Peripheral Switches, 95 Facsimile Machines, 99 Use for the Transmission of Classified Information, 99 Infrared and Radio Frequency, 96 Policy on infrared and RF devices [Confidential, Secret, Restricted], 96 IP Telephony, 98 Call Authentication and Authorization, 99 Infrastructure Hardening, 98 Network Separation, 98 Networks Interconnections, 98 Standards, 98 Vendor Recommendation, 99 Multifunction Devices (MFD), 99 Additional Requirements for MFDs to be used in CONFIDENTIAL level, 102 Additional Requirements for MFDs to be used in Confidential, Secret or Top Secret level, 103 Additional Requirements for MFDs to be used in RESTRICTED level, 103 Additional Requirements for MFDs to be used in SECRET level, 102 Electronic Storage Devices, 101 Logs, 101 Pins and Passwords, 101 Policies, Plans and Procedures, 100 Requirements for MFDs in PNP Use at the UNCLASSIFIED level, 101 Risks with MFDs, 100 Usage Policy, 100 Physical Security, 91 Importance of Physical Security, 91-92 Types of Barriers on Physical Security, 92 Telephone and Pagers, 97 Cordless and Mobile Phones, 97 Paging Services, 97 Telephones in Classified Areas, 97 Use of Telephones for Transmission of Classified Information, 97 Transmission Security, 93 Safeguards in the Use of Selected Means of Transmission, 93 Selecting the Means of Transmission, 93 Wireless Networks, 95 Policy (Confidential), 95-96 Policy (Secret, Restricted), 95 Security Issues with Wireless Networking, 95

147



CRYPTOGRAPHY, 104 Approved Cryptographic Algorithms, 107 Key Management, 107 Access Register, 108 Accounting, 109 Area Security and Access Control, 109 Audits, 109 Cryptographic System Administrator Access, 108 Cryptographic System Material, 108 Cryptographic System Requirements, 108 Cryptographic System, 108 Destruction, 109 Emergency Destruction, 110 Key Recovery, 109 Routine Destruction, 109 Fundamentals of Cryptography, 104 Personnel Authorized to Perform Cryptographic Duties, 104 Safety Measures to Ensure Cryptographic Security, 105 Requirements for Cryptography, 106 Approval of Cryptography , 106 Approve Algorithms and Protocols, 107 Key Support, 107 Requirement for transit Encryption, 106 Requirements for storage encryption, 106 Risk Considerations for Storage of Encryption, 106 DATA TRANSFER, 119 Risks Associated with Data Transfer, 119 Transfer Authorization, 119 Trusted Source, 120 User Responsibilities, 120 Content Filtering, 120 Blocking Suspicious Data, 121 Filtering techniques, 120 Guidelines, 120 Limiting Transfers by File types, 121 Data Import, 122 Data Import to a Classified System, 122 Policy, 122 Data Export, 123 Data Export to Less Classified System, 123 Policy, 123 Temporary Connections, 121 Airgapped Transfers, 121 Connection of Portable Computers and PEDs, 122 Over Classification of Media, 122

148



DEVELOPING A SYSTEM SECURITY PLAN, 29 About System Security Plans (SSPs), 29 Development and maintenance, 29 Purpose, 29 Stakeholders, 29 Developing an SSP, 30 Procedure, 30 DEVELOPING AND MAINTAINING SOPs, 31 SOP Contents, 31 Data Transfers, 32 Improper use of general access rights, 34 System Administrator SOPs, 32 System backup and recovery, 33 System Maintenance and Hardware Destruction, 32 System Users, 33 System Users–SOPs, 33 User Account Management, 32 User guidance, 34 SSP and SOPs, 31 HARDWARE SECURITY, 58 Classifying, Labeling and Registering Hardware, 58 Classifying Hardware, 59 Classifying Media, 59 Classifying Volatile Media, 59 Definition: Media Declassification, 58 Definition: Media Reclassification, 59 Hardware Repair and Maintenance, 59 Labeling Hardware and Media, 59 Off–site repairs, 60 On-Site Repairs, 59 Registering Media and Equipment, 59 Disposing of Hardware, 60 Disposal Process, 60 Faulty Media and Hardware, 60 Standards, 60 Media Destruction, 63 Methods, 63 Requirement Media Sanitation, 63 Supervision of the Destruction Procedure, 63 Media Sanitation, 61 Before Disposing of Video Screens, 62 Declassifying and Reclassifying Magnetic Media, 61 Media that cannot be Reclassified or Declassified, 61 Requirements, 61

149



Sanitizing Electrostatic Devices, 62 Sanitizing Magnetic Media by Degaussing, 62 Sanitizing Magnetic Media by Overwriting, 62 Sanitizing non-volatile memory, 62 Portable Computers and Personal Electronic Devices, 63 Additional Requirements for PDAs used above the Unclassified level, 67 Basic Requirements for all PDAs in PNP Use, 66 Definition, 63 Encryption, 65 Formal Approval, 64 Labeling and Physical Protection, 64 PDA Modes, 65 PDAs for Secret and Restricted Purposes, 68 PDAs for Unclassified Purposes, 67 PDAs to be used above the Restricted Level, 68 PDAs to be used for Confidential Purposes, 68 Personal Digital Assistants, 65 Policy, 64 Risks of PDA Usage, 66 Secure configuration, 65 Security Policy Documentation, 64 Server Requirements, 68 Stand alone mode, 65 Server Mode, 66 Use of PDAs, 65 User Authentication, 65 Vulnerabilities of Portable Computers and PEDs, 64 ICT PRODUCT LIFECYCLE, 54 Acquiring Products, 55 Delivery of Evaluated Products, 55 Delivery of ICT Products, 55 Installing and Configuring Evaluated Products, 55 Installing and Maintaining Software Products, 55 Leasing Arrangements, 55 Operation of Evaluated Products, 56 Patching and Hardening Products, 56 Use of Evaluated Products in Unevaluated Configurations, 55 Data Migration and Archiving, 56 Logical Access Control, 56 Maintaining Access and Access Controls, 56 Protection of Data during Migration, 56 Evaluated Products, 54 Advantages of using Evaluated Products, 54 Product Selection, 54 Policy, 54

150



ICT SECURITY, 2 Process Stages, 2 System Disposal, 3 The Process of ICT Security, 2 ICT SYSTEMS, 3 Appointing/Designating ICT Security Officer, 7 Clearance and Briefing Issues, 9 Designating ICT Security Personnel in Administrative Units, 8 Qualifications of CTSSO, 8 Qualifications of ICTSP, 9 Qualifications of ITSSO, 8 ICT Security Officer Responsibility, 9 Administrative Responsibilities of ITSSO, 10 Administrative Responsibilities of CTSSO, 11 Allocation of CTSSO functions, 11 Allocation of ITSSO functions, 10 CTSSO Responsibilities, 11 ITSSO Responsibilities, 9 Primary Responsibility of ITSSO, 9 Primary Responsibility of CTSSO, 11 Reviewing Responsibilities of ITSSO, 10 Reviewing Responsibilities of CTSSO, 12 Technical Security Advice and Training Responsibilities of ITSSO, 10 Technical Security Advice and Training Responsibilities of CTSSO, 11 Security Roles and Responsibilities, 5 Contacting the DICTM, ITMS and CES, 6 The CES’s Role, 6 The DICTM’s Role, 5 The ITMS’s Role, 6 System Managers, 12 Documentation, Certification and Accreditation Responsibilities, 12 Protection of ICT Resources, 12 Qualifications and Experience, 12 SOPs, 13 System Manager, ITSSO and CTSSO, 13 System Users, 13 Management of privileged access, 14 Requirements of privileged access (e.g. Administrator accounts), 13 Responsibilities of general users, 13 Types of system users, 13 IDENTIFYING AND DEVELOPING ICT SECURITY POLICIES, 26 Developing an ICT Security Policy, 27 Identifying existing policies and standards, 27 Organizing policy statements, 28

151



Process, 27 PNP ICT Security Policies, 26 ICT Security Policy contents, 26 Inconsistencies between policies, 26 National Security Policy Documents, 26 INTRUSION DETECTION, 85 Intrusion Detection Systems (IDS), 85 IDS on Internet Gateways, 85 IDS on other Gateways, 85 Audit Logs and Analysis, 85 Audit Trail Events, 86 Audit Trail Facility, 86 Audit Trail for Software Components, 86 Audit Trail Protection and Archival, 86 Database, 87 E-mail System, 87 Gateways, 87 Operating System, 87 Resources, 86 Responsibility for Determining Audit Requirements, 86 Web Application, 87 Managing Audit Logs, 88 How to Manage an Audit Log, 88 Responsibility for Managing Audit Logs, 88 Other Logs, 88 System Management Logs, 88 User Logs, 88 System Integrity, 89 System Changes, 89 System Integrity Checks, 89 System integrity mechanisms aim, 89 Vulnerability Analysis, 89 Authorization, 89 Guidelines, 89 When to Perform, 90 LOGICAL ACCESS CONTROL, 80 Access and Authorization, 82 Definition: Access Control List, 82 Developing an ACL, 83 Guidelines, 82 Multilevel Systems, 83 Compartmented Mode, 83 Dedicated, 83 Multilevel Mode, 84 Security Requirements, 83

152



System High, 83 Privileged and System Accounts, 82 Default Password, 82 Group Accounts, 82 Use of Privileged Account, 82 User Identification and Authentication, 80 Login Audit, 81 Methods for User Identification and Authentication, 80 Password Management, 81 Password Selection, 80 Screen and Session Locking, 81 Suspension of Access, 81 MAINTAINING ICT SECURITY AND MANAGING SECURITY INCIDENTS, 35 Change Process, 36

Allowing Continued Attacks, 39 Detecting Security Incidents, 37 Effectiveness of Tools, 38 Guidelines, 38 Handling Data Spillage, 39 Handling Malicious Code Infection, 39 Implementation of Tools, 38 Integrity of Evidence, 40 Managing Security Incidents, 38 Recording Incidents, 39 Reporting, 38 Standard, 37 User Awareness, 38 Managing Change, 36 Change Management Standards, 36 Change Process, 36 Types of System Changes, 36 Maintaining ICT security, 35 Compliance with security policy, 35 MANAGING RISK, 19 ICT Security Risk Management, 19 Analyzing the Risks, 22 Appropriate level of detail, 20 Assessing and Prioritizing Risks, 23 Consistency with standards, 19 Determining the scope, 20 Developing a Risk Management Plan, 24 Development and maintenance, 19 Establishing the Context, 20 Guidance for the Risk Assessment Process, 20 Identifying the Risks, 21

153



Likelihood/Threat determination, 23 Outsourcing, 19 Risk Assessment Document, 25 The Risk Assessment document content, 25 NETWORK MANAGEMENT, 112 Gateways, 113 Content and volume checks, 115 Definition: Data Diode, 114 Definition: Firewall, 113 Definition: Gateway, 113 Definition: One-way Gateway, 114 Gateway Assurance Levels, 114 Ingress Filtering, 114 Requirements of Gateways, 114 Network Security, 112 Configuration Management, 112 Connecting Networks, 112 Inter-Network Connections, 112 Inter-Network Security Policy, 113 Network Management, 112 Risk of Undesirable Cascaded Connections, 113 Remote Access, 116 Access Control, 116 Remote Workstations, PEDs and other Devices, 116 Secure Electronic Environment Mail (S.E.E.Mail), 115 Forwarding e-mail, 116 S.E.E. Mail Objectives, 115 S.E.E.Mail Architecture, 115 Virtual LANs, 118 Configuration and Administration Policy, 118 Trunking, 118 Virtual Private Networks, 117 Additional Controls for the VPN, 117 Selecting a VPN Product, 117 Use of VPN, 117 PERSONNEL, 50 Clearances and Briefings Requirements, 52 Clearances for Privilege Users, 53 Responsibilities, 52 Training Resources, 51 Clearances and Briefings, 52 Disclosure of information while on courses, 52 ICT Security Trainers, 51 ICT System and Security Officers, 51 ICT Users, 51

154



PNP ICT Security Awareness Training Programs, 52 Policy, 52 User Training and Awareness, 50 Degree of Security Training, 50 Promoting User Awareness, 51 Security Education, 50 Training responsibility, 50 PHYSICAL SECURITY, 45 Emergency Procedures, 48 Environment Testing, 46 Site-Specific Advice, 46 Fundamentals of ICT Physical Security, 45 Risk Review, 46 Storage Requirement, 45 Unclassified System, 46 Protection of Office Areas, 46 Protection of Servers and Communications Equipment, 47 Administrative Measures, 47 Protection of Workstations and Media, 47 ICT Resources incidents, 48 Physical Security Incidents, 48 Protection of hardware, 48 Protection of laptops, 48 Protection of removable media, 48 REVIEWING ICT SECURITY, 41 ICT Security Review, 41 Follow-up after reviews, 42 Frequency, 41 Who conduct a review, 42 Process for Review of ICT Security, 42 SECURITY DOCUMENTATION, 15 Classifying ICT Security Documents, 17 Document classification, 18 Requirements for ICT Security Documentation, 15 High–level documents, 15 ICT Security Policy, 15 Risk Assessment for ICT systems, 15 Standard Operating Procedures, 16 System Security Plans, 16 Using a documentation framework, 16 Using higher level documents to avoid repetition, 6 The Documentation Process, 16 Documentation maintenance, 17 SOFTWARE SECURITY, 70 Malicious Code and Anti-Virus Software, 71

155



Countermeasures against Malicious Code, 71 Handling Malicious Code Infection, 72 Methods of Infections, 71 Recommendations, 71 Recovering from Malicious Code Infections, 72 Requirements for Content Recovery, 72 Standards, 71 Operating System, 70 Requirements, 70 Risk Considerations, 70 Service Packs and Patches, 70 Software Applications, 73 Accountability, 74 Anonymity and Privacy Problems, 75 Applications and Plug-ins, 76 Auditing and Access Control, 75 Automatic Forwarding of Received E-mails, 77 Blocking of In-bounds E-mails, 78 Blocking of Outbound E-mails, 78 Client Software Hardening, 75 Client-side Active Content, 76 Communications Protection, 74 Cookies, 76 Data base Files, 74 Data Labeling, 73 Database Security, 73 Electronic Mail – Protective Marking Policy, 78 Electronic Mail Security, 76 E-mail Gateways, 77 Format of the Protective Marking, 78 Guidelines, 77 Integrity and Availability, 74 Location of the Protective Marking, 78 Minimum Standards, 77 Printing E-Mail Messages, 79 Reasons for Establishing Electronic mail (e-mail) security controls, 76 Remote Access, 77 Search Engines, 74 Security Standards, 73 Server Auditing, 78 Server Handling, 74 Software Security Policy, 73 The main components of an e-mail system, 76 The objective of web security, 74 Users, 76

156



Web Application Security, 74 Web Client Security, 75 Website Content, 75 Software Development, 79 Software Development Environment, 79 Software Testing, 79

157



REFERENCES AND INFORMATION SOURCES This page is especially dedicated to provide the users of this manual a list of suggested reading reference and data sources that have been useful during the writing of this material. LAWS, POLICIES, STANDARDS AND RELATED STUDIES:

1. NZ ICT Security Manual. NZSIT 402:2008

2. REPUBLIC ACT NO. 7925 Entitled “An Act to Promote and Govern the Development of Philippine Telecommunications and the Delivery of Public Telecommunications Services”.

3. NTC Memorandum Circular No. 05-06-2007 “Consumer Protection Guidelines”.

4. REPUBLIC ACT 8792 entitled “The Philippine E-Commerce Law”

5. Stage two and three of the UN-ASPA Five Stages of E-Government

6. DICTM Administrative and Operational Manual, November 2009.

7. NAPOLCOM RESOLUTION NO. 2009- 709 Prescribing the Standard Specifications for PNP Data Warehouse through its PNP Uniform and Equipment Standardization Board (UESB) Resolution No. 2009-141.

8. NAPOLCOM RESOLUTION NO. 2005- 286 Prescribing the Standard Specifications for Laptop Computer through its PNP Uniform and Equipment Standardization Board (UESB) Resolution No. 2003-23 .

9. NAPOLCOM RESOLUTION NO. 2009- 630 Prescribing the Standard Specifications for Personal Computer through its PNP Uniform and Equipment Standardization Board (UESB) Resolution No. 2005-384.

10. PNPLS SOP “Procedures and Guidelines to be Followed by PNP COMMEL Personnel in the Conduct of Turn-over of COMMEL Equipment for Property Turn-in and/or for Repair to Hqs. COMMEL Service.

11. PNP REGULATION 200-012 “Promulgating Rules Governing Security of

Classified Matters in all PNP Offices and Units”. 12. PNPCES SOP 2005-001 “Security Consideration Prior to Repeater

Installation and for Existing PNP Repeaters”.

158



13. PNPCES SOP 2005-006 “Guidelines and Procedures to be Followed by PNP COMMEL Personnel in the Conduct of Maintenance and Safekeeping of Government Issued Properties”.

14. PNPCES SOP “Duties of Personnel Assigned with the Facilities,

Operations and Records/COMCENTER Division PNP COMMEL Service”. 15. PNPCS SOP 2004-3 “Deployment of IT Personnel to other Offices/Units’. 16. PNPCS WSCSD: Guidelines and SOPs of Web Services and Cyber

Security Division. 17. Philippines: Government to Explore Benefits of Open Source Law.

Free/Open Source Software in the Philippines (FOSS) Act of 2007.

159



INTERNET/WEB ASSIST:

The following web sites have been the rich source of subject information and helpful research materials during the writing of this manual:

1. http://www.gcsb.govt.nz/newsroom/nzsits/nzsit-402-feb08 2. http://www.securityresearch.at/en/is-services/risk-management/ 3. http://www.bsec.canterbury.ac.nz/acis2008/Papers/acis-0199-2008 4. http://www.govinfosecurity.com 5. http://www.itu.int/newsroom/media-kit/story5.html 6. http://www.analysysmason.com/Consulting/Services/Planning/ICT-

technical-capability/ICT-security-advice/ 7. http://fas.org/irp/world/new_zealand/qcbs/index.html 8. http://www.interhack.net/pubs/network-security/network-

security.html#SECTION00040000000000000000 9. ttp://www.dlsu.edu.ph/research/centers/aki/_pdf/_concludedProjects/_volu

meI/Sipinetal.pdf 10. http://www.isiswomen.org/index.php?option=com_content&view=article&id

=810:philippines-government-to-explore-benefits-of-open-source-law&catid=21:cim&Itemid=230

160



PDIR (ATTY) MAGTANGGOL B GATDULA, PhD/CEO VI

Director, DICTM

PCSUPT LEO M KISON, MPA, PESE Deputy Director, DICTM

PCSUPT (ATTY) NAPOLEON R ESTILLES, PhD/CEO VI

Executive Officer, DICTM

- - - - -

WRITERS/RESEARCHERS: PCINSP HARRY R LORENZO III

NUP Emilia C. Cawa

REVIEW AND AMENDMENTS: PSSUPT ALLAN A PARREÑO PSSUPT ELMER C BANTOG PSSUPT BERNABE M BALBA

PSUPT CARLO JOSEPH T ESCOBAL PSUPT RUBEN B BORRES

PCINSP JOHN MAYNARD C ANDAN PCINSP ROMEO L JOAQUIN

ADMINISTRATIVE ASSISTANCE

PSUPT ASPRINIO M CABULA PSUPT MILO B PAGTALUNAN

PCINSP TERESITA V ESCAMILLAN SPO3 Medel O Badlis NUP Estela Q Olbes

TECHNICAL ASSISTANCE

PSINSP FELIX A DIZON JR PO3 Frederick B Supnet

LAYOUT AND DESIGN:

PO3 Ronie B Desales NUP Mario D Monzon II

161

ICT Security Manual -...

Documents

Transcript of ICT Security Manual -...