National Information Systems And Network Security Standards &
Guidelines
Version 3.0
Published by
National Information Technology Development Agency (NITDA)
January 2013
1
Table of Contents
Section One ... 5
1.1 Preamble ... 5
1.2 Authority ... 5
1.3 Scope ... 6
1.4 Application ... 6
Section Two: ... 7
Part 1: ... Standards for the Categorization of Information for Security Management ... 7
2.1 Purpose ... 7
2.2 Information Security Categorization Standards ... 7
2.2.1 Security Objectives ... 7
2.2.2 Data Categorization Tasks ... 8
2.2.3 Data Security Measures ... 9
Part 2: .... Guidelines for the Categorization of Information for Security Management ... 10
2.3 Security Categorization Guidelines... 10
2.4 Classification of Potential Impact of Security Breach on Organizations and Individuals ... 11
2.5 Security Categorization Applied to Information Types ... 12
2.6 Security Categorization Applied to Information Systems ... 13
Section Three ... 16
Part 1:Minimum Security Requirements for National Information And Information Systems ... 16
3.1 Purpose ... 16
3.2 Information System Impact Levels ... 16
3.3 Minimum Security Requirements ... 17
3.4 Security Control Selection ... 18
3.5 Actionable Tasks and Policies for the MDAs ... 19
3.5.1 Server Security ... 19
3.5.2 General server Configuration Guidelines ... 19
3.5.3 Monitoring ... 20
3.5.4 The Acceptable System Use Policy ... 20
3.5.5 The Password Policy: ... 22
Part 2: ... Guidelines for Minimum Security Requirements for National Information and Information Systems ... 24
3.6 Specifications for Minimum Security Requirements (Metrics of Security) ... 24
3.7 General Password Construction Guidelines ... 26
2
3.7.1 Password Protection Standards ... 27
Section Four: ... 28
Part 1: Standards for Intrusion Detection And Prevention Systems (IDPS). ... 28
4.1 Purpose ... 28
Part 2:Guidelines for Intrusion Detection and Prevention ... 29
4.2 Types of Intrusion Detection and Prevention System (IDPS) ... 29
4.3 General Incident Reporting guideline/policy ... 32
Section Five: ... 34
Part 1: ... Standard for Protecting the Confidentiality of Object Identifiable Information (OII) ... 34
5.1 Purpose ... 34
5.2 Introduction and Identification of OII ... 35
5.3 The Potential Impact of Inappropriate Access To OII ... 35
5.4 Methods for Protecting the Confidentiality of OII and Factors for Determining OII Confidentiality Impact Levels ... 36
5.4.1 Overview ... 36
5.4.2 Distinguishability ... 36
5.4.3 Aggregation and Data Field Sensitivity ... 36
5.4.4 Obligation to Protect Confidentiality ... 37
5.4.5 Access to and Location of the OII ... 37
5.4.6 General Protection Measures ... 38
Part 2: ... Guidelines for Protecting the Confidentiality of Object Identifiable Information (OII) ... 41
5.5 Introduction and Identification of OII ... 41
5.6 Examples of OII Data ... 42
5.7 OII and Fair Information Practices ... 42
5.8 The potential impact of inappropriate access to OII ... 43
5.8.1 Impact Level Definitions ... 44
5.9 Methods for protecting the confidentiality of OII and Factors for Determining OII ... 45
Confidentiality Impact Levels ... 45
5.9.1 Overview ... 45
5.9.2 Distinguishability ... 46
5.9.3 Aggregation and Data Field Sensitivity ... 46
5.9.4 Context of Use ... 46
6.0 Obligation to Protect Confidentiality ... 47
6.1 Access to and Location of the OII ... 48
6.1.1 OII Confidentiality Impact Level Examples ... 48
6.2 Education, Training, and Awareness ... 51
3
6.3 De-Identifying Information ... 52
6.4 Anonymous Information ... 53
6.5 Security Controls ... 54
6.6 Recommendations for developing an incident response plan for breaches involving OII ... 56
6.6.1 Preparation ... 57
6.6.2 Detection and Analysis ... 58
6.6.3 Containment, Eradication, and Recovery ... 58
6.7 Post-Incident Activity ... 58
Section Six... 60
Part 1:Standards on Securing Public Web Server ... 60
6.1 Purpose ... 60
6.2 Web Server Policy ... 60
6.3 Web Server Risk ... 61
6.4 General Configuration Standard ... 61
Part 2:Guidelines on Securing Public Web Server ... 63
6.5 Guidelines ... 63
6.5.1 Deployment of Public Web Server ... 63
6.6 Web Application implementation guidelines ... 65
6.6.1 Application Service Provider Guidelines ... 65
6.6.2 The Internet DMZ Equipment Guidelines ... 66
6.7 GENERAL SECURITY CONCEPT ... 66
Section Seven ... 69
Part 1:Standards on Firewalls and Firewall Policy ... 69
7.1 Purpose ... 69
7.2 The Placement of the Firewalls within the Network ... 69
7.3 Architecture with Multiple Layers of Firewalls ... 69
7.4 Policies Based on IP Addresses and Protocols ... 70
7.5 IP Addresses and Other IP Characteristics ... 70
7.6 TCP and UDP ... 71
7.7 IPsec Protocols ... 71
7.8 Policies Based on Applications ... 72
7.9 Virtual Private Network (VPN) Policy ... 72
7.91 Policy ... 72
7.10 Malicious Application and Virus Policy and Guidelines ... 73
Part 2:Guidelines on Firewalls and Firewall Policy ... 75
7.11 General Guidelines and introduction on Firewalls and Firewall Policy ... 75
Section Eight ... 76
4
Part 1:Cyber Forensic Standards ... 76
8.1 Purpose ... 76
8.2 Overall Action Plan for Implementation of Cyber Forensic ... 76
Part 2:Cyber Forensic Guidelines ... 78
8.3 General Guidelines and Overview of Cyber Forensic ... 78
8.3.1 The Tool Capabilities and Features: ... 78
8.3.2 Handling of Retained Data ... 79
8.3.3 The Data Handover Interface ... 79
8.3.4 The Security framework ... 79
8.3.5 Data exchange techniques ... 80
8.3.6 Backward and Update Compatibility ... 80
8.4 Guidelines and Policy for Acceptable Encryption ... 80
9.0 Definition of Terms ... 81
5
Section One
1.1 Preamble
The National Information Technology Development Agency (NITDA) is mandated by the NITDA Act of 2007 to develop Information Technology in Nigeria through regulatory policies, guidelines, standards, and incentives. Part of that mandate is to ensure the safety of the Nigerian cyberspace and a successful implementation of an electronic government program.
Many establishments have migrated their businesses to the online environment. Information networks in both the private and public sectors now drive service delivery in the country. These networks have thus become critical information infrastructure which must be safeguarded.
This document provides government wide Standards and Guidelines on National Information Systems and Network Security. It contains eight sections, section two to section eight are in two parts. Part 1 contains the Standards while Part 2 contains the Guidelines.
Several International Standards documents were reviewed during the development of this Standards and Guidelines which includes:
1. ISO 17799
2. ISO/IEC 27001, 27002, 27005, 27033 3. OFCOM Guidance on Network Security 4. EU Network Security Framework
5. Information Technology Security Guidelines (ITSG-38) Canada 6. NIST Guideline.
What has been has been put together in this document is what stakeholders consider suitable for the Nigerian environment.
1.2 Authority
National Information Systems and Network Security Standards and Guidelines are issued by the National Information Technology Development Agency (NITDA) in accordance with NITDA Act 2007. They are specifically issued pursuant to sections 6 and 17 of the National Information Technology Development Agency Act 2007 and is subject to periodic review by NITDA. A breach of the guidelines shall be deemed to be a breach of the Act.
6 These standards are mandatory for Federal, State and Local Government Agencies and institutions as well as private sector organizations which own, use or deploy critical information infrastructure of the Federal Republic of Nigeria. They serve as reference for systems auditors, network administrators and security personnel, among others. Additional security guidelines may be developed and used at Agency discretion in accordance with these standards.
MDAs are mandated to use the reporting documents in the appendix to report compliance to NITDA on quarterly basis.
1.3 Scope
This document prescribes minimum standards on 7 primary areas of network security and cyber forensic:
1. Categorization of information 2. Minimum security requirements 3. Intrusion detection and protection 4. Protection of OII
5. Securing public web server 6. System firewall
7. Cyber forensic
1.4 Application
The standards contained herein shall apply to:
Public Sector organizations, including:
Federal and State Ministries
Federal and State Departments,
Federal and State Agencies
Local Governments
Private Sector Organizations and Companies
Non-Governmental Organizations (NGOs)
7
Section Two:
Part 1: Standards for the Categorization of Information for Security Management
2.1 Purpose
This section of the document:
A. Sets minimum standards for the categorization of all information collected, processed and stored using ICT systems based on the objectives of providing required levels of information security according to risk levels, threat thresholds, and impact in order to guarantee :
Confidentiality
Integrity
Availability, and
Survivability and continuity of business processes and information systems in Nigeria.
B. Provides guidelines on information security control areas within each category.
C. Prescribes minimum information security requirements for the management, operation, and technical controls for information in each category.
2.2 Information Security Categorization Standards
This document establishes security categories for both information and information systems. The security categories are based on the potential impact on an organization should certain events occur which jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals.
2.2.1 Security Objectives
The five security objectives of information and information systems specified in these standards are:
1) Confidentiality:
Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. A loss of confidentiality is the unauthorized disclosure of information.
8 2) Integrity:
Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. A loss of integrity is the unauthorized modification or destruction of information.
3) Availability:
Ensuring timely and reliable access to and use of information. A loss of availability is the disruption of access to or use of information or an information system.
4) Survivability:
Ensuring that services continue and those business operations survive a security breach. Survivability is lost in a case of complete disruption of operations and discontinuation of services
5) Authenticity
This means that the data (source), security level, user, time and location are required to be authenticated.
2.2.2 Data Categorization Tasks
These standards and guidelines apply to all MDAs’ data categories and to all user-developed data sets and systems that may access these data, regardless of the environment where the data reside (including cloud systems, servers, personal computers, mobile devices, etc.). The standards apply regardless of the media on which data reside (including electronic, microfiche, printouts, CD, etc.) or the form they may take (text, graphics, video, voice, etc.).
All MDAs are required to maintain data in a secure, accurate, and reliable manner as specified in 2.2.3 and be readily available for authorized use. Data security measures must be implemented commensurate with data sensitivity and risk.
I. Data should be classified into one of the following categories:
a. Restricted – the disclosure of which to any unauthorized persons would be unlawful.
b. Public – data to which the general public may be granted access in accordance with the available laws.
II. Data in both categories require security measures to the degree of which the loss or corruption of the data would impair the business or service functions of the MDA, result in financial loss, or violate law, standards and guidelines. Security measures for data must be set by the data custodian, working in cooperation with the data stewards, as defined below. The following roles and responsibilities must be established for enforcing data standards and guidelines:
a. Data Trustee: Data trustees are senior MDA officials (or their designees) who have planning responsibility for data within their functional areas and management responsibilities for defined segments of institutional data. Responsibilities include assigning data stewards, participating in establishing policies, and promoting data resource management for the good of the entire MDA. (Director/CIO)
9 b. Data Steward: Data stewards must be MDA officials having direct operational-level responsibility for information management - usually Deputy Directors/ Assistant Directors. Data stewards are responsible for data access and policy implementation issues.
c. Data Custodian: Information Technology Services/Department (ITS) is the data custodian. The custodian is responsible for providing a secure infrastructure in support of the data, including, but not limited to, providing physical security, backup and recovery processes, granting access privileges to system users as authorized by data trustees or their designees (usually the data stewards), and implementing and administering controls over the information. (Chiefs)
d. Data User: Data users are individuals who need and use MDA data as part of their assigned duties or in fulfillment of assigned roles or functions within the organization.
Individuals who are given access to sensitive data have a position of special trust and as such are responsible for protecting the security and integrity of those data.
2.2.3 Data Security Measures
All MDAs are required to adopt measures for data security as stated by the data-classification level.
Required measures include the following:
I. Encryption requirements
II. Data protection and access control
III. Documented backup and recovery procedures IV. Change control and process review
V. Data-retention requirements VI. Data disposal
VII. Audit controls VIII. Storage locations
10
Part 2: Guidelines for the Categorization of Information for Security Management
2.3 Security Categorization Guidelines
The following are various levels and types of Information categorization as envisioned in the STANDARD’s part for categorization of information for security management:
i. Information shall be categorized according to its information type. An information type is a specific category of information (e.g., private, confidential, secret) as defined by an organization or, in some instances, by a specific law, Executive Order, directive, policy, or regulation.
ii. Information shall be also categorized according to value, owner, types of access, custodian, retention, user, and etc.
iii. Information must also be classified according to the level of impact of adverse effects should the threats materialize (High, Moderate, Low, Not Applicable)
iv. System information (e.g. network routing tables, password files, and cryptographic key management information) must be protected at a level commensurate with the most critical or sensitive user information being processed, stored, or transmitted by the information system to ensure confidentiality, integrity, availability and survivability.
v. The potential impact value of not applicable only applies to the security objective of confidentiality.
vi. System processing functions (i.e., Programs in execution within an information system such as system processes that facilitate the processing, storage, and transmission of information and are necessary for the organization to conduct its essential mission-related functions and operations) shall be subjected to security categorization.
vii. Storage location based shall be subjected to classification.
viii. In general security matrix has at least five dimensions:
a. Information Type
b. Sensitiveness: Public, Secret, Confidential, c. Action: Creation, Modification, Keep, d. Transfer, Purge, Duplicate, Read, Process e. User: The categories of users of Info. System.
f. Time: When the data is accessible, nights, holidays?
g. Location: Where can I KEEP (act) on information?
11 Note for Example: A chunk of information is in level A; means it is top secret. It can be created only by level H staff, Carried by level G staff, Never Duplicated by anybody, purged only by level G staff. Level G staff cannot read it. Level G staff can keep it at most for 5 hours during the working hours of working days. This web site could only be accessed within the governmental premises etc.
2.4 Classification of Potential Impact of Security Breach on Organizations and Individuals
This Publication defines three levels of potential impact on organizations or individuals should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability). The application of these definitions must take place within the context of each organization and the overall national interest.
2.4.1 The potential impact shall be classified as LOW if:
The loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. A limited adverse effect means for instance that the loss of confidentiality, integrity, or availability might:
(i) cause a degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is noticeably reduced;
(ii) result in minor damage to organizational assets;
(iii) result in minor financial loss; or (iv) result in minor harm to individuals.
2.4.2 The potential impact shall be classified as MODERATE if:
The loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. A serious adverse effect means for instance that the loss of confidentiality, integrity, or availability might:
(i) cause a significant degradation in mission capability to an extent and duration that the organization is able to perform its primary functions, but the effectiveness of the functions is significantly reduced;
(ii) result in significant damage to organizational assets;
(iii) result in significant financial loss; or
(iv) result in significant harm to individuals that does not involve loss of life or serious life threatening injuries.
12 2.4.3 The potential impact shall be classified as HIGH if:
The loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic effect on organizational operations, organizational assets, or individuals. A severe or catastrophic effect means for instance that the loss of confidentiality, integrity, or availability might:
(i) cause a severe degradation in or loss of mission capability to an extent and duration that the organization is not able to perform one or more of its primary functions;
(ii) result in major damage to organizational assets;
(iii) result in major financial loss; or
(iv) result in severe or catastrophic harm to individuals involving loss of life or serious life threatening injuries.
2.5 Security Categorization Applied to Information Types
The security category of an information type may be associated with both user information and system information and can be applicable to information in either electronic or non-electronic form. It must also be used as input in considering the required security category (SC) of an information system (see description of security categories for information systems below).
Establishing a required security category of an information type shall be based on the potential impact for each security objective associated with the particular information type. The format for expressing the security category, SC, of an information type is:
SC information type: {(confidentiality, impact), (integrity, impact), (availability, impact)}
where the acceptable values for potential impact are LOW, MODERATE, HIGH, or NOT APPLICABLE.
EXAMPLE 2.1: If an organization managing public information on its web server determines that there is no potential impact from a loss of confidentiality (i.e., confidentiality requirements are not applicable), a moderate potential impact from a loss of integrity, and a moderate potential impact from a loss of availability. The resulting security category, SC, of this information type is expressed as:
SC public information = {(confidentiality, NOT APPLICABLE), (integrity, MODERATE), (availability, MODERATE)}.
EXAMPLE 2.2: If a law enforcement organization managing extremely sensitive investigative information determines that the potential impact from a loss of confidentiality is high, the potential impact from a loss of integrity is moderate, and the
13 potential impact from a loss of availability is moderate. The resulting security category, SC, of this information type is expressed as:
SC investigative information = {(confidentiality, HIGH), (integrity, MODERATE), (availability, MODERATE)}.
EXAMPLE 2.3: If a financial organization managing routine administrative information (not privacy-related information) determines that the potential impact from a loss of confidentiality is low, the potential impact from a loss of integrity is low, and the potential impact from a loss of availability is low, the resulting security category, SC, of this information type shall be expressed as:
SC administrative information = {(confidentiality, LOW), (integrity, LOW), (availability, LOW)}.
2.6 Security Categorization Applied to Information Systems
In determining the security category of an information system consideration must be given to the security categories of all information types resident on the information system. For an information system, the potential impact values assigned to the respective security objectives (confidentiality, integrity, availability) shall be the highest values (i.e., high water mark) from among those security categories that have been determined for each type of information resident on the information system. The format for expressing the security category, SC, of an information system is:
SC information system = {(confidentiality, impact), (integrity, impact), (availability, impact)} where the acceptable values for potential impact are LOW, MODERATE, or HIGH.
Under this section the value of not applicable cannot be assigned to any security objective in the context of establishing a security category for an information system.
This is in recognition that there is a low minimum potential impact (i.e., low water mark) on the loss of confidentiality, integrity, and availability for an information system due to the fundamental requirement to protect the system-level processing functions and information critical to the operation of the information system.
EXAMPLE 2.4: An information system used for large acquisitions in a contracting organization contains both sensitive, pre-solicitation phase contract information and routine administrative information, if the management within the contracting organization determines that:
(i) for the sensitive contract information, the potential impact from a loss of confidentiality is moderate, the potential impact from a loss of integrity is moderate, and the potential impact from a loss of availability is low; and
14 (ii) for the routine administrative information (non-privacy-related information), the potential impact from a loss of confidentiality is low, the potential impact from a loss of integrity is low, and the potential impact from a loss of availability is low, the resulting security categories, SC, of these information types shall be expressed as:
SC contract information = {(confidentiality, MODERATE), (integrity, MODERATE), (availability, LOW)}, and SC administrative information = {(confidentiality, LOW), (integrity, LOW), (availability, LOW)}.
The resulting security category of the information system is expressed as:
SC acquisition system = {(confidentiality, MODERATE), (integrity, MODERATE), (availability, LOW)}, representing the high water mark or maximum potential impact values for each security objective from the information types resident on the acquisition system.
EXAMPLE 2.5: Where a power plant contains a SCADA (supervisory control and data acquisition) system controlling the distribution of electric power for a large military installation, where also the SCADA system contains both real-time sensor data and routine administrative information, and where the management at that power plant determines that:
(i) for the sensor data being acquired by the SCADA system, there is no potential impact from a loss of confidentiality, a high potential impact from a loss of integrity, and a high potential impact from a loss of availability; and
(ii) for the administrative information being processed by the system, there is a low potential impact from a loss of confidentiality, a low potential impact from a loss of integrity, and a low potential impact from a loss of availability, the resulting security categories, SC, of these information types shall be expressed as:
SC sensor data = {(confidentiality, NA), (integrity, HIGH), (availability, HIGH)}, and SC administrative information = {(confidentiality, LOW), (integrity, LOW), (availability, LOW)}.
The resulting security category of the information system is initially expressed as: SC SCADA system = {(confidentiality, LOW), (integrity, HIGH), (availability, HIGH)}, representing the high water mark or maximum potential impact values for each security objective from the information types resident on the SCADA system. The management at the power plant chooses to increase the potential impact from a loss of confidentiality from low to moderate reflecting a more realistic view of the potential
15 impact on the information system should there be a security breach due to the unauthorized disclosure of system-level information or processing functions. The final security category of the information system is expressed as: SC SCADA system = {(confidentiality, MODERATE), (integrity, HIGH), (availability, HIGH)}.
16
Section Three
Part 1: Minimum Security Requirements for National Information And Information Systems
3.1 Purpose
This section of the document:
a) Prescribes Standards on information system impact levels;
b) Provides list of minimum information security requirements for the management, operation, and technical controls for information in each category.
c) Prescribes actionable and tasked standards on security measures for all MDAs on Network, Server, System acceptable use, Password guidelines, Physical Location and Email Security policy.
3.2 Information System Impact Levels
Organizations are required to categorize their information systems as low-impact, moderate-impact, or high-impact for the security objectives of confidentiality, integrity, and availability. The potential impact values assigned to the respective security objectives are the highest values (i.e., high water mark) from among the security categories that have been determined for each type of information resident on those information systems. The generalized format for expressing the security category (SC) of an information system shall be: SC Information System = {(confidentiality, impact), (integrity, impact), (availability, impact)}, where the acceptable values for potential impact are low, moderate, or high.
Explanatory Note:
a) For the purpose of this document, an information system is a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. Information resources include information and related resources, such as personnel, equipment, funds, and information technology.
b) The high water mark concept is employed in these Standards owing to significant dependencies among the security objectives of confidentiality, integrity, and availability. In most cases, a compromise in one security objective ultimately affects the other security objectives.
c) Since the potential impact values for confidentiality, integrity, and availability may not always be the same for a particular information system, the high water mark concept must be used to determine the overall impact level of the information system. Thus, a low-impact system is an information system in which all three of the security objectives are low. A moderate-impact system is an information system in which at least one of the security objectives is moderate and no security objective is greater than moderate. And finally, a high-impact system is an information system in which at least one security objective is high. The determination of
17 information system impact levels must be accomplished prior to the consideration of minimum security requirements and the selection of required security controls for those information systems.
3.3 Minimum Security Requirements
The minimum security requirements cover the following security-related areas with regard to protecting the confidentiality, integrity, availability and survivability of information systems and the information processed, stored, and transmitted by those systems. The security-related areas include:
i. access control, identification and authentication;
ii. awareness and training;
iii. audit and accountability;
iv. certification, accreditation, and security assessments;
v. configuration management;
vi. contingency planning;
vii. incident response;
viii. maintenance;
ix. media protection;
x. physical and environmental protection;
xi. planning;
xii. personnel security;
xiii. risk assessment;
xiv. systems and services acquisition;
xv. system and communications protection; and xvi. System and information integrity.
The areas represent a broad-based, balanced information security program that addresses the management, operational, and technical aspects of protecting national information and information systems.
Policies and procedures play an important role in the effective implementation of enterprise-wide information security programs within the government/ private systems and the success of the resulting security measures employed to protect national information and information systems. Thus, organizations are required to develop and promulgate formal, documented policies and procedures governing the minimum security requirements set forth in this standard and must ensure their effective implementation.
18
3.4 Security Control Selection
Organizations are required to meet the minimum security requirements in this standard by selecting the required security controls and assurance requirements as described by this document. The process of selecting the required security controls and assurance requirements for organizational information systems to achieve adequate securityis a multifaceted, risk-based activity involving management and operational personnel within the organization.
Security categorization of information and information systems, as required by this publication is the first step in the risk management process. Subsequent to the security categorization process, organizations must select required set of security controls for their information systems that satisfy the minimum security requirements set forth in this standard. The selected set of security controls must include one of three tailoredsecurity control baselines in this document that are associated with the designated impact levels of the organizational information systems as determined during the security categorization process.
- For low-impact information systems, organizations must, as a minimum, employ tailored security controls from the low baseline of security controls and must ensure that the minimum assurance requirements associated with the low baseline are satisfied.
- For moderate-impact information systems, organizations must, as a minimum, employ tailored security controls from the moderate baseline of security controls defined and must ensure that the minimum assurance requirements associated with the moderate baseline are satisfied.
- For high-impact information systems, organizations must, as a minimum, employ tailored security controls from the high baseline of security controls defined and must ensure that the minimum assurance requirements associated with the high baseline are satisfied.
Organizations must employ all security controls in the respective security control baselines.
Security categorization must be accomplished as an enterprise-wide activity with the involvement of senior-level organizational officials including, but not limited to, chief information officers, senior Organizations information security officers, authorizing officials (a.k.a. accreditation authorities), information system owners, and information owners.
To ensure a cost-effective, risk-based approach to achieving adequate security across the organization, security control baseline tailoring activities must be coordinated with and approved by required organizational officials (e.g., chief information officers, senior Organizations information security officers, authorizing officials, or authorizing officials designated representatives). The resulting set of security controls must be documented in the security plan for the information system.
19
3.5 Actionable Tasks and Policies for the MDAs
3.5.1 Server Security
This policy applies to server equipment owned and/or operated by the MDA and to servers registered under any MDA owned internal network domain. This policy is specifically for equipment on the internal MDA network. All internal servers deployed at MDA must be owned by an operational group that is responsible for system administration. Approved server configuration guides must be established and maintained by each operational group, based on business needs and approved by management.
Operational groups should monitor configuration compliance and implement an exception policy tailored to their environment. Each operational group must establish a process for changing the configuration guides, which includes reviews.
• Servers must be registered within the corporate enterprise management system. At a minimum, the following information is required to positively identify the point of contact:
Server contact(s) and location, and a backup contact Hardware and Operating System/Version
Main functions and applications, if applicable
• Information in the corporate enterprise management system must be kept up-to-date.
• Configuration changes for production servers must follow the required change management procedures of the organization.
3.5.2 General server Configuration Guidelines
• Operating System configuration should be in accordance with guidelines.
• Services and applications that will not be used must be disabled where practicable.
• Access to services should be logged and/or protected through access-control methods such as TCP Wrappers.
• The most recent security patches must be installed on the system as soon as practicable, the only exception being when immediate application would interfere with business requirements.
• Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication will do.
• Always use standard security principles of least required access to perform a function.
• Do not use root when a non-privileged account will do.
• If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec).
• Servers should be physically located in an access-controlled environment.
• Servers are specifically prohibited from operating from uncontrolled cubicle areas.
20 3.5.3 Monitoring
• All security-related events on critical or sensitive systems must be logged and audit trails saved as follows:
i. All security related logs will be kept online for a minimum of 1 week.
ii. Daily incremental tape backups will be retained for at least 1 month.
iii. Weekly full backups of logs will be retained for at least 1 month.
iv. Monthly full backups will be retained for a minimum of 2 years.
• Security-related events will be reported to Operation group, who will review logs and report incidents to IT management. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to:
Port-scan attacks
i. Evidence of unauthorized access to privileged accounts
ii. Anomalous occurrences that are not related to specific applications on the host.
3.5.4 The Acceptable System Use Policy
The purpose of this standards is to outline the acceptable use of computer equipment at MDAs. These rules must be put in place to protect the employee and MDA. Inappropriate use exposes MDA to risks including virus attacks, compromise of network systems and services, and legal issues. This policy applies to employees, contractors, consultants, temporaries, and other workers at MDA, including all personnel affiliated with third parties. This policy applies to all
3.5.4.1 General Use and Ownership
i. While MDAs network administration desires to provide a reasonable level of privacy, users must be aware that the data they create on the corporate systems remains the property of the MDA. Because of the need to protect MDAs’ network, management cannot guarantee the confidentiality of information stored on any network device belonging to MDA.
ii. Employees must be responsible to exercise good judgment regarding the reasonableness of personal use. Individual departments must responsible for creating guidelines concerning personal use of Internet/Intranet/Extranet systems. In the absence of such policies, employees should be guided by departmental policies on personal use, and if there is any uncertainty, employees should consult their supervisor or manager
iii. NITDA recommends that any information that users consider sensitive or vulnerable be encrypted.
21 iv. For security and network maintenance purposes, authorized individuals within MDAs
should monitor equipment, systems and network traffic at any time.
v. MDA reserves the right to audit networks and systems on a periodic basis to ensure compliance with this policy.
3.5.4.2 Security and Proprietary Information
a) The user interface for information contained on Internet/Intranet/Extranet-related systems should be classified as either confidential or not confidential, as defined by corporate confidentiality guidelines. Examples of confidential information include but are not limited to: organization private details, corporate strategies, competitor sensitive details, trade secrets, specifications, customer lists, and research data.
Employees should take all necessary steps to prevent unauthorized access to this information.
b) Passwords must be kept secured and not shared. Authorized users must be responsible for the security of their passwords and accounts. System level passwords should be changed quarterly; user level passwords should be changed every six months.
c) All PCs, laptops and workstations must be secured with a password-protected screensaver with the automatic activation feature set at 10 minutes or less, or by logging-off (control-alt-delete for Win2K users) when the host will be unattended.
d) Must use encryption of information in compliance with International standard Acceptable Encryption Use policy.
e) Because information contained on portable computers is especially vulnerable, special care must be exercised. Protect laptops in accordance with the Laptop Security policy of MDAs.
f) Postings by employees from a MDA email address to newsgroups must contain a disclaimer stating that the opinions expressed are strictly their own and not necessarily those of MDAs, unless posting is in the course of business duties.
22 g) All hosts used by the employees for official business must be connected to the MDAs’
Internet/Intranet/Extranet, whether owned by the employee or MDAs, shall be continually executing approved virus-scanning software with a current virus database.
h) Employees must use extreme caution when opening e-mail attachments received from unknown senders, which may contain viruses, e-mail bombs, or Trojan horse code.
i) To deter SPAM and Spoofing, MDAs must use any of the three Email authentication systems:
1. Sender policy framework (SPF) 2. Sender ID
3. Domain Keys Identified Mail (DKIM)
3.5.4.3 Unacceptable Use
The following activities are, in general, prohibited. Employees may be exempted from these restrictions:
during the course of their legitimate job responsibilities (e.g., systems administration staff may have a need to disable the network access of a host if that host is disrupting production services).
Under no circumstances is an employee of MDAs authorized to engage in any activity that is illegal under local, state, national or international law while utilizing MDA-owned resources.
3.5.5 The Password Policy:
Passwords are an important aspect of computer security. They are the front line of protection for user accounts. A poorly chosen password may result in the compromise of MDAs’ entire corporate network.
As such, all MDA employees (including contractors and vendors with access to MDA systems) must be responsible for taking the required steps, as outlined below, to select and secure their passwords.
The purpose of this policy is to establish a standard for creation of strong passwords, the protection of those passwords, and the frequency of change. The scope of this policy includes all personnel who have or are responsible for an account (or any form of access that supports or requires a password) on any system that resides at any MDA facility, has access to the MDA network, or stores any non-public MDA information.
23 3.5.5.1 Operational Practice
a. All system-level passwords (e.g., root, enable, OS admin, application administration accounts, etc.) must be changed on at least a quarterly basis.
b. All production system-level passwords must be part of the enterprise administered global password management database.
c. All user-level passwords (e.g., email, web, desktop computer, etc.) must be changed at least every six months. The recommended change interval is every four months.
d. User accounts that have system-level privileges granted through group memberships or programs must have a unique password from all other accounts held by that user.
e. Passwords must not be inserted into email messages or other forms of electronic communication.
f. Where SNMP is used, the community strings must be defined as something other than the standard defaults of "public," "private" and "system" and must be different from the passwords used to log in interactively.
24
Part 2: Guidelines for Minimum Security Requirements for National Information and Information Systems
This section of the document:
a. Provides guidelines on information system impact levels;
b. Prescribes list of minimum information security requirements for the management, operation, and technical controls for information in each category.
c. Provides actionable and tasked policy on security measures for all MDAs on Network, Server, System acceptable use, Password guidelines, Physical Location and Email Security policy.
3.6 Specifications for Minimum Security Requirements (Metrics of Security)
Access Control (AC): Organizations must limit information system access to authorized users, processes acting on behalf of authorized users, or devices (including other information systems) and to the types of transactions and functions that authorized users are permitted to exercise.
Access Control implementations must include Administrative Safeguards (i.e. Personnel Security (PS) – “Due care” in delegating authority), Technical Safeguards (i.e. Identification and Authentication (IA)) and Physical Safeguards (i.e. Physical and Environmental Protection (PE)):
1. Personnel Security (PS): Organizations must: (i) ensure that individuals occupying positions of responsibility within organizations (including third-party service providers) are trustworthy and meet established security criteria for those positions;
(ii) ensure that organizational information and information systems are protected during and after personnel actions such as terminations and transfers; and (iii) employ formal sanctions for personnel failing to comply with organizational security policies and procedures.
2. Identification and Authentication (IA): Organizations must identify information system users, processes acting on behalf of users, or devices and authenticate (or verify) the identities of those users, processes, or devices, as a prerequisite to allowing access to organizational information systems.
3. Physical and Environmental Protection (PE): Organizations must: (i) limit physical access to information systems, equipment, and the respective operating environments to authorized individuals; (ii) protect the physical plant and support infrastructure for information systems; (iii) provide supporting utilities for information systems; (iv) protect information systems against environmental hazards; and (v) provide required environmental controls in facilities containing information systems.
25 4. Awareness and Training (AT): Organizations must: (i) ensure that managers and users of organizational information systems are made aware of the security risks associated with their activities and of the applicable laws, Executive Orders, directives, policies, standards, instructions, regulations, or procedures related to the security of organizational information systems; and (ii) ensure that organizational personnel are adequately trained to carry out their assigned information security-related duties and responsibilities.
5. Audit and Accountability (AU): Organizations must: (i) store , protect, and retain both content and Non content information system audit records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful, unauthorized, or inappropriate information system activity; (ii) ensure that the actions of individual information system users can be uniquely traced to those users so they can be held accountable for their actions; (iii) store and keep such audit records in accordance with subsisting legislation; (iv) must ensure that such stored logs are secured and must only be retrieved for analysis upon compelled to do so in the course investigations.
6. Certification, Accreditation, and Security Assessments (CA): Organizations must: (i) periodically assess the security controls in organizational information systems to determine if the controls are effective in their application; (ii) develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational information systems; (iii) authorize the operation of organizational information systems and any associated information system connections; and (iv) monitor information system security controls on an ongoing basis to ensure the continued effectiveness of the controls.
7. Configuration Management (CM): Organizations must: (i) establish and maintain baseline configurations and inventories of organizational information systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles; and (ii) establish and enforce security configuration settings for information technology products employed in organizational information systems.
8. Contingency Planning (CP): Organizations must establish, maintain, and effectively implement plans for emergency response, backup operations, and post-disaster recovery for organizational information systems to ensure the availability of critical information resources and continuity of operations in emergency situations.
9. Incident Response (IR): Organizations must: (i) establish an operational incident handling capability for organizational information systems that includes adequate preparation, detection, analysis, containment, recovery, and user response activities; and (ii) track, document, and report incidents to required organizational officials and/or authorities.
10. Maintenance (MA): Organizations must: (i) perform periodic and timely maintenance on organizational information systems; and (ii) provide effective controls on the tools, techniques, mechanisms, and personnel used to conduct information system maintenance.
26 11. Media Protection (MP): Organizations must: (i) protect information system media, both paper and digital; (ii) limit access to information on information system media to authorized users; and (iii) sanitize or destroy information system media before disposal or release for reuse.
12. Planning (PL): Organizations must develop, document, periodically update, and implement security plans for organizational information systems that describe the security controls in place or planned for the information systems and the rules of behavior for individuals accessing the information systems.
13. Risk Assessment (RA): Organizations must periodically assess the risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational information systems and the associated processing, storage, or transmission of organizational information.
14. System and Services Acquisition (SA): Organizations must: (i) allocate sufficient resources to adequately protect organizational information systems; (ii) employ system development life cycle processes that incorporate information security considerations; (iii) employ software usage and installation restrictions; and (iv) ensure that third-party providers employ adequate security measures to protect information, applications, and/or services outsourced from the organization.
15. System and Communications Protection (SC): Organizations must: (i) monitor, control, and protect organizational communications (i.e., information transmitted or received by organizational information systems) at the external boundaries and key internal boundaries of the information systems; and (ii) employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational information systems.
16. System and Information Integrity (SI): Organizations must: (i) identify, report, and correct information and information system flaws in a timely manner; (ii) provide protection from malicious code at required locations within organizational information systems; and (iii) monitor information system security alerts and advisories and take required actions in response.
3.7 General Password Construction Guidelines
Passwords are used for various purposes at MDAs. Some of the more common uses include:
user level accounts, web accounts, email accounts, screen saver protection, voicemail password, and local router logins. Since very few systems have support for one-time tokens (i.e., dynamic passwords which are only used once), everyone must be aware of how to select strong passwords.
Poor, weak passwords have the following characteristics:
• The password contains less than eight characters
• The password is a word found in a dictionary (English or foreign)
• The password is a common usage word such as:
27
Names of family, pets, friends, co-workers, fantasy characters, etc.
Computer terms and names, commands, sites, companies, hardware, software.
Birthdays and other personal information such as addresses and phone numbers.
Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.
Any of the above spelled backwards.
Any of the above preceded or followed by a digit (e.g., secret1, 1secret) Strong passwords must have the following characteristics:
• Contain both upper and lower case characters (e.g., a-z, A-Z)
• Have digits and punctuation characters as well as letters e.g., 0-9, !@#$%^&*()_+|~-
=\‘{}[]:";’<>?,./)
• Are at least eight characters long.
• Are not a word in any language, slang, dialect, jargon, etc.
• Are not based on personal information, names of family, etc.
• Passwords should never be written down or stored on-line. Try to create passwords that can be easily remembered. One way to do this is create a password based on a song title, affirmation, or other phrase. For example, the phrase might be: "This May Be One Way To Remember" and the password could be: "TmB1w2R!" or "Tmb1W>r~" or some other variation.
3.7.1 Password Protection Standards
Do not use the same password for MDA accounts as for other non-MDA access (e.g., personal ISP account, option trading, benefits, etc.). Where possible, don’t use the same password for various MDA access needs. For example, select one password for the Engineering systems and a separate password for IT systems. Also, select a separate password to be used for a WIN2K account and a UNIX account.
Do not share MDA passwords with anyone, including administrative assistants or secretaries.
All passwords must to be treated as sensitive, Confidential MDAs’ information.
Here is a list of "dont’s":
• Don’t reveal a password over the phone to ANYONE
• Don’t reveal a password in an email message
• Don’t reveal a password to the boss
• Don’t talk about a password in front of others
• Don’t hint at the format of a password.
• Don’t reveal a password on questionnaires or security forms
• Don’t share a password with family members
• Don’t reveal a password to co-workers while on vacation
28
Section Four:
Part 1: Standards for Intrusion Detection And Prevention Systems (IDPS).
4.1 Purpose
This section of the document:
Prescribes standards on Intrusion detection and prevention systems (IDPS) that are primarily focused on identifying possible incidents, logging information about them, attempting to stop them, and reporting them to security administrators
Prescribes minimum and type of IDPS technology that must be considered for implementation.
Provides actionable policy on IDPS guideline, and incident Response policy.
This policy describes the characteristics of IDPS technologies that MDAs must adopt and provides recommendations for designing, implementing, configuring, securing, monitoring, and maintaining them. The types of IDPS technologies are differentiated primarily by the types of events that they monitor and the ways in which they are deployed. This publication prescribes the following types of IDPS technologies:
Network-Based, which monitors network traffic for particular network segments or devices and analyzes the network and application protocol activity to identify suspicious activity
Host-Based, which monitors the characteristics of a single host and the events occurring within that host for suspicious activity. Implementing the following recommendations should facilitate more efficient and effective intrusion detection and prevention system use for MDAs.
1. Organizations must use multiple types of IDPS technologies (subject to adequacy of Business Requirement Definition of the Company) to achieve more comprehensive and accurate detection and prevention of malicious activity.
2. Organizations planning to use multiple types of IDPS technologies or multiple products of the same IDPS technology type must considered whether or not the IDPSs must be integrated.
3. Before evaluating IDPS products, organizations must define the requirements that the products must meet.
4. When evaluating IDPS products, organizations should consider using a combination of several sources of data on the products’ characteristics and capabilities.
29
Part 2: Guidelines for Intrusion Detection and Prevention
4.2 Types of Intrusion Detection and Prevention System (IDPS)
The two primary types of IDPS technologies -network-based and host-based- each offer fundamentally different information gathering, logging, detection, and prevention capabilities.
Each technology type offers benefits over the others, such as detecting some events that the others cannot and detecting some events with significantly greater accuracy than the other technologies. In many environments, a robust IDPS solution cannot be achieved without using multiple types of IDPS technologies. For most environments, a combination of network-based and host-based IDPS technologies is needed for an effective IDPS solution. Wireless IDPS technologies may also be needed if the organization determines that its wireless networks need additional monitoring or if the organization wants to ensure that rogue wireless networks are not in use in the organization’s facilities. Network Behavior Analysis (NBA) technologies can also be deployed if organizations desire additional detection capabilities for denial of service attacks, worms, and other threats that NBAs are particularly well-suited to detecting.
Organizations must consider the different capabilities of each technology type along with other cost-benefit information when selecting IDPS technologies.
a) Organizations planning to use multiple types of IDPS technologies or multiple products of the same IDPS technology type must be considered whether or not the IDPSs must be integrated.
b) Before evaluating IDPS products, organizations must define the requirements that the products must meet.
Evaluators also need to define specialized sets of requirements for the following:
1. Security capabilities, including information gathering, logging, detection, and prevention
2. Performance, including maximum capacity and performance features
3. Management, including design and implementation (e.g., reliability, interoperability, scalability, product security), operation and maintenance (including software updates), and training, documentation, and technical support
4. Life cycle costs, both initial and maintenance costs.